Junos L2VPN: primero hay que acertar con el contrato de conexión del cliente

Antes de tocar un pseudowire, sigue una trama de cliente hasta el PE y mira dónde se supone que debe aterrizar. El puerto físico la clasifica en una unidad lógica, esa unidad lleva una encapsulación y la unidad está enlazada a un servicio. Tres decisiones separadas, tres formas separadas de equivocarse. La mayoría de los casos escalados como fallo de señalización son en realidad una trama clasificada en una unidad que nadie configuró para ese servicio. Así que empieza en la conexión y avanza hacia fuera.

Deja por escrito el contrato de trama

Registra el contrato antes de elegir cualquier configuración: sin etiqueta, una etiqueta de servicio o una pila. Añade la MTU que enviará el cliente y el tratamiento de etiquetas esperado en cada dirección, porque son propiedades negociadas y no preferencias locales. Un número de unidad es solo un identificador y no dice nada sobre qué tramas aceptará la interfaz.

Escríbelo en la nota de servicio y no en un comentario de ticket. Quien depure esto dentro de seis meses leerá la nota. No leerá el ticket.

Ajusta la encapsulación al contrato

Un servicio con una sola etiqueta suele usar una encapsulación de circuito VLAN como vlan-ccc, mientras que las tramas sin etiqueta necesitan la forma simple de circuito Ethernet y una pila necesita la variante extendida que entiende dos etiquetas. En una plataforma que admite encapsulación de servicio por unidad, una sola interfaz física puede alojar varias a la vez, lo que resulta cómodo y también es la forma en que una trama acaba en la unidad equivocada. Donde la guía de tu plataforma pide family ccc, configúralo como parte de la conexión completa en lugar de atornillarlo a una interfaz enrutada. La guía de encapsulación enumera qué tipos de conexión imponen qué requisitos.

No añadas una sentencia family a cada interfaz por precaución. La configuración que hace funcionar un circuito puede hacer que el siguiente acepte tramas que su cliente nunca envía.

Vincula la conexión al servicio correcto

Una VPN de capa 2 señalizada por BGP, un circuito señalizado por LDP y los demás servicios admitidos tienen cada uno su propia configuración de enlace de interfaz y de señalización, y no son intercambiables. Mezclar el estilo de conexión de uno con la señalización de otro produce un circuito que informa de un par y nunca transporta una trama.

Compara el extremo lejano con el extremo cercano en lugar de revisar cualquiera de ellos de forma aislada: dirección del par, identificador de servicio, acuerdo de encapsulación, expectativa de control word y presupuesto de tamaño. El subyacente MPLS puede estar perfectamente sano mientras la conexión falta o está clasificada en otro sitio, por eso una prueba que solo mira el subyacente no demuestra nada aquí.

Verifica con la trama, no con el estado

Lee los contadores de la interfaz local mientras el cliente envía tráfico, luego el estado del servicio y después confirma que la trama que llega es la que se acordó, incluida su etiqueta. Una conexión reparada entrega esa trama; un cambio de estado por sí solo no demuestra nada.

Donde tengas autorización para capturar, mira la trama en ambos sentidos. La asimetría de etiquetas es fácil de pasar por alto en una vista de estado y evidente en una captura. Esa asimetría también explica las quejas que funcionan en un sentido y fallan en el otro.

Después, déjalo por escrito

Registra cuatro valores en la nota de servicio: contrato, encapsulación, unidad y enlace de servicio. Esos cuatro son lo que necesita un ingeniero nuevo y lo que una revisión de configuración rara vez explicita.

Cuando el circuito se rompa dentro de seis meses, esa nota será la diferencia entre un cuarto de hora de trabajo y volver a deducir todo el diseño desde una configuración en marcha. Añade la fecha de la última verificación, para que la nota diga también cuánto ha envejecido.