OSPF Intermediate

i would suggest a last task:

create a loopback on R4 without adding it to the ospf process and without redistribution.
ensure that you have reachability to it from all other routers.

Reason:
to test that the nssa area type does not allow by default the injection of default route towards R3.

Thanks for another great lab!
In the video solution, to make R3 the DR on the 3-4 link, you increased the priority on R4's interface to 200. This would actually make R4 win the election, since the router with the highest OSPF priority on a segment will become the DR for that segment.
The reason that R3 became the DR is because you cleared the OSPF process on R4. While this was happening, R3 became the DR. When the OSPF process on R4 started up again, R3 was already the DR, and since OSPF does not preempt, R3 stayed the DR.

@Bogdan

Good thinking! I added this one...i like it

@Doug

You are totally right..I messed up So people keep in mind:

- The DR is preemptive.
- Higher priority will become the DR.

Thanks for this!

I have got the Loopback14 on R4 pingable from all routers. Just to confirm if I am doing it as intended, can we use the "ip default-network" command?

ip default-network will advertise the default route and ensure reachability, so yes this is perfectly fine. You'll have reachability without using advertising or redistributing.

I can't get R2 to see the default route and hence ping 172.16.4.1. My thoughts are this is because area 1 is a NSSA and so doesn't pass Type 5 LSAs. All other routers can ping it, just not R2.

comparing my config to yours it doesn't seem to differ other than the mask I've got on 172.16.4.1.

Key part of my R4:

router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 1500
area 2 range 172.16.0.0 255.255.252.0
network 4.4.4.4 0.0.0.0 area 2
network 172.16.0.0 0.0.3.255 area 2
network 192.168.34.4 0.0.0.0 area 0
default-information originate always

When I change the network statement to have the /16 mask for 172 the route from R2 to Loopback14 on R4 works but I do not see a default route on R2. Is this correct?

sh ip route:
Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/151] via 192.168.12.1, 0066, FastEthernet0/0
O IA 192.168.13.0/24 [110/300] via 192.168.12.1, 0066, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback2
3.0.0.0/32 is subnetted, 1 subnets
O IA 3.3.3.3 [110/301] via 192.168.12.1, 0066, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/451] via 192.168.12.1, 0066, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
O IA 172.16.4.0/24 [110/451] via 192.168.12.1, 0009, FastEthernet0/0
O IA 172.16.0.0/22 [110/451] via 192.168.12.1, 0004, FastEthernet0/0
O IA 192.168.34.0/24 [110/450] via 192.168.12.1, 0067, FastEthernet0/0

@ Steve

Allowing the 172.16.0.0 /16 to be advertised on R4 is against the lab objectives.

What I did was to go in to R1 and issue this command under the OSPF process:
R1(config-router)#area 1 nssa default-information-originate

This will make R1 advertise the default-route it knows from R4 in to area 1.
R2 will have a route in its routing table looking like this:
O*N2 0.0.0.0/0 [110/1] via 192.168.12.1, 00:24:53, FastEthernet0/0

I don't know if this is considered against the lab objectives, but I would think that using the already existing default-route in the OSPF network in the NSSA area would be "right" way.
This also scales well compared to some other solutions like adding a static route on R2, which, again, is not against the lab objectives.

Just my 2 cents.

Hi Derry,

Your way sounds correct but I still can't get that R2 router to see the default route.

R1 ospf config:

router ospf 1
router-id 1.1.1.2
log-adjacency-changes
auto-cost reference-bandwidth 1500
area 1 nssa default-information-originate
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.1 0.0.0.0 area 1
network 192.168.13.1 0.0.0.0 area 0

R2 ospf config:

router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 1500
area 1 nssa
network 2.2.2.2 0.0.0.0 area 1
network 192.168.12.2 0.0.0.0 area 1
network 192.168.24.2 0.0.0.0 area 0

R1 shows the default route but R2 shows no default at all (but all other routes)

Hello everybody,

I've encountered the same peculiarity that Steve did while doing my lab. It seems that despite being a default route to 0.0.0.0, OSPF regards it as an External Type 2 route. Since you cannot advertise a type 5 (external) route into NSSA, we don't get the default route in there.

However, this should not be a problem, if you mark the area as a Totally NSSA on R1:
area 1 nssa no-summary
That would do it, and it also seems the right way to do it, because, after all, Area 1 is just a stub area with only one exit, albeit being an NSSA kind.

Cheers for the nice labs!

Hi Guys,

Let me sum up some of the differences between the stub areas which will help you to beat these OSPF labs.

If you use a stub area it will block all type 5 external LSAs. This means you cannot have an ASBR within the stub are because those are blocked.

If you want an ASBR within the stub are you need to convert it into a NSSA (not-so-stubby-area) which uses type 7 external LSAs. This way you can have external routing information within the stub area.

The "totally" stub types will do the exact same thing but they also block type 3 summary LSAs in the area.

Getting the following error when trying to get to the PDF.
TCPDF error: Missing or incorrect image file: images/stories/ospf intermediate.jpg

I have to say Rene, great work and great labs. Thank you for your time and effort. It really helps when you can find quality free labs especially in this economy.

One other thought. Have you considered zipping up all the files into one that includes the Lab PDF, Topology, Configs, and final configs. It would be great to download just one file.

@Rene
On the PDF I just wanted to make sure it was not just me.

On the zipping of the files, it was just an idea maybe going forward. You do enough work keeping this site going and I think you for that.

If I was to work on zipping some of the exiting labs for you would that be OK? If so where could I send them?

In Configuring R4's loopback0 interface as area 2:

you forgot to do this command:

network 192.168.24.0 0.0.0.255 area 0

@Mike The PDF plugin keeps failing on me...it's a pain to get it working Zipping everything sounds like a good idea but it means I'll have to generate a pdf and replace all 100+ lab files so it's not something i'm going to do (soon).

@Usama what do you mean? network 4.4.4.0 0.0.0.255 area 2 is used on R4 to get this loopback in area 2.

Hi Mike,

It's cool to hear that you want to zip the files but I think i'll wait for a moment and first get all the labs out of the way. There's about 300 labs left I want to build so everything is on CCIE R&S level. If i'm going to do it I think I can do it without too much trouble with a script on the webserver command-line ;D appreciate the help though!

I'll try to fix the PDF plugin, I don't like that its not working but it takes so much time fixing it

About the last requirement to reach the 172.16.4.1 address.
R4 is already doing a default-information originate.
So a 0/0 is already out there in the routing table.
The problem is that R2 will not be able to get to R4s loop because the 0/0 is a E2(by default) and thus it will not get into the routing table of R2 since area 1 is NSSA.

To solve the problem I found two ways:
1. Easy way with a static route on R2 for 172.16.4.1
or
2. Since this is a OSPF lab, configure Area 1 as a Totally NSSA so R2 gets a 0/0 from R1 since it can't learn the 0/0 from R4.

I think this is what Bogdan had in mind when he suggested this little trick .

This lab touched on a little bit everything to do with OSPF. Thanks great work once again Rene.

Getting Error while open this lab

error 203-bad numbers of parameters

@James glad you like it!

@Hemant + everyone else that has the 203 bad number of parameters error, here's the solution:

http://gns3vault.com/FAQ/203-bad-number-of-parameters-1-with-minmax22.html

Thanks Rene
its working,,, now i can open all my downloaded LAB

I have an MultiArea ospf configuration lab can u help me i want to upload this lab ex. but how to upload i dont know

What exactly do you want to do?

Dear Rene,

kindly check, the router 4 config, is it completing the requirement.

interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
interface Loopback10
ip address 172.16.0.1 255.255.255.0
!
interface Loopback11
ip address 172.16.1.1 255.255.255.0
!
interface Loopback12
ip address 172.16.2.1 255.255.255.0
!
interface Loopback13
ip address 172.16.3.1 255.255.255.0
!
interface Loopback14
ip address 172.16.4.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.34.4 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 TEST
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.24.4 255.255.255.0
ip ospf authentication
ip ospf authentication-key vault
ip ospf dead-interval 60
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 1500
summary-address 172.16.0.0 255.255.252.0
network 4.4.4.0 0.0.0.255 area 2
network 172.16.0.0 0.0.255.255 area 2
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
default-information originate always
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!

summary-address 172.16.0.0 255.255.252.0 wont work.

Use area 2 range 172.16.0.0 255.255.252.0 command.

Also static route 0.0.0.0 0.0.0.0 towards null0 is missing here for default-route propagation.

Sorry, i missed the always word in default-information originate always command.

It will definitely generate a default route w/o any further condition of having a default-route already.

Completed the lab. Just for clarity: We redistribute routes of any area X to other areas from ABRs using area X range command. Not sure what is the purpose of command summary-address in router ospf mode.

the summary-address command is used to summarize redistributed routes.

Thanks Rene

Ok, so I ran into the same issue that others have mentioned about getting the default route that is being advertised on R4 to the routing table on R2.

I do agree that making the Area 1 stub a totally NSSA works and decreases the size of the routing table on R2, but the instructions specifically say to create a NSSA (not totally NSSA).

For this reason, I believe the appropriate method per instruction would be to use the area 1 nssa default-information-originate on R1 as someone else pointed out in the comments.

Rene, were you going for a specific method for this? I looked over the final configs that were posted which showed neither totally NSSA or default-information-originate, but there was also no Loopback14 on R4 to need either of these commands for.

Last part got me for a few minutes, then I realised that I had used default-information originate and the only router which couldn't ping the address was R2. Not suprising, as NSSA does not inject a default route. Had to change it to a NSSA no-summary before the magical default route was injected and all was dandy. Nice lab, but it would be great if there was virtual link and virtual link authentication somewhere!

i made area 1 nssa totally stubby area..
u rekcon that is a good practice? afterall the exit point for R2 to get "outside" is R1 anyway and R2 is not connected to any other external routes, i reckon it is the solution which can be used..any comments?

cheers.