Hvorfor en Junos L2VPN viser en etikett, men ikke videresender noe

Kunderapporter kommer inn og sier at L2VPN-forbindelsen er Up, tilkoblingen er oppe, og ingen ramme passerer. Statuslysene er ærlige; rammen klassifiseres i en tjeneste som ikke har noen brukbar videresendingstilstand i den fjerne enden. I en BGP-signaliseret punkt-til-punkt L2VPN tilhører den første beslutningen tilkoblingen og ikke et ruteoppslag. Kunderammen ankommer på et logisk grensesnitt, og det grensesnittet navngir forbindelsen og dermed det fjerne stedet. Alt etter dette er etikett-videresendingstilstand bygget fra det peerne annonserte.

Rammen gjør aldri et ruteoppslag

Signaliseringen forberedte tilstanden; behandlingen per pakke er et etikettoppslag på en forbindelse som allerede er valgt. Derfor er spørsmålet om hvorfor en rute mangler, det gale spørsmålet, og det skjuler de to verdiene som betyr noe: tilkoblingens forbindelse og tjenesteetiketten den bruker.

Det forklarer også asymmetrien i innsatsen. Konfigurasjonsgjennomgang forteller hva som burde vært installert, mens forbindelsesvisningen forteller hva som faktisk ble utledet, og bare den andre overlever et avvik i etikettblokken.

To etiketter, to retninger

Hver PE tildeler en etikettblokk lokalt, annonserer basen og størrelsen, og peerne legger til en forskyvning for å utlede etiketten for et bestemt sted. Tildelingene er derfor lokalt betydningsfulle: to PE-er kan bruke forskjellige baser og forskjellige blokkstørrelser for samme tjeneste. Les forbindelsen fra begge ender før du endrer noe. En blokk som ble dimensjonert én etikett for liten, ser nøyaktig ut som en forbindelse som aldri installeres.

show l2vpn connections instance CUST-A extensive

I den utskriften er den innkommende etiketten den denne PE-en tildelte og ba peeren sin bruke, mens den utgående etiketten er peerens tildeling som denne PE-en skyver. Å lese de to baklengs er den klassiske feilen, og den sender deg på jakt etter en verdi som aldri skulle ha dukket opp på denne siden. Forbindelsesreferansen dokumenterer feltene ved siden av etikettene, inkludert sted, status og blokkinformasjon.

Hva etikettoppslaget beviser

Når du har den innkommende verdien, er det lokale oppslaget én kommando:

show route label 160042

Den utskriften bør vise en l2vpn-oppføring med neste hopp, og etikettoperasjonen forteller om rammen skyves, byttes eller poppes før den forlater. Hvis den ikke viser noe, ble tjenestetilstanden aldri installert selv om forbindelsen viser Up, og avviket ligger i signaliseringen og ikke i transporten.

Følg én ramme

En enkelt pakke som skyves inn i tilkoblingen, avgjør mer enn noen konfigurasjonsgjennomgang. Tjenesteetikettens rute bør peke på transport-LSP-en mot den fjerne PE-en, og de to etikettene bør samsvare med verdiene peeren rapporterte. Når transporten er sunn og tjenesteetiketten er feil, når rammen riktig ruter og forkastes der, og det er derfor tellerne i den fjerne enden ser tomme ut mens tellerne i den nære enden ser travle ut.

Kontroller tilkoblingens innkapsling, kontrollord-innstillingen og MTU-en samtidig, fordi dette er forhandlede egenskaper og ikke oppførsel per hopp.

Hold tjenestemodellene fra hverandre

VPLS lærer MAC-adresser, og EVPN annonserer endepunkter, mens en punkt-til-punkt L2VPN ikke gjør noen av delene, så deres rammeutvelgelsesprosedyrer er ikke utskiftbare selv om de rir på den samme BGP- og MPLS-infrastrukturen. Å løfte et feilsøkingstrinn fra én modell til en annen gir selvsikre konklusjoner uten grunnlag.

For en manglende sti, registrer begge peerenes forbindelsesstatus, tilkoblingen, begge etikettretningene, innkapslingen, kontrollord-innstillingen og MTU-en. Den registreringen forbinder det annonserte med det videresendingsplanet faktisk gjør, som er den eneste lenken som betyr noe, og det er også det den neste ingeniøren vil spørre om.