CCNA – Static Host Route

This lab will cover the topic 3.8.c Host Route from the Cisco Certified Network Associate (CCNA) blueprint. It will test your understanding and knowledge of configure static host routes on Cisco IOS devices. Please use the initial configurations as a template for your lab utilizing whatever console means you have (GNS, Physical Gear, VIRL, etc).


This lab is a continuation of our Static Network Route lab. We will use the ending topology and results to continue our practice with Static Host Routes. Two additional PC’s have been added. Once to the subnet, and the other to the subnet. These PC’s are Labled as PC4 ( and PC5 ( Our job in this lab is to force traffic from PC4 to PC5 to travel over the R1 -> R4 -> R3 path while traffic to the other PC’s in those subnets continue to travel over the previous path of R1 -> R2 -> R3.

Starting out we will ping our new destination at We notice that the path taken
is as expected and goes from R1 -> R2 -> R3

If we look at the routing table and CEF table we can confirm that this is indeed taking the right path as far as the routers are concerned.

Our goal in this lab is to send traffic to our specifc host, in this case in a different direction than our normal traffic in that same subnet. To do this we will enter a static host route into R1’s routing table.

This happens due to the host route being a /32 route vs the normal route for being only a 24 bit mask. This only solves our issue on R1 though. We need to continue up the desired path and verify R4’s configuration. Using show ip route with a specific address of we see that the route is not in the table. The CEF output confirms this as well indicating no via and no valid route adjacency.

To correct this we will add a static host route on R4 pointing towards the next hop up towards our destination. In this case that is R3.

We can now verify our previous output by re-issuing the show ip route and show ip cef commands with the speciic address. Note that the route now exists and the CEF table has an appropriate destination.

If we pause here and think about the return traffic we would want to check to make sure R4 also has a route back to our new source PC. Lets add that route and then verify the routing table.

Now it’s time to look at R3. If we look at this case the router does have routes for the destination. However, we are matching the /24 subnet and not the specifc host. This is sending traffic our the wrong direction towards R2. We can fix this by adding a host route back towards R3 fo

Now we will confirm out traffic between our two new hosts is taking the appropriate path towards each other over the R1 -> R4 – > R3 path. We will traceroute towards the and hosts and compare the routes taken.

Looking at this output we can confirm the two new hosts are taking the desired path while all other traffic to the subnet takes the old path. There is a caveat to our solution that you should keep in mind. Traffic source from PC1 to our new destination of PC5 will take one path. While traffic sources from PC5 back to PC1 will take another. This is due to the static routing we have configured causing traffic to go different directions for different destinations on the same subnet.





Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.

Permanent link to this article: