After updating a device to version 7.19.1, romon no longer works, from a device running 7.18.2 (or lower) I can no longer find (via romon) the device that was updated to 7.19.1, downgrading to 7.18.2 everything works normally again, has anyone else noticed this?
Tested in 3 different switches (2 CRS317 and 1 CRS310), after the upgrade, the device is no longer accessible via romon, via IP, mac, etc, all works, only romon breaks.
I can connect fine both to AND from 7.19.1 devices. As well as from 7.20beta2 to various V6/V7 things. But I just have arm/arm64/mipsbe/CHR things, but no CRS’s…
But I’d note they have made various HW offload changes between 7.18 and 7.19… And RoMON is kinda weird (different ether-type) … so possible it might be platform specific problem. If you had another non-CRS to try, that might narrow down the issue.
You can have multiple secrets, which allows remotes to use different secrets. You can even if one empty secret (like default) with other actual secrets.
I lab this up and it’s very cool indeed I never know this feature exist , you can fine tune what you want to see a romon neighbors because a device can have multiple secrets, one use case you can limit the access of your remote network engineer, I just hope/wish that the romon secret key can be bind with the user not on the router itself to make it more flexible
@Amm0 thanks for your great insight I learned a lot from you today
Now that you brought this up, I think it could actually be something with hardware offload, I tested it on a VM and romon worked on this version, I only noticed this problem on switches, and in all cases (obviously) hardware offload is enabled.
I’m going to open a case with Mikrotik to see what they say.
It’s worked like for me. But it’s not documented. The use case I found out while ago was if you normally set a secret, but forget to set a secret on some device with enable RoMON, leaving one blank let you connect to BOTH one with a secret and without. Also having multiple secrets lets you “rotate” secrets without losing RoMON in process.
RoMON packets can be forwarded through network switches or bridges, unless there are specific restrictions on multicast traffic. When using a MikroTik bridge with hardware offloading, these packets are treated like regular multicast packets and are flooded across the network. Since RouterOS v7.17> , if the RoMON service is enabled and the switch chip supports ACL rules, dynamic rules are automatically created to redirect these packets to the CPU, where the RoMON service operates. However, if the switch does not support ACL rules and configuration does not align, such as when CPU and RoMON untagged packets are not in the same VLAN, the RoMON service might not function as expected.
… but what curious is you “survived” 7.18, but it’s 7.17 where you SHOULD have run into this note in docs if it was applicable - but not in 7.19…
Can you try the 7.20beta2 version? There was a fix related to dynamic ACL rules not working properly:
*) switch - fixed ACL rules when ports are not specified (fixes dynamic rules for RoMON);
I file a feature request in MT that romon secret can be bind also to the user so that you can configure what’s available only to a user, I hope MT will grant this