In August 2011, when NVGRE draft appeared mere days after VXLAN was launched, I dismissed it as “more of the same, different encapsulation, vague control plane”. Boy was I wrong … and pleasantly surprised when I figured out one of the major virtualization vendors actually did the right thing.

TL;DR Summary: Hyper-V Network Virtualization is a layer-3 virtual networking solution with centralized (orchestration system based) control plane. Its scaling properties are thus way better than VXLAN’s (or Nicira’s … unless they implemented L3 forwarding since the last time we spoke).

Justin asked an interesting question in a comment to my IPv6 On-Link Determination post: do we need HSRP for IPv6 as the routers already send out RA messages? Pavel quickly pointed out that my friend @packetlife already wrote about it, concluding that you could use RAs unless you need deterministic sub-second failover.

However, there are (as always) a few more gotchas:

When testing the OSPF graceful shutdown feature, I’ve encountered an interesting OSPF feature: if you force a change in LAN DR router (other than rebooting the current DR), you’ll end up with two network LSAs describing the same LAN.

For example, if you force the B2 router in the following network to relinquish its DR status (by setting ip ospf priority 0 on the interface), B1 will take over and generate another network LSA (as expected), but the network LSA generated by B2 will stay in the database for a while and both routers will claim they are connected to both network LSAs.

Will made an interesting comment to my Stackable Data Center Switches article: “Who the heck has 16 uplinks?” Most of us do in the brave new 10GE world.

The second scenario Brad Hedlund described in the Clos Fabrics Explained webinar is a large leaf-and-spine fabric using 10GE uplinks and QSFP+ breakout cables between leaf and spine switches (thus increasing the number of spine switches to 16).

Ronald sent me an interesting question: What's the point of having a secondary path set up for a certain LSP, when this LSP also has fast-reroute enabled (for example, with the Junos fast-reroute command)?

The idea of having a pre-established secondary LSP backing up a traffic engineering tunnel was commonly discussed before FRR was widely adopted, but should have quietly faded away by now.

A while ago I wrote a blog post about remote ND attacks, which included the idea of having /120 prefixes on server LANs. As it turns out, it was a bad idea, and as nosx pointed out in his comment: “there is quite a long list of caveats in all vendor camps regarding hardware in the last 6-8 years that has some potentially painful hardware issues regarding prefix length. Classic issues include ACL construction and TCAM specificity.”

One would hope that the newly-release data center switches fare better. Fat chance!

Mark Berly, the guest star of my VXLAN Technical Deep Dive webinar focused on VXLAN gateways. Here’s the first part of his presentation, explaining what VXLAN gateways are and where you’d need them.

Imagine you have a typical 2-tier data center network (because 3-tier is so last millennium): layer-2 top-of-rack switches redundantly connected to a pair of core switches running MLAG (to get around spanning tree limitations) and IP forwarding between VLANs.

Next thing you know, a rep from your favorite vendor comes along and says: “did you know you could connect all ToR switches into a virtual fabric and manage them as a single entity?” Is that a good idea?

When an IPv4/IPv6 host wants to send a packet to another host, it has to answer the following simple questions:

• Can I reach the destination IP address directly (is the destination on the same LAN/subnet)?
• If not, who will help me forward the packet (who is the first-hop router)?

In IPv4 world, the host can get all the information it needs through DHCP. In IPv6 world, things are way more complex (but also way more correct if you’re a theoretician).