Last days I was eating, drinking, breathing and dreaming DMVPN as I was preparing lab scenarios for my DMVPN webinar (the participants will get complete router configurations for 12 different scenarios implemented in an 8-router fully redundant DMVPN network).

Some of the advanced scenarios were easy; for example, I’ve found a passing reference to passive RIPv2 with IP SLA in the DMVPN/GETVPN Design & Case Study presentation (lost in the mists of time). I knew exactly what the author had in mind and was able to create a working scenario in minutes. Unfortunately, 2-tier hub site with IPSec offload was a completely different beast.

It looks like the signed DNS root zone might finally get deployed on July 15th and Geoff Huston celebrates the fact with a lengthy article on DNSSEC. Just in case you’re not aware what DNSSEC is all about, he’s providing this nifty summary:

A succinct summary of the problem that DNSSEC is intended to address is that DNSSEC is intended to protect DNS clients from believing forged DNS data.

Read the rest of the article on his blog.

When Cisco started preaching about Borderless Networks a few months ago, we all knew the term Borderless Networks was a new fuzzily-defined paradigm revolving around the facts that:

• People want to use their smartphones (and other mobile devices) to access the corporate data from anywhere at any time.
• Employees have started to use third-party cloud services with unproven security or reliability without coordination with corporate IT or Security.

However, when Cisco Press launched the Securing the Borderless Network book (with the subtitle Security for the Web 2.0 World), I was hoping to get some insight into what Cisco really means with the Borderless Networks paradigm. I was also expecting some hard technical facts and solutions for the problems pestering all of us.

One of the scenarios I’m discussing in the DMVPN webinar is redundant DMVPN network with two ISPs. It’s not a particularly complex setup, unless the ISPs decide to deploy anti-spoofing filters (more precisely: unicast RPF checks) in which case it becomes crucially important which outbound interface you use for your DMVPN tunnel.

Anyhow, I was trying to make the whole thing work in a lab and it was repeatedly failing, so I decided to log uRPF violations. According to the documentation, it’s a piece of cake:

During the last Google IPv6 Implementors Conference Donn Lee from Facebook showed how easy it is to make your content available over IPv6 and LISP ... if you happen to have the right load balancer that supports IPv6 (to view his presentation, click the slides link next to his name in the conference agenda). I would say all the excuses why your content cannot be possibly made available over IPv6 are gone (and one can only hope that a certain vendor I’m often mentioning will finally realize IPv6 is needed on more boxes than just routers and switches).

In the recent months, there’s been a lot of buzz about next-generation Data Center bridging, including the Earth Is Flat rediscovery from Brocade (I thought that was settled in middle ages) and a TRILL article in SearchNetworking (which quoted both Greg and me as being on the opposite sides of the TRILL debate).

The more I think about this problem, the more I’m wondering whether we really need large-scale bridging in data centers (it looks like Google can live quite happily without it). We definitely need some bridging, but generic large-scale inter-site monstrosity? I doubt.

Please try to help me: forget all the “this is how we do it” presumptions, figure out a scenario where you absolutely need bridging and describe it in the comments.

Cisco has introduced Tunnel Route Selection, another “somewhat” underdocumented feature in IOS release 12.4(11)T (reading the sparse documentation, it appears to be a half-baked kludge implemented for a specific customer). I was wondering for a long time why I would ever want to use this feature, until Floris Martens asked me a question about a redundant DMVPN network using two ISPs, and all of a sudden it all made a perfect sense.

If you want to influence traffic flow in a network, you might want to tweak routing protocol metrics to shift the traffic between paths of almost-equal cost (I would always prefer MPLS Traffic Engineering as it’s so much better, but sometimes changing a metric is faster than rebuilding your network). OSPF and IS-IS are easy: change the interface metric or interface bandwidth. EIGRP and its composite metric are trickier.

As you know, EIGRP vector metric has five components; two of which are usually ignored and MTU serves only as tie breaker. This leaves us with bandwidth and delay. Every EIGRP reference tells you to adjust interface delay, not bandwidth, and the simplistic explanation is that “bandwidth is used for QoS features, so it’s better left unchanged”. While that’s true, there are other more important reasons to focus on delay:

To understand the principles of DMVPN Phase I, remember these facts:

My long-time friend Anne Johnson has published a link to Vijay Gill’s keynote presentation in her short summary of NANOG 49. Vijay has an interesting problem: Google’s infrastructure is so huge that he has no time for fancy toys or complex solutions; keeping the simple stuff running is hard enough. I love his rephrasing of the KISS principle (renamed to Worse is Better):