Proč se vaše BGP relace neobjeví v routovací tabulce VPC

Příběh, který se opakuje, je ten, že routing démon na VPN zařízení v EC2 naučí VPC jeho vzdálené prefixy, jakmile BGP naběhne. Polovina toho je pravda. Relace naběhne a v routovací tabulce VPC se kvůli tomu nic nezmění, proto je prvním příznakem obvykle podsíť, která tiše posílá provoz do černé díry.

Pletou se tu dvě různé věci: peering s route serverem a instalace tras do tabulky.

Mýtus: zvedněte BGP a VPC se naučí prefixy

BGP je rozhovor mezi dvěma mluvčími a v tomto návrhu jsou mluvčími routing démon na vašem zařízení a koncový bod VPC Route Server, který AWS umístí do podsítě, kterou vlastníte. Ten rozhovor přenáší prefixy. Nedotýká se routovací tabulky vašich pracovních podsítí, protože tyto tabulky se učí jen prostřednictvím propagace, kterou je nutné zapnout na každé z nich. Dokud se tak nestane, tkanina VPC neví nic o tom, co zařízení ví.

Kroky nastavení jsou oddělené z nějakého důvodu: přidružit, vytvořit koncový bod, navázat peering a poté zapnout propagaci.

Route Server je řídicí rovina, ne tunel

Route Server nešifruje, nepředává ani neprohlíží jediný paket. Existuje proto, aby si vyměňoval BGP se zařízením a předal výsledné prefixy routovacím tabulkám nakonfigurovaným k jejich příjmu. Datová rovina se nemění: pakety stále odcházejí přes síťové rozhraní zařízení, cestují jeho VPN a vracejí se stejnou cestou.

To znamená, že kontrola zdroje a cíle na předávající instanci je stále důležitá, protože instance nyní předává provoz adresovaný někomu jinému.

Bezpečnostní skupiny a ovládací prvky podsítě platí i pro předávaný tok. Route Server nepřiměje zařízení, které provoz zahazuje, aby ho předávalo, a neopraví chybějící zpětnou trasu na vzdálené straně.

Propagace je pro každou routovací tabulku, ne pro celou VPC

Přidružení route serveru k VPC a zapnutí propagace v routovací tabulce jsou dvě rozhodnutí a jen to druhé mění chování podsítě. VPC se šesti routovacími tabulkami může přijmout propagovaný prefix v jedné a ne v ostatních pěti, což je přesně správné pro hub podsíť a přesně to vytváří matoucí výsledek «funguje napůl». I tam, kde je propagace zapnutá, může vyhrát konkurenční trasa, protože výběr tras ve VPC preferuje nejdelší prefix a při stejné délce dává přednost statické trase před propagovanou. Tato preference se uplatňuje tiše.

Kontrolujte efektivní tabulku pro konkrétní podsíť, ne seznam prefixů, které zařízení inzeruje. API na tuto otázku odpovídá přímo: aws ec2 associate-route-server a aws ec2 enable-route-server-propagation --route-table-id <id> jsou dva kroky, na které lidé zapomínají, a aws ec2 describe-route-tables --route-table-ids <id> ukazuje, zda prefix vůbec dorazil jako záznam route server.

Zařízení stále nese každý paket

Inzerovat dostupnost není totéž jako ji mít. Relace BGP může zůstat navázaná, i když je VPN zařízení mimo provoz, a statický inzerát, který se nikdy nemění, neustále táhne provoz k mrtvé cestě. Route Server podporuje detekci poruch, například BFD, ale ta testuje živost peeru, ne zdraví všeho za ním.

Svažte inzerát se skutečnou vzdálenou trasou: ohlaste prefix, když je tunel a vzdálená síť v provozu, a stáhněte ho, když nejsou.

Stáhněte prefix a sledujte, co se stane

Testujte po fázích a poslední fázi udělejte odstraněním. Ověřte, že inzerát dorazí, prefix se objeví v každé zamýšlené tabulce, zařízení je další hop, předávání prochází aktivním tunelem a vzdálená strana odpovídá. Poté stáhněte testovací prefix nebo vypněte schválený tunel a sledujte, zda se provoz přesouvá tam, kam návrh říká. Zapište tabulky před a po, dokud je test ještě otevřený.

Přesun trasy na druhé zařízení nepřesune relace, které nesla, protože stav NAT a firewallu zůstává na prvním zařízení.

Pro pevnou sadu tuctu prefixů zůstávají statické trasy v tabulkách VPC levnější odpovědí. Route Server si své místo zaslouží, když se seznam prefixů skutečně mění a politika stahování je něco, co dokážete vysvětlit člověku na pohotovosti.