3

For example, we have small DC1 and decide to make another DC2 in 20km far from DC1 and connect these DCs via dark fiber. For VM Mobility we should extend L2 segment between these DC. I know, that is bad idea cause one failure domain, and good solution in that situation is to not extend L2. Is it very bad if we make simple trunk port between these DC and allow needed VLANs on? I know broadcast storm in that VLAN on DC1 will affect on DC2 too. Can VXLAN resolve broadcast storm problem? What will do VTEP with broadcast storm traffic? Is it encapsulate it to IP and send to another VTEP or have any mechanism to drop it?

Improve this question
2
  • 1
    What sort of speed are you planning to run down the fibre link?
    – jonathanjo
    Commented Mar 20, 2018 at 19:50
  • 2
    Layer-2 across a WAN link is like drugs: Just say, "NO!"
    – Ron Maupin ♦
    Commented Mar 20, 2018 at 20:18

2 Answers 2

Reset to default
5

"VXLAN" by itself is kind of meaningless. It's an encapsulation mechanism. Depending on the control plane and implementation in use it can be used to bridge L2 over L3 networks, provide multi-tenant L3 routing (again, over an L3 underlay) or even provide some measure of traffic engineering. There are a bunch of really key differences between various control planes for VXLAN - ranging from flood-and-learn (VTEP's flooding via an underlay to build a forwarding table) to proprietary/open SDN approaches to EVPN (BGP-based control plane).

The last option (EVPN) is potentially useful, as it removes the need for excessive underlay flooding and is generally a lot more deterministic / controllable at scale. I've traditionally been hesitant about deploying EVPN outside of DC fabrics, as there tends to be a common failure domain in a single BGP / VTEP cluster but there has been some recent work done for multi-site EVPN. The basic idea is that the fabrics at two sites operate their own respective underlays (usually a local RR cluster and underlay reachability) with a site-to-site provisioned connection between spines (w/EBGP) to provide clear separation. You can think of it as automated VXLAN stitching between the two local domains and an inter-site. This provides some much-needed abstraction and hierarchy.

Now...that said, L2 extension is often the least difficult technology in the stack when compared to keeping storage appropriately synchronized, network services (FW, IDS, load balancer) properly set up, managing asymmetric routing, etc. Some of the gyrations I've seen folks get through trying to get active/active firewall gateways going between geographically dispersed data centers are the stuff of nightmares and the potential troubleshooting woes in a properly configured multi-site setup can be exponentially worse than just running a secondary site with appropriate scripting and a nice, healthy L3 boundary.

So... VXLAN-EVPN will get frames back-and-forth between sites reasonably efficiently, localize first-hop routing (i.e. anycast gateways) and (with some implementations) both locally proxy ARP and provide fabric-wide IGMP/MLD snooping but it inherently can't speak to all the nasty problems around that extended LAN...

If you're curious, here is a link to a whitepaper written by the folks at Cisco about the multi-site extensions I allude to above, most of which are currently in the standards bodies for review.

Improve this answer
5

VXLAN is L2 bridging over IP/UDP, so in short: no, it won't save you from a broadcast storm.

There are a few things you can do to avoid broadcast storms from happening:

  • make sure you implement (M/R)STP in your L2 zones to avoid bridge loops
  • consider limiting broadcasts for misbehaving devices
  • limit broadcasts on or before the VXLAN links/end points - unless you limit them in some way, broadcasts will just get tunneled and sent over
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.