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 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه