It may be a good idea to cherry-pick this for 1.4.x branch.

I've creatred a pull request for the above - https://github.com/vyos/vyos-1x/pull/1313

Also, these routes getting an administrative distance of 1, which is impossible to override. I believe the default route from DHCP normally has 210 which is manageable. So, the quick workaround could be increasing distance of these routes.

Below is a packet capture from DHCP exchange:

Sounds good to me.

Any news on this?

I haven't tested it directly but I haven't experienced this problem while working on the configuration changes. I don't have much time right now, so I can't test the exact scenario.

The issue seems still present in Vyos 1.3.0-rc5

Where can I get the rc4? The last RR I see is vyos-1.3-rolling-202105011026-amd64.iso.

BTW, the same happens when adding/removing interfaces to an area.

I did some more digging and found a reliable way of reproducing it:

I think I found a way to reproduce it:

• rename an interface that was previously included in ospfv3 configuration and then remove it in the same commit from ospfv3 in the same commit.
• get an error that interface is not found. I think that at this stage the configuration is applied only partially
• after that error configuration in frr and vyos goes out of sync and never unsynchronized unless forced (or by lucky accident :-)

Hmm, I still have it in my running-config. Is there a way to force config regeneration?

The "Time exceeded" likely means that message is sent to a black hole. There are two bfd sessions running through the same tunnel - one for OSPF and the other for OSPFv3. Timeout settings are the same and the first one is established instantly and is running happily. The OSPFv3 one is not so much:

BFDd amybe creating those addresses automatically. In theory, it doesn't matter what they are as long as both ends have a way of learning them. I'm not sure if this is a general issue or an issue only with wireguard but right now bfd doesn't work with OSPFv3 over wireguard.

BTW, it appears ths fe80::... addresses used in bfd dialogue do not belong to any of the actual interfaces. It could be by design but this si something I discovered when trying to troubleshoot the session. This could also be the reason for mismatch between session ends if the other side does not know the peer address.

Attaching packet captures from both ends filered with bfd && ipv6.addr == fe80::/64 rule

I ran a packet capture on the session and It appears had been an issue with firewall settings on the provider site. It just happened that we hit a similar issue with two providers and VyOS was the common denominator but It appears to be red herring. Feel free to close.

the same is the case for GRE interfaces too (ip6gre in particular)

I ran a packet capture on this BGP session and it appears that VyOS actually sends some packets out and they appear to go through the right gateway... I'm investigating with the provider and will post an update here shortly.

Yes, I've changed the source since i posted the configuration and now it is the specific IP address that the peer expects.

This issue is consistently reproducible and I'm experiencing it with two peers. I convinced one of them to disable passive mode on their end but the other one is not that flexible.

I've also tried with disable-connected-check option with no effect

This is the current setup:

The route is set and validated with traceroute and it has 2 hops.

The 2001:19f0:ffff::1 is the neighbour, it is accessible via the Kernel route and I'm able to pull routes from it. The setup is multihop. But I think you are on something. I think the peer should return the gateway as the next hop and not itself. I'm experimenting with Vultr and their setup is questionable, so this is just one more thing that they messed up. Anyhow, thanks for your help. Feel free to close the ticket.

Hmm, all other routes have longer prefixes, so they should take precedence. As far as I understand the priority is prefix length (longest first) -> admin distance -> metric. So, your explanation contradicts this unless I miss something.

Sorry for the late reply, I've dismantled the setup as I needed to put the PPP link back in use, I will look into it again tonight. In essence, it would be good to see something like this on terse view:

I think the presence of the kernel default route may be the problem. It comes from RA through autoconf option on the interface. I will do some more testing.

I still see it in frr after the reboot but it is not showing in the output of show ipv6 route, so it seems like just a visualization problem.

What command do you use to get this?

I will give it a try once the image is out. The latest right now is still showing 2021-03-23.

Yes, I made mistake when adding the command to the ticket and I corrected it now. It should read: