Send command output to remote server

RouterOS Scripting
1

Hello,

I am trying to figure out a way to send the output results of this command:

/ip route print terse

to a remote server (linux) for further processing.

The catch here is that I don’t want to write the output to a file and then upload the file because I need to run this command/script every few minutes.
So by using a file will wear out the NAND storage since this will be used mostly on routerboards.

Does anyone have any idea how to send this data to a remote server?
I don’t mind the transport protocol (it can be unencrypted telnet for all we care).

2

If you don’t expect thousands of changes at once, it might be best to make an API script that calls “/ip route print follow”, and keeps the connection opened, so that it monitors any changes to the route list.

Alternatively, you could use the “as-value” argument, and then pass the values with “/tool fetch”, e.g.

:local routes [/ip route print as-value];
:foreach route in routes do={
    /tool fetch url=("http://example.com/\?dst-address=" . $route->"dst-address" . "&gateway=" . $route->"gateway");
};
3

Hello,
Thanks for your suggestions!

I need to avoid using the API since this requires access to the remote routers (and there are more than 700 of them using anywhere from v2.9.x to v6.x).
I’ve already implemented it this way using SSH (which works on all versions of mikrotik - since 2.9.x - unlike the API).
But since this approach requires read only access, many router owners are not happy with this and refuse to provide access to collect the statistics I need.

I am trying to figure out a way to send the complete routing table (including BGP AS Paths - that’s mandatory) without having access to the routers.
A local script that will run periodically on each router and push the data to me is what I am looking for, since this way I won’t need any access on the remote routers.
I understand that It may not work on older versions since the scripting engine has undergone many changes over the years.
I can live with only v6.x support for now (which is the majority of the routers at the moment).

Your second approach sounds promising, though after testing it on 6.33.5 & 5.26 it doesn’t seem to work.

The (single) GET requests reaching the webserver from both versions look like this:

x.x.x.x - - [18/Jan/2016:00:08:03 +0200] "GET /?dst-address=&gateway= HTTP/1.1" 200 12806 "-" "Mikrotik/6.x Fetch"
y.y.y.y - - [18/Jan/2016:00:11:05 +0200] "GET /?dst-address=&gateway= HTTP/1.1" 200 12806 "-" "Mikrotik/3.x Fetch"

Any ideas?

Btw, the routing tables on the routers have anywhere from 700 to 2500 routes.
So I expect a LOT of GET requests using the method above (assuming it can work).

It would be nice if the whole ‘/ip route print terse’ output (nice grep-able format) could be sent as a whole with a single request remotely somehow since I’ve already written a parser for that output that converts it to standard ‘sh ip bgp’ formatted output (which can then be parsed by other tools).

4

I figured it out

:local routes [/ip route print detail as-value];

:foreach route in $routes do={
    # :log info  $route;
    /tool fetch keep-result=no url=("http://test.webserver.local/\?dst-address=" . $route->"dst-address" . "&gateway=" . $route->"gateway" . "&bgp-as-path=" . $route->"bgp-as-path");
};

But it’s really really slow.

The GET requests reach the webserver at a rate of 1 per second.
The webserver can handle way more than that. Each request is processed in just ~2-3ms so it doesn’t wait for the server.
Both the router and the webserver I am testing this is on a local gbit network.

Any ideas? :slight_smile:

5

Commenting the fetch command and leaving only the log info it executes instantly.
So the fetch command slows things down for some reason.

6

How about having the server send the command via ssh?

/usr/bin/ssh admin@hostname "/ip route print terse"
7



8

You could collect the output in a string, and at the end, do one fetch call with the whole thing.

The downside is that there’s a limit on how long a URL can be. I haven’t personally ever reached it, but if you have hundreds of routes, you may end up reaching it.

e.g.

:local routes [/ip route print detail as-value];
:local routesOutput "";
:foreach i,route in=$routes do={
    # :log info  $route;
    :foreach key,value in=$route do={
        :set routesOutput ($routesOutput . $key . "[" . $i . "]=" . $value . "&");
    };
};
/tool fetch url=("http://test.webserver.local/\?" . $routesOutput)

If you do reach it, you could rework the above so that you check on every iteration if you’ve reached the limit, and send the previous output if you have, while continuing to gather new output for the next request.

9

Thanks for the suggestion.

The complete route list certainly reaches the default limits of the webserver (Apache by default has a limit of 8KB for example).
The fetch command might also have a limit of its own.

So I will need to modify your code to send the data in 8KB chunks.

This method certainly imposes a lot of work to be done to make it fit on my current system but if there isn’t any other way I guess that will have to do :frowning:

Of course, the best solution would be Mikrotik’s BGP to provide a telnet interface with commands and output like Cisco’s/Quagga’s.
That would be awesome! But I wouldn’t bet on that ever being implemented :stuck_out_tongue:

10

Didn’t you say that you’ve implemented that already for MikroTik’s SSH, and that clients are not happy about it?

Or if you mean having RouterOS be able to send info over telnet/SSH, it already can, with the “/system ssh” command.

Or… what?

11

You are right I wasn’t clear about that.

I meant it would be nice to have a telnet interface like Cisco/Quagga (same commands, same output) since that way I wouldn’t need read-only ssh access but read-only ‘bgp access’.
And there are already tools out there to parse cisco/quagga formatted output.

On the network I am monitoring there are quagga routers and their owners have absolutely no problem providing me with read only access on the BGP daemon (port 2605).
This way I can see information related only to BGP (which I am only interested in).

Mikrotik users on the other hand are not so happy giving SSH access to their routers since I could potentially access many many more stuff than BGP and the routing table (in other words they have to trust me that I won’t go snooping around on their routers).

12

I could imagine MikroTik eventually tweaking their permission system to allow per-menu settings. It’s been a VERY frequent feature request, and even though it’s just text, you can feel that the support staff is already sick to their stomach of repeating “you can’t do that… currently” :laughing: .

But WHEN they do that (because I don’t think it’s an IF), it would simply be their “normal” SSH output, not the Cisco one, that’s for sure.