Cisco France Blog

J'ai testé pour vous: faire un L3VPN sans transport MPLS (aka L3VPNoMGRE)

5 min read



J’ai récemment indiqué comment simplement virtualiser son infrastructure L3 grâce à EVN (Easy Virtual Network). Voir ici pour une petite vidéo et pour la dispo dans le cat6k. EVN est une solution simple mais ne se propage pas sur le WAN… L3VPN over mGRE va nous permettre de continuer notre virtualisation L3 de bout en bout et cela sans utiliser de transport MPLS!

L3VPN over mGRE: principe

Le fonctionnement est très simple: on remplace la couche MPLS de transport de notre L3VPN par une encapsulation GRE. Les paquets échangés entre ingress et egress PE sont donc transportés sur IP ce qui donne pas mal de liberté! Attention, on conserve quand même le label MPLS qui permet de déterminer le VPN. On parle ici de mGRE (Multipoint GRE) car une seule interface tunnel est créée sur chaque routeur (on ne créé pas un full mesh entre tous nos PE). L’adresse de destination du tunnel est tout simplement l’adresse IP du next-hop BGP des routes VPN reçues.

Matériel et IOS utilisé

  • Catalyst 6500 sup2T – 15.0(1)SY1
  • 2 ISR G2 – Cisco 2951 – 15.2(2)T1
  • Catalyst 6500 sup720 – 12.2(33)SXJ2

Topologie du lab

Etape 1 – configuration du L3VPN “standard”

6500-VSS-2T – PE

vlan 31
 name TEST-L3VPNOMGRE
!
vrf definition L3VPNOMGRE
 rd 65501:1
 route-target export 65501:65501
 route-target import 65501:65501
 !
 address-family ipv4
 exit-address-family
!
interface Vlan31
 vrf forwarding L3VPNOMGRE
 ip address 10.100.1.1 255.255.255.0
!
router bgp 65501
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.0.0.254 remote-as 65501
 neighbor 10.0.0.254 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.0.0.254 activate
  neighbor 10.0.0.254 send-community both
 exit-address-family
 !
 address-family ipv4 vrf L3VPNOMGRE
  redistribute connected
 exit-address-family

2951-1 – PE

vrf definition L3VPNOMGRE
 rd 65501:2
 route-target export 65501:65501
 route-target import 65501:65501
 !
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet1/0.20
 description TEST L3VPNOMGRE
 encapsulation dot1Q 20
 vrf forwarding L3VPNOMGRE
 ip address 10.100.2.1 255.255.255.0
!
router bgp 65501
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.0.0.254 remote-as 65501
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.0.0.254 activate
  neighbor 10.0.0.254 send-community both
 exit-address-family
 !
 address-family ipv4 vrf L3VPNOMGRE
  redistribute connected
 exit-address-family

2951-2 – PE

Je vous épargne cette configuration, équivalente bien sûr au routeur précédent.

6500-SUP720 – BGP route-reflector

router bgp 65501
 bgp router-id 10.0.0.254
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 65501
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.2 remote-as 65501
 neighbor 10.0.0.2 update-source Loopback0
 neighbor 10.0.0.3 remote-as 65501
 neighbor 10.0.0.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 send-community both
  neighbor 10.0.0.1 route-reflector-client
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 send-community both
  neighbor 10.0.0.2 route-reflector-client
  neighbor 10.0.0.3 activate
  neighbor 10.0.0.3 send-community both
  neighbor 10.0.0.3 route-reflector-client
 exit-address-family

Premier ping ?

Si j’essaye de pinger entre les 2 sites, ça ne marche pas: normal on a les next-hops mais on ne sait pas comment transporter tout ça car nous n’avons pas de transport MPLS sur le coeur!

VSS-2T#ping vrf L3VPNOMGRE 10.100.2.1 source 10.100.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.1.1
.....
Success rate is 0 percent (0/5)

Etape 2 – Déclaration du transport GRE

Sur les PE il suffit de configurer les 2 éléments suivants:

  • Un profile d’encapsulation L3VPN qui utilise un transport IP
  • Une route-map en entrée des peerings iBGP sur la SAFI vpnv4 qui indique d’utiliser le profile d’ecapsulation créé pour joindre les routes reçues

6500-VSS-2T

l3vpn encapsulation ip L3VPNOMGRE_PROFILE
 transport ipv4 source Loopback0
 protocol gre
 ! Note: "protocol gre" est utilisé par défaut et n'apparaît pas dans la configuration
!
router bgp 65501
 address-family vpnv4
  neighbor 10.0.0.254 route-map L3VPNOMGRE_RM in
 exit-address-family
!
route-map L3VPNOMGRE_RM permit 10
 set ip next-hop encapsulate l3vpn L3VPNOMGRE_PROFILE

2951-1

l3vpn encapsulation ip L3VPNOMGRE_PROFILE
 transport ipv4 source Loopback0
 protocol gre
 ! Note: "protocol gre" est utilisé par défaut et n'apparaît pas dans la configuration
!
router bgp 65501
 address-family vpnv4
  neighbor 10.0.0.254 route-map L3VPNOMGRE_RM in
 exit-address-family
!
route-map L3VPNOMGRE_RM permit 10
 set ip next-hop encapsulate l3vpn L3VPNOMGRE_PROFILE

Si l’on regarde maintenant les routes de la VRF, on voit clairement que le tunnel automatiquement créé avec notre profile d’encapsulation est utilisé pour joindre les routes envoyées par les PE distants.

6500-2T-VSS#sh ip route vrf L3VPNOMGRE
[snip]
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.100.1.0/24 is directly connected, Vlan31
L        10.100.1.1/32 is directly connected, Vlan31
B        10.100.2.0/24 [200/0] via 10.0.0.2, 00:01:30, Tunnel0
B        10.100.3.0/24 [200/0] via 10.0.0.3, 00:04:51, Tunnel0

On peut voir plus clairement ce qu’il se passe au niveau de la table de forwarding MPLS:

6500-2T-VSS#sh mpls forwarding-table vrf L3VPNOMGRE 10.100.2.0 24
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       16         10.100.2.0/24[V] 0             Tu0        10.0.0.2

On peut jeter un coup d’oeil au tunnel créé par le profile d’encpasulation:

6500-2T-VSS#sh int tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Interface is unnumbered. Using address of Loopback0 (10.0.0.1)
  MTU 17864 bytes, BW 10000 Kbit, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 10.0.0.1 (Loopback0)
   Tunnel Subblocks:
      src-track:
         Tunnel0 source tracking subblock associated with Loopback0
          Set of tunnels with source Loopback0, 1 member (includes iterators), on interface
  Tunnel protocol/transport multi-GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1472 bytes
[snip]

Vous noterez que la MTU est de 1472 octets. Heureusement les extrémités de tunnel peuvent fragmenter/réassembler les paquets… Mais attention tout de même si vous utilisez l’option DF. Il semblerait malheureusement que cela ne soit pas possible de changer cette MTU pour l’instant mais cela devrait évoluer.

6500-2T-VSS#ping vrf L3VPNOMGRE 10.100.2.1 source 10.100.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Conclusion

Comme vous l’avez vu, L3VPNoMGRE n’est pas compliqué à mettre en oeuvre. On garde les principes classiques d’un L3VPN de base mais on déclare simplement une encapsulation du type GRE multipoint. Comme pour tout ce qui est tunneling, je conseille de faire particulièrement attention à la MTU. Le 6500 sup2T offre un support de L3VPNoMGRE en hardware, il ne faut pas avoir peur de perte de performance par rapport à du MPLS classique. La techno est également supportée dans nos routeurs d’accès ce qui nous donne une solution disponible entre site principal d’une entreprise et ses filiales.

Maintenant peut-on faire le L3VPNoMGRE au dessus de l’internet? Si la solution marche techniquement, on n’a pas de chiffrement des données (comme pour MPLS d’ailleurs). On privilégiera donc L3VPNoMGRE au dessus d’un transport privé, par exemple une L3VPN fourni par un opérateur. Le L3VPN de l’opérateur garantira un transport privé et le L3VPNoMGRE offrira la couche de virtualisation entre les différentes VRF au sein de l’entreprise. Grâce à L3VPNoMGRE pas besoin de MPLS CsC (carrier supporting carrier) pour ptolonger ses L3VPN donc et c’est tant mieux car rares sont les opérateurs qui offraient ce service!

Maintenant pour ce qui est du multicast a priori pas de problème car on sait faire depuis longtemps déjà des MVPN su un transport IP.

Références

http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_mplsvpnomgre.html

Authors

Jerome Durand

Technical Solutions Architect

Laisser un commentaire


2 commentaires