Almost Perfect for CCNA: a Two-Router, Two-Serial Topology

Are two routers enough for practicing CCNA skills in your home lab? Maybe, maybe not. But you can practice a surprising number of CCNA-level router tasks with a two-router lab using the topology suggested in my last post. Today I’ll discuss pros and cons with this topology, discuss some of the nuances with the lab exercise I listed last post, and close with a new lab exercise challenge – this time with EIGRP.

Let me apologize up front for the length of this post – next time I do a long initial lab, I may have to spread it out a little. Today, 3 pages: page is is a topology discussion, page 2 the answers to the lab from the previous post, and page 3 a new set of lab requirements.

First, with the two router topology (repeated below), if you are already a CCNA, you can probably predict what CCNA-level tasks can and can’t be done with this topology. For those of you not that far into CCNA yet, here’s a list of what I think you can practice quite reasonably on this small two-router topology:

A few CCNA technologies really do require more than the 2-router topology.  With a 3^rd router, one router (2 serial interfaces) acts as FR switch, with the other two routers connecting to the FR-switch router. Once you have the three routers, you can also use all three as IP routers as normal, and use the following topology that I call a router triangle (creative, huh?). This topo works well for routing protocol labs.

(You can practice FR with two routers. To do so, one router needs 3 serial interfaces, and that router connects to itself, acting as both IP router and FR switch. However, you have to kind of turn your head upside down to think through the config. 2501’s are still cheap, and work great as a 2-serial-port FR switch.)

The EIGRP lab (see page 3) gives you a good example of thinking through whether the 2-router topo works well enough for EIGRP for CCNA studies, and for CCNP studies. Next, page 2 of this post examines the answer to the lab from the previous post.

The basic problem with just two routers, combined with only CCNA level commands, is that when R1 learns a route from R2, the hop count will be 1, for a routes learned over each link. So, you miss the ability to see one route with a better RIP metric, see the router use that one route, cause the route to fail, and then see convergence occur so that the router uses the alternate route. There is no way to influence the metrics of the RIP routes except to use more routers, or to use an offset list, which is beyond CCNA. The lab exercise intentionally shows how difficult it is to experience this same sequence with only two routers, and with only CCNA-level commands – and the only answer I see that meets all the requirements requires some effort.

So, let me run through the configuration. If you haven’t read the previous post’s lab, you might want to go read that first.

The first two lab requirements were to configuration IP addresses and bring up interfaces so a router can ping it’s own interfaces, and the other router’s serial interfaces. The following config on R1 and R2 does the trick. (I’ve put it in a figure so that it fits a little better.)

R1:

R2:

These configs follow the addressing requirements, no shut the interfaces, give a clock rate to the router with the DCE cable plugged in (assumed to be R1). It also shows a no keepalive on the router LAN interfaces, in case there’s no connection to a switch – this will let the interfaces reach an up/up state. This is all relatively straightforward if you’re read that far into CCNA prep – if that’s not you, feel free to post questions.

Note: The original requirements, in the previous week’s post, were a little ambiguous. At steps 3 and 4, I meant to specify that only RIP routes were allowed. I’m making that assumption with this explanation.

I chose some details of this lab to force as many of the CCNA-level RIP commands as possible. For example, note that two different masks (255.255.255.0 and 255.255.255.252) are used for subnets of 10.0.0.0, so R1’s RIP must use RIP version 2. Without version 2, R1 would not advertise 10.1.1.0/24 to R2, because both serial links are in network 10.0.0.0, and have a different mask than /24.

R2 also needed a RIP version 2 command – but not to receive R1’s V2 update. Cisco’s RIP implementation defaults to send only V1 updates, but will process both V1 and V2 updates. So, with a version 2 command on R1, but not on R2, R2 would still learn of R1’s route for 10.1.1.0/24. However, R2 needs to turn off auto-summary, which requires RIP version 2. R2 is on the border between two classful networks: 10.0.0.0 and 172.16.0.0. As such, when advertising about subnet 172.16.1.0/25 out the serial interfaces – interfaces in network 10.0.0.0 – R2’s default of auto-summary would cause R2 to summarize and advertise only a route for 172.16.0.0/16 to R1. So, R2 needs both a version 2 and no auto-summary command. (Note that some of the concepts in this paragraph may be sneaking out of CCNA range…)

So, some more of the fundamental correct config, if you read last week’s post as meaning that all routes should be RIP routes (and not static routes), follows:

R1:

R2:

If I was being picky, and you also configured no auto-summary on R1, I’d have to count off a little. R1’s not on the border between multiple classful networks, so this command has no effect.

If you stopped here, R1 would have two routes for 172.16.1.0/25, and R2 would have two routes for 10.1.1.0/24. In real life, that would be the likely desired result. But I added the requirement that only one route for 172.16.1.0/25 be in R1’s routing table, and that route use S0/0/0 as the outgoing interface. If I had been more specific, I would have said that it had to be a RIP-learned route. With that requirement, I was hoping that you would be thinking about how to change the metrics on the routes, to make the RIP route over the top link have a lower metric than the RIP route over the bottom link. For those of you went past CCNA level commands, an offset list can do the trick. (Offset lists just add an integer value to the metric.)

Using CCNA level commands, the solution was to limit R1 to have only one route using the maximum-paths 1 command. This tells R1 to use only one route. With RIP, the route chosen happens to be the first one learned. So, to get a single route on R1 for 172.16.1.0/25, you’d need maximum-paths 1, and if the route out S0/0/1 was in the IP routing table, do a shut/no shut on the S0/0/1 interface. That would make R1 re-learn the route over the S0/0/1 interface, and the route out s0/0/0 would be in R1’s routing table.

That’s a messy lab. The question is, if you were going for CCNA, or recommending to a friend who’s pursuing CCNA, is this 2-route, 2-serial lab enough to learn RIP well? I’d say pretty well. This one lab let you experiment with network commands, version, auto-summary, and even maximum-paths. It’s maybe not as intuitive as a router triangle might be, but it’s still effective. Your thoughts?

Next, on to an EIGRP lab.

So, let’s do one more round with another lab. In this case, let’s again use the 2-router 2-serial topology (repeated here). You can use any interface numbers, and the LAN interfaces do not have to be FastE – just any old LAN interface will do. The lab will differ only slightly from the last lab. The differences:

• Use EIGRP instead of RIP.
• Make R1 have 1 EIGRP route for 172.16.1.0/25 when both serial links are up.
• When you shutdown the top serial link, R1 should converge to an EIGRP route over the bottom link, but not send any EIGRP Query messages to do so.
• Extra credit: change to a router triangle, and meet the same general goals – but use R1’s route directly to R2 as the better route, and fail over to an EIGRP route through R3.

That’s the lab. It probably requires CCNP level knowledge to achieve. It may not even be possible in the 2-router topology – if you think that’s the case, it’s interesting to think about why. If it is achievable, it’ll be a good exercise to think about the details. Feel free to post about the lab and/or why the 2-router topo is good or not in this case.

The above is enough detail if you were working the previous lab. If not, the rest of this post details this new EIGRP lab in full. The below is mostly a copy from the previous post, but edited to add the new requirements. Enjoy!

1)    Configure IP addressing per the list below, and bring up interfaces, such that each router can ping it’s own interface IP addresses.

2)    Confirm that each router can ping the other router’s serial IP addresses.

3)    Configure EIGRP such that R1 has exactly one EIGRP route for subnet 172.16.1.0/25, which uses R1’s S0/0/0 (or equivalent in your pod) as the outgoing interface.

4)    Configure and test so that when you shutdown R1’s S0/0/0 (or your equivalent), R1 learns and uses ( as seen in show ip route) the alternate EIGRP route for 172.16.1.0/25 through R1’s S0/0/1 interface.

5)    Use no unnecessary configuration commands.

Subnet requirements:

1) R1’s LAN: subnet 10.1.1.0/24. Give R1 the lowest IP address in the subnet.

2) R2’s LAN: subnet 172.16.1.0/25. Give R2 the highest IP address in the subnet.

3) Top serial link: subnet 10.1.2.0/30. Give R1 the lower IP address, and R2 the higher address.

Bottom serial link: subnet 10.1.2.4/30. Give R1 the lower IP address, and R2 the higher address.