Router OS 7 version Uplift to 7.21.4

[snuffy22]

Allow newer RouterOS 7.21.4 to work with Netlab.

[snuffy22]

@ipspace I image that you will squash commit this to keep history clean?

Still not gifted in the git department

[ipspace]

@ipspace I image that you will squash commit this to keep history clean?

Yes, all PR merges are squash commits.

Still not gifted in the git department

No worries, we've all been there ;)

[snuffy22]

Ok i've hit a few more wonderful 'issues' with passing some more tests between versions

When I feel i've got close to same amount working as old I will speak up

[ipspace]

Ok i've hit a few more wonderful 'issues' with passing some more tests between versions

Please don't spend even a microsecond worrying about supporting 7.18.x. If Mikrotik feels it's OK to introduce non-trivial disruptive changes to the CLI, then I feel it's perfectly OK to say "netlab release 26.07 (or whatever) requires CHR7 release 7.21, but feel free to use older netlab versions if you like to work with 7.18"

When I feel i've got close to same amount working as old I will speak up

Right now, the BGP RR code is generating invalid configurations. Let me know once you get that working, and I'll rerun the tests. You can also run the integration tests yourself (https://netlab.tools/dev/integration-tests/#running-an-integration-test-suite), but please check in advance @ https://tests.netlab.tools/_html/routeros7 what has been failing in the past. For example, RRs have to work, but I wouldn't worry too much about BGP community propagation.

For the moment, I've changed the status of both PRs (because the EVPN one obviously relies on working BGP config) to "draft". Once you feel you have a working solution, please change it back to "ready for review"

[snuffy22]

So the Route Reflector part

My last local update got it mostly working on 7.21.4 this passed 15/16 tests from the 03-ibgp-rr.yml

[nhu]          Check next-hop handling of reflected routes [ node(s): r2 ]
[FAIL]         Node r2: The next hop(s) for prefix 172.0.42.0/24 is/are 10.0.0.1, not 10.0.0.10

I then decided to test a bunch of other 'new' versions like 7.23.1 and 7.24beta2 all love to fail on this test..
I will try to raise a bug report with Mikrotik as I confirmed that it all worked fine on our prev version of 7.18.2 =/

[ipspace]

My last local update got it mostly working on 7.21.4 this passed 15/16 tests from the 03-ibgp-rr.yml

Trying to figure out what's going on, I get syntax errors when configuring that test

[admin@dut] > /routing/bgp/connection set [/routing/bgp/connection find name=10_0_0_2] router-id=bgp_router_id
expected end of command (line 1 column 74)
[admin@dut] >
[admin@dut] > /routing/bgp/connection set [/routing/bgp/connection find name=10_0_0_2] local.role=ibgp local.address=loopback
[admin@dut] >
[admin@dut] > /routing/bgp/connection set [/routing/bgp/connection find name=10_0_0_2] local.role=ibgp-rr-client
syntax error (line 1 column 85)

Did you push the latest version of your code into this PR?

[snuffy22]

@ipspace I have now updated my branch version that works for all but that one test

Sorry I didn't push earlier

[ipspace]

I then decided to test a bunch of other 'new' versions like 7.23.1 and 7.24beta2 all love to fail on this test.. I will try to raise a bug report with Mikrotik as I confirmed that it all worked fine on our prev version of 7.18.2 =/

The problem seems to be "next hop self" on reflected routes. Some vendors (Cisco IOS) do not change it; others (Arista EOS) always change it and require a route map to work properly. Looks like Mikrotik switched camps ;))

Anyway, if that's the case (I have to do a bit more digging, and maybe change the error message in the failed test), you'll have to change how "next hop self" is configured.

[ipspace]

OK, it's Mikrotik switching camps... Here's an old documentation for nexthop-choice=force:

Note that nexthops set in filters always takes precedence. Also note that nexthop is not changed on route reflection, expect when it's set in filter.

And here's a recent one:

Note that next-hops set in filters always take precedence.

So you'll need a route map (= filter) on the BGP route reflectors applied on IBGP sessions to set the next hop to self but only for EBGP routes. Alternatively, we can document the caveat and move on, but then we'll have problems with EVPN RR tests.

[snuffy22]

I will attempt a filter to fix it properly, though my previous attempt at trying to make one that just removed 'ext communities' loved to just drop the whole route rather than remove the ext communities from the outgoing update.

At least mikrotik chr boots in sub 1 minute so its not incredibly painful when i forget to check the generated output before doing netlab up.

[snuffy22]

I have updated and the 03-ibgp-rr now fully passes.
Also did a little test adding another ebgp peer to dut and it added another rule as expected.

[snuffy22]

I will be updating with a 'per neighbor' route filter in the next 24 hrs..
the idea being.. per neighbor has entries for each 'type' of filter if needed
i'm sure i'll manage to get tripped on some logic when doing it.. but its a 'plan'

/routing/filter/rule add chain=NEIG_A  rule="jump RR_NEXTHOP;"
/routing/filter/rule add chain=NEIG_A  rule="jump EXT_COMM_DISABLE;"

[ipspace]

I have bad news -- the VRF (and consequently MPLS) tests are failing with 7.21.4. The VRF templates are using the neighbor template from routeros7.macro.j2, but there's probably a mismatch between what that code expects and what you're now configuring in those templates, or maybe you just need to upgrade the VRF BGP configuration to 7.21.4 syntax.

Also, the BGP default origination test is failing. Looks like extra/bgp.session/routeros7.j2 needs a fix as well.

I apologize for the moving target, but if we want to make a clean break with 7.18.4 (and it seems like we have to), then everything we had so far has to work with 7.21.4.

If you don't have time to fix these other things, I could try to reverse-engineer what needs to be done.

[snuffy22]

@ipspace I am working through those tests now.

Will it be fully ready by next release, unsure but will keep working through the failing tests and updating here.

04-default originate passes now (VRF fix was my latest change)

[ipspace]

Will it be fully ready by next release, unsure but will keep working through the failing tests and updating here.

Thanks a million. I'm pretty sure the remaining problems are somewhere in the VRF config and that you'll nail it pretty soon.