Category: workshop

TL;DR: I'll be in Bern on September 9th. If you'd like to drop by and discuss network design or automation challenges, read on…

There are tons of SDN workshops, academies, and webinars out there, many of them praising the almost-magic properties of the new technologies, or the shininess of vendors’ new gadgets and strategic alliances. Not surprisingly, the dirty details of real-life deployments aren’t their main focus.

As you might expect, my 2-day workshop isn’t one of them.

One of my readers sent me an interesting question:

How does one impose a security policy on servers connected via a Clos fabric? The traditional model of segregating servers into vlans/zones and enforcing policy with a security device doesn’t fit here. Can VRF-lite be used on the mesh to accomplish segregation?

Good news: the security aspects of leaf-and-spine fabrics are no different from more traditional architectures.

Brook Reams sent me an interesting tidbit: Brocade is the first vendor that actually shipped a VXLAN VTEP controlled by a VMware NSX controller. It’s amazing to see how Brocade leapfrogged everyone else (they also added tons of other new functionality in NOS releases 4.0 and 4.1).

When I first heard about NFV, I thought it was just another steaming pile of hype designed to push the appliance vendors to offer their solutions in VM format. After all, we’re past the hard technical challenges: most appliances deserve to have an Intel Inside sticker, performance problems have been addressed (see Intel DPDK, 6WIND, PF_ring and Snabb Switch), so what’s stopping us from deploying NFV apart from stubborn vendors who want to sell hardware, not licenses?

In the first half hour of the Infrastructure for Private Clouds workshop at last week’s Interop Las Vegas I focused on business aspects of private cloud design: defining the customers, the services, and the level of self-service you’ll offer to your customers.

Nick Martin published a great summary of these topics @ SearchServerVirtualization; I couldn’t have done it better myself (they want to get your email address, but this article is definitely worth it).

If you plan to attend the Troopers 2014 conference in two weeks, don’t forget to include my full-day SDN workshop on Tuesday in your agenda (the Troopers conference is sold out, but you can still register for the workshop). The topics of the workshop will include:

• Why do we need SDN and what is it?
• OpenFlow, its advantages, drawbacks and scalability challenges;
• Typical OpenFlow and SDN deployment considerations;
• Real-life SDN use cases, both OpenFlow- and non-OpenFlow ones;
• Network function virtualization;
• Software-defined data centers.

For more details, check out the workshop description; for other SDN-related materials visit my SDN Resources page.

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.

Initial release of Hyper-V Network Virtualization (HNV) was an add-on to the Hyper-V Extensible Switch, resulting in an interesting mixture of bridging and routing. In Windows Server 2012 R2 the two components became tightly integrated, resulting in a pure layer-3 solution.

Every time I talk about small (per-application) virtual appliances, someone inevitably cries “And who will manage thousands of appliances?” Guess what – I’ve heard similar cries from the mainframe engineers when we started introducing Windows and Unix servers. In the meantime, some sysadmins manage more than 10.000 servers, and we’re still discussing the “benefits” of humongous monolithic firewalls.

Last week I explained how layer-2 and layer-3 packet forwarding works in VMware NSX – a solution that closely emulates traditional L2 and L3 networks. Hyper-V Network Virtualization (HNV) is different – it’s almost a layer-3-only solution with only a few ties to layer-2.

In the first Terastream blog post I mentioned Deutsche Telekom decided to use an IPv6-only access network. Does that mean they decided to go down the T-Mobile route and deployed NAT64 + 464XLAT? That combo wouldn’t work well for them, and they couldn’t use MAP-E due to lack of IP address space, so they deployed yet another translation mechanism – Lightweight 4over6.

The easiest way of connecting overlay virtual networks implemented with VMware NSX for vSphere to the outside world is NSX Edge Services Router. It’s a much improved version of vShield Edge and provides way more than just layer-3 forwarding services – it’s also a firewall, load balancer, DHCP server, DNS forwarder, NAT and VPN termination device.

Dan sent me the following question:

I had another read of the ‘Building IPv6 Service Provider Networks’ material and can see the PE routers use site local ipv6 addressing. I’m about to build another small service provider setup and wondered: would you actually use site local for PE loopbacks etc, or would you use ULA or global addressing? I’m thinking ULA would be better from a security point of view?

TR&DR summary: Don’t do that.

Even though I questioned the wisdom of writing your own network programming applications, I know I would immediately jump into those waters if I were 20 years younger. If you’re like my younger self, you might want to keep a few guidelines in mind.