Community discussions

MikroTik App
 
jk100087
just joined
Topic Author
Posts: 4
Joined: Sun May 22, 2022 11:35 am

Switch port aggregation

Sun May 22, 2022 11:38 am

Hello,

I have a question about trunking protocol on CRS112-8P-4S-IN. It is said that  IEEE802.3ad and IEEE802.1ax compatible Link Aggregation Control Protocol is not supported yet. Up to 8 Trunk groups are supported with up to 8 Trunk member ports per Trunk group. So I assume there is different algorithm that decides, on witch line to send the data. Could you explain, how the choice is made. The problem is, I have set up the trunk line but it sees that traffic is not balanced on both lines between switches.

Please find the attached file with diagram of the setup: I have set up two servers on one switch. Ether ports and sfp ports are assigned to bridge with hw - yes. SFP9 and SFP10 are added to /interface ethernet switch trunk. Same configuration is set up on other switch. As Bridge (R)STP is not aware of underlying switch trunking configuration and some trunk ports can move to discarding or blocking state, I have set protocol-config on bridge - none. When I try to connect from PC1 to Server 1 and PC2 to Server2 and stream large amounts of data, I see that only sfp9 is being utilized. I am using Jumbo frames (9k) on switches. MTUs are set correct, there is no fragmentation of frames.

Am I missing something in config or that is not the case?
You do not have the required permissions to view the files attached to this post.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11485
Joined: Thu Mar 03, 2016 10:23 pm

Re: Switch port aggregation

Sun May 22, 2022 5:02 pm

The very same documentation shows appropriate bond configuration for bridge:
/interface bonding
add name=bonding1 slaves=ether2,ether3,ether4 mode=balance-xor transmit-hash-policy=layer-2-and-3 \
link-monitoring=mii mii-interval=100ms

So the mode is xor with transmit hash policy L2+L3. In essence this means that when all bond members are up (verify that this is the case), all traffic between a pair of hosts (src IP address, src MAC address, dst IP address and dst MAC address are constant for all traffic between them) will allways utilise the same physical link because all packets will have same hash value. As to the selection of which physical link ... transmitting device creates a hash and according to hash value determines the physical link to use. So it doesn't consider link utilization. And with 2 physical links in bond it's 50% chance that two pairs of hosts will use the same physical link. Even distribution can only be achieved with large number of communicating hosts (then statistics kicks in). If transmit hash policy was L3+L4, then the chance of distributing traffic between all physical links would be higher (port numbers do change between different connections), but CRS1xx doesn't seem to support it in hardware (doing it in software would drop performance to the floor).

You may want to read more about different bond modes in wikipedia article.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Switch port aggregation

Sun May 22, 2022 8:32 pm

I agree with @mkx...
Also, i want to add that indeed CRS1xx does not support neither 802.3ad nor xor in hardware...
According to the manual CRS3xx, CRS5xx series switches and CCR2116, CCR2216 support xor and 802.3ad bonding in hardware...
https://help.mikrotik.com/docs/display/ ... es-Bonding
 
jk100087
just joined
Topic Author
Posts: 4
Joined: Sun May 22, 2022 11:35 am

Re: Switch port aggregation

Wed May 25, 2022 3:25 pm

Thank you for the answer.
From documentation this method is used on separate RouterOS, I am looking at CRS1xx - from the same documentation:
/interface ethernet switch trunk
add name=trunk1 member-ports=ether6,ether7,ether8 
I assume this is the default method to make trunks with hardware offload, not over main CPU? Do both codes will give the same results? Or is it required for one switch to be configured in one way, the other in the other?
Also, is there a way I can check the hash value, the ports, MAC an IP are static in my case?
From mikrotik support - this method (trunk on ethernet/switch) uses L2 L3 L4 hash.
The very same documentation shows appropriate bond configuration for bridge:
/interface bonding
add name=bonding1 slaves=ether2,ether3,ether4 mode=balance-xor transmit-hash-policy=layer-2-and-3 \
link-monitoring=mii mii-interval=100ms

So the mode is xor with transmit hash policy L2+L3. In essence this means that when all bond members are up (verify that this is the case), all traffic between a pair of hosts (src IP address, src MAC address, dst IP address and dst MAC address are constant for all traffic between them) will allways utilise the same physical link because all packets will have same hash value. As to the selection of which physical link ... transmitting device creates a hash and according to hash value determines the physical link to use. So it doesn't consider link utilization. And with 2 physical links in bond it's 50% chance that two pairs of hosts will use the same physical link. Even distribution can only be achieved with large number of communicating hosts (then statistics kicks in). If transmit hash policy was L3+L4, then the chance of distributing traffic between all physical links would be higher (port numbers do change between different connections), but CRS1xx doesn't seem to support it in hardware (doing it in software would drop performance to the floor).

You may want to read more about different bond modes in wikipedia article.

Who is online

Users browsing this forum: Amazon [Bot], AnzUl, burnduck, gogle, mkx, Seekport [Bot] and 63 guests