MPLS-filialrouting: vad CE lär sig, och av vem

En värd på en filial öppnar en anslutning till en server på en annan, och båda platserna ligger bakom samma hanterade MPLS VPN på lager 3. Värden känner bara till sin egen standardgateway och inget annat, vilket är korrekt. Det viktiga är att den lokala kundkanten lämnar över paketet till sin leverantörskant, och att leverantörens VPN-routingtillstånd levererar det till den filial som äger destinationsprefixet.

Att följa ett paket längs vägen är det snabbaste sättet att se vilken del som är kundens ansvar och vilken del som hör till tjänsten.

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

Var varje hopps arbete slutar

CE-A behöver en rutt till det avlägsna LAN:et som pekar på sin lokala leverantörsanslutning, inte på den avlägsna filialens WAN-adress. Sedan bär leverantören paketet genom sin egen kärna med hjälp av VPN-routingtillståndet, och CE-B levererar det till mål-LAN:et. Vid ingen tidpunkt behöver en värd förstå etiketter, VRF:er eller den andra sidans internetförbindelse.

Felet som ständigt dyker upp i ärenden är att konfigurera filial B:s WAN-adress som nästa hopp på filial A. Båda filialerna har köpt samma tjänst, så det känns som om de borde vara grannar. Det är de inte: ett nästa hopp måste vara nåbart genom den routingdesign du faktiskt har, och den avlägsna CE:n ligger vanligtvis många hopp bort bakom utrustning du inte administrerar. En statisk rutt byggd på det antagandet visas som aktiv och löser inte upp till något, vilket är värre än en saknad rutt eftersom den ser korrekt ut i tabellen.

RFC 4364 skiljer utbytet mellan kund- och leverantörskant från leverantörens distribution av VPN-rutter, och det är precis den gränsen den här handboken handlar om. Kundens uppgift är att tala om för sin kant vad den kan leverera och att acceptera den nåbarhet tjänsten erbjuder tillbaka.

Vad överlämningen måste komma överens om

Välj mekanismen tillsammans med leverantören i stället för runt dem. Statiska rutter, BGP eller en routingprotokollöverenskommelse mellan CE och PE är alla legitima, och OSPF har en definierad MPLS VPN-modell för en sådan överlämning. Ingen av dem är skäl att bygga ett OSPF-grannskap mellan två avlägsna kundkanter genom en ospecificerad leverantörskärna, eftersom det är en design som leverantören inte har godkänt och inte kan stödja.

Innan ett nytt LAN tas i drift, skriv ned fyra saker: prefixet, den lokala vidare rutten på CE:n, den annonsering leverantören accepterar och de rutter leverantören returnerar. Lägg till all filtrering, prefixgränser eller begränsningar mellan platser som avtalet kräver. Ett sunt grannskap är en kanal för att utbyta information, och det är inte bevis för att ett visst prefix accepterades; sessionen kan vara uppe medan ditt nya subnät sitter i ett filter.

Följ sedan svaret. Filial B behöver en rutt tillbaka till käll-LAN:et, och värden på mottagarsidan behöver sin egen gateway och sina egna tjänstetillstånd. En rutt som dyker upp på CE-A etablerar halva resan, och halva resan är anledningen till att en riktning av ett ping-test ser sund ut medan applikationen fortfarande misslyckas.

Verifiera båda överlämningarna före godkännande

Samla routingtillståndet på båda kundkanterna, bekräfta med leverantören att de avsedda LAN-prefixen accepterades i VPN:et och testa sedan en tillåten applikation i varje riktning. Rutttabeller ensamma bevisar inte att applikationen fungerar, och ett applikationstest ensamt säger inte vilket kontrollplan som misslyckades när den inte fungerar.

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

Läs de tre utdata tillsammans. Den första säger vad kanten tror, den andra säger vad den har lärt sig och från vilken peer, och den tredje säger vad den faktiskt kommer att vidarebefordra. Oenighet mellan dem är oftast ett policy- eller rekursionsproblem snarare än en saknad annonsering, och det är värt att lösa innan leverantören ombeds undersöka. Ta med de tre utdata till samtalet med operatören, för de besvarar de flesta frågor en supportingenjör annars skulle ställa.

Vet vad tjänsten inte erbjuder

Detta är routad åtkomst på lager 3. Det är inte en förbindelse på lager 2 som sträcker ut broadcast mellan kontor, så upptäcktsprotokoll, broadcastberoende applikationer och antaganden om delat segment följer inte med. Utskrift, namnbläddring och allt som beror på ett lokalt segment behöver sin egen design.

VPN-avskiljning är inte heller kryptering. Etikettväxling håller kunder åtskilda inne i leverantörens nätverk, och det gör inte nyttolasten konfidentiell om avtalet kräver konfidentialitet. Där det spelar roll måste applikationen eller ett överlägg tillhandahålla det.

Slutligen bör du hålla tjänstemodellen nedskriven bredvid platsens routingkonfiguration. Nästa ingenjör som lägger till ett subnät bör kunna läsa vilka prefix som annonseras, vem som accepterar dem och vad den förväntade returvägen är: BGP/MPLS IP VPN-specifikationen är referensen för modellen bakom allt detta.