I have a CCR with 3 BGP peers.
When I use telnet or similar to do something like this:
/ip route> print where dst-address=10.10.10.5/32
I get a response in a few seconds, running the following in the API:
/ip/route/print
?dst-address=10.10.10.5/32
Fails to give a response at all on this router (even if I increase the timeout to 5 minutes). If I run the same code against a router with less routes (one that only has my OSPF routes but not the BGP routes) it works fine and returns quickly.
According to http://forum.mikrotik.com/viewtopic.php ... ch#p365124 I need to use that syntax to efficiently search the route database via command line, My investigation so far indicates the matching API is either not optimized or I am calling it the wrong way. The CCR is running 6.10.
Any suggestions?
Re: Optimal way to search ip route when I know the exact pre
My suggestion is: upgrade to 6.15 and after that upgrade BIOS [firmware]
-
-
boen_robot
Forum Guru
- Posts: 2400
- Joined:
- Location: europe://Bulgaria/Plovdiv
Re: Optimal way to search ip route when I know the exact pre
Which API client are you using?
Many API clients just directly start receiving, before they've made sure there's something to receive. Combined with "blocking mode", and a few seconds of inactivity, this leaves them thinking the connection has timed out, and thus they disconnect.
My client did this too, before its current version. Try using it, as see if it works (as it now should). Unless this is a RouterOS bug of some sort, it should give you a reply in a few seconds... maybe a few more than from terminal, but certainly give you results.
The exact PHP to try out in this case:
Many API clients just directly start receiving, before they've made sure there's something to receive. Combined with "blocking mode", and a few seconds of inactivity, this leaves them thinking the connection has timed out, and thus they disconnect.
My client did this too, before its current version. Try using it, as see if it works (as it now should). Unless this is a RouterOS bug of some sort, it should give you a reply in a few seconds... maybe a few more than from terminal, but certainly give you results.
The exact PHP to try out in this case:
Code: Select all
<?php
use PEAR2\Net\RouterOS;
require_once 'PEAR2_Net_RouterOS-1.0.0b4.phar';
$client = new RouterOS\Client('hostname', 'admin', 'password');
$route = $client(new RouterOS\Request('/ip route print', RouterOS\Query::where('dst-address', '10.10.10.5/32')))->getAllOfType(RouterOS\Response::TYPE_DATA);
//$route should now contain the one reply that interests you.
echo $route('gateway') . "\n";
//etc. Re: Optimal way to search ip route when I know the exact pre
rextended:
Is there anything specific that indicates an update will fix this? I've been through the release notes and I'm not seeing anything that seems like it has anything to do with this. The reason I am hesitant to upgrade is this router happens to be our Internet Edge which has all the fiber plugged into it (hence it has the full BGP tables), not a router I want to trouble if it is not neccesary. I'll see if I can get a copy of the BGP tables on another router that is not in the direct line of customer traffic and upgrade that one to see if it has any effect.
boen_robot:
I use python, Its a hevily modified copy of the python library on the wiki. I tried your code and it returned a result after 14 minutes, after I modified my code to set the timeout to 15 minutes mine works as well. So I believe the problem is with the mikrotik.
Anyone from Mikrotik care to comment as to what I need to do to speed this up? Given that my command line can return the data in a few seconds I know the Tik can do it, I'm guessing I need to change some syntax on the request or maybe this is simply not optimized on the API.
Is there anything specific that indicates an update will fix this? I've been through the release notes and I'm not seeing anything that seems like it has anything to do with this. The reason I am hesitant to upgrade is this router happens to be our Internet Edge which has all the fiber plugged into it (hence it has the full BGP tables), not a router I want to trouble if it is not neccesary. I'll see if I can get a copy of the BGP tables on another router that is not in the direct line of customer traffic and upgrade that one to see if it has any effect.
boen_robot:
I use python, Its a hevily modified copy of the python library on the wiki. I tried your code and it returned a result after 14 minutes, after I modified my code to set the timeout to 15 minutes mine works as well. So I believe the problem is with the mikrotik.
Anyone from Mikrotik care to comment as to what I need to do to speed this up? Given that my command line can return the data in a few seconds I know the Tik can do it, I'm guessing I need to change some syntax on the request or maybe this is simply not optimized on the API.
-
-
boen_robot
Forum Guru
- Posts: 2400
- Joined:
- Location: europe://Bulgaria/Plovdiv
Re: Optimal way to search ip route when I know the exact pre
Yeah, I'm afraid it's the latter. A query is supposed to be the equivalent of a "where" argument on a print, so if there's such a major difference, it's not because of an inappropriate syntax.Anyone from Mikrotik care to comment as to what I need to do to speed this up? Given that my command line can return the data in a few seconds I know the Tik can do it, I'm guessing I need to change some syntax on the request or maybe this is simply not optimized on the API.
Could you perhaps try to duplicate this in a "lab setting" so to speak... i.e. a virtual machine with 6.10, with enough routes defined on it? If it doesn't occur there, then it's a CCR firmware specific issue, and if it does, it's a generic RouterOS problem. Also, if it does occur, you can try to set up 6.15 on that VM, and see if it occurs there too (i.e. is it solved already). I'm sure MikroTik devs will greatly appreciate the narrow down.
Re: Optimal way to search ip route when I know the exact pre
Well the 1100AHx2 is unaffected by this issue:
I tried 5.26, 6.10 and 6.15 on the 1100 after iBGP peering it with the CCR to bring the full table.
5.26 took 56 sec, 6.10 and 6.15 take about 1 minute 35 seconds.
I guess I'll have to schedule an upgrade of the CCR to rule out the hardware.
I tried 5.26, 6.10 and 6.15 on the 1100 after iBGP peering it with the CCR to bring the full table.
5.26 took 56 sec, 6.10 and 6.15 take about 1 minute 35 seconds.
I guess I'll have to schedule an upgrade of the CCR to rule out the hardware.
Re: Optimal way to search ip route when I know the exact pre
...My suggestion is: upgrade to 6.15 and after that upgrade BIOS [firmware]
Re: Optimal way to search ip route when I know the exact pre
Running 6.15 and upgrading to firmware 3.13 the time is lower at 5 minutes 20 seconds (instead of almost 15 minutes) but still nowhere near the speed of the CLI (about 10-15 seconds).
Re: Optimal way to search ip route when I know the exact pre
mmm....Running 6.15 and upgrading to firmware 3.13 the time is lower at 5 minutes 20 seconds (instead of almost 15 minutes) but still nowhere near the speed of the CLI (about 10-15 seconds).
Mikrotik reply?
Re: Optimal way to search ip route when I know the exact pre
I ran a few more tests, on an 1100AHx2 a similar difference occurs (via command line comes up almost instantly, API takes 1 minute, 30 sec, vs a few seconds on CCR command line, CCR API is 5 minutes).
So I'm guessing the upgrade removed the difference between the two platforms but there is a common API optimization issue that needs to be addressed. I'll try it out on an x86 VM once I figure out how to set one up on virtualbox to confirm (There's no way i'm not going to get a full BGP table on a RB450 or RB750).
So I'm guessing the upgrade removed the difference between the two platforms but there is a common API optimization issue that needs to be addressed. I'll try it out on an x86 VM once I figure out how to set one up on virtualbox to confirm (There's no way i'm not going to get a full BGP table on a RB450 or RB750).
Who is online
Users browsing this forum: No registered users and 29 guests