Chronicles of CCIE journey

My new Blog

2009-09-01T04:25:00.001-07:00

Moving Here

http://iptechtalk.wordpress.com

Dear Vendors, Why hast thou forsaken SP?

2008-09-24T04:11:00.000-07:00

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.

CCIE Lab Preparation, My personal path and Recommendations

2008-09-22T15:08:00.000-07:00

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.

About the lab.

2008-09-18T15:16:00.001-07:00

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.

CCIE # 22087

2008-09-18T15:16:00.000-07:00

Yes, I passed.

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

EIGRP Stub Leak Map -- Tutorial

2008-07-15T15:44:00.000-07:00

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.

IEWB VOL 1 VER 5, Early Impressions

2008-07-15T04:53:00.000-07:00

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.

Understanding URPF (Tutorial)

2008-06-29T00:53:00.000-07:00

.
.

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.

Fall Back Bridging Tutorial

2008-06-25T10:33:00.000-07:00

.
.
.
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.

Update: There will be updates :D

2008-06-23T01:21:00.000-07:00

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.

Using a strategic Approach to Redistribution: An example

2008-03-09T11:23:00.000-07:00

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

We have EIGRP between R1 and R2 over network 150.1.10/24
We have RIP running on Ethernet between R2 and R3, on serial link (150.1.3.0/24) between R3 and R4 and Ethernet Network between R4 and R5.
OSPF is running on two frame relay networks between R3, R4 and R6, Serial link between R6 and R7 and frame relay link between R 7 and R9.
Also we have RIP on R8’s two networks to R6 and R7
And EIGRP between R9 and R10 Ethernet network and R9 and R7’s frame relay link.

We have to redistribute between EIGRP and RIP at R2, RIP and OSPF at R3, R6, R7, EIGRP and OSPF at R9

According to the strategic approach
1) We first identify our core domain.

Its easy. OSPF sits in the middle, and connects to most other domains.

2) Now we start redistribution

At R2

The methodology is to first do the redistribution if necessary between non core domains.
Hmmm R2 is a single rendezvous point between RIP and EIGRP. SO no problems we can safely have mutual redistribution.
After this step we should have reachability between R1 and R5.

Well all other points involve core domains. Let’s start with single point of redistribution among domains.

At R3:

At R3 we redistribute between OSPF and RIP.
There should be no problem right because a single point of redistribution right?

Well LOOK again.
As a rule we should prefer the native routes. R3 has a RIP route to 150.1.1.0/24 network, which was redistributed in RIP. Now this route is redistributed in OSPF and will reach R4 via OSPF and get installed there.
Immediately we’ll have a loop.
The exact same scenario for networks 150.1.4.0/24 and beyond will occur. R3 had that as RIP route from R4 and redistributed them in OSPF, and they will get fed back at R4 at OSPF routes.

So again we should remember that

“If two routing domains have more that one rendezvous points, even if redistribution is done at a single point make sure that both domains prefer their native routes.”

So with a little foresight, all we need to do is to tag routes going to OSPF on R3 and filter them in OSPF process on R4. ( Distribute-list route-map)
We can also match the routes and lower the admin distance to 109 on R4, but simple tagging seems easier to understand here. Also we can just lower the admin distance of all RIP routes on R4, but as personal rule, I stay away from that. If I know what route is going to cause problem, that’s the route I’ll play with.

At the end of this step R1 and R5 should have reach ability to all OSPF routes.
Lets go to R9 now because a single point of redistribution.
At R9:

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:

Lets say R6 loop back is running RIP as well.

If we understand the problem we faced at R3 we should have no problem here.
On both routers we tag routes during the redistribution and deny those routes getting back into. starting with R6, a simple redistribution would mean that apart from connected routes, now R7 would prefer the route to R6 loopback through R6. We don’t want that, as we always prefer native routes. We can just match the route, make its admin distance less than ospf on both R6 and R7 and we'll be ok.

We wont even need tagging and denying here even.

As Both routers will prefer their native OSPF paths by design, and the RIP native paths because we changed the AD.

When Rip routes are fed into OSPF for example at R6, at R7 it wont be fed back because the route wont be in routing table as an OSPF route but rather as a RIP route.

Btw, being paranoid, I always tag and deny at dual point of redistribution anyway :)

One thing haven’t added here, is that if we redistribute any network/connected route prior to the redistribution question, we should always remember that we are breaking “Inherent redistribute connected of redistribution process.”
We should always modify our route maps to make the process complete.
For example, if at R2 we redistributed a loop back network into rip, the connected interface running EIGRP will not be redistributed here. We should modify the route map we used to redistribute the loop back and add serial interface in that.

P.S
This is a document for self reference.
But if anyone reads it and maybe have a redistribution problem, I’ll be glad rather thankful to look at that and use this approach to see how things work.
I used the same approach on IEWB labs 5 – 15 (no I haven’t completed those), just by looking at the diagram and question and then looking at the solution. Each time, I found that though my methods may be different, solution essentially takes the same loop prevention measures.

This is when I haven’t even configured the network. :P

And apart from IEWB lab 2 scenario, (which involves a backup link), I think the approach will always work. I need to lab that scenario again, but the backup links just adds a whole new level of complexity because in that case, we have to be aware of a route that isn't there :D

Just by looking at the diagram and question and having a little foresight we can already predict and avoid potential problems before they occur.

Going to Narbik's Bootcamp

2008-03-07T15:20:00.000-08:00

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.

A Strategic Approach to Redistribution

2008-03-07T06:56:00.000-08:00

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

Hell hath no fury Like a redistribution gone wrong

2008-02-14T17:02:00.000-08:00

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:(

Break

2007-11-14T01:04:00.000-08:00

Have not been writing. Well, I am and will be on break during November. Annual Leaves and Sister's Wedding :)

BGP communties Problem. Solved, and a lesson to learn

2007-10-19T18:20:00.000-07:00

Well, everyone always talks about knowing the technology well and that exactly was the problem :P
BGP community attributes are non-transitive, means WE HAVE TO SEND THESE TO OTHER BGP SPEAKERS, EVEN IBGP SPEAKERS

I wasn't sending the attribute from R3 to R1 and viceversa :S
Though a lot of time wasted, but a lesson to learn :)
KNOW your technologies well

BGP communties problem

2007-10-19T10:43:00.000-07:00

Here is the scenario diagram…

Objective:
Configure using community No-Export so that hosts on R3’s Ethernet have access to VLANs 5 and 43 but AS 1 and AS 3 cannot reach VLANs 43 and 5 respectively.

Here is my configuration of R4 and R5
R5:
router bgp 1
no synchronization
bgp log-neighbor-changes
network 155.1.5.0 mask 255.255.255.0
neighbor 155.1.0.2 remote-as 2
neighbor 155.1.0.2 send-community
neighbor 155.1.0.2 route-map SET-COMMUNITY out
no auto-summary
!
access-list 1 permit 155.1.5.0 0.0.0.255
!
route-map SET-COMMUNITY permit 10
match ip address 1
set community no-export
!
route-map SET-COMMUNITY permit 20

R4:

router bgp 3
no synchronization
bgp log-neighbor-changes
network 204.12.1.0
neighbor 155.1.146.1 remote-as 2
neighbor 155.1.146.1 send-community
neighbor 155.1.146.1 route-map SET-COMMUNITY out
no auto-summary
!
access-list 1 permit 204.12.1.0 0.0.0.255
!
route-map SET-COMMUNITY permit 10
match ip address 1
set community no-export
!
route-map SET-COMMUNITY permit 20
!

Now everything appears to be fine as I check on R1 and R2 which are neighbors of R4 and R5 respectively

R1#sh ip bgp 204.12.1.0
BGP routing table entry for 204.12.1.0/24, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to
EBGP peer)
Advertised to update-groups:
1
3
155.1.146.4 from 155.1.146.4 (204.12.1.4)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export

And

R2#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to
EBGP peer)
Advertised to update-groups:
2
1
155.1.0.5 from 155.1.0.5 (155.1.5.5)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export

But still R5 and R4 see these routes in their routing table and are able to ping each other…

R4#show ip bgp
BGP table version is 8, local router ID is 204.12.1.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
*> 155.1.5.0/24 155.1.146.1 0 2 1 i
*> 155.1.37.0/24 155.1.146.1 0 2 i
*> 204.12.1.0 0.0.0.0 0 32768 i

Now R4 shouldn’t be able to see 155.1.5.0/24 network but it does :S

R4#ping 155.1.5.5 source 204.12.1.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 204.12.1.4
!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 108/213/316 m

Same is the case with R5. It sees and reaches network advertised by R4…
Any help will be appreciated…

Seems eveyone has bad times, not just me :P

2007-10-18T18:17:00.001-07:00

I had a torrid time with BGP regular expressions...
Maybe I was going in too much detail but the bottom line is that I had to stop. I took a week's break, which fit perfectly with Eid and Holidays and after that I am back to studies...
Did quite a bit of BGP, 3 more days and hopefully it'll be done.
During the period when I was down, reading other blogs, I realized that everyone stumbles on CCIE journey... At least CCIEPURSUIT and ETHAN BANKS suggest that.
These and other blogs have been not only a means of great info, but also motivation.
Can't thank them enough

Its such a good feeling: Of not being the only person who suffers on the way. I actually thought of myself as a complete buffon :P Not now, I am back on track. This months Targets: Complete BGP and Multicast.

BGP AS Path filters are making me wish I were never born :(

2007-10-07T09:50:00.000-07:00

I've been putting off prefix based BGP filteting throughout my networking life.
I never worked in an ISP, my work mostly comprised of Enterprise campus and data networks design, implementation and support and a lots of compressed voice over ATM, for GSM providers.
So, I never cared for BGP as such. Read a little, and read enough for CCNP.
NOW, when I am trying to get through BGP in detail, I just cannot ...
Maybe its a bad week :S
Maybe its Ramadan and because of fasting, during the day I cannot concentrate.
Maybe because in the night, I smoke like a chimney to account for the whole day passed without a smoke and it messes with my head.
Whatever the reason is, BGP stares in my face like the big monster :(
Before I started the prep, my initial thought was that QOS and Multicast will give me a hard time.
Now it looks, I may never be able to complete BGP.
Its been such a bad day, and from the looks of it, next week won't be better even

Status Update

2007-09-29T05:24:00.000-07:00

Again a very good week.
My targets were to cover OSPF and IGP redistrbution, and I was able to complete these.
OSPF took more time than I imagined, and redistrbution a lot lesser.
Maybe since I am only doing advance technology labs for the while and network is never too complex, redistrbution has been easy.
Next Week Targets: BGP (basic), Multicast.

OSPF Network Type Loopback

2007-09-25T14:38:00.000-07:00

Reading across, I found something I didnt know and which I think is very cool.

Ref to RFC 2328

" looped back.
The interface may be looped back in hardware or software. The interface will be unavailable for regular data traffic. However, it may still be desirable to gain information on the quality of this interface, either through sending ICMP pings to the interface or through something like a bit error test. For this reason, IP packets may still be addressed to an interface in Loopback state. To facilitate this, such interfaces are advertised in router-LSAs as single host routes, whose destination is the IP interface address.[4]"

Which simply means that no matter what is the subent mask of my loopback address, it'll be advertised as host route in the OSPF domain, or say a loopback of 1.1.1.1/8 will appear as
"1.0.0.0/32 is subnetted, 1 subnets"

SO, what if I want my actual subnet mask to be advertised ?
All i have to do is to put "ip ospf network point-to-point" in loopback interface config.

A good week

2007-09-20T11:51:00.000-07:00

Well while he previous week was hazardous in the sense that I couldn't do anything, this week has been good.
Completed almost everything related to switching, did IE advance technology switching labs. Also completed EIGRP, IE Eigrp advance technology labs and from the work book did arounf 6 or 7 random labs concerning EIGRP and Switching.

Next week Targets: OSPF, Route redistribution.

Something to cheer !

2007-09-04T14:57:00.000-07:00

Today, rather yesterday was bad day. Got to sleep at 6.A.m and was up at 11 again for office.
The series of fuck-ups continued.
In short, wasn't able to do anything with CAT6513's failed module.
CWM installation failed, even a solaris guy who graciously tried to help me couldn't know why. I keep cursing myself for recommeding this bloody NMS to customer. If only I knew I had to install it :( and I wish for once things happen the way installation documentation says they'd.

Came back home at 6 and decided to wrestle with dynamips. I've been foolishly asking around for dynamips help, and today I decided to give it a go.

From a bad day arrives my moment of cheer:)
I've been finaly able to get dynamips running and made .net files for firsr 4 IEWB labs :)
Its a different story that my notebook almost explodes at 6th router instant.

Tomorrow again after work, have to go to a dinner.
Lolzz, thought about backing out only to realize, it was me who invited all :D

Hopefully on thursday and Friday ( Weekend here) will get to complete switching at least.

A kick in the nads

2007-09-03T15:19:00.000-07:00

Last night, while chalking out my plans so ambitiously, i must have somehow offended god of the fucks ups.
Its 1:20 am in night and I am still at work.
16 port Gbic module for core switch has mysteriously gone down. From reseating, resetting, resetting SUPs to upgrading IOS I've tried everything. And nothing is working.
TAC engineer (I used to be awfully impressed by any one with email id ending at @cisco.com, but all illusions wither :D), who is an idiot, has no clue what he is suggesting.
And my employer thinks that because I am a 'Cisco guy', not solving this problem means I don't know anything.
Gosh, what does a hardware failure have to do with switching anyway. Anyway, unless we hear something definitve from TAC, there is no going home, which means, tomorrow is ruined already :D
Will start studying from Wednesday :P

Week 1 Targets ( 02/09/2007-07/09/2007)

2007-09-02T14:57:00.000-07:00

1) Read CCNP BCMSN excluding Wireless ( 2 Days)
2) Watch BSCI trainings (RIP, EIGRP, OSPF) (Thursday and Friday)
3) Pratice switching and these protocols (Wednesday and Friday)