In a comment to the Firewalls in a Small Private Cloud blog post I wrote “VXLAN is NOT a viable inter-DC solution” and Jason wasn’t exactly happy with my blanket response. I hope Jason got a detailed answer in the VXLAN Technical Deep Dive webinar, here’s a somewhat shorter explanation.

In the Clos Fabrics Explained webinar I focused on the Clos fabrics principles of operation and design options, and Brad Hedlund who graciously agreed to be my guest explained how you can use Dell Force10 switches to build them. In this video he’s describing a simple leaf-and-spine topology with 40GE uplinks.

An incredible amount of IPv6 deployment documents has been published as IETF drafts recently, amongst them:

• Operational security considerations for IPv6 networks
• Design guidelines for IPv6 networks
• Stateless IP/ICMP Translation in IPv6 Data Centre Environments (aka IPv6-only data centers)
• Enterprise IPv6 Deployment Guidelines

Enjoy ... and don’t forget to join the v6ops mailing list ;)

Kaage added a great comment to my Virtual Firewall Taxonomy post:

And many of physical firewalls can be virtualized. One physical firewall can have multiple virtual firewalls inside. They all have their own routing table, rule base and management interface.

He’s absolutely right, but there’s a huge difference between security contexts (to use the ASA terminology) and firewalls running in VMs.

I’m exposed to an incredible variety of topics in my ExpertExpress engagements, but there are always a few recurring themes, one of them being “we’re experiencing long convergence times and high packet loss after our primary Internet link fails.” Almost always the root cause turns out to be full Internet routing table being received on inadequate hardware.

The murky details of IPv6 implementations never crop up till you start deploying it (or, as Randy Bush recently wrote: “it is cheering to see that the ipv6 ivory tower still stands despite years of attack by reality”).

Here’s another one: in theory the prefixes delegated through DHCPv6 should be static and permanently assigned to the customers for long periods of time.

Based on readers’ comments and recent discussions with fellow packet pushers, it seems the marketing departments and industry press managed to thoroughly muddy the virtualized security waters. Trying to fix that, here’s my attempt at virtual firewall taxonomy.

Jernej Horvat sent me the following question:

I know DHCPv6-based prefix delegation should be as stable as possible, so I plan to include the delegated prefix in my RADIUS database. However, for legacy reasons each username can have up to four concurrent PPPoE sessions. How will that work with DHCPv6 IA_PD?

Short answer: worst case, DHCPv6 prefix delegation will be royally broken.

Similar to Data Center and DMVPN trilogy, I bundled the core IPv6 webinars into IPv6 trilogy. Following the great example set by Douglas Adams, the trilogy has four webinars (the real reason: it’s not likely someone would need both Enterprise and Service Provider introductory webinar).

Mrs. Y, the network security princess, sent me an interesting design challenge:

We’re building a private cloud and I'm pushing for keeping east/west traffic inside the cloud. What are your opinions on the pros/cons of keeping east/west traffic in the cloud vs. letting it exit for security/routing?

Short answer: it depends.

Thomas wanted to check whether the IP traffic is actually delivered to a remote site and sent me the following question:

I would like to know whether the packets I sent from site A to site B have been received. I don't want to create test traffic using ip sla, I would like to know that the production traffic has been delivered. I could use ACL counters but I'm running a full mesh of tens of sites. Ipanema does this very well, but I'm surprised that this doesn’t exist on Cisco IOS.

Short answer: that’s not how Internet works.

A reader of my blog experienced problems setting no-export BGP community. Here’s a quick how-to guide (if you’re new to BGP, you might want to read BGP Communities and BGP and route maps posts first).

Somehow I got involved in an IPv6 RADIUS accounting discussion. This is what I found to work in Cisco IOS release 15.2(4)S:

Years ago the IT of the organization I worked for assigned a /28 to my home office. It seemed enough; after all, who would ever have more than ~10 IP hosts at home (or more than four computers at a site).

When the number of Linux hosts and iGadgets started to grow, I occasionally ran out of IPv4 addresses, but managed to kludge my way around the problem by reducing DHCP lease time. However, when the start of school holidays coincided with the first snow storm of the season (so all the kids used their gadgets simultaneously) it was time to act.

Dumlu Timuralp (@dumlutimuralp) sent me an excellent question:

I always get confused when thinking about IP multicast traffic over VXLAN tunnels. Since VXLAN already uses a Multicast Group for layer-2 flooding, I guess all VTEPs would have to receive the multicast traffic from a VM, as it appears as L2 multicast. Am I missing something?

Short answer: no, you’re absolutely right. IP multicast over VXLAN is clearly suboptimal.