More than five years after the MPLS/VPN-in-mGRE encapsulation was standardized (add a few more years for the work-in-progress and IETF draft stages), it finally debuted in a mainstream-wannabe IOS release running on ISR routers (15.1(2)T), making it usable for the enterprise WAN designers, who are probably its best target audience.

I was writing about the two conflicting MPLS/VPN over mGRE implementations a while ago and got the impression the Service Providers aren’t too excited about this option. No wonder – most of them use full-blown MPLS backbones, so they have no need for GRE tunnels.

I always thought the MPLS-over-mGRE encapsulation would be more useful in an enterprise environment, but the feature just wasn’t supported on the right platforms (it’s somewhat hard to build a whole enterprise network using just the 7600s and 7200s). All that has changed with the 15.1(2)T release, which allows you to run MPLS/VPN-over-mGRE on ISR and ISR-G2 routers (I got it up and running on a bunch of 2800s in less than half an hour, including the software upgrade).

MPLS/VPN-over-mGRE gives you a lightweight MPLS/VPN transport directly between the PE-routers without the need to configure end-to-end MPLS in your WAN backbone or GRE tunnels on the PE-routers. All you need is VPNv4-enabled BGP infrastructure; the mGRE tunnel interface needed by this feature is created automagically by Cisco IOS and the GRE encapsulation is quietly performed behind-the-scenes – the CEF entries for the remote VPN destinations point to the hidden tunnel interface, the GRE next-hop is set to the BGP next-hop and the MPLS label applied on the ingress PE-router is taken directly from the VPNv4 BGP route.

The following printouts were taken from my simple lab network. Remote PE-router with loopback IP address 172.16.0.12 is advertising a VPN prefix 10.0.0.2/32. The VPNv4 BGP route goes through a route reflector with IP address 172.16.0.11.

Here’s the detailed information about the VPNv4 BGP route (BGP next hop and remote MPLS label are highlighted) ...

b2#show bgp vpnv4 unicast all 10.0.0.2
BGP routing table entry for 65000:1:10.0.0.2/32, version 7
Paths: (1 available, best #1, table Client)
  Not advertised to any peer
  Local
    172.16.0.12 (metric 53) (via Tunnel0) from 172.16.0.11 (172.16.0.11)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65000:1
      Originator: 172.16.0.12, Cluster list: 172.16.0.11
      mpls labels in/out nolabel/16

... and this is the CEF entry in the VRF CEF table:

b2#show ip cef vrf Client 10.0.0.2
10.0.0.2/32
  nexthop 172.16.0.12 Tunnel0 label 16

Use case

MPLS/VPN-over-mGRE is the ideal transport solution when you have to deploy any-to-any VPN between sparse PE-routers connected to a core IP-only backbone.

Example: your enterprise network has to provide connectivity to a spin-off organization that has its offices located at several sites. You have to isolate them from the rest of the enterprise network (thus the need for MPLS/VPN) and you usually have to provide them with minimum-latency any-to-any connectivity; the delay of going through a set of central routers in a hub-and-spoke MPLS/VPN-over-GRE scenario is often prohibitively high in large-scale networks.

More information

MPLS/VPN-over-mGRE is just one of many WAN transport solutions described in my Enterprise MPLS/VPN Deployment webinar. The webinar also covers MPLS/VPN transport across:

• Serial links, Frame Relay and ATM;
• Switched Ethernet, including pseudowires and VPLS services;
• GRE tunnels, including IPSec-protected GRE tunnels;
• DMVPN, including three methods of running MPLS/VPN over Phase 2 DMVPN networks with direct spoke-to-spoke connectivity.