Miért nem jelenik meg a BGP-munkamenet a VPC útválasztási táblájában

Az a történet járja, hogy az EC2 VPN-berendezésen futó routing démon megtanítja a VPC-nek a távoli prefixeit, amint a BGP feljön. Ennek a fele igaz. A munkamenet feljön, és a VPC útválasztási táblájában emiatt semmi sem változik, ezért az első tünet általában egy alhálózat, amely csendben a semmibe dobja a forgalmat.

Két különböző dolgot kevernek itt össze: a peeringet egy route serverrel, és az útvonalak táblába telepítését.

A mítosz: hozd fel a BGP-t, és a VPC megtanulja a prefixeket

A BGP két beszélő közötti beszélgetés, és ebben a felépítésben a beszélők a berendezésén futó routing démon és egy VPC Route Server végpont, amelyet az AWS az Ön tulajdonában lévő alhálózatba helyez. Ez a beszélgetés prefixeket szállít. Nem érinti a munkaterhelés-alhálózatok útválasztási tábláját, mert azok a táblák csak olyan terjesztés útján tanulnak, amelyet mindegyiken engedélyezni kell. Amíg ez meg nem történik, a VPC szövete semmit sem tud arról, amit a berendezés tud.

A beállítási lépések okkal különülnek el: társítás, a végpont létrehozása, peering, majd a terjesztés engedélyezése.

A Route Server vezérlési sík, nem alagút

A Route Server nem titkosít, nem továbbít és nem vizsgál egyetlen csomagot sem. Azért létezik, hogy BGP-t cseréljen a berendezéssel, és a keletkező prefixeket átadja azoknak az útválasztási tábláknak, amelyeket a fogadásukra konfiguráltak. Az adatsík változatlan: a csomagok továbbra is a berendezés hálózati interfészén keresztül lépnek ki, áthaladnak a VPN-jén, és ugyanazon az úton térnek vissza.

Ez azt jelenti, hogy a továbbító példányon a forrás- és célcím-ellenőrzés továbbra is számít, mert a példány most valaki másnak címzett forgalmat továbbít.

A biztonsági csoportok és az alhálózati vezérlések a továbbított folyamatra is érvényesek. A Route Server nem kényszeríti a forgalmat eldobó berendezést annak továbbítására, és nem javítja ki a távoli oldalon hiányzó visszatérési útvonalat.

A terjesztés útválasztási táblánként történik, nem VPC-nként

A route server VPC-hez társítása és a terjesztés engedélyezése egy útválasztási táblán két döntés, és csak a második változtatja meg, hogy mit tesz egy alhálózat. Egy hat útválasztási táblával rendelkező VPC az egyikben megkaphat egy terjesztett prefixet, a másik ötben nem, ami pontosan helyes egy hub-alhálózat esetén, és pontosan ez hozza létre a zavarba ejtő «félig működik» eredményt. Még ahol a terjesztés be van kapcsolva, egy versengő útvonal nyerhet, mert a VPC útvonalválasztása a leghosszabb prefixet részesíti előnyben, azonos hosszúságnál pedig a statikus útvonalat a terjesztettel szemben. Ez az előnyben részesítés csendben történik.

A berendezés által hirdetett prefixek listája helyett az adott alhálózat tényleges tábláját ellenőrizze. Az API közvetlenül válaszol erre a kérdésre: aws ec2 associate-route-server és aws ec2 enable-route-server-propagation --route-table-id <id> az a két lépés, amelyet az emberek elfelejtenek, és a aws ec2 describe-route-tables --route-table-ids <id> megmutatja, hogy a prefix egyáltalán megérkezett-e route server bejegyzésként.

A berendezés továbbra is minden csomagot visz

Elérhetőséget hirdetni nem ugyanaz, mint rendelkezni vele. Egy BGP-munkamenet akkor is felállítva maradhat, miközben a berendezés VPN-je leállt, és egy soha nem változó statikus hirdetmény folyamatosan halott útvonal felé húzza a forgalmat. A Route Server támogatja a hibafelismerést, például a BFD-t, de ez a peer életképességét vizsgálja, nem mindannak az állapotát, ami mögötte van.

Kösse a hirdetményt a valódi távoli útvonalhoz: hirdesse a prefixet, amikor az alagút és a távoli hálózat működik, és vonja vissza, amikor nem.

Vonjon vissza egy prefixet, és figyelje, mi történik

Teszteljen szakaszosan, és az utolsó szakaszt tegye eltávolítássá. Erősítse meg, hogy a hirdetmény megérkezik, a prefix megjelenik minden szándékolt táblában, a berendezés a következő ugrás, a továbbítás áthalad az aktív alagúton, és a távoli vég válaszol. Ezután vonjon vissza egy tesztprefixet, vagy zárjon le egy jóváhagyott alagutat, és figyelje meg, hogy a forgalom oda mozdul-e, ahol a tervezés szerint kell. Jegyezze fel a táblákat előtte és utána, amíg a teszt nyitva van.

Egy útvonal áthelyezése egy második berendezésre nem helyezi át a szállított munkameneteket, mert a NAT és a tűzfal állapota az első eszközön marad.

Egy tucat prefixből álló rögzített készletnél a VPC tábláiban lévő statikus útvonalak maradnak az olcsóbb válasz. A Route Server akkor érdemli ki a helyét, amikor a prefixlista valóban változik, és a visszavonási szabályzat olyasmi, amit el tud magyarázni az ügyeletesnek.