Like many of us Khalid Raza wasted countless hours sitting in meetings discussing hybrid WAN connectivity designs using a random combination of DMVPN, IPsec, PfR, and one or more routing protocols… and decided to try to create a better solution to the problem.

Last week I ran the second part of the updated (4-hour) VXLAN webinar. The raw videos are already online and cover these topics:

• VXLAN-related technologies, including encapsulation, IP multicast use, unicast VXLAN, and VXLAN-over-EVPN;
• VXLAN implementations, including Cisco Nexus 1000v, VMware vCNS, VMware NSX, Nuage VSP and Juniper Contrail;
• VXLAN gateways, including Arista, Brocade, Cisco and Juniper;
• Hardware VTEP integration with OVSDB and EVPN;
• VXLAN-based data center fabrics, including Cisco’s ACI.

Most overlay virtual networking and cloud orchestration products support security groups – more-or-less-statefulish ACLs inserted between VM NIC and virtual switch.

The lure of security groups is obvious: if you’re willing to change your network security paradigm, you can stop thinking in subnets and focus on specifying who can exchange what traffic (usually specified as TCP/UDP port#) with whom.

MPLS bottom-of-stack bit confused one of my readers. In particular, he had a problem with the part where the egress MPLS Label Switch Router (LSR) should go from labeled (MPLS) to unlabeled (IPv4, IPv6) packets and had to figure out what was in the packet.

Last week Midokura decided to follow Juniper’s lead and make MidoNet an open-source product (after all, a similar move worked really well for Contrail, right?).

I may be too skeptical (again), but I fail to see how this could possibly work.

Imagine being an IT administrator running a multi-tenant enterprise environment (example: an SMB business center). How many things would you have to configure to add a new tenant? How about adding a new user for an existing tenant?

The engineers behind the scenes of FlipIT cloud service ended up with a 40-page configuration guide when they started the service years ago… and obviously decided full-blown automation is the only way to go.

I carried out an interesting quiz during one of my Interop workshop:

• How many use Linux-based servers? Almost everyone raised their hands;
• How many use Apache or Tomcat web servers? Yet again, almost everyone.
• How many run applications written in PHP, Python, Ruby…? Same crowd (probably even a bit more).
• How many use Nginx, Squid or HAProxy for load balancing? Very few.

Is there a rational explanation for this seemingly nonsensical result?

A while ago I had an interesting discussion with a fellow SDN explorer, in which I came to a conclusion that it makes no sense to insert an overlay virtual networking SDN controller between cloud orchestration system and virtual switches. As always, I missed an important piece of the puzzle: federation of cloud instances.

2014-11-04 16:48Z: CJ Williams sent me an email with information on SDN controller in upcoming Windows Server release. Thank you!

It doesn’t make sense to build a new data center network to support legacy bare-metal server infrastructure. You’ll have to use relatively expensive 1G/10G ports to be able to connect the current and future servers, and once the server and virtualization engineers wake up and do hardware refresh you’ll end up with way too many ports (oh, and you do know that transceivers could cost more than the switching hardware, right?).

It was a dark and stormy Halloween night and a networking engineer was stuck in a data center facing a Mission Impossible project: replace a failing Cat6500 with a brand-new Nexus 7000. Shouldn’t have been a problem, if only the cables were labeled.

If you listen to the marketing departments of overlay virtual networking vendors, it looks like the world is a simple place: you deploy their solution on top of any IP fabric, and it all works.

You’ll hear a totally different story from the physical hardware vendors: they’ll happily serve you a healthy portion of FUD, hoping you swallow it whole, and describe in gory details all the mishaps you might encounter on your virtualization quest.

The funny thing is they’re all right (not to mention the really fun part when FUDders change sides ;).

This post SHOULD have been published on April 1st, but I need to define the terminology for another upcoming post, so here it is ;)

RFC 2119 defines polite words to use when something really shouldn’t be done. Some network designs I see deserve more colorful terminology.

2014-11-02: Updated with reference to RFC 6919 (/HT to @LapTop006)

A year ago Matthew Stone first heard about Cumulus Linux when I ranted about it on a Packet Pushers podcast (which only proves that any publicity is good publicity even though some people thought otherwise at that time), and when his cloud service provider company started selecting ToR switches he considered Cumulus together with Cisco and Arista… and chose Cumulus.

In the third part of MPLS Tech Talks, we focused on the role of label distribution protocol (LDP) and its operation in frame-mode MPLS.

More than a year ago I wrote a response to a comment Pascal wrote on my Predicting the IPv6 BGP table size blog post. I recently rediscovered it and figured out that it’s (unfortunately) as relevant as it was almost 18 months ago.

Other people have realized we have this problem in the meantime, and are still being told to stop yammering because the problem is not real. Let’s see what happens in a few years.