brand new hEX (port 5) <-----> L2 switch <--------> rb5009
Winbox into rb5009. Open terminal. There I type,
/tool/mac-telnet <tab>
system will list down all the mac addresses it knows, and there is my new hEX.
No problem so far.
So, I select the mac of the hEX unit, XX:XX:XX:XX:XX:3E, then press enter.
system will prompt for login and password.
Here, doesn’t matter what I type, it will always set you back to the original prompt. Meaning, no go.
I’ve been scratching my head for hours on this and finally got it working.
You see, XX:XX:XX:XX:XX:3E is the mac address of the PORT 5.
Which makes, XX:XX:XX:XX:XX:3B the mac address of the PORT 2.
By default, admin mac address of the bridge interface, so-called LAN, takes the mac address of the PORT 2.
I then replace XX:XX:XX:XX:XX:3E to XX:XX:XX:XX:XX:3B. Boom. You are in.
If this is by design, ing after /too/mac-telnet shouldn’t have listed XX:XX:XX:XX:XX:3E but rather XX:XX:XX:XX:XX:3B.
Anyway, I hope somebody may benefit from my little finding because I sure couldn’t find anywhere on the net talking about this problem.
I guess it is a consequence of the settings for the bridge auto-mac and admin-mac, there is in theory an even worse case, where the mac of the bridge may change after a reboot.
To combine a number of networks into one bridge, a bridge interface should be created (later, all the desired interfaces should be set up as its ports). One MAC address from slave (secondary) ports will be assigned to the bridge interface, the MAC address will be chosen automatically, depending on “port-number”, and it can change after a reboot. To avoid unwanted MAC address changes, it is recommended to disable “auto-mac”, and to manually specify MAC by using “admin-mac”.
Mikrotik (and members of the board) advise is that of assigning manually a mac address to the bridge, but it has to be seen if - even if doing that - it would be listed on another device with /tool/mac-telnet or you would see only the macs of the single ports (in which case, if you do not have trace of the mac manually assigned to the bridge, you would be “locked out” of the telnet connection for good).
Just checked … I have manually set MAC addresses on all bridges … and /tool/mac-telnet [TAB][TAB] displays only those MAC addresses … none of individual port MAC addresses appear on the list.
Good , so the advice is actually good and solves also this possible issue.
It is possible that the auto-mac is somehow a sort of dynamic setting while the manually assigned one is a static one with more relevance.
It is out of box config but the way I see it, it’s already following the recommendation from wiki.
I tried changing admin-mac to XX:XX:XX:XX:YY:3B. Still, /tool/mac-telnet will list XX:XX:XX:XX:XX:3E.
From there,
/tool/mac-telnet XX:XX:XX:XX:XX:3E and
/tool/mac-telnet XX:XX:XX:XX:XX:3B
fail.
Now only,
/tool/mac-telnet XX:XX:XX:XX:YY:3B <---- notice new MAC
works.
Just checked … I have manually set MAC addresses on all bridges … and /tool/mac-telnet [TAB][TAB] displays only those MAC addresses … none of individual port MAC addresses appear on the list.
Well, by default there is only one bridge. Called, bridge. so I don’t know what you mean by “manually set MAC addresses on all bridges” and my experiment with hEX on v7.13.2 with default config, shows different result.
What’s interesting about this is that MAC-WINBOX works. Just not MAC-TELNET.
Come to think of it, if MAC-WINBOX works, and MAC-TELNET doesn’t, it shouldn’t be too hard to have this working for MAC-TELNET also, wouldn’t you say?
You are perfectly right, it should work and it should be reproducible.
I don’t know, maybe a reboot or disabling/re-enabling the bridge after a modification is needed, or maybe just disconnect that Hex from the RB5009 and reconnect it.
But in your case, the newly assigned YY:3B MAC to the bridge is NOT listed at all?
Or is it listed besides the “single” XX:3B, XX:3E?
It could be a case of something remaining “sticky” on either the Hex or the RB5009 (or both).
I have a few Mikrotik devices on the LAN, each have one bridge and I manually set MAC addresses on each and every bridge. Hence use of plural “bridges”. And all of them are shown with their manually set MAC addresses, none “leak” port MAC addresses.
There might be a gotcha: make sure that manually set MAC address isn’t the same as any of port MAC addresses. You can (pretty safely) go with locally administered addresses (I usually take a port MAC and flip the U/L bit).
It could be a case of something remaining “sticky” on either the Hex or the RB5009 (or both).
Yeah, I also suspected something like that so I made sure I rebooted both devices and restarted winbox. I didn’t try disable/enable bridge as that would lock me out. But reboot of the device should cover that.
But in your case, the newly assigned YY:3B MAC to the bridge is NOT listed at all?
Yeah. NOT at all.
Or is it listed besides the “single” XX:3B, XX:3E?
Just XX:3E.
Hence use of plural “bridges”
Okay.
There might be a gotcha: make sure that manually set MAC address isn’t the same as any of port MAC addresses
I also though the point of configuring MAC manually meant you’d be better off using something totally different to what interfaces has already.
Tho XX:XX:XX:XX:YY:3B isn’t something you’d call totally different but as far as processing goes, it’s different enough.
For the sake of argument, I tried, AA:BB:CC:DD:EE:FF (meaning totally different). Same result.
No matter what I change admin-mac to, /tool/mac-telnet will only show the MAC of the hEX interface rb5009 is connected to.
mkx, the units you’ve used for testing, are they v7 ? If any of these are hEX, do you mind posting the config?
If none of them are hEX, can you post the relevant section of the config?
Ideally,
Another thing you may want to check: MAC access is managed under /tool/mac-server and it’s possible to set allowed-interface-list for telnet and winbox separately. In my case the list of allowed interfaces includes one or two VLAN interfaces (yes, I’m using VLANs, they are not seen in export above because on this particular device VLANs are configured on switch chip), but all involved VLAN interfaces are anchored to same bridge interface, hence they share MAC address.
What I don’t know is if these settings also affect how devices are detectable.
Another thing: /ip/neighbor/discovery-settings … not sure how this relates to “detect-ability” either. It can refer to another interface list.
Fun fact: on one of peripherial devices I have multiple VLANs set as allowed for discovery … and a neighbour is detected via two VLANs … properly shows the correct MAC address for both instances, interface name and IP address are different (but correspond):
Another thing you may want to check: MAC access is managed under /tool/mac-server and it’s possible to set allowed-interface-list for telnet and winbox separately
Both set to “all”
VLAN.. Hmm. This is something I can’t try. At least not right now.
Another thing: /ip/neighbor/discovery-settings
That is also set to “all” By default this was set to “LAN”. I also tested when it was set to “LAN”. Not worked.
Looks like VLAN has something to do with this but can’t confirm.
Thank you all for your support, but I’ve got no choice but to go with guessing MAC address.
It’s not like unit has thousand interfaces, I can either increment or decrement one by one.
, so the advice is actually good and solves also this possible issue.