Por que a súa sesión BGP non aparece na táboa de rutas da VPC
Unha sesión BGP nun aparello EC2 non instala rutas da VPC. A propagación actívase por táboa de rutas, e o aparello segue reenviando cada paquete.
A historia que se repite é que un demo de encamiñamento nun aparello VPN de EC2 ensinará á VPC os seus prefixos remotos en canto BGP suba. A metade é certa. A sesión sobe, e nada cambia na táboa de rutas da VPC por iso, polo que o primeiro síntoma adoita ser unha subrede que manda o tráfico en silencio a un burato negro.
Aquí confúndense dúas cousas distintas: o emparellamento cun servidor de rutas e a instalación de rutas nunha táboa.
O mito: sube BGP e a VPC aprenderá os prefixos
BGP é unha conversa entre dous interlocutores, e neste deseño os interlocutores son o demo de encamiñamento do seu aparello e un punto de conexión de VPC Route Server que AWS coloca nunha subrede que vostede posúe. Esa conversa transporta prefixos. Non toca a táboa de rutas das súas subredes de carga, porque esas táboas só aprenden mediante a propagación que hai que activar en cada unha. Ata que iso ocorra, o tecido da VPC non sabe nada do que sabe o aparello.
Os pasos de configuración están separados por unha razón: asociar, crear o punto de conexión, emparellar e despois activar a propagación.
Route Server é un plano de control, non un túnel
Route Server non cifra, non reenvía nin inspecciona un só paquete. Existe para intercambiar BGP co aparello e entregar os prefixos resultantes ás táboas de rutas configuradas para recibilos. O plano de datos non cambia: os paquetes seguen saíndo pola interface de rede do aparello, viaxan polo seu VPN e volven polo mesmo camiño.
Iso significa que a comprobación de orixe e destino na instancia de reenvío segue importando, porque a instancia agora reenvía tráfico dirixido a outra persoa.
Os grupos de seguridade e os controis de subrede tamén se aplican ao fluxo reenviado. Route Server non fará que un aparello que descarta tráfico o reenvíe, nin reparará unha ruta de retorno que falte no lado remoto.
A propagación é por táboa de rutas, non por VPC
Asociar o servidor de rutas coa VPC e activar a propagación nunha táboa de rutas son dúas decisións, e só a segunda cambia o que fai unha subrede. Unha VPC con seis táboas de rutas pode recibir un prefixo propagado nunha e non nas outras cinco, o que é exactamente correcto para unha subrede concentradora e exactamente o que produce o desconcertante resultado de «funciona a medias». Mesmo onde a propagación está activa, unha ruta competidora pode gañar, porque a selección de rutas da VPC prefire o prefixo máis longo e, a igual lonxitude, prefire unha ruta estática a unha propagada. Esa preferencia aplícase en silencio.
Comprobe a táboa efectiva da subrede concreta en lugar da lista de prefixos que anuncia o aparello. A API responde esa pregunta directamente: aws ec2 associate-route-server e aws ec2 enable-route-server-propagation --route-table-id <id> son os dous pasos que a xente esquece, e aws ec2 describe-route-tables --route-table-ids <id> mostra se o prefixo chegou como entrada de route server.
O aparello segue levando cada paquete
Anunciar alcanzabilidade non é o mesmo que tela. Unha sesión BGP pode permanecer establecida mentres o VPN do aparello está caído, e un anuncio estático que nunca cambia segue atraendo o tráfico cara a un camiño morto. Route Server admite detección de fallos como BFD, pero iso proba a vitalidade do par, non a saúde de todo o que hai detrás.
Ate o anuncio á ruta remota real: anuncie o prefixo cando o túnel e a rede remota estean activos, e retíreo cando non o estean.
Retire un prefixo e observe que pasa
Probe por etapas, e faga da última etapa unha retirada. Confirme que o anuncio chega, que o prefixo aparece en cada táboa prevista, que o aparello é o seguinte salto, que o reenvío cruza o túnel activo e que o extremo remoto responde. Despois retire un prefixo de proba, ou peche un túnel aprobado, e observe se o tráfico se move onde o deseño di que debería. Anote as táboas de antes e despois mentres a proba segue aberta.
Mover unha ruta a un segundo aparello non move as sesións que levaba, porque o estado de NAT e da devasa queda no primeiro equipo.
Para un conxunto fixo dunha ducia de prefixos, as rutas estáticas nas táboas da VPC seguen sendo a resposta máis barata. Route Server gaña o seu sitio cando a lista de prefixos cambia de verdade e a política de retirada é algo que pode explicar á persoa de garda.