Ethernet Switches & Routers

Reply
Contributor
Posts: 23
Registered: ‎03-19-2013

MCT VLANs and non-MCT VLANs

Hello,

Attached you will find my diagram.....We have deployed MCT in Distribution layer and MCT in Acces Layer (in each POD).

My question and doubt is the difference with MCT VLANs and non-MCT VLANs.

MCT VLANS are vlans from clients that work together with the MCT right?

and non-MCT VLANs are just normal clients connected to the switches...correct?

Lets say I have two servers: One in LACP which I made cluster-client and configured its VLAN as a member-vlan of the MCT cluster

The other server has a "normal" "classic"  ACTIVE/STANDBY redundancy.....one link to each swithc...but only one is active.

SHOULD I configure the vlan from the active standby inside the cluster? Meaning...making the vlan as a member-vlan of the MCT cluster??????

OR should just be treated as a normal vlan????

I have this doubt because in the next level I have also MCT (in Distribution) or the MLX knows the difference and can forward both "types" of traffic without any problem???

Regards,

Ernesto

Frequent Contributor
Posts: 160
Registered: ‎08-07-2009

Re: MCT VLANs and non-MCT VLANs

Ernesto,

Let me do a little research on this and i will post some detail soon

-Bill

Contributor
Posts: 23
Registered: ‎03-19-2013

Re: MCT VLANs and non-MCT VLANs

I will appreciate that, thank you very much Bill!!

Frequent Contributor
Posts: 160
Registered: ‎08-07-2009

Re: MCT VLANs and non-MCT VLANs

Hi Ernesto,

Let me start by addressing your first 2 questions below.

"MCT VLANS are vlans from clients that work together with the MCT right?"

"non-MCT VLANs are just normal clients connected to the switches...correct?"

Assume two clients are not in the same VLAN
1.    Configure non-MCT VLANs by regular L2 VLAN configuration, and the ports are not MCT ports
2.    Configure MCT VLAN by L2 VLAN configuration plus member-vlan configuration in MCT submode.

Assume two clients are in the same VLAN.
3.    Must configure the VLAN as MCT member VLAN. but the topology may create L2 loop in non-MCT client which requires extra L2 protocol to make the topology as loop-free.
Per VLAN STP and per VLAN RSTP are the supported L2 protocols in this scenario.

This is somewhat of a strange setup.

Lets say I have two servers: One in LACP which I made cluster-client and configured its VLAN as a member-vlan of the MCT cluster

The other server has a "normal" "classic"  ACTIVE/STANDBY redundancy.....one link to each swithc...but only one is active.

SHOULD I configure the vlan from the active standby inside the cluster? Meaning...making the vlan as a member-vlan of the MCT cluster??????

OR should just be treated as a normal vlan????

I have this doubt because in the next level I have also MCT (in Distribution) or the MLX knows the difference and can forward both "types" of traffic without any problem???

As mentioned this is a strange use case.   What exactly is the use case here?  Why is it that you would want active-active for one client and

active-standby for another client, especially two clients are at same layer in terms of network role?

I've also attached an MCT Design and Best Practice doc that may provide some insight for you.

-Bill

Contributor
Posts: 23
Registered: ‎03-19-2013

Re: MCT VLANs and non-MCT VLANs

Hello Bill,

As mentioned this is a strange use case.   What exactly is the use case here?  Why is it that you would want active-active for one client and

active-standby for another client, especially two clients are at same layer in terms of network role?

Well, just because the customer decided that way, we always encourage customers to "form" or to "play along" with the MCT and we tell them they will have a better redundancy because it will be ACTIVE-ACTIVE. Sometimes (for whatever reason) they dont want and they configure their server as ACTIVE-STANDBY.

So the Active-Standby is what I call non-MCT-VLAN becase it will not be a client of the Multi-Chassis-Trunking

Lets say we have:

Server1: ACTIVE-ACTIVE   ------------ vlan 100            (LAG towards the MCT)

Server2: ACTIVE-STANDBY ---------- vlan 200            (Normal link towards both switches)

Which one is the correct configuration?

cluster POD1_MCT 300

rbridge-id 20

session-vlan 4090

member-vlan 100

member-vlan 200

icl ICL-MCT-Link ethernet 15/1

peer 10.191.253.41 rbridge-id 27 icl ICL-MCT-Link

  client-interfaces delay 30

deploy

client Server1

rbridge-id 100

client-interface ethernet 4/18

  deploy

------------------------------------------------------OR THIS

cluster POD1_MCT 300

rbridge-id 20

session-vlan 4090

member-vlan 100

icl ICL-MCT-Link ethernet 15/1

peer 10.191.253.41 rbridge-id 27 icl ICL-MCT-Link

  client-interfaces delay 30

deploy

client Server1

rbridge-id 100

client-interface ethernet 4/18

  deploy

--------------------------------------------------------------------------------------------

This would be the configuration for ACCESS layer, in DISTRIBUTION I am running also MCT

So the question is:

VLAN 200 should be member-vlan of the cluster...or NOT?????

So far no one has given me the same answer...my SE says it should be a member in order to go up to DISTRIBUTION Layer.......TAC Engieneer says it should not be member from the cluster.

I am trying to make clear this part because I am having a lot of flaps in ALL my POD's....and I think this can be the reason....I've read all the documentation about MCT (IP Primer, NetIron guide, Best practices, Reference Architecture, White papers) but no one has an example like mine,

I hope you can give me your opinion Bill.

Thanks,

Ernesto

Broadcom
Posts: 18
Registered: ‎08-11-2012

Re: MCT VLANs and non-MCT VLANs

 
Broadcom
Posts: 18
Registered: ‎08-11-2012

Re: MCT VLANs and non-MCT VLANs

There does not seem to be a CLI knob for specifying "member vlan." Am I missing something here?

 

telnet@SWD_48F_1(config-cluster-SWD)#
  clear                         Clear table/statistics/keys
  client                        Define the cluster client properties
  client-auto-detect            Cluster Client Automatic Detection
  client-interfaces             Define common properties for all client
                                interfaces
  client-isolation              Define isolation mode for all clients
  deploy                        Deploy the cluster
  end                           End Configuration level and go to Privileged
                                level
  exit                          Exit current level
  icl                           Define the inter chassis link properties
  keep-alive-vlan               Assign a Keep-Alive VLAN to the Cluster
  no                            Undo/disable commands
  peer                          Define the cluster peer information
  quit                          Exit to User level
  rbridge-id                    Local rbridge id of the Cluster
  session-vlan                  Assign a session vlan for cluster management
  show                          Show system information
  write                         Write running configuration to flash or terminal
  <cr>
telnet@SWD_48F_1(config-cluster-SWD)#

Frequent Visitor
Posts: 1
Registered: ‎01-04-2013

Re: MCT VLANs and non-MCT VLANs


leel wrote:

There does not seem to be a CLI knob for specifying "member vlan." Am I missing something here?


I'm not sure if you figured this question out but I racked my brain on it for awhile. To spare the next person, I will post what I found about this question. 

 

The solution is to tag the primary LAG port between your two MCT devices on all your client vlans. 

 

In the example provided here: http://community.brocade.com/t5/Ethernet-Switches-Routers/Brocade-NetIron-Multi-Chassis-Trunking-MCT-comparable-to-VSS-VPC/ta-p/2087 

you can see that the ports under the "ICL" dynamic id 1 lag are tagged in every VLAN. 

 

the reason this matters is:

"

  • MCT VLAN: Serves the customer data traffic. An ICL must belong to every MCT VLAN to provide a data path between two cluster devices. When an ICL is added to a VLAN, it becomes an MCT VLAN." -Layer 2 Switching Configuration Guide

-Hope I'm correct in saying all this and that it helps the next person.

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.

vADC is now Pulse Secure
Download FREE NVMe eBook