Ich habe festgestellt, dass es in der aktuellen Version von Quagga unter Linux eine Regel gibt, mit der die Übermittlung bestimmter Routeninformationen an benachbarte Router über RIPv2 unterdrückt werden kann.
Wenn Router r1 über eine Schnittstelle „nic0“ mit einem anderen Router r2 verbunden ist und r1 über eine andere Schnittstelle „nic1“ mit einem anderen Netzwerk „net1“ verbunden ist, hofft r1, seinem Nachbarn r2 die Route zu „net1“ bekannt geben zu können. Das Netzwerk, sagen wir net0, ist das Netzwerk, das r1 und r2 verbindet, also beispielsweise 10.3.1.32/27, und das Netzwerk „net1“ ist beispielsweise 10.3.1.0/24.
In diesem Fall wird der Routeneintrag von 10.3.1.0/24 (über nic1) nicht an r2 gesendet, da das RIPv2-Programm in Quagga den Eintrag intern unterdrückt und gelöscht hat.
Ich habe den Quellcode von RIPv2 von Quagga geprüft und festgestellt, dass dies an einer Regel liegt: 10.3.1.0/24 hat ein Netzwerkpräfix, das im Netzwerkpräfix von 10.3.1.32/27 enthalten ist, mit anderen Worten, die äußersten linken 24 Bits von 10.3.1.0 sind eine Teilzeichenfolge der äußersten linken 27 Bits von 10.3.1.32.
Aber ich verstehe nicht, warum es eine solche Regel gibt. Ist sie durch den RIPv2-Standard definiert oder nur eine Eigenart von Quagga? Meines Wissens ist die Überlappung zwischen net0 und net1 gültig und sollte aufgrund der „Longest Network Prefix Matching Rule“ beim Routing kein Problem darstellen. Und für den Router r2 muss dieser wirklich wissen, dass es ein größeres Netzwerk gibt, das net1 (im Vergleich zu net0) über r1 erreicht werden kann. Wenn diese Routeninformationen von Quagga unterdrückt wurden, weiß r2 das nicht und die Hosts in net1 können von r2-Seite aus nicht von net0 aus erreicht werden.
Gibt es jemanden, der das weiß?
Danke, Woody
Antwort1
Wenn das Netzwerk 10.3.1.0/24 direkt mit R1 verbunden ist, kann das ein Problem darstellen. In diesem Fall hat R1 überlappende IP-Adressen auf beiden Schnittstellen. Ich bin kein Linux-Experte, aber ich weiß, dass dies auf Cisco-Routern nicht unterstützt wird (und ich bin ziemlich sicher, dass es auch auf keinem anderen Router/keiner anderen Firewall unterstützt wird).
Wenn das Netzwerk nicht direkt mit R1 verbunden ist, muss es einen dritten Router im Netzwerk geben, nennen wir ihn R0. R0 ist direkt mit dem Netzwerk 10.3.1.0/24 verbunden und verbindet sich mit R1 über ein anderes Netzwerk, z. B. 172.16.0.0/24. In diesem Fall sollte das Setup problemlos funktionieren. Ich habe dies auf Cisco-Routern getestet.
10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
R 10.3.1.0/24 [120/1] via 172.16.0.101, 00:00:13, Ethernet0/1 (nic1)
C 10.3.1.32/27 is directly connected, Ethernet0/0 (nic0)
Vielleicht kann Quagga – obwohl es sich nicht darüber beschwert – diese überlappenden IP-Bereiche auf seinen beiden Schnittstellen auch nicht verarbeiten.