I'm trying to determine if anyone else has observed this on the CCR2004 and if should file a bug report or if I need to try to capture more data to determine what is going on with the device.

I have a CCR2004-16G-2S+ as an edge router/NAT-firewall for a /24 of private addresses. In addition to the src-NAT, I have a small number of simple dst-NAT rules and pretty typical input and forward chain rules for a device performing the work this box is doing. I do have uPNP enabled for xbox, although it's probably not a factor. CPU utilization is always very low on the device. I have fast track disabled because I am not sure if it can be trusted on this device yet.

The router is also acting as a switch on some of it's gigabit ports, since i only have 10gig ports in this rack otherwise. These gigabit ports are in a bridge and the port that goes to my ISP is a tagged VLAN interface with a pppoe connection - the port that goes to the ISP is not in the bridge with the devices in question. The 10gig SFP+ interface of the CCR2004 is connected via DAC to a CRS312 (the root bridge in an STP environment - i'm running plain STP for the sonos stuff), which feeds my 10gig switching infrastructure but that interface does not flap.

I don't see anything in the logs around that time other than what is in the attached image. But what I believe happens is the pppoe connection goes down first, then the WAN's physical interface goes down (16 in the attached image). Then the 100mb interfaces on the same device will flap. I think that the interfaces being 100mbit is related to them flapping for some reason. The other gigabit interfaces don't flap when this happens (other than the first offender - the WAN), and the 10gig interface going into my root bridge/10gig core doesn't flap.

I have read other posts where something similar was occurring, so I am wondering if this is possibly a bug. Or do I need to explicitly enable more (perhaps STP) logging to better diagnose? What do you think?

For reference, here's another thread with a few folks (and links to other related threads) mentioning port flapping on the first CCR2004 and the new ARM RB5009:

viewtopic.php?t=176626

^ some of these folks seemed to conclude the issue was having winbox connected and looking at a dhcp pane, but I'm not doing dhcp on mikrotiks. I have linux servers for DHCP and DNS.

A 100mbit interface on the CCR2004 flapped again. This time it was when I rebooted a synology that's hanging off of the device with 2 gigabit interfaces. This synology device is not generating spanning tree events like the sonos products do, so I don't think this is spanning tree. I tend to think it's a bug. But I'm certainly open to being proven wrong.

It seems to me that when an interface on the device's gigabit ports changes link state, the interfaces that are 100mbit (in my case) can flap. They are set to auto negotiate right now, so I'm going to hard-code them at 100mbit as a test.

Any constructive input is welcomed, but please don't waste our time with trolling.

For the curious or bored, hard-coding the interfaces to 100Mbps has no impact on the flapping. If other people are not seeing this as well, then I guess it's not a bug. At this time I have 2 theories:

1) I think that the interface flaps may be related to the way the sonos devices use the archaic STP standard, and Mikrotik does not appear (at least to me at this time) to have a way to really dig into spanning tree events via the RouterOS interface. I hope someone can prove me wrong.

Setting the bridge from which the sonos devices connect to a priority of 4096 seems to yield the best results, and this is what is suggested in the sonos docs. So I reworked my STP priorities according to the docs.

2) I think it's also possible that not having igmp snooping enabled could be related to what I've been seeing with the interfaces flapping. I've enabled igmp snooping, as this is also suggested in the sonos docs.

I haven't had an interface flap since 6PM last night, but it's too early to say if I have resolve the issue because at times I have periods of relative stability from this setup. And then it can descend into a maddening string of flapping interfaces, weird dhcp requests, and needing to restart dnsmasq to "help" this sonos device get an IP again, just to have the interface go down again.

What's really odd is that I have a sonos Beam2 and 2 identical surrounds in another room but on the same L2/IP network, and I never ever have a problem with that device. I could set the STP priority on that switch to anything I wanted, and it would still never have an issue. This setup is in an adjacent room. The only theory I can think of for this is that it's almost as if it could be due to some type of interference...very frustrating and kind of odd...