bridge port received packet with own address as source address (d4:ca:6d:2d:e3:cb), probably loop

RouterOS General
1

I get this message now and again - and especially in these times where the entire family is working/studying from home :slight_smile:

ether3-slave-local: bridge port received packet with own address as source address (d4:ca:6d:2d:e3:cb), probably loop

When this happens, all network activity stops - and all computers loose the internet access… I have tried to set an administered mac address - and then that mac address shows up, so I’m pretty sure there isn’t another device with the same mac address.

I only have one router. It is running RouterOS v6.46.6

The issue happens too often (like 1-2 times per day) - and it is very annoying when people are participating in video sessions :frowning:

What is the best way to troubleshoot this?

2

You have only one router, but you haven’t stated how many switches you have, you haven’t posted the configuration export, and you haven’t stated whether some of your home devices aren’t connected using wireless and wired connection at the same time. The issue is a switching/bridging (L2) related one, not a routing-related one.

3

Exactly. I didn’t want to over-inform which is why I asked what the best way to troubleshoot this is. The information about “one router” is because I have seen others have this issue and most of them had more than one WebFig box.

So I have this one RouterBoard 951-2n that runs RouterOS 6.46.6

On port one I have connected the router from the Internet provider that also has a wifi. It runs as a guest wifi so no contact to the RB box. On the inside (port three) there is a std. 8 port TP-Link switch.

Interfaces:

[jda@Router] > interface print 
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE       ACTUAL-MTU L2MTU  MAX-L2MTU MAC-ADDRESS      
 0  R  ether1-gateway                      ether            1500  1600       4076 00:17:9A:20:4E:4F
 1   S ether2-master-local                 ether            1500  1598       2028 D4:CA:6D:2D:E3:CB
 2  RS ether3-slave-local                  ether            1500  1598       2028 D4:CA:6D:2D:E3:CC
 3   S ether4-slave-local                  ether            1500  1598       2028 D4:CA:6D:2D:E3:CD
 4   S ether5-slave-local                  ether            1500  1598       2028 D4:CA:6D:2D:E3:CE
 5  XS wlan1                               wlan             1500  1600       2290 D4:CA:6D:2D:E3:CF
 6  R  bridge-local                        bridge           1500  1598            D4:CA:6D:2D:E3:CB
[jda@Router] >

/john

4

Okay, so ether1 (which is connected to the other router with a wireless AP embedded) is not a member port of the bridge, hence not very likely that a frame from Mikrotik’s bridge could get to the ISP’s router and come back via its WiFi and some device in your network which would be bridging between wireless and wired interface. It’s not absolutely impossible but you need several unusual things to happen simultaneously.

So a question - can you survive for some time without the TP-link, i.e. with only 4 ports to connect wired devices, and if not, can you at least move some cables from the TP-link to ether2, ether4, ether5 of the Mikrotik? Currently, wherever the issue actually happens, you can see it at ether3; so regardless whether the TP-link itself or some connected device are guilty, you cannot distinguish the real source.

If you migrate first three cables to Mikrotik, and the next event again reports ether3 as the in-interface of the looped frame, the next step is to return those three cables back to TP-link and move other three cables from TP-link to Mikrotik, and so on.

5

I cannot survive without it - but I can do the “3 at a time” test. That makes really good sense. And if I understand you correctly then one of them should be the link from the Wifi (also TP-Link)…

6

Ok, I have now moved:

Wireless connection
Sonos
Printer

I’ll get back on next failure :slight_smile:

Thanks for your input!

/John

7

Now I don’t understand you. The ether1 connection to ISP’s router must stay as it is, and the connection between ether3 and the TPlink also stays in place. You only move the other cables from the TPlink to the free ethers of Mikrotik.

I don’t insist that the frame takes a long path via WiFi. It can be sent back due to a bug in one of the connected devices (inclulding the TP-link itself) or due to some cable loop via multiple devices.

8

I did just move three cables from the switch to the router. I don’t use the wifi of the router - but has a separate wifi which I connected directly (via cable) to the router :slight_smile:

I had the error again and this time it was on one of the other ports:

ether5-slave-local: bridge port received packet with own address as source address (d4:ca:6d:2d:e3:cb), probably loop

It is a SONOS bridge that is connected to port 5. Not sure what to do about this - it is not a piece of equipment that I have done a lot to set up (if I remember correctly). They manage most of it themselves…

/John

9

That’s not nice. The reason why loops are so dangerous is that the L2 frame header contains no TTL field, so a frame which arrives back to the sender through the loop will be re-sent the same way, so it will be circulating in the network forever, gradually taking over its whole bandwidth.

As the SONOS network is a blackbox, I’d suggest to keep the SONOS bridge connected directly to ether5, remove ether5 from the bridge, attach a separate L3 subnet with its own DHCP server to it, and set loop-protection at ether5 to off. I don’t know much about SONOS, so the question is whether the management application running on a device in a different subnet than the SONOS boxes will be able to talk to them, and whether the SONOS devices will easily access your NAS in a different subnet if you use one. But regardless all that, it’s the second best option after fixing the SONOS mesh network to stop returning frames to the sender, which may be impossible.

It may be a random glitch which only happens rarely, i.e. if the frame comes back and gets re-sent to the SONOS bridge, it won’t come back again, so you can try to just eep the SONOS bridge connected directly to ether5 and set loop-protection at ether5 to off, but get ready for a network overload.

10

I wrote to the Sonos community and this was the first response that I got:

Sonos uses STP for loop detection and avoidance. Sometimes wiring multiple Sonos units can cause problems when the network infrastructure devices aren’t fully compliant, or in some way interfere with the flow of STP control frames (BPDUs).

Does that give any ideas as to how the problem could be avoided?

11

If “the problem” is that the bridge stops forwarding, then yes, it gives an idea how to avoid it from happening.
If “the problem” is that the frame sent by Mikrotik comes back, then it doesn’t give an idea how to avoid it, but it does give an idea why it happens, and that such frames can be ignored because the Mikrotik’s bridge is not a part of the loop path, so the last suggestion I gave is actually reasonably safe.

The thing is that STP doesn’t react to topology changes immediately. So if a path through the wireless mesh is not transparent for a while for physical reasons, and then becomes transparent again, few frames may get through two paths at the same time before the STP detects that more than one path between two nodes is open and shuts all but one of them.

When a frame for a broadcast or unknown destination arrives to a switch, it is sent out through all ports except the one through which it came in. So when it comes in via two ports for the reason above, it gets sent twice to every other port, and once to each of the two through which it came in. So that’s how it makes it back to the source port - via at least one other switch.

So I assume that what happens is that a broadcast frame (such as an ARP request) is sent from Mikrotik’s ether5, and gets treated the above way, so it returns to the Mikrotik; if the loop protection was disabled, Mikrotik would forward it to other bridge ports and nothing else would happen, as there is no way how it could get back to the SONOS network but via ether5 again, and that won’t happen.

STP interworking is not necessary for as long as there is only a single path between the Mikrotik and the TP-link at one side and the SONOS mesh at the other one (i.e. no actual physical loop); if you had several interconnection links between the Mikrotik and the Sonos (it doesn’t matter whether wired or optical or wireless), STP would have to interwork properly (and loop protecttion would have to be disabled too).

So all in all, if there is just one path between the SONOS mesh and the Mikrotik bridge, via ether5, just set loop-protection at ether5 to off and you should be good. If SONOS is eventually connected to the WiFi AP to which the Mikrotik is connected via ether1, it doesn’t matter because frames are not bridged between ether1 and ether5 on the Mikrotik.

12

Thanks!

I have disabled loop protection on port 5. I’ll see what happens… :wink:

/John

13

…and what happened? :slight_smile:
I’m facing the same issue with sonos. We use CAPSMAN and local forwarding became impossible, so we changed to forward to Manager. We set STP (instead RSTP) in manager bridge, as readed in sonos forum. The problem seems mostly mitigated. We don’t see loops problems anymore, but still some unsuccessful dhcp offerings.

It would be great to read from people who already managed theese issues with sonos and how they handled it.

Thanks in advance!