OSPF NSSA Translation

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

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

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

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

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

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

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