Este documento describe cómo configurar las VPN dinámicas de capa 3 (L3) con la función de túneles de encapsulación de routing genérico multipunto (mGRE).
Antes de configurar las VPN L3 dinámicas con la función de túneles mGRE, asegúrese de que la VPN de conmutación de etiquetas multiprotocolo (MPLS) esté configurada y funcione correctamente, y de que se establezca la conectividad de extremo a extremo para la red IPV4.
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
La función Dynamic L3 VPNs with mGRE Tunnels proporciona un mecanismo de transporte L3 basado en una tecnología de tunelización mGRE mejorada para su uso en redes IP. El transporte de tunelización L3 dinámico también se puede utilizar dentro de las redes IP para transportar el tráfico VPN a través de las redes empresariales y del proveedor de servicios, y para proporcionar interoperabilidad para el transporte de paquetes entre VPN IP y MPLS. Esta función proporciona soporte para RFC 2547, que define la subcontratación de servicios de estructura básica IP para redes empresariales.
Esta es una lista de restricciones que se aplican a las VPN L3 dinámicas con túneles mGRE:
Esta sección describe dos configuraciones:
Estas son las configuraciones necesarias en el Router 3 (R3) y el Router 2 (R2).
Esta es la configuración de R3:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
!
address-family vpnv4
neighbor 192.168.2.2 route-map MGRE-NEXT-HOP in
Esta es la configuración de R2:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
!
address-family vpnv4
neighbor 192.168.3.3 route-map MGRE-NEXT-HOP in
Utilize esta sección para confirmar que su configuración funcione correctamente.
R2#show tunnel endpoints
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.3.3 Refcount 3 Base 0x1E8E1B74 Create Time 00:47:53
overlay 192.168.3.3 Refcount 2 Parent 0x1E8E1B74 Create Time 00:47:53
R2#show l3vpn encapsulation ip MGRE
Profile: MGRE
transport ipv4 source Loopback0
protocol gre
payload mpls
mtu default
Tunnel Tunnel0 Created [OK]
Tunnel Linestate [OK]
Tunnel Transport Source Loopback0 [OK]
R2#show ip route vrf MGRE 172.16.3.3
Routing Table: MGRE
Routing entry for 172.16.3.3
Known via "bgp 65534", distance 200, metric 0, type internal
Last update from 192.168.3.3 on Tunnel0, 01:03:25 ago
Routing Descriptor Blocks:
* 192.168.3.3 (default), from 172.16.112.1, 01:03:25 ago, via Tunnel0 <points to tunnel
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 17 <BGP vpnv4 label>
MPLS Flags: MPLS Required
Si tiene un escenario de conexión dual donde una conexión es MPLS y la otra no es MPLS, debe configurar mGRE en todos los routers PE involucrados. Con esta topología, debe configurar mGRE en los tres routers PE.
Si no ha configurado mGRE en la conexión entre el link R3 y R1 - MPLS, las subredes detrás de R3 no pueden comunicarse con las subredes detrás de R2.
R1 y R2 construyen puntos finales de túnel con R3 basado en el perfil VPN L3. Consulte la configuración de este documento donde el perfil VPN L3 no está configurado, el route-map al peer BGP en R3 no se aplica y el route-map para la VPN L3 para R3 en R1 no se aplica.
Estas son las configuraciones necesarias en R1, R2 y R3.
Esta es la configuración para R1:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
address-family vpnv4
neighbor 192.168.2.2 send-community extended
neighbor 192.168.2.2 route-map MGRE-NEXT-HOP in
neighbor 192.168.3.3 activate
Esta es la configuración de R2:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 route-map MGRE-NEXT-HOP in
neighbor 192.168.1.1 activate
Esta es la configuración de R3:
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 activate
Ahora, puede hacer ping desde el loopback1 R2 al loopback1 R3:
R2#ping vrf MGRE 172.16.3.3 source 172.16.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.2
.....
Success rate is 0 percent (0/5)
R2#show ip route vrf MGRE 172.16.3.3
Routing Table: MGRE
Routing entry for 172.16.3.3/32
Known via "bgp 65534", distance 200, metric 0, type internal
Last update from 192.168.3.3 on Tunnel0, 00:50:23 ago
Routing Descriptor Blocks:
* 192.168.3.3 (default), from 192.168.1.1, 00:50:23 ago, via Tunnel0pointed towards a tunnel>
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 19
MPLS Flags: MPLS Required
R2#show tunnel endpoints
Tunnel1 running in multi-GRE/IP mode
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.1.1 Refcount 3 Base 0x507665E4 Create Time 01:24:25
overlay 192.168.1.1 Refcount 2 Parent 0x507665E4 Create Time 01:24:25
Endpoint transport 192.168.3.3 Refcount 3 Base 0x507664D4 Create Time 00:50:51
overlay 192.168.3.3 Refcount 2 Parent 0x507664D4 Create Time 00:50:51
R2 creó un túnel dinámico para 192.168.3.3 basado en el siguiente salto BGP para la ruta 172.16.3.3.
R2#show ip bgp vpnv4 vrf MGRE 172.16.3.3
BGP routing table entry for 43984:300:172.16.3.3/32, version 29
Paths: (1 available, best #1, table MGRE)
Advertised to update-groups:
1
Local, imported path from 300:300:172.16.3.3/32
192.168.3.3 (metric 3) (via Tunnel0) from 192.168.1.1 (192.168.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:43984:300
Originator: 192.168.3.3, Cluster list: 192.168.1.1
mpls labels in/out nolabel/19
Se verifica en R1 y también crea puntos finales de túnel para ambos routers PE:
R1#show tunnel endpoints
Tunnel1 running in multi-GRE/IP mode
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.2.2 Refcount 3 Base 0x1E8EE7B0 Create Time 01:36:41
overlay 192.168.2.2 Refcount 2 Parent 0x1E8EE7B0 Create Time 01:36:41
Endpoint transport 192.168.3.3 Refcount 3 Base 0x1E8EE590 Create Time 00:59:34
overlay 192.168.3.3 Refcount 2 Parent 0x1E8EE590 Create Time 00:59:34
En R3, no se crean extremos de túnel:
R3#show tunnel endpoints
Esta es la ruta para la subred R2, que originó el ping:
R3#show ip route vrf MGRE 172.16.2.2
Routing Table: MGRE
Routing entry for 172.16.2.2/32
Known via "bgp 65534", distance 200, metric 0, type internal
Last update from 192.168.2.2 01:01:57 ago
Routing Descriptor Blocks:
* 192.168.2.2 (default), from 192.168.1.1, 01:01:57 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 17
MPLS Flags: MPLS Required
Por lo tanto, el paquete se envía encapsulado en GRE hacia R3. Dado que R3 no tiene túnel, no acepta el paquete GRE y lo descarta.
Por lo tanto, debe configurar mGRE de extremo a extremo en una trayectoria para que funcione. Esta es la configuración para mGRE en R3, que es necesaria:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
Tan pronto como cree el perfil VPN L3, se crean los puntos finales de túnel y recibe el tráfico que se descartó antes. Sin embargo, el tráfico de retorno es MPLS y no GRE hasta que aplique el perfil en el peer BGP. Ese tráfico se descarta en R1, porque R1 no tiene ninguna información de etiqueta para R2, que ejecuta solamente IP.
R3#show tunnel endpoints
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.1.1 Refcount 3 Base 0x2B79FBD4 Create Time 00:00:02
overlay 192.168.1.1 Refcount 2 Parent 0x2B79FBD4 Create Time 00:00:02
Endpoint transport 192.168.2.2 Refcount 3 Base 0x2B79FAC4 Create Time 00:00:02
overlay 192.168.2.2 Refcount 2 Parent 0x2B79FAC4 Create Time 00:00:02
R3#show ip cef vrf MGRE 172.16.2.2
172.16.2.2/32
nexthop 192.168.13.1 GigabitEthernet0/0.1503 label 21 17
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 route-map MGRE-NEXT-HOP in
R3#show ip cef vrf MGRE 172.16.2.2
172.16.2.2/32
nexthop 192.168.2.2 Tunnel0 label 17
R2#ping vrf MGRE 172.16.3.3 source 172.16.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Escenario 3
Suponga que las subredes detrás de R5, que necesitan comunicarse con R3, no desean utilizar mGRE. Luego, puede utilizar el route-map que se utilizó para el perfil VPN L3 para establecer el salto siguiente y llamar a una lista de prefijos, y solamente permitir los prefijos que necesitan el túnel mGRE.
Esta es la configuración para R1:
route-map MGRE-NEXT-HOP permit 10
match ip address prefix-list test
set ip next-hop encapsulate l3vpn MGRE
route-map MGRE-NEXT-HOP permit 20
Puede permitir los prefijos en la prueba de lista de prefijos que necesitan el túnel mGRE, y todo lo demás no tiene un túnel como interfaz de salida y sigue el ruteo normal. Esta configuración funciona porque R3 y R5 tienen conectividad MPLS de extremo a extremo.
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
04-Nov-2013 |
Versión inicial |