AFI a SAFI: prečítajte dvojicu pred názvom služby

Môžete sledovať, ako relácia nabehne, ako sa objaví trasa, a napriek tomu čítať nesprávnu službu. Dvojica čísel na začiatku každého oznámenia, identifikátor adresovej rodiny a identifikátor nasledujúcej adresovej rodiny, rozhoduje, ktorý parser číta payload a ktorá tabuľka drží výsledok. Pomýlite dvojicu a importná politika, zhoda route targetu aj hľadanie next hopu bežia proti štruktúre, ktorú nikto neoznámil. Prechádzka nižšie začína pri tej dvojici a končí pri výsledku preposielania.

Do ktorej tabuľky trasa patrí, rozhodujú dve čísla

Dvojica sa objavuje dvakrát: vnútri multiprotokolovej schopnosti, kde hovorca oznamuje rodinu, a pred každým NLRI, ktoré táto rodina nesie. Robí ju to vlastnosťou trasy, nie nastavením na zdrojovom boxe. Výrobcovia ju tlačia ako názov typu Address family VPNv4 Unicast, a formulácia sa medzi vydaniami posúva, kým čísla zostávajú na mieste.

Štyri kódovania pokrývajú takmer každý podnikový prípad: 1 so 128 pre VPN-IPv4 s MPLS labelom, 2 so 128 pre ekvivalent IPv6, 25 s 65 pre VPLS signalizované BGP a 25 s 70 pre EVPN. Prvá chyba je predpokladať, že každá služba Layer 2 žije za 25 s 65, čo skrýva EVPN. Druhá je brať obe IP rodiny ako jednu rodinu s dlhšou adresou, keď sa vyjednávajú oddelene a možno ich prijať na rôznych peer-och. Tretia sa objaví, keď sa šablóna kopíruje z vydania, ktoré pozná len jednu z nich. Pohľad do registra vyrieši všetky tri rýchlejšie než odhad postavený na názve služby.

Berte štyri riadky ako príklady z registra IANA, nie ako samotný register. Keď číslo nezodpovedá ničomu známemu, vyhľadajte ho, kým okolo neho postavíte politiku.

AFI 25 nesie dva nesúvisiace formáty NLRI

Obe rodiny Layer 2 sedia pod AFI 25 a podobnosť tam končí. NLRI pre VPLS v RFC 4761 section 3.2.2 nesie dĺžku, rozlišovač trasy, VE ID, posun bloku VE, veľkosť bloku VE a základňu labelov, ktoré spolu pomenúvajú koncový bod pseudowire a jeho label. EVPN si AFI 25 ponecháva a prechádza na SAFI 70, kde je payload typ trasy: automatické zisťovanie Ethernetu, oznámenie MAC/IP, inkluzívny multicast, Ethernet segment, IP prefix. Preto ten istý bajtový posun znamená v oboch rodinách niečo iné. Parser napísaný pre jednu číta druhú bez sťažnosti a produkuje nezmysel. Dvojica je jediné varovanie, že interpretácia je nesprávna.

Pole, ktoré v jednej rodine znamená posun bloku VE, nemá v druhej náprotivok a trasa oznámenia MAC/IP existuje len v EVPN. Citovať atribút, akoby platil pre obe, je spôsob, akým revízia zachytenej prevádzky ide zle.

Keď vám niekto podá zachytenú prevádzku alebo tabuľku výrobcu, opýtajte sa, ktorej rodine atribút patrí. Potom potvrďte, že prijímajúca implementácia podporuje túto rodinu, nie názov služby z datasheetu. Dve platformy môžu obe tvrdiť podporu VPLS a pritom implementovať rôzne signalizačné rodiny. Dvojica ich oddeľuje; štítok produktu nie.

Vlastná adresová rodina relácie je samostatná otázka

VPN-IPv6 sa bežne oznamuje cez reláciu, ktorej TCP spojenie beží cez IPv4, a to je podporovaný návrh, nie porucha. Čítanie len súhrnu relácie preto nič nehovorí o tom, ktoré VPN rodiny si peer-ovia vymieňajú.

Rodina NLRI, transportná rodina a preposielacia rodina sú tri nezávislé rozhodnutia. Router môže so svojím peer-om hovoriť IPv4, prijať dostupnosť VPN-IPv6 a nainštalovať trasu, ktorej next hop je adresa IPv6 dostupná cestou, ktorú ste nezamýšľali. Každá vrstva potrebuje vlastné potvrdenie. Lokality hlásiace nedostupné destinácie IPv6, kým oznámenia vyzerajú správne, zvyčajne stratili rozlíšenie next hopu, nie vyjednávanie rodín.

Otestujte adresovú rodinu relácie samostatne, potom rodiny, ktoré nesie, potom to, čo jadro dokáže preposlať. Držať tri veci oddelene bráni častej chybnej diagnóze, keď sa správne oznámenie číta ako dôkaz, že IPv6 funguje od konca do konca. Dokazuje len to, že jeden peer povedal druhému o prefixe.

Vyjednané, prijaté, importované, nainštalované

Pre jednu očakávanú trasu musia platiť štyri stavy v poradí a každý je pozorovateľný. Rodina musí byť vyjednaná s týmto peer-om, trasa musí doraziť, route target ju musí importovať do zamýšľaného kontextu a next hop sa musí vyriešiť, aby sa trasa nainštalovala. Preskočenie prvého stavu robí ostatné tri nezodpovedateľnými, pretože nevyjednaná rodina nevytvára žiadne trasy na prehliadnutie. Na platformách v štýle Cisco sú súhrny rodín a schopnosti pre jednotlivých peer-ov samostatné príkazy.

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

Vyjednávanie sa ukazuje vo výmene schopností vypísanej pre každého peer-a, a nadviazaná relácia bez uvedenej rodiny nenesie nič z toho, čo ste žiadali. Import rozhodujú route targety nesené ako rozšírené komunity, takže správna dvojica s nesprávne napísaným targetom nechá tabuľku prázdnu. Inštalácia potom závisí od vyriešenia next hopu v prijímajúcom kontexte, čo môže zlyhať, kým každé oznámenie vyzerá dokonale.

Dátovú rovinu potvrďte nakoniec, pretože trasa v tabuľke je tvrdenie, nie doručenie. Tie isté štyri stavy platia pre každú rodinu; menia sa len príkazy a názvy tabuliek.

Čo dvojica rodín nikdy nedokazuje

Správne prečítanie dvojice vám povie, ako interpretovať smerovacie informácie, ktoré nasledujú, a to je celé tvrdenie. Nič nehovorí o dostupnosti, nič o politike a nič o zdraví dátovej roviny. Zámena oboch plodí sebavedomé tvrdenia o sieti, ktorú nikto neoveril. Nesúlad route targetu a pokazený next hop vyzerajú z dvojice samotnej rovnako. Dvojica je návod na čítanie, nikdy rozsudok.

Keď eskalujete, dajte dvojicu, route target a vyriešený next hop do tej istej poznámky. Ďalší inžinier má potom tri nezávislé veci na testovanie namiesto názvu služby na reinterpretáciu. Ak chýba vyjednávanie, vidia to hneď, nesprávny target nechá import viditeľne chýbať a nevyriešený next hop nechá trasu prítomnú, ale nepoužiteľnú.