Is this related to T20 ?

Hi runar,

Hi rherold!

Hello, I'm interested in that feature request as well.
And additionally, we want to monitor VRRP status via SNMP, assuming it can be done by pretty much the same way.
Thanks!

From the man page:

You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server.

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

In T1276#33655, @syncer wrote:

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

Same goes for DHCPv6 server

In T1276#33738, @ddiguru wrote:

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.

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.

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:         [email protected]
Built on:         Thu 07 Mar 2019 23:19 UTC
Build ID:         4861161f-4f33-4b22-900e-524f241625ca

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

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

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

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

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

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

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

Okay, here is my setup on ESXi 6.7:

@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??)

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

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

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

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

@c-po :

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

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

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

@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

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

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

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

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

In T1276#33579, @Gislaved wrote:

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?

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.

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

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

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

@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 as far as I can see from his start post he has already set that.

In T1276#33553, @byteshifter wrote:

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'
[...]

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

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:~$

@varesa all done like that indeed.

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

My setup is different:

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

Tested on:

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

I did not manage to reproduce the issue.

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

Thanks, sounds good.

I should note that this is not my issue/task nor am I personally affected by it. I just pointed out that part of the original issue should be solved by my PR which originated from elsewhere and left my two cents about how to handle the other case here.

Instance type is c4.xlarge running in US-Gov-West. Let me know if you need anything else.

Can you also tell region and instance type please

@syncer so far it has happened randomly. We haven't identified any correlation between systems events yet.

can you trigger such panic or it happens randomly?

Is it really required to only update the QLogic part? I ather propose that we drop all firmware-* packages and include the "real" matching firmware packages from git.kernel.org

Yes, I agree it's a good idea. In general, the openvpn package has ipv6 support already, the only missing part is rewriting the vyatta code to enable the user to actually use them.
I think we can close this task here and you may want to open a new request for rewriting the openvpn code, which will happen at one point in the future anyway. Another option would be that you rewrite the backend. I don't use openvpn, so I don't have a lot of experience with it.
Let me know what works for you best.

In T1246#33353, @hagbard wrote:

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

There is open-vpn server push-route or so available. Sooner or later that backend will be rewritten.

Gotcha. I merged your PR.
PLease test with: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-openvpn/vyatta-openvpn_0.2.60+vyos3+current2_all.deb

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

In T1246#33342, @hagbard wrote:

@varesa so 'server push-route x.x.x.0/24' does work for you?
The double quotes are an issue with the parser and I doubt that if will be allowed in the future again.

@varesa so 'server push-route x.x.x.0/24' does work for you?
The double quotes are an issue with the parser and I doubt that if will be allowed in the future again.

In T1246#33335, @gmurphy42 wrote:

I went ahead and dug out the other configuration that doesn't work in 1.2.0 either. This is pulled from the config.boot file in the vyos 1.2.0 image i have installed.

openvpn vtun1 {
      description clientvpn
      encryption aes256
      hash sha256
      local-port 1194
      mode server
      protocol tcp-passive
      server {
          name-server x.x.x.4
          name-server x.x.x.3
          push-route x.x.x.0/24
          push-route x.x.x.0/24
          subnet x.x.x.0/24
      }
      tls {
          ca-cert-file /config/auth/ca.crt
          cert-file /config/auth/server.crt
          dh-file /config/auth/dh2048.pem
          key-file /config/auth/server.key
      }
      use-lzo-compression
  }

I went ahead and dug out the other configuration that doesn't work in 1.2.0 either. This is pulled from the config.boot file in the vyos 1.2.0 image i have installed.