The operation of MLAG feature requires two ExtremeXOS switches interconnected by an Inter-Switch connection (ISC).
The ISC is a normal, directly connected, Ethernet connection and it is recommended that you are using the link that is highly reliable, and has high bandwidth. Logically aggregate ports on each of the two switches by assigning MLAG identifiers (MLAG-ID). Ports with the same MLAG-ID are combined to form a single logical network connection.
Each MLAG can be comprised of a single link or a LAG on each switch. When an MLAG port is a LAG, the MLAG port state remains up until all ports in the LAG go down.
As long as at least one port in the LAG remains active, the MLAG port state remains active. When an MLAG port (a single port or all ports in a LAG) fails, any associated MAC FDB entries are moved to the ISC, forcing traffic destined to the MLAG to be handled by the MLAG peer switch. Additionally, the MLAG peer switch is notified of the failure and changes its ISC blocking filter to allow transmission to the MLAG peer port. In order to reduce failure convergence time, you can configure MLAG to use ACLs for redirecting traffic via the "fast" convergence-control option.
Each of the two switches maintains the MLAG state for each of the MLAG ports and communicates with each other to learn the MLAG states, MAC FDB entries, and IP multicast entries of the peer MLAG switch.
ISC Blocking Filters
The ISC blocking filters are used to prevent looping and optimize bandwidth utilization. When at least one MLAG peer port is active, the upper layer software initiates a block of traffic that ingresses the ISC port and needs to be forwarded to the local MLAG ports. This is considered to be the steady state condition. In normal steady state operation most network traffic does not traverse the ISC.
All unicast packets destined to MLAG ports are sent to the local MLAG port only. However, flood and multicast traffic will traverse the ISC but will be dropped from MLAG peer port transmission by the ISC blocking filter mechanism. The ISC blocking filter matches all Layer 2 traffic received on the ISC and blocks transmission to all MLAG ports that have MLAG peer ports in the active state.
When there are no active MLAG peer ports, the upper layer software initiates an unblocking of traffic that ingresses the ISC port and needs to be forwarded to the local MLAG ports thus providing redundancy. This is considered to be the failed state.
Inter-Switch Communication
Keep-alive Protocol
MLAG peers monitor the health of the ISC using a keep-alive protocol that periodically sends health check messages. The frequency of these health-check hellos is configurable. When the MLAG switch stops receiving health check messages from the peer, it could be because of the following reasons:
• Failure of the ISC link when the remote peer is still active.
• The remote peer went down.
[ example of keepalive message ]
Host: 01:03->15:36:36.875440 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:37.593004 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:37.855436 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:38.572920 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:38.835491 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:39.552928 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:39.815430 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:40.532843 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:40.795416 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:41.513039 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:41.775500 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:42.492826 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:42.755412 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:43.472909 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
Host: 01:03->15:36:43.735470 IP 1.1.1.6.53095 > 1.1.1.5.4000: UDP, length 32
Tx: 01:03->15:36:44.452933 IP 1.1.1.5.35239 > 1.1.1.6.4000: UDP, length 32
If the ISC link alone goes down when the remote peer is alive, both the MLAG peers forward the southbound traffic, resulting in duplication of traffic. However, this does not result in traffic loops. This is because the remote node load shares to both the MLAG peers and does not forward the traffic received on one of the load shared member ports to other member ports of the same load shared group.
Starting in ExtremeXOS 15.5, health check messages can also be exchanged on an alternate path by separate configuration – typically the “Mgmt” VLAN. If the peer is alive when the ISC link alone goes down, one of the MLAG peers disables its MLAG ports to prevent duplicate south-bound traffic to the remote node. To reduce the amount of traffic on the alternate path, health check messages are initiated on the alternate path only when the ISC link goes down. When the ISC link is up, no health check messages are exchanged on the alternate path.
When the MLAG switch misses 3 consecutive health check messages from the peer, it declares that the MLAG peer is not reachable on the ISC link. It then starts sending out health check messages on the alternate path to check if the peer is alive. When the first health check message is received from the MLAG peer on the alternate path, it means that the peer is alive. In this scenario, one of the MLAG peers disables its MLAG ports to prevent duplication of south-bound traffic to the remote node.
When the ISC link comes up and the switch starts receiving health check messages on the ISC control VLAN, the ports that were disabled earlier have to be re-enabled. This action is not performed immediately on the receipt of the first health check message on the ISC control VLAN. Instead the switch waits for 2 seconds before enabling the previously disabled ports. This is done to prevent frequent enabling and disabling of MLAG ports due to a faulty ISC link up event.
MLAG Status Checkpointing
Each switch sends its MLAG peer information about the configuration and status of MLAGs that are currently configured over the ISC link.
This information is checkpointed over a TCP connection that is established between the MLAG peers after the keep-alive protocol has been bootstrapped.
Authentication for Checkpoint Messages
The checkpoint messages exchanged between the MLAG peers over the TCP connection are sent in plain text and can be subjected to spoofing. Starting from EXOS 15.5 a provision is provided as part of this feature to secure the checkpoint connection against spoofing.
A key for authentication must be configured on both the MLAG peer switches. This key will be used in calculating the authentication digest for the TCP messages. TCP_MD5SIG socket option will be used for authentication and so only MD5 authentication is supported. The configured key will be used in setting up TCP_MD5SIG option on the checkpoint socket. The same key must be configured on both the MLAG peers. The checkpoint connection will not be established if different keys are configured on the MLAG peer switches.
No comments:
Post a Comment