I’m using RouterOS 6.46.4.
I enabled Traffic Flow, and added several interfaces to be monitored, including a bridge, but soon noticed that my collector wasn’t getting any traffic on the bridge’s network.
I had to add the individual interfaces that are in the bridge in order for the collector to see the traffic.
Is this expected behaviour? Or a bug?
If this is a bug, any idea when it was introduced?
If this is expected, why would Traffic Flow let you pick a bridge as an interface to monitor if you won’t see anything on it anyway?
I’m working on a script that will automatically configure Traffic Flow on hundreds of Mikrotik devices, all running different versions of RouterOS - I need to know exactly what I should be configuring traffic flow on (individual interfaces or bridge), so that it works on all of them.
We have hundreds of Mikrotik devices deployed all over North America. Every time you do a RouterOS update:
You suffer downtime, which in our case, costs thousands of dollars
Risk something going wrong, and the device not coming back online after a reboot, requiring a field tech to be dispatched, costing tens of thousands of dollars, and days of downtime
Also, RouterOS 6.46.4, which is what I’m using is the latest stable version, and it still isn’t working as expected. How exactly is us updating all of our devices to it going to help?
bridge interface is an “interface” which connects device’s CPU to the bridge (the L2 switch-like entity). So whatever you do to bridge interface, you do to connection between router software and L2 network, you don’t affect the rest of interfaces members of bridge (switch-like entity).
I know it sounds complicated, but that’s because bridge has two pesonalities. When you create bridge (switch-like entity), you implicitly create an interface with the same name.
Ok - thanks mkx - I think I follow what you are trying to say.
Unfortunately, I ran some more tests, and the results are not consistent with that.
I have 2 devices I tested on:
hEX lite (RouterBOARD 750r2)
MIPSBE
RouterOS v6.46.4
RB1100AHx2
POWERPC
RouterOS v6.46.4
Both are configured with a LAN bridge, with interfaces in those bridges.
On the hEX lite:
My LAN bridge contains ether2, ether3, ether4, and ether5
Interfaces Monitored by Traffic Flow: ether2, ether3, ether4 and ether5
Results: No Netflow traffic seen by collector
Interfaces Monitored by Traffic Flow: bridge interface
Results: Netflow traffic IS seen by collector
On the RB1100AHx2:
My LAN bridge contains ether6, ether7, ether8, ether9, and ether10
Interfaces Monitored by Traffic Flow: ether6, ether7, ether8, and ether9 (NOT the bridge, and NOT ether10)
Results: No Netflow traffic seen by collector
Interfaces Monitored by Traffic Flow: bridge interface
Results: No Netflow traffic seen by collector
Interfaces Monitored by Traffic Flow: ether10
Results: Netflow traffic IS seen by collector
The stupid thing is this: ether10 on the RB1100AHx2 has absolutely nothing plugged into it. My test computer is plugged into one of the other ports in the bridge.
Both test Mikrotiks are running the same RouterOS version, so now, I don’t know if I should be configuring Traffic Flow to monitor the bridge, or individual interfaces, or both.
The only additional info that MAY be relevant is this: until about 24 hours ago, the RB1100AHx2 was running an older RouterOS version. It had no bridge - it had ether10 as the master port, and ether6, ether7, ether8 and ether9 as its slaves. Since the new RouterOS versions no longer have master/slave interfaces, the update process automatically created a bridge to replace the master port, automatically added ether6 - ether10 to the new bridge, and moved all references to ether10 (the old master port) to the new bridge (IP addresses, DHCP servers, etc).
Now, in theory, ether10 should just be another port in the bridge, no different than any other port in that bridge, but tests show that the only way to see Netflow data about the devices on that LAN is to monitor the old master port. Is this a bug?
I didn’t say you have to update every time there’s one available - I said that every time you perform an update, which idlemind suggested we do on every device under our control, you risk thousands of dollars of damage (per device) if something goes wrong. I promise you I am not exaggerating when I say that I can literally write a book about all the things we’ve come across that are broken on Mikrotiks (no matter how up-to-date the RouterOS is) - we’d have to be insane to trust that we can update every device on our network remotely with no issues of any kind on any of them.
Again, all of this is completely off-topic. I don’t appreciate people derailing my thread.