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

I have included the requested configs (some portions of configs have been censored for security purposes). I have since rolled back to 1.1.8 for this and other reasons but I can confirm that this configuration works on 1.1.8 but not on 1.2.0.

Can you share your config please, with the statement that breaks your config. thx.

Well that is interesting, the package versions are still the same but now it works.

Unfortunately, this works only for default route, but not for any other.

e.g. could indeed be tested to make sure that it works

I think the issue you found might still be a valid one, even though it was not the same one that was originally talked about on IRC.

Needs more testing. I might have been testing the wrong thing. :(

The only packages i manually build are vyatta-cfg-firewall and vyatta-nat, the rest of the packages directories are empty so the packages get downloaded.

Why not use a combination of two?

Root cause is the inability of tftpd to listen on multiple addresses.

Will test with the next rolling before I close off the task.

Yeah, I agree.

As there is no recorded bug in this behavior on 1.2 we only would increase the risk on the LTS versions without legitimate benefit.

We should NOT backport this to VyOS 1.2 crux

We should NOT backport this to VyOS 1.2 crux

Yes, please migrate that function, too. One more migrated command.

/opt/vyatta/share/vyatta-cfg/templates/system/static-host-mapping/host-name/node.def writes the entry, I think the functionality should be integrated into host_name.py. I contacted @c-po to hear his opinion.