Community discussions

MikroTik App
 
jrestr29
just joined
Topic Author
Posts: 6
Joined: Mon Sep 05, 2022 7:04 am

Bonding interface as member of another Bonding ?

Sun May 21, 2023 2:24 am

Hello guys

I'm trying to figure out if the approach I'm going to explain its okay or if its there a better way of doing it or if this could lead to performance or unexpected issues.

I have a CCR1009 connected to a Cisco SG550X switch using a Bonding (2GE interfaces bonded on 802.3ad mode) , however the bandwidth requirements has increased in the last weeks so I need to put to work a 10Gbps SFP+ interface but still need to have some redundancy leaving the SFP+ as main interface but the CCR1009 only has 1 single SFP+ interface.

Initially was thinking about adding the SFP+ to the same bridge where the current bond its and share the tagged VLANs across both the SFP+ and the Bond interface however this doesn't work well, with all interfaces UP I have communication but once the SFP+ goes down it takes almost 1 minute to fallback to the Bond and once SFP+ is back it takes another minute to restore communication.

So I thought about having the current bond as slave in another bond interface having the SFP+ and Bond as slaves and using the mode active / backup with SFP+ being the primary. So far it works well and the link survives when any the SFP+ or slave bond interfaces goes down and then restores successfully when the interface is back but I'm not sure if this configuration could lead to any unexpected issue like ARP issues so any idea or recommendation for this approach will be highly appreciated

This is the configuration I'm testing:
/interface bonding
add mode=802.3ad name=ETH_bonding slaves=ether1,ether2 \
    transmit-hash-policy=layer-3-and-4

add mode=active-backup name=TRUNK_bonding primary=sfp-sfpplus1 slaves=sfp-sfpplus1,ETH_bonding
 
Fif
just joined
Posts: 3
Joined: Thu May 18, 2023 9:02 am

Re: Bonding interface as member of another Bonding ?

Tue May 23, 2023 9:25 pm

Not sure how well the stacked bonding setup would work, but that's certainly an interesting setup.

Coming back to your initial setup (802.3ad bond of all 3 interfaces):
Have you tried setting LACP rate to fast? You'll need to set that up on the other side of the bond as well.
/interface bonding
add mode=802.3ad lacp-rate=1sec name=ETH_bonding \
    slaves=sfp-sfpplus1,ether1,ether2 \
    transmit-hash-policy=layer-3-and-4 
 
tdw
Forum Guru
Forum Guru
Posts: 1841
Joined: Sat May 05, 2018 11:55 am

Re: Bonding interface as member of another Bonding ?

Wed May 24, 2023 12:52 am

Initially was thinking about adding the SFP+ to the same bridge where the current bond its and share the tagged VLANs across both the SFP+ and the Bond interface however this doesn't work well, with all interfaces UP I have communication but once the SFP+ goes down it takes almost 1 minute to fallback to the Bond and once SFP+ is back it takes another minute to restore communication.
What are you using to prevent L2 loops? If you use RSTP and set the path costs appropriately to favour the SFP+ failover should be near intantaneous. Note the Cisco proprietary PVST/PVST+ don't interoperate directly with RSTP so the Cisco should be configured accordingly.

I can't see a single bond of all three interfaces working well due to the dissimilar link speeds.

So I thought about having the current bond as slave in another bond interface having the SFP+ and Bond as slaves and using the mode active / backup with SFP+ being the primary. So far it works well and the link survives when any the SFP+ or slave bond interfaces goes down and then restores successfully when the interface is back but I'm not sure if this configuration could lead to any unexpected issue like ARP issues so any idea or recommendation for this approach will be highly appreciated
Uncharted territory. As this uses MII link status to check if the primary link is operational I can't see any obvious issues - the Mikrotik bridge FDB should be aware of all the local interface MAC addresses associated with the bond links in all states, I suspect it will be more down to how the Cisco handles nested aggregation links.

Who is online

Users browsing this forum: baragoon, FlowerShopGuy, Google [Bot], GoogleOther [Bot], onnyloh, rplant, Semrush [Bot] and 80 guests