git.net

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

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


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

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


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