Waarom je L2VPN de RSVP-TE LSP die je net hebt gebouwd negeert

Twee ingenieurs kunnen hetzelfde onderhoudsvenster verlaten in de overtuiging dat het nieuwe pad in dienst is, en beiden ongelijk hebben om verschillende redenen. De een bouwde de LSP en ging ervan uit dat de dienst zou volgen. De ander liet de dienst met rust en ging ervan uit dat er niets was veranderd. Een pseudowire gebruikt altijd alleen het transport waar zijn peer-adres op dat moment naar resolveert, dus de echte vraag is wat die resolutie nu oplevert, en de twee ontwerpen antwoorden daar verschillend op.

Het ene label benoemt een dienst, het andere verplaatst een pakket

Het pseudowire-label, gesignaleerd door gerichte LDP zoals beschreven in RFC 4447, vertelt de ontvangende provider-edge welk aansluitcircuit het frame moet ontvangen. Het zegt niets over hoe het frame daar kwam. Het label eronder hoort bij het transport, en die stack wordt gebouwd door wat bereikbaarheid aankondigde voor de peer-loopback, of dat nu LDP, RSVP-TE of een segment-gerouteerd pad is. Omdat verschillende protocollen de twee lagen signaleren, kan de ene gezond zijn terwijl de andere verouderd is. Die scheiding is de hele bron van de verwarring.

Het is de moeite waard het ronduit te zeggen: de pseudowire kiest de LSP niet. Hij overhandigt een frame aan het transport, en het transport beslist op basis van het bestemmingsadres dat het kreeg.

Dat is ook waarom een schone ping over de nieuwe LSP zo weinig bewijst. De LSP kan omhoog zijn, gelabeld en andere diensten dragen terwijl je pseudowire nog steeds via een andere volgende hop resolveert. Tot je de binding leest, hebben die twee feiten niets met elkaar te maken.

Optie A: pin de pseudowire vast op een gekozen transport

Vastpinnen betekent de transportresolutie van de dienst deterministisch maken. Afhankelijk van het platform neemt dat de vorm aan van een tunnelselectiebeleid, een expliciet transporteindpunt op de dienst, of een routebeleid dat de volgende hop voor het peer-adres herschrijft. Alle drie doen onder de oppervlakte hetzelfde: ze dwingen de resolutie van één bestemming naar een specifieke LSP. Dat maakt het resultaat achteraf controleerbaar.

De prijs is de reikwijdte. Een beleid dat op een peer-adres matcht, raakt elke dienst die naar die peer wijst, niet alleen de pseudowire die je in gedachten had.

De terugval verdient een beslissing vóór het wijzigingsvenster, niet erdoor. Als de vastgepinde LSP wegvalt, laat je de dienst ofwel over een ander goedgekeurd pad lopen of je laat hem stoppen. Een beleid dat stilletjes terugvalt op een pad dat een latentie- of disjunctie-eis schendt, heeft een schone storing veranderd in iets dat veel moeilijker aan iemand uit te leggen is.

Optie B: laat de IGP kiezen en kijk wat er gebeurt

De dienst met rust laten is een legitiem ontwerp, en vaak het betere. De pseudowire volgt dezelfde resolutie als al het andere verkeer naar de peer-loopback, dus erft hij IGP-convergentie, prefix-onderdrukking en de redundantie die de kern al biedt. Minder beleid betekent minder plaatsen waar een verouderde match zich kan verstoppen. De ruil is dat je niet langer bepaalt welk pad de dienst neemt, alleen dat er een pad bestaat.

Equal-cost multipath scherpt die ruil meer aan dan het op het eerste gezicht lijkt. Hashing is per flow, dus twee gesprekken binnen één pseudowire kunnen op verschillende buitenste labels vertrekken.

Lees de geïnstalleerde doorsturing voordat je een van beide vertrouwt

Begin met het peer-adres in plaats van de dienst. Op Junos drukt show route 203.0.113.1 detail de gekozen volgende hop en de labelbewerking af, en show route table mpls.0 mapt het inkomende label op die bewerking. Op IOS XR geeft show mpls l2transport vc 100 detail de pseudowire-status samen met de opgelegde stack.

Bevestig de LSP die het transport werkelijk gebruikt, niet degene die je ontwerpdocument noemt. traceroute mpls ipv4 203.0.113.1/32 op IOS XR loopt het labelschakelpad af en somt de labels en uitgaande interfaces erlangs op, wat het dichtst bij het zelf bekijken van het pad komt. Herhaal de oefening daarna vanaf de verre provider-edge, want de retourrichting resolveert onafhankelijk en asymmetrie is gebruikelijk na een gedeeltelijke beleidsuitrol. Een pad dat in de ene richting juist is en in de andere fout, is erger dan een dat gelijkmatig fout is, omdat de helft van je tests zal slagen.

Bewaar het bewijs bij het dienstrecord: peer-adres, volgende hop, buitenste label en de datum waarop je het controleerde. Routebeleid veroudert slecht, en niemand herinnert zich welk beleid twee kwartalen geleden van kracht was.

Kies op faalmodus, niet op voorkeur

Vastpinnen past bij diensten met een eis die de IGP niet kan uitdrukken, en bij teams die het beleid bij elke wijziging kunnen onderhouden. Het aan de IGP overlaten past bij diensten die elke afzonderlijke storing moeten overleven zonder mens in de lus.

De beslissende vraag is wat een verkeerd pad je kost. Als een dienst op de verkeerde LSP alleen iets slechter presteert, laat de IGP beslissen en steek de inspanning in monitoring. Als een verkeerd pad een contract, een auditbevinding of een disjunctie-eis breekt, pin het dan vast en schrijf de terugval op. Test daarna de terugval, want een ongeteste terugval is een aanname en geen plan. Hoe dan ook, herlees de geïnstalleerde binding na elke wijziging aan de kern, en behandel een pseudowire die omhoog kwam als bewijs voor niets anders dan dat de signalering werkt.