git.net

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

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


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_ia@xxxxxxxxx>
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.panic@xxxxxxxxx>:
>
> > 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 <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:
> > >
> >
> 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.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ć
> >
>
>
> --
> 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ć