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.

One of my readers sent me an interesting problem a few days ago: the BGP process running on a PE-router in his MPLS/VPN network preferred an iBGP route received from another PE-router to a locally sourced (but otherwise identical) route. When I looked at the detailed printout, I spotted something “interesting” – the pre-bestpath cost extended BGP community.

Last week’s IPv6 summit organized by Jan Žorž was probably one of the best events to attend for engineers interested in real-life IPv6 deployment experience. Some of the highlights included:

• IPv6: Past, Present and Future by Robert Hinden, one of the creators of IPv6;
• Cisco’s IPv6 deployment experiences by Andrew Yourtchenko, technical leader @ Cisco;
• IPv6 deployment in Yahoo by Jason Fesler, distinguished architect @ Yahoo;
• Lessons learned while deploying IPv6 in US Government by Ron Broersma, Network Security Manager @ SPAWAR;
• IPv6 implementation in Time Warner Cable by their director of technology development: Lee Howard of the CGN-is-too-expensive fame.

Enjoy! ... and thank you, Jan, for an excellent event.

During last week’s IPv6 Summit I presented an interesting idea first proposed by Tore Anderson: let’s skip all the transition steps and implement IPv6-only data centers.

You can view the presentation or watch the video; for more details (including the description of routing tricks to get this idea working with vanilla NAT64), watch Tore’s RIPE64 presentation.

One of my readers sent me a great question:

I agree with you that L2 DCI is like driving without a seat belt. But is L3 DCI safer in case of DCI link failure? Let's say you have your own AS and PI addresses in use. Your AS spans multiple sites and there are external BGP peers on each site. What happens if the L3 DCI breaks? How will that impact your services?

Simple answer: while L3 DCI is orders of magnitude safer than L2 DCI, it will eventually fail, and you have to plan for that.

Supposedly it’s a good idea to be able to identify which one of your users had a particular IP address at the time when that source IP address created significant havoc. We have a definitive solution for the IPv4 world: DHCP server logs combined with DHCP snooping, IP source guard and dynamic ARP inspection. IPv6 world is a mess: read this e-mail message from v6ops mailing list and watch Eric Vyncke’s RIPE65 presentation for excruciating details.

During a recent consulting engagement I had an interesting conversation with an application developer that couldn’t understand why a fully redundant data center interconnect cannot guarantee 100% availability.