So I'd love to have this feature back in, but I still don't understand why it was removed. It's ok if it needs to be implemented in some other ways, but for some reason there hasn't been any communication/replies to this issue.

In T915#73396, @craterman wrote:

@Viacheslav what about abnormal label allocation behavior which I wrote earlier? Was it fixed?

In this lab I used VyOS 1.3-rolling-202008170118. The connected routes redistributed in OSPF at HUB are being properly exchanged to WAN router, including the route to the virtual tunnel interface vti50.

Thanks

Yes, nft_chain_nat_ipv6 is also affected by this, and needs the same adjustments as the nat module

Although nat66 (NPT) is not currently incorporated into the mainline, I may need to modify my implementation if it is also modified

Hello, here is a request beyond the outline. Please help me check whether the NAT kernel module of IPv6 has also changed? It turned out to be nft_chain_nat_ipv6？

Would it be reasonable to use BFD for this? Since BFD is already implemented we might be able to use that as well?

In T915#73449, @Viacheslav wrote:

PR https://github.com/vyos/vyos-1x/pull/531
Add discovery hello timers

PR https://github.com/vyos/vyos-1x/pull/531
Add discovery hello timers

In T915#73395, @Viacheslav wrote:

@Cheeze_It Thank's. Can you describe what features you are missing?
And if possible, an example configuration.

It's doesn't work only for GRE encapsulation.
All other interfaces work as expected.

In VyOS 1.3-rolling-202008170118 the interfaces do not generate/get the configured IPv6-EUI Address, as in the image:

In version VyOS 1.3-rolling-202008170118 physical interfaces have an automatic generated IPv6 Link-Local Address set, though Tunnel interfaces does not have it and it is necessary to set manually an IPv6 Link-Local Address ramdomly created. Tunnel interfaces also do not present a Layer-2 address from which a Link-Local IPv6 could be derived.

https://forum.vyos.io/t/ospfv3-not-working-over-gre-tunnel/5805/8

"monitor dhcp" parse /var/log/messages and not use tcpdump

Fixed, VyOS 1.3-rolling-202008190118

dhclient script up this interface after hooks

@Viacheslav what about abnormal label allocation behavior which I wrote earlier? Was it fixed?

@Cheeze_It Thank's. Can you describe what features you are missing?
And if possible, an example configuration.

Works as expected on VyOS 1.3-rolling-202008190118

I also want to add more verification. I was able to bring up LDP *properly* to a Juniper as well. The one thing I was not able to 100% verify was that the labels themselves were proper from end to end *BUT* the Junipers did properly see the labels and did allocate from Vyos. Vyos itself also did the same. Due to a lack of ability to specify an explicit null I cannot absolutely verify yet, but I hope to be able to in the future. SO far though it seems that you guys have done a good job making sure that the P functionality works, and label allocation works. Well done. I was *ALSO* able to make the MPLS label pop up properly. Please check the very bottom for the verification of it working :)

As it turned out, the problem was on the client-side dhcpv6c and was fixed in T2510
Next Rolling release will be without this bug.

vyos@r2-roll:~$ sudo tcpdump -ntvi eth1 port 546
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
IP6 (flowlabel 0x630bb, hlim 1, next-header UDP (17) payload length: 60) fe80::5054:ff:fe78:6e81.546 > ff02::1:2.547: [bad udp cksum 0xbc21 -> 0x1ea8!] dhcp6 solicit (xid=f47a17 (client-ID hwaddr/time type 1 time 651069356 5254004ba2c4) (IA_NA IAID:1 T1:0 T2:0) (elapsed-time 103) (option-request DNS-server DNS-search-list))
IP6 (flowlabel 0x0d161, hlim 64, next-header UDP (17) payload length: 128) fe80::5054:ff:fe3c:7c1f.547 > fe80::5054:ff:fe78:6e81.546: [bad udp cksum 0x8790 -> 0xfa6f!] dhcp6 advertise (xid=f47a17 (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2001:db8::199 pltime:27000 vltime:43200)) (client-ID hwaddr/time type 1 time 651069356 5254004ba2c4) (server-ID hwaddr/time type 1 time 651085104 5254003c7c1f) (DNS-server 2001:db8::ffff 2001:db8::1))
IP6 (flowlabel 0x630bb, hlim 1, next-header UDP (17) payload length: 106) fe80::5054:ff:fe78:6e81.546 > ff02::1:2.547: [bad udp cksum 0xbc4f -> 0x44a5!] dhcp6 request (xid=a568a (client-ID hwaddr/time type 1 time 651069356 5254004ba2c4) (server-ID hwaddr/time type 1 time 651085104 5254003c7c1f) (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2001:db8::199 pltime:27000 vltime:43200)) (elapsed-time 0) (option-request DNS-server DNS-search-list))
IP6 (flowlabel 0x0d161, hlim 64, next-header UDP (17) payload length: 128) fe80::5054:ff:fe3c:7c1f.547 > fe80::5054:ff:fe78:6e81.546: [bad udp cksum 0x8790 -> 0x19e7!] dhcp6 reply (xid=a568a (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2001:db8::199 pltime:27000 vltime:43200)) (client-ID hwaddr/time type 1 time 651069356 5254004ba2c4) (server-ID hwaddr/time type 1 time 651085104 5254003c7c1f) (DNS-server 2001:db8::ffff 2001:db8::1))

Enabling sticky connections had no effect in my testing. The only temporary solution was T2747. Unfortunately, this solution no longer works once the IP address changes on a DHCP-assigned interface.

PR https://github.com/vyos/vyos-1x/pull/528

32-bit Xen PV support was dropped recently from upstream Linux kernel 5.9.
64-bit Xen PV is still supported in upstream Linux kernel.

I believe we should stick to the same format as ntp.conf.

Another idea would be to introduce a new option „pool“ for any specified server to use the pool keyword over server. But I see no downside of always using pool, do you?

That would do a 2 for 1 solution.

In addition to the workaround provided in the task T2747, the following configuration could also be added to the existing configuration:

Tunnel Interfaces also do not generate/configure a Link-Local IPv6. It looks like Tunnel interfaces do not have any MAC Address associated to it.

@ronie can you build an example with frr?

It seems that making the tunnel connection a Stub Area would reach the same design goal without relying on a recursive static route, but it also seems that this feature is not supported in OSPFv3 by now. I´ve opened the following feature requests: https://phabricator.vyos.net/T2804 & https://phabricator.vyos.net/T2803 .

@thomas-mangin in further tests, I've seen wide variability in timing tests, independent of caching, with the original quote being the high-end. That will need to be investigated, but I think performance should not be considered a road-block for now.

I´ve tyred to reproduce this scenario with VyOS 1.3-rolling-202007300117.
The static-default-route is correctly installed in the routing table after rebooting the router.

Sorry, I don't understand what you mean. Can you tell me more about it? What is using net-snmp to submit feature requests?

Please file feature request with net-snmp.

The list of oids currently supported by vyos is as follows:

What if we render pool instead of server to ntp.conf for all servers?

Please retest with the latest rolling as bond/ethernet went through a major refactoring.

We use net-snmp as SNMP server and can only provide the OIDs it supports. Please be more verbose what is missing and what is expected.