Blog Posts in August 2012
Almost everyone agrees the current way of implementing virtual networks with dumb hypervisor switches and top-of-rack kludges (including Edge Virtual Bridging – EVB or 802.1Qbg – and 802.1BR) doesn’t scale. Most people working in the field (with the notable exception of some hardware vendors busy protecting their turfs in the NVO3 IETF working group) also agree virtual networks running as applications on top of IP fabric are the only reasonable way to go ... but that’s all they currently agree upon.
Very short answer: no.
You might think that layer-3 switches perform bridging and routing, while routers do only routing. That hasn’t been the case at least since Cisco introduced Integrated Routing and Bridging in IOS release 11.2 more than 15 years ago. However, Simon Gordon raised an interesting point in a tweet: “I thought IP L3 switching includes switching within subnet based on IP address, routing is between subnets only.”
Layer-3 switches and routers definitely have to perform some intra-subnet layer-3 functions, but they’re usually not performing any intra-subnet L3 forwarding.
When VXLAN came out a year ago, a lot of us looked at the packet format and wondered why Cisco and VMware decided to use UDP instead of more commonly used GRE. One explanation was evident: UDP port numbers give you more entropy that you can use in 5-tuple-based load balancing. The other explanation looked even more promising: VXLAN and OTV use very similar packet format, so the hardware already doing OTV encapsulation (Nexus 7000) could be used to do VXLAN termination. Boy have we been suckered.
Update 2015-07-12: NX-OS 7.2.0 supports OTV encapsulation with VXLAN-like headers on F3 linecards. See OTV UDP Encapsulation for more details (HT: Nik Geyer).
Yesterday I got pulled into a layer-2 DCI tweetfest. Not surprisingly, there were profound opinions all over the place, including “We've been doing it (OTV) for almost a year now. No problems.”
OTV is in fact the least horrible option – it does quite a few things right, including tight control of unicast flooding and reduction of STP scope.
You might as well ask why people insist on not wearing seatbelts after all of the years that particular technology has been proven to save lives.
People will, it seems, persist in the optimistic belief that everything will be OK so long as they are otherwise careful. They think that bad things happen only to other people’s protocols, or packets, but not to theirs. Hope springs eternal and dies in the cold, cold winter of experience.
Finding this one a day after discussing layer-2 DCI? There really are no coincidences.
A while ago, a tweet praising the wonders of 802.1BR piqued my curiosity. I couldn’t resist downloading the latest draft and spending a few hours trying to decipher IEEE language (as far as the IEEE drafts go, 802.1BR is highly readable) ... and it was déjà vu all over again.
Short summary: 802.1BR is repackaged and enhanced 802.1Qbh (or the standardized version of VM-FEX). There’s nothing fundamentally new that would have excited me.
As far as I understand, VXLAN, NVGRE and any tunneling protocol that use global ID in the data plane cannot support PVLAN functionality.
He’s absolutely right, but you shouldn’t try to shoehorn VXLAN into existing deployment models. To understand why that doesn’t make sense, we have to focus on the typical cloud application architectures.
Short summary: everything works as expected on ASR 1K running IOS XE 3.7.
Keith sent me a set of Mobile ARP questions, starting with “What’s your view on using Mobile ARP in a large enterprise?”
Short summary: Mobile ARP is an ancient technology that was designed to solve a problem that disappeared with deployment of DHCP. Now let’s look at the bigger picture.
I got too many questions like this … but interestingly never during a webinar ;)
Brian Christopher Raaen asked a great question in a comment to my OpenStack/Quantum SDN-Based Virtual Networks post:
Other than some syntax difference what do these new HTTP-based APIs add that SNMP couldn’t already do?
Short answer: In theory nothing, apart from familiarity and convenient programming libraries. In practice, there’s a huge gap between theory and practice. See “Hands-on experience” at the bottom of the article.
I’d promised to record another MPLS-related podcast and wanted to refresh my failing memory and revisit the beginnings of Tag Switching (Cisco’s proprietary technology that was used as the basis for MPLS). Several companies were trying to solve the IP+ATM integration problem in mid-nineties, most of them using IP-based architectures (Cisco, IBM, 3Com), while Ipsilon tried its luck with a flow-based solutions.
Most current SDNish tools are too cumbersome for everyday use: OpenFlow is too granular (the controller interacts directly with the FIB or TCAM), and NETCONF is too coarse (it works on the device configuration level and thus cannot be used to implement anything the networking device can’t already do). In many cases, we’d like an external application to interact with the device’s routing table or routing protocols (similar to tracked static routes available in Cisco IOS, but without the configuration hassle).
The usual claim that “IPv6 has better security because it includes mandatory IPsec support” is evidently creating some confusion, at least based on a set of questions I received from one of my readers.
Can IPv6 work without IPsec?
Absolutely. Most IPv6 deployments don’t use IPsec (unless you’re building IPsec-based VPNs over IPv6 transport infrastructure).
I often get three questions about TRILL: Are the TRILL standards finalized? Has anyone implemented it? Is it useful?
Short answers: Yes, No, Maybe (although I remain unconvinced).
A week ago a friend sent me a disturbing email: another creative individual has decided to use my content to attract traffic, this time making sure to remove all the links and even the webinar introductions before republishing it. As expected, the well-populated web site had no about or contact me links, and the domain name registrant was an obvious fake.
Ahmed was reading my EIGRP book (I know it’s hard to get, but fortunately he found a well-marked copy) and wanted to check his understanding of how EIGRP works. The first question was as good a summary as I’ve ever seen:
Does it just simply boil down to the fact that a router will choose not to have anything to do with a reported distance higher than its own cost to that route (feasible distance) for the (paranoid) fear that it could be a loop?
Next, he started wondering why a router would behave that way:
A few years before MPLS/VPN was invented, I’d worked with a service provider who wanted to offer L3-based (peer-to-peer) VPN service to their clients. Having a single forwarding table in the PE-routers, they had to be very creative and used ACLs to provide customer isolation (you’ll find more details in the Shared-router Approach to Peer-to-peer VPN Model section of my MPLS/VPN Architectures book).
Now, what does that have to do with OpenFlow, SDN, Floodlight and Quantum?