2x 6024 interconnected with lacp; both connected with one port using lacp to 5448

LACP LAGs need to be a one to one connection. The LACP LAG cannot have it's connections split off and going to different independent devices. This means that each of the 6024 switches will need to have a separate LAG configured on the 5448. They would not be able to share the same LAG on the 5448.

Bond mode 4 should have each team connecting to the same switch. The switches are independent from one another. The first 6024 doesn't know how the second one is configured.

The team configuration on the server should look more like this:

Team 1 = Nic1, Nic2
Team 2 = Nic3, Nic4

Team 1 connects to port channel on switch 1.
Team 2 connects to port channel on switch 2.

If you have multiple ports connect the 5448 to each of the 6024s, you can use link aggregation on those ports.The 5448 would have two LAGs created. One LAG for switch 1, and a separate LAG for switch 2. Each of the 6024 switches would then need a single LAG configured on them for their connection to the 5448. 

Based on the description you have outlined, it sounds like there will be loops in this network. Be prepared to see connections going into a blocking state. To get the desired results of which interfaces are blocking, and which are not, you may need to manually assign values to each switch/ports. The switch with the lower priority globally set will become the root switch on the network. Generally the root switch is also your core switch. If two connections are creating a loop, the connection with the lower priority will be more favorable.

page 277 of the user guide covers spanning tree configuration on the 6024.

http://dell.to/2bewSSH

Hi,

There is no loop and connections are not blocked as far as I can see.

It's a vrrp setup which works quite well like this.


What you say, I use LAG, sorry, but a LAG requires an LACP, so I use one port (single connection) per LAG/LACP to the 5448 which has the same LAG-id. I see that one port or on the 5448 is in Non-Candidate mode tho so I wonder why that happens and what actually happens.

console# sh interfaces port-channel

Load balancing: Layer 2.

Gathering information...
Channel  Ports
-------  -----
ch1      Active: g40 Non-candidate: g39 <- is a server with one port down so don't worry
ch2
ch3
ch4
ch5
ch6      Active: g45 Non-candidate: g46 <- are the two 6024's
ch7
ch8
console#

When I connect a server, or a NAS with an LACP (same ID on both switches) to both 6024 the traffic is going fine, this becasue, in my opinion, each connection is just one connection to one switch, so it won't loop back and otherwise it would not matter also as it's just traffic from a -> b -> c -> d


This are two scenarios, do you agree on the server/nas idea ?

OK, this is a nice layout, thanks for that!

The reason I most of the time use LACP's by default on some links is because I can extend then more easy later on.

There is a direct LACP (2links) between the two 6024's so I was thinking if you split an LACP from a server/nas between the two 6024's something about that groupID should be communicated between the two.

I agree on ideal, but if it's logic it could not messup because of Spanning-Tree it might be a good idea to do this.

Link aggregation does not require that you use LACP. You can also create a static LAG on the switches.

channel-group 1 mode on = static LAG
channel-group 1 mode auto = LACP LAG

The non-candidate mode is cause because the single LAG is being split to separate devices. I am not certain why the server LAG is working while the LAG is split, but it is not ideal. The 6024 switches do not know how the other switch is configured. It does not matter that the port channels are the same number, this holds no relevance. You could use port channel 7 on one switch to connect to port channel 8 on the second switch.

On the 5448, port channel 6 needs to have both g45 and g46 connect to the same switch. This results in 3 LAGs being created on the 5448. 1st LAG for 6024-1, 2nd LAG for 6024-2, and a 3rd LAG for the server connection.

If there is only going to be one port used for connecting the 5448 to the 6024 switches, g45 to 6024-1 and g46 to 6024-2, then there is no need to use a LAG.

Have you had a look at the spanning tree port statuses on the 6024 switches? Splitting a port channel across two separate devices is not a workaround to spanning tree. When creating a physical loop in the network for redundancy, spanning tree needs to be anticipated and prepared for. 

Hi yes, I did, all are forwarding and non blocking state.

Would you like to see some output ?

No need to post the output, just something to keep an eye on as you work with physical loops in the network.

Thanks a lot catching up on this. I already checked that out and good that you mention it again. I had such setup running earlier (for some years) and wanted to check again.

SO Loops would be always, or should be discovered by the switch in such cases ? I saw this earlier on some different setup happening and checked it all out why it happens, it's kinda a nice solution Spanning Tree.

Spanning tree is design to help ensure that loops are not created on the network. In a scenario where you are able to look at your network topology and see that there is going to be a loop. It is then a good idea to preemptively assign priorities, resulting in control of which ports are blocking. In a scenario where you see no physical loops in the topology, port priorities can be left alone. Spanning tree will then be used to prevent any unexpected/unknown loops.

Superb, thanks for your clear view and explanation, as always!

I wanted to update this to make the topic complete.

As known it could happen it didn't work out and it doesn't. Switches don't complain, no STP blocking, all fine but you keep a flapping mac-address with split lag/lacp.

It's good to test this 200% tho to see what happens and you can tackle things down later when you have a network with issues.

Thanks to :)