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

Priča koja se ponavlja jeste 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 mijenja, zato je prvi simptom obično podmreža koja tiho baca saobraćaj u crnu rupu.

Ovdje se miješaju dvije 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 posjedujete. 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 šifrira, ne prosljeđuje i ne pregleda ni jedan paket. Postoji da razmijeni BGP s uređajem i preda dobijene prefikse tabelama ruta koje su konfigurisane da ih primaju. Ravan podataka je nepromijenjena: 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 provjera izvora i odredišta na instanci koja prosljeđuje i dalje bitna, jer instanca sada prosljeđuje saobraćaj adresiran na nekog drugog.

Sigurnosne grupe i kontrole podmreže i dalje važe za proslijeđeni tok. Route Server neće natjerati uređaj koji odbacuje saobraćaj da ga proslijedi, 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 dvije odluke, a samo druga mijenja 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 gdje je propagacija uključena, konkurentska ruta može pobijediti, jer VPC odabir ruta preferira najduži prefiks, a pri istoj dužini preferira statičku rutu nad propagiranom. Ta preferencija se primjenjuje tiho.

Provjerite 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 mijenja 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 sljedeći hop, da prosljeđivanje prelazi aktivni tunel i da udaljena strana odgovara. Zatim povucite testni prefiks, ili zatvorite odobreni tunel, i posmatrajte da li se saobraćaj pomjera tamo gdje dizajn kaže da treba. Zabilježite tabele prije i poslije dok je test još otvoren.

Premještanje rute na drugi uređaj ne premješ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 mjesto kada se lista prefiksa zaista mijenja i kada politika povlačenja može objasniti osobi koja je na dežurstvu.