Hands-On Lab: Configuring Static Routing via IP Addresses

This hands-on lab configures static routes using a next-hop IP address rather than an outgoing interface, the generally preferred syntax, and compares the resulting routing table entry against the interface-based approach from the previous lab.

Static Route Next-Hop SyntaxRecursive Route LookupRouting Table Comparison

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

Lab Objective

Configure static routes on two routers using next-hop IP addresses rather than outgoing interfaces, verify connectivity, and compare the resulting routing table format against the interface-based method from the previous lab.

Lab Purpose

Next-hop-based static routes are the generally preferred syntax for most scenarios, since they avoid the excessive ARP overhead that interface-based routes can cause on multi-access networks, discussed in the previous lab. Understanding exactly how this method appears in the routing table is essential for correctly reading real-world configurations.

Lab Topology

R1 ---- Serial0/0/0 ------ Serial0/0/0 ---- R2

R1: 10.21.21.1/30, LAN 192.168.11.0/24 (Loopback1)
R2: 10.21.21.2/30, LAN 192.168.21.0/24 (Loopback1)

Task 1: Configure Basic Addressing

Configure the serial interfaces and a loopback on each router representing its local LAN.

Task 2: Configure a Static Route Using a Next-Hop Address on R1

On R1, configure a static route to R2's LAN using R2's serial interface IP address as the next hop.

Task 3: Configure the Equivalent Route on R2

On R2, configure a static route to R1's LAN using R1's serial interface IP address as the next hop.

Task 4: Verify Connectivity

Confirm R1 can reach R2's LAN and vice versa.

Task 5: Compare the Routing Table Entry Format

Examine how this route appears in the routing table, contrasting it with the "directly connected" format seen in the previous lab's interface-based route.

Solution and Verification

R1(config)# interface serial0/0/0
R1(config-if)# ip address 10.21.21.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface loopback1
R1(config-if)# ip address 192.168.11.1 255.255.255.0

R2(config)# interface serial0/0/0
R2(config-if)# ip address 10.21.21.2 255.255.255.252
R2(config-if)# clock rate 64000
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# interface loopback1
R2(config-if)# ip address 192.168.21.1 255.255.255.0

R1(config)# ip route 192.168.21.0 255.255.255.0 10.21.21.2

-- The next-hop IP address (10.21.21.2, R2's
-- serial interface) is specified instead of
-- R1's own outgoing interface name

R2(config)# ip route 192.168.11.0 255.255.255.0 10.21.21.1

R1# ping 192.168.21.1

!!!!!
Success rate is 100 percent (5/5)

R1# show ip route static

S    192.168.21.0/24 [1/0] via 10.21.21.2
-- Notice the route now explicitly shows
-- "via 10.21.21.2" along with the administrative
-- distance/metric pair [1/0] -- a clear contrast
-- with the "directly connected" phrasing the
-- interface-based route showed in the previous lab

Key Takeaway

A next-hop-based static route requires the router to perform a recursive lookup: it must first determine which local interface can actually reach that next-hop address before it can forward traffic, whereas an interface-based route skips this step entirely. This recursive lookup is a small amount of extra processing, but it is exactly what avoids the excessive per-destination ARP behavior that makes interface-based routes problematic on multi-access networks.

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

مقالات مرتبط

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.

ادامه