Bei der Konfiguration von MP-BGP auf Juniper-Hardware kann eine (nicht) offensichtliche Situation zur Wiederherstellung der Nachbarschaft auftreten. Der Grund wird ausführlich in der Junuper Knowledge Base KB20870 beschrieben . Hier ist eine kurze Nacherzählung mit meinen Kommentaren.
Wie Sie wissen, werden bei der Arbeit mit VPNs mehrere Routing-Tabellen verwendet. Wir werden an zwei Hauptinteressen interessiert sein: vrf.inet.0 und bgp.l3vpn.0 (im Folgenden wird die Situation mit L3VPN beschrieben, dies gilt jedoch auch für andere Dienste, bei denen BGP ein Signalisierungsprotokoll ist).
Die Tabelle bgp.l3vpn.0 enthält alle von BGP-Nachbarn empfangenen Routen.
Direkte / statische Routen eines bestimmten PE-Routers werden in die Tabelle vrf.inet.0 eingefügt , und eingehende Routen von Nachbarn aus der Tabelle bgp.l3vpn.0 , die der Importrichtlinie entsprechen (falls konfiguriert), werden importiert.
Gleichzeitig findet kein Export von vrf.inet.0 nach bgp.l3vpn.0 statt, und Routen werden direkt den Nachbarn angekündigt.
Wenn der Router als Routenreflektor fungiert oder wenn MP eBGP-Nachbarn vorhanden sind, werden die Routen sowohl in der Tabelle vrf.inet.0 als auch in bgp.l3vpn platziert . In diesem Fall wird ein Vergleich mit lokalen Routen durchgeführt und (falls erforderlich) der beste Pfad ausgewählt.
Somit kann der Router in einem von zwei definierten Modi arbeiten:
- Auf dem Router ist kein Router-Reflektor konfiguriert, und es gibt keine eBGP-Nachbarn.
- Der Router ist ein Routenreflektor und / oder es befinden sich eBGP-Nachbarn darauf.
Das Ändern der Modi erfordert das Neustarten von MP-BGP-Sitzungen. Dies ist deutlich an der folgenden Topologie zu erkennen:

In der ersten Version (Abb. 1) wird das klassische Vollnetz-iBGP-Schema vorgestellt. Stellen Sie sich nun vor, wir müssen den R4-Router hinzufügen. Aus dem einen oder anderen Grund haben wir uns dazu entschlossen, indem wir R1 als Routenreflektor für R4 eingestellt haben (Abb. 2). Wenn Sie die Einstellungen des Routenreflektors auf R1 vornehmen, werden alle MP-BGP-Sitzungen (mit den Routern R2 und R3) neu installiert, was zu Ausfallzeiten bei der Bereitstellung von Diensten führt.
Um dies zu vermeiden, wird vorgeschlagen, den Router fest in die 2. Betriebsart zu versetzen. Eine Möglichkeit besteht darin, eine Dummy-eBGP-Gruppe zu erstellen. Zum Beispiel:
group fake-vpn { type external; description "## Preventing mpbgp sessions flap ##"; passive; family inet { any; family inet-vpn { any; family iso-vpn { unicast; family l2vpn { signaling; family evpn { signaling; family inet-mvpn { signaling; family inet-mdt { signaling; neighbor 192.0.2.1 { peer-as 65536; }
AS: 65536 und IP: 192.0.2.1 können absolut alles sein, und im passiven Modus können Sie unnötige Versuche vermeiden, eine nicht vorhandene Sitzung vom Router aus einzurichten.
Wann es nützlich sein kann:
- Es gibt keine dedizierten Routenreflektoren im Netzwerk. Die Rolle von RR sind die Kernrouter des Netzwerks. Gleichzeitig besteht die Möglichkeit einer Änderung ihrer Rolle (z. B. von einem P-Router zu einem P / RR oder umgekehrt).
- Es besteht die Möglichkeit, dass eine eBGP-Schnittstelle mit der MP-BGP-Familie angezeigt wird, z. B. Inter-AS.