git.net

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

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


Im aware of his blog :) good stuff really...

On Wed, 14 Nov 2018 at 20:54, Ivan Kudryavtsev <kudryavtsev_ia@xxxxxxxxx>
wrote:

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


-- 

Andrija Panić