I have a problem and Google hasn’t been able to help.
I have the following routing table:
[admin@MikroTik] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 S 0.0.0.0/0 255.255.255.1 1
1 ADS 0.0.0.0/0 10.254.0.254 12
2 ADC 10.254.0.0/24 10.254.0.30 ether1 0
The static route has a routing mark set as follows:
The problem is that in order to select one of the two routes to ‘0.0.0.0/0’ in a script, I need to test against both the dst-address and the routing-mark. I can’t find a way of doing this…
[admin@MikroTik] > :put [/ip route get [find dst-address="0.0.0.0/0"] gateway]
10.254.0.254
works, as does:
[admin@MikroTik] > :put [/ip route get [find routing-mark="testmark"] gateway]
255.255.255.1
However the following code does not:
[admin@MikroTik] > :put [/ip route get [find dst-address="0.0.0.0/0" routing-mar
k="testmark"] gateway]
no such item
The weird thing is that the command line parser accepts this, prompts for this and colourises correctly for this, so it would appear that this should work. It just doesn’t.
I’d report a bug with support. The issue seems to be that the find command for just 0.0.0.0/0 as a dst-address doesn’t find both routes, so filtering further (with the routing mark) fails because the original set didn’t contain the item with that routing mark.
Tests run:
[admin@MikroTik] /ip route> print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 10.10.100.100 1
1 A S 0.0.0.0/0 10.10.100.100 1
[...]
[admin@MikroTik] /ip route> print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S dst-address=0.0.0.0/0 gateway=10.10.100.100 gateway-status=10.10.100.100 reachable outside distance=1 scope=30 target-scope=10 routing-mark=test
1 A S dst-address=0.0.0.0/0 gateway=10.10.100.100 gateway-status=10.10.100.100 reachable outside distance=1 scope=30 target-scope=10
[...]
[admin@MikroTik] /ip route> print where dst-address="0.0.0.0/0"
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 10.10.100.100 1
[admin@MikroTik] /ip route> :put [:len [find dst-address="0.0.0.0/0"]];
1
[admin@MikroTik] /ip route> remove 0
[admin@MikroTik] /ip route> :put [:len [find dst-address="0.0.0.0/0"]];
1
[admin@MikroTik] /ip route>
That’s definitely not right. Neither find nor where account for both routes for the quad zero path.
/ip route> print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S dst-address=0.0.0.0/0 gateway=10.200.200.2 gateway-status=10.200.200.2 reachable ether2 distance=1 scope=30 target-scope=10 routing-mark=test
1 A S dst-address=0.0.0.0/0 gateway=172.16.23.1 gateway-status=172.16.23.1 reachable ether3 distance=111 scope=30 target-scope=10
/ip route> :put [/ip route get [find where dst-address=0.0.0.0/0 routing-mark=test]]
.id=*f;dst-address=0.0.0.0/0;gateway=10.200.200.2;gateway-status=10.200.200.2 reachable ether2;distance=1;scope=30;target-scope=10;routing-mark=test;active=true;static=true;disabled=false
this is how it works.
if you add gateway before last closing square bracket, you will get the gateway address.
/ip route> :put [/ip route get [find where dst-address=0.0.0.0/0 routing-mark=test] gateway]
10.200.200.2
backporting something means bringing the same instability of the new version back to the old one. basically if we backport everyhing, the only difference is the version number. so why change the version numbers at all?
Ouch, a Caesar quote. Now I feel like I done stabbed you.
I appreciate Mikrotik’s approach to back porting - new features go into new versions. But a CLI parser bug makes me kind of nervous. If someone had used that find command together with remove they might have killed their default routes on a remote router (I am an idiot and often forget safe mode - but that’s a different problem). Also, what else doesn’t get caught by this bug? Is it just routing marks, or every string in an AND operation?
We have no idea when 5 will go into stable, and many people wont upgrade immediately but wait a few versions. I am not saying back port the IPv6 features of 5.x, or the new wireless protocols. Just the serious bug fixes until the 5 tree is stable.
and to make new features