Hands-On Lab: Configuring IP Floating Static Routes

This hands-on lab configures a floating static route with a higher administrative distance than an existing OSPF-learned route, demonstrating how it remains inactive as a backup until the primary route fails, then automatically takes over.

Floating Static RouteAdministrative Distance BackupAutomatic Failover

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

Lab Objective

Configure a floating static route as a backup to an existing OSPF-learned primary path, verify it remains unused while the primary route is active, then simulate a primary path failure and confirm the floating route automatically takes over.

Lab Purpose

A floating static route is a static route deliberately configured with a higher administrative distance than a preferred dynamic route, so it sits inactive in the background and is used only if the better route disappears — a simple, reliable backup mechanism that requires no complex protocol configuration.

Lab Topology

R1 ---- Gi0/0 (primary, OSPF) ---- R2
R1 ---- Serial0/0/1 (backup, floating static) ---- R2

R2's LAN reachable via OSPF through Gi0/0
in normal operation, distance 110

Task 1: Confirm the Primary OSPF Route Is Active

Assuming OSPF is already running between R1 and R2 (as configured in earlier labs), confirm R2's LAN is reachable via the OSPF-learned route through Gi0/0.

Task 2: Configure the Floating Static Route

Configure a static route to R2's LAN via the serial backup link, with an administrative distance higher than OSPF's default of 110.

Task 3: Verify the Floating Route Is Inactive

Confirm only the OSPF route appears in the routing table, with the floating static route not currently installed.

Task 4: Simulate a Primary Path Failure

Shut down R1's Gi0/0 interface to simulate the primary link failing.

Task 5: Verify Automatic Failover to the Floating Route

Confirm the floating static route now appears in the routing table and R2's LAN remains reachable via the backup path.

Solution and Verification

R1# show ip route 192.168.60.0

O    192.168.60.0/24 [110/2] via 10.1.1.2, GigabitEthernet0/0
-- Confirms the OSPF-learned route is currently
-- installed with its default distance of 110

R1(config)# ip route 192.168.60.0 255.255.255.0 10.2.2.2 150

-- The trailing "150" sets this static route's
-- administrative distance to 150, deliberately
-- worse than OSPF's 110, so it never competes
-- with the OSPF route while OSPF is available

R1# show ip route 192.168.60.0

O    192.168.60.0/24 [110/2] via 10.1.1.2, GigabitEthernet0/0
-- Only the OSPF route is installed -- the
-- floating static route exists in the
-- configuration but is not yet in the
-- routing table, since its higher distance
-- (150) makes it less preferred

R1(config)# interface gigabitethernet0/0
R1(config-if)# shutdown

R1# show ip route 192.168.60.0

S    192.168.60.0/24 [150/0] via 10.2.2.2
-- With the OSPF route gone (its interface
-- is down), the floating static route is
-- now the best available path and is
-- automatically installed -- no manual
-- intervention was required

R1# ping 192.168.60.1

!!!!!
Success rate is 100 percent (5/5)
-- Confirms R2's LAN remains reachable
-- through the backup serial link

Key Takeaway

A floating static route works purely through administrative distance comparison, discussed earlier in this series regarding route preference — no special protocol or additional configuration decides when to switch, only the standard rule that a lower administrative distance always wins whenever multiple sources offer a route to the same destination.

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

مقالات مرتبط

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.

ادامه