Hi, I have a problem with CRS354-48P-4S + 2Q +. The ports work from ether1 to ether8 but no traffic passes through them. Interfaces are lit, active but no traffic What I noticed is that there are no 1 to 8 ports in the switch.
And if I look for port 9 it finds it.
Where could the problem be?

Here is a related problem with CRS354, you can check the solution viewtopic.php?f=3&t=159176&p=787552&hil ... 54#p788593 and let us know if it fixes your problem...

My problem is not that my traffic is low, my problem is that there is no traffic and the ports are behaving as if everything is fine - they are recognized.

I don't think it would harm your device trying the update.
Ports 1-8 is the first Group of ports and since those specific ports do not work maybe you have made any changes in the Switch menu or anything ?

This is my simple configuration, I bought the device yesterday, I'm sure the ports worked yesterday. I don't want to return it to the dealer without being sure the reason is not in me!

I can't take a look at your config right now...
Since it is new, in case you have no important config on it, just reset it to its default settings...
Or make a backup and then reset...
After that, remove all cables from every ethernet port and test them one by one ...

I have run into a similar issue on my device. What i have noticed and am waiting feedback from support for is a simple supported vlan filtering configuration. I assign the first few ports (ether1-6) to vlan=10 and within a few hours or a day, but the vlan is un-reachable randomly. If i reboot the switch it will resume working for some amount of time. The vlan does continue to trunk and work on the sfp+ and qsfp+ ports during the un-reach-ability.

I also have noticed some 100 and gigabit enabled devices flapping port speed and link without cause (ether1-16).

I am waiting for support feedback.

I have run into a similar issue on my device. What i have noticed and am waiting feedback from support for is a simple supported vlan filtering configuration. I assign the first few ports (ether1-6) to vlan=10 and within a few hours or a day, but the vlan is un-reachable randomly. If i reboot the switch it will resume working for some amount of time. The vlan does continue to trunk and work on the sfp+ and qsfp+ ports during the un-reach-ability.

I also have noticed some 100 and gigabit enabled devices flapping port speed and link without cause (ether1-16).

I am waiting for support feedback.

I think we have the same problem, after reboot the traffic is run, but how long will it work ?

My traffic works for 1 minute or sometimes 3-4 days. I have been working on two support cases on the vlan traffic and the flapping port speed/link issue. Separately, i have added a fourth fan to the CPU cooler than 68C more like 48-56C. As a side note, that has not changes the operation, but seems more reasonable for device health. i have used a Noctua 40mm fan with the rubber grommets to secure it to the CPU heat sink.

In case it helps i will post my config in a bit.

# model = CRS354-48G-4S+2Q+
/interface bridge
add admin-mac=C4:AD:34:XX:XX:XX auto-mac=no name=bridge protocol-mode=none vlan-filtering=yes
/interface ethernet
set [ find default-name=ether20 ] auto-negotiation=no speed=100Mbps
set [ find default-name=qsfpplus1-1 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus1-2 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus1-3 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus1-4 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus2-1 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus2-2 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus2-3 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=qsfpplus2-4 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=sfp-sfpplus1 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=sfp-sfpplus2 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=sfp-sfpplus3 ] arp-timeout=30s l2mtu=9128 mtu=9000
set [ find default-name=sfp-sfpplus4 ] arp-timeout=30s l2mtu=9128 mtu=9000
/system logging action
add name=syslog remote=192.168.0.62 remote-port=51402 src-address=192.168.0.3 target=remote
/interface bridge port
add bridge=bridge interface=ether1 pvid=10
add bridge=bridge interface=ether2 pvid=10
add bridge=bridge interface=ether3 pvid=10
add bridge=bridge interface=ether4 pvid=10
add bridge=bridge interface=ether5 pvid=11
add bridge=bridge interface=ether6 pvid=11
add bridge=bridge interface=ether7 pvid=11
add bridge=bridge interface=ether8 pvid=11
add bridge=bridge interface=ether9 pvid=11
add bridge=bridge interface=ether10 pvid=11
add bridge=bridge interface=ether11 pvid=11
add bridge=bridge interface=ether12 pvid=11
add bridge=bridge interface=ether13 pvid=11
add bridge=bridge interface=ether14 pvid=11
add bridge=bridge interface=ether15 pvid=11
add bridge=bridge interface=ether16 pvid=11
add bridge=bridge interface=ether17 pvid=11
add bridge=bridge interface=ether18 pvid=11
add bridge=bridge interface=ether19 pvid=11
add bridge=bridge interface=ether20 pvid=11
add bridge=bridge interface=ether21 pvid=11
add bridge=bridge interface=ether22 pvid=11
add bridge=bridge interface=ether23 pvid=11
add bridge=bridge interface=ether24 pvid=11
add bridge=bridge interface=ether25 pvid=11
add bridge=bridge interface=ether26 pvid=11
add bridge=bridge interface=ether27 pvid=11
add bridge=bridge interface=ether28 pvid=11
add bridge=bridge interface=ether29 pvid=11
add bridge=bridge interface=ether30 pvid=11
add bridge=bridge interface=ether31 pvid=11
add bridge=bridge interface=ether32 pvid=11
add bridge=bridge interface=ether33 pvid=11
add bridge=bridge interface=ether34 pvid=11
add bridge=bridge interface=ether35 pvid=11
add bridge=bridge interface=ether36 pvid=11
add bridge=bridge interface=ether37 pvid=11
add bridge=bridge interface=ether38 pvid=11
add bridge=bridge interface=ether39 pvid=11
add bridge=bridge interface=ether40 pvid=11
add bridge=bridge interface=ether41 pvid=11
add bridge=bridge interface=ether42 pvid=11
add bridge=bridge interface=ether43 pvid=11
add bridge=bridge interface=ether44 pvid=11
add bridge=bridge interface=ether45 pvid=11
add bridge=bridge interface=ether46 pvid=11
add bridge=bridge interface=ether47 pvid=11
add bridge=bridge interface=ether48 pvid=11
add bridge=bridge interface=qsfpplus1-1 pvid=11
add bridge=bridge interface=qsfpplus1-2 pvid=11
add bridge=bridge interface=qsfpplus1-3 pvid=11
add bridge=bridge interface=qsfpplus1-4 pvid=11
add bridge=bridge interface=qsfpplus2-1 pvid=11
add bridge=bridge interface=qsfpplus2-2 pvid=11
add bridge=bridge interface=qsfpplus2-3 pvid=11
add bridge=bridge interface=qsfpplus2-4 pvid=11
add bridge=bridge interface=sfp-sfpplus1 pvid=11
add bridge=bridge interface=sfp-sfpplus2 pvid=11
add bridge=bridge interface=sfp-sfpplus3 pvid=11
add bridge=bridge interface=sfp-sfpplus4 pvid=11
/interface bridge vlan
add bridge=bridge tagged=qsfpplus1-1,qsfpplus2-1 vlan-ids=12-20
add bridge=bridge tagged=qsfpplus1-1,qsfpplus2-1 vlan-ids=65-94
add bridge=bridge tagged=qsfpplus1-1,qsfpplus2-1 vlan-ids=165-194
add bridge=bridge tagged=qsfpplus1-1,qsfpplus2-1 vlan-ids=11
add bridge=bridge tagged=qsfpplus1-1,qsfpplus2-1 vlan-ids=10
add bridge=bridge vlan-ids=1
/ip address
add address=192.168.0.3/24 interface=ether49 network=192.168.0.0
/ip dns
set servers=192.168.0.5,192.168.0.8
/ip route
add distance=1 gateway=192.168.0.1
/ip service
set telnet address=192.168.0.0/24 disabled=yes port=10023
set ftp address=192.168.0.0/24 disabled=yes port=10021
set www address=192.168.0.0/24 port=10080
set ssh address=192.168.0.0/24 port=10022
set www-ssl address=192.168.0.0/24 disabled=no port=10443
set api address=192.168.0.0/24
set winbox address=192.168.0.0/24
set api-ssl address=192.168.0.0/24
/snmp
set enabled=yes trap-version=2
/system clock
set time-zone-name=America/Los_Angeles
/system identity
set name=switch-dist
/system logging
add action=syslog topics=info
add action=syslog topics=debug
add action=syslog topics=dhcp
add action=syslog topics=error
add action=syslog topics=event
add action=syslog topics=health
add action=syslog topics=interface
add action=syslog topics=ntp
add action=syslog topics=route
add action=syslog topics=script
add action=syslog topics=ssh
add action=syslog topics=system
add action=syslog topics=warning
add action=syslog topics=wireless
add action=syslog topics=account
/system ntp client
set enabled=yes primary-ntp=192.168.0.254
/system package update
set channel=testing
/system routerboard settings
set boot-os=router-os
#error exporting /system swos

I have the exact same problem any feedback from support on this ?

Gys

I have the same problem. I've just fallen in love with Mikrotik and the first device I installed at a customer is a CRS354-48P-4S+2Q+.
Configuration is only a simple bridge over all ports with activated vlan filtering and 4 VLANs.
Everything seemed to work fine. Port 1 is our uplink port to the router.
Yesterday randomly the network stopped to work. First we thought the firewall was the problem because we could still ping the servers on SFP+1 - SFP+3.
After some investigation we saw that it was a problem of the ether ports on the Mikrotik. Like OP the ether ports just showed up as normal but absolutely not a single packet was passing through.

I need a solution for this, really quick. It's one important customer for me. I installed this switch because I only heard good things about Mikrotik.
But this experience is very bad for me. Please help!

Edit: We could validate this problem is also for us only on port 1-8. All other ports seem to be intact.

I have the same problem. I've just fallen in love with Mikrotik and the first device I installed at a customer is a CRS354-48P-4S+2Q+.
Configuration is only a simple bridge over all ports with activated vlan filtering and 4 VLANs.
Everything seemed to work fine. Port 1 is our uplink port to the router.
Yesterday randomly the network stopped to work. First we thought the firewall was the problem because we could still ping the servers on SFP+1 - SFP+3.
After some investigation we saw that it was a problem of the ether ports on the Mikrotik. Like OP the ether ports just showed up as normal but absolutely not a single packet was passing through.

I need a solution for this, really quick. It's one important customer for me. I installed this switch because I only heard good things about Mikrotik.
But this experience is very bad for me. Please help!

Edit: We could validate this problem is also for us only on port 1-8. All other ports seem to be intact.

Did you update RouterOS to the final release 6.46.6 ?

Did you update RouterOS to the final release 6.46.6 ?

Yeah when I installed the switch I updated it to the latest stable.
I just updated to 6.47beta60 in hope that this changes something.

Edit: I just saw that I could update firmware separately? System -> RouterBOARD.
Does this also have something to do with system stability? It says current firmware / factory firmware version is 6.46.1

Whats the difference between the firmware and the normal RouterOS?

Edit2: Problem still there with 6.47beta60. Haven't updated the router board firmware yet.

We have the same issue at a customer location. Port 1-8 is just stopping traffic forwarding. Also opened a support ticket, hope mtik will have a solution for this since its in the middle of a larger hardware-renewal at that customer, now stopped because of this issue. :'-(

I told my distributor about this problem with reference to this thread here.
He forwarded this problem to his Mikrotik contact person on Monday.

I ordered another 4 of this model for a complete network redesign at a customer.
I just hope this is a software problem that gets fixed quick...

If this is a hardware problem with the first switch chip, then I will get into big trouble, because my distributor said that inplace exchanges are not possible...
This would mean I have to buy multiple replacement switches, otherwise the complete network at my customer would be offline...

I hope Mikrotik will respond to this problem... this switch is cheap for the capabilities it has, but for broken hardware its too much...

My distributor got a response by Mikrotik:

We are aware of these complaints about Ethernet port group problem on CRS354 switches and actively investigate it.
Although the solution have not been found yet, we plan to provide it soon.

Is this problem present only on the PoE version?

Is this problem present only on the PoE version?

same issue on non-poe version

Has anyone confirmed if cooling the device more helps and/or if the fans are installed the wrong way and/or the CPU heat sink is poorly mounted? just wondering if software vs hardware fix is needed. never opened up the chassis, but maybe part of the controllers for ports 1-8 are close to the CPU and affected by heat?

this switch is cheap for the capabilities it has, but for broken hardware its too much...

If it doesn't work... it doesn't mater what it costs.

Also... they finally admitted there is "just nothing they can do about" busy airtime. So I stopped using their wireless radios.

Routing... Love THEM. ANYTHING ELSE... going to a different vendor.

Just logging in to say I have the same issues. It caused me 11 hours of downtime for 500 customers when I went out of cell range this last weekend... I guess I will go move the switches off of ports 1-8 until they can fix this.

It's pretty annoying because I also had issues with the 24 port 10 Gig switch that was just released. That switch would quit working once you put in the 18th SFP module while in SWOS...

I have the same problem. Is the issue resolved in new versions RouterOS?

Wish I had checked this thread before I bought. Running 6.47. The ports 1-8 thing has been a tranwreck for me. Not having SWOS is also a PITA. Takes something that should be beyond simple and turns it into a mistake prone mess. Not being able to see everything laid out in a GUI is far from ideal. Ports 1 thru eight drop at random times. I thought I had a bad switch, got it replaced and same issue on the replacement. So now I had to buy a dfferent brand switch which I did not want because they did not sell anything else I really wanted and I had to use the credit, never mind the hassle of swappint out 3 switches. I started out saving a few bucks and ended up spening more than the SG3xx series switches which I should have stuck with. Tried to register for support and the website never worked. They are cheap but they do not have support either which can cost you. Not sure what support would have done in any case. Ugh..... As others have noted, great for routers but not so much for switches, at least this model.

6.48beta5 - 4 days - no problem

agreed, although I moved more critical stuff off those ports I havent seen the issue with 6.48B5.

email support@mikrotik if you want to test the file.

Also... they finally admitted there is "just nothing they can do about" busy airtime. So I stopped using their wireless radios.

What do you mean by that? To improve stability in a high noise environment you can enable RTS/CTS. You can always fine-tune the wireless interface by adjusting hw-retries, disconnect-timeout, preamble, etc. Additionally, if your board uses Atheros wireless chip, adaptive-noise-immunity is also an option.

They are cheap but they do not have support either which can cost you. Not sure what support would have done in any case. Ugh..... As others have noted, great for routers but not so much for switches, at least this model.

If for some reason support form is not working, you can always write an e-mail to support@mikrotik.com

@Reinis thank you for your reply, but that's kind of off-topic.

Is there some qualified news on the port problem of the CRS354? Because this really gets a problem for me.

We have added a fix for this problem in 6.48beta5, it hasn't been released to the web yet, if you are experiencing this issue and want to test this version, please contact us at https://help.mikrotik.com/servicedesk/ or via e-mail support@mikrotik.com

update: 6.48beta5 - problem 1-8 port exists

update: 6.48beta5 - problem 1-8 port exists

Oh no.... :/
Then I can't install this beta for my customers. I can't use my productive customers for beta testing.
I get into big trouble with this.

I need a stable fix for this issues asap :/

I was going to build a small dataroom with some CRS326-24S+2Q+RM as backbone and CRS354-48G-4S+2Q+RM as access switches for servers...But taking into account the instability, some incompatibility between mikrotik devices, slow support, very slow issues fix, I am thinking to go with other vendor !

I strongly believe that for critical envoronments like datacenters, where uptime is very important, Mikrotik is NO GOOD !

For home users and amateurs, i think their items are great

Support just wrote me:

We also received feedbacks from customers that the problem disappeared with beta versions.
Perhaps these people are encountered with a problem that relates specifically to the 6.48beta5 version.
In version 6.48beta7 added new improvements that also related to CRS354.

+1

i have about 15 pcs of crs354 (with / without POE - both variant ) and one of them have also this issue

no some special setting, just bridge all over interfaces and dhcp-client on that bridge

ros 6.47

+2
another switch started doing that thing
OMG
I am running whole network on these switches, I will kill my self...

+2
another switch started doing that thing
OMG
I am running whole network on these switches, I will kill my self...

I feel you I have not that much switches of that type, but the problem is very big

I was going to build my network with CRS354....but seeing this issues, I am going for other vendor.

Arista refurbished, same price, 10 times better.

no biggie, on many units I can move client to ether 9 or higher
i will wait for fix and if sometime some unit fail again on ports 1-8, just will do restart and show must go on...

my trust on mikrotik is no broken, everyone make mistakes

There is more than a month since clients reported the issue and still no fix. They do not care about the switches. Routers are their priority.

The old series of switches still have issues, that were reported and no fix. Mikrotik decided to take the next step with the new generation.

Reboots are permited once in a while. On of my clients run a hosting business. How can I tell him to reboot every time the switch goes nuts ?

Yes, for offices and home users, reboots are not a problem.

Update;
routeros-mipsbe-6.48beta5 does not fix issue
while ports are affected per controller (8 sequential ports), its not always ports 1-8, can be 9-16 or 16-24, etc

latest test beta routeros-mipsbe-6.48beta7 was handed out this morning.. will implement and test this evening

two of my units (I have around 15pcs totally) are affected with this issue and both are failing on ether1-8, I can confirm that, no any other port show problem...

Beta 7 MAY be resolving the issue by automatically flapping the ports. by the time we had the issue it had corrected itself. although at the same time one device in the port group had rebooted which caused a flap of the one port.. so not sure which one made it work again. will report on any info.

also, do NOT apply beta 7 to CRS326-24S+2Q+ if you use Q+ ports.. they seem to stop connecting even if set non-auto neg after updating software and firmware to beta7. works fine in beta5

two of my units (I have around 15pcs totally) are affected with this issue and both are failing on ether1-8, I can confirm that, no any other port show problem...

I have similar issue - how often do the port fail ? Can u reproduce it?

I get 2 groups failing on my 48 switch but can’t reproduce ...
Br
Mark

2 months and still NO fix.

Good job mikrotik !!! True pro !

today tried flapping ports one by one did not help.. had to flap all ports in the affected group and the same time to get it back working. this also throws out the auto-recover possibility. its just random at this point.

Hello Mikrotik-Team,

my customer has the same problem at one of his two crs354.
Is there a date, when you have a fix for this issue?

Hello,

i have exact the same problem with two CRS354-48-4S+2Q+ on ports 1 to 8. Traffic stops forwarding sometimes for a few seconds, sometimes until i disable and re-enable the ports manually.
I have this on two units, today got from my dealer new exchange devices, but they have the same problem. So it looks like a hardware design problem.

Too bad because the devices are actually very nice

Just curious, with anyone having the issue on ports 1-8, if you move those to 9-16 (swap the groups).. do you still see the issue on the first group or does it now move to the new group?

My Customer told me that even with b7 the issue still occurs. i guess its less often, but still not resolved. mtik please advice...

for everyone with this issue, please try new 6.48beta 12 and let us know about results, I will try it also...

Also... they finally admitted there is "just nothing they can do about" busy airtime. So I stopped using their wireless radios.

What do you mean by that? To improve stability in a high noise environment you can enable RTS/CTS. You can always fine-tune the wireless interface by adjusting hw-retries, disconnect-timeout, preamble, etc. Additionally, if your board uses Atheros wireless chip, adaptive-noise-immunity is also an option.

I mean that YOU... took a month between each support email.

Then finally everyone copped to the fact that the noise in my environment was not something Mikrotik could tame. Some fun use of the word... "UNIQUE" was tossed around... But I saw the same problem dozens of times. And switching vendors SOLVED THE PROBLEM AT EVERY LOCATION!

So what I meant was... I have found that their is a pretty common problem that I run into using Mikrotik Wireless that I can solve by swapping vendors.

AND THAT I DO NOT SPEC MIKROTIK RADIOS FOR ANYTHING CRITICAL ANYMORE.

If people want to give it a try... sure... but as soon as they bitch... I flip vendors... Problems vanish. Customers have that bitter taste of paying twice.

I have an Audience sitting on my desk at work... I have it configured as a cap and it works fine. But I have like 10 clients across it 3 radios.

The residential jobs that really killed me... the automation system needed to use the 2.4 radios on Mikrotik WAPs. The Tik radio would just decide... NAH. Rebooting the radio fixed it for a while. But in really crowded installs... they just didn't work at all.

>> So what I meant was... I have found that their is a pretty common problem that I run into using Mikrotik Wireless that I can solve by swapping vendors.
>> AND THAT I DO NOT SPEC MIKROTIK RADIOS FOR ANYTHING CRITICAL ANYMORE.

I know we're getting off topic here but which vendor did you switch to? You'll see in previous posts I have made on the issue I discovered that other vendors like Rukus, Ubiquiti and TPLink turn on the equivalent of setting multicast-helper=full by *default*. Also removing use of any bit rates below 12Mbit or 18Mbit can also help precious airtime from being taken up. I have had classrooms full of 30+ Macbooks and iPads run off a wAPAC just fine (mind you the schools only run on 5GHz).

>> So what I meant was... I have found that their is a pretty common problem that I run into using Mikrotik Wireless that I can solve by swapping vendors.
>> AND THAT I DO NOT SPEC MIKROTIK RADIOS FOR ANYTHING CRITICAL ANYMORE.

I know we're getting off topic here but which vendor did you switch to? You'll see in previous posts I have made on the issue I discovered that other vendors like Rukus, Ubiquiti and TPLink turn on the equivalent of setting multicast-helper=full by *default*. Also removing use of any bit rates below 12Mbit or 18Mbit can also help precious airtime from being taken up. I have had classrooms full of 30+ Macbooks and iPads run off a wAPAC just fine (mind you the schools only run on 5GHz).

30 devices in a controlled environment... little league.

I am talking about brownstones on main street.
People who live in "modern neighborhoods" (With 6K foot houses 4 feet apart and made out of paper).
I mean people who live in apartments
I mean people in Condos.
I mean that one bar I was stupid enough to take the shot...

Its not a multicast helper thing. its not a rate thing. The RADIO WILL STOP ACCEPTING ANY CLIENTS. So I monitor for when the printer drops off line in netwatch then cycle the radio.

Mikrotik specifically stated that the environment is just too crowded. Problem is... thats where most of my jobs are.

And yes Ruckus has been the Silver Bullet EVERYTIME. So I just spec them first. (God I wish I could control a Ruckus like radio in caps-man!!!)

Back to my switch problems... I had the "nothing passes until a reboot." Happened several times.
During a lock up I got in there and started sending pings... THEY PASS. Which made it harder to detect that the SWITCH I NEVER SHOULD HAVE USED LOCKED UP AGAIN!!!

But like I typed before... when it comes to routers... I AM USING A MIKROTIK! Even at the Ubiquiti National Distributor... they couldn't come close to getting the routing working. Kept their switches and WAPs... traded out routers... its been running for several years. Any time they ask me about "UniFi routing... why aren't you in on this." I tell them to look at the system that runs their 4 locations.

Sorry guys, could you please move your "i hate wireless from mtik" to another, different thread?
we need to get this port 1 till 8 issue resolved quickly, but to mix all up here doesnt help much.
thank you.

Sorry guys, could you please move your "i hate wireless from mtik" to another, different thread?
we need to get this port 1 till 8 issue resolved quickly, but to mix all up here doesnt help much.
thank you.

Well how's the new beta 12 going? I am installing a 354 today but luckily can avoid using ports 1-8 for now, still it's a bad bug that needs to go away.

Also, how long before this bug manifests itself? I found one very reliable bug last year with 324s where the CPU interface would no longer respond to Winbox or anything else but it took 13 hours before it occurred. Mikrotik did fix that one.

Sorry guys, could you please move your "i hate wireless from mtik" to another, different thread?
we need to get this port 1 till 8 issue resolved quickly, but to mix all up here doesnt help much.
thank you.

Mikrotik specifically asked for it...

But I did include the problem with my switch and how I found it hard to detect. Ergo why it is sitting in it's box next to my door.

I am waiting for an all clear to even put it on the test bench again. But mean while we are using a lot of EdgeSwitch from UBNT because it's been stable.

I got the same problem. Access points that are connected from port 1 to port 8 are disconnected. I really hope that the solution to this problem will not take long.

Experiencing the same problem on two CRS354-48G-4S+2Q+ devices, tried multiple routeros / firmware versions (6.46.4, 6.46.5, 6.46.6, 6.47 and 6.47.1), now trying 6.48beta12..

disabling -> enabling (individual) ports does not seem to resolve the issue, rebooting the whole device does resolve the issue (temporary).
sometimes it magically get resolved automatically after 'a few minutes ~ a few hours' but most of the time is does not auto-recover.

In the beginning we've experienced the issue 'once a week' (after a few days), now we experience the problem like every '± 4 hours'... Not sure if this is related to 'more devices connected', 'more throughput' etc.

I also disabled spanning-tree (RSTP) and 'Fast Forward' (keeping Fast-Path / hardware offload on) on the bridge, and loop-protection on the individual ports but this is not the problem / not resolving the issue.

Interesting thing is that the log does not show anything related to the issue.

In this thread I've read that it seems to only affect ports 1-8, it seems that we can confirm this!

The switches are mounted in the rear of datacenter rack, regarding health / temperature:
CPU: 82˚
Board1: 57˚
Board2: 32˚
Fan1: 7965rpm
Fan2: 7875rpm
Fan3: 7845rpm

But I'm not sure if it's cooling / temperature related since the other ports (9 - 48 and SFP / QSFP) are working fine, also management is working fine and quick / responsive.

now testing ROS 6.48beta12 ...

24 hours without the problem.
Have to admit that we changed two things:

- Updated software and firmware to 6.48beta12
- Moved devices to higher ports, leaving only 1 device connected to the 'affected' ports

Will move the devices back from the higher port numbers to the initial ones (in the 1-8 range) to see if the beta indeed resolves the issue!

So first feeling is that this might resolve the issue! Although we still have another issue with these switches being ports randomly flapping from 1G -> 100M.

i installed v6.48beta12 at a customers location yesterday.
today switch group 9-16 is completely dead. even after a reboot there is no activity on this ports anymore.
connection is detected but no packets passing through. constant 0bps.

i installed v6.48beta12 at a customers location yesterday.
today switch group 9-16 is completely dead. even after a reboot there is no activity on this ports anymore.
connection is detected but no packets passing through. constant 0bps.

LOL ! Such a garbage equipment ! It is just outrageous how Mikrotik doesnt give a damn about clients !

Maybe the routers are OK, but mikrotik switches are just junk !

i installed v6.48beta12 at a customers location yesterday.
today switch group 9-16 is completely dead. even after a reboot there is no activity on this ports anymore.
connection is detected but no packets passing through. constant 0bps.

which model is this and did you update routerboard firmware as well.. if not, which version is the routerboard. have you put back a previous firmware and the ports work again?

i installed v6.48beta12 at a customers location yesterday.
today switch group 9-16 is completely dead. even after a reboot there is no activity on this ports anymore.
connection is detected but no packets passing through. constant 0bps.

which model is this and did you update routerboard firmware as well.. if not, which version is the routerboard. have you put back a previous firmware and the ports work again?

I always update router board firmware to the same level as firmware. is this not the right way?
Haven't tried to go back yet, because I moved the devices to different ports for now. this Is no final solution, because we need the ports, but for now yeah... my only option.

what makes it hard is, that the problem seems to occur randomly. at least at other customers its random.

what you mean by model? the one the topic is about

go with refurbished Arista.

same price, 10x times the stability and professional equipment.

mikrotik is making garbage software.

go with refurbished Arista.
same price, 10x times the stability and professional equipment.
mikrotik is making garbage software.

Well sure, but your caveat is to buy 2nd hand. These bugs will likely be fixed soon enough and thanks to ROS they will be viable devices for 5+ years. The nice thing about the 3xx PoE switches is they put out 24V as well which has been handy for me already where some legacy Ubnt and Mikrotik stuff is in place.

I have only installed one 354 so far with 6.47.1. I have tempted the devil and put the WAN interface on port 1. I will know very quickly if this port fails. So far so good after 4 days.

Have run CRS354-48P's and CRS354-48G's without 1-8 connected for some while
Also had big problems with flapping ports

Anyone else with more stable performance for 6.47.1?
Have not tested 6.47.1 yet, but will later tonight.

Well sure, but your caveat is to buy 2nd hand. These bugs will likely be fixed soon enough and thanks to ROS they will be viable devices for 5+ years. The nice thing about the 3xx PoE switches is they put out 24V as well which has been handy for me already where some legacy Ubnt and Mikrotik stuff is in place.

I still have a switch from second generation that has a bug that they didnt fix it till now. The bug is that every day, the switch freeze and doesnt forward traffic to ports.
I can access it and reboot and the problem is gone, but the next day it hangs again.

With the CRS354 only 1-8 ports have issue....this is a HUGE improvment taking into account that on the 2nd gen, all 24 ports stopped working. Good job mikroshit !

With the CRS354 only 1-8 ports have issue....

Did you ever make some .rif files and engage politely with Mikrotik support to resolve the issue?

I have noticed having my CAPSMAN controller (a hEX) and the WAN on ports 1 and 2 that traffic doesn't stop outright but there are regular short halts causing Winbox/internet stalls and CAPSMAN clients to disconnect and reconnect. I have found CAPSMAN is a great way to discover if your LAN is dodgy because it's so sensitive to traffic timeouts.

I will make a supout.rif and move these connections off the ports 1-8 group and see what happens.

Well it looks like ports 1-8 work on 6.47.1 BUT the data flow stops sporadically.

I had a WAN interface on port 1 - the internet would stop and start regularly but randomly for short durations.
I had a hEX connected as a CAPSMAN controller on port 2 - Winbox talking to it would always disconnect regularly and some CAPSMAN clients would time out and reconnect.

I moved these to ports 9-10 on the weekend and the WAN and hEX behaviour has been far more stable.

even with ros 6.47.1 is problem still present

even with ros 6.47.1 is problem still present

Use 6.48beta12.. all 6.47.x has the issue for sure.

now I am running ros7.1b, we will see.......

now I am running ros7.1b, we will see.......

7.1b only has 6.47.1 fixes.. please try 6.48b12

+1
Have this problem too, but on ports 16-24.

CRS354-48G-4S+2Q+
I have tried on all ROS versions. Port state is UP, but no traffic passthrough to bridge. Only reboot can help.

+1
Have this problem too, but on ports 16-24.

CRS354-48G-4S+2Q+
I have tried on all ROS versions. Port state is UP, but no traffic passthrough to bridge. Only reboot can help.

Have you done firmware as well as package update?

if you still have the issue on 6.48B12, please email a supout file to support@mikrotik

+1
Have this problem too, but on ports 16-24.

CRS354-48G-4S+2Q+
I have tried on all ROS versions. Port state is UP, but no traffic passthrough to bridge. Only reboot can help.

Have you done firmware as well as package update?

if you still have the issue on 6.48B12, please email a supout file to support@mikrotik

Today i;ll try to update both firmware and ROS via Netinstall, then post reply.

Thank you.

After days of continuous operation of a CRS354-48G-4S+2Q+ with v6.48beta12, we just experienced the same problem on another port-group (17-24).
Rebooting the switch 'solves' the problem, wondering if the root-cause of the problem is already found?

This problem basiscly makes this switch unusable for production environments. Considering replacing the CRS354-48G-4S+2Q+ by it's predecessor (a 10 years old HP switch).

This problem basiscly makes this switch unusable for production environments. Considering replacing the CRS354-48G-4S+2Q+ by it's predecessor (a 10 years old HP switch).

YES ! This is the best decision. Replace this amateur hardware with a vendor that actually works. We dont need fancy equipment, we need working hardware !!!

Is there something new?
On some customer sides its quiet silent, but on others I have really big trouble with this switch.
I have all switches on v6.48beta12.

Is there a chance that 7.1beta1 changes something? I didn't find something CRS354 specific in changelog?

@hostclub: you're so frustrated that you get really mad and sarcastic, I like this seems like German character

@hostclub: you're so frustrated that you get really mad and sarcastic, I like this seems like German character

You should be too if your customers have issues because of hardware failure. Whoever sells services but dont care about customers, maybe should stop offering shitty services.

And when a bug/issue is not fixed in more than 2 MONTHS, would you hope for some miracle ? Or start doing something for your clients? An ideea would be changeing the vendor*....

*changeing a vendor that in uncapable of fixing their own products.

hostclub, sure, its a pain. its always the same issue: you buy a brand-new product from mikrotik or ubnt or whatever. it must be the latest, hottest and/or coolest shit. either because you want it or the customer end wants it. then the first issues occur, because the firmware is not 100% working. upgrading, testing, upgrading, testing... and at the end you might throw the device in trash and replace it or, if you have enough time and breath you might get the device working.

however, both is a lession to learn: if you buy the newest crap, be ready that it might not work from the beginning. i have had this with the beginning of the ubnt AC line, the first devices have been replaced due the fact they needed to replace the hardware. i have had it with metrolinq, who will be replaced soon too, because their hardware at their beginning was bit crappy. but hey, thats the price you have to pay if you want all cheap and cool. otherwise invest 20-100 times the amount and buy something else what is tested and proofed to work.

hostclub, sure, its a pain. its always the same issue: you buy a brand-new product from mikrotik or ubnt or whatever. it must be the latest, hottest and/or coolest shit. either because you want it or the customer end wants it. then the first issues occur, because the firmware is not 100% working. upgrading, testing, upgrading, testing... and at the end you might throw the device in trash and replace it or, if you have enough time and breath you might get the device working.

however, both is a lession to learn: if you buy the newest crap, be ready that it might not work from the beginning. i have had this with the beginning of the ubnt AC line, the first devices have been replaced due the fact they needed to replace the hardware. i have had it with metrolinq, who will be replaced soon too, because their hardware at their beginning was bit crappy. but hey, thats the price you have to pay if you want all cheap and cool. otherwise invest 20-100 times the amount and buy something else what is tested and proofed to work.

I dont rely on mikrotik anymore. They didnt fix issues (with traffic forwarding on some ports) on 2nd generation of switches. So I dont hope new crapy hardware to become trustworthy equipment.

I said it before: mikrotik switches are NOT to be trusted in business/critical environments ! For home users, are great.

Homes are not exempt. Business at least usually have hours of operation. Homes owners can, will and do call anytime!

MikroTik please do a statement and solution on this issue - we have switched to ubiquity because we are not willing to have permanent support calls of our clients !

MikroTik please do a statement and solution on this issue - we have switched to ubiquity because we are not willing to have permanent support calls of our clients !

Forget about mikrotik and their switches. Go with any other vendor.

Any manageable switch can do what mikrotik does, but its stable. Even vendors like zyxel, dlink are good enought.
For switching, ubiquiti îs just fine.

They might never solve this issue.

There were changes added to 6.48beta12 that address this issue, and it fixed the problem for some clients, these changes are also present in 6.47.1.
But if you are still experiencing issues with the aforementioned versions, please contact us at support@mikrotik.com or via our support portal https://help.mikrotik.com/servicedesk ,so we can better understand the issue and investigate the root cause.

The more details you can provide, the better, we are trying to replicate the problem and resolve it.

There were changes added to 6.48beta12 that address this issue, and it fixed the problem for some clients, these changes are also present in 6.47.1.
But if you are still experiencing issues with the aforementioned versions, please contact us at support@mikrotik.com or via our support portal https://help.mikrotik.com/servicedesk ,so we can better understand the issue and investigate the root cause.

The more details you can provide, the better, we are trying to replicate the problem and resolve it.

What is the best way to provide useful informations?
The problem ist, that I tried to avoid the most problematic switch ports at my clients, so I don't have problems everyday. That's why I can't see when these ports stop working now.
and when my customers call me that nothing works im restarting the switch very quick. how can I provide you the informations then?
I can't let the system in a non working state to investigate on it.
I would be glad to help, but don't know how :/

What is the best way to provide useful informations?
The problem ist, that I tried to avoid the most problematic switch ports at my clients, so I don't have problems everyday. That's why I can't see when these ports stop working now.
and when my customers call me that nothing works im restarting the switch very quick. how can I provide you the informations then?
I can't let the system in a non working state to investigate on it.
I would be glad to help, but don't know how :/

When you have issues, export the switch config, export a supp inf and then restart. These logs you send it to mikrotik support. If needed, you provide any other information to them in order to solve the issue. Be our hero

The more details you can provide, the better, we are trying to replicate the problem and resolve it.

I can't let the system in a non working state to investigate on it.
I would be glad to help, but don't know how :/

Same here. We added an old 24-port Switch to get rid of 2x8 Ports of the two CRS354 and to
stop these permanent watchdog reboots. Luckily my customer has a good relation and feels
bound to us, else we would have been kicked out long ago for this. However, the deployment
of new mikrotik hardware has still been stopped due this issue :'-(

There were changes added to 6.48beta12 that address this issue, and it fixed the problem for some clients, these changes are also present in 6.47.1.
But if you are still experiencing issues with the aforementioned versions, please contact us at support@mikrotik.com or via our support portal https://help.mikrotik.com/servicedesk ,so we can better understand the issue and investigate the root cause.

The more details you can provide, the better, we are trying to replicate the problem and resolve it.

any chance you can describe what was done to try to fix the issue and perhaps together with that info we can correlate something else from the environments, how we use them, etc.?

Any chance you can describe what was done to try to fix the issue and perhaps together with that info we can correlate something else from the environments, how we use them, etc.?

+1 to this idea. I find it provides valuable information almost everytime to help narrow in on the real issues are faster.

All of the experiences I've had with newly released MikroTik products make it appear as though public is used for much of the refined testing to polish the products and complete them.

MikroTik since this is your default I find transparency for troubleshooting lacking for everything outside of testing branches.
Can we get some form of a public bug tracker? Or am I reaching here?

We have just had the same issue on 6.47.1 and have logged a ticket with support as requested. (SUP-23979)

Still experiencing this issues.. logged the issue 'SUP-23910', no response yet.

Still experiencing this issues.. logged the issue 'SUP-23910', no response yet.

Received a response, we were asked to return the affected switches to Mikrotik for investigation....
First switch is currently with DHL on its way to Mikrotik (via the distributor in Czech Republic).

Please keep us updated on this. thank you!

I think this is a hardware design issue...

yeah, thats also my guess. lets see.

Sames issues here - just updated to v6.48beta12 to check the behavior.

Folks - I'm watching this thread as someone with a CRS354 that I simply want to use as a switch rather than a router.

Out of interest, for those of you currently using the switch, are you using RouterOS in the absence of SwitchOS for the device or is it the routing capability you need?

No agenda, just wondering. I've mine sitting in a corner waiting for SwitchOS.

Folks - I'm watching this thread as someone with a CRS354 that I simply want to use as a switch rather than a router.

Out of interest, for those of you currently using the switch, are you using RouterOS in the absence of SwitchOS for the device or is it the routing capability you need?

No agenda, just wondering. I've mine sitting in a corner waiting for SwitchOS.

I believe this switch only works with routerOS

I believe this switch only works with routerOS

There was a brief mention in another post that MikroTik were working on SwOS for these devices although, from the looks of things, I'll not be holding my breath waiting for it

viewtopic.php?f=21&t=163657&p=806145&hi ... 54#p806145

if This is a hardware design issue switchOS doesn't help...
for me it would not be a big advantage to have a broken switchOS device than a broken routerOS device...
If this problem would not be in switchOS, then I think it would already be fixed in routerOS... :S

OLD issue/topic. No fix.

Move it to trash (where the crs354-48G/P should be also).

Hahaha

Hey Guys,

I have had a response regarding my ticket on the issue. Tech support gave me a new release of the ROS and to date not more problems (so here's hoping).

The version that I'm on 6.48Beta23

Thanks

LogicalNZ

The version that I'm on 6.48Beta23

Is there some changelog available, that takes account of this problem?
I don't want to install new updates / beta's anymore when there's nothing said about this problem in changelog.

Is this beta23 only available from support?

stop with your stupid whining and just wait for fix, especially when you have nothing to say, except of this useless comments

Your comment îs more stupid than mine. And you are off-topic. Here, we are talking about a broken hardware, not other peoples comments.

Are you working at mikrotik and you are disturbed that customers are not happy for broken hardware?

Mind you own business.

Installed beta23 and testing now. Last time it took just 30 minutes to get a bug, now an hour is passed and still no bug. Though I connected only one link with 15Mbps to the one of problem ports.
I will try to connect some more links tomorrow. Hopefully beta23'd work.

In full awareness that this is only going to get an abusive response, I've got to side with rushlife on this one.

Hostclub, you've obviously had a horrendous experience with these devices and are incredibly frustrated, most likely entirely justifiably so.

However, your bot-like dedication to replying to almost every recent post on this thread with "these are s##t, buy something else" is just spam to those of us who have subscribed to this thread in the hope of finding a solution. Also, it means you don't get to accuse someone else of going off-topic.

"This is broken hardware" is your opinion. You could well be right but you're presenting it as fact when this hasn't been established. Someone a few posts up has said that they've received beta firmware that appears to resolve the issue for them, I notice you didn't reply to that one.

And to save the obvious response, I don't work for Mikrotik, I'm not affiliated with Mikrotik, I don't know anyone who knows anyone who is affiliated with Mikrotik. I'm just a pleb who bought one of these units without checking it out properly.

By the way, I completely agree with you that these devices should never have been allowed out the door with the current software and / or hardware solution and MikroTik should be ashamed of themselves but please, you don't have to respond to EVERY comment calling them out, it's not helping.

Hostclub, you've obviously had a horrendous experience with these devices and are incredibly frustrated, most likely entirely justifiably so.

Please allow me to tell a little story: In the past I have used CRS226-24G-2S+RM as network switches and they had similar issues: traffic was not forward to some ports (sometimes all). I was able to login and reboot them and everything was fine.
I have choosen the "legal" path:
1. wrote on the forum -> no answer.
2. wrote to mikrotik support -> they told me to update the software (but the problem still occured).
It is 2020 and the issues are still not fixed for those. I had to replace them with other vendor -> waste of money and time.

Now I said to give them another chance. And what u know: a similar issue is for these models. OK, no problem, shit happens. Every vendor has issues....but this problem is more than 3 months old and Mikrotik does not put any effort to fix it.

I dont know how you all handle with clients....but its a little bit frustrating to explain to my clients that some switches have issue. They dont care. They just say: "change that stupid hardware".

I can't praise them for releasing an untested product.

Curious.. I am not able to replicate it as often as before.. but for anyone who can see it happen a lot, i had a thought.. can you try reducing the CPU frequency in routerboard settings?

hostclub... as i already said some posts before... i guess noone wants to hear your stories in this thread about some other mtik hardware. please just stop spamming with your frustrated answers. thanks.

hostclub... as i already said some posts before... i guess noone wants to hear your stories in this thread about some other mtik hardware. please just stop spamming with your frustrated answers. thanks.

maybe if noone (including mikrotik support) doesnt want to know about mikrotik hardware/software issues, maybe the forum should be closed, right ?

In regards to 6.48 Beta 23

From my understanding Mikrotik have addressed the ports disconnecting issues. I see no change log at this point.
I would imagine it is available from support as that is where I got it from.


To date, no problems with new firmware. No port dropoffs.

- Alan

In regards to 6.48 Beta 23

To date, no problems with new firmware. No port dropoffs.

OK, this is good news ! Maybe this version should be available for all customers with problems. After a period of testing, they should release a stable version.

No betas for me... Or my end users.

+1
Have this problem too, but on ports 16-24.

CRS354-48G-4S+2Q+
I have tried on all ROS versions. Port state is UP, but no traffic passthrough to bridge. Only reboot can help.

Have you done firmware as well as package update?

if you still have the issue on 6.48B12, please email a supout file to support@mikrotik

Today i;ll try to update both firmware and ROS via Netinstall, then post reply.

Thank you.

Day 13 of test. System operates without problems. ROS 6.47.1

...Your comment îs more stupid than mine.

I doubt it.

...And you are off-topic.

More then you ?
Again,I doubt it.

Here, we are talking about a broken hardware, not other peoples comments.

YOU are talking about NOTHING. You just whining and swearing here.
Not a single bit of constructive thinking, nothing really helpful for other.
Just million comments about nothing.
If you have nothing to say, just be quiet and wait for those they have.

Are you working at mikrotik and you are disturbed that customers are not happy for broken hardware?

No, I am not.
I just work with mikrotik devices for about 11-12 years and I known this sw and hw are great.
Still - It is made for humans by humans. And sometime hw/sw can have error/code mistake.
I am human too so I am able to accept this and willing to help other, or even Mikrotik.

Mind you own business.

I will, and I advise you the same.

I doubt it.

I just work with mikrotik devices for about 11-12 years and I known this sw and hw are great.

You are still off-topic. Can you help the community regarding this issue or just keep talking garbage?

If you dont have usefull information for users owning these switches, just go away. The non-working devices makes us trouble. We dont need more from you. Start being usefull or stfu.

Beta23, four hours of a ~800Mbps using "broken ports" - seems to be ok. Finally. Hoping the issue is fixed but still watching.

Beta23, four hours of a ~800Mbps using "broken ports" - seems to be ok. Finally. Hoping the issue is fixed but still watching.

Hi there where can I get this beta23 ?
i see at mikrotik download section its only 6.48beta12

I just bought CRS 354 48G 4S+ 2Q...
sadly right now im only use 1st port and second port, and sfp+ for my uplink to CCR,
Both gigabit (1st port and 2nd port) sometimes not forward the packet randomly... its not that long (only 1sec or 2sec), but still for production environment its huge issue.

Thank you sir.

Unfortunately problem is not solved with beta23. Once again 8 ports have links but not transmitting. For 26 hours it was ok with high load.

Unfortunately problem is not solved with beta23. Once again 8 ports have links but not transmitting. For 26 hours it was ok with high load.

As I said... when it's not in the changelog, there was nothing done regarding this problem...
What makes me really angry now is, that MikroTik seems to think that we are stupid idiots...
They are continuously sending out new beta firmwares "here try this, maybe this will fix it" while knowing, that they have done NOTHING in this firmware regarding this problem...
What do they think? That someday we will just think it's working? Or this problem will just go away by magic?

@MikroTik this is a very poor performance... Seems like you really don't care...

I am running my CRS354 units with 6.48beta12 (testing), so far so gut.
Not even single problem since upgrade to this version of ROS.
I am watching this on 10pcs (354 with and without poe).

I am running my CRS354 units with 6.48beta12 (testing), so far so gut.
Not even single problem since upgrade to this version of ROS.
I am watching this on 10pcs (354 with and without poe).

how long?

Same issue occured with 6.48beta12 - took a bit longer but anyway...

We will open a ticket and see what they say and maybe we get 6.48beta22 - via support too. Btw any active communication from Mikrotik in the thread would be great.

Btw any active communication from Mikrotik in the thread would be great.

I would love to get any communication from MikroTik in any way... But they just say "try this firmware" knowing that they haven't done anything... Just to keep us busy...
this get's really frustrating :/ If they would have done something regarding this problem, I think they would say what's the problem and how they try to fix it.

I have uptime more than 12 days and everything is just fine...
Really since upgrade to beta 12 I can not reproduce this error.

I applied Beta23 on the 10th of August. To date no problems.

I applied Beta23 on the 10th of August. To date no problems.

Try giving more traffic to the problem ports at least for half an hour. I also had no problems until I plugged one high load uplink. Until that moment ~800mbps with 9-16 ports in total were doing well for a whole day. With additional ~700mbps it worked for 16 minutes.
Also I have some uplinks like ~1Mbps. If I plug them to problem ports I see no problems ever.

As I said... when it's not in the changelog, there was nothing done regarding this problem...

Yep. It seems like "Hmm, we tried those fixes one last time... Let's try these one, maybe it helps!" Hope it's not.
Though that's really sad. I'm afraid that it is hardware mistake 'cause I have one more crs354 that works perfectly even on 6.46. And the thing that makes it more sad that it's some kind of lottery - would it be working brand new crs354 if I replace it or it it'd be the same brand new one with the same bug.

One of the problem ports is my switch uplink port...

+1
Have this problem too, but on ports 16-24.

CRS354-48G-4S+2Q+
I have tried on all ROS versions. Port state is UP, but no traffic passthrough to bridge. Only reboot can help.

Have you done firmware as well as package update?

if you still have the issue on 6.48B12, please email a supout file to support@mikrotik

Today i;ll try to update both firmware and ROS via Netinstall, then post reply.

Thank you.

Day 13 of test. System operates without problems. ROS 6.47.1

Day 17 of test. The same problem. ROS and firmware 6.47.1
The problem recurred on one port.

One of the problem ports is my switch uplink port...

We've uplinked the device using a QSFP+ (40G) port, this port has never given any issue.
We can confirm that the issue seems to be related to either high utilization or the sum of data (packets / bytes, not sure) transferred.

We've not done any further tests (like beta23) since 6.47.1 / 6.48beta12.
Due to the ongoing problems we decided to rollback / revert to their predecessors (HP 1920-48G, which we actually replaced by the Mikrotik CRS a few months ago because of their age).

One of our CRS354's has been returned to Mikrotik for investigation.

when will the problem be resolved?????

Its very odd, since updating 4.28.Beta23 we have not had a single issue.

I take you guys that have ongoing issues have logged a case with support and provided all the information that they require? I found they took a day or two to get on the case, but once on the case they were very responsive.

They do need lots of info, I even gave them a SUP OUT from the upstream router the switches are connected to.

no problem whatsoever...

6.48beta12 I still have a problem! Please attach 6.48beta23

6.48beta12 I still have a problem! Please attach 6.48beta23

E-mail support and you will get access to the version that way. I would never run anything I can download outside official channels.

I sent a e-mail - I'm waiting, like all my clients

Had to be removed from work. This is how the mikrotik equipment works now ... I'm waiting for a decision

sent v6.48beta26, we will try

viewtopic.php?f=21&t=163308&p=811799#p811759

What's new in 6.48beta27 (2020-Aug-18 06:20):

Changes in this release:
*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices;

Now all can test :)

*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices;

[/quote]

I would more like to read "fixed ethernet port group traffic..." instead of "improved".
But lets see if this finally helps.

ld more like to read "fixed ethernet port group traffic..." instead of "improved".

"Fixed" = Admission that it was broken in the first place = grounds for compensation

I wouldn't hold my breath waiting :-)

ld more like to read "fixed ethernet port group traffic..." instead of "improved".

"Fixed" = Admission that it was broken in the first place = grounds for compensation

I wouldn't hold my breath waiting :-)

That is somewhat true. Worst changelog I ever read was for a software that we had way back. It read "Made the shit work like it should". It was an internal note that slipped trough and got us about 50 % discount for a year!

The problem is that who bought thse devices, bought to use in business/professional environments. Usually, home users do not buy such equipment.

So, what should we do? Change the devices with other vendor (like some users allready did)? Try and go on with beta versions and hope its all good (but our customers become angry for downtime) ?

I allready said that its unacceptable that such an issue last so much time. But some of you said that I am a troll.

I never said that vendors are not allowed to have bugs. All vendors have issues/bugs. But some of these vendors fix bugs in short time.

For mikrotik, this bug is more than 4 months old.

Did you see that this changelog entry also was in 6.47.1?

What's new in 6.47.1 (2020-Jul-08 12:34):

*) crs3xx - fixed HW offloading for netPower 15FR and netPower 16P devices (introduced in v6.47);
*) crs3xx - fixed increased CPU temperature for CRS354-48G-4S+2Q+ device (introduced in v6.47);
*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices;
...

So seems not like this beta brings something new regarding this problem :/

6.48beta27
maintains the web in the same way, the traffic does not go through periodically

Did you see that this changelog entry also was in 6.47.1?

What's new in 6.47.1 (2020-Jul-08 12:34):

*) crs3xx - fixed HW offloading for netPower 15FR and netPower 16P devices (introduced in v6.47);
*) crs3xx - fixed increased CPU temperature for CRS354-48G-4S+2Q+ device (introduced in v6.47);
*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices;
...

So seems not like this beta brings something new regarding this problem :/

True but those fixes I think where in the original Beta so fixes from Beta 12 went into 6.47.1 so these fixes should be new and have not yet been introduced into Stable channel just the same change log entry. This is common for MT to do so as they improve something along they way.

What's new in 6.48beta12 (2020-Jul-06 13:33):
Changes in this release:

*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices;

is there some public bug tracker available? where we can track some status?
would also be good for their changelogs to reference bug numbers, so everybody knows what they fixed there.

is there some public bug tracker available? where we can track some status?
would also be good for their changelogs to reference bug numbers, so everybody knows what they fixed there.

O man I would love a bug tracker like MS does with KB articles or also what Cisco is doing.
As of now I only know of case numbers and those are not public.

meanwhile, in the mikrotik community:

is there some public bug tracker available? where we can track some status?
would also be good for their changelogs to reference bug numbers, so everybody knows what they fixed there.

Just to reiterate the same comment I made elsewhere I endorse the above comment because I have made such a request not long ago in these forums.

Now to point out the elephant in the room.
If I could make a suggestion, and this is only a suggestion, maybe we should keep all conversations in these forums at a professional level if we expect to receive professional level help?
I just feel like memes and direct jabs at MikroTik, if warranted, should be for direct conversations done within tickets between yourself and MikroTik.

If I could make a suggestion, and this is only a suggestion, maybe we should keep all conversations in these forums at a professional level if we expect to receive professional level help?
I just feel like memes and direct jabs at MikroTik, if warranted, should be for direct conversations done within tickets between yourself and MikroTik.

Ok Rose, maybe....

acting as professional as mikrotik handling issues !

The point of the forum is to share information peer to peer.

So none of this crap from manufactures like... "Well we have never heard of that before."

Further more...
I would go weeks between emails with support about their crap wireless. Only bitching about it on the forum got them to public ask.. "what's the ticket number?"

Then I would get a "try this"
I would... I report back it didn't work... And another 3 weeks went by.

Call them out on the forum... "What's the ticket number?"

Needless to say I don't bother with their wireless anymore. Which really pisses me off because if caps-man could runs a decent radio... It would be incredible. Sadly... It can not.

So I do not have this switch but how does the new beta work? Based on the silence in this thread it might be better now?

Has the beta solved the issue ?

Has the beta solved the issue ?

I do not know but if I understood Beta 23 (never went public) where good for some and now that Beta 27 is out I'm interested if people have tested and what the result are.
Based on the fact that this thread went silent that can mean that people might have good results because if it did not help we usually hear that in the thread :)

With our office we have 2 of these switches. 1 Poe and one not. The Poe would have this issue about once per day. Since the beta I have not seen it happen once in over 10 days, so this looks promising.

Hi Guys,
does anyone already have experience with beta 27?
I have two 354-24G (no PoE) switches here and I have the same issue on both of them.
But, not only on the first 8 Ports. In my case on Port 11 and on the other switch on Port 12.
Stop working after a while. Link is up. No traffic. No MAC Learning at the port.
After reboot, everything is ok for a while. Or if i link the client to a higher port. E.g. 37, or so. than it works.

Installed beta 27 now and hope it will fix the problem.

Regards
Manfred

Installed beta27
Worked for ~12 hours
Then the problem came again
It works more if there's only a few ports busy or traffic is low

Installed beta27
Worked for ~12 hours
Then the problem came again
It works more if there's only a few ports busy or traffic is low

Well that sucks. Have you created a supout during the issues and sent to MT?

Well that sucks. Have you created a supout during the issues and sent to MT?

Yep. I have an opened ticket with this issue.

I istalled 6.48beta27 too
After 24 hours the problem come back
any news from anyone?

amazing after all this time there is no solution !!!!!

amazing after all this time there is no solution !!!!!

This is a normal behavior as mikrotik doesnt do tests with their hardare. They just release it on market and let the customers do the tests.

A switch that doesnt forward traffic, this is truly an amazing piece of hardware !!! Good job mikroshit !

From our observations, those people who had the same issue (as there are other, not related issues in this topic as well), and who wrote to support, their issue has been resolved in the latest RouterOS v6.48 beta version. If you like, you can wait for the same fix when 6.48 comes out in the stable branch.

If you still have problems even with the latest beta, please email us and provide as much detail as possible, include the RIF file from the latest beta.

I'm sorry for the inconvenience, we will strive to improve testing to catch this type of problem much sooner.

From our observations, those people who had the same issue (as there are other, not related issues in this topic as well), and who wrote to support, their issue has been resolved in the latest RouterOS v6.48 beta version. If you like, you can wait for the same fix when 6.48 comes out in the stable branch.

It's pity to hear it 'cause I do not have the problem with ports 1 to 8, I have the same problem with ports 9 to 16. Is it not related issue? And beta27 (if you're talking about it) did nothing to fix this issue. I sent a rif three days ago and unfortunately had no answer at all. Or you're talking about beta35?

From our observations, those people who had the same issue (as there are other, not related issues in this topic as well), and who wrote to support, their issue has been resolved in the latest RouterOS v6.48 beta version.

Which version is this? Is this mentioned in the changelog(s)?

From our observations, those people who had the same issue (as there are other, not related issues in this topic as well), and who wrote to support, their issue has been resolved in the latest RouterOS v6.48 beta version. If you like, you can wait for the same fix when 6.48 comes out in the stable branch.

If you still have problems even with the latest beta, please email us and provide as much detail as possible, include the RIF file from the latest beta.

I'm sorry for the inconvenience, we will strive to improve testing to catch this type of problem much sooner.

I have same issues with ports stop working - where u see the bug fixed in beta / testing change log ?

What's new in 6.47.3 (2020-Sep-01 05:24):
*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices


You shuld all update to latest version and check out if the issue still exists.

What's new in 6.47.3 (2020-Sep-01 05:24):
*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices


You shuld all update to latest version and check out if the issue still exists.

This line is in the changelog since 6.48beta12, so it actually doesn't say much. And Normis talked about the "latest beta". He even said "If you like, you can wait for the same fix when 6.48 comes out in the stable branch.", so I doubt 6.47.3 will fix anything. I won't waste any time, unless someone convinces me otherwise. ;)

Hey All,

We got asked by Tik support to update to 4.28.Beta23 about 2 or 3 weeks ago, all has been running fine. Last week we had a lockup on ports 9-17 so as per the directions on this forum from Mikrotik, we have upgraded both of our switches to 6.48 Beta 35.

Been running now for 4 days with no problems. I guess its a wait and see exercise now.

What's new in 6.47.3 (2020-Sep-01 05:24):
*) crs3xx - improved Ethernet port group traffic forwarding for CRS354 devices


You shuld all update to latest version and check out if the issue still exists.

I was on this version - this version doesn’t fix it !

Made update on saturday to 6.48 Beta 35. let’s see how long this lasts

I have CRS354-48G-4S+2Q+ switch and no traffic problem on ports 1-8.
You must add each port to Marvell chip so add "hw=yes"

simple/sample config:
/interface bridge add name=bridge pvid=8 vlan-filtering=no
/interface ethernet
set [ find default-name=qsfpplus1-1 ] advertise=1000M-half,1000M-full,10000M-full
...
/interface vlan
add interface=bridge name=srv vlan-id=7
add interface=bridge name=office vlan-id=8
add interface=bridge name=wan1 vlan-id=101
...
/ip address add address=192.168.8.10/24 interface=bridge network=192.168.8.0
/ip route add distance=1 gateway=192.168.8.1
/ip dns set servers=8.8.8.8

/interface bonding add mode=802.3ad name=bond_1-2 slaves=ether1,ether2

/interface bridge port
add bridge=bridge interface=bond_1-2 hw=yes
add bridge=bridge interface=ether3 pvid=101 hw=yes
add bridge=bridge interface=ether4 pvid=101 hw=yes
...
add bridge=bridge interface=ether19 pvid=8 hw=yes
add bridge=bridge interface=ether20 pvid=8 hw=yes
...
add bridge=bridge interface=ether37 pvid=7 hw=yes
add bridge=bridge interface=qsfpplus1-1 pvid=7 hw=yes
...
/interface bridge vlan
add bridge=bridge untagged=ether3,ether4 vlan-ids=101
add bridge=bridge tagged=bond_1-2 untagged=ether37,qsfpplus1-1 vlan-ids=7
add bridge=bridge tagged=bond_1-2 untagged=ether19,ether20 vlan-ids=8
...
/interface ethernet switch port-isolation
set ether3 forwarding-override=ether4
set ether4 forwarding-override=ether3

/ip service disable telnet,ftp,www,api,api-ssl
/user set 0 address=192.168.0.0/16

/interface bridge port set [f] ingress-filtering=yes
/interface bridge set bridge pvid=8 vlan-filtering=yes

/password

Can anyone confirm for sure that 6.48 Beta 35 has fixed this issue? I'm about to make a decision to buy a bunch of CRS354s, and if this issue has not been fixed, we have no choice but to choose a different brand.

I have CRS354-48G-4S+2Q+ switch and no traffic problem on ports 1-8.
You must add each port to Marvell chip so add "hw=yes"

Now I do not have this switch, I have different models, but from what I read this is traffic based. Those that report issues must have hw=yes otherwise they could never reach the speed they say they have. So in this case I do not doubt that issues in the platform exists and MT is slowly fixing problems one by one and normal workaround to go to SWOS cannot be used in this case.
But I would however recommend everyone that has an issue to create a supout file during the issue and send to Mikrotik as there might be more then one issue here.

I have CRS354-48G-4S+2Q+ switch and no traffic problem on ports 1-8.
You must add each port to Marvell chip so add "hw=yes"

In my opinion, HW offload is set as default.
I didn't configured it manually. It is shown as enable in Winbox but not part of an config export. So, I mentioned that is it a default feature of the switch.

KIsman, I see the same thing regarding the default of the hardware offload. I have been running on Beta35 now for around 2weeks with no issues to date.

today installed 6.48beta40 for all of my crs354 units
even with beta 35 no problems
we will se

today installed 6.48beta40 for all of my crs354 units
even with beta 35 no problems
we will se

Im Running CRS354-48P-4S+2Q+ on 6.48beta40.
The problem that Switch Group 2 (Port 9-16) stopped passing traffic appeared again today.
Ports are active but 0bps Tx and Tx.

Seems like a bad joke to me. "Try this, this fixes it" "try it now, this time it fixes it" "this new beta fixes it"...
Mikrotik is joking around with us...

As I said from the beginning, I think its a hardware design issue, nothing that can be fixed via software in a clean way. Maybe they can integrate some dirty fix like restating interfaces or stuff...
But this will never be nice...

Im really really disappointed.

When I said that this is outrageous and miktotik did a horrible job, all users told me I am a troll and mikrotik is the best....

This is more than a 5 months old issue and still no fix. CRS354 sucks big time and mikrotik doesnt give a sh*t about it !

We should ask for refund for this garbage hardware.

When I said that this is outrageous and miktotik did a horrible job, all users told me I am a troll and mikrotik is the best....

This is more than a 5 months old issue and still no fix. CRS354 sucks big time and mikrotik doesnt give a sh*t about it !

We should ask for refund for this garbage hardware.

From reading here I think this is more then one issues and if you experience issues you should contact support as you may have a different issue then the others.
But still this was in no way a good launch and will give you that :-)

today installed 6.48beta40 for all of my crs354 units
even with beta 35 no problems
we will se

problem is still present, bad luck....

problem is still present, bad luck....

Customers that choosed services from companies that use mikrotik, have bad luck...

At our side we have 6 of them in production, only 2 of the six have the issue, both on ports 17/24.
I think it is a hardware issue with faulty controllers of the switch 8 port blocks. This would explain why sometimes it is ports 1/8 some other time 17/24 and also why some switches are fine.
I haven't read anyone until now to have the faulty port block move on the device. (1/8 faulty becoming 9/16 for exemple).
Moving all devices from faulty port range to good port ranges doesnt makes it become faulty so definitively not related to the workload/connected devices.

We are are at beta40 of the firmware, I think mikrotik will have to consider the "hardware problem" cause.

I don't thing is necessarily hardware fault, but (what I think) for mikrotik is hard to reproduce. It can by caused by some type of data frame, some "wrong" hw signal from cheap network card.. I can be virtually anything....
I thing this is why is taking so long to come with some type of solution.

Adding another datapoint... I have a CRS354-48P-4S+2Q+ that for the past few updates has blocked some ports (16 was one of them) after about 12-48 hours post-update. It is currently on 6.47.4. I update the packages and firmware at the same time and reboot twice to make sure both are updated.

At Layer 2, the port is active and negotiates a gigabit connection with the device. If I force the Ethernet interface to 100Mbps (/int eth set 15 auto-negotiation=no speed=100) it successfully establishes a 100Mbps connection. No entries show up in the ARP table (/ip arp print) or the bridge table (/int br host print).

If I disable and re-enable the port (/int eth set 15 disabled=yes/no) the port comes back up and shows a link on both sides, but passes no traffic. Removing and re-adding the port to the bridge has no effect. "HW" is set to "yes" for this port in the bridge (/int br port print). It's a non-PoE computer attached to this port.

Rebooting the switch fixes the problem and it hasn't re-appeared post-update, but this is a pretty quiet network. If the bug is part of a wrapping counter I probably wouldn't see it. I would look for a counter initialized after a firmware update. The counter might be internal to the switch chip and used by its firmware. I would start looking in the VLAN tag processing code.

This switch has bridge VLAN processing turned on and I don't remember it having a problem before I enabled that (/in br vlan add bridge=bridge tagged=e46,sfpp1,bridge,sfpp4 untagged=e25,e26 vlan-ids=30).

It's a production switch so I can't try to make it fail, but if I have to reboot the switch in the future, I'll install the 6.48 beta firmware and see if I can get a support file and open a ticket.

I also have a CRS326-24G-2S+ that stopped moving traffic to one SFP interface in a similar fashion shortly after an update. This also happened shortly after I added VLANs to this network. Rebooting fixed it. It didn't fail after the most recent update to 6.47.4. I don't have enough information to assume this is related, but I thought I would throw it out there just in case.

...... I think mikrotik will have to consider the "hardware problem" cause.

Found a simple solution for this issue: throw away the crs354 mikroshit garbage and installed a Cisco 4948E (48x1gbps, 4x10gbps). It works as expected !

Hi guys

we are experiencing the problem on ports 1-8 which started yesterday so we restarted the switch and it fixed the problem however it happened again today.

I've noticed that there doesn't seem to be any fixes at this time for this so in the meantime does anyone have a script that we could use that will automatically restart the switch if the problem occurs again.

Regards,

you can set netwatch action for some host which lost ping....

you can set netwatch action for some host which lost ping....

Thanks Rushlife,

I also found watchdog, will that work as well?

yeah,
you can reboot device when a specific IP address does not respond or if hw freeze

What's new in 6.48beta48 (2020-Oct-14 10:26):

Important note!!!

Using this version on CRS354-48G-4S+2Q+RM or CRS354-48P-4S+2Q+RM will cause booting issues and device may need to be reinstalled.



Carefully....

April, May, June, July, August, September, October - > more than 7 months issue and still no fix

What do you think:

1. It is a hardware issue and mikrotik cant fix is (and should refund customers) ?
or
2. mikrotik doesnt give a shit and will not fix it ?

Hello
I'm facing the same at our client network.
Strange thing here is that we have 2 of this switches with almost identical config (Each switch serves different office floor), the only difference is that the problematic one has one SFP installed in access VLAN mode, all of the other configurations are identical. I've wrote to support@mt and meanwhile I will try to move the SFP to the other switch and see if the problem will go with the module :)
Both switches are running 6.47 packages and firmware.

I know it has been said before here but I also think that there is not 1 issue here but several.
Might be hardware for some and software for some users. So to fix I think it is important to generate a supout file during the issue and email support@mikrotik.com to get your own case for your issues.
Otherwise Mikrotik might not be aware of just your specific issue.