[pve-devel] [PATCH pve-network 0/8] generic sdn controller plugins + improvments

[Alexandre DERUMIER]

>>Sorry, I did not had time to give this a proper check and it looks to start 
>>getting serious so I did not wanted to wave this through. If then something 
>>was off it would be much more work to fix/change it later on.. 

No problem, It was just to be sure that it wasn't lost in the mailing.



>>There are now quite a few plugins, (possible) involved daemons and 
>>technologies here..
yes. I have added a demo plugin for faucet (an sdn for ovs). It's not fully
working, but it was more to see if the plugin implementation could match with
differents sdn technos.


>>Would you, Alexandre, mind writing up in short what different technologies for 
>>which purpose/reason SDN has now or will gain soon and what implementations are 
>>used or planned to? That would be great, as currently I'm missing a bit the 
>>bigger picture, and that should be quite clear to be sure we're going in the 
>>right direction.. 

yes sure.

Currently, I'm focusing on linux bridge, with vlan && vxlan.

The basic plugins are without sdn controller. (so layer2, no routing):

vlan
-----
- vlan is classic vlan, but be able to define vmbr/vnet at datacenter level.
so we'll be able to add permission on them. (That's really missing currently, if we want to give
access to customer to some speficic vlans).

vxlan
-----
vxlan:(unicast|multicast) is like vlan, but with tunneling over ip. (layer2, no routing)


vxlan(bgp-evpn) is where we have a "real" sdn, with a controller. That's mean no arp flood,
the controller (frr router here), exchange through bgp the mac/ip of the vms to differents hosts.
And it's also possible to have anycast gateway (each host, have same ip on vmbr, which is the gateway
of the vm).
For external connectivity,basic bgp routing and static routing is implemented too.

(Our usecase at work, is 3 datacenters with a shared proxmox cluster/ceph where we can move vm across dc, keeping the same gateway)

That's the basic.
(I think it's almost complete, maybe need to code cleanup, and I need to implement api permissions too)



>From this base, later, I think we could implement :

- distributed dhcp server. (for bgp-evpn easy as we have anycast ip, for vlan maybe it's possible
to have the same ip on each host too, maybe with some filtering to keep arp local and not flood the network)

Maybe a dns relay server

Maybe implement nat rules

maybe network loadbalancers.

maybe some global network stats by vnet

Maybe a cloudinit metadata server (no more disk)

A lot of thing could be implemented ;) 


I don't known if we need more sdn plugin later (maybe some users will need to connect to existing/proprietary controller).
Some sdn controllers have features like dhcp,dns relay embedded. So maybe it'll go to plugins too.(I really don't known)


I really like bgp-evpn because it's standard, supported also by almost all physical switchs vendors, and full distributed like proxmox/ceph.
It's almost the same than vmware nsx, but opensource and standard.








----- Mail original -----
De: "Thomas Lamprecht" <t.lamprecht at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>, "aderumier" <aderumier at odiso.com>
Cc: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
Envoyé: Vendredi 11 Octobre 2019 12:42:16
Objet: Re: [pve-devel] [PATCH pve-network 0/8] generic sdn controller plugins + improvments

Hi, 

On 10/11/19 9:45 AM, Alexandre DERUMIER wrote: 
> Hi, 
> 
> Is it ok for you to merge theses patches ? 
> 

Sorry, I did not had time to give this a proper check and it looks to start 
getting serious so I did not wanted to wave this through. If then something 
was off it would be much more work to fix/change it later on.. 

There are now quite a few plugins, (possible) involved daemons and 
technologies here.. 
I'd like to have someone with good networking base knowledge take a bit of a 
look over the whole concept planned here, so Wolfgang B. is CCd for now. 

Would you, Alexandre, mind writing up in short what different technologies for 
which purpose/reason SDN has now or will gain soon and what implementations are 
used or planned to? That would be great, as currently I'm missing a bit the 
bigger picture, and that should be quite clear to be sure we're going in the 
right direction.. 

cheers, 
Thomas