Any plans adding webrtc support/endpoint at routeros?
Webrtc is great at event streaming as it keeps the underneath channel always open eliminating tcp connection overhead and polling. This way several metrics, starting from network traffic, can be realtime monitored and can leverage the power of cloud (realtime: analytics, threat detection, logging, you name it).
Right now, routeros console lacks traffic monitoring (except monitor-traffic for physical interfaces only). No vlans, no queues, no firewall traffic/statistics realtime monitor, which are available only via winbox. Webrtc could fill this gap and ‘reinvent’ routeros as a powerful truly cloud router. (I’m talking about CCR especially).
I don’t understand what you’re talking about. To my knowledge, WebRTC is a browser API, mainly suitable for real-time media (audio/video) applications. How is it related to RouterOS?
Not quite true, the same real-time stats are also available via WebFig.
Well, webrtc is a broad term, a bit confusing for a router.
I’m talking about a mechanism of streaming realtime events (logs, bandwidth usage, etc) programmatically, so they can be analyzed by external servers. For example, imagine all traffic/statistics winbox tabs be available to an external server for realtime threat detection. Think about a realtime syslog service over 1 always on established connection.
A websocket endpoint could be a great start. Webfig is great, but it doesnt have APIs, so the solution could be an API websocket endpoint available to developers (not only webfig).
Andriys, it isnt possible right now to monitor realtime the bandwidth (data rates, packet rates, (not the actual traffic)) of a specific firewall rule or a specific queue. By monitor, I dont mean looking at a graph all the time, but let an external server do it and alert when something is wrong based on criteria running on the external server. The router should be capable of sending that info as it happens, not on external demand (API), in the first place.
Netflow is really heavy for this job, sending ALL traffic or ALL headers ALL the time isnt the solution.
Syslog isnt suitable for the job, as it doesnt stream (lossy udp, huge overhead when tcp used). A syslog that could connect to a websocket server could be a solution (however a more old fashioned one), but the current syslog solution, no.
Also, the API is great for asking the router for data sparsely, not realtime communications.
There is no way to programmatically get (cli, API, syslog) data/packet rates for resources other than bridges and physical interfaces (using monitor-traffic).
I would like to listen to more thoughts on this topic.
NetFlow isn’t that heavy. Really. I mean it. It’s not something like port mirroring, it doesn’t mirror packets nor even packet headers. It only sends to a collector an accumulated per-flow statistics (either when flow is finished or on a regular basis with configurable interval). It’s perfect for nearly real-time per-interface/ip/application/flow/etc bandwidth (bps and pps) monitoring.
I don’t see how WebSocket can be better then a pure TCP transport. WebSocket protocol IS, basically, just a way to convert (standard says “upgrade”) an HTTP connection into a clean TCP transport.
Well, you can, for example, execute the following command via API to get firewall filter counters: /ip firewall filter print stats.
Other counters you can see via WinBox should also be available via API.
I’m pretty sure WinBox and WebFig query (poll) various statistic counters in a similar way.
Netflow contains too much ‘noise’ information which need much more great bandwidth and processing power to analyze at the back end server. Is it possible to netflow (bps and pps) a specific set of simple queues?
Websocket is a persistent tcp connection. Syslog implemented here, establishes tcp connections continuously(tcp keep alive could be a better approach, so that all messages are transmitted over the same tpc connection)
Yes, I can use the command but it will kill the router if I execute it every second! Mind the fetch overhead too. Webfig uses tcp posts all the time (polling) witch is ineficient. It works well though and my concern is that it isnt available directly via a webfig API.
