Varför din BGP-session inte dyker upp i VPC:ns rutttabell

Historien som upprepas är att en routing-demon på en EC2 VPN-appliance kommer att lära VPC:n dess fjärrprefix så snart BGP kommer upp. Hälften av det är sant. Sessionen kommer upp, och ingenting i VPC:ns rutttabell ändras på grund av det, vilket är varför det första symtomet oftast är ett subnät som tyst skickar trafiken i ett svart hål.

Här blandas två olika saker ihop: peering med en route server, och installation av rutter i en tabell.

Myten: få upp BGP och VPC:n lär sig prefixen

BGP är ett samtal mellan två talare, och i den här designen är talarna routing-demonen på din appliance och en VPC Route Server-slutpunkt som AWS placerar i ett subnät du äger. Det samtalet bär prefix. Det rör inte rutttabellen för dina arbetsbelastningssubnät, eftersom de tabellerna bara lär sig genom propagering som måste aktiveras på var och en. Tills det händer vet inte VPC:ns fabric något om vad appliancen vet.

Konfigurationsstegen är åtskilda av en anledning: associera, skapa slutpunkten, peer, och aktivera sedan propagering.

Route Server är ett kontrollplan, inte en tunnel

Route Server krypterar, vidarebefordrar eller inspekterar inte ett enda paket. Den finns för att utbyta BGP med appliancen och lämna de resulterande prefixen till de rutttabeller som är konfigurerade att ta emot dem. Dataplanet är oförändrat: paketen lämnar fortfarande genom appliancens nätverksgränssnitt, färdas genom dess VPN och kommer tillbaka samma väg.

Det betyder att käll- och destinationskontrollen på vidarebefordringsinstansen fortfarande spelar roll, eftersom instansen nu vidarebefordrar trafik adresserad till någon annan.

Säkerhetsgrupper och subnätskontroller gäller även för det vidarebefordrade flödet. Route Server får inte en appliance som släpper trafik att vidarebefordra den, och den reparerar inte en saknad returrutt på fjärrsidan.

Propagering är per rutttabell, inte per VPC

Att associera route servern med VPC:n och att aktivera propagering på en rutttabell är två beslut, och bara det andra ändrar vad ett subnät gör. En VPC med sex rutttabeller kan ta emot ett propagerat prefix i en och inte i de andra fem, vilket är precis rätt för ett hub-subnät och precis det som ger det förvirrande «fungerar halvt»-resultatet. Även där propagering är på kan en konkurrerande rutt vinna, eftersom VPC:ns ruttval föredrar det längsta prefixet och, vid lika längd, föredrar en statisk rutt framför en propagerad. Den preferensen tillämpas tyst.

Kontrollera den effektiva tabellen för det specifika subnätet i stället för listan över prefix som appliancen annonserar. API:et svarar direkt på den frågan: aws ec2 associate-route-server och aws ec2 enable-route-server-propagation --route-table-id <id> är de två stegen folk glömmer, och aws ec2 describe-route-tables --route-table-ids <id> visar om prefixet överhuvudtaget anlände som en route server-post.

Appliancen bär fortfarande varje paket

Att annonsera nåbarhet är inte samma sak som att ha den. En BGP-session kan förbli etablerad medan appliancens VPN ligger nere, och en statisk annons som aldrig ändras fortsätter att dra trafik mot en död väg. Route Server stöder felavkänning som BFD, men det testar peerens livskraft, inte hälsan hos allt bakom den.

Bind annonsen till den riktiga fjärrrutten: annonsera prefixet när tunneln och fjärrnätverket är uppe, och dra tillbaka det när de inte är det.

Dra tillbaka ett prefix och se vad som händer

Testa i faser, och gör den sista fasen till en borttagning. Bekräfta att annonsen anländer, att prefixet dyker upp i varje avsedd tabell, att appliancen är nästa hopp, att vidarebefordran korsar den aktiva tunneln och att fjärränden svarar. Dra sedan tillbaka ett testprefix, eller stäng en godkänd tunnel, och observera om trafiken flyttar dit designen säger. Anteckna tabellerna före och efter medan testet fortfarande är öppet.

Att flytta en rutt till en andra appliance flyttar inte sessionerna den bar, eftersom NAT- och brandväggstillstånd stannar på den första enheten.

För en fast uppsättning på ett dussin prefix är statiska rutter i VPC-tabellerna fortfarande det billigare svaret. Route Server förtjänar sin plats när prefixlistan verkligen ändras och återdragningspolicyn är något du kan förklara för personen på jour.