MPLS/VPN over mGRE strikes again

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 (register here). 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.

If you attended the first session in December, download the updated PDF from my Webinar Management System.

5 comments:

  1. Do MPLS/VPN-over-mGRE and mVPN share the same or a similar architecture on the core side?
    Would the main difference be PE-router array determination?

    ReplyDelete
  2. There is no "core side" - it's pure IP forwarding beyond the PE-router.

    As far as I understand, both features use the same encapsulation and differ primarily in actual implementation and IOS configuration mechanisms. Do they interoperate? I would guess "yes" but would not bet my network design on it.

    ReplyDelete
  3. Considering that this architecture is refered to as MPLS/VPN I thought it'd be proper to call the P routers array the 'core side', backbone or P-Network (I prefer the latter).
    I thought of MPLS/VPN-over-mGRE and mVPN being similar as the GRE P-packets use IP
    only, be it public ip addresses or a SP MPLS backbone (IGP only/no LDP).
    I gotta reread your MPLS and VPN Architectures, II :-[

    ReplyDelete
  4. Considering that this architecture is refered to as MPLS/VPN I thought it'd be proper to call the P routers array the 'core side', backbone or P-Network (I prefer the latter).
    I thought of MPLS/VPN-over-mGRE and mVPN being similar as the GRE P-packets use IP only, be it public ip addresses or a SP MPLS backbone (IGP only/no LDP).
    I gotta reread your MPLS and VPN Architectures, II :-[

    ReplyDelete
  5. Interesting line of thought, but it just doesn't feel right, as the IP core has nothing to do with the MPLS forwarding. GRE is just an application as far as IP is concerned.

    Following the same argument you could call (traditional, not MPLS-enabled) ATM switches P-routers when there's an ATM VC linking two PE-routers. Or you could call IP routers "voice switches" just because they forward VoIP packets.

    On the other hand, RFC 4364 says "Routers in the SP's network that do not attach to CE devices are known as "P routers".", making your argument valid.

    However, RFC 4023 talks about "adjacent LSRs separated by IP network", raising the question whether a box must be an LSR to be called a P-router.

    Now I'm getting confused :-E

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.