Ce document décrit comment configurer des VPN de couche 3 (L3) dynamiques avec la fonctionnalité de tunnels mGRE (Generic Routing Encapsulation) multipoint.
Avant de configurer des VPN L3 dynamiques avec la fonctionnalité de tunnels mGRE, assurez-vous que votre VPN MPLS (Multiprotocol Label Switching) est configuré et fonctionne correctement, et que la connectivité de bout en bout est établie pour le réseau IPV4.
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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 fonctionnalité VPN L3 dynamiques avec tunnels mGRE fournit un mécanisme de transport L3 basé sur une technologie de tunnellisation mGRE améliorée pour une utilisation dans les réseaux IP. Le transport de tunnel L3 dynamique peut également être utilisé dans les réseaux IP afin de transporter le trafic VPN à travers les réseaux des fournisseurs de services et des entreprises, et pour fournir l'interopérabilité pour le transport de paquets entre les VPN IP et MPLS. Cette fonctionnalité prend en charge la norme RFC 2547, qui définit l'externalisation des services de réseau fédérateur IP pour les réseaux d'entreprise.
Voici une liste de restrictions qui s'appliquent aux VPN L3 dynamiques avec tunnels mGRE :
Cette section décrit deux configurations :
Il s'agit des configurations requises sur les routeurs 3 (R3) et 2 (R2).
Voici la configuration pour le 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
Voici la configuration pour le 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
Utilisez cette section pour confirmer que votre configuration fonctionne correctement.
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 vous avez un scénario de connexion double où une connexion est MPLS et l'autre non MPLS, vous devez configurer mGRE sur tous les routeurs PE impliqués. Avec cette topologie, vous devez configurer mGRE sur les trois routeurs PE.
Si vous n'avez pas configuré mGRE sur la connexion entre R3 et la liaison R1 - MPLS, les sous-réseaux derrière R3 ne peuvent pas communiquer avec les sous-réseaux derrière R2.
R1 et R2 créent des points d'extrémité de tunnel avec R3 en fonction du profil VPN de couche 3. Référez-vous à la configuration dans ce document où le profil VPN de couche 3 n'est pas configuré, la route-map vers l'homologue BGP (Border Gateway Protocol) sur R3 n'est pas appliquée et la route-map pour le VPN de couche 3 pour R3 sur R1 n'est pas appliquée.
Il s’agit des configurations requises sur R1, R2 et R3.
Voici la configuration de 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
Voici la configuration pour le 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
Voici la configuration pour le R3 :
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 activate
Vous pouvez maintenant envoyer une requête ping à partir du bouclage R2 loopback1 vers le bouclage R3 loopback1 :
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 a créé un tunnel dynamique pour 192.168.3.3 basé sur le tronçon suivant BGP pour la route 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
Elle est vérifiée sur R1 et a également créé des points de terminaison de tunnel pour les deux routeurs 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
Sur R3, aucun point d'extrémité de tunnel n'est créé :
R3#show tunnel endpoints
Voici la route du sous-réseau R2, à l’origine de la requête 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
Le paquet est donc envoyé encapsulé dans GRE vers R3. Comme R3 n'a pas de tunnel, il n'accepte pas le paquet GRE et le supprime.
Par conséquent, vous devez configurer mGRE de bout en bout sur un chemin afin de le faire fonctionner. Voici la configuration de mGRE sur R3, qui est nécessaire :
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
Dès que vous créez le profil VPN de couche 3, des points de terminaison de tunnel sont créés et vous recevez le trafic qui a été abandonné précédemment. Cependant, le trafic de retour est MPLS et non GRE jusqu'à ce que vous appliquiez le profil sur l'homologue BGP. Ce trafic est abandonné sur R1, car R1 ne dispose d'aucune information d'étiquette pour R2, qui exécute uniquement 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
Scénario 3
Supposons que les sous-réseaux derrière R5, qui doivent communiquer avec R3, ne souhaitent pas utiliser mGRE. Ensuite, vous pouvez utiliser la route-map qui a été utilisée pour le profil VPN L3 afin de définir le tronçon suivant et appeler une liste de préfixes, et autoriser uniquement les préfixes qui ont besoin du tunnel mGRE.
Voici la configuration de 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
Vous pouvez autoriser les préfixes dans le test prefix-list qui ont besoin du tunnel mGRE, et tout le reste n'a pas de tunnel comme interface de sortie et suit le routage normal. Cette configuration fonctionne car R3 et R5 disposent d’une connectivité MPLS de bout en bout.
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
29-Oct-2013 |
Première publication |