Por qué tu L2VPN ignora el RSVP-TE LSP que acabas de crear

Dos ingenieros pueden salir de la misma ventana de mantenimiento convencidos de que la nueva ruta está en servicio, y ambos equivocarse por motivos distintos. Uno construyó el LSP y supuso que el servicio lo seguiría. El otro dejó el servicio en paz y supuso que nada había cambiado. Un pseudowire solo usa el transporte al que resuelve la dirección de su par en ese momento, así que la pregunta real es qué produce esa resolución ahora, y los dos diseños responden de forma distinta.

Una etiqueta nombra un servicio, la otra mueve un paquete

La etiqueta del pseudowire, señalizada por LDP dirigido como se describe en RFC 4447, indica al borde de proveedor receptor qué circuito de acceso debe recibir la trama. No dice nada sobre cómo llegó allí la trama. La etiqueta de debajo pertenece al transporte, y esa pila la construye lo que haya anunciado alcanzabilidad para el loopback del par, ya sea LDP, RSVP-TE o una ruta segmentada. Como protocolos distintos señalizan las dos capas, una puede estar sana mientras la otra está obsoleta. Esa separación es toda la fuente de la confusión.

Conviene decirlo sin rodeos: el pseudowire no elige el LSP. Entrega una trama al transporte, y el transporte decide a partir de la dirección de destino que se le dio.

También por eso un ping limpio por el nuevo LSP demuestra tan poco. El LSP puede estar activo, etiquetado y transportando otros servicios mientras tu pseudowire sigue resolviéndose por otro siguiente salto. Hasta que leas la vinculación, esos dos hechos no tienen relación.

Opción A: fijar el pseudowire a un transporte elegido

Fijar significa hacer determinista la resolución de transporte del servicio. Según la plataforma, eso toma la forma de una política de selección de túnel, un punto final de transporte explícito en el servicio, o una política de ruta que reescribe el siguiente salto para la dirección del par. Las tres hacen lo mismo por debajo: fuerzan la resolución de un destino hacia un LSP concreto. Eso es lo que hace el resultado auditable después.

El coste es el alcance. Una política que coincide en una dirección de par afecta a todos los servicios apuntados a ese par, no solo al pseudowire que tenías en mente.

El respaldo merece una decisión antes de la ventana de cambio, no durante ella. Si el LSP fijado cae, o dejas que el servicio vaya por otra ruta aprobada o lo dejas detenerse. Una política que vuelve en silencio a una ruta que incumple un requisito de latencia o de disjunción ha convertido una interrupción limpia en algo mucho más difícil de explicar a cualquiera.

Opción B: dejar que el IGP elija y observar qué pasa

Dejar el servicio en paz es un diseño legítimo, y a menudo el mejor. El pseudowire sigue la misma resolución que cualquier otro tráfico hacia el loopback del par, así que hereda la convergencia del IGP, la supresión de prefijos y la redundancia que el núcleo ya ofrezca. Menos políticas significan menos lugares donde esconderse una coincidencia obsoleta. El intercambio es que ya no controlas qué ruta toma el servicio, solo que exista alguna ruta.

El multipath de igual coste agudiza ese intercambio más de lo que parece a primera vista. El hashing es por flujo, así que dos conversaciones dentro de un pseudowire pueden salir por etiquetas externas distintas.

Lee el reenvío instalado antes de confiar en cualquiera de los dos

Empieza por la dirección del par en lugar del servicio. En Junos, show route 203.0.113.1 detail imprime el siguiente salto seleccionado y la operación de etiqueta, y show route table mpls.0 asigna la etiqueta entrante a esa operación. En IOS XR, show mpls l2transport vc 100 detail da el estado del pseudowire junto con la pila impuesta.

Confirma el LSP que el transporte usa realmente, no el que nombra tu documento de diseño. traceroute mpls ipv4 203.0.113.1/32 en IOS XR recorre la ruta conmutada por etiquetas y enumera las etiquetas y las interfaces de salida a lo largo de ella, que es lo más parecido a mirar la ruta tú mismo. Luego repite el ejercicio desde el borde de proveedor remoto, porque la dirección de retorno se resuelve de forma independiente y la asimetría es habitual tras un despliegue parcial de políticas. Una ruta correcta en un sentido y equivocada en el otro es peor que una equivocada de forma uniforme, porque la mitad de tus pruebas pasarán.

Guarda la evidencia con el registro del servicio: dirección del par, siguiente salto, etiqueta externa y la fecha en que lo comprobaste. Las políticas de ruta envejecen mal, y nadie recuerda cuál estaba vigente hace dos trimestres.

Elige por modo de fallo, no por preferencia

Fijar encaja en servicios con un requisito que el IGP no puede expresar, y en equipos que pueden mantener la política en cada cambio. Dejarlo al IGP encaja en servicios que deben sobrevivir a cualquier fallo único sin una persona en el bucle.

La pregunta decisiva es qué te cuesta una ruta equivocada. Si un servicio en el LSP equivocado solo rinde un poco peor, deja que el IGP decida y gasta el esfuerzo en monitorización. Si una ruta equivocada rompe un contrato, un hallazgo de auditoría o un requisito de disjunción, fíjala y escribe el respaldo. Luego prueba el respaldo, porque un respaldo no probado es una suposición y no un plan. En cualquier caso, relee la vinculación instalada tras cualquier cambio en el núcleo, y trata un pseudowire que ha levantado como prueba de nada salvo de que la señalización funciona.