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

Tested on 1.4-rolling-202105170417 works correct. Propose to backport this to 1.3

There are two separate issues in this task: quoting of hw-id values (resolved in Sagitta/Equuleus); re-ordering of interfaces with respect to hw-id (Open).

@wsapplegate I create a PR for it https://github.com/vyos/vyos-1x/pull/847
Can you describe how to test/check it? I'm not familiar with that dns format. I tried zone with dot and without. Not sure how to check/test it.

PR: https://github.com/vyos/vyatta-cfg-quagga/pull/79

@rizkidtn I don't understand exactly what wrong with the community?
Customers sent you routes, with blackhole community, on the router you mark match this community and set next hop "blackhole" IP address.

My expectation is that you can configure MTU 1500 at a GRETAP device to ensure same mtu at bridge. This solves a lot of problems caused by mixing host with different MTU size.
Larger frames that exceed pmtu and have df = 1 are fragmented and send to the gretap endpoint. Thus, underlay MTU has no impact of the communitcation between two hosts that are bridged via GRETAP and communicate with MTU 1500.

@ernstjo what you mean by "too old"? I think it's fairly new (5.10):

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

I don't fully understand your scheme
What interrelation between arp and tcp policy?

show conf com | match ospfv3

Copy configuration.
Delete protocols ospfv3
commit
re-add ospf config.

I just tried that and it fails. We get

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:

did you try
set protocols static table 1 route 0.0.0.0/0 interface 'eth1'

Iproute2 is too old and needs a newer version. So, we have to upgrade that package.

Even I also faced this error while upgrading the server from 1.2.7 to the latest rolling release.

Time Exceeded (3)

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

PR for current https://github.com/vyos/vyos-1x/pull/844
PR for Equuleus https://github.com/vyos/vyatta-cfg-quagga/pull/78

Fix should be easy implement in create function with following add in:

I can't reproduce it VyOS 1.3-rolling-202105011026

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.

As WireGuard has bo MAC address a EUI64 link-local address is calculated artificially https://github.com/vyos/vyos-1x/blob/current/python/vyos/ifconfig/wireguard.py#L161

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.

Hi @ernstjo got an idea how we should do it?

Thanks for the hint.