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 là 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
2 commentaires