Hands-On Lab: Configuring LACP Fast Rate

This hands-on lab configures LACPDU fast rate on an EtherChannel bundle, reducing the interval between LACP control packets to accelerate detection of a failed member link compared to the default slow rate.

LACP Fast RateLACPDU IntervalFaster Member Link Failure Detection

~3 min read · Updated Sep 23, 2026

Lab Objective

Configure LACP fast rate on an EtherChannel bundle's member interfaces, verify the reduced LACPDU interval takes effect, and compare the time to detect a failed member link against the default slow rate behavior.

Lab Purpose

LACP, discussed earlier in this series regarding EtherChannel negotiation, periodically exchanges control packets to confirm each member link remains healthy. The default interval is relatively slow, meaning a failed member link can take longer than necessary to be detected and removed from the bundle — LACP fast rate reduces this detection time significantly.

Lab Topology

Switch1 ---- Po1 (Gi1/0/1, Gi1/0/2) ---- Switch2

LACP already configured and bundle active,
as covered in an earlier lab

Task 1: Verify the Default LACP Rate

Confirm the current LACPDU interval on the bundle's member interfaces.

Task 2: Configure LACP Fast Rate

Enable LACP fast rate on both member interfaces on Switch1.

Task 3: Verify the New Rate Takes Effect

Confirm the LACPDU interval has changed accordingly.

Task 4: Simulate a Member Link Failure Under the Default Rate

Before applying fast rate on Switch2's side, simulate a link failure and time how long detection takes under the default slow rate.

Task 5: Apply Fast Rate on Switch2 and Repeat the Failure Test

Configure fast rate on Switch2 as well, then repeat the failure simulation and compare detection time.

Solution and Verification

Switch1# show lacp internal

Flags: S - Device is requesting Slow LACPDUs
Port      Flags  State  LACP port Priority
Gi1/0/1    SA     bndl   32768
Gi1/0/2    SA     bndl   32768
-- "S" confirms Slow LACPDUs are currently
-- being requested -- the default interval
-- of 30 seconds between LACP hellos

Switch1(config)# interface range gigabitethernet1/0/1-2
Switch1(config-if-range)# lacp rate fast

Switch1# show lacp internal

Flags: F - Device is requesting Fast LACPDUs
Port      Flags  State  LACP port Priority
Gi1/0/1    FA     bndl   32768
Gi1/0/2    FA     bndl   32768
-- "F" confirms fast rate is now active,
-- reducing the LACPDU interval from 30
-- seconds down to 1 second

-- With Switch2 still at the default slow
-- rate, simulating Gi1/0/1's link failure
-- (e.g., unplugging or shutting the port):

-- Detection and removal from the bundle
-- took up to approximately 90 seconds
-- (roughly three missed slow-rate intervals
-- before the peer is considered down),
-- since Switch2's side was still operating
-- on the default 30-second interval

Switch2(config)# interface range gigabitethernet1/0/1-2
Switch2(config-if-range)# lacp rate fast

-- Repeating the same link failure
-- simulation with fast rate now active
-- on both sides:

-- Detection and removal from the bundle
-- occurred within roughly 3 seconds
-- (three missed 1-second fast-rate
-- intervals), a dramatic improvement over
-- the default rate's detection time

Key Takeaway

LACP fast rate is configured independently on each side of a link, but both sides typically need it enabled to see the full benefit, since detection timing depends on the interval the LOCAL switch uses to expect hellos from its peer — configuring it only on one switch still leaves that switch waiting on the slower default timing from its neighbor's perspective, exactly as demonstrated by the intermediate test in this lab before Switch2 was updated.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring iBGP and the Full-Mesh Requirement

This hands-on lab configures iBGP among three routers within a single autonomous system, demonstrating the full-mesh peering requirement by deliberately omitting one peering relationship and observing the resulting route propagation failure.

Continue

Hands-On Lab: Configuring eBGP Between Two Autonomous Systems (CCNP Depth)

This hands-on lab configures eBGP between two routers in different autonomous systems with a full verification workflow, examining the BGP table, AS-path attribute, and confirming routes are correctly installed with eBGP's default administrative distance.

Continue

Hands-On Lab: Configuring Policy-Based Routing (PBR)

This hands-on lab configures Policy-Based Routing on a router to send traffic from a specific source subnet out a different path than the normal routing table would select, overriding the destination-based forwarding decision that every previous routing lab in this series relied on.

Continue

Hands-On Lab: Configuring Route Leaking Between VRFs

This hands-on lab configures selective route leaking between two VRFs using route targets and a shared services VRF, allowing specific routes to cross the otherwise strict isolation boundary established in the previous VRF-Lite lab.

Continue

Hands-On Lab: Configuring VRF-Lite

This hands-on lab configures VRF-Lite on a router to maintain two completely separate routing tables for two different customer networks sharing the same physical router, verifying each VRF's traffic remains isolated despite using overlapping IP address space.

Continue

Hands-On Lab: Configuring Layer 3 EtherChannel

This hands-on lab configures a routed EtherChannel between two Layer 3 switches, bundling two physical links into a single logical routed interface rather than a switched trunk, and verifies OSPF forms a single neighbor relationship across the bundle rather than one per physical link.

Continue