MPLS fióktelep-útválasztás: mit tanul meg a CE, és kitől

Egy fióktelep gazdagépe kapcsolatot nyit egy másik fióktelep kiszolgálójával, és mindkét telephely ugyanazon felügyelt MPLS VPN mögött van, a 3. rétegben. A gazdagép csak a saját alapértelmezett átjáróját ismeri, semmi mást, ami helyes. A lényeg az, hogy a helyi ügyfélperem átadja a csomagot a szolgáltatói peremének, és a szolgáltató VPN-útválasztási állapota eljuttassa a cél-előtagot birtokló fióktelephez.

Egy csomag végigkövetése az útvonalon a leggyorsabb módja annak megállapítására, melyik rész az ügyfél felelőssége, és melyik rész tartozik a szolgáltatáshoz.

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

Hol ér véget az egyes ugrások feladata

A CE-A-nak a távoli LAN felé mutató útvonalra van szüksége, amely a helyi szolgáltatói csatlakozására mutat, nem a távoli fióktelep WAN-címére. Ezután a szolgáltató a saját gerinchálózatán viszi át a csomagot a VPN-útválasztási állapot segítségével, és a CE-B a cél-LAN-ra juttatja. Egyetlen ponton sem kell a gazdagépnek címkéket, VRF-eket vagy a túloldal internet-körét értenie.

A jegyekben újra és újra felbukkanó hiba az, hogy a B fióktelep WAN-címét állítják be következő ugrásként az A fióktelepen. Mindkét fióktelep ugyanazt a szolgáltatást vásárolta meg, ezért úgy tűnik, mintha szomszédoknak kellene lenniük. Nem azok: a következő ugrásnak azon az útválasztási tervezésen keresztül kell elérhetőnek lennie, amely valóban van, és a távoli CE általában sok ugrásra van olyan berendezés mögött, amelyet Ön nem üzemeltet. Az erre a feltevésre épített statikus útvonal aktívként jelenik meg, és semmire sem oldódik fel, ami rosszabb a hiányzó útvonalnál, mert a táblázatban helyesnek látszik.

Az RFC 4364 elválasztja az ügyfél- és a szolgáltatói perem közötti cserét a szolgáltató VPN-útvonalainak terjesztésétől, és pontosan ez az a határ, amelyről ez a kézikönyv szól. Az ügyfél feladata, hogy megmondja a peremének, mit tud szállítani, és elfogadja azt az elérhetőséget, amelyet a szolgáltatás visszaad.

Miben kell az átadásnak megegyeznie

A mechanizmust a szolgáltatóval együtt válassza, ne körülötte. A statikus útvonalak, a BGP vagy a CE és PE közötti útválasztási protokoll-megállapodás mind legitim, és az OSPF-nek van definiált MPLS VPN-modellje az ilyen átadáshoz. Egyik sem ok arra, hogy OSPF-szomszédságot építsen két távoli ügyfélperem között egy nem meghatározott szolgáltatói gerincen keresztül, mert az olyan tervezés, amelyhez a szolgáltató nem járult hozzá, és amelyet nem tud támogatni.

Mielőtt egy új LAN élesbe áll, írjon le négy dolgot: az előtagot, a helyi továbbító útvonalat a CE-n, a hirdetést, amelyet a szolgáltató elfogad, és az útvonalakat, amelyeket a szolgáltató visszaad. Adja hozzá a szerződés által előírt szűréseket, előtag-korlátokat vagy telephelyek közötti korlátozásokat. Az egészséges szomszédság az információcsere csatornája, és nem bizonyítéka annak, hogy egy adott előtagot elfogadtak; a munkamenet állhat, miközben az új alhálózata egy szűrőben ül.

Ezután kövesse a választ. A B fióktelepnek útvonalra van szüksége vissza a forrás-LAN-ra, és a fogadó oldali gazdagépnek a saját átjárójára és a saját szolgáltatási engedélyeire. A CE-A-n megjelenő útvonal egy oda-vissza út felét teremti meg, és az út fele az oka annak, hogy a ping-teszt egyik iránya egészségesnek látszik, miközben az alkalmazás továbbra is meghiúsul.

Az átadás előtt ellenőrizze mindkét átadást

Gyűjtse össze az útválasztási állapotot mindkét ügyfélperemen, erősítse meg a szolgáltatóval, hogy a tervezett LAN-előtagokat elfogadták a VPN-be, majd teszteljen egy engedélyezett alkalmazást mindkét irányban. Az útvonaltáblák önmagukban nem bizonyítják, hogy az alkalmazás működik, és egy alkalmazásteszt önmagában nem mondja meg, melyik vezérlési sík hibázott, amikor nem működik.

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

Olvassa a három kimenetet együtt. Az első azt mondja, mit hisz a perem, a második azt, mit tanult és melyik partnertől, a harmadik pedig azt, mit fog ténylegesen továbbítani. A köztük lévő eltérés általában házirend- vagy rekurziós probléma, nem hiányzó hirdetés, és érdemes megoldani, mielőtt a szolgáltatótól vizsgálatot kér. Vigye ezt a három kimenetet a szolgáltatóval folytatott beszélgetésre, mert megválaszolják a legtöbb kérdést, amelyet egy támogatási mérnök egyébként feltenne.

Tudja, mit nem nyújt a szolgáltatás

Ez 3. rétegbeli útválasztott hozzáférés. Ez nem 2. rétegbeli kör, amely kiterjeszti a sugárzást az irodák között, ezért a felderítési protokollok, a sugárzástól függő alkalmazások és a megosztott szegmensre vonatkozó feltevések nem utaznak vele. A nyomtatás, a névbejárás és minden, ami helyi szegmenstől függ, saját tervezést igényel.

A VPN-elválasztás sem titkosítás. A címke-kapcsolás távol tartja az ügyfeleket a szolgáltató hálózatán belül, és nem teszi bizalmassá a hasznos terhet, ha a szerződés bizalmasságot ír elő. Ahol ez számít, azt az alkalmazásnak vagy egy fedőrétegnek kell biztosítania.

Végül tartsa a szolgáltatásmodellt írásban a telephely útválasztási konfigurációja mellett. A következő mérnök, aki alhálózatot ad hozzá, olvasni tudja, mely előtagokat hirdetik, ki fogadja el őket, és mi a várt visszaút: a BGP/MPLS IP VPN specifikáció a referencia mindennek a hátterében álló modellhez.