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?
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.