Junos L2VPN: få kundens anslutningskontrakt rätt först

Innan du rör en pseudowire ska du följa en kundram in i PE:n och se var den ska landa. Den fysiska porten klassificerar den i en logisk enhet, den enheten bär en inkapsling, och enheten är bunden till en tjänst. Tre separata beslut, tre separata sätt att göra fel. De flesta ärenden som eskaleras som signaleringsfel är i själva verket en ram som klassificeras i en enhet som ingen har konfigurerat för den tjänsten. Börja alltså vid anslutningen och arbeta utåt.

Skriv ner ramkontraktet

Registrera kontraktet innan du väljer någon konfiguration: otaggad, en tjänstetagg eller en stapel. Lägg till den MTU som kunden kommer att skicka och den tagghantering som förväntas i varje riktning, eftersom det är förhandlade egenskaper och inte lokala preferenser. Ett enhetsnummer är bara en identifierare och säger inget om vilka ramar gränssnittet tar emot.

Skriv det i tjänstanteckningen och inte i en ärendekommentar. Den som felsöker det här om sex månader läser anteckningen. Ärendet läser hen inte.

Matcha inkapslingen mot kontraktet

En tjänst med en enda tagg använder vanligen en VLAN-circuit-inkapsling som vlan-ccc, medan otaggade ramar behöver den enkla Ethernet-circuit-formen och en stapel behöver den utökade varianten som förstår två taggar. På en plattform som stöder tjänsteinkapsling per enhet kan ett fysiskt gränssnitt hysa flera samtidigt, vilket är praktiskt och också är hur en ram hamnar i fel enhet. Där guiden för din plattform family ccc, konfigurerar du det som en del av den kompletta anslutningen i stället för att skruva fast det på ett routat gränssnitt. Den inkapslingsguiden listar vilka anslutningstyper som ställer vilka krav.

Lägg inte till en family-sats på varje gränssnitt som en försiktighetsåtgärd. Den konfiguration som får en circuit att fungera kan få nästa att ta emot ramar som dess kund aldrig skickar.

Bind anslutningen till rätt tjänst

En BGP-signalerad Layer 2 VPN, en LDP-signalerad circuit och de övriga tjänster som stöds har var sin gränssnittsbindning och signaleringskonfiguration, och de är inte utbytbara. Blandar du den enas anslutningsstil med den andras signalering får du en circuit som rapporterar en peer och aldrig bär en ram.

Jämför den bortre änden med den nära änden i stället för att granska någon av dem isolerat: peeradress, tjänsteidentifierare, inkapslingsöverenskommelse, förväntan på control word och storleksbudget. MPLS-underlaget kan vara helt friskt medan anslutningen saknas eller är klassificerad någon annanstans; därför bevisar ett test som bara tittar på underlaget ingenting här.

Verifiera med ramen, inte med statusen

Läs de lokala gränssnittsräknarna medan kunden skickar trafik, läs sedan tjänstestatusen och bekräfta därefter att ramen som anländer är den överenskomna ramen, inklusive dess tagg. En reparerad anslutning levererar den ramen; en statusändring i sig är inte bevis för något.

Där du har behörighet att fånga trafik ska du titta på ramen i båda riktningarna. Taggasymmetri är lätt att missa i en statusvy och uppenbar i en fångst. Den asymmetrin förklarar också klagomål som fungerar i en riktning och misslyckas i den andra.

Skriv sedan ner det

Registrera fyra värden i tjänstanteckningen: kontrakt, inkapsling, enhet och tjänstebindning. De fyra är vad en ny ingenjör behöver och vad en konfigurationsgranskning sällan säger uttryckligen.

När circuiten går sönder om sex månader är den anteckningen skillnaden mellan en kvarts arbete och att härleda hela designen igen från en körande konfiguration. Lägg till datumet då du senast verifierade den, så att anteckningen också säger hur inaktuell den är.