Blog Posts in December 2012
When I’m asking the yearly subscribers whether they’d like to renew their subscription, I promise them new content every 2-3 months (4-6 new sessions per year). 2012 was definitely a good year in that respect.
It started with the access network part of large-scale IPv6 design and deployment webinar, then there were two Data Center Fabrics update sessions (in May and November), scalability part of the cloud computing networking webinar, and a DMVPN design session.
12 months and ~210 blog posts later, it’s time for yet another “That’s It” blog post. Another exciting year has swooshed by, and I’d like to thank you all for the insightful comments you made, the great questions you asked, and the wonderful challenges you keep sending me.
If at all possible, now’s the time to start shutting down the pagers and smartphones, and enjoy the simpler (and less stressful) life with the loved ones. Have a great holiday season and all the best in the coming year! I’m going offline ... right now ;)
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.
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!