CCNA – Static Network Route

This lab will cover the topic 3.8.b Network Route from the Cisco Certified Network Associate (CCNA) blueprint. It will test your understanding and knowledge of configure static network 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 has two PCs residing in different subnets. PC 1 is in the subnet. PC2 is in the subnet. PC3 is in the subnet. The core routers know how to get to all of the links between them, however, they DO NOT know how to get to the PC subnets. You’re goal in this lab is to get traffic flowing between PC1s subnet and PC2s subnet utizling your knowledge of static routing. To make this lab more interesting there is a specific traffic flow that must be achieved. The path PC1 takes to reach PC2 and PC3 must go over Router 2.

Start out by checkineg the routing table of R1, PC1’s point of entry into the network.

Here we notive that the router does not know any route towards the other destinations. We know that PC1 most go through R2 in order to reach either PC2 or PC3 based on our directions above. This indicates that we can create a static route towards both the and subnets and point it towards R2.

Now we have to look from R2 point of view. In order for R2 to forward traffic to either PC2 or PC3 it will need to send packets destined to the subnets towards it’s next hop. In this case, it’s next hop is R3. We will add those routes now.

At this point it may be believe that we can now get to these destinations by pinging from the PC1 to PC2 and PC3 since we have added the proper routes. While this is true, we should note that return traffic from PC2 and PC3 has no route to take as the R2,R3, and R4 routers do not know how to reach the subnet. We can see this by debugging packets on either R3 or R4 when pinging their PC subnets from PC1. In t his case I will send pings from PC1 to the R3 interface for the subnet. Note how the PC sends the packets, and we indeed see the packets arriv at R3 and and echo reply is sent back. However, we never see the reply reach PC1. This is due to the lack of routes back to PC1’s subnet.

Notice how the reply packets form R3 are sent to the correct destination of the PC’s address. If we look at R3’s routing table we will notice that there is indeed no route towards the subnet

To resolve this issue for both the PC2 and PC3 subnets we will need to add the following route to R4, R3, and R2 pointing at their correct next hops.

We are not able to successful ping form PC1 ( all the way through the network to PC2 ( and PC3 ( We can do a traceroute to verify the path takes the R1 -> R2 -> R3 Path.





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: