Vincent Bernat wrote a good article about that. Highly recommend. Would be great if CloudStack will support that: https://vincent.bernat.ch/en/blog/2017-vxlan-bgp-evpn
ср, 14 нояб. 2018 г. в 14:37, Andrija Panic <andrija.pa...@gmail.com>: > I have just single pod/subnet in a Zone so it's regular stuff, multicast... > > I'm also curious how this would span to multiple subnets in production - I > did have a chat with my networking colleague back in the days... > > Cheers > > On Wed, 14 Nov 2018 at 19:45, Ivan Kudryavtsev <kudryavtsev...@bw-sw.com> > wrote: > > > 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.pa...@gmail.com>: > > > > > Simon just explained it well - and a few additions from my side, in > case > > it > > > helps > > > > > > Read details in this page, in order to avoid some hard issues during > > later > > > production (beside MTU, check the max_igmp_membership etc...) > > > http://docs.cloudstack.apache.org/en/4.11.1.0/plugins/vxlan.html > > > > > > 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 > > > bridge. > > > > > > 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 :) > > > > > > > > > https://docs.google.com/drawings/d/1oPWU5p_wUd9UPhXGZg7j4acu5XYPbkLWzmihi6Qbwl8/edit?usp=sharing > > > > > > 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). > > > > > > > > > CHeers > > > > > > On Wed, 14 Nov 2018 at 18:29, Simon Weller <swel...@ena.com.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: > > > > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Linux+native+VXLAN+support+on+KVM+hypervisor > > > > > > > > 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.alexan...@gmail.com> > > > > Sent: Wednesday, November 14, 2018 10:32 AM > > > > To: users@cloudstack.apache.org > > > > 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ć > > > > > > > > > -- > > With best regards, Ivan Kudryavtsev > > Bitworks LLC > > Cell RU: +7-923-414-1515 > > Cell USA: +1-201-257-1512 > > WWW: http://bitworks.software/ <http://bw-sw.com/> > > > > > -- > > Andrija Panić > -- With best regards, Ivan Kudryavtsev Bitworks LLC Cell RU: +7-923-414-1515 Cell USA: +1-201-257-1512 WWW: http://bitworks.software/ <http://bw-sw.com/>
