Wireless Access

Can someone provide a document with details on how the controllers determine L2 vs L3 adjancy in a cluster.

We run OTV between 2 DC which provide L2 adj for our systems how ever our controllers flap between L2 & L3.  TAC told us there was a "special" MAC broadcast used by controllers but couldn't provide us any additional details.  We are trying to understand if we are preventing something on our OTV config or is there another issue. We have excluded all unnecessary vlans in cluster config.

------------------------------
Michael McSweeney
------------------------------

What is OTV?

Instead of using clustering, backup-lms should be used instead between two DCs.  Clusters were not designed to span DCs.

The layer 2 broadcasts occur on all of the VLANs not excluded in a cluster configuration.  If your controllers keep flapping between l2 and l3 it indicates packet loss or high latency.  If there was no connectivity, it would simply just be in l3 all of the time.  Excluding vlans removes diagnostic ability and should really only be done for VLANs that do not exist at both cluster members.
"show lc-cluster vlan-probe status" should tell  you which VLAN is failing probes.

  It is crucial that cluster members have very low latency and very little loss to properly execute fast failover.  If you don't have low latency and low loss, it is not sustainable to run a cluster between two DCs.  Controllers in a cluster should be physically or structurally co-located.  It is also a bad idea to stretch layer 2 VLANs between DCs for client connectivity.  If you have any issues with loss or latency, it can be maddening to troubleshoot and you should avoid that at all costs.


------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------

Thank you for the reply.

OTV = Overlay Transport Virtualization
Copied from Cisco Website, (Providing as a reference not a endorsement or recommendation of technology)
Overlay Transport Virtualization (OTV) on the Nexus 7000 is an industry-first technology that significantly simplifies extending Layer 2 applications across distributed data centers. You can now deploy Data Center Interconnect (DCI) between sites without changing or reconfiguring your existing network design.)

We have low latency links between our DC environments.

Is there any documentation on the l2 broadcast used between controllers?  Aruba TAC implied it used a "special" mac address for the broadcast, we are really just trying to understand the solution so we can determine the correct design for our environment.

We appreciate any information and the community members taking the time to help other community members.  

------------------------------
Michael McSweeney
------------------------------

Original Message:
Sent: Sep 14, 2021 05:17 AM
From: Colin Joseph
Subject: Cintroller Cluster L2 Discovery

What is OTV?

Instead of using clustering, backup-lms should be used instead between two DCs.  Clusters were not designed to span DCs.

The layer 2 broadcasts occur on all of the VLANs not excluded in a cluster configuration.  If your controllers keep flapping between l2 and l3 it indicates packet loss or high latency.  If there was no connectivity, it would simply just be in l3 all of the time.  Excluding vlans removes diagnostic ability and should really only be done for VLANs that do not exist at both cluster members.
"show lc-cluster vlan-probe status" should tell  you which VLAN is failing probes.

  It is crucial that cluster members have very low latency and very little loss to properly execute fast failover.  If you don't have low latency and low loss, it is not sustainable to run a cluster between two DCs.  Controllers in a cluster should be physically or structurally co-located.  It is also a bad idea to stretch layer 2 VLANs between DCs for client connectivity.  If you have any issues with loss or latency, it can be maddening to troubleshoot and you should avoid that at all costs.


------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------

It is an ethernet unicast from one controller to the next of type 0x88b5.  It is about 60 bytes.

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------

Original Message:
Sent: Sep 14, 2021 07:10 AM
From: Michael McSweeney
Subject: Cintroller Cluster L2 Discovery

Thank you for the reply.

OTV = Overlay Transport Virtualization
Copied from Cisco Website, (Providing as a reference not a endorsement or recommendation of technology)
Overlay Transport Virtualization (OTV) on the Nexus 7000 is an industry-first technology that significantly simplifies extending Layer 2 applications across distributed data centers. You can now deploy Data Center Interconnect (DCI) between sites without changing or reconfiguring your existing network design.)

We have low latency links between our DC environments.

Is there any documentation on the l2 broadcast used between controllers?  Aruba TAC implied it used a "special" mac address for the broadcast, we are really just trying to understand the solution so we can determine the correct design for our environment.

We appreciate any information and the community members taking the time to help other community members.  

------------------------------
Michael McSweeney
------------------------------


Original Message:
Sent: Sep 14, 2021 05:17 AM
From: Colin Joseph
Subject: Cintroller Cluster L2 Discovery

What is OTV?

Instead of using clustering, backup-lms should be used instead between two DCs.  Clusters were not designed to span DCs.

The layer 2 broadcasts occur on all of the VLANs not excluded in a cluster configuration.  If your controllers keep flapping between l2 and l3 it indicates packet loss or high latency.  If there was no connectivity, it would simply just be in l3 all of the time.  Excluding vlans removes diagnostic ability and should really only be done for VLANs that do not exist at both cluster members.
"show lc-cluster vlan-probe status" should tell  you which VLAN is failing probes.

  It is crucial that cluster members have very low latency and very little loss to properly execute fast failover.  If you don't have low latency and low loss, it is not sustainable to run a cluster between two DCs.  Controllers in a cluster should be physically or structurally co-located.  It is also a bad idea to stretch layer 2 VLANs between DCs for client connectivity.  If you have any issues with loss or latency, it can be maddening to troubleshoot and you should avoid that at all costs.


------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.