CCIE R&S Pursuit

OSPF NSSA Translation

2009-05-29T14:45:00.003-05:00

Justin asked a question that I did not immediately have an answer to (thank you Justin). It had to do with OSPF NSSA translation. He was stating that a router (R6) in area 0 had received only one Type-5 LSA translated from an NSSA area, but the RIB showed two equal cost paths to reach the network. The setup is a box network with R6 generating the Type-7 LSA in area 1, R1 and R4 are ABR's for area 1 and R5 is in area 0. R1 is the 7->5 translator.

R5#sho ip route
...
155.0.0.0/24 is subnetted, 2 subnets
C 155.0.0.0 is directly connected, Serial0/0
160.0.0.0/24 is subnetted, 1 subnets
O E2 160.0.60.0 [110/20] via 155.0.0.4, 00:04:02, Serial0/0
[110/20] via 155.0.0.1, 00:04:02, Serial0/0
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 150.0.5.0/24 is directly connected, Loopback0
O IA 150.0.6.6/32 [110/75] via 155.0.0.4, 00:04:02, Serial0/0
[110/75] via 155.0.0.1, 00:04:02, Serial0/0
O IA 150.0.4.4/32 [110/65] via 155.0.0.4, 00:04:02, Serial0/0
O IA 150.0.1.1/32 [110/65] via 155.0.0.1, 00:04:02, Serial0/0

R5#sho ip ospf data
...
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
160.0.60.0 150.0.100.100 528 0x80000001 0x00DFE1 0

Well that's interesting. But what information does the LSA have in it?

R5#sho ip ospf data ext

OSPF Router with ID (150.0.5.5) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 649 Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 160.0.60.0 (External Network Number )
Advertising Router: 150.0.100.100
LS Seq Number: 80000001
Checksum: 0xDFE1
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 150.0.6.6
External Route Tag: 0

Ahh, the blessed Forwarding Address. Looking back at the routing table we do indeed have a route to 150.0.6.6, both to 155.0.0.1 and 155.0.0.4. So the routing table is updated that 160.0.60.0/24 can be reached equally by R1 and R4, even though R1 is the only one performing the translation.

Now is this OSPF performing this recursive lookup or is it the router? I filtered 150.0.6.6 from entering area 0 on both ABRs.

R1(config)#ip prefix-list plR6_out deny 150.0.6.6/32
R1(config)#ip prefix-list plR6_out permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#area 1 filter-list prefix plR6_out out

R4(config)#ip prefix-list plR6_out deny 150.0.6.6/32
R4(config)#ip prefix-list plR6_out permit 0.0.0.0/0 le 32
R4(config)#router ospf 1
R4(config-router)#area 1 filter-list prefix plR6_out out

R5#sho ip route
...
155.0.0.0/24 is subnetted, 2 subnets
C 155.0.0.0 is directly connected, Serial0/0
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 150.0.5.0/24 is directly connected, Loopback0
O IA 150.0.4.4/32 [110/65] via 155.0.0.4, 00:16:50, Serial0/0
O IA 150.0.1.1/32 [110/65] via 155.0.0.1, 00:16:50, Serial0/0

Both the external route and the route to 150.0.6.6 have been removed. Next I added a static route to 150.0.6.6 to see if the external route would reappear...

R5(config)#ip route 150.0.6.6 255.255.255.255 155.0.0.4
R5#sho ip route
...
155.0.0.0/24 is subnetted, 2 subnets
C 155.0.0.0 is directly connected, Serial0/0
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 150.0.5.0/24 is directly connected, Loopback0
S 150.0.6.6/32 [1/0] via 155.0.0.4
O IA 150.0.4.4/32 [110/65] via 155.0.0.4, 00:22:07, Serial0/0
O IA 150.0.1.1/32 [110/65] via 155.0.0.1, 00:22:07, Serial0/0

Well it would appear that the recursive lookup to the forwarding address in type-5 LSA's are indeed completely within the OSPF process. This means I can have all kinds of fun.

First I can have R1 perform 7->5 translation, but send all traffic to R4. To accomplish I filter the router ID of the Forwarding Address on R1. Bingo presto all traffic to R6 now travels through R4, including the external network being translated by R1. As a side note, there is no need for the static route on R5.

Next I could send the translated traffic to R4, but have R1 be the primary means to get to R6. The same setup is used previously filtering out 150.0.6.6 on R1, but on R5 I include a static route to 150.0.6.6 to 155.0.0.1 (R1).

Of course, this is all one way traffic as the return traffic is not affected. So one must make the same modifications in the reverse direction to ensure route symmetry.

Anthony

Up and running again

2009-05-21T15:58:00.002-05:00

So after some headaches and just straight lazyness I'm back on the horse. Maybe I'm trying to keep my pace too fast after coming home... Dunno, I'm a glutton for punishment.

Let me tell you, the new comp is great BTW. Everything I've wanted in a computer for a while now. At this point I'm not limited by my resources, but my imagination which in turn will be limited by resources once I think too big.

But this is a CCIE pursuit! I've finally completed the RIP labs. Everything was amazingly easy, if brain numbingly boring, except the last lab. I ran into a problem in a frame-relay hub and spoke where the hub was a multipoint sub-interface and the spokes were using their main interfaces. An additional PVC was provisioned between the spokes, but was implicitly not to be used. The frame-relay setup was easy (I've done it enought times by now). The overall objective was to originate a default route from the hub to the spokes and that is the only route advertised from the hub.

I could do this several ways, but I knew the intent was the default-information originate command under the RIP process and then using a distribute list to filter out all other routes outbound. Everything was working swimingly, except the hub was getting the default route from the spokes? Yup, it looked like split-horizon wasn't working. My first instinct was to filter out the default route, but allow all others inbound.

ip prefix-list no_default_in seq 5 permit 0.0.0.0/0 ge 1
!
router rip
distribute-list prefix no_default_in in

Worked like a champ, but I knew that wasn't the answer. Time to figure out why split-horizon wasn't working. First off, how does one check if split-horizon is even enabled? Burried deep within "show ip interface xxx" mentions something about split-horizon.

Spoke#sho ip int s0/0
Serial0/0 is up, line protocol is up
...
Split horizon is disabled
...

Huh, imagine that. Go into the interface and issue the command "ip split-horizon". Remove the inbound route-filter at the hub and everything is working as it should.

But I know what you're thinking... My daddy taught me that split-horizon is always on by default. Very true, except in two cases. It took me a while to find it, but I found the answer in "Cisco IOS IP Routing Protocols Command Reference". Go there to find the answer for yourself if you'd like.

So the RIP labs are done with. Rather than move onto multicast, I'm going to move onto OSPF. I don't want to start Multicast until after I've completed the BGP labs.

Anthony

Delayed and stuff...

2009-05-18T12:47:00.004-05:00

So I've been a little behind the curve lately as I try to setup a new computer and get everything back to normal. I'll probably get flamed for this, but my new computer is a Mac Pro. Now before you call me John Kerry I'll explain my choice.

First was function. I wanted a fairly powerful computer with many cores so that I could run very large topologies in Dynamips. There are some concepts that I have been wanting to try out in large partial meshed topologies and frankly my little 4 core laptop wasn't up to the task. The new Mac Pro has 8 cores w/ hyperthreading making a total of 16 "processors" available. I chose the 2.6Ghz model rather than the 2.9Ghz. Combined with 12GB of RAM, I have enough power and space to load many, many routers in all kinds of topologies.

But at the end of the day I prefer Windows, even if I have give OSX a chance the last couple of days. My opinion may sway as time goes on, but I still prefer Windows as of now. As all new Macs are Intel based you can load Windows, namely Vista and the new Windows 7. So I jumped on the Windows 7 bandwagon as it's free right now. Combined with an ATI 4870 video card and dual ViewSonic 21.5" monitors, I have a pretty rockin' setup. Yes, games run flawlessly in Windows on my new Mac Pro. Oops, I mean GNS3 runs awesome!

Next was price. To build even half of the same system would cost me ~3-4k for a decent rig. But I was able to build this for 4.8k. That's right, two quad core hyper-threaded processors, 12G DDR-3 ram, 4870, 1 TB HD for 4.8k. And I get the benefit of OSX and Windows on one machine.

Which brings me to my final reason. As I picked up an iPhone when I came back I've had a couple of ideas for some apps both for myself and of course to make money. The only legitimate place to do any software development is on a Mac. I was looking at a Mac mini for such development which would have put me back another $750+. So combining a decent PC and the Mac mini would put me roughly in the same ballpark as this one machine, but only have half the processing power. Granted, my upgrade path is smaller, but eVGA just announced an nVidia GTX 285 for the Mac to be released in June. That would be almost twice the graphics power that I have now and be Cuda capable (I'm interested in it). Or I could pick up another 4870 to install in crossfire (only useful in Windows at the moment).

All in all, I'm pretty happy with my purchase, if it was a little pricy and somewhat overkill.

Anthony

Today's goals

2009-05-14T07:44:00.002-05:00

Today goals are:

Complete RIP workbook
Complete Multicast workbook

Should be a fairly easy day with the exception of mBGP in the multicast workbook, but then again I need a challenge after the last couple of days.

Anthony

Today's a bust

2009-05-13T17:27:00.002-05:00

I started out the day saying I was going to do a little spring cleaning... that turned into sifting through a decade+ worth of crap. So far I have two full boxes (moving boxes mind you) of junk and old software and another box full of old documents I need to burn. My bed looks like a homeless garage sale is occuring and my new desk which was once fairly clean is now a repository for everything I think i need to keep, but probably will throw away in a couple of years (except the rubik's cube... you can always use one of those).

I'll see about getting a few labs going later tonight, but at this pace, I'm not so sure that's likely.

Anthony

The day closes

2009-05-12T18:55:00.002-05:00

Review of the goals for the day:

Complete remaining Frame-Relay workbook (success)
Complete EIGRP workbook (success)

Well then, things are starting to move along swimmingly. Frame-relay was simple, if not too simple. I still feel I'm missing something, unless it really is that easy (things rarely are).

As for EIGRP, fleshed out some obscure configurations such as unequal-cost load balancing and administrative distance manipulation. I've never been a fan of modifying the administrative distance and believe one can achieve the same goals through other means. Not that it doesn't have it's place, I just don't see it anymore with route tagging as useful as it is.

Speaking of route tagging, I ran into a weird problem today on my last lab. I had two routers (R4 & R5) with two loopbacks created on R5 for redistribution. One loopback was to be tagged, the other was not. I created my route-map and redistributed connected based upon that route-map. I then headed over to R4 to place an inbound distribute-list that only accepted the tagged loopback. As soon as I placed the distribute-list, the neighbor adjacencies reset (normal), but no route was filtered in the routing table. Cleared the routing table, no luck. Cleared the adjacencies again, no luck. Looking at each route I didn't see a tag. So I headed over to R5. Yep, everything looks right, but wait a minute, if R4 doesn't see any tagged routes, shouldn't all EIGRP routes be filtered? As it stood, no routes were filtered. This makes no sense...

Tried everything I could to filter those routes from resetting interfaces, completely rebuilding the route-maps, redistribution and distribute-lists, but nothing. I was about to call BS, again like with this morning's long troubleshooting exercise, but this time there was no italics or hidden information. This was configured correctly, but behaving abnormally. So, I reset the routers back to baseline and implemented again. Wouldn't you know it, it worked this time. I'm going to have to say this was a problem with GNS3 this time as I performed an initial config, removed it, reapplied it and still no love, but a reset of the routers and yet another reapply fixes the issue. So, again, a little problem caused a bunch of unnecessary troubleshooting. I guess that's what you get when the price is right (free).

Anthony

The things you learn the hard way...

2009-05-12T11:45:00.003-05:00

So I just spent the last hour trying to diagnose a problem... that didn't exist. Let me explain. I had an EIGRP lab that required me to implement unicast between two neighbors (R1 & R2) on a multi-access network with three neighbors (R1, R2 & R3). Simple enough I use the neighbor command under EIGRP on both neighbors (R1 & R2).

router eigrp 1
network 0.0.0.0
neighbor 10.0.0.x fa0/0

Sweet, there's a relationship, but the relationship with R3 went away, as I suspected. But upon review of the Verification section of the lab I see a network on R1 that came from R3! What? You mean I'm supposed to have a neighbor relationship with R3 on R1 and R2? So it's off to Cisco docs... debugs... forum trolling... all confirming what I believed to be the right answer. Once you use a neighbor statement on an interface it completely ignores multicast (one of the debug messages clearly says this).

R2#debug eigrp packets
R2#debug ip eigrp neighbor 1 10.0.0.3
IP Neighbor target enabled on AS 1 for 10.0.0.3
IP-EIGRP Neighbor Target Events debugging is on
*Mar 1 00:02:12.583: EIGRP: Received HELLO on FastEthernet0/0 nbr 10.0.0.3
*Mar 1 00:02:12.587: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 00:02:12.587: EIGRP: Ignore multicast Hello FastEthernet0/0 10.0.0.3

I even rebuilt the lab from scratch, same affect. Built it with completely different router platforms and IOS (went from 3745 w/ 12.4.23 to 2600XM w/12.3.26), again same symptom.

Ok, off to InternetworkExperts to clarify what the crap is going on when all of the sudden I notice at the top of the verification section a statement in italics that reads, "Before neighbor statements applied". Crap, scroll down and indeed there is an "After neighbor statements applied" and guess what, I had it right the whole time.

So lessons learned. EIGRP disables multicast discovery on an interface with a neighbor statement (kinda already knew that) and... read the italics (nay the entire verification section) BEFORE extensive troubleshooting. A perfect example of K.I.S.S.

Anthony

Day 2 - Ramping Up

2009-05-12T07:44:00.002-05:00

Today's goals are:

Complete remaining Frame-Relay workbook
Complete EIGRP workbook

Pretty ambitious goals for my second day, but I think I can get through it. Going to need to start using the new Cisco documentation today as well. I've looked at some of the labs for today and I'm not sure how to implement some of them. Rather than cheating by looking at the end of the lab, I'd much rather begin learning how to locate resources on the documentation I'll be presented during the lab.

Anthony

Day one comes to a close

2009-05-11T20:38:00.002-05:00

It's been a long and interesting day. I learned a few things both technically and about myself.

My goals for today were to complete a baseline clonable topology for GNS3. I soon realized that a full scale topology was not needed as the individual labs in IE Workbook v1 only use a few devices each time. So far in the Frame Relay (more on that later) book I have used the same topology over and over again, but with only two routers. I found it very easy to create a base config that only included basics (such as router name, turning off domain lookup (I HATE DOMAIN LOOKUP!)) and write mem it. Config up a lab, but don't write it. When it works, just stop the routers and restart them, back to the base config in 30 seconds. So did I accomplish this goal? Technically no, but I found a more efficient way to perform labs consecutively.

The second goal was to begin with the EIGRP labs. Again, failure, but for good reason. I thought EIGRP would be a good starting ground, but I have a severe lack in knowledge in Frame Relay and several EIGRP labs require working Frame Relay. So I've started there. Was able to get through all two-router scenarios without cheating. Will complete the Frame Relay workbook tomorrow which includes 5 labs designed around Hub-and-Spoke.

What did I learn about Frame Relay? It's not as intimidating as I once thought. It's complexity lies in it's many ways to do the same thing, namely how to identify a distant router by a layer-2 address (DLCI) and then how to make a layer-2 to layer-3 mapping either statically or dynamically. Ultimately it's just an interface that can receive many different layer-2 frames from different senders. It's how you want the router to interpret those frames and make routing decisions based upon that.

As such I can see the need for both point-to-point and multipoint initially. Point-to-point makes life easier to understand as a DLCI only points to one distant router eliminating complexities such as split horizon, but required the use of exceedingly more IP addresses, even using /31 addressing. Multipoint allowed one IP address to talk to all distant routers in the cloud, but had several shortcomings, again with split horizon and OSPF concerns. Now with the use of ip unnumbered, I cannot see any valid reason to ever use mutlipoint. The main drawback, IP space, was removed and made even better as you can utilize the loopback address further reducing IP utilization.

Finally, as for personal growth information, I've found I start to go cross-eyed at the 7th to 8th hour. A quick nap and a few more labs made for an interesting, if relaxing first day. If all days go like today, I'll be ready before the end of June...

Anthony

The Biggining

2009-05-11T07:33:00.000-05:00

Here starts the journey to become a CCIE in Routing and Switching. Well, beginning in the sense that I've already passed the written, but will begin full time study for the lab portion today. My first attempt will be at the end of June at RTP in North Carolina, second will be mid- to late-August. My goals are to pass the first time (who's isn't?), but fully realize I need to plan for at least one failure, with room for a second. Given that they will significantly update the lab Oct 18, 2009, I need to pass before then.

The course material I plan to use is InternetworkExperts workbooks volumes one through three initially (4.1 and 5.0). I then plan to expand into the IPExperts workbooks for an alternate take refresher. Hardware will consist of GNS3/Dynamips for most, if not all, router scenarios. Will probably supplement with rack rentals during the full lab scenarios to get a better feel and experience as well as complete the switching portions. I was originally going to purchase a bunch of equipment from CCBootCamp, but decided against it. It would cost too much ($7k-$12k) and I do not exactly have room for 13U+ (9 routers, 4 switches) of equipment. Plus, it would be loud.

Anywho, here's to the journey. This blog will be to catalog and assist in that journey. For one, it'll be nice to see where I was and how I progress. It'll also be nice to see the troubles I encounter and the solutions. But this blog will also be a reminder of sorts to keep me focused. Nothing motivates more than telling the world you're being lazy by not studying or not showing progress.

Goals for today are:

Create a baseline topology with default configs to easily clone for future labs
Begin EIGRP Labs

Creating the topology will be a chore in it's own right as GNS3 can be flaky at times. The EIGRP labs will be a good starter as I believe I already have a very solid understanding and extensive experience using EIGRP in production networks. It'll be a nice easy start.

Let the POAP (Period Of Ass Pain) begin...

Anthony