Heavy Networking | September 25, 2015
Show 256 – Design & Build 6 – VXLAN Use Cases
Ethan
Banks
Greg
Ferro
Listen, Subscribe & Follow:
There’s a lot of talk in the industry about network virtualization. VXLAN is one of the encapsulation protocols you can use, and it’s the focus of today’s show.
We’ll discuss why you might want to virtualize your network, and why you’d use an overlay.
If you do go down this road, what are the design considerations you need to keep in mind as you put this system together? We’ll talk about VXLAN use cases, pros and cons, and debate the finer technical points of L2/L3 data center networking.
Three guests join us to delve into VXLAN:
Anthony Burke, Senior Systems Engineer, Network and Security Business Unit, VMware. He blogs at Network Inferno.
Richard Alexander, solutions director for Logicalis UK. You can find him at CXOunplugged.
Lukas Krattiger, Technical Marketing Engineer, Cisco Systems
Show Notes:
Use Cases – Why does an organization add overlays to their network?
- vMotion between DCs / L2 (contained in the overlay) vs L3 (unique address space between DCs)
- Similar to above, preserving L2 adjacency between services
- Allow mobility for apps
- VXLAN is not for compute virtualization only
- VXLAN is not DCI, but it helps
Components – What are the major elements for this solution?
- It’s just another overlay/encap type
- Understanding the VNID
- Rare that 802.1q 4096 isn’t enough in enterprises
- VTEPs
- Multicast “control plane” by default (i.e. no control plane) for VTEPs to learn location of endpoints (aka Flood&Learn)
Design Considerations
-Routing protocols are built for transporting routed protocols, now we put Layer 2 overlays on top (new requirements)
-As Layer 2 has (mostly) multi-destination traffic, unicast alone might not be good enough
-Some key requirements for Layer 3 underlay (Unicast, Multicast)
- Interface types
- IPv4, IPv6
- PIM ASM vs. BiDir and RP redundancy/load balancing
-Some key differentiators in regards to the Protocols (OSPF vs, IS-IS vs. EIGRP vs BGP)
-Differences between a Layer-3 Underlay vs. a Layer-3 Fabric (MSDCs)
-What if we put VXLAN on top?
- Unicast and Multicast specifics for VXLAN
- VTEP reachability
- BUM traffic
- Multicast vs. MP-BGP control plane for VXLAN
Links:
NSX for vSphere: VXLAN Control Plane modes explained – Dmitri Kalintsev
TCP/IP Over VXLAN Bandwidth Overheads – Steven Iveson
Show 233 – Cisco Nexus Using BGP As A VXLAN Control Plane – Sponsored – Packet Pushers
Share this episode
I can’t wait till a vendor says I have a protocol to change the MTU.
Oh wait that is SDN.
Cannot disagree more with Greg about IP Multicast! I love it! Works well in really advanced networks.
A discussion on performance would have been useful, I believe it’s pretty poor from a host perspective as NIC hardware offload can’t handle it. Perhaps not relevant here?
In one of his comments, Greg Ferro uses Professor Comer’s statement about how BGP is not a database (from an earlier podcast) as an argument against EVPN. I don’t think that is a valid argument. EVPN is not meant to distribute policies. It just distributes reachability information for MACs, which is comparable in functionality to distributing IP routes.
At 43:05, you are saying that using BGP in EVPN to propagate mac addresses “you will never get a signal back from the network saying yes i’ve got that information”. My understanding is that BGP updates are packed into TCP messages and TCP offers an acknowledgement mechanism that will you give a signal back. Could you please explain why you think and I quote you: “BGP is a near-enough design to run in a certain mode to propagate information if your lucky”?
Greg’s traveling this week, and I happened to notice this. I’ll make a stab at the answer. He can fill in the details if he has a chance.
Greg is using hyperbole to make a point. BGP was not designed as a database, and using it as such is stretching it beyond what is was designed to do, from his point of view. So, yes, TCP will confirm TCP messages were delivered, but packet delivery confirmation doesn’t prove that the BGP application did anything with the payload.
Ethan,
how is a mac-address different than a ip prefix (/32 if you’d like)? seems like a natural extension to me rather than inventing something else, which is more transactional (which is what Greg must be getting at i didn’t listen).
mac learning on a L2 device and arp are transactional either, so we would need new protocols there too or else you’re only fixing a fraction of a possible problem.
It isn’t especially different from my point of view, and I don’t feel that using BGP as a control plane in this way is a bad idea. BGP may not be the perfect solution, but it’s good enough. We understand how to configure it. BGP is available on most network devices. BGP is the tool at hand, and can get the job done. Thus, the industry is using it.
But that doesn’t mean that for transporting large numbers of records around with increasingly complex schemas and very little in the way of feedback loops is what BGP was designed to do back in the day. BGP is a highly scalable routing protocol — that is its core function. BGP was not designed to be a full-on database.
Now, consider that the computing world has changed. Far more computing power is available in modern control planes is available now than there ever used to be. So, perhaps it’s time for something better, as we think ahead to SDN ways of programming the forwarding plane?
I’ll see if I can get Greg to — in a non-ranty way — explain his point of view in more detail. There’s more to the logic than just “BGP is old.” It’s more about how BGP is being dragged along because it happens to be available, as opposed to it being the right solution in all the use-cases it has been applied to.
Ethan, I was confused about this too and talked to some of the software developers to get some clarifications. You are thinking about TCP and BGP as separate instances connected between each other but it is not the case. According to them, TCP and BGP will be created under a single PID and if the TCP connection is working properly so will the BGP application. The only case were TCP wouldn’t deliver the information to BGP, would be in the case of a bug in the software but it is highly unlikely since BGP has been in use and development for years. Hope I can get a different perspective on this from you.
Thank you
Ethan,
I am new to vxlan.
Got this question on implementing vxlan across to data centers.
Lets say I have clos fabric architecture in both DCs.And L3DCI between them.
When vxlan is deployed,do all vteps from both DCs form a single L2 domain with BGP-EVPN control plane spanning both DCs?
I still think that Extreme /Avaya give you much simpler and easy to deploy and understanding