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, comience en un extremo de la VPN (el enrutador perimetral del cliente local [CE]) y siga las rutas hasta el otro extremo de la VPN (el enrutador CE remoto).
Solución
Los siguientes pasos de solución de problemas le ayudarán a diagnosticar problemas comunes:
Si configuró un protocolo de enrutamiento entre el perimetral del proveedor local (PE) y los enrutadores CE, compruebe que el emparejamiento y la adyacencia estén completamente operativos. Al hacerlo, asegúrese de especificar el nombre de la instancia de enrutamiento. Por ejemplo, para comprobar las adyacencias de OSPF, escriba el
show ospf neighbor instance routing-instance-namecomando en el enrutador de PE.Si el emparejamiento y la adyacencia no están completamente operativos, compruebe la configuración del protocolo de enrutamiento en el enrutador CE y compruebe la configuración del protocolo de enrutamiento para la instancia de enrutamiento VPN asociada en el enrutador PE.
Compruebe que los enrutadores CE y PE locales puedan hacer ping entre sí.
Para comprobar que el enrutador CE local puede hacer ping a la interfaz VPN en el enrutador PE local, utilice un
pingcomando en el siguiente formato, especificando la dirección IP o el nombre del enrutador PE:user@host> ping (ip-address | host-name)
Para comprobar que el enrutador PE local puede hacer ping al enrutador CE, utilice un
pingcomando en el siguiente formato, especificando la dirección IP o el nombre del enrutador CE, 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 eco salientes:user@host> ping ip-address interface interface local echo-address
A menudo, el emparejamiento o la adyacencia entre el CE local y los enrutadores PE locales deben producirse antes de que un
pingcomando se realice correctamente. Para comprobar que un vínculo está operativo en un entorno de laboratorio, quite la interfaz del enrutamiento y reenvío VPN (VRF) eliminando lainterfaceinstrucción del nivel de[edit routing-instance routing-instance-name]jerarquía y volviendo a confirmar la configuración. Al hacer esto, se elimina la interfaz de la VPN. A continuación, vuelva a intentar el ping comando. Si el comando se ejecuta correctamente, vuelva a configurar la interfaz en la VPN y vuelva a comprobar la configuración del protocolo de enrutamiento en los enrutadores CE y PE locales.En el enrutador PE local, compruebe que las rutas del enrutador CE local estén 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 CE es
10.255.14.155/32y el protocolo de enrutamiento entre los enrutadores PE y CE es BGP. La entrada se parece a cualquier anuncio ordinario de BGP.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 CE local no están presentes en la tabla de enrutamiento VRF, compruebe que el enrutador CE anuncia rutas al enrutador PE. Si se utiliza enrutamiento estático entre los enrutadores CE y PE, asegúrese de que están configuradas las rutas estáticas adecuadas.
En un enrutador PE remoto, compruebe que las rutas del enrutador CE 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 del prefijo (la primera línea de la salida), el distintivo de ruta se agrega al prefijo de ruta del enrutador CE 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 versión 4 (IPv4) únicas.
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 de conmutación de etiquetas (LSP) utilizada para transportar el tráfico VPN.El
Pushcampo muestra ambas etiquetas que se transportan en el paquete VPN-IPv4. La primera etiqueta es la etiqueta interna, que es la etiqueta VPN asignada por el enrutador PE. La segunda etiqueta es la etiqueta externa, que es una etiqueta RSVP.El
Communitiescampo enumera la comunidad objetivo.El
Secondary tablescampo enumera otras tablas de enrutamiento de este enrutador en las que se ha instalado esta ruta.
Si las rutas del enrutador CE local no están presentes en la tabla de enrutamiento bgp.l3vpn.0 del enrutador PE remoto, haga lo siguiente:
Compruebe el filtro de importación VRF en el enrutador PE remoto, que está configurado en la
vrf-importinstrucción. (En el enrutador PE local, compruebe el filtro de exportación VRF, que está configurado con lavrf-exportinstrucción).Compruebe que haya un LSP operativo o una ruta 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 de IBGP entre los enrutadores PE esté establecida y configurada correctamente.
Verifique si hay rutas "ocultas", lo que generalmente 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 asignada por 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, que muestra que la etiqueta interna de coincide con la etiqueta interna del
100004enrutador 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 CE 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 distintivo de ruta ya no se antepone al prefijo. La última línea,
Primary Routing Table, enumera la tabla de la que se 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 del enrutador CE local, es posible que las rutas no hayan pasado la directiva de importación de VRF en el enrutador PE remoto.
Si una ruta VPN-IPv4 no coincide con
vrf-importninguna política, la ruta no aparece en la tabla bgp.l3vpn y, por lo tanto, no está presente en la tabla VRF. Si esto ocurre, podría indicar que en el enrutador PE ha configurado otravrf-importinstrucción en otra VPN (con un destino común) y las rutas aparecen en la tabla bgp.l3vpn.0, pero se importan a la VPN incorrecta.En el enrutador CE remoto, compruebe que las rutas del enrutador CE 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 PE y CE remotos, y asegúrese de que los pares y adyacencias (o rutas estáticas) entre los enrutadores PE y CE sean correctos.
Si determina que las rutas originadas desde el enrutador CE local son correctas, repita este procedimiento para comprobar las rutas originadas desde el enrutador CE remoto.
Ejemplo: solución de problemas de VPN de capa 3
En este ejemplo se muestra cómo usar el ping comando para comprobar la accesibilidad de varios enrutadores en una topología VPN y cómo usar el traceroute comando para comprobar la ruta de acceso que los paquetes viajan entre los enrutadores VPN.
- Requisitos
- Visión general
- Hacer ping al enrutador CE desde otro enrutador CE
- Hacer ping a los enrutadores PE y CE remotos desde el enrutador CE local
- Hacer ping a un enrutador CE desde una interfaz de acceso múltiple
- Hacer ping a los enrutadores PE conectados directamente desde los enrutadores CE
- Hacer ping a los enrutadores CE conectados directamente desde los enrutadores PE
- Hacer ping al enrutador CE remoto desde el enrutador PE local
- Solución de problemas de rutas anunciadas de manera inconsistente desde interfaces Gigabit Ethernet
Requisitos
En este ejemplo se utilizan los siguientes componentes de hardware y software:
-
Enrutadores serie M
-
Junos OS versión 10.0R1 y posteriores
Visión general
Topología
La topología que se muestra en la figura 1 ilustra 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 CE desde otro enrutador CE
Procedimiento
Procedimiento paso a paso
A continuación se describe cómo usar el ping y traceroute los comandos para solucionar problemas de topologías VPN de capa 3. Puede hacer ping a un enrutador CE del otro especificando la dirección de circuito cerrado del otro enrutador CE como dirección IP en el ping comando. Este ping comando se ejecuta correctamente si los enrutadores CE han anunciado las direcciones de circuito cerrado a sus enrutadores PE conectados directamente. El éxito de estos ping comandos también significa que el enrutador CE1 puede hacer ping a cualquier dispositivo de red más allá del enrutador CE2, y viceversa. La figura 1 muestra la topología a la que se hace referencia en los pasos siguientes:
-
Hacer ping al enrutador CE2 (VPN5) desde el 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 ms -
Cuando se utiliza el
traceroutecomando para examinar la ruta utilizada por una VPN de capa 3, no se muestran los enrutadores del proveedor (P) en la red del proveedor de servicios. Como se muestra arriba, 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. -
Hacer ping al enrutador CE1 (VPN4) desde el 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 a los enrutadores PE y CE remotos desde el enrutador CE local
Procedimiento
Procedimiento paso a paso
Desde el enrutador CE local, puede hacer ping a las interfaces VPN en los enrutadores PE y CE remotos, que son interfaces punto a punto. La figura 1 muestra la topología a la que se hace referencia en los siguientes ejemplos:
-
Hacer ping al enrutador CE2 desde el 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 conectada directamente 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 ms -
Hacer ping al enrutador PE2 (VPN2) desde el enrutador CE1 (VPN4). En este caso, los paquetes que se originan en el enrutador CE1 van al enrutador PE2, luego al enrutador CE2 y vuelven 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 mediante 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 CE desde una interfaz de acceso múltiple
Procedimiento
Procedimiento paso a paso
No puede hacer ping a un enrutador CE del otro si la interfaz VPN es una interfaz de acceso múltiple, como la fe-1/1/2.0 interfaz del enrutador CE1. Para hacer ping al enrutador CE1 desde el enrutador CE2, debe incluir la vrf-table-label instrucción en el nivel de jerarquía del enrutador PE1 o configurar una ruta estática en el [edit routing-instances routing-instance-name] enrutador PE1 a la interfaz VPN del enrutador CE1. Si incluye la vrf-table-label instrucción para hacer ping a un enrutador, no podrá configurar una ruta estática.
-
Si configura una ruta estática en el enrutador PE1 a la interfaz VPN del enrutador CE1, su siguiente salto debe apuntar al enrutador CE1 (en el nivel de jerarquía) y esta ruta debe anunciarse desde el
[edit routing-instance routing-instance-name]enrutador PE1 al enrutador PE2, como se muestra en la siguiente 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 PE conectados directamente desde los enrutadores CE
Procedimiento
Procedimiento paso a paso
Desde las interfaces de circuito cerrado de los enrutadores CE, puede hacer ping a la interfaz VPN en el enrutador PE conectado directamente. La figura 1 muestra la topología a la que se hace referencia en este procedimiento:
-
Desde la interfaz de circuito cerrado del enrutador CE1 (VPN4), haga ping a la interfaz VPN,
fe-1/1/0.0, 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 del enrutador CE2 (VPN5), haga ping a la interfaz VPN,
t3-0/0/3.0, 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 del enrutador CE2 (VPN5), haga ping a la interfaz VPN,
t3-0/0/3.0, 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 CE conectados directamente desde los enrutadores PE
Procedimiento
Procedimiento paso a paso
Desde las interfaces VPN y de circuito cerrado de los enrutadores PE, puede hacer ping a la interfaz VPN en el enrutador CE conectado directamente. La figura 1 muestra la topología a la que se hace referencia en este procedimiento:
-
Desde la interfaz VPN del enrutador PE (enrutador PE1), puede hacer ping a la interfaz VPN o de circuito cerrado en el enrutador CE conectado directamente (enrutador CE1).
Desde la interfaz VPN del enrutador PE1 (VPN1), haga ping a la interfaz VPN,
fe-1/1/0.0, 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 del enrutador PE1 (VPN1), haga ping a la interfaz de circuito cerrado,
10.255.10.4, 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 hasta las interfaces VPN y de circuito cerrado en el enrutador CE1, respectivamente, utilice los siguientes
traceroutecomandos: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 del enrutador PE2 (VPN2), haga ping a la interfaz VPN,
t3-0/0/3.0, 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 del enrutador PE2 (VPN2), haga ping a la interfaz de circuito cerrado,
10.255.10.5, 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 siguientes
traceroutecomandos: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 CE remoto desde el enrutador PE local
Procedimiento
Procedimiento paso a paso
El siguiente procedimiento es efectivo solo para VPN de capa 3. Para hacer ping a un enrutador CE remoto desde un enrutador 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 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 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 a 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;
El
interface-namees la unidad lógica de la interfaz de circuito cerrado (por ejemplo,lo0.1). -
Desde la interfaz VPN del enrutador PE, ahora puede hacer ping a la unidad lógica en la interfaz de circuito cerrado del enrutador CE remoto:
user@host> ping interface interface hostUtilice
interfaceesta opción 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 utilizar elping interfacecomando, consulte la Referencia de comandos de interfaces de Junos.
Solución de problemas de rutas anunciadas de manera inconsistente desde interfaces Gigabit Ethernet
Procedimiento
Procedimiento paso a paso
Para rutas directas en una LAN en una VPN de capa 3, Junos OS intenta localizar un enrutador CE que se puede designar como el siguiente salto. Si esto no se puede hacer, se eliminan las rutas anunciadas desde las interfaces Gigabit Ethernet.
En tales casos:
-
Utilice la
staticinstrucción en los niveles de[edit routing-options]jerarquía o[edit logical-systems logical-system-name routing-options]en la instancia de enrutamiento VRF a un enrutador CE en la subred LAN y configure el enrutador CE como el siguiente salto. Todo el tráfico a destinos directos en esta LAN irá al enrutador CE. Puede agregar dos rutas estáticas a dos enrutadores CE en la LAN para obtener redundancia. -
Configure la
vrf-table-labelinstrucción en los niveles de[edit routing-instances routing-instance-name]jerarquía para asignar la etiqueta interna de un paquete a una tabla de enrutamiento VRF específica. Esto permite examinar el encabezado IP encapsulado para forzar búsquedas IP en la instancia de enrutamiento VRF para todo el tráfico.Nota:La
vrf-table-labelinstrucción no está disponible para todas las interfaces orientadas al núcleo; por ejemplo, no se admiten interfaces canalizadas. Consulte Filtrado de paquetes en VPN de capa 3 basadas en encabezados IP para obtener información sobre la compatibilidad con lavrf-table-labelinstrucción a través de interfaces Ethernet y SONET/SDH.
Ejemplo: diagnóstico de problemas de red relacionados con VPN de capa 3 mediante la desactivación de la disminución de TTL
En este ejemplo se muestra cómo deshabilitar la disminución de TTL en una sola instancia de enrutamiento VRF en un escenario de VPN de capa 3.
Requisitos
Antes de empezar:
-
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 las VPN, puede ser útil deshabilitar la disminución del tiempo de vida normal (TTL). El encabezado IP incluye un campo TTL que sirve como contador de saltos. En cada salto enrutado, el TTL se reduce en uno; si el TTL llega a cero antes de que el paquete llegue a su destino, el paquete se descarta y (opcionalmente) se envía un mensaje ICMP TTL excedido al origen. Las etiquetas MPLS también tienen un campo TTL. Los enrutadores MPLS copian el TTL de un paquete IP cuando entra en una ruta de conmutación de etiquetas (LSP). Un paquete IP con un TTL de 27 recibe una etiqueta MPLS con un TTL de 27. Junos OS disminuye el TTL MPLS de un paquete encapsulado en MPLS en lugar del TTL IP, en cada salto de conmutación de etiquetas. Dado que la TTL MPLS se copia (o propaga) desde la TTL IP, una traceroute enumera todos los saltos de la ruta, ya sea enrutada o conmutada por etiquetas. Cuando el paquete sale del LSP, el TTL MPLS decrementado se propaga de nuevo al campo TTL IP.
De forma predeterminada, la propagación TTL está habilitada. La instrucción global no-propagate-ttl deshabilita la propagación de TTL en el nivel del enrutador y afecta a todos los LSP señalados por RSVP o LDP. Cuando un enrutador actúa como enrutador de entrada para un LSP y la configuración del enrutador incluye la no-propagate-ttl instrucción, el enrutador inserta un encabezado MPLS con un valor TTL de 255, independientemente del TTL del paquete IP. Cuando un enrutador actúa como el penúltimo enrutador, hace emerger el encabezado MPLS sin propagar el TTL MPLS al paquete IP. Por lo tanto, se conserva el valor TTL del paquete IP, independientemente del recuento de saltos del LSP.
En lugar de configurar el comportamiento de propagación de TTL en el nivel de enrutador, puede configurar el comportamiento para 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 única instancia de enrutamiento VRF en lugar de en el nivel de enrutador global.
La configuración por VRF tiene prioridad sobre la configuración global del enrutador. Si deshabilita la propagación TTL en el enrutador y habilita explícitamente la propagación TTL para una sola instancia de enrutamiento VRF, la propagación TTL estará vigente 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 se cambia el comportamiento de propagación TTL, los siguientes saltos 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 no-vrf-propagate-ttl en los enrutadores de entrada.
Diagrama de topología
La figura 2 muestra la topología utilizada en este ejemplo. El enrutador PE1 y el enrutador 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 la propagación TTL deshabilitada en VPN-A pero no en VPN-B. Los paquetes recibidos por PE1 en la interfaz conectada a CE1 tienen la propagación TTL deshabilitada. En este ejemplo se muestra la configuración del enrutador PE1. No es necesario incluir la no-vrf-propagate-ttl instrucción en el enrutador de salida (PE2).
Configuración
Procedimiento
Configuración rápida de CLI
Para deshabilitar rápidamente la propagación de TTL en una instancia de enrutamiento VRF, copie los siguientes comandos y péguelos en la 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 es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar un mapa 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 vecina interna del BGP es la dirección de interfaz de circuito cerrado del enrutador PE2 de la figura 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 las 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 -
Definir el sistema autónomo local.
[edit] user@PE1# edit routing-options [edit routing-options] user@PE1# set autonomous-system 1 user@PE1# exit -
Si ha terminado de configurar el dispositivo, confirme la configuración.
[edit] user@PE1# commit
Resultados
Confirme la configuración introduciendo los show interfacescomandos, show policy-options, show protocolsshow routing-instances, y show routing-options .
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:
-
Vea el
TTL Actioncampo en la salida delshow route extensive table VPN-Acomando. -
Vea el
TTL Actioncampo en la salida delshow route extensive table VPN-Bcomando. -
En el dispositivo CE1, ejecute el comando en la
traceroutedirección de circuito cerrado del dispositivo CE4. -
En el dispositivo CE4, ejecute el comando en la
traceroutedirección de circuito cerrado del dispositivo CE1.