AFI en SAFI: lees die paar voordat jy die diensnaam lees
AFI 25 met SAFI 65 is nie dieselfde diens as AFI 25 met SAFI 70 nie. Lees die paar, en kontroleer dan die familie-uitruiling, die roete en die aanstuurresultaat.
Jy kan sien hoe 'n sessie opkom, 'n roete sien verskyn, en tog die verkeerde diens lees. Die paar getalle aan die begin van elke aankondiging, die adresfamilie-identifiseerder en die opvolgende adresfamilie-identifiseerder, bepaal watter ontleder die vrag lees en watter tabel die resultaat hou. Kry die paar verkeerd en die invoerbeleid, die roeteteiken-ooreenstemming en die volgende-sprong-soektog loop almal teen 'n struktuur wat niemand aangekondig het nie. Die wandeling hieronder begin by daardie paar en eindig by die aanstuurresultaat.
Twee getalle bepaal in watter tabel die roete hoort
Die paar verskyn twee keer: binne die multiprotokol-vermoë, waar 'n spreker 'n familie aankondig, en voor elke NLRI wat daardie familie dra. Dit maak dit 'n eienskap van die roete eerder as 'n instelling op die oorsprongkas. Verkopers druk dit as 'n naam soos Address family VPNv4 Unicast, en die bewoording verskuif tussen vrystellings terwyl die getalle bly staan.
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
Vier enkoderings dek byna elke ondernemingsgeval: 1 met 128 vir MPLS-gemerkte VPN-IPv4, 2 met 128 vir die IPv6-ekwivalent, 25 met 65 vir BGP-aangeduide VPLS, en 25 met 70 vir EVPN. Die eerste fout is om te aanvaar elke Layer 2-diens lê agter 25 met 65, wat EVPN verberg. Die tweede is om die twee IP-families as een familie met 'n langer adres te behandel, terwyl hulle afsonderlik onderhandel word en op verskillende eweknieë aanvaar kan word. 'n Derde verskyn wanneer 'n sjabloon gekopieer word uit 'n vrystelling wat net een van hulle ken. 'n Opsoek in die register beslis al drie vinniger as 'n raaiskoot op die diensnaam.
Behandel die vier rye as voorbeelde uit die IANA-register, nie die register self nie. Wanneer 'n getal niks ooreenstem met wat jy herken nie, soek dit op voordat jy 'n beleid daarom bou.
AFI 25 dra twee onverwante NLRI-formate
Albei Layer 2-families sit onder AFI 25, en die ooreenkoms stop daar. Die VPLS-NLRI in RFC 4761 section 3.2.2 dra 'n lengte, 'n roete-onderskeier, 'n VE ID, 'n VE-blokoffset, 'n VE-blokgrootte en 'n etiketbasis, wat saam 'n pseudodraad-eindpunt en sy etiket benoem. EVPN behou AFI 25 en skuif na SAFI 70, waar die vrag 'n roetesoort is: Ethernet-outo-ontdekking, MAC/IP-aankondiging, inklusiewe multicast, Ethernet-segment, IP-voorvoegsel. Dieselfde greepoffset beteken dus verskillende dinge in die twee families. 'n Ontleder wat vir een geskryf is, lees die ander sonder klag en lewer onsin. Die paar is die enigste waarskuwing dat die interpretasie verkeerd is.
'n Veld wat in een familie VE-blokoffset beteken, het geen eweknie in die ander nie, en die MAC/IP-aankondigingsroete bestaan net in EVPN. Om 'n eienskap aan te haal asof dit op albei van toepassing is, is hoe 'n opname-oorsig verkeerd loop.
Wanneer iemand jou 'n opname of 'n verkopertabel gee, vra aan watter familie die eienskap behoort. Bevestig dan dat die ontvangende implementering daardie familie ondersteun, nie die diensnaam op die datablad nie. Twee platforms kan albei VPLS-ondersteuning beweer terwyl hulle verskillende seiningsfamilies implementeer. Die paar skei hulle; die produknaam nie.
Die sessie se eie adresfamilie is 'n aparte vraag
VPN-IPv6 word gereeld aangekondig oor 'n sessie waarvan die TCP-verbinding oor IPv4 loop, en dit is ondersteunde ontwerp, nie 'n fout nie. Om net die sessieopsomming te lees sê dus niks oor watter VPN-families die eweknieë uitruil nie.
NLRI-familie, vervoerfamilie en aanstuurfamilie is drie onafhanklike besluite. 'n Roeteerder kan IPv4 met sy eweknie praat, VPN-IPv6-bereikbaarheid aanvaar, en 'n roete installeer waarvan die volgende sprong 'n IPv6-adres is wat bereikbaar is deur 'n pad wat jy nie bedoel het nie. Elke laag het sy eie bevestiging nodig. Terreine wat onbereikbare IPv6-bestemmings rapporteer terwyl aankondigings korrek lyk, het gewoonlik volgende-sprong-resolusie verloor, nie familie-onderhandeling nie.
Toets die sessie se adresfamilie op sy eie, dan die families wat dit dra, dan wat die kern kan aanstuur. Om die drie apart te hou verhoed die algemene misdiagnose waar 'n korrekte aankondiging gelees word as bewys dat IPv6 van punt tot punt werk. Dit bewys net dat een eweknie vir 'n ander van 'n voorvoegsel vertel het.
Onderhandel, ontvang, ingevoer, geïnstalleer
Vir een verwagte roete moet vier toestande in volgorde geld, en elkeen is waarneembaar. Die familie moet met daardie eweknie onderhandel wees, die roete moet arriveer, 'n roeteteiken moet dit in die beoogde konteks invoer, en die volgende sprong moet resolveer sodat die roete installeer. Om die eerste toestand oor te slaan maak die ander drie onbeantwoordbaar, want 'n ononderhandelde familie lewer geen roetes om te ondersoek nie. Op Cisco-agtige platforms is die familie-opsommings en die per-eweknie-vermoëns aparte opdragte.
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address familyOnderhandeling verskyn in die vermoë-uitruiling wat per eweknie gedruk word, en 'n gevestigde sessie met geen familie gelys nie dra niks van wat jy gevra het nie. Invoer word beslis deur roeteteikens wat as uitgebreide gemeenskappe gedra word, so 'n korrekte paar met 'n verkeerd getikte teiken laat die tabel leeg. Installasie hang dan daarvan af dat die volgende sprong in die ontvangende konteks resolveer, wat kan misluk terwyl elke aankondiging perfek lyk.
Bevestig die datavlak laaste, want 'n roete in die tabel is 'n bewering, nie 'n aflewering nie. Dieselfde vier toestande geld vir elke familie; net die opdragte en tabelname verander.
Wat 'n familiepaar nooit bewys nie
Om die paar korrek te lees sê jou hoe om die roeteringinligting wat volg te interpreteer, en dit is die hele bewering. Dit sê niks oor bereikbaarheid, niks oor beleid, en niks oor die gesondheid van die datavlak nie. Om die twee te verwar lewer selfversekerde stellings oor 'n netwerk wat niemand geverifieer het nie. 'n Roeteteiken-wanpassing en 'n gebroke volgende sprong lyk identies van die paar alleen. Die paar is 'n leesinstruksie, nooit 'n uitspraak nie.
Wanneer jy eskaleer, sit die paar, die roeteteiken en die geresolveerde volgende sprong in dieselfde nota. Die volgende ingenieur het dan drie onafhanklike dinge om te toets in plaas van 'n diensnaam om te herinterpreteer. As onderhandeling ontbreek, sien hulle dit dadelik; 'n verkeerde teiken laat die invoer sigbaar afwesig; en 'n onopgeloste volgende sprong laat die roete teenwoordig maar onbruikbaar.