O túnel RSVP-TE está activo, pero o L3VPN do cliente non ten ruta
O transporte e o servizo son decisións distintas. Lea a pila de etiquetas, comprobe por separado a resolución do seguinte salto e a conexión da VRF, e logo probe un fluxo real do cliente.
Dous equipos poden ter razón á vez cando o cliente informa de que a VPN está caída e o equipo de transporte informa de que o túnel está ben. Un LSP con enxeñaría de tráfico e unha MPLS L3VPN responden a preguntas distintas: un move paquetes etiquetados polo núcleo, o outro decide a que contexto de encamiñamento pertence un paquete. Cando se confunden, a discusión dá voltas porque cada parte mide un obxecto diferente e ambas as medicións son válidas.
Transporte activo e servizo caído é un estado normal
Un LSP pode estar establecido, transportar tráfico e ser visible en todos os sistemas de monitorización, mentres o servizo do cliente segue sen poder usarse. Nada desa combinación é contraditorio, porque o túnel non opina sobre se existe un prefixo remoto, se unha política de importación o aceptou ou se o circuíto de conexión deixa pasar tramas.
O síntoma que adoita revelar a confusión é asimétrico: os ping desde o loopback do PE funcionan mentres un host da LAN do cliente non recibe nada, ou ao revés. Anote que enderezos funcionaron antes de formular unha teoría. Cando advirta que está a probar dous obxectos distintos, o seguinte paso é ler a pila de etiquetas en lugar de discutir que gráfico é correcto. Dous enderezos, dous propietarios e normalmente dúas persoas distintas que cada unha cre que a outra rompeu algo.
Lea a pila como dúas responsabilidades
A etiqueta inferior pertence ao servizo e a etiqueta superior pertence ao camiño. O RFC 4364 describe a secuencia con claridade: primeiro imponse a etiqueta da ruta VPN, despois ese paquete etiquetado tunelízase cara ao seguinte salto BGP, que é onde un túnel de enxeñaría de tráfico empurra a súa propia etiqueta por riba.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
No PE remoto, a etiqueta de servizo selecciona o tratamento, que pode ser unha consulta de VRF ou unha decisión de conexión. Esa etiqueta non pode intercambiarse por outra que só atravese o núcleo, e as dúas non son intercambiables aínda que ambas aparezan na mesma pila e na mesma interface.
Que demostra o éxito de RSVP e que non
RSVP-TE establece LSP con encamiñamento explícito, con ou sen reservas de recursos, o que é unha garantía concreta e útil sobre o camiño que segue un paquete polo núcleo. Non é unha afirmación sobre as rutas do cliente, e un nome de túnel configurado non é unha ruta en absoluto.
Tampouco a presenza de RSVP ofrece unha promesa de rendemento de extremo a extremo. A reserva de ancho de banda nun LSP non di nada sobre o circuíto de conexión, a liña de acceso do propio cliente nin o comportamento das colas no bordo remoto. Tratalo como unha garantía produce respostas seguras a preguntas que ninguén fixo. Se o requisito é realmente un compromiso de ancho de banda, hai que montalo a partir das pezas que de verdade o impoñen, e o LSP é só a metade desa cadea.
Comprobe en orde e logo detéñase
Traballe desde o transporte cara a fóra e detéñase no primeiro paso que falle, porque cada paso posterior supón que os anteriores se mantiveron. Primeiro confirme que o LSP está establecido e que a entrada de reenvío do prefixo do servizo apunta realmente a el. Despois confirme que a ruta VPN existe na táboa correcta, que o seu enlace de etiqueta está presente e que a política de importación a aceptou. Despois confirme a conexión: a interface, a encapsulación e, cando corresponda, o identificador de VLAN que pertence a ese contrato.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERA sintaxe dos comandos varía segundo a plataforma, así que trate esas catro liñas como as catro preguntas e non como un script. A parte importante é que cada unha interroga un obxecto distinto, e iso é o que fai que un fallo sinale un propietario concreto.
Siga unha solicitude permitida e conserve as boas probas
Termine con unha soa solicitude real do cliente, permitida pola política, e a súa resposta. Un fluxo funcional de extremo a extremo resolve máis que unha páxina de lecturas de contadores, e exercita a combinación en lugar de cada peza por separado.
Cando falle unha etapa posterior, conserve a observación correcta do LSP en lugar de reconstruír o transporte. Reconstruír un túnel que funciona non pode reparar un prefixo remoto ausente, unha conexión de VRF equivocada ou unha regra de acceso ao destino, e destrúe a proba que en primeiro lugar lle dixo que o transporte estaba san.