Software-Defined Networking is clearly a tautological term – after all, software defined networking device behavior ever since we stopped using Token Ring MAUs and unmanaged hubs. Open Networking Foundation claims it owns the definition of the term (which makes approximately as much sense as someone claiming they own the definition of red-colored clouds), but I was always wondering who coined the term in the first place.

Gordon sent me a whole list of NSX gateway questions:

• Do you need a virtual gateway for each VXLAN segment or can a gateway be the entry/exit point across multiple VXLAN segments?
• Can you setup multiple gateways and specify which VXLAN segments use each gateway?
• Can you cluster gateways together (Active/Active) or do you setup them up as Active/Standby?

The answers obviously depend on whether you’re deploying NSX for multiple hypervisors or NSX for vSphere. Let’s start with the former.

Every time someone wonders about the viability of unicast reverse path forwarding (uRPF) as source address validation technique at the edge of an ISP network, someone else inevitably claims it can’t possibly work due to asymmetrical routing issues. Is the situation really so black-and-white?

Ed Horley wrote another great post arguing you don’t need Unique Local Addresses in an IPv6 network … and I couldn’t figure out what the problem was until I got the underlying context: it seems many engineers try to transplant their IPv4 mentality into IPv6 world and see ULAs as a nice replacement for RFC1918 with NAT66 or NPT66 on the private network edge. No wonder Ed argues against that.

A few days ago I described how most OpenFlow data center fabric solutions use out-of-band control plane (separate control-plane network). Can we do something similar when running OpenFlow switch (example: Open vSwitch) in a hypervisor host?

TL&DR answer: Sure we can. Does it make sense? It depends.

Someone left the following comment on one of my blog posts a few days ago:

IPv6 to a network engineer is like Communism to a Marxist. It would come in such a distant future that it would be in a form we can barely picture accurately. […] So my money is on NAT444, at least in the US.

Meanwhile on planet Earth (in 2014):

12 months, 260 blog posts, and a dozen of webinars … and it’s time for another end-of-year post. It’s amazing how quickly a year goes by when you have fun.

I’d like to thank you for your insightful comments, great questions you asked, and wonderful challenges you keep sending me … and special thanks to all of you who trusted me enough to buy my webinars or decided to rely on my professional judgment.

Don’t forget to shut down your pagers and smartphones (if at all possible), and enjoy the simpler (and less stressful) life with the loved ones. Have a great holiday season and all the best (including plenty of SDN fun) in the coming year!

As you know, I’m promising my subscribers 4-6 new sessions a year. 2013 definitely wasn’t a bad year in that respect ;)

The year started with IPv6 Transition Mechanisms, and virtual firewalls.

There was a deep dive into scale-out architectures and load balancing in April, and the mandatory Data Center Fabrics Update session in May.

TL&DR Summary: It depends on your business model

With the explosion of overlay virtual networking solutions (with every single reasonably-serious vendor having at least one) one might get the feeling that it doesn't make sense to build greenfield IaaS cloud networks with VLANs. As usual, there's significant difference between theory and practice.

You should always consider the business requirements before launching on a technology crusade. IaaS networking solutions are no exception.

2013 was definitely the year of overlay virtual networks, with every major networking and virtualization vendor launching a new product or adding significant functionality to an existing one. Here’s a brief overview of what they’re currently offering:

After my Clouds, Overlays and SDN: What really matters keynote presentation @ MENOG 12 a few attendees asked me for a recording; one of them said “I want everyone in my organization to watch it.” Alas, wishes don’t always come true: the video team was streaming the presentations, but not recording them.

Fortunately I had the same presentation @ PLNOG 11 and like always the PLNOG organizers did a marvelous job. The video has just been posted on YouTube. Enjoy!

Got a really interesting question from A. Reader: “When and how does VXLAN use IGMP and PIM in transport (underlay) networks?”

Obviously you need IGMP and PIM in multicast environments only (vCNS 5.x, Nexus 1000V in multicast mode).

It’s easy to say “SDN is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices,” handwave over the details, and let someone else figure them out. Implementing that concept in a reliable manner is a totally different undertaking.

A good friend of mine sent me an interesting question:

When I configure mpls ip on an interface, will all packets on that interface be labeled, or just the MPLS/VPN packets received through VRFs? I always assumed that stuff in the global routing table just got forwarded as IP packets without any labels.

Well, that’s not how MPLS works (at least not in its default incarnation on Cisco IOS).

Packet forwarding behavior of VMware NSX and Hyper-V Network Virtualization is well documented; no such documentation exists for Amazon VPC. However, even though Amazon uses a proprietary solution (heavily modified Xen hypervisor with homemade virtual switch), it’s pretty easy to figure out the basics from the observed network behavior and extensive user documentation.