Zwei Protokolle, zwei Aufgaben: wann OSPF, wann BGP

Link-State gegen Path-Vector in einem Absatz

OSPF ist ein Link-State-Protokoll. Jeder Router beschreibt in Link State Advertisements, welche Links er hat und was sie kosten, und flutet diese Beschreibung in seiner Area. Am Ende hat jeder Router dieselbe Landkarte, die Link-State-Datenbank, und berechnet darauf mit dem Dijkstra-Algorithmus den kürzesten Weg zu jedem Ziel. Die Kosten leitet Cisco aus der Bandbreite ab: Referenzbandbreite geteilt durch Interfacebandbreite, mit einem Standardwert von 100 Mbit/s als Referenz. Deshalb kosten bei Standardwerten ein 1-Gbit- und ein 100-Gbit-Link gleich viel, nämlich 1, und auf jedem Router gehört derselbe Befehl auto-cost reference-bandwidth in die Konfiguration.

BGP ist ein Path-Vector-Protokoll. Ein BGP-Router kennt keine Topologie, sondern bekommt von jedem Nachbarn eine Liste von Präfixen, an der jeweils der AS_PATH hängt, also die Folge der autonomen Systeme, durch die das Präfix bis hierher gereicht wurde. Findet ein Router die eigene AS-Nummer im Pfad, verwirft er die Route, und so verhindert BGP Schleifen zwischen Netzen. Welchen Pfad er nimmt, entscheidet ein fester Algorithmus über Attribute, nicht über eine Metrik der Leitungen.

Daraus folgt der wichtigste Unterschied für den Alltag. OSPF findet automatisch den technisch besten Weg, aber du kannst ihm kaum sagen, welcher Weg geschäftlich gewollt ist. BGP findet von sich aus nur einen erreichbaren Weg, nimmt aber jede Regel an, die du ihm über Attribute mitgibst.

Wann ein Unternehmen BGP braucht

Die Liste ist kürzer, als viele denken. In diesen Fällen ist BGP gesetzt oder zumindest der saubere Weg, in allen anderen reichen OSPF und statische Routen.

• Multihoming mit zwei Providern, bei dem eingehender Verkehr auf dieselben öffentlichen Adressen über beide Leitungen kommen soll. Dafür brauchst du eine öffentliche AS-Nummer und eigene Adressen. AS-Nummern und IPv6-PI-Adressen vergibt der RIPE NCC auch über einen Sponsoring-LIR. IPv4-Adressen gibt es seit der Erschöpfung des RIPE-Pools nur noch als /24 über die Warteliste für neue LIR-Mitglieder oder über den Transfermarkt.

• Eine private Anbindung an Azure über ExpressRoute oder an AWS über Direct Connect. Beide übergeben Routen per eBGP, und eine private AS-Nummer aus dem Bereich 64512 bis 65534 nach RFC 6996 reicht in der Regel.

• Ein Azure-VPN-Gateway mit mehreren aktiven Tunneln. Microsoft beschreibt BGP dort als optional, aber erst damit schaltet der Verkehr beim Ausfall eines Tunnels automatisch auf den zweiten um.

• Ein MPLS-VPN des Carriers, bei dem der Provider-Edge-Router per BGP die Präfixe der anderen Standorte übergibt. Manche Carrier bieten auch statische Übergaben an, BGP ist aber die Variante, bei der neue Standorte ohne Ticket sichtbar werden.

• Ein Rechenzentrum mit Leaf-Spine-Fabric und EVPN, in dem BGP als Underlay oder als Control Plane für VXLAN dient. Das ist ein eigenes Thema, ändert aber nichts daran, dass der Campus daneben OSPF sprechen kann.

Zwei Provider ohne eigene AS: was dann geht

Viele mittelständische Unternehmen haben zwei Leitungen von zwei Providern, aber keine eigenen Adressen. Jeder Provider vergibt seine eigenen öffentlichen Adressen, und die Adressen von Provider A kann Provider B nicht ankündigen. BGP hilft hier nicht, weil es nichts gibt, was du über beide Leitungen ankündigen könntest.

Ausgehend lässt sich der Fall trotzdem lösen: zwei Default Routes, eine davon als Floating Static Route mit höherer administrativer Distanz, gekoppelt an ein IP-SLA-Tracking, das den Next Hop hinter der Leitung prüft. Eingehend bleibt jeder Dienst an die Adressen eines Providers gebunden. Fällt der aus, muss der DNS-Eintrag auf die Adresse des anderen umgestellt werden, und die TTL bestimmt, wie lange das dauert.

Wer eingehend wirklich ausfallsicher sein muss, etwa für einen eigenen VPN-Konzentrator oder Webdienste im Haus, kommt an eigenen Adressen und eigener AS nicht vorbei. Wer die Dienste ohnehin in die Cloud verlagert, braucht dagegen meist nur ausgehend zwei Wege, und dafür reicht statisches Routing oder ein SD-WAN.

iBGP und OSPF nebeneinander

Sobald zwei Edge-Router jeweils eine eBGP-Session zu einem Provider haben, müssen sie voneinander wissen, welche Präfixe der andere gelernt hat. Dafür sprechen sie iBGP miteinander. Die iBGP-Session wird zwischen Loopback-Adressen aufgebaut, damit sie nicht an einem einzelnen physischen Link hängt, und OSPF sorgt dafür, dass diese Loopbacks erreichbar sind.

Zwei Regeln von iBGP überraschen beim ersten Aufbau. Erstens gibt ein Router Routen, die er per iBGP gelernt hat, nicht an andere iBGP-Nachbarn weiter. Deshalb brauchen alle iBGP-Router eine Vollvermaschung oder einen Route Reflector nach RFC 4456. Zweitens behält iBGP den Next Hop der eBGP-Route bei, also die Adresse im Transfernetz des Providers. Kennt der andere Edge-Router dieses Transfernetz nicht, ist die Route unbrauchbar. Der übliche Ausweg ist next-hop-self auf der iBGP-Session.

Das folgende Beispiel zeigt die Arbeitsteilung auf einem der beiden Edge-Router: OSPF für Loopbacks und interne Netze, eBGP zum Provider mit Filtern in beide Richtungen, iBGP zum zweiten Edge-Router.

interface Loopback0
 ip address 10.255.0.1 255.255.255.255
!
interface GigabitEthernet0/0/0
 description Uplink Provider-A
 ip address 203.0.113.2 255.255.255.252
 bfd interval 300 min_rx 300 multiplier 3
!
router ospf 1
 router-id 10.255.0.1
 auto-cost reference-bandwidth 100000
 passive-interface default
 no passive-interface GigabitEthernet0/0/1
 network 10.255.0.1 0.0.0.0 area 0
 network 10.0.0.0 0.0.255.255 area 0
 default-information originate
!
ip prefix-list PL-OUT seq 10 permit 198.51.100.0/24
ip prefix-list PL-IN seq 10 permit 0.0.0.0/0
!
router bgp 64511
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 neighbor 203.0.113.1 remote-as 64496
 neighbor 203.0.113.1 description Provider-A
 neighbor 203.0.113.1 fall-over bfd
 neighbor 10.255.0.2 remote-as 64511
 neighbor 10.255.0.2 update-source Loopback0
 !
 address-family ipv4
  network 198.51.100.0 mask 255.255.255.0
  neighbor 203.0.113.1 activate
  neighbor 203.0.113.1 prefix-list PL-IN in
  neighbor 203.0.113.1 prefix-list PL-OUT out
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.2 next-hop-self
 exit-address-family
!
ip route 198.51.100.0 255.255.255.0 Null0

Redistribution und ihre Risiken

Redistribution heißt, Routen aus einer Quelle in ein anderes Protokoll zu übernehmen. Zwischen BGP und OSPF ist das möglich, aber an kaum einer Stelle richtig. Drei Gründe sprechen dagegen, BGP-Routen pauschal in OSPF zu verteilen.

• Größe: Eine volle oder auch nur teilweise Internettabelle als externe LSAs flutet jede Area, belastet jeden Router mit SPF-Berechnungen und sprengt kleine Access-Router.

• Schleifen bei gegenseitiger Redistribution an zwei Punkten: Eine Route wandert von BGP in OSPF, am zweiten Edge-Router von OSPF zurück in BGP, und kommt mit besserer Bewertung wieder an. Abhilfe sind Tags, die jede umverteilte Route markieren, und Route-Maps, die markierte Routen an der Gegenstelle verwerfen.

• Administrative Distanz: Cisco bewertet eBGP mit 20, OSPF mit 110 und iBGP mit 200. Ein Präfix, das per OSPF und per iBGP ankommt, wird über OSPF genommen, auch wenn BGP den gewollten Weg kennt. Wer das nicht im Kopf hat, sucht stundenlang nach dem Grund für einen falschen Pfad.

Was stattdessen funktioniert

In den meisten Unternehmensnetzen reicht es, wenn die Edge-Router per default-information originate eine Default Route ins OSPF geben, und zwar nur, solange sie selbst eine Default Route vom Provider haben. Fällt der Provider aus, verschwindet die Default Route aus BGP, der Edge-Router zieht seine Ankündigung ins OSPF zurück, und der Verkehr wandert zum zweiten Edge-Router.

In Gegenrichtung kündigst du per network-Anweisung nur die eigenen Präfixe an. Der network-Befehl unter router bgp verlangt bei Cisco, dass genau dieses Präfix mit dieser Maske in der Routingtabelle steht. Eine statische Route auf Null0 für das Aggregat erfüllt das zuverlässig, auch wenn einzelne interne Subnetze gerade fehlen.

Muss doch umverteilt werden, etwa weil ein Cloud-Gateway Präfixe per BGP liefert, die im Campus bekannt sein sollen, dann mit einer Route-Map, die nur ausdrücklich erlaubte Präfixe durchlässt und sie mit einem Tag versieht. Cisco verteilt per iBGP gelernte Routen ohnehin nur mit dem Zusatz bgp redistribute-internal in ein IGP, was ein bewusst eingebauter Schutz ist.

ip prefix-list PL-AZURE seq 10 permit 10.50.0.0/16 le 24
!
route-map RM-BGP-TO-OSPF permit 10
 match ip address prefix-list PL-AZURE
 set tag 65515
 set metric-type type-1
!
router ospf 1
 redistribute bgp 64511 route-map RM-BGP-TO-OSPF

Entscheidungsbaum für dein Netz

Die Fragen sind so geordnet, dass jede Antwort den Fall weiter eingrenzt. Bei der ersten Antwort, die BGP verlangt, ist die Grenze gefunden, an der eBGP gesprochen wird. Alles dahinter bleibt OSPF.