Waarom je BGP-sessie niet in de VPC-routetabel verschijnt

Het verhaal dat steeds wordt herhaald, is dat een routing-daemon op een EC2 VPN-appliance de VPC de externe prefixen leert zodra BGP omhoog komt. De helft daarvan is waar. De sessie komt omhoog, en niets in de routetabel van de VPC verandert daardoor, waardoor het eerste symptoom meestal een subnet is dat verkeer stilletjes in een zwart gat laat verdwijnen.

Hier worden twee verschillende dingen verward: peering met een route server, en het installeren van routes in een tabel.

De mythe: breng BGP omhoog en de VPC leert de prefixen

BGP is een gesprek tussen twee sprekers, en in dit ontwerp zijn de sprekers de routing-daemon op je appliance en een VPC Route Server-eindpunt dat AWS in een subnet plaatst dat van jou is. Dat gesprek draagt prefixen. Het raakt de routetabel van je workload-subnetten niet, omdat die tabellen alleen leren via propagatie die op elk ervan moet worden aangezet. Tot dat gebeurt, weet de VPC-fabric niets van wat de appliance weet.

De configuratiestappen zijn om een reden gescheiden: koppelen, het eindpunt aanmaken, peeren en dan propagatie aanzetten.

Route Server is een controlevlak, geen tunnel

Route Server versleutelt, stuurt of inspecteert geen enkel pakket. Het bestaat om BGP met de appliance uit te wisselen en de resulterende prefixen aan de routetabellen te geven die zijn geconfigureerd om ze te ontvangen. Het datavlak is ongewijzigd: pakketten verlaten nog steeds via de netwerkinterface van de appliance, reizen door zijn VPN en komen langs dezelfde weg terug.

Dat betekent dat de bron- en bestemmingscontrole op de doorstuurinstantie nog steeds belangrijk is, omdat de instantie nu verkeer doorstuurt dat aan iemand anders is gericht.

Beveiligingsgroepen en subnetcontroles gelden ook voor de doorgestuurde stroom. Route Server dwingt een appliance die verkeer laat vallen niet om het door te sturen, en het repareert geen ontbrekende terugroute aan de externe kant.

Propagatie is per routetabel, niet per VPC

De route server aan de VPC koppelen en propagatie op een routetabel aanzetten zijn twee beslissingen, en alleen de tweede verandert wat een subnet doet. Een VPC met zes routetabellen kan een gepropageerd prefix in één ontvangen en niet in de andere vijf, wat precies goed is voor een hub-subnet en precies datgene wat het verwarrende «werkt half»-resultaat oplevert. Zelfs waar propagatie aan staat, kan een concurrerende route winnen, omdat de routekeuze van de VPC het langste prefix verkiest en bij gelijke lengte een statische route boven een gepropageerde. Die voorkeur wordt stil toegepast.

Controleer de effectieve tabel voor het specifieke subnet in plaats van de lijst prefixen die de appliance adverteert. De API beantwoordt die vraag rechtstreeks: aws ec2 associate-route-server en aws ec2 enable-route-server-propagation --route-table-id <id> zijn de twee stappen die mensen vergeten, en aws ec2 describe-route-tables --route-table-ids <id> laat zien of het prefix überhaupt als route-server-item is aangekomen.

De appliance draagt nog steeds elk pakket

Bereikbaarheid adverteren is niet hetzelfde als het hebben. Een BGP-sessie kan gevestigd blijven terwijl de VPN van de appliance plat ligt, en een statische aankondiging die nooit verandert blijft verkeer naar een dood pad trekken. Route Server ondersteunt foutdetectie zoals BFD, maar dat test de levensvatbaarheid van de peer, niet de gezondheid van alles erachter.

Koppel de aankondiging aan de echte externe route: kondig het prefix aan wanneer de tunnel en het externe netwerk omhoog zijn, en trek het in wanneer ze dat niet zijn.

Trek een prefix in en kijk wat er gebeurt

Test in fasen, en maak de laatste fase een verwijdering. Bevestig dat de aankondiging aankomt, het prefix in elke bedoelde tabel verschijnt, de appliance de volgende hop is, het doorsturen door de actieve tunnel gaat en de externe kant antwoordt. Trek dan een testprefix in, of sluit een goedgekeurde tunnel, en kijk of verkeer beweegt naar waar het ontwerp zegt. Noteer de tabellen voor en na terwijl de test nog open is.

Een route naar een tweede appliance verplaatsen verplaatst de sessies die hij droeg niet, omdat NAT- en firewallstatus bij het eerste apparaat blijven.

Voor een vaste set van een dozijn prefixen blijven statische routes in de VPC-tabellen het goedkopere antwoord. Route Server verdient zijn plek wanneer de prefixlijst echt verandert en het intrekkingsbeleid iets is dat je kunt uitleggen aan de persoon die dienst heeft.