Weird routing loop in logs but there isn't one.

I too had the same issue with my RB3011. It seems to be a software related. I reset my config and removed the bridge between the two switches, which resolved the matter.

I run a simple network:
Ether 1 - PPPoE
Ether 2 - LAN

Upgraded from a RB2011 which never had the loop with the same config.

So that’s 3 of us and counting with the same problem. I have raised this to MT support now via formal email and also referenced this thread. I really do hope somebody gives this some attention.

Progress for tonight;
The bugfix rOS is not available fro the Arm architecture currently so that strikes another line of enquiry off.

Have reconfigured as @sruys has and so far so good, 17 mins of no error message.
I will leave the config as it is now and not touch anything else to see if this fixes it, if it does then MT you have some bug fixing to do!

So far so good (kind of)

We’ve gone the best part of 2 hours without an error message (although the router isn’t working how I want it to) but oddly it has rebooted itself once in this time. I’m going to write that off as a random reboot of no origin and hope it doesn’t happen again.

I just wanted to confirm that no errors are being reported after an uptime of 1 day 17 hours (no random reboots) with my current config without a bridge interface but with a manual patch between the two master ports.

i’ve received a reply from Mikrotik support regarding this matter:

Hello,

We have seen this problem in older versions but cannot reproduce it in the latest
ones. We recommend upgrading to v6.35rc1x. If you notice any problem in v6.35rc
version, let us know, we are still investigating it.

Regards,
Janis B.

To upgrade to the version they specified I had to choose the branch “release candidate”

Channel: release candidate
Installed Version
6.34.1
Latest Version
6.35rc11

I’m upgrading right now and I’ll post the results afterwards.

The upgrade to the latest test version had no effect, stil the same errors. I’ve replied this to Mikrotik support and I’ve send them my config and a screenshot of the error. maybe they’ll find something obvious that I’m missing

Thanks for keeping the community updated with your progress.

I am seeing the same errors in my RB3011 logs.
Is this limited to the RB3011 with ARM?

Hi there I thought I would drop on this as well, as I am experiencing the exact same thing on my new RB3011 running version 6.34.2.

When I switched from RB2011 to RB3011 I did the foolish thing of restoring a binary backup which I took on the RB2011 to the RB3011, which obviously overwrote all the mac addresses on my interfaces. Real messy mistake, but I managed getting my network working again. After a while the same messages as you guys above describe started appearing, which made me wonder what had changed between the previous working setup on my RB2011 and to the setup which is present now. So first reflex was to do a configuration reset and start reapplying my previous configuration using an old backup.rsc file, line by line only the really important lines. At first I didn’t see any weird log messages but soon they started appearing again.

One thing I’ve noticed is that when you observe the Interfaces in question the TX/RX Bytes on these interfaces start increasing quite rapidly once the first message in the logs appears.

I really don’t understand what might be the real problem here.

It seems to be a bug in the current firmware. You can read the previous comments for a workaround but I would suggest you mail you report this with Mikrotik support so they have more examples to work with.

I’ve just seen that bugfix 6.32.4 has been released for the ARM version. I’m wondering if it is worth rolling back to that as the problem only seemed to start at 6.34.

I’m not at my desk currently but will try it tonight I think and report back.

Small update;
The bugfix firmware still won’t download and work on my RB3011. I get an error;
missing routeros-arm-6.32.4.npk

I haven’t updated yet to 6.34.2

Update:

Hello,

We have reproduced this problem and are working on to fix it in upcoming RouterOS
version.

Regards,
Janis B.


Come to the MUM - Europe 2016 (Slovenia), Malaysia, Bangladesh,
Russia (Irkutsk, Vladivostok), China, Philippines, Mexico, United
States, Indonesia, Middle East (Dubai)!

02/18/2016 22:39 - sruyswrote:

Dear Janis

Thank you for your speedy reply.

I’ve upgraded to the 6.35rc11 version from the release candidate channel.
I’ve replaced the physical patching between de two master ports by a bridge
interfcae containing the two master ports and withing 15 seconds the errors
started again. I’ve added a screenshot of the logs in attachment.

I’ve also added an export of my working config with physical patched master
ports and a config resulting in the errors.

I’ve you need any more specific info do not hesitate to ask.

Kr

sruys



TLDR: next update will contain fix

Excellent! At least you have got a reply, I submitted supout files and have had silence since.

Excellent, perfect now we can be certain that it is a real bug and not a configuration/setup problem. :confused:

I’ve finally had a message back from MikroTik support. They confirmed that bugfix is not compatible with ARM. Nothing about the problem itself.

Just had a response from MikroTik support;

Hello,

We just made a fix specially for RB3011 today. We released 6.35rc15 version.

It fixes multiple problems which are caused by load on router. Is it possible that
you could test it now?

Regards,
XXXXX XXXX

I have just updated my RB3011 just now. Interestingly the release notes state that when the CPU is under high load it generates ether errors but my CPU load barely ever goes above 5% (love that ARM CPU)

I’ll also perform the update tommorow and post the results. @Steve: did the router report the collision errors when you applied the bridge configuration? With my config the errors start as soon as 15 seconds after boot

First indications aren’t looking good. I’ve had a collision error already on 2 ports that aren’t in the software bridge. I’ve disabled 1 of them just in case that is a separate problem.