DMVPN Phase 2 Fundamentals

Phase 2 DMVPN in a nutshell:

  • Multipoint GRE tunnels on all routers.
  • NHRP is used for dynamic spoke registrations (like with Phase 1 DMVPN), but also for on-demand resolution of spoke transport addresses.
  • Traffic between the spokes initially flows through the hub router until NHRP resolves the remote spoke transport IP address and IKE establishes the IPSec session with it.
  • The IP next-hop address for any prefix reachable over DMVPN must be the egress router (hub or spoke). From the routing perspective, Phase 2 DMVPN subnet should behave like a LAN.
  • Multicast packets (including routing protocol hello packets and routing updates) are exchanged only between the hub and the spoke routers.
  • Routing adjacencies are established only between the hub and the spoke routers unless you use statically configured neighbors.

For more details watch the DMVPN webinar webinar.

add comment

OSPF Configuration in Phase 1 DMVPN Network

This is how you configure OSPF in a Phase 1 DMVPN network (read the introductory post and Phase 1 DMVPN fundamentals first):

Remember:

  • Use point-to-multipoint network type on the hub router to ensure the hub router is always the IP next hop for the DMVPN routes.
  • Use point-to-multipoint network type on the spoke routers to ensure the OSPF timers match with the hub router.
  • The DMVPN part of your network should be a separate OSPF area; if at all possible, make it a stub or NSSA area.
  • If absolutely needed, use OSPF LSA flood filter on the hub router and a static default route on the spokes.

For more information, watch the DMVPN Technology and Configuration webinar.

see 4 comments

DMVPN Phase 1 Fundamentals

Phase 1 DMVPN in a nutshell:

  • Point-to-point GRE tunnel on spoke routers
  • Multipoint GRE tunnel on the hub router.
  • All the DMVPN traffic (including the traffic between the spokes) flows through the hub router.
  • On the spoke routers, the hub router must be the IP next-hop for all destinations reachable through the DMVPN subnet (including other spokes).
  • Multicast packets (including routing protocol hello packets and routing updates) are exchanged only between the hub and the spoke routers.
read more see 1 comments

Sometimes You Need to Step Back and Change Your Design

A few days ago I received the following e-mail from one of my readers:

I am trying presently to put in place a DMVPN solution running OSPF. I was wondering if you ever saw a solution with dual hub dual cloud design with OSPF working in practice because since I started I have issue with asymmetric routing because of the OSPF functionality.

Actually, I did… and exactly the same setup is included in the tested router configurations you get with the DMVPN: from Basics to Scalable Networks webinar. While there are many things that can go wrong with DMVPN, I’ve never heard about asymmetric routing problems, so I started to investigate what’s actually going on.

read more see 5 comments

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.

read more see 5 comments

Interesting links (2011-01-09)

Jedi Mind Tricks: HTTP Request Smuggling – an intriguing HTTP vulnerability and the countermeasure using ... what else ... F5.

Flailing IPv6 – up to 13% of IPv6 connections fail, mostly due to broken tunnels. Stop tunneling!

Cisco UCS criticism and FUD: Answered – another great article by @bradhedlund. Assuming he’s not making it up, some competitors must be really desperate.

Understanding Inter-Area Loop Prevention Caveats in OSPF Protocol – a masterpiece by @plapukhov. I thought I knew almost everything there is to know about OSPF. Boy was I wrong.

read more add comment

Campfire: the true story of MPLS

Just before 2010 disappeared, a tweet by my friend Greg @etherealmind Ferro triggered a minor twitstorm. He wrote:

If we had implemented IPv6 ten years ago, would we have MPLS today? I think not.

His tweet contains two major misconceptions:

  • MPLS was designed to implement layer-3 VPN services;
  • We wouldn’t need VPNs if everyone would be using global IPv6 addresses.

I’ll focus on the first one today; the inaccuracy of the second one is obvious to anyone who was asked to implement MPLS VPNs in enterprise networks to ensure end-to-end path separation between departments or users with different security levels.

read more see 5 comments

Interesting links (2011-01-02)

New Year Resolution #1: I shall clean my Inbox on a weekly basis. Here are the links that started gathering dust during the last week:

add comment

Cleaning the Inbox: Internet-related Links

Every Internet-related post is a great opportunity to increase comment count. I’ll pass this time, here are the articles I found interesting with little or no comments from my side. First the generic Internet:

And then my favorite controversy:

see 2 comments
Sidebar