Chronicles of CCIE journey

I am over the initial euphoria of passing the R/S lab and thinking about the future.
I am getting married in March, so before that, I can muster up some time. And since last year studying was all I did, I don’t know what would I do for the next 5 months if not study  .
Browsing the web about the SP materials, I realized, service provider track is the most neglected of all by the vendors. And that only leads to confusion as I don’t know, which vendor to choose for SP prep, specially considering that 5 months is all I have to start and finish the prep and financial constraints make it impossible for me to gather all prep materials.

Lets Look at IPexpert. The offer Blended Learning Solutions for R/S, Voice and Security, and one track they ignore is…. Yes, the service provider track. According to support, it may take 3 months or more before BLS is out, time I don’t have. Let’s look at their free V-seminars. They offer 9 different seminars for Voice and R/S and only 1 for Service Provider.

InternetworkExpert was supposed to upgrade the SP workbook but that’s long overdue as well. Also, from what I’ve heard the workbook solutions offer NO explanation or verification whatsoever. I’ve heard that dynamips version of same workbook does offer some explanations, but for a guy like me, who is not great comfortable with MPLS at all, the topics that dynamips doesn’t cover will not be available in dynamips workbook and will be problematic. Also, priced at 395 apiece, I cannot afford to buy both dynamips and regular workbook, when they are 90% the same. Due to financial constraints, the COD is out of question for me already. In fact, before my company agreed to finance the bootcamp, all I could buy was first 10 IE labs only. Also their technology labs as I hear need upgrading as well. IE is upgrading R/S technology labs and doing a wonderful job, but again Service Provider track is neglected.

IEMentor earned a good reputation for Service Provider track 3 years back. But they were supposed to release an upgraded version in October 07 and one year after the due date, it’s still not released.

Narbik is making his SP workbooks but those won’t be ready till January next year anyway.

Also, I am unable to find good unbiased reviews of products on the blogsphere.

Anyway, I’d appreciate if anyone has good SP experience and can recommend a particular product.

I have to make a decision soon and start studying again. It almost feels weird when I return to home from office and have nothing to study, which basically means I am getting bored as hell? 

Also, I have to ask Ethan if I can post topics regarding SP prep etc here or not. In any case, I write at http://ccie-chronicles.blogspot.com as well. And whatever I write here, is there as well. If Ethan allows me to continue writing here, I will be writing about my SP prep here as well. Until then, I am waiting to hear from readers about the SP prep.

Well this post will be in two parts. The smaller first part will detail what I did to prepare for the lab.
And the in second part, I will detail what I think is the best way of preparing for the lab, based on personal experience and problems I had along the way. In short, if I had to prepare for the lab all over again, the path I’d take will be in the recommendations J



My preparation path:



Workbooks



Narbik Kocharian’s Advance Technology Workbook

IEWB Dynamips workbook vol 2 (First 10 labs)



Bootcamp:



I attended Narbik Kocharians bootcamp in April



I started my journey last year and started working on written and lab simultaneously.

I cleared the written exam in March, and then started concentrating on the lab.

Even before that my method was to read through DOC cd and make small labs to understand a technology and feature using dynamips. By the time I attended Narbik’s bootcamp in April, I had finished first 10 IEWB labs.

After the bootcamp I concentrated on Narbik’s workbook and completed it cover to cover and did some of the IEWB labs over and over again till the lab date.



I followed this path, but will I do the same if I have to do everything all over again? No, I will change the methodology and hence my recommended preparation method is as follows.



Recommendations:



Assuming you have cleared your written exam what should be your next step.

Personally I think, you should start with focusing on individual technology.

For that I recommend Narbik’s Advance Technology Workbook. His philosophy is to take a technology, make small labs about every feature and then beat it to death. When you are finished with his workbook, you have typed in 95% of commands you need to know and practiced 95% of all features that can show up.

The figure 95% is estimation, and Narbik is continuously updating his workbooks J



Now, I am also very satisfied with IE workbooks, and IE is reshaping their Vol 1 technology labs according to same philosophy. Up till now, those are in Beta Phase. So at the moment, the only deep technology workbook that I know of is Narbik’s.



I did attend Narbik’s bootcamp and I have only good things to say about it. I chose it because it was the cheapest, but the 5 day bootcamp was really informative and a great experience. Once again, I didn’t attend other vendors’ bootcamps so I cannot compare. But from what I heard, everyone praises both IE and IPexpert bootcamps as well. So I’ll also recommend Narbik’s bootcamp to all readers.





After that, you should start with full scale labs. I only tried IE first 10 labs and I was really happy with those. I didn’t try any other vendor for full scale labs so I cannot comment on those. I would recommend those to all readers as well.



In this way, by doing Narbik;s lab first, you learn to do almost everything you need to, independently. And with full scale labs, you improve your speed, stamina and learn how to approach a full scale lab and get a very good idea about how technologies interact with each other.





I hope this post is useful for readers of this blog.

Well
About my experience of the lab, let’s start with basics.

Was the lab very difficult?
No, to be true, I found it ridiculously easy. I was done in three and half hours, spent next three and half verifying more than a dozen times, and left an hour early.
It may seems like my holier than thou attitude, but right after I reached hotel I had a chat with Daniel Hammerstein, who frequently comments on cciecandidate.com. And he can vouch that I said the same thing to him, even before my result came. That apart from one interpretation (silly language to blame here) and one corner case question, the lab was ridiculously easy. So 94 out of 100 marks were up for grabs for anyone who studied well enough.

So it was all that easy and no glitches?

That’s also not true. A particular question bugged the hell out of me. And guess what, it was an interpretation problem. And while leaving the lab, the only thing I was thinking was that if my interpretations were right, I couldn’t fail. But the uncertainty kept me on edge until I saw the result.

Was there any obscure technologies/out of the world questions?
Yes … One question was something I couldn’t have dreamed about showing up. Luckily my practice of focusing on documentation as lab prep paid off and though it was a corner case (mind you a very easy one only if you know it), I didn’t even have to look at DOC CD.

How’d you rate the difficulty level of CCIE lab?

Compared with IEWB labs, I’d say a 5 or 6.
Why I’d rate the lab like that. Well the breadth of technologies tested was broad, but IE labs generate problems within themselves, for example redistribution causes loops, preferring a path some time causes RFP failures in multicast, some security features break connectivity. Means a task, simple as maybe, often causes deep running problems. CCIE lab tested knowledge about everything and then some, but questions were fairly independent and they question didn’t cause hidden problems. That is why I think lab was easy.


Was DOC CD available and were there any broken links?

I only accessed 3560 configuration guide and that was accessible without a problem.

What about lab facility?

Well Dubai has a small room for CCIE lab, with 5 seats. We were four people in the same room.
At least in Dubai, you are provided with different color highlighters and plethora of lead pencils.

A word about the Proctor?

Mr.Zia was an extremely nice guy. Not very helpful in my particular case though 
I bugged him throughout for the same question and he told me that I was over thinking the issue. To be fair, I was asking him the question in format of “Is it A or B?” and he couldn’t give away the answer  But later I rephrased the question and he did his best to eliminate my confusion. Needless to say, in a high pressured environment like the lab, confusions don’t go away easy. He was also very friendly and not snobbish at all.


How I approached the Lab?

Well, I started of by drawing a L3 diagram. L2 diagrams were provided and were very clear, and so were L3 diagrams, but to be able to write on the paper, and avoid turning back the pages, I drew my own diagram.
I spent the first 20 minutes reading the lab, drawing L3 diagram and creating aliases.
By one and half hour I had completed the L2 section. By the way, my particular lab had a very heavy L2 section.
I was done with IGP and verification by two and half hours and then everything flew by. I mean in an hour I was able to do security, BGP, multicast, Ip services and QOS with around 10 minute each on every section. Here the questions were straight forward without any ambiguities and often very very simple if you know what you are doing.
I didn’t draw a bgp diagram, but I strongly recommend it. On my L3 (IGP) page; I used a different color maker to designate BGP.

Lunch was after 5 hours in my case. By Lunch time I had gone over the verification at least four times and was still worried about my interpretation of a particular question.
I didn’t eat anything during lunch, so cannot comment on quality of food.

After the lunch break, I started verification again. This time around, I’d sh runn before running the verification commands and went over each question 6 or 7 time again.
Around 7 hours into lab, I’ve had enough  and couldn’t stand to sit there anymore, so I left sweating and hoping.

I couldn’t sleep and kept on checking t email 10 times an hour. Around 2 AM I received the email that my score report is available, and between the time I clicked on the link and saw the report, I kept trembling and all my confidence went down the drain :P
Its been around 24 hours and I am still high like I am on speed: D and loving the feeling.

What Next?

Haven’t thought about it, and will not at least during September again 

I will write another post in coming days on my views on preparation and advice for CCIE candidates. So keep checking the pages.

Yes, I passed.

Just checked the report, and will write in detail after the moment has sunk in

While reviewing IEWB VOL 1 VER 5 labs, I discovered a new feature: EIGRP Stub with Leak Map. I spent some time researching the topic and found out a variation of the feature which is not explored in the workbook.
Here I’ll try to demonstrate EIGRP stub routing with leak map as well as what is called strictly controlled Leak Maps.

Our topology is shown in the figure.




The basic routing configuration on the routers is as follows.
R4 and R5 are running rip.

R4:
router rip
version 2
passive-interface default
no passive-interface Serial1/0
network 150.1.0.0
no auto-summary

R5:
router rip
version 2
network 5.0.0.0
network 150.1.0.0
no auto-summary

The rip table of R4 is as follows.

R4#sh ip route rip
5.0.0.0/24 is subnetted, 4 subnets
R 5.5.0.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0
R 5.5.1.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0
R 5.5.2.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0
R 5.5.3.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0



R4:
router eigrp 10
network 150.1.14.4 0.0.0.0
no auto-summary


R1:
router eigrp 10
network 150.1.12.1 0.0.0.0
network 150.1.13.1 0.0.0.0
network 150.1.14.1 0.0.0.0
no auto-summary
!

R2:
router eigrp 10
network 150.1.12.2 0.0.0.0
no auto-summary


R3:
router eigrp 10
network 150.1.13.3 0.0.0.0
auto-summary
!


Also at R4 we have mutual distribution between Rip and EIGRP.



R4
router eigrp 10
redistribute rip met 1 1 1 1 1
router rip
redistribute eigrp 10 met 1



Now we examine the routing tables on R2 and R3.
We notice that all eigrp routes, including the external RIP routes are in routing table.



R2#sh ip route eigrp
5.0.0.0/24 is subnetted, 4 subnets
D EX 5.5.0.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
D EX 5.5.1.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
D EX 5.5.2.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
D EX 5.5.3.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
150.1.0.0/24 is subnetted, 4 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:03:54, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:03:54, Serial1/0
D EX 150.1.45.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0




R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 4 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
D EX 5.5.2.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
D EX 5.5.3.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
150.1.0.0/24 is subnetted, 4 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:03:50, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:03:50, Ethernet0/0
D EX 150.1.45.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0





Now we’ll configure R1 as stub.
As a result all external routes should disappear from R2 and R3.

R1
router eigrp 10
eigrp stub connected



R2#sh ip route eigrp
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:00:23, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:00:23, Serial1/0


R3#sh ip route eigrp
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:01:15, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:01:15, Ethernet0/0

All right!

Now we’ll discover different options for leak maps by implementing different routing policies.

Policy 1:

Configure R1 such that R2 and R3 have reach ability to 5.5.0.5 and 5.5.1.5 networks.

For this we’ll match the desired networks in an access-list and then implement EIGRP stub Leak Map.



R1
access-list 1 permit 5.5.0.0 0.0.0.255
access-list 1 permit 5.5.1.0 0.0.0.255
route-map EIGRP_LEAK
match ip address 1
router eigrp 10
eigrp stub connected leak-map EIGRP_LEAK

Now we examine the routing tables on R2 and R3

R2#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560537856] via 150.1.12.1, 00:00:28, Serial1/0
D EX 5.5.1.0 [170/2560537856] via 150.1.12.1, 00:00:28, Serial1/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:00:28, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:00:28, Serial1/0
R2#

R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:00:20, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:00:20, Ethernet0/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:00:20, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:00:20, Ethernet0/0
R3#


Policy 2:
Configure R1 such as R3 sees both 5.5.0.0 and 5.5.1.0 networks but R2 cannot.

Here we can use ‘match interface’ option in the route-map.
This is called strictly controlled Leak map.
The login is as follows

1. If “match interface” options is not used, routes are leaked on all interfaces.
2. If “match interface” option is used, routes are ONLY leaked on the interface matched.


So we’ll use match interface argument in the route-map and only match interface Ethernet 0/0, which is connected to R3.

route-map EIGRP_LEAK permit 10
match ip address 1
match interface e0/0

R1#sh route-map
route-map EIGRP_LEAK, permit, sequence 10
Match clauses:
ip address (access-lists): 1
interface Ethernet0/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes




Now we examine the routing tables.


R2#sh ip route eigrp
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:02:42, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:02:42, Serial1/0




R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:03:55, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:03:55, Ethernet0/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:03:55, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:03:55, Ethernet0/0

So, only R3 is seeing the leaked networks now, and R2 hasn’t.



Policy 3:
Allow R3 access to 5.5.0.0/24 and 5.5.1.0/24 networks only.
Allow R4 access to 5.5.2.0/24 and 5.5.3.0/24 only.


So we’ll match the other two routes in another access-list and match that and Interface S1/0

On R1:
route-map EIGRP_LEAK permit 20
match ip address 2
match interface s1/0


R1#sh route-map
route-map EIGRP_LEAK, permit, sequence 10
Match clauses:
ip address (access-lists): 1
interface Ethernet0/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map EIGRP_LEAK, permit, sequence 20
Match clauses:
ip address (access-lists): 2
interface Serial1/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes


Now we examine the routing tables.






R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:05:48, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:05:48, Ethernet0/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:05:48, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:05:48, Ethernet0/0



R2#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.2.0 [170/2560537856] via 150.1.12.1, 00:00:25, Serial1/0
D EX 5.5.3.0 [170/2560537856] via 150.1.12.1, 00:00:25, Serial1/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:05:08, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:05:08, Serial1/0

Lets test connectivity




Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/58/80 ms
R3#ping 5.5.1.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/60/84 ms


R2#ping 5.5.2.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.2.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/68/96 ms
R2#ping 5.5.3.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.3.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/58/80 ms


Policy 4:
Add a loopback0 3.3.0.0/24 on R3. Allow R3 to reach RIP networks when sourced from Loopback 0.

Well this is to emphasize the point that we need to consider all implications of the configuration we make.
Since R1 is a stub connected router, towards R4 it is advertising 150.1.13.0/24 and 150.1.12.0/24 networks which are directly connected, which are then redistributed into RIP and hence R3 and R1 can ping R5’s loopbacks.
But R3’s loopback won’t be advertised to R4 and until we add another route-map entry leaking this network to R4, we won’t be able to reach to R5’s loopback networks from R3’s loopback network.

Lets see this



R3:
int lo 0
ip add 3.3.0.3 255.255.255.0
router eigrp 10
net 3.3.0.3 0.0.0.0


R3#ping 5.5.0.5 source lo 0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.0.5, timeout is 2 seconds:
Packet sent with a source address of 3.3.0.3
.....

Success rate is 0 percent (0/5)


Now we add another route-map Entry to allow 3.3.0.0/24 network to leak to R4.

R1:
access-list 3 permit 3.3.0.0 0.0.0.255
route-map EIGRP_LEAK permit 30
match ip address 3
match interface e0/1





R4#sh ip route eigrp
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.0.0 [90/435200] via 150.1.14.1, 00:00:28, Ethernet0/0
150.1.0.0/24 is subnetted, 4 subnets
D 150.1.13.0 [90/307200] via 150.1.14.1, 00:01:39, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.14.1, 00:01:39, Ethernet0/0


Now this network will be redistributed into rip and we’ll have connectivity.


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.0.5, timeout is 2 seconds:
Packet sent with a source address of 3.3.0.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/54/68 ms


Well that’s about it for EIGRP stub Leak Maps.
Please let me know if you find any ambiguity.

A lot of people work differently, and when it comes to preparing for CCIE lab everyone has a different strategy.

Me, I am more of a reader than a handyman :) that is to say, I spend most of the time reading and far less time labbing. Even in the time I lab, I spend most of time making short labs, testing technologies than doing full scale labs. One reason is that I only have 10 dynamips IEWB full scale labs and I already did them twice anyway.

Recently I requested Brian Mcghann and Petr from InternetworkExpert to allow me access to their Vol 1 Beta labs and very generously they did. I am a customer of IE but due to financial constraints, I bought only first 10 dynamips labs and so the vol 1 beta access wasn’t automatically there for me.
While I am going through the labs, I must say I am impressed and there is also a feeling of déjà vu. My company financed Narbik’ bootcamp and hence I received his advance technologies workbook. I loved that. Basically Narbik took a technology and beat that to death. Quite similar approach of these Beta labs. When it comes to me, I’d prefer such approach above all other that is to learn everything about a technology rather than doing 40 full scale labs. Even before I went to Narbik’s bootcamp, my method of preparation was to read say 15 pages of documentation a day, and lab them up in small labs on dynamips. Narbik’s labs saved time I spent for cooking up a topology to test a feature.

I have not seen existing versions of Vol 1, but from what I heard those were very basic. These beta labs are not.

Though I am waiting for OSPF, security and QOS Vol 1 labs, and only after that I can rate these VOL 1 labs completely, I have to admit, I really liked these labs up till now. I even learned one new feature of EIGRP which is EIGRP stub routing with leak maps. If I were to advise anyone on how to prepare, my advice would be to go through Narbik’s Advance Technologies Workbook or( if by that time these VOL 1 labs are out) these VOL 1 beta labs, very slowly.

Do each technology in a week, and not only do the labs, read documentation about every feature and learn it properly. And at the end, do 10-20 full scale labs.

Anyway here are my initial impressions of the labs.



Bridging and Switching:

As I mentioned, my idea of technology labs is to cover all about a technology.

I feel bridging and switching sections should include small labs on following topics

IRB (Integrated Routing and Bridging). Of course, we’ll use routers for this J but technology wise the feature should be here
DAI (Dynamic Arp Inspection) (Though this topic can be potentially included in security. As I mentioned I need to see the security and QOS, before having a complete idea, as many feature I’d like to see can fall under switching as well as under these two topics. For me, DAI is more of a switching topic.)
MVR (Multicast VLAN Registration) And IGMP snooping, IGMP Profile commands etc. But then again, these features may have been covered in Multicast sections. Also IGMP snooping and DAI are inter-related, so for me these should be a part of switching.
SDM Templates
More explanation in lab 1.18. Trunk ether channel over DOT 1 Q tunnel can cause a lot of problems, if we are not sure of STP and VTP paths throughout our network. Instead of shutting down the links that can cause problems, these problems should be explored.
Port Security. ( Again, can be covered in security beta labs)


Frame Relay:

I again learned a new feature, bridging over frame relay and I thought I knew everything about frame relay.

Excellent


RIP:



Excellent labs,

Covering all the topics I think are necessary to learn RIP.



EIGRP:

I learned a new feature here. I can’t make it work though on dynamics unless I add the match interface option in Eigrp Stub Leak Route map.

This needs more research on my part though.

I’ll lab this up over the weekend, and maybe right a tutorial after understanding the feature completely.





Also, I believe strategy wise, IE is on right track.

I’ve known people going through full scale labs rigorously. This approach of learning everything, before doing full scale labs is what I’d recommend and I’ve followed.



I am really looking forward to QOS section, especially Catalyst QOS.

Let’s see how comprehensive those labs would be.

.
.

Unicast Reverse Path Forwarding is a small security feature
When configured on an interface, the router checks the incoming packet’s source address with its routing table. If the incoming packet’s source is reachable via the same interface it was received on, the packet is allowed. URPF provides protection again spoofed packets with unverifiable source.
Though basically a single line command, URPF can be a little confusing when used with access-list feature if order of operation is not understood completely.
We’ll use this simple topology to demonstrate URFP.





R1 and R2 are connected through frame-relay and a Ethernet connection.
We test our basic connectivity.

R2#ping 150.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/93/192 ms

R1#ping 150.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/45/84 ms

R1#ping 150.1.21.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/100 ms

All right we have reachability on both Ethernet and frame relay interfaces.
In order to demonstrate URPF we use two static routes on R1 and R2.
R1 uses frame-relay to reach R2’s loop back (2.2.2.2/24) and R2 user Ethernet to reach R1’s Loopback (1.1.1.1/24)

R1(config)#ip route 2.2.2.0 255.255.255.0 150.1.12.2
R2(config)#ip route 1.1.1.0 255.255.255.0 150.1.21.1

Without URPF, we should be able to ping R2’s loopback from R1’s loopback.

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms


Now we enable URPF on frame-relay interface on R2.
Now when the incoming packet arrives at the frame interface, R2 checks the source address (1.1.1.1/24) in its routing table.
Since the interface used to reach this address is Ethernet0/0 , URPF checks fail and ping is not successful.

!
interface S1/0
ip address 150.1.12.2 255.255.255.0
ip verify unicast reverse-path

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)


All right!
This was the most simple part.
Now we use URPF with an access-list.

Understanding URPF Order of Operation:

Here we have to understand the order of operations.

1) When packet arrives at the interface, URPF check is done. If the check is successful, the packet is transmitted, and ACL doesn’t come into play
2) If the check is failed, ACL is consulted. Traffic is allowed or denied based on ACL entries.
3) The thing to understand here is that an ACL with deny any any will not mean that all traffic is denied. It won’t come into play unless the URPF check is failed. If URPF check is successful all traffic is allowed. If it is failed then ACL is checked an traffic is allowed or denied based on the ACL.

R2:
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.
ip verify unicast reverse-path 101

access-list 101 permit tcp any any
access-list 101 deny ip any any log-input

Here we are allowing the TCP traffic and denying all other traffic in ACL.
It means that a telnet sourced from the LoopBack 0 of R1 to LoopBack 0 of R2 will be successful, but all other traffic will be denied.

From R1:
R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ... Open


Password required, but none set

[Connection to 2.2.2.2 closed by foreign host]

Success rate is 0 percent (0/5)
R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)


Below is the log generated by ACL.

*Mar 1 00:16:40.171: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 (Serial1/0 ) -> 2.2.2.2 (0/0),

Now lets ping the loopback with source frame-relay interface.

R1#ping 2.2.2.2 source S1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

As you can see that though ACL is denying all ICMP traffic our ping is successful.
For the simple reason that ACL won’t be checked until URPF check is failed. And in the above case, it’s successful.


Now lets change the ACL.
Now our intention is to allow HTTP traffic between the loopbacks as well as ICMP traffic and deny all other traffic.

R2:
access-list 101 permit tcp any any eq www
access-list 101 permit icmp any any
access-list 101 deny ip any any log-input

We’ll be able to ping or telnet at port 80 but regular telnet will fail

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/57/80 ms
R1#telnet 2.2.2.2 80 /source-interface loopback 0
Trying 2.2.2.2, 80 ... Open


R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ...
% Connection timed out; remote host not responding

R2: (:Log)
*Mar 1 00:20:18.895: %SEC-6-IPACCESSLOGP: list 101 denied tcp 1.1.1.1(35617) (S
erial1/0 ) -> 2.2.2.2(23), 1 packet


Well thats about it for URPF.
In lab exam if the feature shows up, be careful, as it can break connectivity if routers have asymmetrical routing.
Asymmetrical routing is not a problem in LAB generally as long as we have connectivity, but with URPF enabled, asymmetrical routing will break connectivity.
In that case,we can either tune unicast routing table or use the access-list with URPF to allow for connectivity.

.
.
.
Bridging is an obscure topic in CCIE R&S study.
It can be divided in three types

1) IRB (Integrated Routing and Bridging)
2) CRB (Concurrent Routing and Bridging
3) Fall back bridging

IRB is discussed in Lab 3 of internetworkExpert labs.

Basically IRB and CRB are generally used on routers to bridging different VLAN domains. If IRB is used, we can route IP over these bridged interfaces. The topic that is least discussed is Fall Back Bridging that we configure on switches. It is basically for non-IP traffic, and thats why chances of it appearing on the LAB are slim.
But since nowadays obscure topics are my thing as I am pretty much done with the core, in fact back in April Narbik and all my fellow bootcampers urged me to take the lab immediately saying that I was more than ready and worried about things which I should not.
But my Lab date is September 18th and by that time, I want to be prepared in every thing. One of such things is Fall Back bridging, so that if by chance it shows up, i am ready to tackle it.
Other topics about which Iĺl try to write tutorials are in my post below this one.

I’ll be demonstrating how fall-back bridging works using this example. SW1 has VLAN 11 and VLAN 22 defined and R1 and R2 are in VLAN 11 and 22 respectively. R3 and R4 are connected to switch ports Fa0/3 and fa0/4 and I’ll be demonstrating how fall back bridging works using this example.


Topology Diagram:






SW1 is 3550.
3560 behaves identically

SW1 has VLAN 11 and VLAN 22 defined and R1 and R2 are in vlan 11 and 22 respectively.
R3 and R4 are connected to switch ports Fa0/3 and fa0/4 and VLANS are not defined.
For simplicity the mac-address are as follows.
R1 F0/0 = 0000.0000.001
R2 F0/0 = 0000.0000.002
R3 F0/0 = 0000.0000.003
R4 F0/0 = 0000.0000.004


Our goal here is to make all four router bridge the non-ip traffic between them where as R1 and R2 are in VLAN 11 and 12 respectively and R3 and R4 are not in any vlan.

The configuration of switchports connecting to R1 and R2 are as follows
!
interface FastEthernet0/1
description To R1 F0/0
switchport access vlan 11
!
interface FastEthernet0/2
description To R3 F0/0
switchport access vlan 22

To enable bridging on the physical port first we have to issue no-switchport command on physical interface.
Interface fa0/3 and fa0/4 here.
Here is the configuration of these ports.


!
interface FastEthernet0/3
description To R3 F0/0
no switchport
no ip address
!
interface FastEthernet0/4
no switchport
no ip address
end


Now we configure our fall back bridging.
For R1 and R2 the bridging will be configured under SVIs and for R3 and R4 under physical interface

SW1(config)#bridge 1 protocol vlan-bridge
SW1(config)#int vlan 11
SW1(config-if)#bridge-group 1
SW1(config-if)#int vlan 22
SW1(config-if)#bridge-group 1
SW1(config-if)#int fa0/3
SW1(config-if)#bridge-group 1
SW1(config-if)#int fa0/4
SW1(config-if)#bridge-group 1


And we are done with simple fall back bridging.
For verification, we will simulate an IPX network.

SW1#sh bridge group
Bridge Group 1 is running the VLAN Bridge compatible Spanning Tree protocol
Port 25 (FastEthernet0/3) of bridge group 1 is forwarding
Port 26 (FastEthernet0/4) of bridge group 1 is forwarding
Port 22 (Vlan11) of bridge group 1 is forwarding
Port 23 (Vlan22) of bridge group 1 is forwarding


On R1:
R1(config)#ipx routing
R1(config)#int Fa0/0
R1(config-if)#ipx net
R1(config-if)#ipx netwo
R1(config-if)#ipx network ABC
R1(config-if)#ipx encapsulation sap
R1(config-if)#do sh ipx int f0/0
FastEthernet0/0 is up, line protocol is up
IPX address is ABC.0000.0000.0001, SAP




Similarly on R2, R3 and R4
Our IPX address are as follows
R1: ABC.0000.0000.0001
R2: ABC.0000.0000.0002
R3: ABC.0000.0000.0003
R4: ABC.0000.0000.0004

We will ping from R1 to all other routers and also monitor the bridge group table.


R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0002
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0002, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/66/192 ms
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0003
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0003, timeout is 2 seconds:
!!!!!
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0004
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0004, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/48/72 ms
Finally the bridging table on switch


SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self

Bridge Group 1:

Address Action Interface Age RX count TX count
0000.0000.0001 forward Vlan11 0 20 15
0000.0000.0002 forward Vlan22 0 10 5
0000.0000.0003 forward FastEthernet0/3 0 6 5
0000.0000.0004 forward FastEthernet0/4 0 5 4



Now we’ll play with some features.

By default the mac-address are learned dynamically.
We can discard a mac-address, and force a router out of bridge group.
Lets discard R4’s mac address.


This will be done with the following command

SW1(config)#bridge 1 address 0000.0000.0004 discard
SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self

Bridge Group 1:
Address Action Interface Age RX count TX count
0000.0000.0001 forward Vlan11 2 20 15
0000.0000.0002 forward Vlan22 3 10 5
0000.0000.0003 forward FastEthernet0/3 3 6 5
0000.0000.0004 discard - P 5 4



Now R1 should not be able to communicate with R4 but still be communicating with R2 and R3.
Lets test this.

R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0004
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0004, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0003
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0003, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/58/168 ms


All right!
Now we can also change the behavior of dynamic learning by using “no bridge 1 acquire” command.
In that case, we have to manually add the mac-address we want to communicate with.
Lets do this and we’ll not manually add R2ś mac-address.

Weĺl see that R1 can ping R1 and R3 and R4 but not R2.

SW1(config)#no bridge 1 address 0000.0000.0004 discard
SW1(config)#no bridge 1 acquire
SW1(config)#do clear arp
SW1(config)#do sh bridge
Total of 300 station blocks, 300 free
Codes: P - permanent, S - self

All right all addresses have gone now.


Now we add

SW1(config)#bridge 1 address 0000.0000.0001 forward vlan 11
SW1(config)#bridge 1 address 0000.0000.0003 forward fastEthernet
SW1(config)#bridge 1 address 0000.0000.0004 forward

We can specify interface if we want, to avoid unnecessary broadcast. But this is not essential for communication.
Let’s see the bridge table now.


SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self
Bridge Group 1:
Address Action Interface Age RX count TX count
0000.0000.0001 forward Vlan11 P 0 0
0000.0000.0002 discard Vlan22 0 0 0
0000.0000.0003 forward FastEthernet1/3 P 0 0
0000.0000.0004 forward - P 0 0



As you can see that R2 mac address is being discarded.
As after no bridge 1 acquire, we need to manually add the mac-adresses.
Now we ping from R1 to R2 and R3 and R4.

R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0002
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0002, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0003
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0003, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/29/36 ms



Side Options:




Like spanning-tree we can modify forward time, hello time, and priority (for selecting root) by following commands


bridge 1 forward-time
bridge 1 hello-time
bridge 1 priority


Also under the interface we can modify cost and priority to choose the path to root-bridge


SW1(config-if)#bridge-group 1 priority
SW1(config-if)#bridge-group 1 path-cost


Also aging time in bridge group table can be modified using
SW1(config)#bridge 1 aging-time ?
<10-1000000> Seconds




That’s pretty much it for fall back bridging.
For IRB (Integrated Routing and Bridging) and CRB (Concurrent Routing and Bridging) IE LAB 3 has a good write-up, which should be enough for understanding

Note:

Any readers, this is my first attempt at writing a tutorial.
Please let me know if it was helpful.

Had been away from posting for a while.
Here is a summary of last 3 months.
Went to NArbik's bootcamp and was a great experience.
Lab scheduled at September 18th.
And pretty much done with core topics.
Now i'll be doing some side topics for a month, and posting some tutorials here...
Here are the Topics I am looking for to complete within this month

L2:
L2 tunnelling *
Bridging ( IRB, CRB, Fall back bridging)*
Cat QOS ( SRR and WRR Queuing, Aggregate Policer, 3560 Buffer allocations, Caveats)
Catalyst Flow Control *

Frame-relay DEs.

L3:
Protocol Timers.

Multicast :
Some little features

IP Services/ Security:
WCCP *
DRP Servers
URFP *
CBAC *
Reflexive ACLs *



* About these topics, I'll try to write short tutorials as well.

Here is a scenario I cooked up for redistribution. I’ve tried to make it as complex as possible but addressing is kept simple.









Hmmm similar scenario but EIGRP and OSPF here.
Unlike last time we wont have a problem unless EIGRP has an external route.
In that case, we have to filter that in OSPF so that at R7, we prefer or native routes of EIGRP.
Remember HIGHER to LOWER we need to take care, if domains have more than one meeting points.

At the end of this step, we’ll have reachability between R10->R5->R1 and vice versa.

Now we go to double point of redistribution.

At R6 and R7:

I'll be attending Narbik's bootcamp in April in Dubai.

Though I'd have much preferred to attend a bootcamp in July or August after finishing all IEWB labs and say a month before my Lab, but there is an uncertainty about later lab dates in Dubai .

My new Tentative Schedule about labbing is
Plus now my plan is to complete 12 IEWB labs before the bootcamp.
Come back spend a month (May) on Narbik's work book.
June will be for the remaining 8 IEWB labs.
July will be for repeition IEWB labs with difficulty 7 and higher.
Plus since I save the config just before redistribution, I may do other labs IGP onwards.
August will be dedciated to 2 mock labs (IEWB and CCIE accessor) and Narbik's work book revision.
I May attend Narbik's bootcamp around September again, just before going to the lab.

I am getting better at redistribution or at least thinking so.

I complete LAB 7 ( yes I am not doing labs in order) and Lab 6 uptil BGP.And though redistibution gave me a headache a i spent like 2 hours on each task, I did them right. What more, I did those in my own way, which is quite different from the Solution Guide.

After sweating a lot , I think I am slowly adopting a strategic approcah towards redistribution.

The way I see it is that we have to have a method before starting redistribution.I used to ignore suboptimal paths and try to tag everything, but now I have realized that going through a step by step process, eliminating loops and suboptimal paths at each step is the way to go.

Here is the methodology that has been working for me



1) Identify one of the routing domains as core routing domain. It doesn't matter which protocol it is. For me its the largest domain, which normally sits in the centre of topology.



2) Identify if there has to be redistrbution between non core or edge domains.If so, do that first. Again making sure that if two domains have more than one rendezvous point, they keep preferring their native routes. ( Doesn't matter if redistrbution is done on a single point or two. Avoid routes to get back in



3) Ensure connectivity on the edge domains.Also ensure that native paths are preferred.



4) Now redistribute between core and edge domains.Single point of redistribution first, and verify connectivity.Again, make sure that native routes are preferred. (AD or tagging)



5) If there are more than onr points of redistribution between core domain and edge domain, tag at one and deny the routes getting back at the other point and vice versa.



6)Make sure that before redistribution, if there was a 'redistribute connected' command used to advertise a loopback or a connected link, you modify it so that no interface that is supposed to be redistributed in left out.



For example R1 is a border router between OSPF and Eigrp. R1 runs EIGRP at serial and OSPF at ethernet. If I advertised R1's loopback in EIGRP through redistribution at an earlier stage, then during OSPF->EIGRP redistribution the ethernet interface won't be advertised, which should be as its running OSPF.

Workaround is simple, go to the route-map and make changes according.



What this approach does?

Well first of all we'll have connectivity between the edge domains.Then we'll inject routes from core into edge domains, making sure that core domain, within itself prefers its own routes and also edge domains prefer their own routes.There will be no loop (hopefully) and routing will be optimal, as each domain is preferring its native routes. Plus if we encounter any loop, it'd be easy to find out after which step the loop is occured.

It'd be easy to troubleshoot and worst case scenario, we can eliminate the step that resulted in a loop maintaining end to end reachability.



There is some problem with my Visio.I'll make a topology later and explain the process, through that. I could use an internetworkexpert topology, but I am not sure that'd be all right due to copy right issues. Though all I want to do here is borrow a diagram :S

Well
Its been three days and since BGP regex, the worst time I had in CCIE Prep.

The task is InternetworkExpert Lab2 , task 4.11 Redistribution.
I am stuck and have tried to read whatever I could find regarding this task but just cant, cant do it right.
When the backup interface is up, the solution is SG doesn't work. And ofcourse when backup link is down, full reachability isn't there.
I am going nuts.

Thinking again, maybe I am not CCIE material maybe:(