Wat is het verschil tussen Active en Connect?

In Connect zet de router zelf een TCP-verbinding op. Mislukt dat, dan gaat hij naar Active: luisteren of de andere kant verbindt, tot de retry-timer hem weer naar Connect stuurt. Flappen tussen die twee betekent dus vrijwel altijd: TCP komt niet tot stand. Kijk dan naar firewalls, ACL's, MD5 en het neighbor-IP aan beide kanten, niet naar BGP-attributen.

Mijn sessie is Established maar ik ontvang geen routes. Hoe kan dat?

Dan doet BGP zijn werk en ligt het aan beleid: een filter dat alles afkeurt, RPKI-invalid prefixes die je dropt, of de andere kant kondigt simpelweg niets aan. Kijk eerst wat je vóór filtering ontvangt. Zo zie je of het probleem bij jou zit of bij je peer.

Kan RPKI de oorzaak zijn?

Ja. Klopt je ROA niet, bijvoorbeeld een verkeerd origin-AS of een max-length die te kort is voor je more-specifics, dan is je prefix invalid en gooien peers die RPKI doen hem weg. Dekt geen enkele ROA je prefix, dan is hij not found en wordt hij gewoon geaccepteerd. Maar heeft een grotere prefix waar de jouwe in valt wel een ROA, dan is jouw prefix zonder eigen ROA invalid. Het gaat vaak mis na het opsplitsen of verhuizen van adresruimte. Controleer je ROA's en IRR-objecten.

Kun je hier op korte termijn naar kijken?

Ja. Met read-only toegang en de laatste notificatie erbij kan ik gericht zoeken.

// BGP komt niet op

BGP-sessie komt niet op (Active, Connect of Idle)

Een BGP-sessie die niet opkomt, vertelt je in welke state hij hangt precies hoe ver hij komt. Met die state erbij is de lijst mogelijke oorzaken ineens kort.

Loop je hier nu tegenaan?

Bel of mail en leg het voor. Neem ik niet op, stuur dan even een mail.

Bellen053 744 0920 E-mailinfo@bouwhuisit.nl AgendaPlan een gesprek

Herken je dit?

De sessie blijft in Active of Connect staan en flapt tussen die twee.
De sessie staat op Idle en probeert het niet eens.
De sessie komt op en valt na een paar seconden weer weg.
De sessie is Established maar er komen geen prefixes binnen.
Het werkte tot er iets wijzigde aan de firewall, het IP of de config.

Waar het meestal aan ligt

In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.

[TCP]

Active of Connect: TCP poort 179 komt niet tot stand

De sessie probeert te verbinden en krijgt niets terug. Meestal een firewall of ACL die poort 179 blokkeert, een verkeerd neighbor-IP of bronadres, een MD5-mismatch, of de andere kant is nog niet geconfigureerd.

[IDLE]

Idle: lokaal iets niet in orde

Vaak een administratieve shutdown, een ontbrekende route naar de peer, een eBGP-peer die niet direct aangesloten is, of een max-prefix-limiet die de sessie heeft neergehaald. Idle (Admin) betekent letterlijk dat hij niet mag.

[ASN]

Verkeerd AS-nummer of een OPEN die wordt geweigerd

Een mismatch in het remote AS geeft een Bad Peer AS in de notificatie. Capabilities worden onderhandeld, dus een verschil daarin breekt de OPEN meestal niet. Heb je geen address family gemeen, dan krijg je wel een sessie die Established is en niks vervoert.

[TTL]

Multihop en TTL

Bij een eBGP-peer die niet direct aangesloten zit, bijvoorbeeld tussen loopbacks, moet ebgp-multihop of multihop aan staan. Zonder dat gaat het pakket met TTL 1 de deur uit (of verstuurt Cisco het niet eens). iBGP doet standaard al multihop.

[MD5]

Wachtwoord of MD5-mismatch

Eén kant met authenticatie en de andere zonder geeft een TCP-sessie die niet tot stand komt zonder duidelijke BGP-melding. In de systeemlogs zie je dan wel MD5-fouten.

[FILT]

Established maar geen prefixes

De sessie werkt; de filters niet. Een import- of export-filter, een ontbrekende as-path-match, of een prefixlijst die de nieuwe ranges niet kent.

Wat ik als eerste check

Doe deze stappen zelf, of bel en dan lopen we ze samen door.

1
Lees de state en de laatste foutmelding
Met show bgp summary zie je de state. De laatste notificatie staat in show bgp neighbors <ip> (of birdc show protocols all). Die melding is je diagnose; zonder die melding zoek je in het donker.
2
Test of TCP 179 open is
Vanaf de router, met het juiste bronadres: telnet <peer-ip> 179 /source-interface lo0 op Cisco, nc -s <bron-ip> -vz <peer-ip> 179 op Linux. Een refused of reset betekent vaak dat de andere kant jouw bron-IP niet als neighbor kent. Een timeout wijst naar een firewall, of naar MD5.
3
Controleer of je de peer überhaupt kunt bereiken
Ping het neighbor-IP vanaf het bronadres dat je in update-source hebt staan (ping -I op Linux, ping <ip> source <ip> op Cisco en Junos). Bij een loopback-peering moet het pad naar die loopback aan beide kanten bekend zijn.
4
Vergelijk de AS-nummers en IP's letter voor letter
Het klinkt simpel, maar een omgedraaide cijferreeks of het IP van de vorige peer is een veelvoorkomende oorzaak. Leg jouw configuratie naast wat de andere partij denkt te hebben afgesproken.
5
Controleer authenticatie en multihop
Aan beide kanten dezelfde keuze: wel of geen wachtwoord, wel of geen multihop. Een halve afspraak geeft een sessie die zwijgend blijft hangen.
6
Established, maar leeg? Kijk naar de filters
Met show bgp neighbor <ip> received-routes zie je of je iets binnenkrijgt vóór filtering. Op Cisco en FRR moet daarvoor soft-reconfiguration inbound aan staan, op Junos is het show route receive-protocol bgp <ip> hidden. Komt er wel wat binnen maar staat het niet in de tabel, dan is je import-filter de dader.

De state doet het denkwerk

Bij BGP hoef je niet te gokken. De toestandsmachine is klein en elke state sluit een hoop oorzaken uit. Blijf je in Active of Connect hangen, dan komt TCP niet tot stand: poort 179, een ACL, een verkeerd adres, MD5, of een peer die jou niet kent. Kom je tot Established zonder routes, dan is het beleid: filters, limieten, RPKI. Idle wijst naar iets lokaals.

Wat het lastig maakt, is dat de nuttige informatie in de notificatie zit. En die staat niet in de summary, die moet je per neighbor opzoeken.

Even iemand die meekijkt?

Stuur me de output van je show bgp summary en de laatste notificatie, dan zeg ik je waar het spaak loopt. Als het aan de andere kant ligt, krijg je de onderbouwing waarmee je dat bij je upstream of IX kunt aankaarten.

Veelgestelde vragen

Wat is het verschil tussen Active en Connect?: In Connect zet de router zelf een TCP-verbinding op. Mislukt dat, dan gaat hij naar Active: luisteren of de andere kant verbindt, tot de retry-timer hem weer naar Connect stuurt. Flappen tussen die twee betekent dus vrijwel altijd: TCP komt niet tot stand. Kijk dan naar firewalls, ACL's, MD5 en het neighbor-IP aan beide kanten, niet naar BGP-attributen.
Mijn sessie is Established maar ik ontvang geen routes. Hoe kan dat?: Dan doet BGP zijn werk en ligt het aan beleid: een filter dat alles afkeurt, RPKI-invalid prefixes die je dropt, of de andere kant kondigt simpelweg niets aan. Kijk eerst wat je vóór filtering ontvangt. Zo zie je of het probleem bij jou zit of bij je peer.
Kan RPKI de oorzaak zijn?: Ja. Klopt je ROA niet, bijvoorbeeld een verkeerd origin-AS of een max-length die te kort is voor je more-specifics, dan is je prefix invalid en gooien peers die RPKI doen hem weg. Dekt geen enkele ROA je prefix, dan is hij not found en wordt hij gewoon geaccepteerd. Maar heeft een grotere prefix waar de jouwe in valt wel een ROA, dan is jouw prefix zonder eigen ROA invalid. Het gaat vaak mis na het opsplitsen of verhuizen van adresruimte. Controleer je ROA's en IRR-objecten.
Kun je hier op korte termijn naar kijken?: Ja. Met read-only toegang en de laatste notificatie erbij kan ik gericht zoeken.

Verwante problemen

[BGP & peering]

BGP-specialist voor peering, ASN en RPKI

BGP van aanvraag tot productie: eigen AS-nummer, IP-ruimte, peering bij AMS-IX en NL-ix, filters, RPKI en ROA's. Van een operator met een eigen netwerk.

[MikroTik]

MikroTik specialist inhuren

Hulp met MikroTik en RouterOS: firewall, BGP, VPN's, VLANs en de eigenaardigheden van fasttrack, CRS-switching en upgrades naar RouterOS 7.

Wil je dit bespreken?

Bel of mail met je vraag. Neem ik niet op, stuur dan even een mail.