Juniper MC-LAG Best Practices: Configuration and Usage - 夜莺博客

Juniper MC-LAG Best Practices: Configuration and Usage

Multi-Chassis Link Aggregation (MC-LAG) on Juniper EX and QFX switches delivers active-active redundancy, but only when the design follows the vendor's usage notes. This article summarizes the official Juniper Networks MC-LAG best practices: keeping ARP and MAC tables synchronized with arp-l2-validate, avoiding DHCP server redundancy pitfalls on MC-LAG peers, choosing the right DHCP relay agent behavior, separating ICCP and ICL across different ports and FPCs, and understanding how the LACP system ID behaves in every ICCP failure scenario. It is the practical checklist you need before deploying MC-LAG in production.

ARP and MAC Synchronization

ARP and MAC address tables normally stay synchronized in MC-LAG configurations, but can get out of sync under conditions such as link flapping. To keep them in sync while the network stabilizes, enable the arp-l2-validate statement on IRB interfaces. This option validates ARP and MAC table entries and automatically applies updates when they drift apart. Note that it may impact performance in scale configurations, so it is recommended as a workaround during incidents rather than for permanent operation.

DHCP Design Constraints and Best Practice

Configuring the DHCP server directly on MC-LAG peers is not supported when DHCP service redundancy is required. DHCP relay with Option 82 is also not supported together with MAC address synchronization - if DHCP relay is required, configure VRRP over IRB or RVI for Layer 3 functionality instead.

In an MC-LAG active-active environment, Juniper recommends using the bootp relay agent:

set forwarding-options helpers bootp server 192.0.2.10
set forwarding-options helpers bootp interface irb.10

This avoids stale session information issues that can arise when the router uses the extended DHCP relay agent (jdhcp) process.

ICCP and ICL Design

Use separate ports and, where possible, different Flexible PIC Concentrators (FPCs) for the interchassis link (ICL) and the Inter-Chassis Control Protocol (ICCP) interfaces. An aggregated Ethernet interface is preferred for ICCP. Configure prefer-status-control-active together with the status-control standby configuration to prevent the LACP MC-AE system ID from reverting to the LACP default system ID during an ICCP failure. This option should only be used when ICCP will never go down unless the remote peer goes down.

Failure Handling Scenarios

The official usage notes document the ICCP failure behavior for QFX Series switches:

  • ICCP down, ICL down or up, backup liveness not configured: LACP system ID changes to the default value.
  • ICCP down, backup liveness Active: LACP system ID changes to default for both active and standby MC-AE interfaces.
  • ICCP down, backup liveness Inactive: no change in LACP system ID.
  • ICCP up, ICL down: LACP state moves to standby and the MUX state moves to the waiting state.

Backup Liveness Detection

Configure the master-only statement on the IP address of the management interface for backup liveness detection on both the primary and the backup MC-LAG peers, ensuring fast and deterministic failover behavior when ICCP connectivity is lost.

Related Reading

原文链接:https://www.juniper.net/documentation/us/en/software/junos/mc-lag/topics/concept/best-practices-usage-notes.html