Re: Information on VXLAN implementations (and other guest isolation methods)
Andrija, cool stuff.
Do you run it with multicast or BGP EVPN? Looks like multicast is not the
best approach for large-scale deployments.
ср, 14 нояб. 2018 г. в 13:38, Andrija Panic <andrija.panic@xxxxxxxxx>:
> Simon just explained it well - and a few additions from my side, in case it
> Read details in this page, in order to avoid some hard issues during later
> production (beside MTU, check the max_igmp_membership etc...)
> Here is example from one of my dev setups, if that helps - but it boils
> down to what Simon shared.
> bond0.150 is the vlan 150 that is dedicated to carry all VXLAN "tunnels"
> (it HAS to have the IP, it serves as VTEP basically) - you would probably
> want to define this as separate PHYSICAL NETWORK during zone provisioning
> (because other networks i.e. management, storage, public doesn't support
> vxlan as isolation method) - so you define "bond.150" as the KVM traffic
> label for Guest Network
> (FYI: you could also create bridge cloudXYZ that has bond0.150 as member
> and use this as KMV traffic label, but cloudstack will just extract child
> interface, bond0.150 and create later the structure on its own - while
> cloudXYZ bridge is NOT used anywhere else)
> So my setup, bond0.150. Cloudstack needs to create i.e. vxlan structure
> with vxlan id 9999, so it will take bond0.150 and create VXLAN interface on
> top of it (ip -d link show vxlan9999, to see it's properties ....)
> After cloudstack has created a vxlan interface (on top of you vlan
> interface), it will then create a bridge (brvx-9999) and finally join vm's
> NIC to this bridge so both vxlan interface and VMs vNIC will be part of
> That's it - works well as Simon said, last 4 years in production with
> Here is any UGLY but informative drawing from my side :)
> So you can see tunnels etc. On the picture are also some other networks
> like public network on vlan 160 etc...
> (images on Simon's link are excellent, just old bridge names)
> In case you use VXLAN for Guest networks (VPC networks, isolated, etc) -
> make sure to understand that Private Gateway network only supports VLAN,
> not VXLAN, it's usefull to know, since I later had to add new physical
> networks to support Private Gateway (didn't plan originally for it).
> On Wed, 14 Nov 2018 at 18:29, Simon Weller <firstname.lastname@example.org>
> > Hi Alexandre,
> > VXLAN on KVM works very well and we've had it in production for a number
> > of years now.
> > Please see this document on how it is implemented:
> > Cloudstack does create all the VXLAN configuration for each new network,
> > you just need to have a working underlay that supports multicast (e.g.
> > IP on the VXLAN interface and iptables rules rules that allow multicast
> > traffic).
> > We place our VXLANs into a VLAN and expose that VLAN via a KVM traffic
> > label to the VXLAN guest network.
> > - Si
> > ________________________________
> > From: Alexandre Bruyere <bruyere.alexandre@xxxxxxxxx>
> > Sent: Wednesday, November 14, 2018 10:32 AM
> > To: users@xxxxxxxxxxxxxxxxxxxxx
> > Subject: Information on VXLAN implementations (and other guest isolation
> > methods)
> > Hello.
> > I'm currently investigating guest isolation methods for a project. The
> > was thrown about to use VXLANs, but it's rather fuzzy on how it actually
> > implemented.
> > Does Cloudstack automatically create and maintain VXLAN connections, or
> > does it ride off an already-implemented VXLAN system configured under the
> > hood?
> > And what would be the use cases for VXLANs? Would it be appropriate to
> > in a small-scale network for hybrid clusters? If not, what would the
> > Cloudstack community recommend?
> > Thanks for your time!
> Andrija Panić
With best regards, Ivan Kudryavtsev
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>