De ce sesiunea BGP nu apare în tabela de rutare a VPC-ului

Povestea care se repetă este că un demon de rutare de pe un aparat VPN EC2 va învăța VPC-ul prefixele sale la distanță imediat ce BGP urcă. Jumătate din asta este adevărat. Sesiunea urcă și nimic din tabela de rutare a VPC-ului nu se schimbă din cauza ei, de aceea primul simptom este de obicei o subrețea care aruncă în liniște traficul într-o gaură neagră.

Aici se confundă două lucruri diferite: peeringul cu un server de rutare și instalarea rutelor într-o tabelă.

Mitul: ridică BGP și VPC-ul va învăța prefixele

BGP este o conversație între doi vorbitori, iar în acest design vorbitorii sunt demonul de rutare de pe aparatul tău și un punct final VPC Route Server pe care AWS îl plasează într-o subrețea pe care o deții. Acea conversație transportă prefixe. Nu atinge tabela de rutare a subrețelelor tale de lucru, pentru că acele tabele învață doar prin propagarea care trebuie activată pe fiecare dintre ele. Până când asta se întâmplă, țesutul VPC-ului nu știe nimic despre ce știe aparatul.

Pașii de configurare sunt separați dintr-un motiv: asociază, creează punctul final, fă peering, apoi activează propagarea.

Route Server este un plan de control, nu un tunel

Route Server nu criptează, nu transmite și nu inspectează niciun singur pachet. Există pentru a schimba BGP cu aparatul și a preda prefixele rezultate tabelelor de rutare configurate să le primească. Planul de date este neschimbat: pachetele ies în continuare prin interfața de rețea a aparatului, călătoresc prin VPN-ul lui și se întorc pe același drum.

Asta înseamnă că verificarea sursei și a destinației pe instanța de transmitere contează în continuare, pentru că instanța transmite acum trafic adresat altcuiva.

Grupurile de securitate și controalele de subrețea se aplică și fluxului transmis. Route Server nu va forța un aparat care aruncă traficul să îl transmită și nu va repara o rută de întoarcere lipsă pe partea îndepărtată.

Propagarea este pe fiecare tabelă de rutare, nu pe tot VPC-ul

Asocierea serverului de rutare cu VPC-ul și activarea propagării într-o tabelă de rutare sunt două decizii, și doar a doua schimbă ce face o subrețea. Un VPC cu șase tabele de rutare poate primi un prefix propagat într-una și nu în celelalte cinci, ceea ce este exact corect pentru o subrețea hub și exact ceea ce produce rezultatul derutant «funcționează pe jumătate». Chiar și acolo unde propagarea este activă, o rută concurentă poate câștiga, pentru că selecția rutelor în VPC preferă prefixul cel mai lung și, la lungime egală, preferă o rută statică uneia propagate. Această preferință se aplică în tăcere.

Verifică tabela efectivă pentru subrețeaua concretă în locul listei de prefixe anunțate de aparat. API-ul răspunde direct la această întrebare: aws ec2 associate-route-server și aws ec2 enable-route-server-propagation --route-table-id <id> sunt cei doi pași pe care oamenii îi uită, iar aws ec2 describe-route-tables --route-table-ids <id> arată dacă prefixul a ajuns ca intrare route server.

Aparatul transportă în continuare fiecare pachet

A anunța accesibilitatea nu este același lucru cu a o avea. O sesiune BGP poate rămâne stabilită în timp ce VPN-ul aparatului este căzut, iar un anunț static care nu se schimbă niciodată continuă să tragă traficul către o cale moartă. Route Server acceptă detectarea defecțiunilor precum BFD, dar asta testează vitalitatea partenerului, nu sănătatea a tot ce este în spatele lui.

Leagă anunțul de ruta la distanță reală: anunță prefixul când tunelul și rețeaua la distanță sunt active, și retrage-l când nu sunt.

Retrage un prefix și urmărește ce se întâmplă

Testează în etape, și fă din ultima etapă o eliminare. Confirmă că anunțul ajunge, că prefixul apare în fiecare tabelă dorită, că aparatul este următorul hop, că transmiterea traversează tunelul activ și că capătul îndepărtat răspunde. Apoi retrage un prefix de test, sau închide un tunel aprobat, și observă dacă traficul se mută unde spune designul. Notează tabelele înainte și după cât timp testul este încă deschis.

Mutarea unei rute pe un al doilea aparat nu mută sesiunile pe care le transporta, pentru că starea NAT și a firewall-ului rămâne pe primul echipament.

Pentru un set fix de o duzină de prefixe, rutele statice din tabelele VPC-ului rămân răspunsul mai ieftin. Route Server își câștigă locul când lista de prefixe se schimbă cu adevărat și politica de retragere este ceva ce poți explica persoanei de gardă.