Brána pobočky zobrazuje prefix cloudu ve své tabulce BGP, relace s poskytovatelem je navázaná, a přesto požadavek uživatele na tento prefix odchází špatným rozhraním. Nic není rozbité tak, jak naznačuje monitoring, protože „BGP se to naučil“ je tvrzení o řídicí rovině. Mezi touto tabulkou a paketem jsou čtyři oddělené přechody a tok se zastaví přesně na jednom z nich. Projděte brány popořadě a zastavte se u první, která selže.

První brána: co soused skutečně poslal

Začněte prefixem tak, jak byl přijat, ne shrnutý. Najděte přesnou síť a masku v tabulce BGP a poznamenejte si next hop, AS path a případnou community, kterou může importní politika porovnat. Souhrnná trasa na dashboardu může skrýt fakt, že konkrétní prefix nebyl nikdy přijat.

Importní politika je obvyklé místo, kde trasa zmizí bez chyby. Prefix list, filtr community nebo inbound route map mohou aktualizaci zahodit, zatímco relace zůstává nahoru a zdravá, a proto zelené světlo souseda dokazuje tak málo. Nepřítomnost řádku v logu neznamená nepřítomnost rozhodnutí. Obvykle znamená, že rozhodnutí padlo tiše, přesně jak je nakonfigurováno.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Čtěte výstup v tomto pořadí. První dva příkazy říkají, zda informace dorazila a co peer tvrdí, že poslal; poslední dva, zda se něco dostalo do směrovacích a přeposílacích tabulek. Prefix přítomný v prvním příkazu a chybějící ve třetím je problém výběru nebo instalace, ne konektivity.

Druhá brána: výběr, pak instalace

BGP vybírá nejlepší cestu a vybraná cesta se neinstaluje automaticky. Next hop se musí přeložit, a jiný zdroj tras už může tento prefix vlastnit s lepší administrativní vzdáleností. Statická trasa zbylá z migrace snadno přemůže platnou cestu BGP a pošle provoz jinam.

RFC 4271 drží tři myšlenky oddělené: co poslal peer, co tento speaker vybral jako nejlepší a co bude dál inzerovat. Jsou to konceptuální role, ne tři fyzické databáze, které musí dodavatel vystavit, ale právě to oddělení dělá z „je to v BGP“ neúplnou odpověď.

Zkontrolujte také, který kontext směrování čtete. Trasa nainstalovaná ve VRF, do které rozhraní uživatele nepatří, je pro pakety tohoto uživatele neviditelná, a tabulka přitom celou dobu vypadá správně.

Třetí brána: vyhledání, které platí pro tento tok

Teď přestaňte ptát se na trasu a začněte ptát se na paket. Poznamenejte zdrojovou adresu uživatele, cíl, protokol, port a vstupní rozhraní, protože každé z nich může vybrat jinou politiku. Pak se podívejte na vyhledání, které platí pro tuto kombinaci, místo na obecnou směrovací tabulku.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Specifičtější prefix je zde nejčastější překvapení, policy route druhé. Obě přebíjejí agregát, na který jste se dívali, a ani jedna není vidět v souhrnu tabulky BGP.

Ping z brány samotné není důkazem o relaci uživatele. Jiná zdrojová adresa, jiná cesta politikou a často jiný výsledek. Testujte se stejným zdrojem, který používá aplikace, nebo přijměte, že test odpovídá na jinou otázku.

Čtvrtá brána: vzdálená polovina cesty

Pokud místní vyhledání tunel skutečně vybere, paket musí ještě přijmout ochranná politika, povolit pravidlo předávání a odpovědět něco na druhé straně. Krypto ACL, které nezahrnuje pár adres, provoz zahodí, zatímco tunel hlásí, že je nahoru, což vytváří timeout nerozlišitelný od selhání směrování.

Zpáteční cesta je stejně důležitá jako odchozí. Strana cloudu musí vědět, jak dosáhnout zdroje pobočky, buď trasou, nebo překladem, který jste záměrně nakonfigurovali. Asymetrické zpáteční cesty jsou běžné v návrzích testovaných jen z jednoho směru.

Spojte nové autorizované spojení se třemi pozorováními: místní politikou, která odpovídala, čítači tunelu, které se pohnuly, a příjmem na vzdálené straně, kde je to vidět. Pokud se čítače nehýbou, paket do tunelu nikdy nevstoupil, ať tabulka tras říká cokoli. Pokud se hýbou a nic nedorazí, vzdálená strana ho zahazuje nebo směruje špatně. Tyto dva výsledky vedou k úplně jiným týmům.

Pojmenujte přechod, který selhal

Zapište výsledek jako jeden z pěti stavů: nepřijato, nepřijato politikou, nevybráno, nenainstalováno nebo neshoduje se s tímto tokem. Přidejte šestý pro případ, kdy je místní cesta správná a vzdálený konec nemůže odpovědět. Ta věta je výstup a je mnohem užitečnější než screenshot navázaného souseda.

V akceptačním plánu udržujte i negativní test: cíl, který nesmí procházet tunelem, ověřený po změně. Checklist, který dokazuje jen šťastnou cestu, nezachytí široké pravidlo politiky, které někdo přidá při příštím okně údržby.

Související články