[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Information on VXLAN implementations (and other guest isolation methods)

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 vxlan.

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 <sweller@xxxxxxx.invalid> wrote:

> 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. an
> 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 idea
> was thrown about to use VXLANs, but it's rather fuzzy on how it actually is
> 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 use
> in a small-scale network for hybrid clusters? If not, what would the
> Cloudstack community recommend?
> Thanks for your time!


Andrija Panić