Směrování poboček MPLS: co se CE naučí a od koho

Host v jedné pobočce otevírá spojení k serveru v jiné a oba areály stojí za stejnou spravovanou MPLS VPN na 3. vrstvě. Host zná jen svou výchozí bránu a nic dalšího, což je správně. Podstatné je, že místní zákaznická hrana předá paket své hraně poskytovatele a že stav směrování VPN u poskytovatele jej doručí do pobočky, která vlastní cílový prefix.

Projít jeden paket po cestě je nejrychlejší způsob, jak zjistit, která část je odpovědností zákazníka a která patří službě.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Kde končí práce každého hopu

CE-A potřebuje trasu pro vzdálenou LAN směřující k jeho místnímu připojení k poskytovateli, nikoli k WAN adrese vzdálené pobočky. Poskytovatel pak nese paket svým jádrem pomocí stavu směrování VPN a CE-B jej doručí do cílové LAN. Host v žádném okamžiku nemusí rozumět popiskům, VRF ani internetovému okruhu protější strany.

Chyba, která se v tiketech objevuje pořád, je nastavení WAN adresy pobočky B jako dalšího hopu v pobočce A. Obě pobočky si koupily stejnou službu, takže to vypadá, jako by měly být sousedé. Nejsou: další hop musí být dosažitelný přes návrh směrování, který skutečně máte, a vzdálená CE je obvykle mnoho hopů daleko za zařízením, které nespravujete. Statická trasa postavená na tomto předpokladu se zobrazí jako aktivní a nerozřeší se do ničeho, což je horší než chybějící trasa, protože v tabulce vypadá správně.

RFC 4364 odděluje výměnu mezi zákaznickou a poskytovatelskou hranou od distribuce tras VPN poskytovatelem, a to je přesně ta hranice, o které je tato příručka. Úkolem zákazníka je říct své hraně, co může doručit, a přijmout dosažitelnost, kterou služba nabízí zpět.

Na čem se předání musí dohodnout

Vyberte mechanismus s poskytovatelem, ne kolem něj. Statické trasy, BGP nebo uspořádání směrovacího protokolu mezi CE a PE jsou všechny legitimní a OSPF má pro takové předání definovaný model MPLS VPN. Nic z toho není důvod stavět sousedství OSPF mezi dvěma vzdálenými zákaznickými hranami přes nespecifikované jádro poskytovatele, protože to je návrh, se kterým poskytovatel nesouhlasil a nemůže jej podporovat.

Než nová LAN vstoupí do provozu, zapište čtyři věci: prefix, místní další trasu na CE, oznámení, které poskytovatel přijme, a trasy, které poskytovatel vrátí. Přidejte jakékoli filtrování, limity prefixů nebo omezení mezi lokalitami, která ukládá smlouva. Zdravé sousedství je kanál pro výměnu informací, a není důkazem, že byl konkrétní prefix přijat; relace může být aktivní, zatímco vaše nová podsíť sedí ve filtru.

Potom sledujte odpověď. Pobočka B potřebuje trasu zpět do zdrojové LAN a host na přijímací straně potřebuje vlastní bránu a vlastní oprávnění ke službě. Trasa, která se objeví na CE-A, zajišťuje polovinu cesty tam a zpět, a polovina cesty tam a zpět je důvod, proč jeden směr testu ping vypadá zdravě, zatímco aplikace stále selhává.

Ověřte obě předání před podpisem

Shromážděte stav směrování na obou zákaznických hranách, potvrďte u poskytovatele, že zamýšlené prefixy LAN byly přijaty do VPN, a poté otestujte jednu povolenou aplikaci v každém směru. Samotné směrovací tabulky nedokazují, že aplikace funguje, a samotný test aplikace vám neřekne, která řídicí rovina selhala, když nefunguje.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Čtěte tři výstupy společně. První říká, čemu hrana věří, druhý říká, co se naučila a od kterého peeru, a třetí říká, co bude skutečně předávat. Nesoulad mezi nimi bývá problém politiky nebo rekurze, nikoli chybějící oznámení, a vyplatí se jej vyřešit, než poskytovatele požádáte o vyšetřování. Vezměte tyto tři výstupy na hovor s operátorem, protože odpovídají na většinu otázek, které by vám jinak položil inženýr podpory.

Vězte, co služba neposkytuje

Toto je směrovaný přístup 3. vrstvy. Toto není okruh 2. vrstvy, který rozšiřuje broadcast mezi pobočkami, takže objevovací protokoly, aplikace závislé na broadcastu a předpoklady o sdíleném segmentu s ním necestují. Tisk, procházení názvů a cokoli, co závisí na místním segmentu, potřebuje vlastní návrh.

Oddělení VPN také není šifrování. Přepínání popisků drží zákazníky odděleně uvnitř sítě poskytovatele a nečiní obsah důvěrným, pokud smlouva vyžaduje důvěrnost. Tam, kde na tom záleží, to musí zajistit aplikace nebo nadstavba.

Nakonec mějte model služby zapsaný vedle konfigurace směrování lokality. Příští inženýr, který přidá podsíť, by měl být schopen přečíst, které prefixy se oznamují, kdo je přijímá a jaká je očekávaná zpětná cesta: specifikace BGP/MPLS IP VPN je referencí pro model, který za tím vším stojí.