BRAIN-Kernnetz – BGP als Protokoll zum Austausch der Routing-Informationen

Diese Seite beschreibt nicht die Grundlagen von BGP. Diese sind in diverser Literatur (siehe Literaturhinweise am Ende der Seite) umfangreicher beschrieben.

Vielmehr sollen hier einzelne Problematiken bei der Konfiguration von BGP näher betrachtet und an Hand von konkreten Konfigurationsbeispielen erläutert werden.
Die Konfigurationsbeispiele orientieren sich zunächst an der Syntax von Cisco-IOS und Foundry IronWare. Beispiele für die CLIs anderer Hersteller werden bei Bedarf folgen.

Bitte gewünschte CLI-Syntax auswählen:

Aktuell werden Syntax Beispiele in Cisco-Syntax gezeigt.

Grundkonfiguration

Alle BRAIN-Teilnehmer, die auf Ihren Routern BGP einrichten, um mit dem BRAIN Routen über Peering auszutauschen und noch keine AS-Nummer haben, erhalten in Absprache mit BRAIN eine AS-Nummer aus dem Bereich 65101-65130.
Unter dieser AS-Nummer werden in der Folge mit dem BRAIN-AS 65100 Routing-Informationen über BGP ausgetauscht.

BGP benutzt TCP, daher ist ein sogenanntes Transitnetz zwischen den Peering-Partnern notwendig. Dieses Transitnetz wird üblicherweise von BRAIN vergeben.

In den Beispielen werden nicht offiziell geroutete IP-Adressen aus dem Bereich 10.0.0.0/8 verwendet. In der Praxis müssen diese Adressen natürlich durch offizielle Adressen ersetzt werden. Folgende Adressen, Netze und AS-Nummern werden im Beispiel (siehe Abbildung 1) verwendet:

Transit-Netz:    10.0.1.0/30
BRAIN-IP:        10.0.1.1
Einrichtungs-IP: 10.0.1.2
BRAIN-AS:        65100
Einrichtungs-AS: 65130

Von der Einrichtung
zu annoncierende Netze: 10.10.0.0/16
                        10.20.0.0/16

Die Konfiguration für BGP auf dem Einrichtungs-Router RE1 sieht wie folgt aus:

interface ethernet 1/1
 ip adress 10.0.1.2/30

router bgp
 local-as 65130
 neighbor 10.0.1.1 remote-as 65100

 address-family ipv4 unicast
 network 10.10.0.0/16
 network 10.20.0.0/16
 exit-address-family

MD5-Passwort einrichten

Aus Sicherheitsgründen wird beim Peering mit BRAIN die MD5-Signierung für die BGP-Session verwendet. Dabei wird jedem Paket der TCP-Session eine Checksumme und ein geheimer Key (Passwort) zugeordnet. Dies erzeugt eine kryptografisch sichere Signatur des Paketes. Ohne den Key zu kennen ist es nahezu unmöglich ein Paket mit einer gültigen Signatur für diese Session zu erzeugen. Ist die MD5-Signierung aktiviert, verwirft BGP alle Pakete, die nicht korrekt signiert sind.

Die Konfiguration für MD5-Signierung auf dem Einrichtungs-Router RE1 sieht wie folgt aus:

interface ethernet 1/1
 ip adress 10.0.1.2/30

router bgp
 local-as 65130
 neighbor 10.0.1.1 remote-as 65100
neighbor 10.0.1.1 password geheim

 address-family ipv4 unicast
 network 10.10.0.0/16
 network 10.20.0.0/16
 exit-address-family

Peering von einem Einrichtungs-Router zu zwei BRAIN-Peers

Aus Redundanzerwägungen kann es für eine Einrichtung sinnvoll sein, über zwei getrennte Leitungen zu zwei verschiedenen BRAIN-Routern jeweils eine BGP-Session zu haben. In diesem Beispiel wird die Konfiguration für einen Einrichtungs-Router RE1 betrachtet. RE1 unterhält zwei getrennte BGP-Sessions zu RB1 und RB2.
Dazu wurde ein weiteres Interface auf dem Einrichtungs-Router bereitgestellt (siehe Abbildung 2) und ein weiteres Transitnetz konfiguriert:

Transit-Netz:            10.0.2.0/30
BRAIN-IP auf RB2:        10.0.2.1
Einrichtungs-IP auf RE1: 10.0.2.2

Die BGP-Konfiguration auf RE1 muss jetzt den Umstand berücksichtigen, dass es im Normalfall (also keine Leitungsunterbrechung oder Interfacedefekt) zwei gleichwertige Wege von AS65130 in das AS65100 gibt. Entsprechend gibt es auch zwei gleichwertige Wege von AS65100 in das AS65130.

Ein Load-Sharing über beide Wege soll nicht stattfinden – es soll immer nur ein Link genutzt werden. Welcher Link letztendlich genutzt wird, bestimmt die Konfiguration auf dem Einrichtungs-Router. Der Router muss für den ausgehenden Verkehr einen Link priorisieren und für den reinkommenden Verkehr dem Peering-Partner mitteilen, welcher Link zu AS65130 genutzt werden soll.

Zu diesem Zweck gibt es die BGP-Attribute „Multi-Exit-Diskriminator“ und „Local-Preference“.

Der Multi-Exit-Diskriminator (MED) ändert die Standardgewichtung der an andere BGP-Peers annoncierten Routen. Erhält der Remote-Peer zwei gleiche Routen mit unterschiedlichen MED, bevorzugt er den Link, über den er das Netz mit den niedrigeren MED erreicht.
Mit der Local-Preference versieht der Einrichtungs-Router RE1 die von RB1 und RB2 gelernten Routen mit einer Gewichtung. Für den ausgehenden Verkehr wird der Link bevorzugt, dessen Routen die höhere Local-Preference aufweisen.

Im Folgenden wird gezeigt. wie der Einrichtungs-Router RE1 so konfiguriert werden kann, dass der Link über Interface e1/1 zu BR1 favorisiert wird, also der primary Link ist. Der Link über Interface e1/2 zu BR2 wird dann nur bei Ausfall des primären Links verwendet!

Konfiguration für MED und LOCAL_PREF auf dem Einrichtungs-Router RE1:

interface ethernet 1/1
 ip adress 10.0.1.2/30

interface ethernet 1/2
 ip adress 10.0.2.2/30

router bgp
 local-as 65130
 neighbor 10.0.1.1 remote-as 65100
 neighbor 10.0.1.1 password geheim

! verwende route-map zum setzen des MED fuer annoncierte Routen
 neighbor 10.0.1.1 route-map out setMED-BR1
! verwende route-map zum setzen von LOCAL_PREF fuer empfangene Routen
 neighbor 10.0.1.1 route-map in setPRIMARY_PATH-BR1
! Konfig fuer zweiten Peer (Backup-Link)
 neighbor 10.0.2.1 remote-as 65100
 neighbor 10.0.2.1 password geheim
 neighbor 10.0.2.1 route-map out setMED-BR2
 neighbor 10.0.2.1 route-map in setSECONDARY_PATH-BR2

 address-family ipv4 unicast
 network 10.10.0.0/16
 network 10.20.0.0/16
 exit-address-family
!
access-list 1 permit 10.10.0.0/16
access-list 1 permit 10.20.0.0/16
!
access-list 2 permit any
!
! route-map fuer niedrigen MED zur Priorisierung von BR1
route-map setMED-BR1 permit 10
 match ip address 1
 set metric 100
!
! route-map fuer hohen MED fuer Backup ueber BR2
route-map setMED-BR2 permit 10
 match ip address 1
 set metric 200

! route-map fuer hohe LOCAL_PREF fuer Primary-Link ueber BR1
route-map setPRIMARY_PATH-BR1 permit 10
 match ip address 2
 set local-pref 200

! route-map fuer niedrige LOCAL_PREF fuer Backup-Link
route-map setSECONDARY_PATH-BR2 permit 10
 match ip address 2
 set local-pref 100

Erläuterung:

Der zweite Peer 10.0.2.1 wird analog zum ersten Peer konfiguriert.
Um den MED für zu annoncierende Routen und Local-Preference für die empfangenen Routen zu setzen, werden jeweils Route-Maps konfiguriert.
Mit der set-Anweisung in den Route-Maps bekommen alle „matches“ einen speziellen MED, bzw. eine spezielle Local-Preference. Die Netze, für die ein MED oder eine Local-Preference gesetzt werden sollen, werden in Access-Listen definiert. Auf Access-Listen wird in Route-Maps mit der „match“-Anweisung referenziert. Dazu werden folgende ACLs verwendet:
access-list 1: filtert auf die zu annoncierenden Einrichtungsnetze
access-list 2: erlaubt alle zu lernenden Netze vom BRAIN-Peer
access-list 2 permit any ist notwendig, da Route-Maps ein implizites deny all für die zu filternden Netze enthalten.

Peering von zwei Einrichtungs-Routern zu zwei BRAIN-Peers

Diese Konstellation unterscheidet sich nur unwesentlich in der Konfiguration von Peering von einem Einrichtungs-Router zu zwei BRAIN-Peers. Der zweite Einrichtungs-Router sei RE2 und habe eine Verbindung zum zweiten BRAIN-Router RB2 über Interface e1/1 (Abbildung 3). Auf RE2 wird ebenfalls ein Transitnetz zu RE2 eingerichtet:

Transit-Netz:            10.0.2.0/30
BRAIN-IP auf RB2:        10.0.2.1
Einrichtungs-IP auf RE2: 10.0.2.2

Auch hier muss eine Priorisierung der beiden möglichen Verbindungen zwischen BRAIN und der Einrichtung stattfinden.
Zu beachten ist nun, dass zwischen RE1 und RE2 über eine direkte oder indirekte Verbindung innerhalb des Einrichtungs-AS die Routing-Informationen über von RB1 bzw. RB2 gelernte Routen ausgetauscht werden! Dies wird idealerweise durch die Verwendung von I-BGP (BGP innerhalb eines autonomen Systems) als Protokoll zum BGP-Routenaustausch zwischen RE1 und RE2 erreicht.
Wird nur OSPF als Routing-Protokoll zwischen RE1 und RE2 verwendet, sind zwei Dinge zu beachten:

• Redistributierung der gelernten Routen von BGP ins interne OSPF
• explizite Umsetzung des BGP-Attributs Local-Preference in eine OSPF-Metric

Es folgt die Konfiguration für die beiden Einrichtungs-Router RE1 und RE2. Die Konfiguration für das interne Routing-Protokoll zwischen RE1 und RE2 wird in diesem Beispiel weggelassen und ggf. an anderer Stelle erläutert.

Die Konfiguration für RE1 und RE2:

interface ethernet 1/1
 ip adress 10.0.1.2/30

router bgp
 local-as 65130
 neighbor 10.0.1.1 remote-as 65100
 neighbor 10.0.1.1 password geheim
 neighbor 10.0.1.1 route-map out setMED-BR1
 neighbor 10.0.1.1 route-map in setPRIMARY_PATH-BR1

 address-family ipv4 unicast
 network 10.10.0.0/16
 network 10.20.0.0/16
 exit-address-family
 
access-list 1 permit 10.10.0.0/16
access-list 1 permit 10.20.0.0/16
!
access-list 2 permit any
!
!
! route-map fuer niedrigen MED zur Priorisierung von BR1
route-map setMED-BR1 permit 10
 match ip address 1
 set metric 100

! route-map fuer hohe LOCAL_PREF fuer Primary-Link ueber BR1
route-map setPRIMARY_PATH-BR1 permit 10
 match ip address 2
 set local-pref 200

interface ethernet 1/1
 ip adress 10.0.2.2/30

router bgp
 local-as 65130
 neighbor 10.0.2.1 remote-as 65100
 neighbor 10.0.2.1 password geheim
 neighbor 10.0.2.1 route-map out setMED-BR2 
 neighbor 10.0.2.1 route-map in setSECONDARY_PATH-BR2

 address-family ipv4 unicast
 network 10.10.0.0/16
 network 10.20.0.0/16
 exit-address-family

access-list 1 permit 10.10.0.0/16
access-list 1 permit 10.20.0.0/16
!
access-list 2 permit any
!
!
! route-map fuer hohen MED zum Backup ueber BR2
route-map setMED-BR2 permit 10
 match ip address 1
 set metric 200
!
! route-map fuer niedrige LOCAL_PREF fuer Backup-Link ueber BR2
route-map setSECONDARY_PATH-BR2 permit 10
 match ip address 2
 set local-pref 100

Literatur

Folgende Literatur war für mich zum Verständnis von BGP äußerst hilfreich:

• Routing TCP/IP, Band II
  Umfassendes Handbuch zu externen Routing-Protokollen und erweitertem IP-Routing
  Autor: Jeff Doyle, Jennifer DeHaven Carroll
  Verlag: Markt+Technik
  Seitenzahl: 1060Dieses Buch stammt von CiscoPress und erläutert u. A. die Grundlagen von BGP sehr ausführlich angereichert um zahlreiche Konfigurationsbeispiele für Cisco-Router. Sehr empfehlenswert für Administratoren von Cisco-Technik, die sich auch mit BGP befassen müssen/wollen.
• BGP4 – Inter-Domain Routing in the Internet
  Die kompakteste BGP4-Dokumentation, die ich kenne. Das Buch ist meiner Ansicht nach sehr empfehlenswert, wenn man schon ein Grundverständnis von BGP und Routing mitbringt. Alle wesentlichen Aspekte von BGP4 werden auf nur 130 Seiten dargestellt – genial!
• NetIron Series Configuration Guide
  Brocade Configuration-Guide für IronWare
• RapidOS Command Line Interface Reference
  Riverstone Configuration-Guide für RapidOS
• RapidOS User Guide
  Riverstone User-Guide für RapidOS