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

[Alexandre DERUMIER]

Hi Dietmar,

some news:

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


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 ?


Here a sample config:


/etc/network/interfaces 
-----------------------

eth0
  uplink 1


eth1
  uplink 2



/etc/pve/network/router.cfg (for vxlanfrr, generate main part of frr.config, maybe can we allow user to specify custom  complex config)
----------------------------
router: router1
        bgpas 1234
        peers 192.168.0.1,192.168.0.2,192.168.0.3

-> generate frr.conf

bgp router-id 192.168.0.1
 no bgp default ipv4-unicast
 coalesce-time 1000
 neighbor 192.168.0.2 remote-as 1234
 neighbor 192.168.0.3 remote-as 1234
 !
 address-family l2vpn evpn
  neighbor 192.168.0.2 activate
  neighbor 192.168.0.3 activate
  advertise-all-vni
 exit-address-family
!


/etc/pve/network/transportzone.cfg   
-----------------
vlan transportzonecustomer1
   uplink 1
   allowedvlan 2-100


vlan transportzonecustomer2
   uplink 1
   allowedvlan 100-1000


vxlanunicast transportzonecustomer3
        uplink 2
        allowedvxlan 10000-20000
        peers 192.168.0.1;192.168.0.2;192.168.0.3


vxlanmulticast transportzonecustomer3
        uplink 2
        allowedvxlan 20000-30000
        multicastaddress 224.0.0.x 

vxlanfrr transportzonecustomer3
         uplink 2
         allowedvxlan 40000-50000
         router router1

         #enable inter-vxlan routing
         vrf vrf1 (maybe reuse transportzone name?)
         l3vni 4000
         edgenodes node1,node2   (for external routing)


(generate frr.conf router1 sub part:

vrf vrf1
 vni 4000
!
router bgp 1234 vrf vrf1
! 
 bgp router-id 192.168.0.1
 ! 
 address-family ipv4 unicast
  redistribute connected
 exit-address-family
 !
 address-family l2vpn evpn
  advertise ipv4 unicast
 exit-address-family
!
line vty
!
)






/etc/pve/network/vnets.cfg
---------------------------
vnet0 : mynetwork1 
        transportzone zone1 
        networkid: (vlan/vxlan-id) 


vnet1: mynetwork2 
       transportzone zone4 
       networkid: (vlan/vxlan-id) 
       address: cidr 
       hwaddress: 44:39:39:FF:40:10 






----- Mail original -----
De: "aderumier" <aderumier at odiso.com>
À: "dietmar" <dietmar at proxmox.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Vendredi 1 Mars 2019 10:10:01
Objet: Re: [pve-devel] rfc : /etc/pve/networks.cfg implementation

Ok, 
I'll begin to code, and we'll see what's the best way ! 


----- Mail original ----- 
De: "dietmar" <dietmar at proxmox.com> 
À: "aderumier" <aderumier at odiso.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Vendredi 1 Mars 2019 09:39:33 
Objet: Re: [pve-devel] rfc : /etc/pve/networks.cfg implementation 

> Maybe could we reuse pvestatd ? 

maybe 

> maybe we could add a version parameter in /etc/pve/networks.cfg, (user need to increment it to apply config on different nodes, like push a button "commit" in gui), 
> 
> then pvestatd simply need to compare this version with local version (should be fast and non blocking), and fork a background task to do the change ? 

You can simply compute an sha digest to detect changes. 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel