Closed PR and reopened in https://github.com/vyos/vyos-1x/pull/72 due to creating a new branch

Change priority to high as the bug makes DHCPv6 static mappings inoperable.

https://github.com/vyos/vyos-1x/pull/71

ISC-dhcp can parse this option either as a quoted string or colon-separated hex list. common/tables.c

Please verify the fix with latest rolling release

After some more investigation, dhcpd6.leases in /config/ and /opt/vyatta/etc/config/ are the same.
In the same config folder there's also dhcpdv6.leases (with the letter "v" before 6) that's a leftover from an older image.

-rw-r--r-- 1 root root       3262 Jun 12 14:55 dhcpd6.leases
-rw-r--r-- 1 root root       2615 Jun 12 14:23 dhcpd6.leases~
-rw-r--r-- 1 root root      27726 Jun 12 14:30 dhcpd.leases
-rw-r--r-- 1 root root      28072 Jun 12 14:22 dhcpd.leases~
-rwxrwxr-x 1 root vyattacfg  8141 Oct 27  2018 dhcpdv6.leases
-rwxrwxr-x 1 root vyattacfg 17618 Oct 27  2018 dhcpdv6.leases~

If I delete these two, I get a nice traceback when running show dhcpv6 server leases:

vyos@vyos:~$ show dhcpv6 server leases 
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 81, in <module>
    leases = get_leases(lease_file, state='active')
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 44, in get_leases
    leases = IscDhcpLeases(lease_file).get()
  File "/usr/lib/python3/dist-packages/isc_dhcp_leases/iscdhcpleases.py", line 110, in get
    with open(self.filename) as lease_file:
FileNotFoundError: [Errno 2] No such file or directory: '/config/dhcpdv6.leases'

So it seems that at some point the dhcpd leases filename was changed without updating the name everywhere else (and leaving the old files dangling).

Just discovered the problem, my mistake, sorry!

Just did a fresh build w/o problems - seems you downloaded the sources instead of git clone as suggested by @runborg

When you downloaded vyos-build did you download it or used git clone? It complains about an invalid git repository so i suppose you used the download option?

Yes, this is a fresh container...

Is the vyos-builder container newly created?

This is the command used to enter docker container:

What command did you use when starting the docker container? Make iso also require sudo to run but missing sudo that not generate that error message

All items should be fixed.

IMHO this was fixed by @rherold and is merged into the latest rolling. Please verify if the issue still exists.

I can reproduce this Bug. Please priotize it's critical not to have iBGP

Adding some debug code to /opt/vyatta/share/vyatta-cfg/templates/protocols/ospf/passive-interface/node.def (set -x for delete) shows:

Not much response, but multiple users I recommend VyOS to are having this issue. So i would say it's a bug and not intended behaviour.

I commented out lines 389 and 390 in https://github.com/vyos/vyatta-cfg-system/blob/67b10e6ff5f33d73c128508f00198cc3c04c13fc/scripts/vyatta-interfaces.pl#L377.

@joshua we do not use the ssh and the ssh-import-id as the ssh keys need to be set by vyos config.

There are many complexities with our deployments that force our hand for acceptable configuration paradigms. It might make more sense to discuss this directly via email like we did for the DHCP VTI/VPN features/bug fixes that are included in 1.2.1.

Or if DNAT is a no go, use wireguard and tunnel it.

What about destination nat? (https://vyos.readthedocs.io/en/latest/nat.html#destination-nat) + binding it too loopback.

Our use case requires that the SSH listener be a public IP address (no NAT), of which we only get the one on the DHCP interface. As such, your suggestion will not work for us.

You can always let SSH listen to a loopback address

Confirmed fixed in vyos-1.2.0-rolling+201905210337

Confirmed fixed in vyos-1.2.0-rolling+201905210337

The place that limits it to only ethernet devices seems to be: https://github.com/vyos/vyatta-cfg-system/blob/crux/templates/interfaces/pseudo-ethernet/node.tag/link/node.def (the checking itself happens at https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/vyatta-interfaces.pl#L377)

I have prepared the change
https://github.com/mevertse/vyatta-cfg-quagga/commit/d3685f504e0c22a8c88899aebc1e8705637259c4

https://github.com/vyos/vyatta-openvpn/commit/cdd5d072f5a722156a06e600b5742e8bc3854b55

Thank you @wsapplegate for the contribution. Please test with the next rolling release.

Thank you @wsapplegate for the contribution. Please test with the next rolling release.

We should not emit any warning at all - this was caused by a bug in the remote-port implementation.

The above patch should fix the issue.

The above patch should fix the issue.

This patch should fix the issue.