AFI a SAFI: přečtěte dvojici dřív než název služby

Můžete sledovat, jak relace naskočí, jak se objeví trasa, a přesto číst špatnou službu. Dvojice čísel na začátku každého oznámení, identifikátor adresové rodiny a identifikátor navazující adresové rodiny, rozhoduje, který parser čte payload a která tabulka drží výsledek. Spletete-li dvojici, importní politika, shoda route targetu i hledání next hopu běží proti struktuře, kterou nikdo neoznámil. Procházka níže začíná u této dvojice a končí u výsledku předávání.

Které tabulce trasa patří, rozhodují dvě čísla

Dvojice se objevuje dvakrát: uvnitř multiprotokolové capability, kde mluvčí oznamuje rodinu, a před každým NLRI, které tato rodina nese. Dělá to z ní vlastnost trasy, ne nastavení na zdrojovém boxu. Výrobci ji tisknou jako název typu Address family VPNv4 Unicast a formulace se mezi verzemi posouvá, zatímco čísla zůstávají na místě.

Čtyři kódování pokrývají téměř každý podnikový případ: 1 se 128 pro VPN-IPv4 s MPLS labelem, 2 se 128 pro ekvivalent IPv6, 25 se 65 pro VPLS signalizované BGP a 25 se 70 pro EVPN. První chyba je předpokládat, že každá služba Layer 2 žije za 25 se 65, což skrývá EVPN. Druhá je brát obě IP rodiny jako jednu rodinu s delší adresou, když se vyjednávají odděleně a lze je přijmout na různých peerech. Třetí se objeví, když se šablona kopíruje z verze, která zná jen jednu z nich. Pohled do registru vyřeší všechny tři rychleji než odhad postavený na názvu služby.

Berte čtyři řádky jako příklady z registru IANA, ne jako registr samotný. Když číslo neodpovídá ničemu známému, vyhledejte ho, než kolem něj postavíte politiku.

AFI 25 nese dva nesouvisející formáty NLRI

Obě rodiny Layer 2 sedí pod AFI 25 a podobnost tam končí. NLRI pro VPLS v RFC 4761 section 3.2.2 nese délku, rozlišovač trasy, VE ID, offset bloku VE, velikost bloku VE a základnu labelů, což dohromady pojmenovává koncový bod pseudowire a jeho label. EVPN si AFI 25 ponechává a přechází na SAFI 70, kde je payload typ trasy: automatické zjištění Ethernetu, oznámení MAC/IP, inkluzivní multicast, Ethernet segment, IP prefix. Stejný bajtový offset tak v obou rodinách znamená různé věci. Parser napsaný pro jednu čte druhou bez stížnosti a produkuje nesmysl. Dvojice je jediné varování, že interpretace je špatná.

Pole, které v jedné rodině znamená offset bloku VE, nemá v druhé protějšek a trasa oznámení MAC/IP existuje jen v EVPN. Citovat atribut, jako by platil pro obě, je způsob, jak se revize zachyceného provozu pokazí.

Když vám někdo předá zachycený provoz nebo tabulku výrobce, zeptejte se, ke které rodině atribut patří. Pak potvrďte, že přijímající implementace podporuje tuto rodinu, ne název služby z datasheetu. Dvě platformy mohou obě tvrdit podporu VPLS, přitom implementují různé signalizační rodiny. Dvojice je odděluje; štítek produktu ne.

Vlastní adresová rodina relace je samostatná otázka

VPN-IPv6 se běžně oznamuje přes relaci, jejíž TCP spojení běží přes IPv4, a to je podporovaný návrh, ne závada. Čtení pouhého souhrnu relace proto nic neříká o tom, které VPN rodiny si peerové vyměňují.

Rodina NLRI, transportní rodina a předávací rodina jsou tři nezávislá rozhodnutí. Router může se svým peerem mluvit IPv4, přijmout dostupnost VPN-IPv6 a nainstalovat trasu, jejíž next hop je adresa IPv6 dostupná cestou, kterou jste nezamýšleli. Každá vrstva potřebuje vlastní potvrzení. Lokality hlásící nedostupné destinace IPv6, zatímco oznámení vypadají správně, obvykle ztratily rozlišení next hopu, ne vyjednávání rodin.

Otestujte adresovou rodinu relace samostatně, pak rodiny, které nese, pak co jádro dokáže předat. Držet tři věci oddělené brání časté chybné diagnóze, kdy se správné oznámení čte jako důkaz, že IPv6 funguje od konce ke konci. Dokazuje jen, že jeden peer řekl druhému o prefixu.

Vyjednáno, přijato, importováno, instalováno

Pro jednu očekávanou trasu musí platit čtyři stavy v pořadí a každý je pozorovatelný. Rodina musí být s tímto peerem vyjednaná, trasa musí dorazit, route target ji musí importovat do zamýšleného kontextu a next hop se musí přeložit, aby se trasa nainstalovala. Přeskočení prvního stavu činí ostatní tři nezodpověditelnými, protože nevyjednaná rodina nevytváří žádné trasy k prohlédnutí. Na platformách ve stylu Cisco jsou souhrny rodin a capability pro jednotlivé peery samostatné pří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ávání se ukazuje ve výměně capability vypsané pro každý peer a navázaná relace bez uvedené rodiny nenese nic z toho, co jste žádali. Import rozhodují route targety nesené jako rozšířené komunity, takže správná dvojice se špatně napsaným targetem nechá tabulku prázdnou. Instalace pak závisí na rozlišení next hopu v přijímajícím kontextu, což může selhat, zatímco každé oznámení vypadá perfektně.

Datovou rovinu potvrďte nakonec, protože trasa v tabulce je tvrzení, ne doručení. Stejné čtyři stavy platí pro každou rodinu; mění se jen příkazy a názvy tabulek.

Co dvojice rodin nikdy nedokazuje

Správné přečtení dvojice vám řekne, jak interpretovat směrovací informace, které následují, a to je celé tvrzení. Nic neříká o dostupnosti, nic o politice a nic o zdraví datové roviny. Záměna obojího plodí sebejistá tvrzení o síti, kterou nikdo neověřil. Nesoulad route targetu a rozbitý next hop vypadají z pouhé dvojice stejně. Dvojice je návod ke čtení, nikdy rozsudek.

Když eskalujete, dejte dvojici, route target a přeložený next hop do stejné poznámky. Další inženýr pak má tři nezávislé věci k otestování místo názvu služby k přeinterpretování. Chybí-li vyjednávání, uvidí to hned, špatný target nechá import viditelně chybět a nepřeložený next hop nechá trasu přítomnou, ale nepoužitelnou.