Hi,

I have configured task 3.7 which asks to ensure traffic routes to a selection of subnets via the R1 serial link from R5. I have the following configured:

ip access-list standard via-r1
 permit 139.1.11.0
 permit 139.1.2.0
 permit 139.1.0.0
 permit 139.1.6.0
 permit 139.1.7.0

router ospf 1
distance 109 150.1.1.1 0.0.0.0 via-r1

In the routing table I only see the route for 139.1.11.0 with an AD of 109

O IA    139.1.11.0/24 [109/65] via 139.1.15.1, 00:33:01, Serial1/0.15
O IA    139.1.2.0/24 [110/65] via 139.1.25.2, 00:33:01, Serial1/0.25
O IA    139.1.0.0/24 [110/138] via 139.1.25.2, 00:33:01, Serial1/0.25
                     [110/138] via 139.1.15.1, 00:33:01, Serial1/0.15
O IA    139.1.6.0/24 [110/148] via 139.1.25.2, 00:33:01, Serial1/0.25
                     [110/148] via 139.1.15.1, 00:33:01, Serial1/0.15
O IA    139.1.7.0/24 [110/139] via 139.1.25.2, 00:33:01, Serial1/0.25

When I debug ip routing I can see the routes with the AD of 109, but they dont get put into the routing table:

(see 139.1.7.0 as an example)

*Mar  1 04:21:40.642: RT: add 139.1.7.0/24 via 139.1.15.1, ospf metric [109/139]
*Mar  1 04:21:40.642: RT: NET-RED 139.1.7.0/24
*Mar  1 04:21:40.642: RT: add 139.1.7.0/24 via 139.1.25.2, ospf metric [110/139]
*Mar  1 04:21:40.642: RT: NET-RED 139.1.7.0/24

I have configured the same as the SG, but cant work this one out.

Cheers

People keep asking this question regularly :) The problem is that in newer IOS versions (12.3T, 12.4) they "fixed" that feature that allows using Administrative distance to select best routes insides a single OSPF process. There is even a known bug-id for that one, i published it on the forum a couple of time, and it should also be in th forum history. The solution guide probably reference to IOS version 12.2T that did not have this "bug". For more recent IOS versions, you need to look for workaround, like route summarization or filtering.

Thanks Petr.

Just to close this off on the new forums this is what I configured to make this work - I just did this lab again today so thought Id follow it up!

Rack1R2#srb router ospf
router ospf 1
 router-id 150.1.2.2
  area 0 range 139.1.0.0 255.255.0.0

Which gives you only a summary route on R5 for the 139.1.0.0/16 range from R2 - maening that the more specific routes are learned from R1 forcing the traffic that way.

Rack1R5#sir ospf
     139.1.0.0/16 is variably subnetted, 16 subnets, 3 masks
O IA    139.1.11.0/24 [110/65] via 139.1.15.1, 00:01:19, Serial1/0.501
O IA    139.1.2.0/24 [110/193] via 139.1.15.1, 00:01:14, Serial1/0.501
O IA    139.1.0.0/24 [110/138] via 139.1.15.1, 00:01:19, Serial1/0.501
O IA    139.1.0.0/16 [110/65] via 139.1.25.2, 00:01:14, Serial1/0.502
O IA    139.1.6.0/24 [110/148] via 139.1.15.1, 00:01:19, Serial1/0.501
O IA    139.1.7.0/24 [110/139] via 139.1.15.1, 00:01:19, Serial1/0.501

The area range command is a much nicer way to achieve the desired result although it comes at the cost of advertising routes to subnets that don’t exist in the domain.  Your first post you specified the distance command with the router ID of router 1.  This is the reason that only the routes that originated on R1 had their distance decremented.  If you used  0.0.0.0 255.255.255.255 then it would have matched all the desired routes.

The problem here however is that routes to say V367 can be learned via both R1 and R2.  So in effect you lose the ability to differentiate between OSPF peers and miss the point of doing it.  I my case whilst this worked for setting the AD all route still preferred R2 as the cost to R1 and R2 are equal and R2 has the higher RID and ip address. 

As such the area range was used to achieve the desired results.  I used 139.1.0.0 255.255.240.0 as an range.

Trying to ask a reverse question with regards to this task.

"DO NOT use ip ospf cost, bandwidth, virtual-link, stub or nssa commands"

How do we go about in using  'ip ospf cost' & 'bandwidth & 'virtual-link', 'stub' or 'nssa' commands just to match ONLY VLANs 2,6,7, 11 and 367.

Virtual-link : I tried creating a virtual-link on Area1 from R5 to R1, even with the virtual-link established, R5 is still learning ospf routes from both R1 and R2 "O"? Shouldnt routes learned from R2 considered as "IA" and routes learned from R1 as "O"?

Rack1R5(config-router)#do sh ip route

O       139.1.11.0 [110/65] via 139.1.15.1, 00:02:40, Serial1/0.1
C       139.1.15.0 is directly connected, Serial1/0.1
O       139.1.13.0 [110/128] via 139.1.15.1, 00:02:40, Serial1/0.1
O       139.1.2.0 [110/65] via 139.1.25.2, 00:02:35, Serial1/0.2
O       139.1.0.0 [110/138] via 139.1.25.2, 00:02:40, Serial1/0.2
                  [110/138] via 139.1.15.1, 00:02:40, Serial1/0.1
O       139.1.6.0 [110/148] via 139.1.25.2, 00:02:40, Serial1/0.2
                  [110/148] via 139.1.15.1, 00:02:40, Serial1/0.1
O       139.1.7.0 [110/139] via 139.1.25.2, 00:02:40, Serial1/0.2
                  [110/139] via 139.1.15.1, 00:02:40, Serial1/0.1

'stub' or 'nssa': stub and nssa applies to the area as a whole. How can i further filter it off to match only VLANs 2,6,7, 11 and 367.

By making R1 as stub, R2 as stub no-summary, and R5 as stub, i achieved the following results, preferred paths still go via R1 except it applies to all learned OSPF routes instead of just only VLANs 2,6,7, 11 and 367.

Rack1R5(config-router)#do sh ip route ospf
     139.1.0.0/24 is subnetted, 13 subnets
O IA    139.1.11.0 [110/65] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    139.1.13.0 [110/128] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    139.1.2.0 [110/193] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    139.1.0.0 [110/138] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    139.1.6.0 [110/148] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    139.1.7.0 [110/139] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    139.1.23.0 [110/192] via 139.1.15.1, 00:00:01, Serial1/0.1
     150.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O IA    150.1.7.7/32 [110/139] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    150.1.6.6/32 [110/139] via 139.1.15.1, 00:00:01, Serial1/0.1
O IA    150.1.3.3/32 [110/129] via 139.1.15.1, 00:00:01, Serial1/0.1
O       150.1.2.2/32 [110/65] via 139.1.25.2, 00:00:01, Serial1/0.2
O*IA 0.0.0.0/0 [110/65] via 139.1.25.2, 00:00:01, Serial1/0.2
               [110/65] via 139.1.15.1, 00:00:01, Serial1/0.1