AFI és SAFI: a párt olvassa el a szolgáltatás neve előtt

Láthatja, ahogy egy munkamenet felépül, ahogy egy útvonal megjelenik, és mégis rossz szolgáltatást olvas. A számok párja minden hirdetés élén, a címcsalád-azonosító és a következő címcsalád-azonosító dönti el, melyik elemző olvassa a hasznos terhet, és melyik tábla tartja az eredményt. Ha eltéveszti a párt, az importszabály, az útvonalcél egyezése és a következő ugrás keresése mind olyan szerkezet ellen fut, amelyet senki nem hirdetett. Az alábbi végigvezetés abból a párból indul, és a továbbítás eredményénél ér véget.

Két szám dönti el, melyik táblába tartozik az útvonal

A pár kétszer jelenik meg: a többprotokollos képességen belül, ahol egy beszélő családot hirdet, és minden NLRI előtt, amelyet az a család hordoz. Ezért az útvonal tulajdonsága, nem pedig beállítás a forrásgépen. A gyártók Address family VPNv4 Unicast alakú névként nyomtatják, és a megfogalmazás kiadások között vándorol, míg a számok a helyükön maradnak.

Négy kódolás lefedi szinte az összes vállalati esetet: 1 a 128-cal az MPLS-címkézett VPN-IPv4-hez, 2 a 128-cal az IPv6 megfelelőjéhez, 25 a 65-tel a BGP-vel jelzett VPLS-hez, és 25 a 70-nel az EVPN-hez. Az első hiba azt feltételezni, hogy minden Layer 2 szolgáltatás a 25 és 65 mögött van, ami elrejti az EVPN-t. A második, hogy a két IP-családot egyetlen, hosszabb című családnak tekintjük, holott külön tárgyalják őket, és különböző partnereken fogadhatók el. Egy harmadik akkor jelenik meg, amikor egy sablont olyan kiadásból másolnak, amely csak az egyiket ismeri. A nyilvántartásban való keresés mindhármat gyorsabban rendezi, mint a szolgáltatás nevére épített találgatás.

A négy sort az IANA nyilvántartás példáinak tekintse, nem magának a nyilvántartásnak. Ha egy szám nem egyezik semmi ismerttel, nézze meg, mielőtt szabályt építene köré.

Az AFI 25 két egymástól független NLRI-formátumot hordoz

Mindkét Layer 2 család az AFI 25 alatt ül, és a hasonlóság ott véget ér. A VPLS NLRI a RFC 4761 section 3.2.2-ban hosszt, útvonal-megkülönböztetőt, VE ID-t, VE-blokk eltolást, VE-blokk méretet és címkealapot hordoz, amelyek együtt egy pseudowire végpontot és annak címkéjét nevezik meg. Az EVPN megtartja az AFI 25-öt, és a SAFI 70-re lép, ahol a hasznos teher egy útvonaltípus: Ethernet automatikus felderítés, MAC/IP hirdetés, befogadó multicast, Ethernet szegmens, IP előtag. Ezért ugyanaz a bájteltolás mást jelent a két családban. Az egyikre írt elemző a másikat panasz nélkül olvassa, és értelmetlenséget állít elő. A pár az egyetlen figyelmeztetés, hogy az értelmezés hibás.

Az a mező, amely az egyik családban VE-blokk eltolást jelent, a másikban nem létezik, és a MAC/IP hirdetési útvonal csak az EVPN-ben van. Egy attribútumot úgy idézni, mintha mindkettőre vonatkozna, az az út, amelyen egy rögzítés áttekintése félremegy.

Amikor valaki rögzítést vagy gyártói táblázatot ad, kérdezze meg, melyik családhoz tartozik az attribútum. Ezután erősítse meg, hogy a fogadó megvalósítás támogatja azt a családot, nem az adatlap szolgáltatásnevét. Két platform egyaránt állíthatja a VPLS támogatását, miközben eltérő jelzési családokat valósít meg. A pár elválasztja őket; a termékcímke nem.

A munkamenet saját címcsaládja külön kérdés

A VPN-IPv6 rendszeresen olyan munkameneten keresztül hirdetett, amelynek TCP-kapcsolata IPv4 felett fut, és ez támogatott tervezés, nem hiba. Ezért csak a munkamenet-összefoglalót olvasva semmit sem tudunk meg arról, mely VPN-családokat cserélnek a partnerek.

Az NLRI család, a szállítási család és a továbbítási család három független döntés. Egy router beszélhet IPv4-et a partnerével, elfogadhatja a VPN-IPv6 elérhetőségét, és telepíthet olyan útvonalat, amelynek következő ugrása egy IPv6-cím, amely olyan úton érhető el, amelyet nem szándékozott. Minden rétegnek saját megerősítésre van szüksége. Azok a helyek, amelyek elérhetetlen IPv6-célokat jelentenek, miközben a hirdetések helyesnek tűnnek, általában a következő ugrás feloldását veszítették el, nem a családtárgyalást.

Tesztelje a munkamenet címcsaládját külön, majd az általa hordozott családokat, majd azt, amit a mag továbbítani tud. A három szétválasztása megakadályozza a gyakori téves diagnózist, amelyben egy helyes hirdetést annak bizonyítékaként olvasnak, hogy az IPv6 végponttól végpontig működik. Az csak azt bizonyítja, hogy az egyik partner beszélt a másiknak egy előtagról.

Tárgyalt, fogadott, importált, telepített

Egy várt útvonalhoz négy állapotnak kell sorrendben teljesülnie, és mindegyik megfigyelhető. A családot tárgyalni kell azzal a partnerrel, az útvonalnak meg kell érkeznie, egy útvonalcélnek importálnia kell a szánt környezetbe, és a következő ugrásnak fel kell oldódnia, hogy az útvonal települjön. Az első állapot kihagyása a másik hármat megválaszolhatatlanná teszi, mert a nem tárgyalt család nem termel átvizsgálható útvonalakat. A Cisco stílusú platformokon a család-összefoglalók és a partnerekénti képességek külön parancsok.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

A tárgyalás a partnereként nyomtatott képességcserében látszik, és egy létrejött munkamenet, amelyben nincs felsorolt család, semmit sem hordoz abból, amit kért. Az importot a kiterjesztett közösségként hordozott útvonalcélok döntik el, ezért egy helyes pár elgépelt céllal üresen hagyja a táblát. A telepítés ezután a következő ugrás fogadó környezetben való feloldásától függ, ami meghiúsulhat, miközben minden hirdetés tökéletesnek látszik.

Utoljára az adatsíkot erősítse meg, mert a táblában lévő útvonal állítás, nem kézbesítés. Ugyanaz a négy állapot érvényes minden családra; csak a parancsok és a táblanevek változnak.

Amit egy családpár soha nem bizonyít

A pár helyes olvasása megmondja, hogyan értelmezze a következő útvonalinformációt, és ez az egész állítás. Semmit sem mond az elérhetőségről, a szabályról vagy az adatsík egészségéről. A kettő összekeverése magabiztos kijelentéseket szül egy olyan hálózatról, amelyet senki nem ellenőrzött. Az útvonalcél-eltérés és a törött következő ugrás a párból nézve azonosnak tűnik. A pár olvasási utasítás, soha nem ítélet.

Amikor eszkalál, tegye a párt, az útvonalcélt és a feloldott következő ugrást ugyanabba a feljegyzésbe. A következő mérnöknek akkor három független dolga van tesztelni a szolgáltatásnév újraértelmezése helyett. Ha hiányzik a tárgyalás, azonnal látják, a rossz cél láthatóan hiányzóvá teszi az importot, és a feloldatlan következő ugrás jelenlévő, de használhatatlan útvonalat hagy.