Multiple conditions with [find ...]

NAB · Wed Sep 15, 2010 5:23 pm

Hi,

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:

/ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
    255.255.255.1 routing-mark=testmark scope=30 target-scope=10

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.

Any ideas?

fewi · Wed Sep 15, 2010 6:02 pm

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.

Tests run on 4.10 and 4.11.

NAB · Thu Sep 16, 2010 10:34 am

Damn. And I wasted four hours trying to debug this, convinced I was doing something wrong.

E-mail sent.

NAB · Thu Sep 16, 2010 11:02 am

After a good sleep and a bit more digging, it appears that the problem is caused by the routing marks...

[admin@MikroTik] > /ip route add dst-address=1.1.1.1/32 gateway=2.2.2.2 comment="test_a"
[admin@MikroTik] > /ip route add dst-address=1.1.1.1/32 gateway=3.3.3.3 comment="test_b" routing-mark="testmark"
[admin@MikroTik] > :put [/ip route get [find dst-address="1.1.1.1/32" comment="test_a"] distance]               
1
[admin@MikroTik] > :put [/ip route get [find dst-address="1.1.1.1/32" comment="test_a"] gateway]        
2.2.2.2
[admin@MikroTik] > :put [/ip route get [find dst-address="1.1.1.1/32" comment="test_b"] gateway] 
no such item

In fact, looking even further, [find...] completely ignores anything where the routing mark is set:

[admin@MikroTik] > /ip route add dst-address="10.255.2.21/32" routing-mark="testmark" gateway=10.254.0.254
[admin@MikroTik] > :put [/ip route get [find dst-address="10.255.2.21/32"] gateway]                          
no such item

But take out the routing mark and it works perfectly

[admin@MikroTik] > /ip route add dst-address="10.255.2.22/32" gateway=10.254.0.254                         
[admin@MikroTik] > :put [/ip route get [find dst-address="10.255.2.22/32"] gateway] 
10.254.0.254

So, big, huge and fat bug.

NAB · Thu Sep 16, 2010 11:07 am

Should also add that this bug doesn't appear to exist in ROS 5.0b6.

janisk · Thu Sep 16, 2010 11:11 am

/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

that was last 5.0 build thought.

NAB · Thu Sep 16, 2010 11:26 am

that was last 5.0 build thought.

Yes. It all appears to work fine for the 5.x tree, just not 4.x

Thu Sep 16, 2010 12:18 pm

that was last 5.0 build thought.
Yes. It all appears to work fine for the 5.x tree, just not 4.x

that's why we make those new versions. to fix bugs

and to make new features

fewi · Thu Sep 16, 2010 3:10 pm

But are you going to back port it? 5.x is beta, after all.

Thu Sep 16, 2010 3:14 pm

et tu, fewi?

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?

fewi · Thu Sep 16, 2010 3:59 pm

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.

:D

NAB · Thu Sep 16, 2010 8:11 pm

basically if we backport everyhing, the only difference is the version number.

Indeed, but the only person who has mentioned backporting everything is you.

What it boils down to is that there is a known bug in your 'stable' release tree. All we're asking for is a fix.

Fri Sep 17, 2010 10:44 am

It's not that we don't backport anything. We do. Major problems are fixed.

Multiple conditions with [find ...]

Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Re: Multiple conditions with [find ...]

Who is online