Solución de problemas de VPN de capa 3
Diagnóstico de problemas comunes de VPN de capa 3
Problema
Descripción
Para solucionar problemas en la configuración de VPN de capa 3, inicie en un extremo del enrutador VPN (el enrutador local de borde de cliente [BRC] ) y siga las rutas hacia el otro extremo de la VPN (el enrutador BRC remoto).
Solución
Los siguientes pasos para la resolución de problemas deben ayudarlo a diagnosticar problemas comunes:
Si configuró un protocolo de enrutamiento entre el borde del proveedor local (PE) y los enrutadores BRC, compruebe que el emparejamiento y la adyacencia están completamente operativos. Cuando haga esto, asegúrese de especificar el nombre de la instancia de enrutamiento. Por ejemplo, para comprobar OSPF adyacencias, ingrese el
show ospf neighbor instance routing-instance-namecomando en el enrutador de PE.Si el emparejamiento y la adyacencia no son completamente operativos, compruebe la configuración del protocolo de enrutamiento en el enrutador BRC y compruebe la configuración del protocolo de enrutamiento para la instancia de enrutamiento VPN asociada en el enrutador de PE.
Compruebe que los enrutadores BRC y PE locales puedan hacer ping entre sí.
Para comprobar que el enrutador BRC local puede hacer ping en la interfaz VPN en el enrutador de PE local, utilice un comando con el siguiente formato, especificando la dirección IP o el nombre del
pingenrutador de PE:user@host> ping (ip-address | host-name)
Para comprobar que el enrutador de PE local puede hacer ping en el enrutador de BRC, utilice un comando con el siguiente formato, especificando la dirección IP o el nombre del enrutador BRC, el nombre de la interfaz utilizada para la VPN y la dirección IP de origen (la dirección local) en los paquetes de solicitud de echo
pingsaliente:user@host> ping ip-address interface interface local echo-address
A menudo, el emparejamiento o adyacencia entre los enrutadores de PE local BRC y local deben subir antes de que un
pingcomando se haga exitoso. Para comprobar que un vínculo está operativo en una configuración de laboratorio, elimine la interfaz del enrutamiento y reenvío VPN (VRF) eliminando la instrucción del nivel jerárquico y confirmando de nuevo lainterface[edit routing-instance routing-instance-name]configuración. Al hacer esto, se elimina la interfaz de la VPN. Luego vuelva a intentar ping el comando. Si el comando se realiza correctamente, vuelva a configurar la interfaz en la VPN y compruebe de nuevo la configuración del protocolo de enrutamiento en los enrutadores BRC y PE locales.En el enrutador de PE local, compruebe que las rutas del enrutador de BRC local se encuentran en la tabla VRF ( routing-instance-name .inet.0):
user@host> show route table routing-instance-name.inet.0 <detail>
En el ejemplo siguiente se muestran las entradas de la tabla de enrutamiento. Aquí, la dirección de circuito cerrado del enrutador de BRC es y el protocolo de enrutamiento entre el PE y los enrutadores
10.255.14.155/32BRC es BGP. La entrada se parece a cualquier anuncio BGP común.10.255.14.155/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Nexthop: 192.168.197.141 via fe-1/0/0.0, selected State: <Active Ext> Peer AS: 1 Age: 45:46 Task: BGP_1.192.168.197.141+179 Announcement bits (2): 0-BGP.0.0.0.0+179 1-KRT AS path: 1 I Localpref: 100 Router ID: 10.255.14.155Si las rutas del enrutador BRC local no están presentes en la tabla de enrutamiento VRF, compruebe que el enrutador BRC esté anunciando rutas al enrutador de PE. Si se utiliza enrutamiento estático entre los enrutadores BRC y PE, asegúrese de que estén configuradas las rutas estáticas adecuadas.
En un enrutador de PE remoto, compruebe que las rutas del enrutador de BRC local estén presentes en la tabla de enrutamiento bgp.l3vpn.0:
user@host> show route table bgp.l3vpn.0 extensive 10.255.14.175:3:10.255.14.155/32 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.255.14.175:3 Source: 10.255.14.175 Nexthop: 192.168.192.1 via fe-1/1/2.0, selected label-switched-path vpn07-vpn05 Push 100004, Push 100005(top) State: <Active Int Ext> Local AS: 69 Peer AS: 69 Age: 15:27 Metric2: 338 Task: BGP_69.10.255.14.175+179 AS path: 1 I Communities: target:69:100 BGP next hop: 10.255.14.175 Localpref: 100 Router ID: 10.255.14.175 Secondary tables: VPN-A.inet.0El resultado del
show route table bgp.l3vpn.0 extensivecomando contiene la siguiente información específica de la VPN:En el nombre de prefijo (la primera línea del resultado), el diferenciador de ruta se agrega al prefijo de ruta del enrutador de BRC local. Dado que el diferenciador de ruta es único en Internet, la concatenación del diferenciador de ruta y el prefijo IP proporciona entradas de enrutamiento VPN-IP únicas versión 4 (IPv4).
El
Route Distinguishercampo enumera el diferenciador de ruta por separado de la dirección VPN-IPv4.El
label-switched-pathcampo muestra el nombre de la ruta conmutada por etiqueta (LSP) utilizada para transportar el tráfico VPN.El
Pushcampo muestra ambas etiquetas que se llevan en el paquete VPN-IPv4. La primera etiqueta es la etiqueta interna, que es la etiqueta VPN que le asignó el enrutador de PE. La segunda etiqueta es la etiqueta externa, que es una etiqueta RSVP.El
Communitiescampo enumera la comunidad de destino.El campo enumera otras tablas de enrutamiento de este enrutador en las
Secondary tablesque se instaló esta ruta.
Si las rutas del enrutador BRC local no están presentes en la tabla de enrutamiento bgp.l3vpn.0 en el enrutador de PE remoto, haga lo siguiente:
Compruebe el filtro de importación VRF en el enrutador de PE remoto, el cual está configurado en la
vrf-importinstrucción. (En el enrutador de PE local, compruebe el filtro de exportación VRF, el cual está configurado con lavrf-exportinstrucción.)Compruebe que hay un LSP operativo o una ruta de LDP entre los enrutadores pe. Para ello, compruebe que las direcciones del próximo salto del IBGP estén en la tabla inet.3.
Compruebe que la sesión del IBGP entre los enrutadores de PE está establecida y configurada correctamente.
Compruebe si hay rutas "ocultas", lo que por lo general significa que las rutas no se etiquetaron correctamente. Para ello, utilice el
show route table bgp.l3vpn.0 hiddencomando.Compruebe que la etiqueta interna coincida con la etiqueta VPN interna que asigna el enrutador de PE local. Para ello, utilice el
show route table mplscomando.
En el ejemplo siguiente se muestra el resultado de este comando en el enrutador de PE remoto. Aquí, la etiqueta interna es
100004.... Push 100004, Push 10005 (top)
En el siguiente ejemplo, se muestra el resultado de este comando en el enrutador de PE local, lo que muestra que la etiqueta interna de coincide con la etiqueta interna en
100004el enrutador de PE remoto:... 100004 *[VPN/7] 06:56:25, metric 1 > to 192.168.197.141 via fe-1/0/0.0, Pop
En el enrutador de PE remoto, compruebe que las rutas del enrutador de BRC local estén presentes en la tabla VRF ( routing-instance-name .inet.0):
user@host> show route table routing-instance-name.inet.0 detail 10.255.14.155/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.255.14.175:3 Source: 10.255.14.175 Nexthop: 192.168.192.1 via fe-1/1/2.0, selected label-switched-path vpn07-vpn05 Push 100004, Push 100005(top) State: <Secondary Active Int Ext> Local AS: 69 Peer AS: 69 Age: 1:16:22 Metric2: 338 Task: BGP_69.10.255.14.175+179 Announcement bits (2): 1-KRT 2-VPN-A-RIP AS path: 1 I Communities: target:69:100 BGP next hop: 10.255.14.175 Localpref: 100 Router ID: 10.255.14.175 Primary Routing Table bgp.l3vpn.0En esta tabla de enrutamiento, el diferenciador de rutas ya no se antepone al prefijo. La última línea,
Primary Routing Table, enumera la tabla desde la cual aprendió esta ruta.Si las rutas no están presentes en esta tabla de enrutamiento, pero estaban presentes en la tabla de enrutamiento bgp.l3vpn.0 en el enrutador BRC local, es posible que las rutas no hubieran pasado la política de importación de VRF en el enrutador de PE remoto.
Si una ruta VPN-IPv4 no coincide con ninguna política, la ruta no se muestra en la tabla bgp.l3vpn en absoluto y, por lo tanto, no está presente en la
vrf-importtabla VRF. Si esto ocurre, podría indicar que en el enrutador de PE, configuró otra instrucción en otra VPN (con un destino común) y las rutas se muestran en la tabla bgp.l3vpn.0, pero se importa en lavrf-importVPN incorrecta.En el enrutador BRC remoto, compruebe que las rutas del enrutador de BRC local estén presentes en la tabla de enrutamiento (inet.0):
user@host> show route
Si las rutas no están presentes, compruebe la configuración del protocolo de enrutamiento entre los enrutadores de PE y BRC remotos, y asegúrese de que los pares y adyacencias (o rutas estáticas) entre los enrutadores PE y BRC sean correctos.
Si determina que las rutas originadas en el enrutador de BRC local son correctas, compruebe las rutas originadas desde el enrutador de BRC remoto repitiendo este procedimiento.
Ejemplo: Solución de problemas de VPN de capa 3
En este ejemplo, se muestra cómo usar el comando para comprobar la accesibilidad de varios enrutadores en una topología VPN y cómo usar el comando para comprobar la ruta que los paquetes viajan entre los enrutadores ping traceroute VPN.
- Requisitos
- Visión general
- Hacer ping al enrutador BRC desde otro enrutador BRC externo
- Hacer ping en el PE remoto y BRC remoto desde el enrutador de BRC local
- Hacer ping a un enrutador BRC desde una interfaz multiacceso
- Hacer ping a los enrutadores de PE conectados directamente desde los enrutadores BRC de red
- Hacer ping a los enrutadores de BRC conectados directamente desde los enrutadores de PE
- Hacer ping al enrutador de BRC remoto desde el enrutador de PE local
- Solución de problemas Rutas anunciadas incoherentemente desde interfaces de Gigabit Ethernet
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
M Series routers
Junos OS versión 10.0R1 y posteriores
Visión general
Topología
La topología mostrada en la Figura 1 muestra la red utilizada en este ejemplo para demostrar cómo emplear los comandos ping y traceroute para probar la conectividad entre los enrutadores que participan en una VPN de capa 3.
Hacer ping al enrutador BRC desde otro enrutador BRC externo
Procedimiento
Procedimiento paso a paso
A continuación, se describe cómo usar el ping y los comandos para solucionar problemas de topologías VPN de traceroute capa 3. Puede hacer ping en BRC enrutador desde el otro especificando la dirección de circuito cerrado del otro enrutador BRC como dirección IP en el ping comando. Este comando tiene éxito si las direcciones de circuito cerrado han sido anunciadas por los enrutadores BRC a sus enrutadores ping PE conectados directamente. El éxito de estos comandos también significa que el enrutador CE1 puede hacer ping en cualquier dispositivo de red más allá del ping enrutador CE2 y viceversa. En la Figura 1 se muestra la topología a la que se hace referencia en los pasos siguientes:
Enrutador de ping CE2 (VPN5) del enrutador CE1 (VPN4):
user@vpn4> ping 10.255.10.5 local 10.255.10.4 count 3 PING 10.255.10.5 (10.255.10.5): 56 data bytes 64 bytes from 10.255.10.5: icmp_seq=0 ttl=253 time=1.086 ms 64 bytes from 10.255.10.5: icmp_seq=1 ttl=253 time=0.998 ms 64 bytes from 10.255.10.5: icmp_seq=2 ttl=253 time=1.140 ms --- 10.255.10.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.998/1.075/1.140/0.059 ms
Para determinar la ruta desde la interfaz de circuito cerrado del enrutador CE1 a la interfaz de circuito cerrado del enrutador CE2, utilice el
traceroutecomando:user@vpn4> traceroute 10.255.10.5 source 10.255.10.4 traceroute to 10.255.10.5 (10.255.10.5) from 10.255.10.4, 30 hops max, 40 byte packets 1 vpn1-fe-110.isp-core.net (192.168.192.1) 0.680 ms 0.491 ms 0.456 ms 2 vpn2-t3-001.isp-core.net (192.168.192.110) 0.857 ms 0.766 ms 0.754 ms MPLS Label=100005 CoS=0 TTL=1 S=1 3 vpn5.isp-core.net (10.255.10.5) 0.825 ms 0.886 ms 0.732 msCuando usa el comando para examinar la ruta utilizada por una VPN de capa 3, no se muestran los enrutadores del proveedor (P) en la red
traceroutedel proveedor de servicios. Como se muestra anteriormente, el salto del enrutador VPN1 al enrutador VPN2 se muestra como un solo salto. El enrutador P (VPN3) que se muestra en la Figura 1 no se muestra.Enrutador de ping CE1 (VPN4) del enrutador CE2 (VPN5):
user@vpn5> ping 10.255.10.4 local 10.255.10.5 count 3 PING 10.255.10.4 (10.255.10.4): 56 data bytes 64 bytes from 10.255.10.4: icmp_seq=0 ttl=253 time=1.042 ms 64 bytes from 10.255.10.4: icmp_seq=1 ttl=253 time=0.998 ms 64 bytes from 10.255.10.4: icmp_seq=2 ttl=253 time=0.954 ms --- 10.255.10.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.954/0.998/1.042/0.036 ms
Para determinar la ruta del enrutador CE2 al ENRUTADOR CE1, utilice el
traceroutecomando:user@vpn5> traceroute 10.255.10.4 source 10.255.10.5 traceroute to 10.255.10.4 (10.255.10.4) from 10.255.10.5, 30 hops max, 40 byte packets 1 vpn-08-t3-003.isp-core.net (192.168.193.2) 0.686 ms 0.519 ms 0.548 ms 2 vpn1-so-100.isp-core.net (192.168.192.100) 0.918 ms 0.869 ms 0.859 ms MPLS Label=100021 CoS=0 TTL=1 S=1 3 vpn4.isp-core.net (10.255.10.4) 0.878 ms 0.760 ms 0.739 ms
Hacer ping en el PE remoto y BRC remoto desde el enrutador de BRC local
Procedimiento
Procedimiento paso a paso
Desde el enrutador BRC local, puede hacer ping a las interfaces VPN en los enrutadores de PE y BRC remoto, que son interfaces punto a punto. En la Figura 1 se muestra la topología a la que hace referencia en los ejemplos siguientes:
Enrutador de ping CE2 del enrutador CE1.
user@vpn4> ping 192.168.193.5 local 10.255.10.4 count 3 PING 192.168.193.5 (192.168.193.5): 56 data bytes 64 bytes from 192.168.193.5: icmp_seq=0 ttl=253 time=1.040 ms 64 bytes from 192.168.193.5: icmp_seq=1 ttl=253 time=0.891 ms 64 bytes from 192.168.193.5: icmp_seq=2 ttl=253 time=0.944 ms --- 192.168.193.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.891/0.958/1.040/0.062 ms
Para determinar la ruta desde la interfaz de circuito cerrado del enrutador CE1 a la interfaz directamente conectada del enrutador CE2, utilice el
traceroutecomando:user@vpn4> traceroute 192.168.193.5 source 10.255.10.4 traceroute to 192.168.193.5 (192.168.193.5) from 10.255.10.4, 30 hops max, 40 byte packets 1 vpn1-fe-110.isp-core.net (192.168.192.1) 0.669 ms 0.508 ms 0.457 ms 2 vpn2-t3-001.isp-core.net (192.168.192.110) 0.851 ms 0.769 ms 0.750 ms MPLS Label=100000 CoS=0 TTL=1 S=1 3 vpn5-t3-003.isp-core.net (192.168.193.5) 0.829 ms 0.838 ms 0.731 msEnrutador de ping PE2 (VPN2) del enrutador CE1 (VPN4). En este caso, los paquetes que se originan en el enrutador CE1 van al enrutador PE2, luego al enrutador CE2 y de vuelta al enrutador PE2 antes de que el enrutador PE2 pueda responder a las solicitudes del Protocolo de mensajes de control de Internet (ICMP). Puede comprobarlo con el
traceroutecomando.user@vpn4> ping 192.168.193.2 local 10.255.10.4 count 3 PING 192.168.193.2 (192.168.193.2): 56 data bytes 64 bytes from 192.168.193.2: icmp_seq=0 ttl=254 time=1.080 ms 64 bytes from 192.168.193.2: icmp_seq=1 ttl=254 time=0.967 ms 64 bytes from 192.168.193.2: icmp_seq=2 ttl=254 time=0.983 ms --- 192.168.193.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.967/1.010/1.080/0.050 ms
Para determinar la ruta del enrutador CE1 al enrutador PE2, utilice el
traceroutecomando:user@vpn4> traceroute 192.168.193.2 source 10.255.10.4 traceroute to 192.168.193.2 (192.168.193.2) from 10.255.10.4, 30 hops max, 40 byte packets 1 vpn1-fe-110.isp-core.net (192.168.192.1) 0.690 ms 0.490 ms 0.458 ms 2 vpn2-t3-003.isp-core.net (192.168.193.2) 0.846 ms 0.768 ms 0.749 ms MPLS Label=100000 CoS=0 TTL=1 S=1 3 vpn5-t3-003.isp-core.net (192.168.193.5) 0.643 ms 0.703 ms 0.600 ms 4 vpn-08-t3-003.isp-core.net (192.168.193.2) 0.810 ms 0.739 ms 0.729 ms
Hacer ping a un enrutador BRC desde una interfaz multiacceso
Procedimiento
Procedimiento paso a paso
No puede hacer ping BRC enrutador desde el otro si la interfaz VPN es una interfaz multiacceso, como la interfaz en el fe-1/1/2.0 enrutador CE1. Para hacer ping al enrutador CE1 desde el enrutador CE2, debe incluir la instrucción en el nivel de jerarquía del enrutador PE1 o configurar una ruta estática en el enrutador PE1 a la interfaz VPN del enrutador vrf-table-label [edit routing-instances routing-instance-name] CE1. Si incluye la instrucción vrf-table-label para hacer ping en un enrutador, no puede configurar una ruta estática.
Si configura una ruta estática en el enrutador PE1 a la interfaz VPN del enrutador CE1, su próximo salto debe apuntar al enrutador CE1 (en el nivel de jerarquía), y esta ruta se debe anunciar del enrutador PE1 al PE2 como se muestra en la siguiente
[edit routing-instance routing-instance-name]configuración:[edit] routing-instances { direct-multipoint { instance-type vrf; interface fe-1/1/0.0; route-distinguisher 69:1; vrf-import direct-import; vrf-export direct-export; routing-options { static { route 192.168.192.4/32 next-hop 192.168.192.4; } } protocols { bgp { group to-vpn4 { peer-as 1; neighbor 192.168.192.4; } } } } policy-options { policy-statement direct-export { term a { from protocol bgp; then { community add direct-comm; accept; } } term b { from { protocol static; route-filter 192.168.192.4/32 exact; } then { community add direct-comm; accept; } } term d { then reject; } } } }Ahora puede hacer ping al enrutador CE1 desde el enrutador CE2:
user@vpn5> ping 192.168.192.4 local 10.255.10.5 count 3 PING 192.168.192.4 (192.168.192.4): 56 data bytes 64 bytes from 192.168.192.4: icmp_seq=0 ttl=253 time=1.092 ms 64 bytes from 192.168.192.4: icmp_seq=1 ttl=253 time=1.019 ms 64 bytes from 192.168.192.4: icmp_seq=2 ttl=253 time=1.031 ms --- 192.168.192.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.019/1.047/1.092/0.032 ms
Para determinar la ruta entre estas dos interfaces, utilice el
traceroutecomando:user@vpn5> traceroute 192.168.192.4 source 10.255.10.5 traceroute to 192.168.192.4 (192.168.192.4) from 10.255.10.5, 30 hops max, 40 byte packets 1 vpn-08-t3003.isp-core.net (192.168.193.2) 0.678 ms 0.549 ms 0.494 ms 2 vpn1-so-100.isp-core.net (192.168.192.100) 0.873 ms 0.847 ms 0.844 ms MPLS Label=100021 CoS=0 TTL=1 S=1 3 vpn4-fe-112.isp-core.net (192.168.192.4) 0.825 ms 0.743 ms 0.764 ms
Hacer ping a los enrutadores de PE conectados directamente desde los enrutadores BRC de red
Procedimiento
Procedimiento paso a paso
Desde las interfaces de circuito cerrado en BRC, puede hacer ping en la interfaz VPN en el enrutador de PE conectado directamente. En la Figura 1 se muestra la topología a la que hace referencia este procedimiento:
Desde la interfaz de circuito cerrado del enrutador CE1 (VPN4), haga ping en la interfaz
fe-1/1/0.0VPN, en el enrutador PE1:user@vpn4> ping 192.168.192.1 local 10.255.10.4 count 3 PING 192.168.192.1 (192.168.192.1): 56 data bytes 64 bytes from 192.168.192.1: icmp_seq=0 ttl=255 time=0.885 ms 64 bytes from 192.168.192.1: icmp_seq=1 ttl=255 time=0.757 ms 64 bytes from 192.168.192.1: icmp_seq=2 ttl=255 time=0.734 ms --- 192.168.192.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.734/0.792/0.885/0.066 ms
Desde la interfaz de circuito cerrado en el enrutador CE2 (VPN5), haga ping en la interfaz
t3-0/0/3.0VPN, en el enrutador PE2:user@vpn5> ping 192.168.193.2 local 10.255.10.5 count 3 PING 192.168.193.2 (192.168.193.2): 56 data bytes 64 bytes from 192.168.193.2: icmp_seq=0 ttl=255 time=0.998 ms 64 bytes from 192.168.193.2: icmp_seq=1 ttl=255 time=0.834 ms 64 bytes from 192.168.193.2: icmp_seq=2 ttl=255 time=0.819 ms --- 192.168.193.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.819/0.884/0.998/0.081 ms
Desde la interfaz de circuito cerrado en el enrutador CE2 (VPN5), haga ping en la interfaz
t3-0/0/3.0VPN, en el enrutador PE2:user@vpn5> ping 192.168.193.2 local 10.255.10.5 count 3 PING 192.168.193.2 (192.168.193.2): 56 data bytes 64 bytes from 192.168.193.2: icmp_seq=0 ttl=255 time=0.998 ms 64 bytes from 192.168.193.2: icmp_seq=1 ttl=255 time=0.834 ms 64 bytes from 192.168.193.2: icmp_seq=2 ttl=255 time=0.819 ms --- 192.168.193.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.819/0.884/0.998/0.081 ms
Para determinar la ruta desde la interfaz de circuito cerrado del enrutador CE2 a las interfaces VPN del enrutador PE2, utilice el
traceroutecomando:user@vpn5> traceroute 192.168.193.2 source 10.255.10.5 traceroute to 192.168.193.2 (192.168.193.2) from 10.255.10.5, 30 hops max, 40 byte packets 1 vpn-08-t3003.isp-core.net (192.168.193.2) 0.852 ms 0.670 ms 0.656 ms
Hacer ping a los enrutadores de BRC conectados directamente desde los enrutadores de PE
Procedimiento
Procedimiento paso a paso
Desde las interfaces VPN y de circuito cerrado en los enrutadores de PE, puede hacer ping en la interfaz VPN en el enrutador BRC conectado directamente. En la Figura 1 se muestra la topología a la que hace referencia este procedimiento:
Desde la interfaz VPN en el enrutador de PE (enrutador PE1), puede hacer ping en la interfaz VPN o de circuito cerrado en el enrutador BRC conectado directamente (enrutador CE1).
Desde la interfaz VPN en el enrutador PE1 (VPN1), haga ping en la interfaz
fe-1/1/0.0VPN, en el enrutador CE1:user@vpn1> ping 192.168.192.4 interface fe-1/1/0.0 local 192.168.192.1 count 3 PING 192.168.192.4 (192.168.192.4): 56 data bytes 64 bytes from 192.168.192.4: icmp_seq=0 ttl=255 time=0.866 ms 64 bytes from 192.168.192.4: icmp_seq=1 ttl=255 time=0.728 ms 64 bytes from 192.168.192.4: icmp_seq=2 ttl=255 time=0.753 ms --- 192.168.192.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.728/0.782/0.866/0.060 ms
Desde la interfaz VPN en el enrutador PE1 (VPN1), haga ping en la interfaz de circuito
10.255.10.4cerrado, en el enrutador CE1:user@vpn1> ping 10.255.10.4 interface fe-1/1/0.0 local 192.168.192.1 count 3 PING 10.255.10.4 (10.255.10.4): 56 data bytes 64 bytes from 10.255.10.4: icmp_seq=0 ttl=255 time=0.838 ms 64 bytes from 10.255.10.4: icmp_seq=1 ttl=255 time=0.760 ms 64 bytes from 10.255.10.4: icmp_seq=2 ttl=255 time=0.771 ms --- 10.255.10.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.760/0.790/0.838/0.034 ms
Para determinar la ruta desde la interfaz VPN en el enrutador PE1 a las interfaces VPN y de circuito cerrado en el enrutador CE1, respectivamente, utilice los
traceroutesiguientes comandos:user@vpn1> traceroute 10.255.10.4 interface fe-1/1/0.0 source 192.168.192.1 traceroute to 10.255.10.4 (10.255.10.4) from 192.168.192.1, 30 hops max, 40 byte packets 1 vpn4.isp-core.net (10.255.10.4) 0.842 ms 0.659 ms 0.621 ms user@vpn1> traceroute 192.168.192.4 interface fe-1/1/0.0 source 192.168.192.1 traceroute to 192.168.192.4 (192.168.192.4) from 192.168.192.1, 30 hops max, 40 byte packets 1 vpn4-fe-112.isp-core.net (192.168.192.4) 0.810 ms 0.662 ms 0.640 ms
Desde la interfaz VPN en el enrutador PE2 (VPN2), haga ping en la interfaz
t3-0/0/3.0VPN, en el enrutador CE2:user@vpn2> ping 192.168.193.5 interface t3-0/0/3.0 local 192.168.193.2 count 3 PING 192.168.193.5 (192.168.193.5): 56 data bytes 64 bytes from 192.168.193.5: icmp_seq=0 ttl=255 time=0.852 ms 64 bytes from 192.168.193.5: icmp_seq=1 ttl=255 time=0.909 ms 64 bytes from 192.168.193.5: icmp_seq=2 ttl=255 time=0.793 ms --- 192.168.193.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.793/0.851/0.909/0.047 ms
Desde la interfaz VPN en el enrutador PE2 (VPN2), haga ping en la interfaz de circuito
10.255.10.5cerrado, en el enrutador CE2:user@vpn2> ping 10.255.10.5 interface t3-0/0/3.0 local 192.168.193.2 count 3 PING 10.255.10.5 (10.255.10.5): 56 data bytes 64 bytes from 10.255.10.5: icmp_seq=0 ttl=255 time=0.914 ms 64 bytes from 10.255.10.5: icmp_seq=1 ttl=255 time=0.888 ms 64 bytes from 10.255.10.5: icmp_seq=2 ttl=255 time=1.066 ms --- 10.255.10.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.888/0.956/1.066/0.079 ms
Para determinar la ruta desde la interfaz VPN en el enrutador PE2 a las interfaces VPN y de circuito cerrado en el enrutador CE2, respectivamente, utilice los
traceroutesiguientes comandos:user@vpn2> traceroute 10.255.10.5 interface t3-0/0/3.0 source 192.168.193.2 traceroute to 10.255.10.5 (10.255.10.5) from 192.168.193.2, 30 hops max, 40 byte packets 1 vpn5.isp-core.net (10.255.10.5) 1.009 ms 0.677 ms 0.633 ms user@vpn2> traceroute 192.168.193.5 interface t3-0/0/3.0 source 192.168.193.2 traceroute to 192.168.193.5 (192.168.193.5) from 192.168.193.2, 30 hops max, 40 byte packets 1 vpn5-t3-003.isp-core.net (192.168.193.5) 0.974 ms 0.665 ms 0.619 ms
Hacer ping al enrutador de BRC remoto desde el enrutador de PE local
Procedimiento
Procedimiento paso a paso
El siguiente procedimiento es eficaz solo para VPN de capa 3. Para hacer ping en un enrutador BRC remoto desde un enrutador de PE local en una VPN de capa 3, debe configurar las siguientes interfaces:
Configure una unidad lógica para la interfaz de circuito cerrado.
Para configurar una unidad lógica adicional en la interfaz de circuito cerrado del enrutador de PE, configure la
unitinstrucción en el nivel de[edit interfaces lo0]jerarquía:[edit interfaces] lo0 { unit number { family inet { address address; } } }Configure la interfaz de circuito cerrado para la instancia de enrutamiento VPN de capa 3 en el enrutador de PE local. Puede asociar una interfaz de circuito cerrado lógico con cada instancia de enrutamiento VPN de capa 3, lo que le permite hacer ping en una instancia de enrutamiento específica en un enrutador.
Especifique la interfaz de circuito cerrado que configuró en el paso 1 mediante la
interfaceinstrucción en el nivel de[edit routing-instances routing-instance-name]jerarquía:[edit routing-instances routing-instance-name] interface interface-name;
La
interface-namees la unidad lógica de la interfaz de circuito cerrado (por ejemplo,lo0.1).Desde la interfaz VPN en enrutador de PE, ahora puede hacer ping en la unidad lógica en la interfaz de circuito cerrado en el enrutador BRC remoto:
user@host> ping interface interface host
Se
interfaceusa para especificar la nueva unidad lógica en la interfaz de circuito cerrado (por ejemplo,lo0.1). Para obtener más información acerca de cómo usar el comando, consulte La Referencia deping interfacecomandos de interfaces de Junos.
Solución de problemas Rutas anunciadas incoherentemente desde interfaces de Gigabit Ethernet
Procedimiento
Procedimiento paso a paso
Para rutas directas en una LAN en una VPN de capa 3, el Junos OS intenta localizar un enrutador BRC que se pueda designar como el próximo salto. Si esto no se puede hacer, se descartan las rutas anunciadas desde interfaces de Gigabit Ethernet.
En tales casos:
Utilice la instrucción en los niveles de jerarquía o en la instancia de enrutamiento VRF a un enrutador BRC en la subred
static[edit routing-options]de LAN, configurando el enrutador de BRC como el próximo[edit logical-systems logical-system-name routing-options]salto. Todo el tráfico hacia destinos directos en esta LAN irá al enrutador BRC seguro. Puede agregar dos rutas estáticas a dos enrutadores BRC en la LAN para fines de redundancia.Configure la instrucción en los niveles de jerarquía para asignar la etiqueta
vrf-table-labelinterna de un paquete a una tabla de enrutamiento[edit routing-instances routing-instance-name]VRF específica. Esto permite que el examen del encabezado DE IP encapsulado forme búsquedas IP en la instancia de enrutamiento VRF para todo el tráfico.Nota:La instrucción no está disponible para todas las interfaces orientadas al núcleo; por ejemplo, no se admiten
vrf-table-labelinterfaces canalizadas. Consulte Filtrado de paquetes en VPN de capa 3 basadas en encabezados IP para obtener información acerca de la compatibilidad con la instrucción a través de interfaces Ethernet yvrf-table-labelSONET/SDH.
Ejemplo: Cómo diagnosticar problemas de red relacionados con VPN de capa 3 mediante la deshabilitación del decremento de TTL
En este ejemplo, se muestra cómo deshabilitar la decrementación de TTL en una sola instancia de enrutamiento VRF en un caso de VPN de capa 3.
Requisitos
Antes de comenzar:
Configure las interfaces del enrutador. Consulte la Guía de configuración de interfaces de red.
Visión general
Para diagnosticar problemas de red relacionados con VPN, puede ser útil deshabilitar la decreción normal de tiempo de vida (TTL). El encabezado IP incluye un campo TTL que sirve como contador de saltos. En cada salto enrutado, el TTL se disminuye uno; si el TTL alcanza cero antes de que el paquete llegue a su destino, el paquete se descarta y (opcionalmente) se envía un mensaje de TTL ICMP superado al origen. MPLS etiquetas también tienen un campo TTL. MPLS los enrutadores copian el TTL de un paquete IP cuando ingresa una ruta de conmutación de etiquetas (LSP). Un paquete IP con un TTL de 27 recibe MPLS etiqueta con un TTL de 27. Junos OS disminuye la MPLS TTL de un paquete encapsulado de MPLS en lugar del TTL IP en cada salto con conmutación de etiqueta. Dado que el MPLS TTL se copia (o propaga) del TTL IP, un traceroute enumera todos los saltos de la ruta, ya sea enrutados o con conmutación de etiquetas. Cuando el paquete sale del LSP, el valor decrementado MPLS TTL se propaga de nuevo al campo TTL IP.
De forma predeterminada, la propagación TTL está habilitada. La instrucción global deshabilita la propagación de TTL en el nivel del enrutador y afecta a todos los no-propagate-ttl LSP con señales RSVP o LDP. Cuando un enrutador actúa como enrutador de entrada para un LSP y la configuración del enrutador incluye la instrucción, el enrutador inserta un encabezado MPLS con un valor TTL de 255, independientemente del no-propagate-ttl paquete IP TTL. Cuando un enrutador actúa como el penúltimo enrutador, aparece el encabezado MPLS sin propagar el MPLS TTL en el paquete IP. Por lo tanto, el valor TTL del paquete IP se conserva, independientemente del recuento de saltos del LSP.
En lugar de configurar el comportamiento de propagación de TTL en el nivel del enrutador, puede configurar el comportamiento de las rutas en una instancia de enrutamiento VRF. En este ejemplo, se muestra cómo deshabilitar la propagación de TTL para las rutas en una sola instancia de enrutamiento VRF en lugar de en el nivel del enrutador global.
La configuración por VRF tiene prioridad sobre la configuración del enrutador global. Si deshabilita la propagación de TTL en el enrutador y habilita explícitamente la propagación de TTL para una sola instancia de enrutamiento VRF, la propagación de TTL está en efecto para esa instancia de enrutamiento. Para habilitar explícitamente la propagación de TTL en una instancia de enrutamiento VRF, incluya la vrf-propagate-ttl instrucción en la instancia de enrutamiento.
Cuando cambia el comportamiento de propagación de TTL, los saltos siguientes antiguos para rutas VRF se eliminan de la tabla de enrutamiento inet.3 y se agregan nuevos saltos siguientes.
Solo necesita configurar la vrf-propagate-ttl instrucción o en los no-vrf-propagate-ttl enrutadores de entrada.
Diagrama de topología
En la Figura 2 se muestra la topología utilizada en este ejemplo. Los enrutadores PE1 y PE2 tienen dos VPN---VPN-A y VPN-B. Los dispositivos CE1 y CE4 pertenecen a VPN-A. Los dispositivos CE2 y CE5 pertenecen a VPN-B. En este ejemplo, el enrutador PE1 tiene deshabilitada la propagación de TTL en VPN-A, pero no en VPN-B. Los paquetes recibidos por PE1 en la interfaz conectada a CE1 han desactivado la propagación de TTL. En este ejemplo, se muestra la configuración en el enrutador PE1. No es necesario incluir la instrucción en el enrutador de no-vrf-propagate-ttl salida (PE2).
Configuración
Procedimiento
CLI configuración rápida
Para deshabilitar rápidamente la propagación de TTL en una instancia de enrutamiento VRF, copie los siguientes comandos y pegue los comandos en el CLI.
[edit] set interfaces lo0 unit 0 family inet address 10.255.179.45/32 primary set protocols mpls interface all set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.179.45 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 10.255.179.71 set protocols ospf area 0.0.0.0 interface fe-1/1/2.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ldp interface all set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from interface ge-1/2/0.0 set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement VPN-B-export term a from protocol static set policy-options policy-statement VPN-B-export term a then community add VPN-B set policy-options policy-statement VPN-B-export term a then accept set policy-options policy-statement VPN-B-export term b then reject set policy-options policy-statement VPN-B-import term a from protocol bgp set policy-options policy-statement VPN-B-import term a from community VPN-B set policy-options policy-statement VPN-B-import term a then accept set policy-options policy-statement VPN-B-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:1:100 set policy-options community VPN-B members target:1:200 set routing-instances VPN-A instance-type vrf set routing-instances VPN-A interface ge-1/2/0.0 set routing-instances VPN-A route-distinguisher 10.255.179.45:100 set routing-instances VPN-A interface ge-1/2/0.0 set routing-instances VPN-A no-vrf-propagate-ttl set routing-instances VPN-A vrf-import VPN-A-import set routing-instances VPN-A vrf-export VPN-A-export set routing-instances VPN-A protocols ospf export bgp-to-ospf set routing-instances VPN-A protocols ospf area 0.0.0.0 interface ge-1/2/0.0 set routing-instances VPN-B instance-type vrf set routing-instances VPN-B interface so-0/1/0.0 set routing-instances VPN-B route-distinguisher 10.255.179.45:300 set routing-instances VPN-B vrf-import VPN-B-import set routing-instances VPN-B vrf-export VPN-B-export set routing-instances VPN-B routing-options static route 10.255.179.15/32 next-hop so-0/1/0.0 set routing-options autonomous-system 1
Procedimiento paso a paso
En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo CLI, consulte Uso del editor de CLI en el modo de configuración.
Para configurar una asignación de flujo:
Configure la interfaz de circuito cerrado.
[edit] user@PE1# edit interfaces [edit interfaces] user@PE1# set lo0 unit 0 family inet address 10.255.179.45/32 primary user@PE1# exit
Configure los protocolos de enrutamiento.
La dirección BGP de vecino es la dirección de interfaz de circuito cerrado del enrutador PE2 en el gráfico 2.
[edit] user@PE1# edit protocols [edit protocols] user@PE1# set mpls interface all user@PE1# set bgp group ibgp type internal user@PE1# set bgp group ibgp local-address 10.255.179.45 user@PE1# set bgp group ibgp family inet-vpn unicast user@PE1# set bgp group ibgp neighbor 10.255.179.71 user@PE1# set ospf area 0.0.0.0 interface fe-1/1/2.0 user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable user@PE1# set ospf area 0.0.0.0 interface lo0.0 user@PE1# set ldp interface all user@PE1# exit
Configure políticas de enrutamiento para VPN-A y VPN-B.
[edit] user@PE1# edit policy-options [edit policy-options] user@PE1# set policy-statement VPN-A-export term a from protocol ospf user@PE1# set policy-statement VPN-A-export term a from interface ge-1/2/0.0 user@PE1# set policy-statement VPN-A-export term a then community add VPN-A user@PE1# set policy-statement VPN-A-export term a then accept user@PE1# set policy-statement VPN-A-export term b then reject user@PE1# set policy-statement VPN-A-import term a from protocol bgp user@PE1# set policy-statement VPN-A-import term a from community VPN-A user@PE1# set policy-statement VPN-A-import term a then accept user@PE1# set policy-statement VPN-A-import term b then reject user@PE1# set policy-statement VPN-B-export term a from protocol static user@PE1# set policy-statement VPN-B-export term a then community add VPN-B user@PE1# set policy-statement VPN-B-export term a then accept user@PE1# set policy-statement VPN-B-export term b then reject user@PE1# set policy-statement VPN-B-import term a from protocol bgp user@PE1# set policy-statement VPN-B-import term a from community VPN-B user@PE1# set policy-statement VPN-B-import term a then accept user@PE1# set policy-statement VPN-B-import term b then reject user@PE1# set policy-statement bgp-to-ospf from protocol bgp user@PE1# set policy-statement bgp-to-ospf then accept user@PE1# set community VPN-A members target:1:100 user@PE1# set community VPN-B members target:1:200 user@PE1# exit
Configure las instancias de enrutamiento VPN-A y VPN-B, incluida la
no-vrf-propagate-ttlinstrucción en VPN-A.[edit] user@PE1# edit routing-instances [edit routing-instances] user@PE1# set VPN-A instance-type vrf user@PE1# set VPN-A interface ge-1/2/0.0 user@PE1# set VPN-A route-distinguisher 10.255.179.45:100 user@PE1# set VPN-A interface ge-1/2/0.0 user@PE1# set VPN-A no-vrf-propagate-ttl user@PE1# set VPN-A vrf-import VPN-A-import user@PE1# set VPN-A vrf-export VPN-A-export user@PE1# set VPN-A protocols ospf export bgp-to-ospf user@PE1# set VPN-A protocols ospf area 0.0.0.0 interface ge-1/2/0.0 user@PE1# set VPN-B instance-type vrf user@PE1# set VPN-B interface so-0/1/0.0 user@PE1# set VPN-B route-distinguisher 10.255.179.45:300 user@PE1# set VPN-B vrf-import VPN-B-import user@PE1# set VPN-B vrf-export VPN-B-export user@PE1# set VPN-B routing-options static route 10.255.179.15/32 next-hop so-0/1/0.0 user@PE1# exit
Defina el sistema autónomo local.
[edit] user@PE1# edit routing-options [edit routing-options] user@PE1# set autonomous-system 1 user@PE1# exit
Cuando termine de configurar el dispositivo, confirme la configuración.
[edit] user@PE1# commit
Resultados
Para confirmar su configuración, escriba los comandos show interfaces show policy-options , , show protocols show routing-instances show routing-options y.
user@PE1# show interfaces
lo0 {
unit 0 {
family inet {
address 10.255.179.45/32 {
primary;
}
}
}
}
user@PE1# show policy-options
policy-statement VPN-A-export {
term a {
from {
protocol ospf;
interface ge-1/2/0.0;
}
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-B-export {
term a {
from protocol static;
then {
community add VPN-B;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-B-import {
term a {
from {
protocol bgp;
community VPN-B;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from protocol bgp;
then accept;
}
community VPN-A members target:1:100;
community VPN-B members target:1:200;
user@PE1# show protocols
mpls {
interface all;
}
bgp {
group ibgp {
type internal;
local-address 10.255.179.45;
family inet-vpn {
unicast;
}
neighbor 10.255.179.71;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/1/2.0;
interface fxp0.0 {
disable;
}
interface lo0.0;
}
}
ldp {
interface all;
}
user@PE1# show routing-instances
VPN-A {
instance-type vrf;
interface ge-1/2/0.0;
no-vrf-propagate-ttl;
route-distinguisher 10.255.179.45:100;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
ospf {
export bgp-to-ospf;
area 0.0.0.0 {
interface ge-1/2/0.0;
}
}
}
}
VPN-B {
instance-type vrf;
interface so-0/1/0.0;
route-distinguisher 10.255.179.45:300;
vrf-import VPN-B-import;
vrf-export VPN-B-export;
routing-options {
static {
route 10.255.179.15/32 next-hop so-0/1/0.0;
}
}
}
user@PE1# show routing-options autonomous-system 1;
Verificación
Para comprobar la operación, ejecute los siguientes comandos:
Consulte el
TTL Actioncampo en la salida delshow route extensive table VPN-Acomando.Consulte el
TTL Actioncampo en la salida delshow route extensive table VPN-Bcomando.En el dispositivo CE1, ejecute el comando a la dirección de circuito cerrado del dispositivo
tracerouteCE4.En el dispositivo CE4, ejecute el comando a la dirección
traceroutede circuito cerrado del dispositivo CE1.