Hvorfor L2VPN-en din ignorerer RSVP-TE LSP-en du nettopp bygde

To ingeniører kan forlate samme vedlikeholdsvindu overbevist om at den nye veien er i drift, og begge kan ta feil av ulike grunner. Den ene bygde LSP-en og antok at tjenesten ville følge. Den andre lot tjenesten være og antok at ingenting var endret. En pseudowire bruker alltid bare den transporten som peer-adressen dens løses til i det øyeblikket, så det egentlige spørsmålet er hva den oppløsningen gir nå, og de to designene svarer ulikt på det.

Én etikett navngir en tjeneste, den andre flytter en pakke

Pseudowire-etiketten, signalert av målrettet LDP som beskrevet i RFC 4447, forteller den mottakende leverandørkanten hvilken tilkoblingskrets som skal motta rammen. Den sier ingenting om hvordan rammen kom dit. Etiketten under tilhører transporten, og den stakken bygges av det som annonserte nåbarhet for peer-loopbacken, enten det er LDP, RSVP-TE eller en segmentrutet vei. Fordi ulike protokoller signalerer de to lagene, kan det ene være sunt mens det andre er utdatert. Den separasjonen er hele kilden til forvirringen.

Det er verdt å si rett ut: pseudowiren velger ikke LSP-en. Den leverer en ramme til transporten, og transporten avgjør ut fra destinasjonsadressen den har fått.

Det er også derfor en ren ping gjennom den nye LSP-en beviser så lite. LSP-en kan være oppe, etikettmerket og bære andre tjenester mens pseudowiren din fortsatt løses gjennom et annet neste hopp. Inntil du leser bindingen, er de to fakta uten sammenheng.

Alternativ A: fest pseudowiren til en valgt transport

Festing betyr å gjøre tjenestens transportoppløsning deterministisk. Avhengig av plattformen tar det form av en tunnelvalgspolicy, et eksplisitt transportendepunkt på tjenesten, eller en rutepolicy som skriver om neste hopp for peer-adressen. Alle tre gjør det samme under overflaten: de tvinger oppløsningen av én destinasjon over på en bestemt LSP. Det er det som gjør resultatet reviderbart etterpå.

Prisen er omfanget. En policy som matcher på en peer-adresse påvirker hver tjeneste som peker mot den peeren, ikke bare pseudowiren du hadde i tankene.

Reserveveien fortjener en beslutning før endringsvinduet, ikke under det. Hvis den festede LSP-en faller, lar du enten tjenesten gå på en annen godkjent vei eller du lar den stoppe. En policy som stille faller tilbake på en vei som bryter en latens- eller disjunkthetsbetingelse, har gjort et rent avbrudd til noe som er mye vanskeligere å forklare for noen.

Alternativ B: la IGP-en velge og se hva som skjer

Å la tjenesten være er et legitimt design, og ofte det bedre. Pseudowiren følger samme oppløsning som all annen trafikk til peer-loopbacken, så den arver IGP-konvergens, prefikssuppresjon og den redundansen kjernen allerede tilbyr. Færre policyer betyr færre steder der en utdatert match kan gjemme seg. Byttet er at du ikke lenger styrer hvilken vei tjenesten tar, bare at det finnes en vei.

Like-kostnads multipath skjerper det byttet mer enn det ser ut ved første øyekast. Hasjing er per flyt, så to samtaler i én pseudowire kan gå ut på ulike ytre etiketter.

Les den installerte videresendingen før du tror på noen av dem

Start med peer-adressen i stedet for tjenesten. På Junos skriver show route 203.0.113.1 detail ut det valgte neste hoppet og etikettoperasjonen, og show route table mpls.0 mapper den innkommende etiketten til den operasjonen. På IOS XR gir show mpls l2transport vc 100 detail pseudowire-tilstanden sammen med den pålagte stakken.

Bekreft LSP-en som transporten faktisk bruker, ikke den designdokumentet ditt navngir. traceroute mpls ipv4 203.0.113.1/32 på IOS XR går gjennom den etikettsvitsjede veien og lister etikettene og de utgående grensesnittene langs den, som er det nærmeste du kommer å se veien selv. Gjenta deretter øvelsen fra den fjerne leverandørkanten, fordi returretningen løses uavhengig og asymmetri er vanlig etter en delvis policy-utrulling. En vei som er riktig én vei og feil den andre er verre enn en som er jevnt feil, fordi halvparten av testene dine vil passere.

Oppbevar bevisene sammen med tjenesteposten: peer-adresse, neste hopp, ytre etikett og datoen du kontrollerte. Rutepolicyer eldes dårlig, og ingen husker hvilken som gjaldt for to kvartaler siden.

Velg etter feilmodus, ikke etter preferanse

Festing passer for tjenester med en betingelse IGP-en ikke kan uttrykke, og for team som kan vedlikeholde policyen gjennom hver endring. Å overlate det til IGP-en passer for tjenester som må overleve enhver enkelt feil uten et menneske i loopen.

Det avgjørende spørsmålet er hva en feil vei koster deg. Hvis en tjeneste på feil LSP bare yter litt dårligere, la IGP-en bestemme og bruk innsatsen på overvåking. Hvis en feil vei bryter en kontrakt, et revisjonsfunn eller et disjunkthetskrav, fest den og skriv ned reserveveien. Test deretter reserveveien, fordi en utestet reserve er en antakelse og ikke en plan. Uansett, les den installerte bindingen på nytt etter enhver endring i kjernen, og behandle en pseudowire som kom opp som bevis for ingenting annet enn at signaleringen virker.