Varför din L2VPN ignorerar den RSVP-TE LSP du just byggt

Två ingenjörer kan lämna samma underhållsfönster övertygade om att den nya vägen är i drift, och båda ha fel av olika skäl. Den ene byggde LSP:n och antog att tjänsten skulle följa. Den andre lät tjänsten vara och antog att inget hade ändrats. En pseudowire använder alltid bara den transport som dess peer-adress löses till i det ögonblicket, så den verkliga frågan är vad den upplösningen ger nu, och de två designerna svarar olika på det.

En etikett namnger en tjänst, den andra flyttar ett paket

Pseudowire-etiketten, signalerad av riktad LDP som beskrivs i RFC 4447, talar om för den mottagande leverantörskanten vilken anslutningskrets som ska ta emot ramen. Den säger ingenting om hur ramen kom dit. Etiketten under tillhör transporten, och den stacken byggs av det som annonserade nåbarhet för peer-loopbacken, vare sig det är LDP, RSVP-TE eller en segmentroutad väg. Eftersom olika protokoll signalerar de två lagren, kan det ena vara friskt medan det andra är inaktuellt. Den separationen är hela källan till förvirringen.

Det är värt att säga rakt ut: pseudowiren väljer inte LSP:n. Den lämnar en ram till transporten, och transporten avgör utifrån destinationsadressen den fått.

Det är också därför en ren ping genom den nya LSP:n bevisar så lite. LSP:n kan vara uppe, etiketterad och bära andra tjänster medan din pseudowire fortfarande löses genom ett annat nästa hopp. Tills du läser bindningen har de två fakta inget med varandra att göra.

Alternativ A: fäst pseudowiren vid en vald transport

Att fästa betyder att göra tjänstens transportupplösning deterministisk. Beroende på plattform tar det formen av en tunnelvalspolicy, en explicit transportändpunkt på tjänsten, eller en routningspolicy som skriver om nästa hopp för peer-adressen. Alla tre gör samma sak under ytan: de tvingar upplösningen av en destination till en specifik LSP. Det är det som gör resultatet granskningsbart efteråt.

Priset är omfattningen. En policy som matchar på en peer-adress påverkar varje tjänst som pekar mot den peeren, inte bara den pseudowire du hade i tankarna.

Reservvägen förtjänar ett beslut före ändringsfönstret, inte under det. Om den fästa LSP:n faller låter du antingen tjänsten gå på en annan godkänd väg eller så låter du den stanna. En policy som tyst faller tillbaka på en väg som bryter mot ett latens- eller disjunkthetskrav har förvandlat ett rent avbrott till något som är mycket svårare att förklara för någon.

Alternativ B: låt IGP välja och se vad som händer

Att lämna tjänsten ifred är en legitim design, och ofta den bättre. Pseudowiren följer samma upplösning som all annan trafik till peer-loopbacken, så den ärver IGP-konvergens, prefixundertryckning och den redundans som kärnan redan erbjuder. Färre policyer innebär färre platser där en inaktuell matchning kan gömma sig. Bytet är att du inte längre styr vilken väg tjänsten tar, bara att det finns en väg.

Equal-cost multipath skärper det bytet mer än det verkar vid första anblicken. Hashning sker per flöde, så två samtal inom en pseudowire kan avgå på olika yttre etiketter.

Läs den installerade vidarebefordran innan du litar på någon av dem

Börja med peer-adressen i stället för tjänsten. På Junos skriver show route 203.0.113.1 detail ut valt nästa hopp och etikettoperationen, och show route table mpls.0 mappar den inkommande etiketten till den operationen. På IOS XR ger show mpls l2transport vc 100 detail pseudowire-status tillsammans med den pålagda stacken.

Bekräfta den LSP som transporten faktiskt använder, inte den som ditt designdokument namnger. traceroute mpls ipv4 203.0.113.1/32 på IOS XR går igenom den etikettväxlade vägen och listar etiketterna och de utgående gränssnitten längs den, vilket är det närmaste man kommer att själv titta på vägen. Upprepa sedan övningen från den avlägsna leverantörskanten, eftersom returriktningen löses oberoende och asymmetri är vanlig efter en delvis policyutrullning. En väg som är rätt åt ena hållet och fel åt det andra är värre än en som är jämnt fel, eftersom hälften av dina tester kommer att passera.

Spara bevisen tillsammans med tjänsteposten: peer-adress, nästa hopp, yttre etikett och datumet du kontrollerade. Routningspolicyer åldras dåligt, och ingen minns vilken som gällde för två kvartal sedan.

Välj efter felmod, inte efter preferens

Fästning passar tjänster med ett krav som IGP:n inte kan uttrycka, och team som kan underhålla policyn genom varje ändring. Att lämna det till IGP:n passar tjänster som måste överleva varje enskilt fel utan en människa i loopen.

Den avgörande frågan är vad en fel väg kostar dig. Om en tjänst på fel LSP bara presterar lite sämre, låt IGP:n avgöra och lägg kraften på övervakning. Om en fel väg bryter ett kontrakt, ett revisionsfynd eller ett disjunkthetskrav, fäst den och skriv ner reservvägen. Testa sedan reservvägen, eftersom en otestad reserv är ett antagande och inte en plan. Hur som helst, läs om den installerade bindningen efter varje ändring i kärnan, och behandla en pseudowire som kom upp som bevis för inget annat än att signaleringen fungerar.