Hvorfor en Junos L2VPN viser en label, men ikke videresender noget

Kunderapporter kommer ind og siger, at L2VPN-forbindelsen er Up, at tilslutningen er oppe, og at ingen ramme passerer. Statuslysene er ærlige; rammen klassificeres i en tjeneste, der ikke har nogen brugbar videresendelsestilstand i den fjerne ende. I en BGP-signaleret punkt-til-punkt L2VPN tilhører den første beslutning tilslutningen og ikke et ruteopslag. Kunderammen ankommer på en logisk grænseflade, og den grænseflade navngiver forbindelsen og dermed det fjerne sted. Alt derefter er label-videresendelsestilstand bygget ud fra det, fællerne annoncerede.

Rammen laver aldrig et ruteopslag

Signaliseringen forberedte tilstanden; behandlingen per pakke er et labelopslag på en forbindelse, der allerede er valgt. Derfor er spørgsmålet, hvorfor en rute mangler, det forkerte spørgsmål, og det skjuler de to værdier, der betyder noget: tilslutningens forbindelse og den tjenestelabel, den bruger.

Det forklarer også asymmetrien i indsatsen. Konfigurationsgennemgang fortæller, hvad der burde være installeret, mens forbindelsesvisningen fortæller, hvad der faktisk blev udledt, og kun den anden overlever en uoverensstemmelse i labelblokken.

To labels, to retninger

Hver PE tildeler en labelblok lokalt, annoncerer dens base og størrelse, og dens fæller tilføjer et offset for at udlede labelen for et bestemt sted. Tildelinger er derfor lokalt betydningsfulde: to PE'er kan bruge forskellige baser og forskellige blokstørrelser til den samme tjeneste. Læs forbindelsen fra begge ender, før du ændrer noget. En blok, der blev dimensioneret en label for lille, ser præcis ud som en forbindelse, der aldrig installeres.

show l2vpn connections instance CUST-A extensive

I det output er den indgående label den, som denne PE tildelte og bad sin fælle om at bruge, mens den udgående label er fællens tildeling, som denne PE skubber. At læse de to bagvendt er den klassiske fejl, og det sender dig på jagt efter en værdi, der aldrig skulle have vist sig på denne side. Forbindelsesreferencen dokumenterer felterne ved siden af labelene, herunder sted, status og blokinformation.

Hvad labelopslaget beviser

Når du har den indgående værdi, er det lokale opslag én kommando:

show route label 160042

Det output bør vise en l2vpn-post med et næste hop, og labeloperationen fortæller, om rammen skubbes, ombyttes eller poppes, før den forlader. Hvis det ikke viser noget, blev tjenestetilstanden aldrig installeret, selvom forbindelsen viser Up, og uoverensstemmelsen ligger i signaleringen og ikke i transporten.

Følg én ramme

En enkelt pakke skubbet ind i tilslutningen afgør mere end nogen konfigurationsgennemgang. Tjenestelabelruten bør pege på transport-LSP'en mod den fjerne PE, og de to labels bør svare til de værdier, fællen rapporterede. Når transporten er sund, og tjenestelabelen er forkert, når rammen den rigtige router og kasseres der, og det er derfor, den fjerne ends tællere ser tomme ud, mens den nære ends ser travle ud.

Kontrollér tilslutningens indkapsling, kontrolordsindstillingen og MTU'en på samme tid, fordi det er forhandlede egenskaber og ikke adfærd for hvert hop.

Hold tjenestemodellerne adskilt

VPLS lærer MAC-adresser, og EVPN annoncerer endepunkter, mens en punkt-til-punkt L2VPN ikke gør nogen af delene, så deres rammeudvælgelsesprocedurer kan ikke udskiftes, selvom de rider på den samme BGP- og MPLS-infrastruktur. At løfte et fejlfindingsskridt fra én model til en anden giver selvsikre konklusioner uden grundlag.

For en manglende sti skal du registrere begge fællers forbindelsesstatus, tilslutningen, begge labelretninger, indkapslingen, kontrolordsindstillingen og MTU'en. Den registrering forbinder det annoncerede med det, videresendelsesplanet faktisk gør, hvilket er det eneste led, der betyder noget, og det er også det, den næste ingeniør vil spørge om.