New PR created for matching functionality in policy local-route: https://github.com/vyos/vyos-1x/pull/3938

@bernhardschmidt my PR for this made it into current rolling, which rather than just widening the table range, allows using 'set vrf' instead of 'set table' to policy route directly to VRFs with out-of-range RT IDs.

My opinion is largely based on my recent use-case for this, the GRE-match ethertype fields. I remember grumbling a couple of times about needing to convert bases to decimal in the past, but it's been too long to remember specifically what I was configuring at the time.

New PR that will allow targeting VRFs directly by name, to reach higher table IDs: https://github.com/vyos/vyos-1x/pull/3740

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

Just some quick testing with 2 VyOS instances connected via 2 straight ethernet into a virtual switch. eth0 on the remote has been given a description of "ETHZERO".

Looking at it, T5816 already attempted to fix this and is probably better for users - doesn't give the full flexibility of regex and doesn't handle '_' at all, but does have a strict format expectation.

Looking at the code in FRR, it just expands '_' to the full match '(^|[,{}()]|$)' and sends that whole match off to regexec().

All working nicely in current rolling.

@Thunderstorm looks like this one made it to the current rolling, if you're able to try it out?

I've created a PR for this: https://github.com/vyos/vyos-1x/pull/3655

I've created a PR with a very simple fix: https://github.com/vyos/vyos-1x/pull/3654

While I think the mismatch between PBR-addressable RTs and VRF RTs is a bit odd, the PR's been rejected and could be addressed differently in any case. In the meantime, VRFs with RTs 100-200 are targetable by PBR.

I think this one would be fixed by my PR for https://vyos.dev/T6045

@bernhardschmidt Are you able to share the relevant pieces of your VXLAN and VRF config as well?

@a.apostoliuk this one should be resolved in the current rolling release, if you're able to check it out?

I have https://github.com/vyos/vyos-1x/pull/3616 and https://github.com/vyos/vyos-1x/pull/3637 as works in progress.

I may have figured something out in https://vyos.dev/T4694.

It looks like outbound encap can be matched via routing expressions:

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

@fatred fix should be in the latest rolling, if you'd like to give it a go?

I've created a PR for this one: https://github.com/vyos/vyos-1x/pull/3590 covering both pieces - for Remote Port, if the PortID type is ifname, we use the PortID before falling through to Descr and so on. The detail view side of things is a straightforward call to lldpcli in this PR but could be improved.

I'll see if I can whip up a patch for the detail commands.

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

I've created a quick PR for this: https://github.com/vyos/vyos-1x/pull/3581

This is without my patch applied, confirming both the problem and a workaround:

On testing, it looks like vyos.utils.network.get_vxlan_vni_filter() doesn't know how to handle when there are no vni filters installed.

I've created a quick PR to give sane feedback from the validator: https://github.com/vyos/vyos-1x/pull/3572

I've created a PR for this that fixed a mistake with my original patch: https://github.com/vyos/vyos-1x/pull/3570

Is this meant to be possible this way?

As far as I can tell the test will always error if the remote matches and neither source-interface and source-address are configured differently, including the case where they're both blank (source-interface == None on both tunnels triggers this particular case).

Only recently moved from 1.3 to 1.5 and noticed rollback-soft immediately (great stuff), the completion message was annoying me too.

I've just been picking at this one tonight because it's close to some areas of interest (DMVPNs in VRFs), so hopefully this input is useful and appropriate: