Wie man Routen von einem IBGP-Peer zum anderen mit Route-Reflektor wirbt

Wie man Routen von einem IBGP-Peer zum anderen mit Route-Reflektor wirbt

43343
Created On 09/25/18 19:50 PM - Last Modified 06/07/23 19:46 PM


Resolution


 

In diesem Artikel wird das Szenario diskutiert, in dem Routen, die von einem IBGP-Peer gelernt wurden,
aufgrund der Split-Horizon-Regel nicht zu einem anderen IBGP beworben werden und wie man diese Routen mit der Palo Alto Networks Firewall als Routen Reflektor bewerben kann.


Die folgende Topologie wird zu illustrativen Zwecken verwendet:

 

 2016-04-_10-21 -45. png

 

  • B1 und B3 sind IBGP-Peers von B2.
  • IBGP Peering befindet sich in einem etablierten Zustand zwischen B1-B2 und B2-B3.
  • B1 und B3 werben für die Strecken 5.5.5.0/24 bzw. 8.8.8.0/24 jeweils bis B2.
     

 

 

 BGP-Routen sind in der lokalen BGP-Rippe von B2 vorhanden:

 

admin @ B1 > anzeigen-Routing-Protokoll BGP Loc-Rib
virtueller Router: B1 (ID 22) = = = = = = =

Präfix nexthop Peer Weight Locprf org Med Klappe AS-path
* 5.5.5.0/24 local 0 100 i/c 0 0

Gesamt Routen: 1 

 

 

admin @ B2 > anzeigen-Routing-Protokoll BGP Loc-Rib
virtueller Router: B2 (ID 23) = = = = = = =

Präfix nexthop Peer Weight Locprf org Med Klappe AS-path
* 5.5.5.0/24 1.1.1.1 B1 0 100 i/c 0     0
* 8.8.8.0/24 3.3.3.2 B3 0 100 i/c 0 0

Gesamt Routen: 2 

 

B2 enthält die Routen, die von B1 und B3 in der lokalen Rippe beworben werden

 

 

admin @ B3 > anzeigen-Routing-Protokoll BGP Loc-Rib
virtueller Router: B3 (ID 24) = = = = = = =

Präfix nexthop Peer Weight Locprf org Med Klappe AS-path
* 8.8.8.0/24 local 0 100 i/c 0 0

t otal-Routen gezeigt: 1 

 

 

 

Problem:

 

Aufgrund der geteilten Horizont Regel werden keine Routen von B2 beworben:

 

admin @ B1 > Anzeige des Routing-Protokolls BGP Rib-out
virtueller Router: B1 (ID 22) = = = = = = = =

Präfix nexthop Peer Originator ADV Status aggr Status AS-path
5.5.5.0/24 1.1.1.1 B1-B2 0.0.0.0         beworben keine Aggregation

Gesamt Routen gezeigt: 1  

 

 

admin @ B2 > Show-Routing-Protokoll BGP Rib-out
Virtual Router: B2 (ID 23) = = = = = = = =

Präfix nexthop Peer Originator ADV Status aggr Status AS-path

Gesamt Routen angezeigt:

 

 B2 wirbt nicht für Routen zu B1 oder B3, obwohl B2 die ausgeschriebenen Routen in der lokalen Rippe enthält.

 

 

admin @ B3 > anzeigen-Routing-Protokoll BGP Rib-out
Virtual Router: B3 (ID 24) = = = = = = = =

Präfix nexthop Peer Originator ADV Status aggr Status AS-path
8.8.8.0/24 3.3.3.2 B3-B2 0.0.0 .0 beworben keine Aggregation

Gesamt Routen gezeigt: 1  

 

 

 

 

Lösung:

 

Um B2 zu ermöglichen, die Routen zu bewerben, die von IBGP-Kollegen an andere IBGP-Kollegen gelernt wurden, ist es ein Routen Reflektor.

Auf den Peers selbst ist keine Konfiguration erforderlich, sondern nur das Gerät, das als Routen Reflektor fungiert.

Dies erfordert, dass die IBGP-Peers als Client/Non-Client auf B2 konfiguriert werden:

 

Betrachten Sie die folgenden Aspekte der Werbung bei der Konfiguration der Peers als Client/Non-Client:

 

  •   EINE von einem Client erlernte Route kann an einen anderen EBGP-Nachbarn, Kunden und nicht-Client weitergeleitet werden.
  •   EINE Route, die von einem nicht-Client gelernt wurde, kann an einen anderen EBGP-Nachbarn und-Kunden weitergeleitet werden, nicht aber an einen nicht-Client.

 

 

Hinweis: Wenn beide Peers als "nicht-Clients" konfiguriert sind, werden keine Routen beworben.

             ' Nicht-Clients ' ist die Standardeinstellung für den Peer, daher ist der Routen Reflektor standardmäßig deaktiviert.

 

 

In diesem Beispiel sind sowohl die Peers B1 als auch die B3 als Routen-Reflektor-Clients konfiguriert und B2 ist als Routen-reflektorserver konfiguriert:

 

 

B1. png

 

B3. png

 

Konfigurieren Sie folgende Attribute für den Routen Reflektor, die zur Schleifen Prävention eingesetzt werden:

 

Reflektorcluster -ID-als Cluster-ID verwendet

Router -ID-als OriginatorId verwendet

 

CID_OID. png

 

Optional kann das nächste Hopfen Attribut für die vom Routen Reflektor beworbenen Routen als Original oder selbst ausgewählt werden:

 

Self Hop. png

 

Die Routen werden nun von B2 beworben:

 

admin @ B1 > Show-Routing-Protokoll BGP Rib-out
Virtual Router: B1 (ID 22) = = = = = = = =

Präfix nexthop Peer Originator ADV Status aggr Status AS-path
5.5.5.0/24 1.1.1.1 B1-B2 0.0.0.0 a dvertised keine Aggregation

Gesamt Routen gezeigt: 1  

 

 

admin @ B2 > Show-Routing-Protokoll BGP Rib-out
Virtual Router: B2 (ID 23) = = = = = = = =

Präfix nexthop Peer Originator ADV Status aggr Status AS-path
8.8.8.0/24 3.3.3.2 B1 3.3.3. 2 beworben keine Aggregation
5.5.5.0/24 1.1.1.1 B3 1.1.1.1 beworben keine Aggregation

Gesamt Routen gezeigt: 2  

 

Sowohl 8.8.8.0/24 als auch 5.5.5.0/24 werden nun von B2 beworben

 

 

admin @ B3 > anzeigen-Routing-Protokoll BGP Rib-out
Virtual Router: B3 (ID 24) = = = = = = = =

Präfix nexthop Peer Originator ADV Status aggr Status AS-path
8.8.8.0/24 3.3.3.2 B3-B2 0.0.0.0         beworben keine Aggregation

Gesamt Routen gezeigt: 1  

 

 

Routen sind in der BGP-lokal Rippe B1 und B2 zu sehen:

 

admin @ B1 > anzeigen-Routing-Protokoll BGP Loc-Rib
virtueller Router: B1 (ID 22) = = = = = = =

Präfix nexthop Peer Weight locprf org Med Klappe AS-path
8.8.8.0/24 3.3.3.2 B1-B2 0 100 i/c 0        0
* 5.5.5.0/24 lokale 0 100 i/c 0 0

Gesamt Routen: 2  

 

Route 8.8.8.0/24 ist jetzt in lokal-Rib der B1

 

 

admin @ B2> Show-Routing-Protokoll BGP Loc-Rib
virtueller Router: B2 (ID 23) = = = = = = =

Präfix nexthop Peer Weight locprf org Med Klappe AS-path
* 5.5.5.0/24 1.1.1.1 B1 0 100 i/c              0 0
* 8.8.8.0/24 3.3.3.2 B3 0 100 i/c 0 0

Gesamt Routen: 2  

 

 

admin @ B3> anzeigen-Routing-Protokoll BGP Loc-Rib
virtueller Router: B3 (ID 24) = = = = = = =

Präfix nexthop Peer Weight locprf org Med Klappe AS-path
5.5.5.0/24 1.1.1.1 B3-B2 0 100 i/c 0   0
* 8.8.8.0/24 lokale 0 100 i/c 0 0

Gesamt Routen: 2  

 

Route 5.5.5.0/24 ist jetzt in lokal-Rib von B3

 

 

 

Die folgenden Mechanismen werden verwendet, um Schleifen mit Hilfe der Cluster -ID und der Originator-ID- Attribute zu vermeiden:

 

  • Wenn ein BGP-Router im eingehenden Update eine Route von einem iBGP-Nachbarn erhält und das vorhanden sein einer eigenen Router-ID im Originator-ID-Attribut erkennt, wird er das Update ablehnen.
  • Wenn ein BGP-Router eine Route von einem iBGP-Nachbarn erhält, der so konfiguriert ist, dass er als Routen Reflektor funktioniert, und im eingehenden Update das vorhanden sein einer eigenen Cluster-ID im Cluster-List-Attribut erkennt, wird er das Update ablehnen.

 

 



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClfrCAC&lang=de&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language