I’d like to send a raw UDP packet every second towards some host in the network with router statistics (cpu, mem, selected interfaces up/down + tx/rx) in condensed form (raw hex bytes) to fit as much data as possible into one packet. Is this currently possible with scripting?
I’m looking for same thing today.
In your case maybe using API can be better?
I’m searching a way to create and send account (for dhcp) radius packets to a freeradius server.
No, API is too bulky to reliably poll couple of thousand devices every second. Devices should report their state by themselves without being asked for that information every time. It’s really idiotic if you think about it. You know you’ll poll each device every n seconds, so why generate useless traffic and eat away cpu cycles for that?
The easiest way I can think of to do this would be to create a script that basically prints those values (comma-separated), then in logging create a rule to send only those messages to a remote syslog server (your host). Parse the incoming syslog message, remove the unneeded syslog header info, and read the values.
That’s some idea, and it should work. Thanks for the pointer. If nothing else comes up, I’ll try naging Mikrotik for some kind of tool for this, or maybe work out some RFC for such protocol. It should be somewhat useful for people with networks with thousands+ of nodes.
It is generally not necessary for something like this, I think. With large numbers of devices, a combination of SNMP polling every ~5 minutes, plus traps received instantly when unusual events occur (interface down, cpu higher than threshold, etc.) should generally suffice. Storage of interface graphs with per second resolution would be extreme.
SNMP polling every second can also be used to fetch the values you want, you can request multiple OIDs in one request. This might be less CPU intensive than a script, but would require traffic to the MikroTik to make the requests.
Actually, you can probably send the data as a trap using the script:
/snmp send-trap value=“whatever,some,data,100,99.4”
With the API, you can call “/interface monitor-traffic interface=bridge-local interval=1s”, and “/system resource print interval=1s”, at which point the API will keep returning replies every second. In other words, there’s no “polling” involved in that case. The two requests can be done over a single connection, with the API client processing them in the order they arrive in. Plus, the API strikes a good balance between being compact vs. being reliably delivered (because it’s on TCP, and not UDP) and easily parsable.
But it won’t work over UDP, that you can expect every second, and monitor for it’s absence to quickly determine that something is wrong, and you either have significant PLR in network, or device went down after few missed packets. But keep the discussion coming. I’m open to ideas 
and keeping 1s-resolution graphs would be unnecessary obviously – sending if stats every second is not really required, pretty much empty packet with sequential number would be sufficient.
I’m pretty sure TCP takes care of keeping the connection alive, and thus dead if there’s a failure. If the API client is disconnected, it means there’s some sort of a problem at or between the two end points (either a software or hardware one), but whether you use TCP or UDP, you can’t get more specific than that. And (assuming the API client is done right), a disconnect will become apparent as soon as you attempt to interact with said disconnected connection (or, if not done right, a few seconds after that, when the underlying sys call times out). Heck, UDP is faster precisely because it lacks this very safety.
On the API client side, if the connection goes off, you can retry it, and if the retry fails, log it as an outage.
Well, that’s another thing then. If sacrificing resolution by dropping the occasional packets is acceptable, I guess SNMP could potentially do this, though in that case, you wouldn’t really be detecting outages, since, by design, UDP can drop packets occasionally. I mean, you could, but you have to “manually” do that on the client side, and “guess” that the problem is “serious” rather than “temporary”.
How exactly do you do it with SNMP I’m not sure honestly. I haven’t personally used it. But the very description of it is the very thing you’re after.