Wir haben eine Reihe von Maschinen, die sowohl an ein Hochgeschwindigkeits- als auch an ein Niedriggeschwindigkeitsnetzwerk angeschlossen sind; andere Maschinen sind nur mit dem Niedriggeschwindigkeitsnetzwerk verbunden. Ich untersuche die Bereitstellung von OSPF, damit jede Verbindung automatisch die schnellste Route wählen kann. Ich möchte jedoch nicht, dass die Maschinen versehentlich selbst zu Routern werden, daher verwende ich die Option max-metric router-lsa administrativein /etc/quagga/ospfd.conf.
Leider wird nicht nur der Wert für die Kosten der ausgehenden Verbindung zu Werbezwecken auf ∞ gesetzt, sondern es wird auch ∞ (also 65535) als Verbindungskosten verwendet, wenn die Routenkosten auf dem Host berechnet werden. Das Ergebnis ist, dass Pfade, die die Hochgeschwindigkeitsverbindung verwenden, nicht bevorzugt werden, sondern als Pfade mit gleichen Kosten behandelt werden. Wenn ich die max-metricEinstellung entferne, wird korrekt berechnet, dass die Hochgeschwindigkeitsverbindung bevorzugt wird.
Hinweis: Im Moment experimentiere ich nur mit VMs und virtuellen Netzwerken, daher sind die Links tatsächlich gleichwertig und ich gebe die Kosten manuell an. Drei Maschinen sind mit einem Netzwerk verbunden, mit den Adressen 192.168.50.2-4, zwei sind mit einem anderen Netzwerk verbunden, mit den Adressen 192.168.51.2-3, und jede Maschine hat auch eine Loopback-Adresse 192.168.100.x, über die sie sich gegenseitig ansprechen. Hier ist meine Datei /etc/quagga/ospfd.conf auf einer der Maschinen:
hostname ospf
password zebra
enable password zebra
interface eth1
ip ospf area 0
ip ospf cost 1000
ip ospf hello-interval 1
ip ospf dead-interval 5
interface eth2
ip ospf area 0
ip ospf cost 100
ip ospf hello-interval 1
ip ospf dead-interval 5
interface lo
ip ospf area 0 192.168.100.1
ip ospf cost 100
router ospf
log-adjacency-changes
passive-interface lo
max-metric router-lsa administrative
auto-cost reference-bandwidth 1000
log stdout
und hier ist die Routing-Tabelle:
node1# show ip ospf route
============ OSPF network routing table ============
N 192.168.50.0/24 [65535] area: 0.0.0.0
directly attached to eth1
N 192.168.51.0/24 [65535] area: 0.0.0.0
directly attached to eth2
N 192.168.100.1/32 [0] area: 0.0.0.0
directly attached to lo
N 192.168.100.2/32 [65535] area: 0.0.0.0
via 192.168.50.3, eth1
via 192.168.51.3, eth2
N 192.168.100.3/32 [65535] area: 0.0.0.0
via 192.168.50.4, eth1
============ OSPF router routing table =============
Wie Sie sehen, hat der Zugriff auf 192.168.100.2 65535 gekostet und die Weiterleitung erfolgt über beide Schnittstellen.
Gibt es eine Möglichkeit, den Host dazu zu bringen, die Verbindungskosten für seine eigene Berechnung des kürzesten Pfads zu verwenden und gleichzeitig zu verhindern, dass der Host als Transit-Router verwendet wird?
Antwort1
Ich habe es nicht geschafft, Quagga dazu zu bringen, das zu tun, was ich wollte (habe es auch mit FRR versucht, gleiches Problem), aber ich habe festgestellt, dass Bird mit OSPF v3 gut funktioniert. OSPF v3 hat eine integrierte Funktion für Stub-Router, anstatt sich darauf zu verlassen, die Verbindungskosten auf unendlich zu setzen. Quagga/FRR unterstützen RFC 5838 nicht, also konnte ich OSPF v3 nicht mit ihnen ausprobieren.