cancel
Showing results for 
Search instead for 
Did you mean: 

Important to MLAG using all unique ethernet port numbers on each MLAG peer switch?

Important to MLAG using all unique ethernet port numbers on each MLAG peer switch?

David_Nelson
New Contributor III

Hi All,

I am setting up a pair of EXOS switches as MLAG peers to provide redundant connectivity to stacked switches in our IDF closets.

 I have been referencing the EXOS User Guide along with some other GTAC articles. In one titled, “

Key Design Points of an EXOS Multi-LAG” (https://extremeportal.force.com/ExtrArticleDetail?an=000064510)

 

About 8 bullet points down under the heading, “The key MLAG design points are:” I find this statement:

To avoid underlying port# duplication on the LAG from the perspective of the connected upstream server/switch, it is important to MLAG using all unique Ethernet port numbers on each MLAG peer switch.

 

I am wondering how important is this? I have only found it mentioned in this one article, and have setup a few switches as MLAG peers now and they seem to be working fine, so I have to wonder.

 

Anyhow if this is true and needs to be observed I am correct in interpreting this to mean that instead of using MLAG-Peer-A Port 1, and MLAG-Peer-B Port 1 as my MLAG ports to connect an IDF switch, that I must mix these up and Ports 1 and 2 on the respective MLAG peer switches?

 

Thank you!

David

 

1 ACCEPTED SOLUTION

Chris_H
Extreme Employee

Hello,

 

First of all, I agree that the comment in the first article the different port numbering was quite confusing (even to me), so I have removed this from the article, as - as already mentioned earlier - it’s not necessary to use different ports.

Rather the opposite even. Using the same ports makes configuration much more simpler, i.e. when using “orchestration” (the simultaneous configuration of both MLAG peers). Also troubleshooting would be quite painful when the ports on the MLAG peers are different.

I also corrected some other small points, but left majority of the article as it was. 

 

In regards to the second article, when it comes to STP on the MLAG ports, the MLAG peers determine between each other which one is considered the “STP master” and only this switch will send the STP BPDU’s out the MLAG ports, as otherwise the connected device would receive the BDPU’s twice - once from each MLAG peer, and this is obviously not wanted.


The way they determine who’s said “STP master” is based on the MLAG indices and can be different per MLAG port. One MLAG peer will handle all the odd indices and the other the even ones.
Let’s say for example, you’re having 6 switches you want to connect via MLAG and are therefore using 6 MLAG ports with MLAG indices 101,102,103,104, 105 and 106, then one MLAG peer will send out the STP BPDU’s on the MLAG ports that are configured for indices 101,103 and 105, and the other MLAG peer will send them out on the ports configured for indices 102, 104 and 106.  

Let’s say you have one of the MLAG peers acting as a root bridge for an STP domain and you want the switches connected to all 6 MLAG ports to participate in STP, then you may want this root-bridge-MLAG peer to send out the BPDU’s to all of the MLAG ports. To achieve this you would have to use either only odd or even MLAG indices (so i.e. 101,103,105,107, 109 and 111 OR 100,102,104,106, 108 and 110 if we stick with the “6 MLAG ports” example), as this would mean that the same MLAG peer is the “STP master”. 

The mentioned “unpredictable convergence behavior” (and that’s why it’s mentioned that it’s a “best practice”) is that if the MLAG-STP mastership is shared between the two MLAG peer switches, in case of a reboot of one of them, half of the connected switches/devices would receive an STP TC, while the other half doesn’t. 

 

I hope this helped clear this up a bit.

 

Chris

View solution in original post

6 REPLIES 6

Chris_H
Extreme Employee

Hello,

 

First of all, I agree that the comment in the first article the different port numbering was quite confusing (even to me), so I have removed this from the article, as - as already mentioned earlier - it’s not necessary to use different ports.

Rather the opposite even. Using the same ports makes configuration much more simpler, i.e. when using “orchestration” (the simultaneous configuration of both MLAG peers). Also troubleshooting would be quite painful when the ports on the MLAG peers are different.

I also corrected some other small points, but left majority of the article as it was. 

 

In regards to the second article, when it comes to STP on the MLAG ports, the MLAG peers determine between each other which one is considered the “STP master” and only this switch will send the STP BPDU’s out the MLAG ports, as otherwise the connected device would receive the BDPU’s twice - once from each MLAG peer, and this is obviously not wanted.


The way they determine who’s said “STP master” is based on the MLAG indices and can be different per MLAG port. One MLAG peer will handle all the odd indices and the other the even ones.
Let’s say for example, you’re having 6 switches you want to connect via MLAG and are therefore using 6 MLAG ports with MLAG indices 101,102,103,104, 105 and 106, then one MLAG peer will send out the STP BPDU’s on the MLAG ports that are configured for indices 101,103 and 105, and the other MLAG peer will send them out on the ports configured for indices 102, 104 and 106.  

Let’s say you have one of the MLAG peers acting as a root bridge for an STP domain and you want the switches connected to all 6 MLAG ports to participate in STP, then you may want this root-bridge-MLAG peer to send out the BPDU’s to all of the MLAG ports. To achieve this you would have to use either only odd or even MLAG indices (so i.e. 101,103,105,107, 109 and 111 OR 100,102,104,106, 108 and 110 if we stick with the “6 MLAG ports” example), as this would mean that the same MLAG peer is the “STP master”. 

The mentioned “unpredictable convergence behavior” (and that’s why it’s mentioned that it’s a “best practice”) is that if the MLAG-STP mastership is shared between the two MLAG peer switches, in case of a reboot of one of them, half of the connected switches/devices would receive an STP TC, while the other half doesn’t. 

 

I hope this helped clear this up a bit.

 

Chris

Miguel-Angel_RO
Valued Contributor II

Stephan’s,

 

We can use the ports we want but the MLAG id’s used in the following command should all be odd or even:

enable mlag port <master-port> peer <peer-name> id <MLAG id>

If not, there could be some undocumented behaviour.

Mig

StephanH
Valued Contributor III

Hello,

both GTAC articles leave room for interpretation as to whether the MLAG ID or the port is involved.

Up to now I have always used the same port on both switches in an MLAG. So far without problems. 
 

Regards Stephan

Stefan_K_
Valued Contributor

Hi Mig,

do they really mean the MLAG ID, when they say “mlag index ports“?

“As the attached switch is expecting only 1 switch on its LAG uplink MLAG uses a special method to have only 1 MLAG switch sending STP BPDU's.
One MLAG switch that owns the even mlag index ports will send BPUD's for these, the one that owns the odd mlag index ports will send BPDU;s for those.“

This would mean that there are different MLAG IDs configured on the MLAG Peers - how would that even work?

GTM-P2G8KFN