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/>
