Waarom 'n Junos L2VPN 'n label wys maar niks aanstuur nie

Klantverslae kom in wat sê die L2VPN-verbinding is Op, die aanhegting is op, en geen raam kruis nie. Die statusligte is eerlik; die raam word in 'n diens geklassifiseer wat aan die ander kant geen bruikbare aanstuurtoestand het nie. In 'n BGP-geseinde punt-tot-punt L2VPN behoort die eerste besluit aan die aanhegting eerder as aan 'n roetesoektog. Die klantraam kom op 'n logiese koppelvlak aan, en daardie koppelvlak noem die verbinding en dus die afgeleë terrein. Alles daarna is label-aanstuurtoestand wat uit die adverteer van die eweknieë gebou is.

Die raam doen nooit 'n roetesoektog nie

Seinbereiding het die toestand voorberei; per-pakket verwerking is 'n labelsoektog op 'n verbinding wat reeds gekies is. Om te vra waarom 'n roete ontbreek, is dus die verkeerde vraag, en dit verberg die twee waardes wat saak maak: die aanhegting se verbinding en die dienslabel wat dit gebruik.

Dit verduidelik ook die ongelykheid in moeite. Konfigurasie-hersiening vertel jou wat geïnstalleer moes gewees het, terwyl die verbindingaansig vertel wat werklik afgelei is, en net die tweede een oorleef 'n labelblok-wanpassing.

Twee labels, twee rigtings

Elke PE ken plaaslik 'n labelblok toe, adverteer sy basis en grootte, en sy eweknieë voeg 'n offset by om die label vir 'n bepaalde terrein af te lei. Toekennings is dus plaaslik betekenisvol: twee PE's kan verskillende basisse en verskillende blokgroottes vir dieselfde diens gebruik. Lees die verbinding van beide kante voordat jy iets verander. 'n Blok wat een label te klein geskaal is, lyk presies soos 'n verbinding wat nooit installeer nie.

show l2vpn connections instance CUST-A extensive

In daardie uitset is die inkomende label die een wat hierdie PE toegeken en aan sy eweknie gesê het om te gebruik, terwyl die uitgaande label die eweknie se toekenning is wat hierdie PE instoot. Om die twee omgekeerd te lees is die klassieke fout, en dit stuur jou op soek na 'n waarde wat nooit aan hierdie kant moes verskyn het nie. Die verbindingverwysing dokumenteer die velde langs die labels, insluitend terrein, status en blokinligting.

Wat die labelsoektog bewys

Sodra jy die inkomende waarde het, is die plaaslike soektog een opdrag:

show route label 160042

Daardie uitset behoort 'n l2vpn-inskrywing met 'n volgende sprong te wys, en die labelbewerking vertel jou of die raam ingestoot, omgeruil of uitgehaal word voordat dit vertrek. As dit niks wys nie, is die dienstoestand nooit geïnstalleer nie, selfs al wys die verbinding Op, en die verskil lê in seine eerder as in vervoer.

Volg een raam

Een enkele pakket wat in die aanhegting ingestoot word, beslis meer as enige konfigurasie-hersiening. Die dienslabelroete behoort na die vervoer-LSP na die afgeleë PE te wys, en die twee labels behoort ooreen te stem met die waardes wat die eweknie gerapporteer het. Wanneer vervoer gesond is en die dienslabel verkeerd is, bereik die raam die regte router en word daar weggegooi, en dit is waarom die ander kant se tellers leeg lyk terwyl die nabye kant se tellers besig lyk.

Kontroleer die aanhegting se inkapseling, die beheerwoord-instelling en die MTU op dieselfde tyd, want dit is onderhandelde eienskappe eerder as per-hop gedrag.

Hou die diensmodelle apart

VPLS leer MAC-adresse en EVPN adverteer eindpunte, terwyl 'n punt-tot-punt L2VPN nie een van die twee doen nie, so hul raamkeuseprosedures is nie uitruilbaar nie ondanks dieselfde BGP- en MPLS-infrastruktuur. Om 'n probleemoplossingsstap van een model na 'n ander te lig, lewer selfversekerde gevolgtrekkings sonder grond.

Vir 'n ontbrekende pad, teken beide eweknieë se verbindingstatus aan, die aanhegting, beide labelrigtings, die inkapseling, die beheerwoord-instelling en die MTU. Daardie rekord verbind wat geadverteer is met wat die aanstuurvlak werklik doen, wat die enigste skakel is wat saak maak, en dit is ook wat die volgende ingenieur sal vra.