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

Alexandre DERUMIER aderumier at odiso.com
Fri Mar 22 12:42:37 CET 2019

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.


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:


  uplink 1

  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

-> generate frr.conf

bgp router-id
 no bgp default ipv4-unicast
 coalesce-time 1000
 neighbor remote-as 1234
 neighbor remote-as 1234
 address-family l2vpn evpn
  neighbor activate
  neighbor activate

vlan transportzonecustomer1
   uplink 1
   allowedvlan 2-100

vlan transportzonecustomer2
   uplink 1
   allowedvlan 100-1000

vxlanunicast transportzonecustomer3
        uplink 2
        allowedvxlan 10000-20000

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
 address-family ipv4 unicast
  redistribute connected
 address-family l2vpn evpn
  advertise ipv4 unicast
line vty

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

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

More information about the pve-devel mailing list