3 ms·

So you can still connect to a device if it doesn’t have an IP? That’s pretty cool. Then out of curiosity, do I understand correctly that these types of packets

So you can still connect to a device if it doesn’t have an IP? That’s pretty cool. Then out of curiosity, do I understand correctly that these types of packets are bridged, not routed, and as such doesn’t work if you’re not in the same subnet?

w7 5y ago
Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices. [0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.
- swinglock 5y ago
  The accurate term is "broadcast domain" or "Ethernet segment".
  - w7 5y ago
    Haha, whoops I mashed the two together. Similar to one of those moments when one speaks and swaps the first letters of two words.
mdb31 5y ago
Yes, Mikrotik MAC-telnet works regardless of the IP configuration: it's technically broadcast UDPv4 to port 20561, but the address information in the protocol data is the only thing that's required for it to work. So the IP addresses can be something invalid like 0.0.0.0, in which case you both need to be on the same L2 segment (bridged). But, it's also entirely possible to use valid IP source/destination addresses (which don't need to be exactly your addresses, just a combination that works in both directions across any routers involved, so Ethernet packets end up on the right segment -- this requires some NAT tricks, but in the end it does work...) for the same protocol to work in a L3 environment. Also, on an all-Mikrotik network, there's https://help.mikrotik.com/docs/display/ROS/RoMON https://help.mikrotik.com/docs/display/ROS/RoMON, which, once you set it up, allows for even more interesting traffic flows. My use case for MAC-telnet is "remote hands" provisioning of new/replacement routers and switches. The only thing the local IT resource needs to be able to do, is connect the equipment to a correct uplink port, after which things will usually work (if not, a factory defaults reset may be required). At the moment, some minor manual configuration work using another Mikrotik box is still required to enable IPv6 and configure the correct VLAN, after which my scripts take over. If MAC-telnet authentication can now be automated as well (and testing that is next on my to-do list...), provisioning could be fully automated in most cases.

w7 5y ago

Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices. [0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.

swinglock 5y ago
The accurate term is "broadcast domain" or "Ethernet segment".
- w7 5y ago
  Haha, whoops I mashed the two together. Similar to one of those moments when one speaks and swaps the first letters of two words.

mdb31 5y ago

Yes, Mikrotik MAC-telnet works regardless of the IP configuration: it's technically broadcast UDPv4 to port 20561, but the address information in the protocol data is the only thing that's required for it to work. So the IP addresses can be something invalid like 0.0.0.0, in which case you both need to be on the same L2 segment (bridged). But, it's also entirely possible to use valid IP source/destination addresses (which don't need to be exactly your addresses, just a combination that works in both directions across any routers involved, so Ethernet packets end up on the right segment -- this requires some NAT tricks, but in the end it does work...) for the same protocol to work in a L3 environment. Also, on an all-Mikrotik network, there's https://help.mikrotik.com/docs/display/ROS/RoMON https://help.mikrotik.com/docs/display/ROS/RoMON, which, once you set it up, allows for even more interesting traffic flows. My use case for MAC-telnet is "remote hands" provisioning of new/replacement routers and switches. The only thing the local IT resource needs to be able to do, is connect the equipment to a correct uplink port, after which things will usually work (if not, a factory defaults reset may be required). At the moment, some minor manual configuration work using another Mikrotik box is still required to enable IPv6 and configure the correct VLAN, after which my scripts take over. If MAC-telnet authentication can now be automated as well (and testing that is next on my to-do list...), provisioning could be fully automated in most cases.