Page MenuHomePhabricator

dhcp relay + VLAN fails
Needs testing, LowPublicBUG

Description

vyos:
eth0 172.16.0.1
eth1.40 172.16.40.1
eth1.41 172.16.41.1
eth1.42 172.16.42.1
dhcp-relay 172.16.0.10

none of the options for "set service dhcp-relay relay-options relay-agents-packets [discard]" is working. Replacing the vyos VM with opnsense VM works.

Someone else seems to have discovered this effect quite a while ago: https://www.reddit.com/r/homelab/comments/4a92nw/obscure_problem_with_dhcprelay_over_vlan_when/

Details

Difficulty level
Unknown (require assessment)
Version
1.2 rolling
Why the issue appeared?
Will be filled on close

Event Timeline

pasik added a subscriber: pasik.Mar 2 2019, 4:27 PM

I seem to run into the same issue but it also happened on 1.18 for me, reported here:

https://forum.vyos.io/t/dhcp-relay-stops-after-dhcp-offer-to-client/3434

varesa added a subscriber: varesa.Mar 4 2019, 3:27 PM

I did not manage to reproduce the issue.

I have a VyOS VM with a trunk interface. DHCP server running on VLAN 26 and client running on VLAN 27.

interfaces {
    ethernet eth2 {
        address dhcp
        description Management
        hw-id 00:50:56:bd:51:fd
    }
    ethernet eth3 {
        vif 26 {
            address 10.1.0.1/24
            description "New DHCP server subnet"
        }
        vif 27 {
            address 10.2.0.1/24
            description "New DHCP client subnet"
        }
    }
    loopback lo {
    }
}

service {
    dhcp-relay {
        interface eth3.26
        interface eth3.27
        server 10.1.0.100
    }
    ssh {
        listen-address 0.0.0.0
        port 22
    }
}

FROM DHCP-client on VLAN 26:

Mar  4 17:21:11 localhost dhclient[2085]: Internet Systems Consortium DHCP Client 4.2.5                                                                 
Mar  4 17:21:11 localhost dhclient[2085]: Copyright 2004-2013 Internet Systems Consortium.                                                              
Mar  4 17:21:11 localhost dhclient[2085]: All rights reserved.
Mar  4 17:21:11 localhost dhclient[2085]: For info, please visit https://www.isc.org/software/dhcp/                                                     
Mar  4 17:21:11 localhost dhclient[2085]:
Mar  4 17:21:11 localhost dhclient[2085]: Listening on LPF/ens192/00:50:56:bd:41:15                                                                     
Mar  4 17:21:11 localhost dhclient[2085]: Sending on   LPF/ens192/00:50:56:bd:41:15                                                                     
Mar  4 17:21:11 localhost dhclient[2085]: Sending on   Socket/fallback
Mar  4 17:21:11 localhost dhclient[2085]: DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 8 (xid=0x4c929a8)                                  
Mar  4 17:21:12 localhost dhclient[2085]: DHCPREQUEST on ens192 to 255.255.255.255 port 67 (xid=0x4c929a8)                                              
Mar  4 17:21:12 localhost dhclient[2085]: DHCPOFFER from 10.2.0.1
Mar  4 17:21:12 localhost dhclient[2085]: DHCPACK from 10.2.0.1 (xid=0x4c929a8)

From DHCP-server on 10.1.0.100 / VLAN 27:

Mar  4 17:21:11 localhost dhcpd: DHCPDISCOVER from 00:50:56:bd:41:15 via 10.2.0.1
Mar  4 17:21:12 localhost dhcpd: DHCPOFFER on 10.2.0.100 to 00:50:56:bd:41:15 via 10.2.0.1
Mar  4 17:21:12 localhost dhcpd: DHCPREQUEST for 10.2.0.100 (10.1.0.100) from 00:50:56:bd:41:15 via 10.2.0.1
Mar  4 17:21:12 localhost dhcpd: DHCPACK on 10.2.0.100 to 00:50:56:bd:41:15 via 10.2.0.1
varesa added a comment.Mar 4 2019, 3:37 PM

I was asked to test with VRRP, still works fine.

high-availability {
    vrrp {
        group dhcp-client {
            interface eth3.27
            virtual-address 10.2.0.1/24
            vrid 100
        }
        group dhcp-server {
            interface eth3.26
            virtual-address 10.1.0.1/24
            vrid 100
        }
    }
}
interfaces {
    ethernet eth2 {
        address dhcp
        description Management
        hw-id 00:50:56:bd:51:fd
    }
    ethernet eth3 {
        vif 26 {
            address 10.1.99.1/24
            description "New DHCP server subnet"
        }
        vif 27 {
            address 10.2.99.1/24
            description "New DHCP client subnet"
        }
    }
    loopback lo {
    }
}
service {
    dhcp-relay {
        interface eth3.26
        interface eth3.27
        server 10.1.0.100
    }
}
varesa added a comment.Mar 4 2019, 3:39 PM

Tested on:

vyos@vyos# run show version 
Version:          VyOS 1.2.0-rolling+201903040337
Built by:         autobuild@vyos.net
Built on:         Mon 04 Mar 2019 03:37 UTC
Build ID:         e94847d5-8722-4dc0-b56f-fb8e5aaf2b14

@varesa mention that you are running it on a ESXi VM and I do KVM (proxmox). I have seen messages that it could matter...

Thanks for the tests, let's see where this turns out.

My setup is different:

  • Fedora 29 Server as host OS
  • 1 NIC onboard (eth1)
  • 1 NIC as USB Adapter (eth2)
  • 1 "pure" virtual LAN (eth0)
  • connected to eth0: vyos VM + 3 VMs, one of then as DHCP server
  • connected to eth1: subinterfaces eth1.40 - 42, relay server is VM with DHCP server
  • connected to eth2: another dhcp server
  • all VMs are implemented as QEMU/KVM
  • all interfaces were bridged to vyos VM
varesa added a comment.EditedMar 4 2019, 6:14 PM

For those of you with issues with DHCP relay and VLANs, have you:

  • Added the interface that the DHCP server is reachable on to the service dhcp-relay interface <interface> list?
  • Added the sub-interface (e.g. eth0.20) to the interfaces instead of the parent interface (eth0)?

EDIT: s/dhcp-server/dhcp-relay

@varesa all done like that indeed.

vyos@vyos:~$ sh conf commands
set interfaces ethernet eth0 address '172.16.0.1/24'
set interfaces ethernet eth0 address 'fd00::1/64'
set interfaces ethernet eth0 duplex 'auto'
set interfaces ethernet eth0 hw-id '52:54:00:7a:87:b1'
set interfaces ethernet eth0 smp-affinity 'auto'
set interfaces ethernet eth0 speed 'auto'
set interfaces ethernet eth1 duplex 'auto'
set interfaces ethernet eth1 hw-id '52:54:00:4b:73:5f'
set interfaces ethernet eth1 smp-affinity 'auto'
set interfaces ethernet eth1 speed 'auto'
set interfaces ethernet eth1 vif 40 address '172.16.40.1/24'
set interfaces ethernet eth1 vif 41 address '172.16.41.1/24'
set interfaces ethernet eth1 vif 42 address '172.16.42.1/24'
set interfaces ethernet eth1 vif 60 address 'fd00:60::1/64'
set interfaces ethernet eth1 vif 61 address 'fd00:61::1/64'
set interfaces ethernet eth1 vif 62 address 'fd00:62::1/64'
set interfaces ethernet eth1 vif 100 address 'fd00:100::1/64'
set interfaces ethernet eth1 vif 100 address '172.16.100.1/24'
set interfaces ethernet eth1 vif 101 address 'fd00:101::1/64'
set interfaces ethernet eth1 vif 101 address '172.16.101.1/24'
set interfaces ethernet eth1 vif 102 address 'fd00:102::1/64'
set interfaces ethernet eth1 vif 102 address '172.16.102.1/24'
set interfaces ethernet eth2 address 'dhcp'
set interfaces ethernet eth2 duplex 'auto'
set interfaces ethernet eth2 hw-id '52:54:00:10:84:02'
set interfaces ethernet eth2 smp-affinity 'auto'
set interfaces ethernet eth2 speed 'auto'
set interfaces loopback lo
set nat source rule 100 outbound-interface 'eth2'
set nat source rule 100 translation address 'masquerade'
set service dhcp-relay interface 'eth1.40'
set service dhcp-relay interface 'eth1.41'
set service dhcp-relay interface 'eth1.42'
set service dhcp-relay interface 'eth1.100'
set service dhcp-relay interface 'eth1.101'
set service dhcp-relay interface 'eth1.102'
set service dhcp-relay relay-options relay-agents-packets 'discard'
set service dhcp-relay server '172.16.0.10'
set service mdns repeater interface 'eth1.40'
set service mdns repeater interface 'eth1.41'
set service ssh listen-address '172.16.0.1'
set service ssh listen-address 'fd00::1'
set service ssh port '22'
set system config-management commit-revisions '100'
set system console device ttyS0 speed '9600'
set system host-name 'vyos'
set system login user vyos authentication encrypted-password '[deleted: what else?]'
set system login user vyos authentication plaintext-password ''
set system login user vyos level 'admin'
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org
set system ntp server 2.pool.ntp.org
set system syslog global facility all level 'info'
set system syslog global facility protocols level 'debug'
set system time-zone 'Europe/Berlin'
vyos@vyos:~$

#!/bin/bash

NAME=vyos

virt-install \

--network bridge:br0 \
--name ${NAME} \
--ram 512 \
--vcpus 1 \
--disk /var/lib/libvirt/images/${NAME}.qcow2,size=2 \
--graphics none \
--os-type linux --os-variant debian9 \
--cdrom=/tmp/vyos-1.2.0-rolling+201902120337-amd64.iso \
--noreboot

------------------

#!/bin/bash

virsh attach-interface --domain vyos --type bridge --source br1 --model virtio --mac 52:54:00:4b:73:5f --config --live
virsh attach-interface --domain vyos --type bridge --source br2 --model virtio --mac 52:54:00:10:84:02 --config --live

varesa added a comment.Mar 4 2019, 8:43 PM

vyos@vyos:~$ sh conf commands
set interfaces ethernet eth0 address '172.16.0.1/24'
[...]
set service dhcp-relay interface 'eth1.40'
set service dhcp-relay interface 'eth1.41'
set service dhcp-relay interface 'eth1.42'
set service dhcp-relay interface 'eth1.100'
set service dhcp-relay interface 'eth1.101'
set service dhcp-relay interface 'eth1.102'
set service dhcp-relay relay-options relay-agents-packets 'discard'
set service dhcp-relay server '172.16.0.10'
[...]

So the DHCP server is behind eth0, right? What happens if you add set service dhcp-relay interface eth0?

@varesa as far as I can see from his start post he has already set that.

@byteshifter are you able to give is some tcpdumps on the dhcp-ports on the switch and also some tcpdumps/logging on the DHCP server ?

@varesa : DHCP server is reachable via eth0. No DHCP service for eth0. Will not add that command. vyos has to work w/o.

byteshifter added a comment.EditedMar 4 2019, 10:16 PM

@Gislaved : No, VM is down. Alpine Linux is up. Have to make progress, project is delayed.
No problems with opnsense VM or Alpine Linux VM regarding DHCPv4 relaying.

The way ISC DHCP Relay works you need to give it both the upstream and downstream interfaces (e.g. where it will listen to requests and ones where it will talk to the DHCP server). It is also shown (while not explicitly said) in the documentation: https://wiki.vyos.net/wiki/DHCP_relay

This is not specific to VyOS only and other platforms (that use ISC DHCP Relay the same way) will tell you to do the same: https://support.cumulusnetworks.com/hc/en-us/articles/201787526-Configuring-DHCP-Relays

So this is not a bug. Being able to differentiate between upstream and downstream interfaces could be a feature request though

I have tested this also with putting the DHCP subnet tagged on the interface itself within proxmox. Same problem occures... So removing the server from the vlan.interface doesn't change a thing, I could test with the clients on their own interface (ethX) and add that to the relay section instead of ethX.clientVlanId but I doubt if that works.

So I don't see where do you see that this could not be a bug.

@varesa Currently there is no way to specify upstream and downstream interfaces in vyos. If vyos was relying on isc dhcp relay from the beginning, how are upstream and downstream interfaces expected to be specified?

From https://wiki.vyos.net/wiki/User_Guide

VyOS is primarily based on Debian GNU/Linux and the Quagga routing engine. Its configuration syntax and command-line interface are loosely derived from Juniper JUNOS...

https://www.juniper.net/documentation/en_US/junos/topics/example/dhcp-subscriber-access-dhcp-relay-minimum-configuration.html

Seems you implemented it the ISC way, but provided a JUNIPER way configuration style.

Design fail -> Bug.

varesa added a comment.EditedMar 5 2019, 7:01 AM

I have tested this also with putting the DHCP subnet tagged on the interface itself within proxmox. Same problem occures... So removing the server from the vlan.interface doesn't change a thing, I could test with the clients on their own interface (ethX) and add that to the relay section instead of ethX.clientVlanId but I doubt if that works.
So I don't see where do you see that this could not be a bug.

I still doubt you issue is still relevant to this one. You tested it works with standard hosts, only PXE booting does something differently.

@varesa Currently there is no way to specify upstream and downstream interfaces in vyos. If vyos was relying on isc dhcp relay from the beginning, how are upstream and downstream interfaces expected to be specified?
From https://wiki.vyos.net/wiki/User_Guide

VyOS is primarily based on Debian GNU/Linux and the Quagga routing engine. Its configuration syntax and command-line interface are loosely derived from Juniper JUNOS...

https://www.juniper.net/documentation/en_US/junos/topics/example/dhcp-subscriber-access-dhcp-relay-minimum-configuration.html
Seems you implemented it the ISC way, but provided a JUNIPER way configuration style.
Design fail -> Bug.

That behaviour is inherited straight from Debian. VyOS just provides a config frontend to the config file /etc/default/isc-dhcp-relay.

Just try and install the package 'isc-dhcp-relay' on a debian box and you'll see that the config file has only INTERFACES=''. This is why I consider it not a VyOS bug.

EDIT: And I consider it completely feasible to add config support for upstream/downstream interfaces separately since the ISC relay seems to support that. I just think that's better classified as a FR/Improvement than a bug

NOTE: I'm not part of the official VyOS team so I'm not really one to decide what is a bug and what isn't. I just presented my opinion (and the facts it is based on). I'm not really interested in arguing about this further. If we're still in disagreement, so be it.
c-po added a subscriber: c-po.Mar 5 2019, 7:02 AM

@byteshifter VyOS provides no explicit way in configuring upstream and downstream interfaces. It supports only "interfaces".

If you have multiple paths to the DHCP server or asymmetric routing, include all the incoming ports from which the DHCP response from the server may be received. Also, include the incoming port that receives the initial DHCP request from the host. For example, the host default gateway is eth0, and eth1 and eth2 are equal cost paths to the DHCP server. Thus, a DHCP response may be received on eth1 or eth2.

I was the one who did the change from Perl to a Python based script for dhcp-relay service, maybe there is an error in the generated config? But as of now I do not see any with:

cpo@LR1# show service dhcp-relay 
 interface eth0
 interface eth1
 relay-options {
     relay-agents-packets append
 }
 server 172.16.254.30
cpo@LR1# cat /etc/default/isc-dhcp-relay 

### Autogenerated by dhcp_relay.py ###

# Defaults for isc-dhcp-relay initscript
# sourced by /etc/init.d/isc-dhcp-relay

#
# This is a POSIX shell fragment
#

# What servers should the DHCP relay forward requests to?
SERVERS="172.16.254.30"

# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="eth0 eth1"

# Additional options that are passed to the DHCP relay daemon?
OPTIONS="-4 -a -m append"
c-po claimed this task.Mar 5 2019, 7:04 AM

@c-po
Not sure what you meant by your first sentence.

The DHCP server reachable via eth2 does not manage eth1 and it's subinterfaces/vlans. So valid replies can come in via eth0 only. The role of an interface can be specified with -id or -iu. Using the script above you would leave INTERFACES empty and assign "-iu eth eth0 -id eth1.40 -id eth1.41 -id eth1.42" to OPTIONS.

c-po added a comment.Mar 5 2019, 10:31 AM

@byteshifter, I do not see the -id and -iu options in the man page of isc-dhcp-relay. Where dis you retrieve that options?

@varesa no it does not work with normal hosts, also not with PXE.

DHCP works on the same VLAN interface, that is!

c-po added a comment.Mar 5 2019, 2:54 PM

@byteshifter unfortunately you refer to the wrong version. we are using isc-dhcp-relay from Debian Jessie, as VyOS 1.2.0 is based on Debian Jessie, please see https://manpages.debian.org/jessie/isc-dhcp-relay/dhcrelay.8.en.html

@c-po What can cause my issue that my clients don't receive the PACK as shown in the topic ? I'm unable to debug it, all inferfaces are set for dhcp-relay.

@c-po :

4.3 branch is End of life (EOL) as of July 2018

https://www.isc.org/downloads/

I am refering to the correct version. Building vyos on obsolete packages is not so brilliant...

c-po added a comment.Mar 5 2019, 5:25 PM

@Gislaved I need to adjust my lab to this, first. Let me get back to you.

Gislaved added a comment.EditedMar 5 2019, 5:55 PM

@c-po ok please let me know! I'm kinda stuck here :)

@c-po how much work is it to adjust your lab for this ? most of us did this on the fly as it's not that much work and difficult. I would like to make a decission as there is too much rumour around DHCP(-RELAY) handling by VyOS and it's not going to help at the moment.

Thank for the good work tho, LTS looks promissing.

c-po added a comment.Mar 6 2019, 5:02 PM

@Gislaved I need to reconfigure my ESX environment from Portgroups with fixed VLAN configuration to a trunk and then to one of my VyOS instances as DHCP server - maybe today or tomorrow. Please apologize if you feel this takes too long but some of us do VyOS maintenance for fun besides a day job.

You can always go for Commercial Support.

Gislaved added a comment.EditedMar 6 2019, 5:13 PM

@c-po I understand partly what you say but what differs Commercial Support from community as it not work at all, I assume other Commercial Customers would have the same issue and still not fixed (for years it seems??)

At this point I cannot test further to see what it's capable off, that's why.

c-po added a comment.Mar 6 2019, 6:36 PM

Okay, here is my setup on ESXi 6.7:

BR1 <-- Native Portgroup --> [vSwitch] <-- Trunk Portgroup --> CR1 <-- Trunk Portgroup --> [vSwitch] <-- LR1 (dhcp client)

BR1 runs VyOS 1.2.0
CR1 runs VyOS 1.2.0
LR1 runs VyOS 1.2.0-rolling+201903020900

BR1 reports via monitor log

Mar  6 19:34:07 BR1 dhcpd: DHCPREQUEST for 172.18.201.10 from 00:50:56:22:12:01 via 172.18.201.254
Mar  6 19:34:07 BR1 dhcpd: DHCPACK on 172.18.201.10 to 00:50:56:22:12:01 via 172.18.201.254

Router Configuration is as follows:

CR1 (172.18.201.254 is the interface facing LR1)

cpo@CR1# show service 
 dhcp-relay {
     interface eth0.5
     interface eth0.201
     server 172.16.254.30
 }

BR1 loopback address (172.16.254.30)

cpo@BR1# show service dhcp-server shared-network-name VLAN-0201
 authoritative
 subnet 172.18.201.0/24 {
     default-router 172.18.201.254
     dns-server 172.16.254.30
     static-mapping LR1.wueIII {
         ip-address 172.18.201.10
         mac-address 00:50:56:22:12:01
     }
 }

I can confirm this running.

How to proceed?

  • Can you change the NIC type in your KVM setup?

@c-po I moved the config from a VirtIO to a vmxnet3 interface and now I get DHCP. so something is wrong with the VirtIO drivers ?

I didn't test that yet as I was testing some other provision stuff as well and like to use the VirtIO interfaces, they perform great!

syncer added a subscriber: syncer.Mar 6 2019, 6:55 PM

@Gislaved what you mean on VirtIO here?
on VMWare we only support vmxnet3, e1000 emulated driver throws to many problems

@syncer I use(d) VirtIO driver on KVM, works OK except for the DHCP part it seems which is kinda strange.

Update, VirtIO works: on the Hypervisor: ethtool -K <interfacename> tx off

syncer added a comment.Mar 6 2019, 8:34 PM

Wondering if we should disable all offload stuff in virtualized environments (which not make sense anyway)

Alpine Linux and OPNsense make it without "cheat mode" (ethtool).
I used the virt-install / bash script above for all.

@syncer you need it on Hypervisor tap level not in the VM itself.

But if it would add something, for VM's it would be good to get rid off it :)

ddiguru added a subscriber: ddiguru.Mar 8 2019, 4:25 PM

I'd like to weigh in on this, as I have seen a couple of issues. I'm running the following:

Version:          VyOS 1.2.0-rolling+201903072319
Built by:         autobuild@vyos.net
Built on:         Thu 07 Mar 2019 23:19 UTC
Build ID:         4861161f-4f33-4b22-900e-524f241625ca

Architecture:     x86_64
Boot via:         installed image
System type:      VMware guest

My relay config is:

dhcp-relay {
    interface eth4
    interface eth0
    relay-options {
        relay-agents-packets discard
    }
    server 192.168.4.40
}

my interfaces are:

Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             192.168.4.11/24                   u/u  DS0-DPG-40-LAB
...
...
eth4             10.1.1.1/24                       u/u  DS0-DPG-DHCP-TEST
...
lo               127.0.0.1/8                       u/u
                 ::1/128

My DHCP server is 192.168.4.40 in this case. I'm doing some testing with Kea DHCP 1.5.0 and I happened to see some issues.

There are two (2) issues that are somewhat frustrating and/or disturbing:

  • I'm seeing duplicated DHCPREQUEST packets by the dhcp relay - one with giaddr 10.1.1.1 and one with 192.168.4.11. The packet with giaddr 192.168.4.11 gets a DHCPNAK
  • The other issue is that i'm getting these duplicated DHCPREQUEST packets during RENEW i.e. the client is unicasting. I don't think that a DHCP relay should get involved during a unicast transaction from DHCP Client to Server. Only during REBINDING or INIT when the client broadcasts the packet.
NOTE: this link is to a post that matches my symptoms exactly! https://forum.netgate.com/topic/99064/dhcp-relay-broken-implementation

Something interesting - The above configuration launches isc-dhcp-relay as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 -i eth0 192.168.4.40

This has the bad behavior w/ the extra DHCPREQUEST that has the local giaddr.

When i launch it as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 192.168.4.40 -i eth0

I no longer get the extra DHCPREQUEST with the local giaddr (which gets DHCPNAKed)

So, it's as if the last -i <interface> is treated as the upstream interface. The man page on dhclient does not detail that!

NOTE: I have not tested adding additional interfaces i.e. /usr/sbin/dhclient -q -4 -a -m discard -i eth1 -i eth2 -i eth3 -i eth4 192.168.4.40 -i eth0 to see if that works as well.

An aside - ISC is actively developing KEA DHCP as the next generation DHCPv4 and DHCPv6 server. Currently, there is no DHCP Relay Agent in the KEA code as of version 1.5.0. The ISC has also stated that ISC dhcpd version 4.4.x is the last code train.

The isc-dhcp-relay package in VyOS 1.2.0+rolling(s) is 4.3.1 - Some of these very issues/bugs in ISC dhcrelay have been fixed in newer releases of the 4.3.x code.

As mentioned earlier isc-dhcp-relay later versions of 4.3.x and 4.4.x has support for -iu and -id upstream and downstream interfaces.

Something interesting - The above configuration launches isc-dhcp-relay as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 -i eth0 192.168.4.40

This has the bad behavior w/ the extra DHCPREQUEST that has the local giaddr.
When i launch it as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 192.168.4.40 -i eth0

I no longer get the extra DHCPREQUEST with the local giaddr (which gets DHCPNAKed)
So, it's as if the last -i <interface> is treated as the upstream interface. The man page on dhclient does not detail that!

NOTE: I have not tested adding additional interfaces i.e. /usr/sbin/dhclient -q -4 -a -m discard -i eth1 -i eth2 -i eth3 -i eth4 192.168.4.40 -i eth0 to see if that works as well.

Arrrrrr! I Retested this and it doesn't work. I'm still getting extra DHCPREQUEST and NAK

varesa added a comment.Mar 8 2019, 9:07 PM
In T1276#33655, @syncer wrote:

Wondering if we should disable all offload stuff in virtualized environments (which not make sense anyway)

I don't think *all* offload should be disabled - maybe some.

For example TSO works just fine through a hypervisor and at least some vendors recommend to enable it (and LRO) to improve performance:
https://nielshagoort.com/2017/10/19/tcp-segmentation-offload-esxi-explained/
https://docs.fortinet.com/vm/vmware-esxi/fortigate/6.0/fortigate-vm-on-vmware-esxi/6.0.0/789910/tso-and-lro

Gislaved added a comment.EditedMar 9 2019, 8:42 PM

@varesa You are mixing VirtIO which needs offloading, ESXi doesn't need that, nor it's driver. It's related to native KVM mostly.

Any news about this ?

syncer changed the task status from Open to Needs testing.Apr 17 2019, 7:54 PM
syncer triaged this task as Low priority.
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
c-po added a comment.EditedApr 21 2019, 11:23 AM

I can not test it due to lacking KVM environment. All good on ESXi.

Looks like a hypervisor issue

c-po removed c-po as the assignee of this task.Apr 21 2019, 11:33 AM