De BGP-sessie komt niet op of gaat steeds weg

Je hebt een BGP-peering ingericht met je provider, met een tweede locatie of tussen twee routers in je eigen netwerk. De sessie komt niet op established, of hij komt op en valt na een minuut weer weg, of hij staat er wel en er komt geen enkele route binnen.

Wat het niet is: dit is in de meeste gevallen geen BGP-probleem. BGP praat over een gewone TCP-verbinding op poort 179. Komt die verbinding niet tot stand, dan is er nog niets van BGP in het spel en zoek je in de verkeerde hoek. Pak dus eerst de onderste laag.

Drie beelden, drie oorzaken. Een sessie die nooit opkomt is bereikbaarheid, firewall of authenticatie. Een sessie die op en neer gaat is een timer die verloopt. Een sessie die staat en niets levert is een filter.

De snelle controles, op volgorde

1. Wat is de toestand? /routing bgp session print. Goed antwoord: een sessie met established: yes en een uptime die oploopt. Een uptime die steeds opnieuw bij nul begint, is een flap.
2. Wat zegt het logboek? /log print where topics~"bgp". Dit is de kortste weg naar het antwoord. BGP stuurt bij een weigering een notificatie mee met de reden erin, en die staat hier.
3. Is de peer bereikbaar? /ping peer, en als je een lokaal adres gebruikt /ping peer src-address=jouw adres. Goed antwoord: antwoord, vanaf het adres dat je ook voor BGP gebruikt.
4. Komt poort 179 door? /ip firewall filter print stats en kijk naar de input-chain. Goed antwoord: er is een regel die TCP 179 van deze peer accepteert, en de afsluitende drop telt niet op terwijl je het probeert.
5. Wat komt er binnen en wat gaat eruit? /ip route print where bgp voor wat je ontvangt, en /routing bgp advertisements print voor wat je stuurt. Goed antwoord: precies de prefixen die je verwachtte, en niet meer.

De gewone oorzaken, meest voorkomend eerst

De firewall laat poort 179 niet binnen

De standaard input-chain accepteert verkeer vanaf de LAN-lijst en gooit de rest weg. Een peering met je provider komt vanaf WAN en valt daar dus buiten. Voeg een regel toe die TCP 179 accepteert van het adres van die ene peer, niet van alles.

Het AS-nummer klopt niet

Bij eBGP wordt het AS-nummer in de OPEN gecontroleerd. Staat er aan jouw kant een ander nummer dan de peer verwacht, dan volgt een notificatie en gaat de sessie meteen weer dicht. Controleer beide kanten letterlijk, ook het eigen AS.

Het bronadres is niet wat de peer verwacht

Peer je op loopback-adressen, dan moet jouw sessie ook vanaf dat loopback vertrekken. Laat je het lokale adres leeg, dan kiest de router het adres van de uitgaande interface en herkent de peer dat niet.

Multihop staat uit terwijl er meer dan één hop tussen zit

Een eBGP-sessie vertrekt standaard met een TTL van 1, dus hij overleeft precies één router. Peer je op loopbacks, dan heb je multihop nodig aan beide kanten.

De MD5-sleutel verschilt

Een TCP MD5-wachtwoord dat aan één kant staat of aan beide kanten anders is, laat de TCP-verbinding zelf mislukken. Je krijgt dan geen nette BGP-melding maar een verbinding die niet tot stand komt, wat de zoektocht een stuk langer maakt. Controleer de sleutel teken voor teken.

De sessie flapt: een timer loopt af

BGP verwacht regelmatig een keepalive. Verdwijnen die door pakketverlies, een volle CPU of een MTU-vernauwing onderweg, dan loopt de hold-timer af en begint alles opnieuw. Grote UPDATE-pakketten die door een te kleine MTU verdwijnen geven precies dit beeld; test met /ping peer size=1400 do-not-fragment.

De sessie staat, maar er gaat niets uit

Dat is een filter, en het is de meest voorkomende verrassing in een verse opzet. Zie hieronder wat de tool hier doet.

Wat de configurator hiervan doet

• BGP staat in het onderdeel Routing, standaard uit. Je vult je eigen AS in, een router-ID of een loopback, een lijst netwerken die je wilt adverteren, en per peer een naam, adres, remote AS, lokaal adres, TCP MD5-wachtwoord, multihop en de keuze om alleen een default route te accepteren.
• Het script zet één template default met jouw AS en router-ID, en daaronder een /routing bgp connection per peer. De rol wordt afgeleid: is het remote AS gelijk aan het jouwe, dan wordt het iBGP, anders eBGP. Dat is dus geen veld dat je zelf kiest.
• De netwerken die je opgeeft komen in een adreslijst bgp-networks en die lijst wordt de output.network van het template.
• Er worden twee filterketens geschreven. bgp-in-default-only accepteert alleen 0.0.0.0/0 en hangt aan een peer als je "alleen default accepteren" aanvinkt. bgp-out-networks accepteert alleen je eigen netwerken en hangt altijd aan elke peer.
• Daar zit de val: laat je het veld met te adverteren netwerken leeg, dan bestaat bgp-out-networks uit één regel, en die regel is reject. De sessie komt keurig op en je adverteert niets. Er komt geen waarschuwing over. Vul dus altijd je netwerken in, ook als je denkt dat het vanzelf gaat.
• De tool waarschuwt wel als een peer geen TCP MD5-wachtwoord heeft.
• De verbindingen krijgen address-families=ip. IPv6-prefixen worden dus niet uitgewisseld.
• In een site met meerdere apparaten kun je BGP aanzetten op een gerouteerde tunnel. De tool vult dan aan beide kanten de peering in op de tunneladressen, zet de statische routes over die tunnel uit omdat BGP ze nu levert, en geeft een fout als een van de twee routers geen AS-nummer heeft.
• Wat de tool niet doet: hij opent geen poort 179 in de firewall. Peer je over WAN, dan zet je die regel er zelf bij in het onderdeel Firewall, bij Diensten op de router zelf bereikbaar vanaf internet, met het adres van de peer in het veld "alleen vanaf".

Als het niet aan je router ligt

• De peer. Bij een provider ligt de fout net zo vaak aan de andere kant. Vraag om de sessiestatus van hun kant voordat je verder zoekt.

Verder lezen: BGP, Tunnels tussen locaties en Firewall & NAT.