CCNA – Static Host Route

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 10.1.1.0/24 subnet, and the other to the 172.16.2.0/24 subnet. These PC’s are Labled as PC4 (10.1.1.3) and PC5 (172.16.2.3). 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 172.16.2.3. 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 172.16.2.3 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 172.16.2.0/24 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 172.16.2.3 we see that the route is not in the table. The CEF output confirms this as well indicating no via 0.0.0.0 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 172.16.2.3 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 172.16.2.2 and 172.16.2.3 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 172.16.2.0/24 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.

R1

R2

R3

R4