[pve-devel] rfc : /etc/pve/networks.cfg implementation

[Alexandre DERUMIER]

>>I think this would be great. 
ok thanks !

>>I suggest we start with simple setups, then test and extend the code and models ...
yes, I'll first works on vlan, this is the simple part

then extend it to vxlan l2

and then on vxlan l3 (with routing and vrf), where it's more complex.

and last, the vxlan l3 routing to outside




----- Mail original -----
De: "dietmar" <dietmar at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Samedi 23 Mars 2019 15:38:42
Objet: Re: [pve-devel] rfc : /etc/pve/networks.cfg implementation

> I'm still working on it, but after some discussions with my co-workers using a lot vmware and students at last training, 
> I have some changes for proposal. 
> 
> 1) 
> 
> in /etc/network/interfaces, don't use "transport-zone" as name for option, 
> but use "uplink", this is the name in vmware, so users won't be lost. 

Ok for me ... 

> The other difference, is that this "uplink" can be used in differents transport-zone. 
> 
> Transport zone are still defined at datacenter level, 
> for a simple vlan config, you can have 1transport zone allowing vlan 10-20 on uplink 1, 
> and another transport zone on same uplink allowing vlan 30-40. 
> 
> The main idea, is that a transport-zone is basically a tenant, so we you add permissions on it, 
> maybe put it in a pool, and then user can create vnet bridge himself, inside the correct vlan range. 

sounds good. 

> 2)for frr, I would like to have a router object,(where we define bgp peer,as,..),to generate main part of frr config 
> and this router can be used by differents vxlan transport zones in differents vrf. (they a subojects of the main router in frr.config too) 
> Like this, each vxlan transport zone is in a different vrf, so no routing between them. (each customer have a transport zone, and can't access 
> to other customer transport zone) 
> 
> 
> What do you think about it ? 

I think this would be great. I suggest we start with simple setups, then test and extend the code and models ... 

- Dietmar