Junos L2VPN: få kundens tilkoblingskontrakt riktig først

Før du rører en pseudowire, følg én kunderamme inn i PE-en og se hvor den skal lande. Den fysiske porten klassifiserer den i en logisk enhet, den enheten bærer en innkapsling, og enheten er bundet til en tjeneste. Tre separate beslutninger, tre separate måter å gjøre det feil på. De fleste sakene som eskaleres som signaleringsfeil, er faktisk en ramme som klassifiseres i en enhet ingen har konfigurert for den tjenesten. Start derfor ved tilkoblingen og arbeid utover.

Skriv ned rammekontrakten

Registrer kontrakten før du velger noen konfigurasjon: uten tag, én tjenestetag eller en stabel. Legg til MTU-en kunden kommer til å sende og taggbehandlingen som forventes i hver retning, for det er forhandlede egenskaper og ikke lokale preferanser. Et enhetsnummer er bare en identifikator og sier ingenting om hvilke rammer grensesnittet vil godta.

Skriv det i tjenestenotatet og ikke i en sakskommentar. Den som feilsøker dette om seks måneder, leser notatet. Saken leser vedkommende ikke.

Tilpass innkapslingen til kontrakten

En tjeneste med én tag bruker vanligvis en VLAN-circuit-innkapsling som vlan-ccc, mens utaggede rammer trenger den enkle Ethernet-circuit-formen, og en stabel trenger den utvidede varianten som forstår to tagger. På en plattform som støtter tjenesteinnkapsling per enhet, kan ett fysisk grensesnitt huse flere samtidig, noe som er praktisk og også er hvordan en ramme havner i feil enhet. Der guiden for plattformen din family ccc, konfigurerer du det som en del av den komplette tilkoblingen i stedet for å bolte det på et rutet grensesnitt. Den innkapslingsveiledningen viser hvilke tilkoblingstyper som stiller hvilke krav.

Ikke legg til en family-setning på hvert grensesnitt som en forsiktighetsregel. Konfigurasjonen som får én circuit til å virke, kan få den neste til å godta rammer kunden aldri sender.

Bind tilkoblingen til riktig tjeneste

En BGP-signalisert Layer 2 VPN, en LDP-signalisert circuit og de andre støttede tjenestene har hver sin grensesnittbinding og signaleringskonfigurasjon, og de er ikke utskiftbare. Blander du tilkoblingsstilen til den ene med signaleringen til den andre, får du en circuit som rapporterer en peer og aldri bærer en ramme.

Sammenlign den fjerne enden med den nære enden i stedet for å gjennomgå en av dem isolert: peeradresse, tjenesteidentifikator, innkapslingsavtale, forventning til control word og størrelsesbudsjett. MPLS-underlaget kan være helt friskt mens tilkoblingen mangler eller er klassifisert et annet sted; derfor beviser en test som bare ser på underlaget ingenting her.

Verifiser med rammen, ikke med statusen

Les de lokale grensesnitttellerne mens kunden sender trafikk, les deretter tjenestestatusen, og bekreft så at rammen som ankommer er den avtalte rammen, inkludert taggen. En reparert tilkobling leverer den rammen; en statusendring alene er ikke bevis for noe.

Der du har tillatelse til å ta opp trafikk, se på rammen i begge retninger. Taggasymmetri er lett å overse i en statusvisning og tydelig i en opptak. Den asymmetrien forklarer også klager som virker i én retning og feiler i den andre.

Skriv det så ned

Registrer fire verdier i tjenestenotatet: kontrakt, innkapsling, enhet og tjenestebinding. De fire er det en ny ingeniør trenger, og det en konfigurasjonsgjennomgang sjelden sier eksplisitt.

Når circuiten ryker om seks måneder, er det notatet forskjellen mellom en kvarters jobb og å utlede hele designet på nytt fra en kjørende konfigurasjon. Legg til datoen du sist verifiserte det, slik at notatet også sier hvor utdatert det er.