Waarom jou BGP-sessie nie in die VPC-roetertabel verskyn nie

Die verhaal wat herhaal word, is dat ’n roeteringsdaemon op ’n EC2 VPN-toestel die VPC sy afgeleë prefikse sal leer sodra BGP opkom. Die helfte daarvan is waar. Die sessie kom op, en niks in die VPC-roetertabel verander daarvoor nie, en daarom is die eerste simptoom gewoonlik ’n subnet wat stilweg verkeer in ’n swartgat laat verdwyn.

Twee verskillende dinge word hier verwar: peering met ’n roeteserver, en die installering van roetes in ’n tabel.

Die mite: bring BGP op en die VPC leer die prefikse

BGP is ’n gesprek tussen twee sprekers, en in hierdie ontwerp is die sprekers die roeteringsdaemon op jou toestel en ’n VPC Route Server-eindpunt wat AWS in ’n subnet plaas wat jy besit. Daardie gesprek dra prefikse. Dit raak nie die roetertabel van jou werkvrag-subnette nie, want daardie tabelle leer net deur propagasie wat op elkeen geaktiveer moet word. Tot dit gebeur, weet die VPC-weefsel niks van wat die toestel weet nie.

Die opstellingsstappe is om ’n rede apart: assosieer, skep die eindpunt, peer, aktiveer dan propagasie.

Route Server is ’n beheervlak, nie ’n tonnel nie

Route Server verskans, stuur of ondersoek nie ’n enkele pakkie nie. Dit bestaan om BGP met die toestel uit te ruil en die resulterende prefikse aan die roetertabelle te gee wat gekonfigureer is om hulle te ontvang. Die datavlak is onveranderd: pakkies verlaat steeds deur die toestel se netwerkkoppelvlak, reis sy VPN en kom dieselfde pad terug.

Dit beteken die bron- en bestemmingskontrole op die deurstuurinstansie maak steeds saak, want die instansie stuur nou verkeer deur wat aan iemand anders geadresseer is.

Sekuriteitsgroepe en subnetbeheermaatreëls geld ook steeds vir die deurgestuurde vloei. Route Server sal nie ’n toestel wat verkeer laat val, dwing om dit deur te stuur nie, en dit sal nie ’n ontbrekende terugroete aan die afgeleë kant herstel nie.

Propagasie is per roetertabel, nie per VPC nie

Om die roeteserver met die VPC te assosieer en om propagasie op ’n roetertabel te aktiveer, is twee besluite, en net die tweede verander wat ’n subnet doen. ’n VPC met ses roetertabelle kan ’n gepropageerde prefiks in een ontvang en nie in die ander vyf nie, wat presies reg is vir ’n hub-subnet en presies die verwarrende halfwerk-resultaat lewer. Selfs waar propagasie aan is, kan ’n mededingende roete wen, want VPC-roeteseleksie verkies die langste prefiks en, by gelyke lengte, verkies ’n statiese roete bo ’n gepropageerde een. Daardie voorkeur word stilweg toegepas.

Kontroleer die effektiewe tabel vir die spesifieke subnet eerder as die lys prefikse wat die toestel adverteer. Die API beantwoord daardie vraag direk: aws ec2 associate-route-server en aws ec2 enable-route-server-propagation --route-table-id <id> is die twee stappe wat mense vergeet, en aws ec2 describe-route-tables --route-table-ids <id> wys of die prefiks hoegenaamd as ’n route-server-inskrywing aangekom het.

Die toestel dra steeds elke pakkie

Om bereikbaarheid te adverteer is nie dieselfde as om dit te hê nie. ’n BGP-sessie kan gevestig bly terwyl die toestel se VPN af is, en ’n statiese advertensie wat nooit verander nie, bly verkeer na ’n dooie pad trek. Route Server ondersteun foutopsporing soos BFD, maar dit toets die lewendigheid van die peer, nie die gesondheid van alles agter die peer nie.

Bind die advertensie aan die werklike afgeleë roete: kondig die prefiks aan wanneer die tonnel en die afgeleë netwerk op is, en trek dit terug wanneer hulle nie is nie.

Trek ’n prefiks terug en kyk wat gebeur

Toets in fases, en maak die laaste fase ’n verwydering. Bevestig dat die advertensie aankom, die prefiks in elke beoogde tabel verskyn, die toestel die volgende sprong is, deursturing deur die aktiewe tonnel gaan en die afgeleë kant antwoord. Trek dan ’n toets-prefiks terug, of sluit ’n goedgekeurde tonnel, en kyk of verkeer beweeg waar die ontwerp sê dit moet. Teken die voor- en na-tabelle aan terwyl die toets nog oop is.

Om ’n roete na ’n tweede toestel te skuif, skuif nie die sessies wat dit gedra het nie, want NAT- en firewall-toestand bly by die eerste toestel.

Vir ’n vaste stel van ’n dosyn prefikse bly statiese roetes in die VPC-tabelle die goedkoper antwoord. Route Server verdien sy plek wanneer die prefikslys werklik verander en die onttrekkingsbeleid iets is wat jy aan die persoon op diens kan verduidelik.