| |
DG8NGN > HAMNET 28.05.10 14:23l 135 Lines 5217 Bytes #999 (0) @ DL
BID : S5KDB0FHN045
Read: OE5RCO GUEST DL6DBA DG8NGN DG2NBN DB1YAK DL8MEW DM8BS DL5SFI DL6PM
Read: DK3EL OE5SFM
Subj: Problemloesung iBGP
Path: DB0FHN
Sent: 100528/1223z @:DB0FHN.#BAY.DEU.EU [JN59NK Nuernberg] obcm1.07b3
From: DG8NGN @ DB0FHN.#BAY.DEU.EU (Jann)
To: HAMNET @ DL
X-Info: No login password
Hi,
danke fuer die persoenlichen Rueckmeldungen. Die Stichworte "AllowAS In" und
"BGP Confederation" waren Gold wert. Die haben exakt auf die zwei
Problemstellungen gepasst.
Beschreibung des Problems 1 mit Loesungsweg (am besten HAMNET-DL.pdf
oeffnen!):
HF:
DB0ZKA <-Funk-> DB0FOX <-Inet-> DB0FHN <-Inet-> DB0NOE <-Funk-> DB0HBG
IT:
DB0ZKA, DB0FOX, DB0NOE, DB0HBG: AS64631
DB0FHN: AS64626
DB0ZKA <-iBGP-> DB0FOX <-eBGP-> DB0FHN <-eBGP-> DB0NOE <-iBGP-> DB0HBG
Usernetze, welche ueber BGP vermittelt werden:
DB0ZKA: 44.225.44.160/28
DB0FOX: 44.225.44.128/27
DB0NOE: 44.225.44.64/29
DB0HBG: 44.225.44.0/28
Standardeinstellung:
- DB0FHN kennt alle Usernetze
- DB0FHN announced alle Usernetze an DB0FOX und DB0NOE
- DB0NOE verwirft die Routen der Usernetze DB0FOX und DB0ZKA
- DB0FOX verwirft die Routen der Usernetze DB0NOE und DB0HBG
Grund: Routen der eigenen AS-Nummer koennen nur ueber interne BGP-Knoten
vermittelt werden.
Abhilfe:
- DB0FOX: -> Routing -> BGP -> Peers (DB0FHN) -> General -> "AllowAS In:"
<Wert 1 eintragen>
- DB0NOE: -> Routing -> BGP -> Peers (DB0FHN) -> General -> "AllowAS In:"
<Wert 1 eintragen>
Neue Situation:
- DB0FHN kennt alle Usernetze
- DB0FHN announced alle Usernetze an DB0FOX und DB0NOE
- DB0NOE und DB0FOX kennen alle Usernetze
- DB0HBG verwirft die Routen der Usernetze DB0FOX und DB0ZKA
- DB0ZKA verwirft die Routen der Usernetze DB0NOE und DB0HBG
Grund: Routen, welche im AS_Path ueber externe AS verlaufen, werden verworfen
(exaktere Beschreibung als oben).
Abhilfe:
Auf allen Knoten des betroffenen AS mit "Auslandspeering" einfach fuer jeden
Peeringpartner die Option einschalten.
Beschreibung des Problems 2 mit Loesungsweg (am besten HAMNET-DL.pdf
oeffnen!):
HF:
OE2XZR <-Funk-> DB0INN <-Funk-> DB0AAT <-Funk-> DB0HOB
IT:
OE2XZR: AS64520
DB0INN, DB0AAT, DB0HOB: AS64625
OE2XZR <-eBGP-> DB0INN <-iBGP-> DB0AAT <-iBGP-> DB0HOB
^ ^
°-------------iBGP--------------°
Usernetze, welche ueber BGP vermittelt werden:
- DB0INN: 44.225.20.32/29
- DB0AAT: 44.225.20.0/28
- DB0HOB: 44.225.20.48/29
Transfernetz OE2XZR <-> DB0INN, welches ueber BGP vermittelt wird:
- OE2XZR: 44.143.47.0/29
- DB0INN: 44.143.47.0/29
Standardeinstellung:
- alles funktioniert
- Full-Mesh-Konzept gefaellt nicht, ist aber Bedingung fuer iBGP
Grund fuer das "gefaellt nicht": Steigt die Anzahl der Knoten in einem AS,
wird der administrative Aufwand und Datenoverhead laestig.
Abhilfe:
Alternativen "Route Reflector" und "BGP Confederation" pruefen:
- Route Reflector: Single-Point-of-Failure + ein wenig Overhead bleibt und
steigt ab vier Knoten
- BGP Confederation: Benoetigt private AS-Nummern: Bisher 65530 - 65535 fuer
das HAMNET koordiniert (reicht derzeit fuer 6 Standorte).
--> Die Wahl faellt auf BGP Confederation. Doku:
http://tools.ietf.org/html/rfc5065 (Abschnitt 2 ist lesenswert).
Konfiguration:
- DB0HOB: AS65535
- DB0AAT: AS65534
- DB0INN: AS65533
Auf allen Knoten wird nun die BGP-Confederation gesetzt:
-> Routing -> BGP -> Instance (default) -> Confederation: 64525
-> Routing -> BGP -> Instance (default) -> Confederation Peers: 65530-65535
(ging bei mir via Winbox nicht zu setzen -> Terminal)
Neue Situation:
OE2XZR <-eBGP-> DB0INN <-(i)eBGP-> DB0AAT <-(i)eBGP-> DB0HOB
Neues Problem:
Bisher haben wir immer bei jedem BGP-Peer "NextHop = Force Self"
konfiguriert. "Force" ist eigentlich immer schlecht und klingt nach
"Workaround". In diesem Fall hat das "Force Self" dazu gefuehrt, dass DB0HOB
beim Ansprechen des Usernetzes von DB0INN das Paket nicht direkt an die
Backbone-RouterIP von DB0INN geschickt hat (das Backbonenetz zwischen DB0INN,
DB0AAT und DB0HOB ist gebridged), sondern an DB0AAT geschickt wurde. DB0AAT
hat dann zwar das Paket an DB0INN weitergeleitet, aber man moechte das
innerhalb einer Bridge nicht machen. Ausserdem wurden ICMP-Redirect-Pakete
verschickt.
Abhilfe:
Also erstmal wieder NextHop auf "Default" gestellt und nochmal ueberlegt,
warum wir "Force Self" ueberhaupt eingefuehrt haben. Der Grund ist einfach.
DB0INN vermittelt die Route, die von OE2XZR gelernt wurden jetzt (=default)
an DB0AAT mit "NextHop = 44.143.47.6" und nicht mehr (=force_self) mit
"NextHop = 44.224.10.253" (die IP-Adresse von DB0INN im Backbonenetzwerk).
DB0AAT und DB0HOB koennen den NextHop 44.143.47.6 auf Layer-2 gar nicht
erreichen, sondern nur auf Layer-3. DB0AAT und DB0HOB verwerfen daher die
Routen von OE2XZR, die ueber DB0INN kommen.
Weitere Abhilfe:
Ein Blick in http://tools.ietf.org/html/rfc4271 Abschnitt 5.1.3 beschreibt
"NEXT_HOP". Die Option "Multihop" ist fuer jeden BGP-Peer einstellbar. Sie
bewirkt, dass der angegebene NEXT_HOP in einer vermittelten
Routinginformation (in unserem Fall 44.143.47.6) mit den bereits existierenden
Routen berechnet wird. Auf DB0HOB sieht man zum Beispiel jetzt folgenden
Routeneintrag unter "IP -> Routes": 44.225.52.0/24 mit Gateway 44.143.47.6
recursive via 44.224.10.253.
Daher gleich mal die Empfehlung an die Kollegen in OE mit der Option Multihop
beim Problem "Default" oder "Force Self" zu spielen. Ausserdem ist sicherlich
auch in OE das Full-Mesh-Problem etwas groesser als hier.
73,
Jann
Read previous mail | Read next mail
| |
