This is the .net file I used in my INE labs. If you’re going to run a pure Dynamips lab, then you should use this file instead.
Hybrid Topology: Download
Physical SWITCH to SERVER mappings:
SW1:
Fa0/1 – eth12
Fa0/3 – eth8
Fa0/5 – eth3
SW2:
Fa0/2 – eth11
Fa0/4 – eth7
Fa0/6 – eth6
Fa0/24 – eth4
SW3:
Fa0/3 – eth10
Fa0/5 – eth5
Fa0/24 – eth2
SW4:
Fa0/4 – eth9
Fa0/6 – eth1
(I posted this on the GroupStudy mailing list.)
CCNA, CCNP, & PRE-CCIE
I started the CCNA in 2008. At the time, I thought passing the CCIE was literally impossible, and didn’t really even consider it. I was more of a Linux Sysadmin anyways and networking wasn’t my specialty, I just wanted to broaden my knowledge. But I became addicted to the technology, and after passing the CCNA I immediately started studying for the CCNP. I built a rack of 2600s & 3550s, and then created labs for every technology on the CCNP. In 2010 I finished the CCNP and also changed jobs. At this point I was feeling really burnt out and took a few months off from studying. After some time (late 2010), I decided to start studying again. I sold off all of my routers and switches (except for two 3550s), and purchased some reading material for my ‘Pre-CCIE Written’ studying. These books are: Interconnections by Perlman, TCP/IP Illustrated by Stevens, and Internetworking with TCP/IP by Comer. These books took me quite a while to read. Interconnections is especially difficult to read, but very much worth the time. (These 3 books are not only on the CCIE reading list, but recommended to me by the best engineers I know).
The Written
In May 2011 I started officially studying for the CCIE Written. My study materials for the written consisted of the Official CCIE Routing and Switching Guide, Routing TCP/IP VOL1 & 2, various RFCs, and lots of Cisco Documentation. I also had SafariBooksOnline, and read chapters from lots of other Cisco Press books. The only time I would touch the command line, was to verify my understanding of something that didn’t make sense in words. I passed the written June 27, 2011.
After passing the written, I felt like I had a strong foundation of knowledge. I wanted to build upon this foundation as much as I could. I did not want to hesitate between the Written and the Lab. So I immediately scheduled a lab date and started building my rack ( or hybrid rack). I had always used dynamips, but now it was time to get serious, and this meant forking out the cash for some 3560s & a new server. The lab I built is a Hybrid Dynamaips lab. This consists of a rackmount server running Debian Linux, 2x Catalyst 3550s, 2x Catalyst 3560s, and a 16U Skeletek rack. My server has 3x Quad-Core NICs which allow me to bridge any NIC to any virtual router in dynamips. Pictures & more details here: https://yuri.easytospell.net/?p=721
Lab Study
I started with INE Volume I, it was a great workbook to start with. I spent A LOT of time on each task, even the easy ones. I wanted to understand EVERYTHING perfectly! After INE Volume I, I started working on INE Volume II. While doing the Volume II labs I also worked on Narbiks Foundations workbook. On weekends I would do volume II labs in 8 hour sessions, and on weekdays I would do Narbiks WB after work (from 6:30pm to 12:00am). In November I went to Narbiks Bootcamp! That was a lot of fun, it was like summer camp for networking nerds. Narbik is simply a great teacher, and studying with other people was a great experience. Forums & mailing lists are awesome, but there isn’t anything that beats in-person.
Study Discipline
During my studies I tried to ban myself from using google. If I was doing a practice lab I would limit myself to the DocCD only. If I was doing INE Vol I or Narbiks Adv WB I would limit myself to the DocCD, Books, and RFCs. Forcing yourself to understand something from the GROUND up is important. It might be easy to find someone else asking the same question on google, and sometimes it is appropriate to find information this way, but don’t get lazy. Reading should always be a part of your study routine anyways. Even if its just 45 minutes on the train to work. Never stop studying the theory.
Final Review: 6 weeks before the lab.
This was a little plan I created, and I am actually really proud of this. I printed out the extended R&S Blueprint, and marked each section with a certain amount of days. I divided each section into time ranges ( over 30 days), giving bigger topics more days than others. Day 1 for a topic would consist of researching and studying the topic on the DocCD. Day 2+ for a topic would consist of labbing various scenarios from Narbiks WB & INE Vol 1. I did this for every single topic on the Extended Blueprint. After 30 days I had covered the entire Blueprint. With two weeks left berore my lab, I spent 1 week finishing INE volume II, and the final week resting with some light review. 3 days before the lab I did one final Volume II lab. It was an easier lab that I had already done, but I wanted to keep my spirits high.
Lab Day:
Since I live in San Francisco I considered just driving to San Jose early in the morning for the lab, but I used to do that commute every day, and it just sucks. Instead, I rented a hotel room at some place called Avatar (Right next to iHOP- very classy!). After checking into the Hotel I did a practice drive to building C to familiarize myself with the target area. The rest of the day I spent doing LIGHT review of random topics & watched some program on the History channel about Navy Seals! I tried to go to bed early that night, but I couldn’t sleep AT ALL, I was too excited! I just laid awake looking at my alarm clock, and listening to the drunk people in the next room.
Troubleshooting:
This is the section that I really feared the most. The general strategy with troubleshooting is to do the easy tickets first, and that is exactly what I did. If you understand the technology, the troubleshooting is not very difficult. But I did get stuck on one ticket. The one I saved for last!! I had 30 minutes for it too!! Grrrr!!!
Configuration:
The configuration section was fair. Now of course I had a doubts about certain things. And this really lowered my expectations about passing. But you just have to be confident. I finished the configuration section with about one and half hours to spare. This gave me time to go over everything, and it is probably why I passed this section. By the way, I am not fast at typing. I just knew all of the technology. If you know the technology, time management will not be an issue.
Post Lab
I went into the lab thinking I could, and SHOULD pass the first time. I left the lab with my expectations low. In fact I was comfortable with the fact that I will probably not pass the first time. After driving through the most hellish San Jose traffic, I finally got back to SF and began explaining to my family that we shouldn’t get our hopes up. I said there was about a 30% chance that I would pass. Once I sat down at my desk, I began to furiously reproduce the issue I had on the troubleshooting. But I couldn’t reproduce the damn problem in my lab! This really annoyed me! So I basically crashed into a depressed heap on the couch, and started chain eating granola bars. Eventually I thought to check my score report. Maybe that would give me a clue as to what the issue was? I know they don’t give any kind of detailed report, but I wasn’t thinking rationally. I opened up my mailbox, clicked the link for my ccie report, and to my ultimate shock, read “PASS”. I almost fell out of my seat. I clicked refresh so many times, and I had my girl friend make sure that I wasn’t delusional. I’ve never felt so tired and happy in my life. I had just been on one hell of an emotional roller coaster.
Advice
*You must understand the CORE technologies. I think everyone says this- But I will say it too! Things like OSPF, BGP, MPLS, IPV6, and Multicast should be something you have intimate knowledge of. Not just memorization of the commands to configure X. There is a big difference between understanding how to configure a protocol, and UNDERSTANDING how a protocol works.
*I love the Narbik and INE workbooks. But the vendors cannot spoon feed you everything. There is a very large aspect of your studies that must be done on your own. This means using debugs, packet captures, and RFCs to better understand each protocol.
*There are a lot of IP services, but you should think of these as free points, a gift from Cisco. I was really scared of them at first, all I cared about were the core technologies. Spend some time to study them, and you will realize that they’re so easy.
*I think I had the right attitude going into the lab. I went into the lab with a confidence of 100, and by the end of the day had a confidence of 30! If you go into the lab with a confidence of 50, what is going to happen by the end of the day!!?? So go into the lab with a confidence of 110! I promise you something in there will knock it down, so start strong!
*No matter what happens during the lab, never give up. This kind of goes with the above. Even if you’re confidence is low, you’re probably doing better than you think! So just keep going. Finish the lab as best you can. I bet you will surprise yourself!
This has been the greatest Achievements for me! Good luck to everyone out there who is studying! I look forward to further participation on this Mailing List, and other forums that I frequent!
-Yuri Bank
CCIE #33680
I’ve spent the last 2 and 1/2 years studying for the CCIE. The last 7 months were the most intense. While working full-time, I studied 4-6 hours per day on weekdays, and 8-10 hours on weekends. This is by far the most difficult & greatest achievement in my life. The CCIE R&S Lab is no joke. Even with the massive amount of studying, I set my expectations low on the lab date. There are a lot of people smarter than myself who attempt this lab multiple times before passing. I walked out of the lab accepting the fact that my chances were slim. When I got home, reading the e-mail that said I had passed was surreal. I thought maybe it was mistake? Did I REALLY pass the first time? It was so shocking, I didn’t even know what to say. I’m still swallowing the fact that I passed.
After it is all said and done, all I have now is a number. A new title? A reputation that people will eagerly test me on? For me, the greatest part of this was the *journey* itself, and not really the end result (Cliche I know!). I’ve learned an incredible amount of discipline that can be applied to other things. I’ve learned a lot about network technologies. I’ve learned how to work under pressure & stress for long hours. And I’ve met an awesome community of people who studied with me, helped me, and will continue to be a part of my life.
-Yuri Bank
BGP inject-map allows you to conditionally advertise a component subnet of a larger aggregate route. The component subnet does not have to be in the route table, it is generated by the router applying the inject-map. The route is only advertised IF the aggregate route in the exist-map is matched. This feature provides a very powerful way to engineer traffic since it’s control mechanism is based on Longest prefix-matching behavior. NOTE: As we will find out below, bgp inject-map can be dangerous, so you must take care when using this tool.
SCENARIO:
R1 is advertising an aggregate route of its four loopback interfaces: 172.100.0.0/22
GOAL:
R4 should forward ALL traffic for 172.100.3.0/24
Since AS400 is only receiving 172.100.0.0/22, we cannot use traditional methods such as (localpref) to accomplish this without affecting the entire summary route. There are multiple alternative ways we can achieve the stated goal, and ‘bgp inject-map’ is one of them.
R1 Configuration:
Make sure R1 is advertising an aggregate route and suppressing the specific prefixes.
R1(config)#router bgp 200 R1(config-router)#network 172.100.0.0 mask 255.255.255.0 R1(config-router)#network 172.100.1.0 mask 255.255.255.0 R1(config-router)#network 172.100.2.0 mask 255.255.255.0 R1(config-router)#network 172.100.3.0 mask 255.255.255.0 R1(config-router)#aggregate-address 172.100.0.0 255.255.252.0 summary-only R1(config-router)#
R1#show ip bgp | inc 172.100 BGP table version is 21, local router ID is 172.100.3.1 s> 172.100.0.0/24 0.0.0.0 0 32768 i *> 172.100.0.0/22 0.0.0.0 32768 i s> 172.100.1.0/24 0.0.0.0 0 32768 i s> 172.100.2.0/24 0.0.0.0 0 32768 i s> 172.100.3.0/24 0.0.0.0 0 32768 i R1#
VERIFY on R4 and R5:
We’re receiving ONLY the summary route.
Written by
R4#show ip route bgp
172.100.0.0/22 is subnetted, 1 subnets
B 172.100.0.0 [20/0] via 172.24.0.2, 00:11:22
172.12.0.0/24 is subnetted, 1 subnets
B 172.12.0.0 [20/0] via 172.24.0.2, 00:07:57
172.13.0.0/24 is subnetted, 1 subnets
B 172.13.0.0 [20/0] via 172.24.0.2, 00:08:28
172.23.0.0/24 is subnetted, 1 subnets
B 172.23.0.0 [20/0] via 172.24.0.2, 00:08:28
172.35.0.0/24 is subnetted, 1 subnets
B 172.35.0.0 [200/0] via 192.45.0.5, 00:10:28
R4#
R4 Configuration (route-maps):
The ‘bgp inject-map’ requires two route-maps which indicate what should be advertised and what should be matched.
bgp inject-map [inject-map] exist-map [exist-map]
1. Create prefix-list & route-map that define the route we want to inject
R4(config)#ip prefix-list GENERATE_ROUTE permit 172.100.3.0/24 R4(config)#route-map INJECT_MAP R4(config-route-map)#set ip address prefix-list GENERATE_ROUTE R4(config-route-map)#exit
2. Create two prefix-lists & a route-map that match the aggregate route. First prefix-list matches the aggregate route (172.100.0.0/22) and the second matches the route source. The route source is the IP address of the neighbor we’re receiving the route from. You MUST specify this criteria (R2 172.24.0.2).
R4(config)#ip prefix-list AGGREGATE permit 172.100.0.0/22 R4(config)#ip prefix-list SOURCE permit 172.24.0.2/3 R4(config)#route-map EXIST_MAP R4(config-route-map)#match ip address prefix-list AGGREGATE R4(config-route-map)#match ip route-source prefix-list SOURCE
R4#show ip prefix-list ip prefix-list AGGREGATE: 1 entries seq 5 permit 172.100.0.0/22 ip prefix-list GENERATE_ROUTE: 1 entries seq 5 permit 172.100.3.0/24 ip prefix-list SOURCE: 1 entries seq 5 permit 172.24.0.2/32
R4#show route-map
route-map INJECT_MAP, permit, sequence 10
Match clauses:
Set clauses:
ip address (prefix-list) GENERATE_ROUTE
Policy routing matches: 0 packets, 0 bytes
route-map EXIST_MAP, permit, sequence 10
Match clauses:
ip address prefix-lists: AGGREGATE
ip route-source prefix-lists: SOURCE
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R4#
R4 Activate bgp inject-map
R4(config)#router bgp 400 R4(config-router)#bgp inject-map INJECT_MAP exist-map EXIST_MAP R4(config-router)#
R4#show ip bgp injected-paths
BGP table version is 13, local router ID is 192.45.0.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.100.3.0/24 172.24.0.2 0 ?
R4#
Verification
We should make sure R5 has the route for the injected path and do some tests.
R5#show ip bgp 172.100.3.0
BGP routing table entry for 172.100.3.0/24, version 44
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x860
Advertised to update-groups:
1
Local, (aggregated by 200 172.100.3.1)
192.45.0.4 from 192.45.0.4 (192.45.0.4)
Origin incomplete, metric 0, localpref 100, valid, internal, atomic-aggregate, best
R5#
R5 now has the route for 172.100.3.0/24 pointing towards R4. All of the routers in AS400 should now route through R4 for the 172.100.3.0/24 due to longest-prefix matching rules. We will still use the aggregate route (172.100.0.0/22) for everything else.
Lets do some pings on R5 to verify connectivity
R5#ping 172.100.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.100.3.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R5#
Hmmm! That is not good!
Ok, we should perform a traceroute and see where this is failing.
R5#traceroute 172.100.3.1 Type escape sequence to abort. Tracing the route to 172.100.3.1 1 192.45.0.4 4 msec 4 msec 4 msec 2 172.24.0.2 [AS 200] 8 msec 8 msec 12 msec 3 172.23.0.3 [AS 200] 12 msec 8 msec 12 msec 4 172.35.0.5 8 msec 8 msec 12 msec 5 192.45.0.4 20 msec 16 msec 12 msec 6 172.24.0.2 [AS 200] 16 msec 24 msec 20 msec 7 172.23.0.3 [AS 200] 16 msec 20 msec 20 msec 8 172.35.0.5 16 msec 20 msec 16 msec 9 192.45.0.4 20 msec 20 msec 24 msec 10 172.24.0.2 [AS 200] 28 msec 32 msec 28 msec 11 172.23.0.3 [AS 200] 28 msec 28 msec 24 msec 12 172.35.0.5 32 msec 32 msec 36 msec 13 192.45.0.4 44 msec 36 msec 44 msec 14 172.24.0.2 [AS 200] 40 msec 36 msec 44 msec 15 172.23.0.3 [AS 200] 40 msec 36 msec 36 msec 16 172.35.0.5 36 msec 36 msec 40 msec 17 192.45.0.4 40 msec 36 msec 40 msec 18 172.24.0.2 [AS 200] 56 msec 44 msec 44 msec 19 172.23.0.3 [AS 200] 56 msec 48 msec 48 msec
The hell?! We have a routing loop! Packet is going from R5 to R4 to R2 to R3 and then back to R5 again, this continues until the IP TTL expires! OK so we definitely have some problems here. Lets take a look at the routing tables on R2 & R3.
R2#show ip bgp 172.100.3.0
BGP routing table entry for 172.100.3.0/24, version 26
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x840
Advertised to update-groups:
1
400, (aggregated by 200 172.100.3.1)
172.23.0.3 from 172.23.0.3 (172.35.0.3)
Origin incomplete, metric 0, localpref 100, valid, internal, atomic-aggregate, best
R2#
R3#show bgp 172.100.3.0
BGP routing table entry for 172.100.3.0/24, version 24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2 3
400, (aggregated by 200 172.100.3.1)
172.35.0.5 from 172.35.0.5 (192.45.0.5)
Origin incomplete, localpref 100, valid, external, atomic-aggregate, best
R3#
So it seems that R3 learned the injected route (172.100.3.0/24) from R5, and then advertised it to R2. This route is more specific than the aggregate they have from R1, so it takes precedence! Also notice the AS_PATH, it has AS 400 listed but not AS 200! This is why the advertisement made it to R3.
When R4 injects the route, it suppresses the advertisement to R2 (as it should) because it is the source and next-hop for the injected route! R5 however, advertises the UPDATE to R3 as it would with any other route. R3 accepts the route because it doesn’t see its own AS in the AS_PATH. R3 advertises 173.100.3.0/24 to R2, and a routing loop is formed.
copy-attributes
We can solve the routing loop issue by including the full AS_PATH in the injected route. This will prevent R3 from accepting the route (172.100.3.0/24) from R5 due to BGP loop prevention rules (R3 will see its own AS in the AS_PATH).
R4(config)#router bgp 400 R4(config-router)#bgp inject-map INJECT_MAP exist-map EXIST_MAP copy-attributes R4(config-router)#
R4#show ip bgp injected-paths
BGP table version is 14, local router ID is 192.45.0.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.100.3.0/24 172.24.0.2 0 200 i
R4#
Very good. R4 is copying the AS_PATH attribute from the parent route (172.100.0.0/22) to the injected route (172.100.3.0/24).
Lets check R2 and R3. They should only have a route for the aggregate 172.100.0.0/22, but not the more specific route 172.100.3.0/24 that R4 is injecting.
R2#show ip bgp 172.100.3.0 255.255.255.0 % Network not in table R2#
R2#show bgp 172.100.3.0
BGP routing table entry for 172.100.0.0/22, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
Local, (aggregated by 400 172.100.3.1)
172.13.0.1 from 172.13.0.1 (172.100.3.1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
R2#
R3#show ip bgp 172.100.3.0 255.255.255.0 % Network not in table R3#
R3#show bgp 172.100.3.0
BGP routing table entry for 172.100.0.0/22, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
Local, (aggregated by 400 172.100.3.1)
172.13.0.1 from 172.13.0.1 (172.100.3.1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
R3#
Perfect!
Check R5 again. We should see 200 in the AS_PATH. This is important because R3 will accept the route from R5 if it is not there.
R5#show ip bgp 172.100.3.0 255.255.255.0
BGP routing table entry for 172.100.3.0/24, version 45
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
200, (aggregated by 200 172.100.3.1)
192.45.0.4 from 192.45.0.4 (192.45.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
R5#
A final ping & traceroute to verify connectivity and routing.
R5#ping 172.100.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.100.3.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms R5#
R5#traceroute 172.100.3.1 Type escape sequence to abort. Tracing the route to 172.100.3.1 1 192.45.0.4 8 msec 4 msec 0 msec 2 172.24.0.2 [AS 200] 4 msec 8 msec 8 msec 3 172.12.0.1 [AS 200] 12 msec 16 msec 12 msec R5#
UPDATED!
I’ve recently started working on some of Narbik’s labs, so I created a full dynamips topology for them. I’m also planning to create a hybrid topology for use with 4x 3550s/3560s (stay tuned for that). In the diagram below: the left hand column shows the interface conversions since I’m using c3725s with the NM-16ESW. All of the other interfaces should match up exactly.
You can download the .net file here!
