Community discussions

MikroTik App
 
User avatar
clambert
Member Candidate
Member Candidate
Topic Author
Posts: 120
Joined: Wed Jun 12, 2019 5:04 am

Uneven MPLS traffic between CPUs

Sat Mar 04, 2023 5:39 am

Hi everyone, we are seeing a particular behavior with incoming MPLS (L3VPN) traffic on the RB1100AHx4 and CCR2004-1G-12S+2XS running ROSv6 (6.48.6 long-term). In both devices the incoming traffic is completely handled by CPU 0.

In the CCR2004 we have discovered that if the MPLS interface is a VLAN interface, then the traffic is evenly balanced between CPU 0 and CPU 2 (in the RB1100 it does not make any difference).

Has anyone experienced this behaviour? And if that were the case, have you been able to solve it somehow?
 
User avatar
clambert
Member Candidate
Member Candidate
Topic Author
Posts: 120
Joined: Wed Jun 12, 2019 5:04 am

Re: Uneven MPLS traffic between CPUs

Wed Mar 22, 2023 1:06 pm

Looking for information that can help us understand why this behavior occurs we have found the following information:
Flow/Packet steering
● RouterOS uses Receive Flow/Packet steering to assign incoming traffic to a specific CPU core/thread, based on the hash value.
● The hashing process can be:
– Hard-coded in the hardware.
– Configurable in the hardware.
– Implemented in the interface driver.
● Receive flow/packet steering will try to keep single TCP stream bound to single CPU core/thread as long as possible.
Reviewing the IRQ behavior in a RB1100AHx4 it is verified that the imbalance in the CPU cores comes from the traffic sent from the Realtek RTL8367 Gibabit Switch. The traffic received on channel 0 (we understand that it is associated with CPU0) is two orders of magnitude greater than that received on the three remaining channels.
/system resource irq print
 4 ro 128 al-eth-switch0-0-rx-0          auto            3 171 711 696
 5 ro 129 al-eth-switch0-0-rx-1          auto               31 839 251
 6 ro 130 al-eth-switch0-0-rx-2          auto               17 488 979
 7 ro 131 al-eth-switch0-0-rx-3          auto               18 862 440
We believe the limitation is that RTL8367 in not able to distinguish the MPLS header and effectively hash it to send traffic to the CPU in a balanced way.

Who is online

Users browsing this forum: No registered users and 16 guests