Obtaining a CCNP in Four Months

OK... you first have to have some prior IP networking experience to be able to understand the language and the concepts. But, if you are focused and dedicated, you can obtain the CCNA in a month and the CCNP in four months, full-time and probably, one year part-time, through a course of self-study, reading and hands-on lab work. I just obtained the CCNP certification last week and the CCNA in January.

Basically, get copies of the Cisco Exam Certification Guides for the CCNA and CCNP. Check out the Cisco Learning Center, especially for Also, obtain a good Video course, like CBTNuggets or TrainSignal, to introduce the topics and get a broad level perspective.

To build your lab, you can find real equipment on ebay. But I would suggest purchasing a powerful PC and porting GNS3/Dynamips, a cisco router emulation environment (do a google search). This provides emulated testbed of routers for the Cisco 17xx, 26xx, 36xx and 72xx etc, with real IOS capabilities. There is also enough coverage for VLANs, Layer 3 switching and trunking with the NSM module on some of the routers. I was able to emulate up to 9 routers on Windows XP running over OS-X 10.5.x bootcamp on a 2.8 GHz Quad Core MacPro.

Here are some of the areas that I enjoyed studying and a have very strong knowledge.
Most of these of these topics are covered with hands-on labs.

• Routing: OSPF/EIGRP/BGP/IS-IS, MPLS, IP Multicast, PIM, IGMP, Frame Relay, NAT
• Layer 2/3 Switching: VLANs, 802.1Q, RSTP, HSRP, PPPoE, PPPoA
• Security and Services: IPSec, GRE, Radius/AAA, VPNs, SSH, 802.1X, VoIP, Wireless
• QoS: Queuing, DSCP, Congestion Management/Avoidance, Traffic Shaping/Policing, NBAR

Wireless and VoIP require additional hardware, and you will also need to obtain a copy
a copy of the Cisco SDM for some labs.

Plan on 6-8 hours per day, 5 to 6 days per week.
I took the two test route for the CCNA. The CCNP consists of four exams, about 1 per month.
Add a week additional time in case you fail and exam and need to re-take (like I did on the BSCI). I needed to pace myself with the BSCI lab work because of the amount of fun I had doing the configurations and debug. The BSCI was the hardest and most people, I hear, opt to take
it last. I took it first and it provided a solid foundation for all the other exams. Here is a BGP lab layout from a configuration lab.

Go for it! You can do it!

Filter a RIP route with Distribute List

This one seems worthy of a blog post. Previously, I discovered some esoterically cool stuff about auto-summarization and how in RIPv2, it is possible to create routing "blackholes" when certain routes are auto-summarized across classful boundaries then fed back to the originator of the route. The originator of the route then point back to the routers that auto-summarized the route. The network is a circular so eventually split-horizon stops the route update madness. Bottom line, pings to anything unknown address in the 10.0.0.0/8 network will loop between two routers until the TTL expires. This came about in my final lab ICND2 lab studies. Check out the ICND2 Certification Guide, Appendix F, last question and check the output of the show ip route command. Turns out, EIGRP stops this kind of thing cold with the clever Null0 bit bucket.

But on to the subject of the day.

I discovered how to use a distribute-list to filter a RIPv2 update. The whole exercise was a prelude to how to summarize (there's that word again) external RIP routes into a OSPF network across an Autonomous System Boundary Router (ASBR). The problem became how to start with a clean network where none of the OSPF networks were leaking into the RIP domain and none of the RIP routes were spilling into the OSPF domain. I use those words because I lack the technical-speak for the situation. Suffice it to say, my studies and meanderings have paid off with a nice solution.


Check out the diagram. The ASBR, R4, is running RIPv2 and OSPF. Each serial interface is in the 10.0.0.0/8 network. Since the network command in RIP only accepts classful networks, both S1/0 and S1/1 are included in the RIP process. So a passive-interface Serial 1/1 prevents the RIP advertisement leakage into the OSPF side of the R4.

Looking at the route table on R5, the 10.1.34.0/30 network is advertised since it is a connected interface on R4. That is really not desired because it exposes a part of the OSPF backbone network to the external network. Plus a ping from R5 to R3's S1/0 interface would go unanswered anyway. Investigating the distribute-list command allows for filtering routes based on an access-list. Creating an access-list that denies the subnet address (source address) and attaching itto the outgoing side of R4's Serial 1/0 interface filters the route. In fact, running debug ip rip displays "suppressing null update" for the update going out Serial 1/0. The configuration is listed in the diagram.

Using a passive-interface command on Serial1/0 would also work to suppress the RIP update, but it would defeat redistributing any learned routes to the external RIP domain from R4. That does not seem desirable since the next step in this investigation will be how to get networks in Area 1 (192.168.x.x/16) to talk to networks in the RIP domain (172.16.x.x/16) without using a static route and not exposing any details about Area 0 to RIP. Neat trick... later.

EIGRP: Say Hello to your Neighbors before Updating

I ran across this issue in my CCNA Frame Relay configuration lab studies. After creating a full mesh network in one IP subnet between R1 (Mayberry), R2 (Mount Pilot) and R3 (Raleigh) (see CCNA-ICND2 Exam Cert. Guide, Odom, page 489), and having that work (no big deal, all defaults work just fine), I moved on to testing the requirement of having R3 simulate a non-Cisco router which used ietf encapsulation between the LAPF headers and payload (RFC 1490/2474). No big deal. The encapsulation works just fine. The crux of this issue lies elsewhere.

The exercise, on page 491, states that R1 (a Cisco router) must accommodate R3 by using ietf encapsulation on a frame relay map command. Here is the tricky part. The specific command of interest in Example 14-4 is replaced by a correction in the errata. The errata states the line should be "frame-relay map ip 199.1.1.3 53 ietf". Therein lies the problem. The "authoritative" errata needs an errata!!!

Here are the full configs:

R1:
interface serial0/0/0
encapsulation frame-relay
frame-relay lmi-type ansi
frame-relay interface-dlci 53 ietf !!!!! <--- watch out
ip address 199.1.1.1 255.255.255.0

interface fastethernet 0/0
ip address 199.1.10.1 255.255.255.0
!
router eigrp 1
network 199.1.1.0
network 199.1.10.0


R3:
interface serial0/0/0
encapsulation frame-relay ietf
ip address 199.1.1.3 255.255.255.0

interface fastethernet 0/0
ip address 199.1.12.3 255.255.255.0
!
router eigrp 1
network 199.1.1.0
network 199.1.12.0

Both routers are configured for EIGRP on the their networks. As soon as both links come up, both routers send EIGRP Hellos to each other. R1 quickly creates an adjacency with R3 and immediately sends Update packets. R3 does not do the same.

Hmmm. Inspecting "show ip eigrp neighbors" on R1 displays R3 but a "1" is showing up under the Q column. This means it has sent a message and is awaiting an acknowledgement (I surmise this is a function of RTP - Reliable Transport Protocol). After a time, R1 gives up due to too many retransmissions of it original update. R3's serial interface can be ping'd but that is it.

Meanwhile, on R3, it is receiving updates but not forming neighbors with R1. Why? Because it never hears a Hello from R1. Inspecting "debug eigrp packets", an Update is received from R1 but EIGRP indicates "Neighbor (199.1.1.1) not yet found". What!? Can't you hear it talking to you?

Turns out R1 is not forwarding broadcast (or multicast) over the PVC to R3. EIGRP Hellos are multicast on 224.0.0.10. And the authoritative frame-relay map command was not set with the broadcast option.

So here is the correct config for R1:

R1:
interface serial0/0/0
encapsulation frame-relay
frame-relay lmi-type ansi
frame-relay interface-dlci 53 ietf broadcast !!!!! <--- Aha!!!
ip address 199.1.1.1 255.255.255.0

Neighbor relations form, updates are exchanged, routing tables filled. Ahhh! Life is good! Also, all of this was confirmed via Wireshark for good measure.

Interesting... a router in OSPF will not even start sending updates unless it receives back a Hello with it's IP address in it. But that a different story for

Moral: Say Hello to your neighbors! And make sure they have heard you before giving them the latest news update.