proxmox 7.0 sdn beta test

MrPowerGamerBR said:
Hey @spirit, first off: Thanks for creating this plugin, I'm using it since November in production without any issues and this plugin made me learn so much about how SDN works (way more than my internship, which is also related to sdn, heh) and it works so well!

And now here's a question: Is it possible to use a specific failover IP for VXLAN?

Example: I have two interfaces: vmbr0 and vmbr0:1, my IP bound to vmbr0 which is sadly getting DDoS'd which can cause issues due to host providers (example: OVH, ReliableSite, etc) mitigating DDoS traffic and thinking that the VXLAN traffic is a DDoS attack.

So I wanted to route VXLAN traffic with my failover IP bound to "vmbr0:1", and because it is on a different IP, it won't be attacked by pesky DDoS attacks... but how can I do that?
Click to expand...
mmmm, I'm not sure.

can you try to edit /etc/network/interfaces.d/sdn

Code: 
auto vxlan_yourvnet
iface vxlan_yournvnet
        vxlan-id 10000
        vxlan_remoteip x.x.x.x
        vxlan_remoteip x.x.x.x
        mtu 1450
and add at the end
Code: 
       vxlan-local-tunnelip  x.x.x.x -->your failoverip of vmbr0:1

then: ifreload -a (not sure if it can be change online, so maybe ifdown vxlan_yourvnet && ifup vxlan_yourvnet)

do it on each node.

if it's working, it could add an option to specify the interface.
(a new release should be available soon, but I could have time to implement it)
 
spirit said:
mmmm, I'm not sure.

can you try to edit /etc/network/interfaces.d/sdn

Code: 
auto vxlan_yourvnet
iface vxlan_yournvnet
        vxlan-id 10000
        vxlan_remoteip x.x.x.x
        vxlan_remoteip x.x.x.x
        mtu 1450
and add at the end
Code: 
       vxlan-local-tunnelip  x.x.x.x -->your failoverip of vmbr0:1

then: ifreload -a (not sure if it can be change online, so maybe ifdown vxlan_yourvnet && ifup vxlan_yourvnet)

do it on each node.

if it's working, it could add an option to specify the interface.
(a new release should be available soon, but I could have time to implement it)
Click to expand...
I will try that later, thanks! :)

I'm not sure how it could be implemented on the GUI tho, because you would need to do a way of "okay, this node will use this IP for VXLAN connections but everyone else will use the default vmbr0 IP"

Also a small issue that I've noticed (which isn't a huge issue, but it is kinda annoying) is that sometimes when I restart a container that uses VXLAN, other containers (also connected via VXLAN) are not "available"... until they magically are? This only seems to happen after a restart and then it never happens again.

I don't think that this could be a external firewall causing issues because even containers hosted in the same machine have the same weird behavior.

Code: 
root@nginx:~# ping 172.16.11.101
PING 172.16.11.101 (172.16.11.101) 56(84) bytes of data.
From 172.16.0.2 icmp_seq=1 Destination Host Unreachable
From 172.16.0.2 icmp_seq=2 Destination Host Unreachable
From 172.16.0.2 icmp_seq=4 Destination Host Unreachable
From 172.16.0.2 icmp_seq=7 Destination Host Unreachable
From 172.16.0.2 icmp_seq=8 Destination Host Unreachable
From 172.16.0.2 icmp_seq=10 Destination Host Unreachable
From 172.16.0.2 icmp_seq=13 Destination Host Unreachable
From 172.16.0.2 icmp_seq=16 Destination Host Unreachable
From 172.16.0.2 icmp_seq=19 Destination Host Unreachable
From 172.16.0.2 icmp_seq=22 Destination Host Unreachable
From 172.16.0.2 icmp_seq=23 Destination Host Unreachable
From 172.16.0.2 icmp_seq=25 Destination Host Unreachable
From 172.16.0.2 icmp_seq=26 Destination Host Unreachable
From 172.16.0.2 icmp_seq=28 Destination Host Unreachable
From 172.16.0.2 icmp_seq=31 Destination Host Unreachable
From 172.16.0.2 icmp_seq=34 Destination Host Unreachable
From 172.16.0.2 icmp_seq=37 Destination Host Unreachable
From 172.16.0.2 icmp_seq=40 Destination Host Unreachable
From 172.16.0.2 icmp_seq=41 Destination Host Unreachable
From 172.16.0.2 icmp_seq=43 Destination Host Unreachable
From 172.16.0.2 icmp_seq=46 Destination Host Unreachable
From 172.16.0.2 icmp_seq=49 Destination Host Unreachable
From 172.16.0.2 icmp_seq=52 Destination Host Unreachable
From 172.16.0.2 icmp_seq=53 Destination Host Unreachable
From 172.16.0.2 icmp_seq=55 Destination Host Unreachable
From 172.16.0.2 icmp_seq=58 Destination Host Unreachable
From 172.16.0.2 icmp_seq=61 Destination Host Unreachable
From 172.16.0.2 icmp_seq=62 Destination Host Unreachable
From 172.16.0.2 icmp_seq=68 Destination Host Unreachable
From 172.16.0.2 icmp_seq=69 Destination Host Unreachable
64 bytes from 172.16.11.101: icmp_seq=74 ttl=64 time=1341 ms
64 bytes from 172.16.11.101: icmp_seq=75 ttl=64 time=318 ms
64 bytes from 172.16.11.101: icmp_seq=76 ttl=64 time=0.265 ms
64 bytes from 172.16.11.101: icmp_seq=77 ttl=64 time=0.265 ms
64 bytes from 172.16.11.101: icmp_seq=78 ttl=64 time=0.240 ms
64 bytes from 172.16.11.101: icmp_seq=79 ttl=64 time=0.221 ms

Again it is not a huuuge issue because this only seems to happen once after a restart and then it never happens again, but still, very weird.

UPDATE: I think that the issue was that I had a "invalid IP" (online, but didn't use VXLAN) in my peering IPs, I don't know why that would cause a issue and why it would only affect one of my machines, but hey, it is fixed!
 
Last edited:
Hi Spirit,

Im trying to move away from using OVS due to performance issues I have picked up when using OVS with Intel X710 network cards, I could not get full 10G throughput using OVS with a simple bond interface a 1 OVS bridge, by just changing to a linux bridge and linux bond I get almost full 10G with the VM.

I have noticed when using the SDN plugin with no Openvswitch used on the Host , that some features are missing and have not found a way to make it working using only linux bridges, below is the example that works using openvswitch.

I have a customer with a vlan 4057 assigned , the customer have several VM's and some are servers mixed OS's some linux and some windows and some VM's are Firewalls and some are routers, the vlan 4057 is the STAG for the client and any QinQ vlan's should be allowed.

There is 4 vnets linked to 2 zones, 1x QINQ and 1 x vlan,

The QinQ/vnets is assigned to Servers and the VLAN/vnets is assigned to the Routers and Firewalls,

The normal VLAN/vnet zones assigned to the Firewalls and Routers should be allowed to trunk and vlan which is working on the OVS setup but does not work on the linux bridge setup, see below config

/etc/network/interfaces.d/sdn for working OVS

Code: 
#version:50


auto brol1302
iface brol1302
        bridge_ports z_brol4057.1302
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto brol2071
iface brol2071
        bridge_ports z_brol4057.2071
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto brol4057
iface brol4057
        bridge_ports ln_brol4057
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto broll13
iface broll13
        bridge_ports z_brol4057.13
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto ln_brol4057
iface ln_brol4057
        ovs_type OVSIntPort
        ovs_bridge vmbr0
        ovs_mtu 9000
        ovs_options vlan_mode=dot1q-tunnel other_config:qinq-ethtype=802.1q tag=4057

auto sv_brol4057
iface sv_brol4057
        ovs_type OVSIntPort
        ovs_bridge vmbr0
        ovs_mtu 9000
        ovs_options vlan_mode=dot1q-tunnel tag=4057 other_config:qinq-ethtype=802.1q

auto vmbr0
iface vmbr0
        ovs_ports sv_brol4057
        ovs_ports sv_brol4057
        ovs_ports ln_brol4057
        ovs_ports sv_brol4057

auto z_brol4057
iface z_brol4057
        mtu 9000
        bridge-stp off
        bridge-ports sv_brol4057
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

/etc/pve/sdn/zones.cfg for OVS

Code: 
qinq: brol4057
        bridge vmbr0
        tag 4057
        mtu 9000
        vlan-protocol 802.1q

vlan: vbro4057
        bridge vmbr0
        mtu 9000

vnets.cfg for OVS

Code: 
vnet: broll13
        tag 13
        zone brol4057
        vlanaware 1

vnet: brol1302
        tag 1302
        zone brol4057
        vlanaware 1

vnet: brol2071
        tag 2071
        zone brol4057
        vlanaware 1

vnet: brol4057
        tag 4057
        zone vbro4057
        vlanaware 1
 
im getting below error when creating above config on a linux bridge system


netlink : error: netlink: z_brol4057: cannot add bridge vlan 13: operation failed with 'Invalid argument' (22)
netlink : error: netlink: z_brol4057.13: cannot enslave link z_brol4057.13 to broll13: operation failed with 'Invalid argument' (22)
broll13 : warning: broll13: skipping port z_brol4057.13, invalid ether addr 00:00:00:00:00:00

TASK ERROR: command 'ifreload -a' failed: exit code 1

When creating the Zones and vnets i n the GUI the below config files are created.

/etc/pve/sdn/zones.cfg

Code: 
qinq: brol4057
        bridge vmbr0
        tag 4057
        mtu 9000
        vlan-protocol 802.1q

vlan: vbro4057
        bridge vmbr0
        mtu 9000

/etc/pve/sdn/vnets.cfg


Code: 
vnet: brol1302
        tag 1302
        zone brol4057
        vlanaware 1

vnet: brol2071
        tag 2071
        zone brol4057
        vlanaware 1

vnet: broll13
        tag 13
        zone brol4057
        vlanaware 1

vnet: brol4057
        tag 4057
        zone vbro4057
        vlanaware 1

/etc/network/interfaces.d/sdn


Code: 
auto brol1302
iface brol1302
        bridge_ports z_brol4057.1302
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto brol2071
iface brol2071
        bridge_ports z_brol4057.2071
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto brol4057
iface brol4057
        bridge_ports vmbr0.4057
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto broll13
iface broll13
        bridge_ports z_brol4057.13
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto vmbr0
iface vmbr0
        bridge-vlan-protocol 802.1q

auto z_brol4057
iface z_brol4057
        mtu 9000
        bridge-stp off
        bridge-ports vmbr0.4057
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

for some reason not all Bridges / interfaces are coming up see below the zone for some reason have NO-CARRIER


Code: 
ip link show  | grep mtu | column -t
1:   lo:                          <LOOPBACK,UP,LOWER_UP>                    mtu  65536  qdisc  noqueue  state   UNKNOWN   mode   DEFAULT         group  default  qlen   1000
2:   eth0:                        <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>   mtu  9000   qdisc  mq       master  bond0     state  UP              mode   DEFAULT  group  default  qlen  1000
3:   eth1:                        <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>   mtu  9000   qdisc  mq       master  bond0     state  UP              mode   DEFAULT  group  default  qlen  1000
4:   bond0:                       <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>  mtu  9000   qdisc  noqueue  master  vmbr0     state  UP              mode   DEFAULT  group  default  qlen  1000
5:   vlan16@bond0:                <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
6:   vlan17@bond0:                <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
7:   vlan20@bond0:                <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
8:   vmbr0:                       <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
17:  vmbr0.4057@vmbr0:            <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  master  brol4057  state  UP              mode   DEFAULT  group  default  qlen  1000
18:  z_brol4057:                  <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  state   DOWN      mode   DEFAULT         group  default  qlen   1000
19:  z_brol4057.1302@z_brol4057:  <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  master  brol1302  state  LOWERLAYERDOWN  mode   DEFAULT  group  default  qlen  1000
20:  brol1302:                    <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  state   DOWN      mode   DEFAULT         group  default  qlen   1000
21:  z_brol4057.2071@z_brol4057:  <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  master  brol2071  state  LOWERLAYERDOWN  mode   DEFAULT  group  default  qlen  1000
22:  brol2071:                    <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  state   DOWN      mode   DEFAULT         group  default  qlen   1000
23:  brol4057:                    <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
24:  z_brol4057.13@z_brol4057:    <BROADCAST,MULTICAST>                     mtu  9000   qdisc  noop     state   DOWN      mode   DEFAULT         group  default  qlen   1000
25:  broll13:                     <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UNKNOWN   mode   DEFAULT         group  default  qlen   1000

Trying to bring up the bridge manually gives below error.

ifup z_brol4057
error: misconfig..? vmbr0.4057 bridge port is enslaved to multiple interfaces ['brol4057', 'z_brol4057']
 
Last edited:
pieteras.meyer said:
Hi Spirit,

I have noticed the Zone simple is not working and below error is shown when trying to create a simle zone

Parameter verification failed. (400)

type: value 'simple' does not have a value in the enumeration 'evpn, faucet, qinq, vlan, vxlan
Click to expand...
I think that the pve-network code is not yet updated. A good news, the new version is coming really soon (proxmox 6.4), code has been merged !
 
pieteras.meyer said:
im getting below error when creating above config on a linux bridge system


netlink : error: netlink: z_brol4057: cannot add bridge vlan 13: operation failed with 'Invalid argument' (22)
netlink : error: netlink: z_brol4057.13: cannot enslave link z_brol4057.13 to broll13: operation failed with 'Invalid argument' (22)
broll13 : warning: broll13: skipping port z_brol4057.13, invalid ether addr 00:00:00:00:00:00

TASK ERROR: command 'ifreload -a' failed: exit code 1

When creating the Zones and vnets i n the GUI the below config files are created.

/etc/pve/sdn/zones.cfg

Code: 
qinq: brol4057
        bridge vmbr0
        tag 4057
        mtu 9000
        vlan-protocol 802.1q

vlan: vbro4057
        bridge vmbr0
        mtu 9000

/etc/pve/sdn/vnets.cfg


Code: 
vnet: brol1302
        tag 1302
        zone brol4057
        vlanaware 1

vnet: brol2071
        tag 2071
        zone brol4057
        vlanaware 1

vnet: broll13
        tag 13
        zone brol4057
        vlanaware 1

vnet: brol4057
        tag 4057
        zone vbro4057
        vlanaware 1

/etc/network/interfaces.d/sdn


Code: 
auto brol1302
iface brol1302
        bridge_ports z_brol4057.1302
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto brol2071
iface brol2071
        bridge_ports z_brol4057.2071
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto brol4057
iface brol4057
        bridge_ports vmbr0.4057
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto broll13
iface broll13
        bridge_ports z_brol4057.13
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000

auto vmbr0
iface vmbr0
        bridge-vlan-protocol 802.1q

auto z_brol4057
iface z_brol4057
        mtu 9000
        bridge-stp off
        bridge-ports vmbr0.4057
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

for some reason not all Bridges / interfaces are coming up see below the zone for some reason have NO-CARRIER


Code: 
ip link show  | grep mtu | column -t
1:   lo:                          <LOOPBACK,UP,LOWER_UP>                    mtu  65536  qdisc  noqueue  state   UNKNOWN   mode   DEFAULT         group  default  qlen   1000
2:   eth0:                        <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>   mtu  9000   qdisc  mq       master  bond0     state  UP              mode   DEFAULT  group  default  qlen  1000
3:   eth1:                        <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>   mtu  9000   qdisc  mq       master  bond0     state  UP              mode   DEFAULT  group  default  qlen  1000
4:   bond0:                       <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>  mtu  9000   qdisc  noqueue  master  vmbr0     state  UP              mode   DEFAULT  group  default  qlen  1000
5:   vlan16@bond0:                <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
6:   vlan17@bond0:                <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
7:   vlan20@bond0:                <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
8:   vmbr0:                       <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
17:  vmbr0.4057@vmbr0:            <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  master  brol4057  state  UP              mode   DEFAULT  group  default  qlen  1000
18:  z_brol4057:                  <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  state   DOWN      mode   DEFAULT         group  default  qlen   1000
19:  z_brol4057.1302@z_brol4057:  <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  master  brol1302  state  LOWERLAYERDOWN  mode   DEFAULT  group  default  qlen  1000
20:  brol1302:                    <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  state   DOWN      mode   DEFAULT         group  default  qlen   1000
21:  z_brol4057.2071@z_brol4057:  <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  master  brol2071  state  LOWERLAYERDOWN  mode   DEFAULT  group  default  qlen  1000
22:  brol2071:                    <NO-CARRIER,BROADCAST,MULTICAST,UP>       mtu  9000   qdisc  noqueue  state   DOWN      mode   DEFAULT         group  default  qlen   1000
23:  brol4057:                    <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UP        mode   DEFAULT         group  default  qlen   1000
24:  z_brol4057.13@z_brol4057:    <BROADCAST,MULTICAST>                     mtu  9000   qdisc  noop     state   DOWN      mode   DEFAULT         group  default  qlen   1000
25:  broll13:                     <BROADCAST,MULTICAST,UP,LOWER_UP>         mtu  9000   qdisc  noqueue  state   UNKNOWN   mode   DEFAULT         group  default  qlen   1000

Trying to bring up the bridge manually gives below error.

ifup z_brol4057
error: misconfig..? vmbr0.4057 bridge port is enslaved to multiple interfaces ['brol4057', 'z_brol4057']
Click to expand...
mmm, this is because you have a vnet in vlan 4057 on vmbr0 for the vlan zone and qinq also using vlan4057. I don't think I could handle this easily.
any reason to use the same vlan4057 in the vlan zone ?

one possible way, could be to define this brol4057 vnet in the qinq zone but without tag. (It's currently not possible, but I could add support for this).

does it work if you manually edit sdn network config with:

Code: 
auto brol4057
iface brol4057
        bridge_ports z_brol4057
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000
?
 
Last edited:
spirit said:
mmm, this is because you have a vnet in vlan 4057 on vmbr0 for the vlan zone and qinq also using vlan4057. I don't think I could handle this easily.
any reason to use the same vlan4057 in the vlan zone ?
Click to expand...
Hi Spirit,

I have a customer with a vlan 4057 assigned , the customer have several VM's and some are servers mixed OS's some linux and some windows and some VM's are Firewalls and some are routers, the vlan 4057 is the STAG for the client and any QinQ vlan's should be allowed.

There is 4 vnets linked to 2 zones, 1x QINQ and 1 x vlan,

The QinQ/vnets is assigned to Servers and the VLAN/vnets is assigned to the Routers and Firewalls so they can add any vlan they wish to use
spirit said:
one possible way, could be to define this brol4057 vnet in the qinq zone but without tag. (It's currently not possible, but I could add support for this).
Click to expand...
This should work and take away the need to have a QINQ zone and Vlan zone for vlan 4057 and the create the VNET for the firewalls and routers without a tag and then the VNET for the Servers as before with a tag.


spirit said:
I think that the pve-network code is not yet updated. A good news, the new version is coming really soon (proxmox 6.4), code has been merged !
Click to expand...
This is good news.
 
The new version is effectively out now, in libpve-network-perl >= 0.5 for backend and pve-manager >= 6.4-4 for GUI.

There were quite some changes, for example, the way how the currently applied state was saved and pending changes were detected (it's more flexible and fine-grained now), so there may some hiccups regarding that.

If you run this on something somewhat production like I'd suggest test the update first in a small (e.g., virtual) test environment to avoid surprises. Due to the experimental preview status we cannot yet guarantee full backwards compatibility.

Thanks to all with feedback here and especially Alexandre for his work here!
 
pieteras.meyer said:
This should work and take away the need to have a QINQ zone and Vlan zone for vlan 4057 and the create the VNET for the firewalls and routers without a tag and then the VNET for the Servers as before with a tag.



This is good news.
Click to expand...
can you test the code that I have send in my previous message, and do an ifreload -a to see if it's working ? I have looked at the code, I can implement vnet without tag easily for qinq.
 
spirit said:
can you test the code that I have send in my previous message, and do an ifreload -a to see if it's working ? I have looked at the code, I can implement vnet without tag easily for qinq.
Click to expand...
Hi Spirit,

Yes I have a LAB server which I can apply the patch to and see if this will work.

PS
What is you personal thoughts on the performance issue I'm seeing with OVS vs LINUX Bridge? I was under the impression that the OVS stack had better In kernel forwarding and hardware offloading capabilities which in return should have less CPU overhead
 
t.lamprecht said:
The new version is effectively out now, in libpve-network-perl >= 0.5 for backend and pve-manager >= 6.4-4 for GUI.

There were quite some changes, for example, the way how the currently applied state was saved and pending changes were detected (it's more flexible and fine-grained now), so there may some hiccups regarding that.

If you run this on something somewhat production like I'd suggest test the update first in a small (e.g., virtual) test environment to avoid surprises. Due to the experimental preview status we cannot yet guarantee full backwards compatibility.

Thanks to all with feedback here and especially Alexandre for his work here!
Click to expand...
I have upgraded my LAB server to 6.4-4,

After upgrade all my zones were gone but the VNETS were still there,

zone.JPG

vnet.JPG

Trying to add a zone gives below error
Code: 
Parameter verification failed. (400)

ipam: property is missing and it is not optional
 
t.lamprecht said:
Yeah, that's a bug, I had a PVE IPAM configured which got auto-selected, so I did not notice that. Will look into it.
Click to expand...
Also seeing below error in syslog
Code: 
Apr 28 13:45:10 pve00 pvestatd[1376]: sdn status update error: cannot lookup undefined type! at /usr/share/perl5/PVE/Network/SDN/Zones.pm line 260.
Apr 28 13:45:20 pve00 pvestatd[1376]: sdn status update error: cannot lookup undefined type! at /usr/share/perl5/PVE/Network/SDN/Zones.pm line 260.
Apr 28 13:45:31 pve00 pvestatd[1376]: sdn status update error: cannot lookup undefined type! at /usr/share/perl5/PVE/Network/SDN/Zones.pm line 260.
Apr 28 13:45:40 pve00 pvestatd[1376]: sdn status update error: cannot lookup undefined type! at /usr/share/perl5/PVE/Network/SDN/Zones.pm line 260.
Apr 28 13:45:50 pve00 pvestatd[1376]: sdn status update error: cannot lookup undefined type! at /usr/share/perl5/PVE/Network/SDN/Zones.pm line 260.
 
Normally means that there's a vnet in the running-config referencing a unkown or not-yet known zone.
Triggering a config apply in SDN panel could help.

But I tried to improve the behaviour here a bit:
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=153cb80d4ce96798f4157378246df4369d094167

And made IPAM for now optional for the zone (gui patch is still missing):
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=57a335c4c013fda3216185d463c1fe4d62d8a2e5

Available on pvetest as libpve-network-perl version 0.5-2
 
t.lamprecht said:
Normally means that there's a vnet in the running-config referencing a unkown or not-yet known zone.
Triggering a config apply in SDN panel could help.

But I tried to improve the behaviour here a bit:
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=153cb80d4ce96798f4157378246df4369d094167

And made IPAM for now optional for the zone (gui patch is still missing):
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=57a335c4c013fda3216185d463c1fe4d62d8a2e5

Available on pvetest as libpve-network-perl version 0.5-2
Click to expand...
I have applied this and seems to be working,

could you also look to apply the below that Spirit mentioned to allow a QinQ vnet without a tag?
spirit said:
one possible way, could be to define this brol4057 vnet in the qinq zone but without tag. (It's currently not possible, but I could add support for this).
Click to expand...
 
t.lamprecht said:
Normally means that there's a vnet in the running-config referencing a unkown or not-yet known zone.
Triggering a config apply in SDN panel could help.

But I tried to improve the behaviour here a bit:
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=153cb80d4ce96798f4157378246df4369d094167

And made IPAM for now optional for the zone (gui patch is still missing):
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=57a335c4c013fda3216185d463c1fe4d62d8a2e5

Available on pvetest as libpve-network-perl version 0.5-2
Click to expand...
some zones/vnets options have change anyway, so I think the best way is to recreate zones/vnets with same name,
it shouldn't break current running network on reload.
 
t.lamprecht said:
And made IPAM for now optional for the zone (gui patch is still missing):
https://git.proxmox.com/?p=pve-network.git;a=commitdiff;h=57a335c4c013fda3216185d463c1fe4d62d8a2e5

Available on pvetest as libpve-network-perl version 0.5-2
Click to expand...
I need to check on routed vnets (simple/evpn), where you defined a gateway, it's already registered in ipam db.
I don't remember if I'm checking everywhere in the code than ipam is enabled or not. I think it's ok currently,
but I think I had forced it, because if you enable ipam after vnet creation with gateway defined, they are not registered to ipam.
(I'm already forbid ipam change between 2 ipams, but I'm not sure it's implemented from no ipam to ipam)
 
pieteras.meyer said:
Hi Spirit,

Yes I have a LAB server which I can apply the patch to and see if this will work.
Click to expand...
I mean , before I'm doing a patch, can you try to change directly in /etc/network/interfaces.d/sdn

Code: 
auto brol4057
iface brol4057
        bridge_ports z_brol4057
        bridge_stp off
        bridge_fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 9000
(changing bridge_ports)

and do a ifreload -a, and check that it's ok.



pieteras.meyer said:
PS
What is you personal thoughts on the performance issue I'm seeing with OVS vs LINUX Bridge? I was under the impression that the OVS stack had better In kernel forwarding and hardware offloading capabilities which in return should have less CPU overhead
Click to expand...
My personal opinion: I really don't like ovs, I have seen too much strange bugs report since years., and if ovs service is crashing, no more network... So I'm trusting the kernel, keep it simple stupid.

Until proxmox have implemented dpdk/xdp for ovs (and it's really a pain to implement), forwarding performance should be equal.
 
  • Like
Reactions: linkstat and t.lamprecht
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom