_HUGE_ Packet loss on CRS125 :(((

src · Wed Feb 11, 2015 12:55 pm

Hello,

I'm not sure it is software or hardware problem, but I still have a question to all of you guys.

I have CRS125-24G hardware and I have a packet loss on every traffic passed thru CPU (I think).

1) Ports 17 (IP1.1) and 19 (IP1.2) are slave. Master port 21 for both. There is IP1 on port 21 (or on bridge1 which is port 21 only - tried both - no matter)
- there is no packet loss between IP1.1 and IP1.2 (they are going thru switch directly)
- there is a packet loss between IP1.2 and IP1 (3-6% on load)

2) Port SFP is slave with port 2 master. There is IP2 on port 2.
- there is a packet loss on this link also (the same 3-6%)

RouterOS 6.26 / Firmware 3.22 (the same with 6.25/3.19)
CPU at ~40% mark while running probe.

The probe is:
# ping -i 0.001 -s 10000 -q -c 1000 192.168.2.200
PING 192.168.2.200 (192.168.2.200): 10000 data bytes

--- 192.168.2.200 ping statistics ---
1000 packets transmitted, 964 packets received, 3.6% packet loss
round-trip min/avg/max/stddev = 0.611/0.848/41.717/1.935 ms

Diagram attached.

IMG_1980.JPG

src · Wed Feb 11, 2015 2:28 pm

Ok. Even if I set IP address on port 19 running probe, take it out of switch (master port=none) when the problem still persist. So I assume the problem on SWITCH-CPU internal link. Wondering if it is hardware problem or it can be figured out by some software settings?

src · Wed Feb 11, 2015 3:06 pm

There is an increased rtt in case of packet loss also:
--- 192.168.2.200 ping statistics ---
1000 packets transmitted, 958 packets received, 4.2% packet loss
round-trip min/avg/max/stddev = 0.605/0.787/41.168/1.913 ms

--- 192.168.2.200 ping statistics ---
1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.600/0.685/1.111/0.041 ms

Wed Feb 11, 2015 3:14 pm

src - You could try to set interface queue to default small for interfaces which are being used in communication (also master port if ti is configured for used interfaces). "/queue interface set <interface_name> queue=default-small"

src · Wed Feb 11, 2015 3:22 pm

The same problem. No problem to ping another mikrotik via switched ports. The problem to ping CRS125 itself.

src · Wed Feb 11, 2015 3:24 pm

Maybe the problem in switch settings? I didn't touch it, but there is a bunch of ROS updates placed in top of default (very old) settings.

src · Wed Feb 11, 2015 5:28 pm

upgraded to 6.27 - no change

src · Mon Feb 16, 2015 4:37 pm

Anyone?

lambert · Mon Feb 16, 2015 11:17 pm

Do you have any packet loss with -i 0.01?

Do you have any packet loss with -s 1472?

The CPU on the CRS is small. Watch cpu utilization while you run the ping command. You are doing a serious flood ping with your existing ping command.

Your existing size is forcing it to send 7 packets over the wire per ping request, unless you've increased the MTU and not told us about it. So, combined with your interval, you are sending 7 * 1000 packets per second to the CPU of the CRS. The CPU of the CRS, and your testing device, is having to perform reassembly actions on every incoming packet and fragmentation actions for every outgoing packet. I think you are just abusing the CPU of the CRS. I presume that the CPU of your test source device is faster than the CRS.

I have no idea why anyone would pick that size option for rapid ping test packets.

src · Mon Feb 16, 2015 11:46 pm

It's a stress test, right. Because the packet loss is up and down, I prefer to do a comparison tests between different systems. So I run these settings because the loss is more constant on these packets. The other system running the same setup is based on the same CPU (mikrotik 2011) and have no packet loss with this probe. The other one connected to CRS port is mikrotik 912 with no packet loss too. Even while probe running thru CRS switch logics. So I assume there is no problem with CPU overloading, the load is not exceed 40% while running probe.

brodayga · Tue Feb 17, 2015 9:27 am

+1
same http://forum.mikrotik.com/viewtopic.php ... 55#p469284

src · Tue Feb 17, 2015 10:57 am

Thanks God I'm not alone!

src · Tue Feb 17, 2015 1:52 pm

Ok. I reset config on CRS125.
Now what we have with no default config, just IP address on one of interfaces:
--- x.x.x.66 ping statistics ---
5000 packets transmitted, 4788 packets received, 4.2% packet loss
round-trip min/avg/max/stddev = 14.705/15.063/76.878/2.814 ms

The same subnet, mikrotik 2011:
--- x.x.x.67 ping statistics ---
5000 packets transmitted, 5000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.759/12.916/14.490/0.146 ms

So any thoughts?

The probe is:
ping -s 10000 -i 0.001 -q -c 5000 x.x.x.y

src · Tue Feb 17, 2015 2:05 pm

Also guys have performance issues:
http://forum.mikrotik.com/viewtopic.php?t=82422

MIKROTIK, any answer on this?

src · Tue Feb 17, 2015 2:28 pm

Or even so:

--- X.X.X.66 ping statistics ---
1000 packets transmitted, 826 packets received, 17.4% packet loss
round-trip min/avg/max/stddev = 16.003/36.950/50.360/5.109 ms

--- X.X.X.67 ping statistics ---
1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.911/13.055/14.039/0.150 ms

brodayga · Sun Feb 22, 2015 10:59 am

UP. how to solve the problem?

src · Sun Feb 22, 2015 11:12 am

Seems no way to solve it. Switched back to old rb2011

chocbanana · Tue Feb 24, 2015 7:14 am

We have the same issue using a CRS125 on v6.27 with 16 ports bridging onto a VPLS tunnel and one port for MPLS/IP uplink - inexplicable packet loss when pinging to IPs that are both on and through the CRS. There is an absence of any L2 errors on any interfaces. CPU is only hitting 30-40%

I have not found a solution either, we are about to replace it with something else.

src · Tue Feb 24, 2015 9:39 am

Mikrotik, any response?!

okoun · Tue Feb 24, 2015 10:24 am

Hello, I have exactly the same problem, I do not think that it is a weak CPU but something bad in RoS because how is it possible that in version 6.12 is quite low packet loss, and then in the amounts of 6.19 versions need is much greater? Not noticed that he was somehow overloaded switch.
For me, I pray also that mikrotik responded to this, obviously is a mistake on his part (mikrotik). Caution If you replace the CRS RouterBOARD RB2011 and the problem disappears, and is the same CPU!

UMarcus · Tue Feb 24, 2015 10:25 pm

Less Packet Loss with my CRS125 RoS 6.27

Probe ping -s 10000 -i 0.001 -q -c 5000

5000 packets transmitted, 4980 received, 0% packet loss, time 5286ms
rtt min/avg/max/mdev = 0.643/0.785/54.237/1.705 ms, pipe 6

5000 packets transmitted, 4995 received, 0% packet loss, time 5089ms
rtt min/avg/max/mdev = 0.640/0.724/32.616/0.684 ms, pipe 4

5000 packets transmitted, 4999 received, 0% packet loss, time 5013ms
rtt min/avg/max/mdev = 0.562/0.609/0.722/0.031 ms

Ping to CRS125 direct and Ping routed thru VLAN A to B via CRS125.

okoun · Wed Feb 25, 2015 9:39 am

I do not need to send any special parameter to ping Just look on the graph for smokeping and you can see that it has a small packet loss, it happens but only at certain times and times are changing daily. It's definitely not the network load, packet loss is at any time.

Kozma_last_108000.png

okoun · Thu Mar 05, 2015 12:52 am

So far, no response from either the technical support Mikrotik. Will the anyone care? Or it will be corrected to version 7 of ROS?

src · Thu Mar 05, 2015 3:13 pm

Seems everybody at Mikrotik know the problem but anyone cares.

((

brodayga · Thu Mar 12, 2015 4:52 pm

UP. how to solve the problem?

lambert · Thu Mar 12, 2015 4:59 pm

I have no opinion on whether or not this will help your issue. Have you tried http://forum.mikrotik.com/viewtopic.php?t=92711#p463429.

DLNoah · Thu Mar 12, 2015 5:09 pm

Ok. Even if I set IP address on port 19 running probe, take it out of switch (master port=none) when the problem still persist. So I assume the problem on SWITCH-CPU internal link. Wondering if it is hardware problem or it can be figured out by some software settings?

One thing I haven't seen mentioned here:

The wiring diagram for any of the MikroTik switch chips (including the ones in the CRS125) is such that the chip has ONE single lane to the cpu port. So, in the CRS125's specific case, the hardware is basically a single 26-port gigabit network switch, with 24 Ethernet ports, 1 SFP port, and 1 port connected to the RouterOS CPU layer.

There were a couple major changes in the underlying configuration for CRS switches in the v6.x series. Based on the change logs, the most recent major changes were in v6.12. The recommendation I've followed for all of my CRSs is that if I upgraded them from something before v6.12 to something after v6.12, I do a full factory reset (with defaults) and then re-configure the switch manually or import a configuration from something that was configured starting with a post-v6.12 default.

Otherwise, it's not very clear from your initial post exactly what you're testing -- are you testing from device to device, or from device to CRS? Your ping test is putting over 80Mbps of full-duplex traffic into/through the switch (and all the resulting de-fragmentation & fragmentation if it's going into the switch). Based on my experience, I don't typically expect a CRS1xx or RB2011 series unit to handle more than 150-200Mbps Half-Duplex traffic going through the CPU ports -- if you're testing device to device and the two devices are not in the same master-port group, you're basically trying to ram 320Mbps Half-Duplex (80Mbps in and out x2) through the CPU port on the CRS, and I wouldn't be terribly surprised to see it having problems at that point, even if the CPU itself isn't maxing out.

src · Thu Mar 12, 2015 7:21 pm

As I said, I reset CRS even with no defaults (clean) on 6.27. The problem still persist. No problem on RB2011.

No answer from Mikrotik. Seems they know problem.

honzam · Thu Mar 12, 2015 8:35 pm

No answer from Mikrotik. Seems they know problem.

+ 1

okoun · Sun Mar 15, 2015 12:41 pm

Exactly, I can confirm that it does not help erase the whole setup, it is still the same. Additionally, if you exchange it for RB2011 problem does not occur!
In my view, the problem everyone, but many admins do not solve this problem, because many times even such small packet loss measured.

src · Sun Mar 15, 2015 1:08 pm

I think it's time to call Mikrotik support about the issue. Local Mikrotik distributor doesn't understand the problem. Certified Mikrotik trainer doesn't respond on my question.

((

wpeople · Tue Mar 17, 2015 6:06 pm

i've just run into the same issue: i wanted to transfer 3x2011 into 1xCRS.
If the CRS is the first in the row, receiving traffic from port1 and passing to port2 (with VLANs, using ethernet-default queue [pfifo 250pkts] instead of only hw queue)
We had huge packet loss, also illogical issues in network.

Pulling off CRS and leaving just the chain of 2011 - everything working pretty nice.
(same ROS version: 6.25)

I'm very interested, how this can be happened, with same version of software, and same CPU kind.

hossain2004a · Tue Mar 17, 2015 7:21 pm

So far, no response from either the technical support Mikrotik. Will the anyone care? Or it will be corrected to version 7 of ROS?

I'm very lucky in contacting mikrotik supports

.... maybe I should try

Thanks God I'm not alone!

src · Tue Mar 17, 2015 7:29 pm

Just sent them an email

src · Wed Mar 18, 2015 11:58 am

Received response from Mikrotik. The same "change queue type" answer. Still not working. Will keep you guys informed how it goes.

src · Mon Mar 23, 2015 4:49 pm

Recommended to do Netinstall. The same problems after clean 6.27 Netinstall.

chocbanana · Tue Mar 24, 2015 3:04 am

Thanks for keeping us updated. Very interested to see something from Mikrotik support.

UMarcus · Wed Mar 25, 2015 2:21 pm

Thanks for keeping us updated. Very interested to see something from Mikrotik support.

+1

src · Wed Mar 25, 2015 3:28 pm

Still no answer from them since I confirmed problems after clean Netinstall. I also gave them access to my CRS125 so they can check everything by themselves if needed.

hossain2004a · Wed Mar 25, 2015 6:22 pm

There are 2 possibilities:
1- They are working on your problem
2- They have forgot it!!!

Jeanluck · Thu Mar 26, 2015 6:48 pm

I loss 30% of packets with CRS212, I thought that with 6.23 firmware in the CCR1016 connected to CRS212 the problem was solved, but not. Finally the CCR1016 is wrong.... with other CCR unit all works fine.
Even if you think the problem is in the CRS like me, maybe on your CCR

miasik · Fri Mar 27, 2015 12:01 pm

Try queue type "ethernet-default"

UMarcus · Fri Mar 27, 2015 1:31 pm

Try queue type "ethernet-default"

I guess this is already testet by src without success :

Received response from Mikrotik. The same "change queue type" answer. Still not working. Will keep you guys informed how it goes.

troffasky · Sat Mar 28, 2015 9:15 am

I found I was getting 10-15% packet loss through my CRS125 when an IPsec tunnel terminated on it was loaded up [about 15Mbps of IPsec throughput]. I changed the queue type to ethernet-default [which seems to be the default answer to any problem with a CRS125] and now I get 20Mbps IPsec throughput [which is the limit of the line it is plugged in to] and ~0.5% packet loss.

src · Sat Mar 28, 2015 9:20 am

I have no IPSec but I have ~80mbps on MPPE encrypted VPN tunnels or ~60Mbps on openvpn with rb2011 so 20Mbps on IPSec sounds bad.

Sat Mar 28, 2015 6:51 pm

I have no IPSec but I have ~80mbps on MPPE encrypted VPN tunnels or ~60Mbps on openvpn with rb2011 so 20Mbps on IPSec sounds bad.

He said 20 Mbps is the line speed, so that's actually good.

src · Sat Mar 28, 2015 8:20 pm

I asked Mikrotik do they want me to ship my unit to them because they said they can't reproduce problem on their test board. How many people with the same problem here?

okoun · Tue Mar 31, 2015 2:56 pm

Well, I do not simulate well, so if anything MikroTik observed, so maybe it's normal. In addition, I repeat that the packetloss is very small and if it is not set to smokeping great sensitivity so you can not see!
For me it is on two switches that are purchased at a different time, switch the serial number: 49CC021402FB and other switch has a number: 49C904AD4219. Both have the same problem.

src · Thu Apr 02, 2015 11:32 am

Ok guys. I received an update from Mikrotik (6.28rc19) which significantly improved the results!

# while true; do date; ping -i 0.001 -s 14720 -q -c 10000 192.168.88.1 | tail -2; done
Thu Apr  2 11:26:50 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.644/0.757/5.631/0.178 ms
Thu Apr  2 11:27:01 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.639/0.752/5.575/0.140 ms
Thu Apr  2 11:27:11 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.644/0.750/4.593/0.100 ms
Thu Apr  2 11:27:22 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.649/0.749/4.540/0.077 ms
Thu Apr  2 11:27:33 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.640/0.752/4.653/0.132 ms
Thu Apr  2 11:27:43 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.637/0.750/4.602/0.115 ms
Thu Apr  2 11:27:54 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.637/0.751/4.606/0.116 ms
Thu Apr  2 11:28:05 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.640/0.754/5.578/0.154 ms
Thu Apr  2 11:28:16 EEST 2015
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.634/0.752/4.589/0.132 ms
Thu Apr  2 11:28:26 EEST 2015
10000 packets transmitted, 9999 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.637/0.756/7.913/0.194 ms

okoun · Thu Apr 02, 2015 4:49 pm

I would also like to test but I have this latest RC release, please send thanks.

src · Thu Apr 02, 2015 6:31 pm

Please anyone try it on your CRS125. Let us know the results!

https://drive.google.com/file/d/0BzmrUq ... sp=sharing

okoun · Fri Apr 03, 2015 1:03 am

So that's ok?

[m@k] /system routerboard> print
routerboard: yes
model: CRS125-24G-1S
serial-number: 49CC021402FB
current-firmware: 3.22
upgrade-firmware: 3.16.3

src · Fri Apr 03, 2015 2:18 am

> /system package print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 routeros-mipsbe 6.28rc19
1 system 6.28rc19
2 X wireless-fp 6.28rc19
3 X ipv6 6.28rc19
4 wireless 6.28rc19
5 hotspot 6.28rc19
6 dhcp 6.28rc19
7 mpls 6.28rc19
8 routing 6.28rc19
9 ppp 6.28rc19
10 security 6.28rc19
11 advanced-tools 6.28rc19

okoun · Fri Apr 03, 2015 7:06 pm

So unfortunately for me it's the same problem with most versions.

I test it in real traffic.

src · Fri Apr 03, 2015 10:24 pm

Okoun,
Did you managed to upgrade your CRS by this new ROS?

okoun · Fri Apr 03, 2015 11:32 pm

Yes, I switch to the two recorded it from version 6.12 and it's a total disaster it is much worse, as shown here:

kozma.png

it looks like it probably will be back at 6.12 which erred far less!

This is one switch after the upgrade:

 [@] > system routerboard print 
       routerboard: yes
             model: CRS125-24G-1S
     serial-number: 49CC021402FB
  current-firmware: 3.22
  upgrade-firmware: 3.16.3
  
[@] > system package print 
Flags: X - disabled 
 #   NAME                                                                                        VERSION                                                                                        SCHEDULED              
 0   routeros-mipsbe                                                                             6.28rc19                                                                                                              
 1   system                                                                                      6.28rc19                                                                                                              
 2 X wireless-fp                                                                                 6.28rc19                                                                                                              
 3   ipv6                                                                                        6.28rc19                                                                                                              
 4   wireless                                                                                    6.28rc19                                                                                                              
 5   hotspot                                                                                     6.28rc19                                                                                                              
 6   dhcp                                                                                        6.28rc19                                                                                                              
 7   mpls                                                                                        6.28rc19                                                                                                              
 8   routing                                                                                     6.28rc19                                                                                                              
 9   ppp                                                                                         6.28rc19                                                                                                              
10   security                                                                                    6.28rc19                                                                                                              
11   advanced-tools                                                                              6.28rc19  
  
[@] > queue interface print 
 # INTERFACE                  QUEUE                 DEFAULT-QUEUE                
 0 ether1                     only-hardware-queue   only-hardware-queue          
 1 ether2                     only-hardware-queue   only-hardware-queue          
 2 ether3                     only-hardware-queue   only-hardware-queue          
 3 ether4                     only-hardware-queue   only-hardware-queue          
 4 ether5                     only-hardware-queue   only-hardware-queue          
 5 ether6                     only-hardware-queue   only-hardware-queue          
 6 ether7                     only-hardware-queue   only-hardware-queue          
 7 ether8                     only-hardware-queue   only-hardware-queue          
 8 ether9                     only-hardware-queue   only-hardware-queue          
 9 ether10                    only-hardware-queue   only-hardware-queue          
10 ether11                    only-hardware-queue   only-hardware-queue          
11 ether12                    only-hardware-queue   only-hardware-queue          
12 ether13                    only-hardware-queue   only-hardware-queue          
13 ether14                    only-hardware-queue   only-hardware-queue          
14 ether15                    only-hardware-queue   only-hardware-queue          
15 ether16                    only-hardware-queue   only-hardware-queue          
16 ether17                    only-hardware-queue   only-hardware-queue          
17 ether18                    only-hardware-queue   only-hardware-queue          
18 ether19                    only-hardware-queue   only-hardware-queue          
19 ether20                    only-hardware-queue   only-hardware-queue          
20 ether21                    only-hardware-queue   only-hardware-queue          
21 ether22                    only-hardware-queue   only-hardware-queue          
22 ether23                    only-hardware-queue   only-hardware-queue          
23 ether24                    only-hardware-queue   only-hardware-queue          
24 sfp1                       only-hardware-queue   only-hardware-queue

src · Sat Apr 04, 2015 9:46 am

Can you also change queue to Ethernet-default as recommended and try again?

okoun · Sat Apr 04, 2015 10:46 am

OK, I've set up and see what it will do in the evening

[@] /queue interface> print 
 # INTERFACE                                                                          QUEUE                                                                          DEFAULT-QUEUE                                                                         
 0 ether1                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 1 ether2                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 2 ether3                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 3 ether4                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 4 ether5                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 5 ether6                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 6 ether7                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 7 ether8                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 8 ether9                                                                             ethernet-default                                                               only-hardware-queue                                                                   
 9 ether10                                                                            ethernet-default                                                               only-hardware-queue                                                                   
10 ether11                                                                            ethernet-default                                                               only-hardware-queue                                                                   
11 ether12                                                                            ethernet-default                                                               only-hardware-queue                                                                   
12 ether13                                                                            ethernet-default                                                               only-hardware-queue                                                                   
13 ether14                                                                            ethernet-default                                                               only-hardware-queue                                                                   
14 ether15                                                                            ethernet-default                                                               only-hardware-queue                                                                   
15 ether16                                                                            ethernet-default                                                               only-hardware-queue                                                                   
16 ether17                                                                            ethernet-default                                                               only-hardware-queue                                                                   
17 ether18                                                                            ethernet-default                                                               only-hardware-queue                                                                   
18 ether19                                                                            ethernet-default                                                               only-hardware-queue                                                                   
19 ether20                                                                            ethernet-default                                                               only-hardware-queue                                                                   
20 ether21                                                                            ethernet-default                                                               only-hardware-queue                                                                   
21 ether22                                                                            ethernet-default                                                               only-hardware-queue                                                                   
22 ether23                                                                            ethernet-default                                                               only-hardware-queue                                                                   
23 ether24                                                                            ethernet-default                                                               only-hardware-queue                                                                   
24 sfp1                                                                               ethernet-default                                                               only-hardware-queue

Now it looks like this:

--- 10.10.1.2 ping statistics ---
21100 packets transmitted, 21100 received, 0% packet loss, time 21121ms
rtt min/avg/max/mdev = 0.036/0.041/0.133/0.009 ms

and

--- 10.10.1.2 ping statistics ---
20624 packets transmitted, 20624 received, 0% packet loss, time 20689ms
rtt min/avg/max/mdev = 0.067/0.075/0.329/0.017 ms

src · Sat Apr 04, 2015 12:34 pm

So now you have no packet loss? What shows your smokeping?

okoun · Sun Apr 05, 2015 8:48 pm

Hello and after the change queue is a LITTLE bit better, but it still errs more than a traditional L2 Tp-link switch.

k.png

src · Sun Apr 05, 2015 9:24 pm

You have packet loss between switched ports?

okoun · Sun Apr 05, 2015 9:45 pm

Yes, this is a device that goes through the switch

08000.png

Here's just clearly see that the switch slow, when in peak flows about 50-80Mb So it starts pretty packet loss. If I go over 100Mb so it's even worse, but we are talking about real data rather than simulated. If it is necessary to simulate BTEST and packet loss is not!

src · Sun Apr 05, 2015 10:26 pm

Hey, it's still not clear, what you mean by packet loss, because you said there is no packet loss on tp-link switch. So doing side-by-side comparison with l2 switch you're not using router functionality just a switching? If so, my CRS never had such problem with wire speed switching.

okoun · Sun Apr 05, 2015 10:49 pm

Not misunderstood.
I thought that when this switch CRS trade for TPlink switch and packet loss immediately disappear.
Otherwise, use the CRS switch in the mode of pure L2 switch, it means that I have a port configured as master everywhere. It should not be something else set in the switch box in WinBox?
Otherwise, even at CRS I switch running OSPF.

Fri Apr 17, 2015 9:27 am

Still not sure, but it looks to me like you are using switch for routing / bridging. If so, it explains why there are performance problems.

okoun · Mon Apr 20, 2015 10:21 pm

This is a bad idea. Previously, it was the place RB2011 which had a similar operation on it just ran out of ports and had to replace the CRS and there was not a problem!

Mon Apr 20, 2015 10:45 pm

2011 and CRS have different connection of ports to cpu. Therefore the difference in routing performance. But you should be able to reach 200 routed Mbits easily anyway. I would still suspect the main cpu to switch link internal processing queue for that. But it is only my opinion, nothing more.

Who is online