Zašto se BGP sesija ne pojavljuje u VPC tabeli ruta

Priča koja se ponavlja jest da će routing daemon na EC2 VPN uređaju naučiti VPC njegove udaljene prefikse čim BGP proradi. Pola toga je tačno. Sesija proradi, i ništa u VPC tabeli ruta se zbog toga ne menja, zato je prvi simptom obično podmreža koja tiho baca saobraćaj u crnu rupu.

Ovde se mešaju dve različite stvari: peering sa route serverom i instaliranje ruta u tabelu.

Mit: podignite BGP i VPC će naučiti prefikse

BGP je razgovor između dva sagovornika, a u ovom dizajnu sagovornici su routing daemon na vašem uređaju i endpoint VPC Route Servera koji AWS postavlja u podmrežu koju posedujete. Taj razgovor nosi prefikse. On ne dira tabelu ruta vaših radnih podmreža, jer te tabele uče samo kroz propagaciju koja mora biti omogućena na svakoj od njih. Dok se to ne dogodi, VPC tkivo ne zna ništa o tome šta uređaj zna.

Koraci postavljanja su odvojeni s razlogom: povežite, kreirajte endpoint, uspostavite peering, zatim omogućite propagaciju.

Route Server je kontrolna ravan, a ne tunel

Route Server ne šifruje, ne prosleđuje i ne pregleda ni jedan paket. Postoji da razmeni BGP s uređajem i preda dobijene prefikse tabelama ruta koje su konfigurisane da ih primaju. Ravan podataka je nepromenjena: paketi i dalje izlaze kroz mrežni interfejs uređaja, putuju njegovim VPN-om i vraćaju se istim putem.

To znači da je provera izvora i odredišta na instanci koja prosleđuje i dalje bitna, jer instanca sada prosleđuje saobraćaj adresiran na nekog drugog.

Sigurnosne grupe i kontrole podmreže i dalje važe za prosleđeni tok. Route Server neće naterati uređaj koji odbacuje saobraćaj da ga prosledi, niti će popraviti nedostajuću povratnu rutu na udaljenoj strani.

Propagacija je po tabeli ruta, ne po VPC-u

Povezivanje route servera s VPC-om i omogućavanje propagacije u tabeli ruta su dve odluke, a samo druga menja ono što podmreža radi. VPC sa šest tabela ruta može primiti propagirani prefiks u jednoj, a ne u ostalih pet, što je tačno ispravno za hub podmrežu i tačno ono što stvara zbunjujući rezultat «radi napola». Čak i tamo gde je propagacija uključena, konkurentska ruta može pobediti, jer VPC odabir ruta preferira najduži prefiks, a pri istoj dužini preferira statičku rutu nad propagiranom. Ta preferencija se primenjuje tiho.

Proverite efektivnu tabelu za konkretnu podmrežu, a ne listu prefiksa koje uređaj objavljuje. API na to pitanje odgovara direktno: aws ec2 associate-route-server i aws ec2 enable-route-server-propagation --route-table-id <id> su dva koraka koja ljudi zaborave, a aws ec2 describe-route-tables --route-table-ids <id> pokazuje da li je prefiks uopšte stigao kao route server unos.

Uređaj i dalje nosi svaki paket

Objavljivati dostupnost nije isto kao imati je. BGP sesija može ostati uspostavljena dok je VPN uređaja pao, a statička objava koja se nikad ne menja stalno vuče saobraćaj ka mrtvom putu. Route Server podržava otkrivanje kvarova kao što je BFD, ali to testira živost peera, a ne zdravlje svega iza peera.

Vežite objavu za stvarnu udaljenu rutu: objavite prefiks kada su tunel i udaljena mreža gore, i povucite ga kada nisu.

Povucite prefiks i gledajte šta se dešava

Testirajte u fazama, i neka zadnja faza bude uklanjanje. Potvrdite da objava stiže, da se prefiks pojavljuje u svakoj predviđenoj tabeli, da je uređaj sledeći hop, da prosleđivanje prelazi aktivni tunel i da udaljena strana odgovara. Zatim povucite testni prefiks, ili zatvorite odobreni tunel, i posmatrajte da li se saobraćaj pomera tamo gde dizajn kaže da treba. Zabeležite tabele pre i posle dok je test još otvoren.

Premeštanje rute na drugi uređaj ne premešta sesije koje je nosila, jer stanje NAT-a i firewall-a ostaje na prvom uređaju.

Za fiksni skup od desetak prefiksa statičke rute u VPC tabelama ostaju jeftiniji odgovor. Route Server zaslužuje svoje mesto kada se lista prefiksa zaista menja i kada politika povlačenja može objasniti osobi koja je na dežurstvu.