Hands-On Lab: Configuring Flex Links

This hands-on lab configures Flex Links between two uplinks on an access switch, providing sub-second failover without relying on Spanning Tree at all, and verifies traffic automatically shifts to the backup link when the primary fails.

Flex Links ConfigurationSTP-Independent RedundancyActive Backup Failover

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure two uplink ports on an access switch as a Flex Links pair, verify one becomes active while the other stays in standby without Spanning Tree blocking either, and confirm traffic automatically shifts to the backup link within roughly a second of the primary failing.

Lab Purpose

Spanning Tree, covered extensively earlier in this series, provides loop prevention but with convergence delays even in its fastest Rapid PVST+ form. Flex Links offers a simpler, STP-independent alternative specifically for the common case of a single access switch with two uplinks to the same or different upstream switches, trading STP's general-purpose flexibility for significantly faster, more predictable failover in this specific topology.

Lab Topology

AccessSwitch
  Gi1/0/23 ---- uplink to DistSwitch1 (primary)
  Gi1/0/24 ---- uplink to DistSwitch1 (backup)

Both uplinks connect to the same upstream
switch for this lab, though Flex Links also
supports uplinks to two different switches

Task 1: Configure the Flex Links Pair

Configure Gi1/0/23 as the active interface with Gi1/0/24 as its Flex Links backup.

Task 2: Verify the Flex Links Status

Confirm Gi1/0/23 shows as active/forwarding and Gi1/0/24 shows as standby, independent of any Spanning Tree state.

Task 3: Verify Gi1/0/24 Is Not Simply STP-Blocked

Confirm Gi1/0/24's standby state is a Flex Links function rather than a Spanning Tree blocking state.

Task 4: Simulate the Primary Uplink Failing

Shut down Gi1/0/23 and observe how quickly Gi1/0/24 takes over.

Task 5: Verify Traffic Resumes via the Backup Link

Confirm connectivity through the switch is restored via Gi1/0/24.

Solution and Verification

AccessSwitch(config)# interface gigabitethernet1/0/23
AccessSwitch(config-if)# switchport backup interface gigabitethernet1/0/24

-- This single command on the primary interface
-- establishes the entire Flex Links pair --
-- no configuration is needed on Gi1/0/24 itself

AccessSwitch# show interfaces switchport backup

Switch Backup Interface Pairs:

Active Interface        Backup Interface        State
------------------------------------------------------------------------
Gi1/0/23                 Gi1/0/24                Active Up/Backup Standby

AccessSwitch# show spanning-tree interface gigabitethernet1/0/24

Interface        Role Sts Cost
Gi1/0/24          Desg FWD 4
-- Notice STP itself considers this port
-- Designated/Forwarding -- Flex Links
-- operates as a completely separate
-- mechanism layered on top, independently
-- holding the port in standby regardless
-- of what STP's own state would otherwise
-- allow

AccessSwitch(config)# interface gigabitethernet1/0/23
AccessSwitch(config-if)# shutdown

AccessSwitch# show interfaces switchport backup

Active Interface        Backup Interface        State
------------------------------------------------------------------------
Gi1/0/23                 Gi1/0/24                Active Down/Backup Up
-- Gi1/0/24 activated almost immediately --
-- well under a second, since Flex Links
-- does not need to run any STP recalculation
-- or convergence process at all

DownstreamPC> ping [upstream gateway]

!!!!!
Success rate is 100 percent (5/5)
-- Connectivity confirmed restored through
-- Gi1/0/24

Key Takeaway

Flex Links operates entirely independently of Spanning Tree, as shown by Gi1/0/24 still displaying a Designated/Forwarding STP role even while genuinely held in standby by the Flex Links mechanism — this independence is precisely what allows failover far faster than any STP convergence process, but it also means Flex Links only handles this specific simple pair-of-uplinks scenario, unlike STP's general-purpose loop prevention across arbitrarily complex topologies.

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

مقالات مرتبط

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.

ادامه