MikroTik

We're having a problem on the LAN at one of our sites in which we're getting an error that says "WLAN1: bridge port received packet with own address as source address . . . probably loop." The router that is logging the error is the first wireless client in the chain of hops, so it's the closest one to our gateway router. WLAN1 is configured as a station bridge, and it connects to a tower that is an AP bridge. A total of four station bridges connect to the tower.

We physically inspected throughout the site for cabling problems that could cause a spanning tree loop, and checked for loops in our wireless connections and found none. We tried blocking all the remote stations with an access list and brought them back up one by one to see if we could determine where the problem was occurring. I brought up one station with no problem. I was able to recreate the problem by then letting two different stations connect to the tower access point individually. We replaced the access point on the tower, and the problem persists. We have over 90 sites with MikroTik wireless backhauls, and we're only having this problem at one site. Any ideas as to what might cause this problem?

All MikroTik devices at this site are running RouterOS 6.38.1. We have one switch running SwitchOS 1.17.

Same problem on CPE with ROS 6.38.5
AP with ROS 6.38.5 als AP bridge, CPE configured as station bridge. bridge1 with wlan1 and ether1

Only this one CPE is connected with the AP, on eth of the CPE a laptop is connected. No switches are playing in this setup.

thanks, Frank

Hello, try disabling Neighbor Discovery on ether1 and wlan1 interfaces and keep enabled only on bridge1.

Hi,
Neighbor Discovery setting before:
bridge1 => enabled
ether1 => enabled
wlan1 => disabled

now set to:
bridge1 => enabled
ether1 => disabled
wlan1 => disabled

Thanks. I will report the result after 24 h monitoring.
best regards, Frank

You could also try to disable default forwarding on the AP.

Then the stations cannot pass data between each other.(in theory)

Are you sure that you did not copy the MAC address from one place to another?
This can happen when you restore a backup of one device on another, or import an export which has MAC addresses in it.
E.g. when you "convenient rollout plan" has been to restore a backup of a single configured client onto every client's AP,
you will have surprises like this.

No, both configurations are done from scratch with default settings first after the problems are coming with the news ROS.

Editing of the Neighbor Discovery setting have not solve the problem.

But setting on both units (AP and CPE) the MAC address of the unit's wireless interface as Admin MAC address of the bridge, this brings a stable connection (current link uptime > 1 hour and a very low PING time)
The bridge error message for having a loop is also gone away. At the moment, everything is working fine.

This points in the direction I mentioned. Check all MAC addresses in the system to see if they are unique.
(wlan1, ether1, bridge on all connected devices)

I've also started having this issue over the weekend.

I've checked and rechecked MAC addresses but there don't seem to be any duplicates and I've disabled anything not used.

If I shut off the router (and switch it's plugged into) for a minute or two the issue clears, but then comes back after X amount of time (sometimes it's an hour, sometimes it's six).

Mostly just throwing in my 2 cents as this seems to be a new issue that a few people are experiencing around the same time.

- Toucan

Hi
I'm having the same problem and it occurs at random times only once or twice and then nothing for hours. I downgraded to ros5.25 and it stopped. I would suspect a clash between the way ubiquity handles bridged connections and Mikrotik's way

I had the same problem at a device with capsman. I solved it by removing bridge from all cap devices. Now discovery interface is ether1 and not bridge1.

I have this problem since before I bought mikrotik.
There's a chance that this error is trigger whenever I open a specific computer. Sometimes it works Fine and sometimes Give me this error.
I have many computers connected in hub which conneted to router(mikrotik) and then to modem. I have motherboard of gigabite Jetway and Asrock.
Only This Asrock Give me error. As I checked its lanport Only Thing Than get my attention is the light that it immit. As I believe normal color should be lightgreen and orange blinking but, this one immit orrange and red. I checked other pc And I found out theres 2 of my computer that immit such different light. after That nothing in the internet could explain me better. All I got is that Other light than lightgreen and orange has low transfer rate of data bites. though Internet speed is normally working fine as It should be.
Can someone gues whats might occuring this instances?

I'm hoping I'm not too late to help out.

I was having this issue too. Here's a quick overview of my setup.

I have vlan interfaces, using a bridge called BR-TRUNK for the "interface" field.
Then I assign those interfaces as bride ports.


My RB1200 is my CapsMAN with VLANs being sent through a trunk port (ether08) to my hAP ac. I use wlan2 (5GHz) of the hAP ac as the trunk port to 3 other hAP ac lites. This is when I started getting those pesky messages. Having read a reply from becs (+1), I disabled MNDP from all VLAN bridges (except BR-TRUNK) and VLAN interfaces.

This seems to have solved my issue.

Best regards,

plz check ur network to see if u have the same mac or not

solution for same mac

reset factory one of router

does disabling the STP/RSTP help in this case??

also there is a "LOOP PROTECT" which i think can play a important part in this. just don't know how?

I had the same problem on CAPsMAN... Left in bridge only ether1 (I had wlan1 in bridge, too) and it solved it. Maybe this could help someone.

I had the same problem on CAPsMAN... Left in bridge only ether1 (I had wlan1 in bridge, too) and it solved it. Maybe this could help someone.

could you please explain this in detail...

Hello. I just solved this problem by removing the bridge (of course I lost the connection with the router). Then I created a new bridge. And after that, it was still necessary to Disable and Enable the problem port, which one I saw in the error messages. For 30 minutes there is no error. Prior to this, there were errors in the log every 7-10 seconds.

I am sorry. After the router restarted, the warning appeared again. The solution is not working.

I have a CCR in a datacenter where the internet connection is provided by a pair of (juniper) routers in VRRP configuration and I very seldomly see the message on that port, but I think it happens when the active router changes.
It is only one such message and then it may not be seen for a month.
I just disregard those.
Of course when it happened every minute, I would research the matter more deeply....

I had the same problem on CAPsMAN... Left in bridge only ether1 (I had wlan1 in bridge, too) and it solved it. Maybe this could help someone.

My setup: Capsman running on an rb2011 connected to a cAP AC
RB2011
eth5->cAP AC
eth5->Vlan
Vlan->Bridge_Vlan

cAP AC
eth1->RB2011
eth1->Vlan
Vlan->Bridge_Vlan
Did some troubleshooting based on this guys advice and another's recommendation to change Discovery to Ether1. In the end only setting Discovery on the Bridge_Vlan itself and nowhere else solved the potential looping issue for me. I hope this can help someone else out.

In our experience, that problem is caused by damaged ethernets. The ethernet maybe working or not, but the symptom is always the same, it links either it has a cable pluged or not (I mean that the link led is turned on even if the ethernet does not have a cable pluged).

Of course you also have to consider a real loop as a possibility

This many people not a coincidence. Happened to me too.

In my case it was caused by MAC conflicts caused by Virtual WLAN interfaces, that are created sequentially.
So if you have 2-3 routers that have been purchased together, their MAC address are very close, so creating 4-5 Virtual adapters on each will cause them to overlap.
Check them out.

My solution:

- Since we are setting bit1 of the 1st byte of the MAC, for ”Locally administered”, we are free to change it.
- BUT - The last 3 bytes should always be unique – so i NEVER change those,

Instead: Byte 2+3 are free to be changed.
I set bit 1 of the 1st byte like You do:
4C:5E:0C:81:CF:8E becomes 4E:5E:0C:81:CF:8E

THEN, when I add more virtuals, I change bytes 2+3. Since we are using locally administered macs, nothing is stopping us from changing them.
Since i am not changing the last 3 bytes, they are guaranteed to be unique:

Example:
4E:00:01:81:CF:8E
4E:00:02:81:CF:8E
4E:00:03:81:CF:8E
4E:00:04:81:CF:8E



Problem shown below:

Router 1:
[pit@HTP Reception] > int pr
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 1600 4076 4C:5E:0C:81:CF:8E
1 wlan2 wlan 1500 1600 2290 4C:5E:0C:11:10:83
2 S wlan2-100 wlan 1500 1600 2290 4E:5E:0C:11:10:83
3 S wlan2-101 wlan 1500 1600 2290 4E:5E:0C:11:10:84

Router 2:
[pit@BB7 LaererV] > int pr
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 1600 4076 4C:5E:0C:82:8D:00
1 wlan2 wlan 1500 1600 2290 4C:5E:0C:11:10:7F
2 S wlan2-100 wlan 1500 1600 2290 4E:5E:0C:11:10:7F
3 S wlan2-101 wlan 1500 1600 2290 4E:5E:0C:11:10:80
4 S wlan2-102 wlan 1500 1600 2290 4E:5E:0C:11:10:81
5 S wlan2-103 wlan 1500 1600 2290 4E:5E:0C:11:10:82
6 S wlan2-104 wlan 1500 1600 2290 4E:5E:0C:11:10:83
7 S wlan2-105 wlan 1500 1600 2290 4E:5E:0C:11:10:84
8 wlan5 wlan 1500 1600 2290 4C:5E:0C:82:8D:01

Well, receiving a packet with same mac address is definitely a loop. The issue here is how to analyze the loop apart from the obvious checking mac addresses of the interfaces.
In my opinion this is related whenever you have bridge interfaces created, be it STP, RSTP or none. The learning of the mac-addresses from the bridge might be causing the issue.
But we need a better tool to understand and analyze properly the issue.
Is there someone in the network spoofing mac addresses?
Does Neighbor Discovery receive invalid packets?
Does Detect Internet causes issues?
Is the bridge interface itself generating invalid packets?

Probably is admin Mac address that causes the loop.
Try to set one instead of auto mac, for example I set ether1 Mac as admin Mac on AP and wlan1 on station

I decided to update my hAP ac Lite to 6.43.7 today.
It is running for more than 12 hours now and I haven't noticed any message in the log about this issue. I don't have a remote syslog to save all logs, but it looks like the issue is solved. Also, looking at versions change log Mikrotik has made some substantial changes to the bridge.
Anyway, will keep you posted if the issue appears again after this update.

Great advice I have changed my virtual wlans so they are more distinctly different from the WLANs.
If have an AP with two WLANS is it okay to change them too, so they are clearly distinct from each other ????
I noticed that my vlans all have the same mac address, but the vlan attached for the ISP does not. Assuming all vlans on a bridge get assigned same mac address?

If have an AP with two WLANS is it okay to change them too, so they are clearly distinct from each other ????

You can change MAC addresses where ever you want. Just keep them distinct. The important thing is to have different MAC addresses for VAPs ... if VAP has same MAC address as AP, it just won't work (although it might seem to be fine from configuration point of view).
.

I noticed that my vlans all have the same mac address, but the vlan attached for the ISP does not. Assuming all vlans on a bridge get assigned same mac address?

VLANs share MAC address of a physical port. In a switch/bridge configuration, switched ports don't need MAC address at all, because MAC address is only needed as base of L3 operation. Hence when multiple ether ports are bridge in RB, all ports will seem to be using bridge's MAC address (whichever that might be). Combined with first sentence in this paragraph ... you have all LAN VLANs using MAC of the bridge. I assume WNA port is not member of the bridge, hence it uses its own MAC address.

I configured WAN to run over VLAN (actually it's untagged, but it's ingressing on a port with PVID set) over ethernet port which is member of unified bridge ... so in my case WAN uses same MAC address as LAN. VLAN tagging keeps L2 separation.

Thanks, I did change my WLAN mac addresses as well and then lost all wifi connectivity on those WLANS, so I only changed the VWLAN ones.

original post was created "Sat Feb 11, 2017". that's almost two years ago today and nobody seems certain about this issue. it's not isolated. any hotshots?

Hello all, I have come across this problem myself, what happens is its the clients end, you normally see a MAC Provided address and what interface or in this case if your using the Wireless its going to say bridge. You will have to track down the client down with their MAC address and get there IP Address. If you have Access Point radios, you can start there and look at the MAC address in the Tools and Networks. Typically they will be listed there with there IP address the AP shows and there MAC. The clients end radio device is whats wrong, what the problem was in most cases the radio device (wireless device) the client had went bad, typically after a bad storm and they got hit by lighting and screwed up the equipment. Other times its because the client would plug the incoming internet port into a LAN port instead of the internet ether port.

Happens fairly often for me, seem to be something to do with Capsman, and only my one AP does it the other AP's seem ok. Rebooting my RB2011 seems to fix it but only for a few hours.

ether10: bridge port received packet with own address as source address (4c:5e:0c:00:00:00), probably loop

I've got the same problem.
STP definitively BLOCKs the Loop in my infrastructure.

The message "bridge port received packet with own address as source address" disappears as soon as I disable neighbor discovery.

So I suspect that either Neighbor discovery is broken, or that STP-Blocked Ports still transport MNDP-Packets.

Is bridge's MAC same as any member ports MAC (including ethernet and wifi ports)? If yes, try to change bridge MAC to some unique number (add 2 to second digit of MAC ... if MAC starts as 4c:5e:0c, change it to 4e:5e:0c).

Already done.
All MACs are unique

Already done.
All MACs are unique

i had changed the bridge admin mac address, but the problem still exist.

routerboard: yes
model: 2011UiAS
serial-number: xxxxxxxx
firmware-type: ar9344
factory-firmware: 3.41
current-firmware: 6.42.1
upgrade-firmware: 6.42.1

holy f**ckamolly. this issue has been around for ALMOST THREE YEARS NOW! whatever happened to all those supposed MikroTIk hotshots out there??? what with all the MTCNA, MTCRE and and sorts of b*llsh*t certs you got but can't find a fix for this loop problem?????

firstly - no certification (does not matter if cisco or mikrotik or anything else) guarantee that person is bright and creative. It just means that (s)he was able to pass the test. Nothing else.
secondly - troubles with suspected loops can't be easily fixed remotely. It would take ages to ask question, wait, think, ask another question etc.. Unless it is obvious and common trouble, easiest and fastest way is to hire skilled person who will run around for few hours with sniffer and by the end of the day, it will be fixed.

Then you read things like

I suspect that...

Excuse me but WHAT?? Someone with issue suspect? tap the network, sniff the data, confirm/reject suspicion. You don't need MTCNA to come up with this. Its common sense.

Its common sense.

Common sense is under-utilized these days. By many people.

Mikrotik has confirmed that this is an issue with neighbor discovery.
But since they assume that this is just a cosmetical issue, a time/date for a fix of this issue will be in the far future.

Mikrotik has confirmed that this is an issue with neighbor discovery.
But since they assume that this is just a cosmetical issue, a time/date for a fix of this issue will be in the far future.

it's mean that probleam can be resolved by disabling neighbor discovery?

Hello

I had this issue a while back but forgot how I solved it.

I have a software vlan setup with 8 VLANs, one of which is a Telco only vlan. If memory serves, I only kept the associated bridge of that vlan as a neighbour enabled interface, along with physical interfaces.

Cheers,


Sent from my cell phone. Sorry for the errors.

Hi All,

I have this problem only on my DiscLite5 (Boardname=RBDisc5nD), when a change to new Disclite5 (Boardname=RBDisc-5nD), the problem solved.
Until now, around 8 units of disclite5 was changed to new Disclite w/ new broadname.
The problem is with the hardware or firmware, I think.

I have tried to make ether 1 Mac as admin Mac on the AP and wlan1 on the station, but no luck.

It seems disabling neighbor discovery solves the false positive alerts (that were generated exactly every 1 min):

It seems disabling neighbor discovery solves the false positive alerts (that were generated exactly every 1 min):

This likely means that you cloned your first device to your second (e.g. by restoring a backup) and thus created a dup MAC address on your network.

I've resolve the issue.
My configuration consist of three routers, one is capsman, two of them are used for caps. On one of the caps the bridge mac was inherit from the wlan1 and the capsman uses the same mac address on his virtual cap interface.
I've change the bridge mac with the ether1's mac.

I got the "...probably loop" error logs and after all I figured out a missconfigured wirless mode. In my case I had a point-to-point connection, one end with mikrotik wireless in mode=bridge and the other end was just in "mode=station", not as expected in "mode=station bridge". Correcting the mode to "station bridge" makes the link work perfectly and no more "... probably loop .." error logs.

It is sign of mac address conflict. reset mac addresses of each interface and set auto-mac=yes for all bridges.

It is mostly caused by restoring backup of a router to another.

as pe1chl said, check all your interface's mac address

specially (i guess) the bridge mac address because it can be the same of one of the ports on the same equipment and it seems it makes it to work worse regarding that.

on the other half, check if you have a slow link or a WDS one, i had the same problem while testing a WDS link with another brand's equipment AND making mikrotik's bandwith tests on firmware 6.43.14. i wont go on further details to not make it more confusing because i have spent a lot of time on this and finally i gave up and restored the original CPE without WDS link. But it was strange to have this loop log regarding the eth interface mac (even after changing the bridge's one and having a bit better results)

cheers

Same problem here and posting some of my experience that may help.
I Have the same issue from time to time. Once the cause was of 2 lhg link connected as point to point with wireless "bridge" mode on ap with wds dynamic enabled and the wds default bridge is the bridge that contain the eth and wlan interfaces and "station wds" wireless mode on the station side. I solved it by removing the wlan interface from the bridge of the ap because I noticed that the wds interface is added to the bridge dynamically and the bridge will contain 3 port (eth,wlan and wds dynamic interface).
But sometimes I can't know the reason. I use omintik with poe a lot and make them as ap bridge and connect it from the main station with a link. It helps me a lot. I usually use mikrotik and ubitquiti to connect my stations together and also for clients. Some stations will have the probably loop error on the log of the omnitik and cause pppoe sessions to disconnect a lot.
The newest problem now is that I have an omintik that was working fine with no probably loop error. A new client wants to connect to the omnitik ap bridge but there was a problem with resetting his sq lite mikrotik (the user led will blink slowly when trying to reset) so I decide to use the sq lite station of his brother who is already a client of my clients. I use vlans as different ISP so the station wds contains a vlan interface hosted on the wlan(which is the trunk in my case) and placed it in a bridge with the ether. I placed a tp-link router and used it as a switch after disabling dhcp and changing its default ip because I wasn't having a dummy switch and connected the 2 routers to the bridge ports of the tp-link router with pppoe connection on wan interfaces of the 2 routers. Everything worked fine after few days I noticed that the omintik started to give the probably loop error and pppoe users are disconnected periodically, and I am sure that there is no duplicate mac address in this station because all my configs are from scratch.
So the cause is placing a switch after the station wds client mode.
I am going to replace this router which I used the 4 ports bridge of it with a netis 8 port 10/100 mbps switch and watch if the error occurs again.

I had the same problem recently, and I was able to resolve the issue.
If you go to IP-Neighbors, and there you should see the same interface repeating for two different MAC.
In this case the router is giving you the correct information that there is a loopback,
In my case the problem was with a switch connected to one of repeated ports that I so on IP - Neighbors on the router that was causing the problem

hope this will help

INFO:
RB951 ROS 7.1.3

I encounter that problem just now
STEPS TAKEN:
-reboot = not fixed
-unplug ethernet cable then plug back = not fixed
-move cable to different port = not fixed

SOLUTIONS:
-disable nic in /interface (in my case ether4) then enable back

After applying all the possible solution form google the success was 0 for me then i just delete the bridge from my mikrotik rb4011 and configure a single port as lan which i connect to a 24 port gigabit switch everything is going smoothly & no more loop no network down

Just SPAM: It doesn't make any sense, you didn't ask for help on the forum and the cause of everything could simply be you who weren't able to configure the device correctly.