«

»

Print this Post

CCNA – Default Route Lab

This lab will cover the topic 3.8.a Default route from the Cisco Certified Network Associate (CCNA) blueprint. It will test your understanding and knowledge of configure static default routes on Cisco IOS devices. The only devices that can be modified on this lab are the following: R1 and R5. Please use the initial configurations as a template for your lab utilizing whatever console means you have (GNS, Physical Gear, VIRL, etc).

CCNADefaultLab


To complete this lab R1 must successfuly be able to ping PC1 (55.5.5.2). You will need to configure the R1 Eth0/0 interface with the first available IP address in the 10.12.12.8/29 address range. The other end of this link is already configured with the last available address. You must then use your knowledge of default routing to successfully generate end to end traffic. The only devices that can be modified are R1 and R5.

We start out by configuring Ethernet0/0 with the first available address in the 10.12.12.8/29 subnet.

Next we will verify R1’s ability to ping the other side of its Ethernet0/0 link which is using the last available address in the 10.12.12.8/29 subnet.

Now we can test whether R1 can ping the Webserver at 55.5.5.2

With now ability to reach the Webserver lets check the routing table of R1. Note how there is only one entry for the connected 10.12.12.8 subnet.

To take this a step further we will check the CEF table to see if it has any matches. Take note of how the CEF match is 0.0.0.0/0 via 0.0.0.0. This indicates that there is no match for this entry.

Now we will add a default route on R1 for all unknown networks pointing at the next hop which is the last address in our Ethernet0/0 subnet on the other end of the link. We have already confirmed we can communicate with this next hop.

We will now verify that our default route is showing up in the routing table, and that our destination is matched via the default route. Note that the output of show ip cef now indicates that the default route of 0.0.0.0/0 is reachable via 10.12.12.4, our next hop router. This does not indicate that we have full reachability.

Now that our default route is in place we can test our reachability from R1 to the WebServer at 55.5.5.2 utilizing troubleshooting tools such as ping and traceroute.

Since we have no success on pings and we make it to our first hop of R2 which is the other side of our Ethernet0/0 link. A good place to start is checking to see if R2 itself can reach our destination of 55.5.5.2

Since R2 is able to ping our WebServer, and we don’t have access to the internet routers, we will check reachability from PC1 (Webserver) to R2. Note how both the ping test and the traceroute test recieve Destination host unreachable back from 55.5.5.1 (next hop for the webserver)

With the knowledge that R5 does not know how to reach our destination of 10.12.12.9 it is a good place to start troubleshooting in the reverse direction in a similar fashion to the begining of the lab. We will first check the routing and cef tables.

Noting again that we don’t have an entry for our subnet, nor a default route to match (as indicated by the above output) we will need to create a default route on R5 pointing to it’s next hop for any unknown networks. Since we do not know the next hop IP address for a default route from R5 we will point it out it’s Eth0/3 interface.

We can now verify via the routing table and the CEF table that 10.12.12.9 is reachable via a default route pointing out Ethernet 0/3

Now verify that R5 can indeed reach 10.12.12.9 using it’s new default route.

We are now ready to test complete end to end connectivity by pinging R1 from the PC (WebServer) and by pinging the Webserver from R1


R2

R3

R4

R5

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: http://www.packetpilot.com/ccna-default-route-lab/