I85PREP
⌘ K
JNCIS-SP study materials
JNCIS-SP study resources

Dual-Homed Access Switch, STP Root, LAG and a Reload

JNCIS-SP · Put your knowledge to work in context.

All case studies

Dual-Homed Access Switch, STP Root, LAG and a Reload

A metro Ethernet edge uses two aggregation switches, AGG-1 and AGG-2, joined by a 2 x 10G bundle, each with one 10G link to access switch ACC-1. ACC-1 carries VLANs 100, 200 and 300 on a trunk to both AGGs. The customer runs its own STP domain behind ACC-1 with about 300 MAC addresses. AGG-1 was the STP root by default priority. After AGG-1 was reloaded for a software upgrade, VLAN 200 lost connectivity for 38 seconds and the bundle between AGG-1 and AGG-2 flapped three times. The customer also reports that a broadcast storm in VLAN 300 took down all three VLANs.

1. Explain the 38-second outage on VLAN 200 during the AGG-1 reload and recommend how the L2 topology should be built so that a single switch reload is not a service event.

Read the worked answer

Why 38 seconds. AGG-1 was root only because of the default bridge priority. When it reloaded, root election moved to AGG-2, which forces a full spanning-tree recalculation on every VLAN in the topology, plus a MAC flush of the 300 customer addresses and relearning of the customer's own STP domain behind ACC-1. 38 seconds is consistent with classic 802.1D timers (max age 20 s + listening 15 s + learning 15 s) rather than RSTP, where the same event is sub-second.

What to build instead.

  1. Make root deterministic. Set AGG-1 as root for the VLANs you want active on AGG-1 with an explicit priority (for example 4096) and AGG-2 as secondary (8192). Never leave root to the default priority - every switch in the network then has the same claim.
  2. Run RSTP (or MSTP with explicit instance-to-VLAN mapping) so a root change is a fast transition, not a timer run-out. Verify with show spanning-tree bridge and show spanning-tree interface.
  3. Dual-homed access with two independent links means one of them is blocked by STP. That blocked link is your 38-second window. Either accept it and make failover fast with RSTP, or use a real multi-chassis LAG between AGG-1 and AGG-2 so ACC-1 has one logical bundle and no STP blocking at all.
  4. The customer's own STP domain behind ACC-1 must not be allowed to influence your topology: put BPDU guard or loop protection on the customer-facing ports, and do not let customer BPDUs reach AGG-1's root election.

2. The aggregate bundle between AGG-1 and AGG-2 flapped three times during the reload. What does that tell you about the bundle design, and what would you change?

Read the worked answer

Interpretation. A bundle that flaps during a reload of one of its members is normally telling you that the bundle is being brought up before the member links are stable, or that LACP is negotiating repeatedly because only one side is up. Three flaps is not random; it is a restart interaction.

Things to check and change:

  1. LACP mode and timers. Use active LACP on both sides with fast timers if carrier-grade failover is required (lacp periodic fast). A one-sided or passive/static bundle gives you no protection against a member link that passes traffic but should not be in the bundle.
  2. minimum-links. Set minimum-links 1 (or higher, per capacity requirement) so the bundle does not bounce the whole logical interface while members are still coming up after a reload.
  3. LACP system priority and member link ordering. Ensure both AGGs agree on system priority so the same side is always the actor and the bundle does not renegotiate on every reload.
  4. Member link preemption/post-reload behaviour. If a link was added back after the reload, the bundle should reconverge by adding a member, not by tearing down and rebuilding.
  5. Do not confuse this with multi-chassis. A LAG between two separate aggregation switches is not a multi-chassis LAG; if ACC-1 is dual-homed to AGG-1 and AGG-2 without MC-LAG, the access switch sees two independent STP links, and the LAG between the AGGs is just an STP topology link. The design intent needs to be clear before tuning timers.

Validate with show lacp interfaces and show interfaces ae0 across the reload, not afterwards.

3. A broadcast storm in VLAN 300 took down VLANs 100 and 200 as well. Explain the mechanism and how to contain it, including what to check on the aggregation switches.

Read the worked answer

Mechanism. A broadcast storm on a trunk consumes the shared link capacity and the shared switch CPU, and because VLANs 100, 200 and 300 all traverse the same trunk and the same bundle, VLAN 300's storm starves the other two. If the storm is caused by a loop, it also drives the root's MAC table toward capacity and can trigger repeated topology changes, which flushes the other VLANs' forwarding entries.

Containment.

  1. Per-VLAN storm control on the customer-facing ports, set high enough not to trip on normal broadcast, low enough to protect the trunk:
set switch-options interface ge-0/0/1 storm-control broadcast level 5
  1. Loop protection / BPDU guard on all customer-facing edge ports. A customer looping their own access port is the common trigger, and the edge port should be shut rather than allowed to enter the topology.
  2. Separate STP instances per VLAN (MSTP) so that a topology change in one instance does not force recalculation in all three. With a single instance, VLAN 300's problem is definitionally VLAN 100's problem.
  3. Check on the AGGs. show ethernet-switching table for an abnormal MAC count, show spanning-tree interface for a port in an unexpected forwarding state, and interface input/output rates on the trunk to confirm which VLAN is driving the load. Look for the same source MAC appearing on both AGG uplinks, which indicates a loop rather than genuine broadcast.
  4. Confirm the customer's own switch behind ACC-1 is not passing BPDUs upstream; if it is, the customer's root can become your root.