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？

So I fixed this on my setup by kill -9 conntrackd
and then sudo /etc/init.d/conntrackd start

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

This happens only when in config before migration exists nodes system 'ntp' without other params.

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