Por que o teu L2VPN ignora o RSVP-TE LSP que acabas de construír

Dous enxeñeiros poden saír da mesma ventá de mantemento convencidos de que a nova ruta está en servizo, e ambos equivocarse por motivos distintos. Un construíu o LSP e supuxo que o servizo o seguiría. O outro deixou o servizo tranquilo e supuxo que nada cambiara. Un pseudowire só usa o transporte ao que resolve o enderezo do seu par nese momento, así que a pregunta real é que produce esa resolución agora, e os dous deseños responden de xeito diferente.

Unha etiqueta nomea un servizo, a outra move un paquete

A etiqueta do pseudowire, sinalizada por LDP dirixido como se describe en RFC 4447, indica á beira de provedor receptora que circuíto de acoplamento debe recibir a trama. Non di nada sobre como chegou alí a trama. A etiqueta de abaixo pertence ao transporte, e esa pila constrúea o que anunciase alcanzabilidade para o loopback do par, sexa LDP, RSVP-TE ou unha ruta encamiñada por segmentos. Como protocolos distintos sinalizan as dúas capas, unha pode estar sa e a outra obsoleta. Esa separación é toda a fonte da confusión.

Paga a pena dicilo sen rodeos: o pseudowire non elixe o LSP. Entrega unha trama ao transporte, e o transporte decide a partir do enderezo de destino que se lle deu.

Tamén por iso un ping limpo pola nova LSP demostra tan pouco. A LSP pode estar activa, etiquetada e transportando outros servizos mentres o teu pseudowire aínda resolve por outro seguinte salto. Ata que leas a vinculación, eses dous feitos non teñen relación.

Opción A: fixar o pseudowire a un transporte elixido

Fixar significa facer determinista a resolución de transporte do servizo. Segundo a plataforma, iso toma a forma dunha política de selección de túnel, un punto final de transporte explícito no servizo, ou unha política de ruta que reescribe o seguinte salto para o enderezo do par. As tres fan o mesmo por baixo: forzan a resolución dun destino cara a un LSP concreto. Iso é o que fai o resultado auditable despois.

O custo é o alcance. Unha política que coincide nun enderezo de par afecta todos os servizos apuntados a ese par, non só o pseudowire que tiñas en mente.

A reserva merece unha decisión antes da ventá de cambio, non durante. Se o LSP fixado cae, ou deixas que o servizo vaia por outra ruta aprobada ou deixas que se deteña. Unha política que retrocede en silencio a unha ruta que incumpre un requisito de latencia ou de disxunción converteu unha interrupción limpa en algo moito máis difícil de explicar a calquera.

Opción B: deixar que o IGP elixa e observar que pasa

Deixar o servizo tranquilo é un deseño lexítimo, e a miúdo o mellor. O pseudowire segue a mesma resolución que calquera outro tráfico cara ao loopback do par, así que herda a converxencia do IGP, a supresión de prefixos e a redundancia que o núcleo xa ofreza. Menos políticas significan menos lugares onde se agachar unha coincidencia obsoleta. O intercambio é que xa non controlas que ruta toma o servizo, só que exista algunha ruta.

O multipath de igual custo agudiza ese intercambio máis do que parece a primeira vista. O hashing é por fluxo, así que dúas conversacións dentro dun pseudowire poden saír por etiquetas externas distintas.

Le o reenvío instalado antes de confiar en calquera dos dous

Comeza polo enderezo do par en lugar do servizo. En Junos, show route 203.0.113.1 detail imprime o seguinte salto seleccionado e a operación de etiqueta, e show route table mpls.0 asigna a etiqueta entrante a esa operación. En IOS XR, show mpls l2transport vc 100 detail dá o estado do pseudowire xunto coa pila imposta.

Confirma o LSP que o transporte usa realmente, non o que nomea o teu documento de deseño. traceroute mpls ipv4 203.0.113.1/32 en IOS XR percorre a ruta conmutada por etiquetas e lista as etiquetas e as interfaces de saída ao longo dela, que é o máis parecido a mirar a ruta ti mesmo. Despois repite o exercicio desde a beira de provedor remota, porque a dirección de retorno se resolve de forma independente e a asimetría é habitual tras unha implantación parcial de políticas. Unha ruta correcta nun sentido e equivocada no outro é peor que unha equivocada de forma uniforme, porque a metade das túas probas pasarán.

Garda a evidencia co rexistro do servizo: enderezo do par, seguinte salto, etiqueta externa e a data na que o comprobaches. As políticas de ruta envellecen mal, e ninguén lembra cal estaba vixente hai dous trimestres.

Elixe por modo de fallo, non por preferencia

Fixar acae para servizos cun requisito que o IGP non pode expresar, e para equipos que poden manter a política en cada cambio. Deixalo ao IGP acae para servizos que deben sobrevivir a calquera fallo único sen unha persoa no bucle.

A pregunta decisiva é que che custa unha ruta equivocada. Se un servizo no LSP equivocado só rende un pouco peor, deixa que o IGP decida e gasta o esforzo en monitorización. Se unha ruta equivocada rompe un contrato, un achado de auditoría ou un requisito de disxunción, fíxaa e escribe a reserva. Despois proba a reserva, porque unha reserva non probada é unha suposición e non un plan. En calquera caso, relê a vinculación instalada tras calquera cambio no núcleo, e trata un pseudowire que levantou como proba de nada agás de que a sinalización funciona.