Re: OSPF filtering

Hello Rares,

I investigated this myself after seeing your post since I remember whizzing
past this INE lab without thinking too much about it. So to summarize what I
see is happening....

I looked at what's happening to the global routing table via:

access-list 3 permit 150.1.3.3
debug ip ospf local 3 (installation of routes into OSPF RIB)
debug ip ospf global 3 (installation of routes into the Global RIB as seen
in 'show ip route')

"Issue":
R6 has 2 possible routes to 150.1.3.3. One via R4 or not directly through
area 0, this is only allowed when "capability transit" is enabled. The
other route is via R1 a backbone/area 0 router which is allowed weather or
not "capability transit" is enabled/disabled.

So with "capability transit" enabled:

OSPF RIB sees both routes as below from debugging:

Via R1 (area 0)
*Dec 9 22:53:04.060: OSPF-RIB-LOCAL: Add 150.1.3.3/255.255.255.255, area 0,
type Intra, dist 3783, forward 0, tag 0x0, via 155.1.146.1
GigabitEthernet0/0.146, route flags (None), path flags (none), source
150.1.3.3, spf 34, list-type change_list

Via R4 (non area 0, only allowed because of "capability transit")
*Dec 9 22:53:04.064: OSPF-RIB-LOCAL: Add 150.1.3.3/255.255.255.255, area 0,
type Intra, dist 1564, forward 0, tag 0x0, via 155.1.146.4
GigabitEthernet0/0.146, route flags (None), path flags (none), source
150.1.3.3, spf 34, list-type transit_list

The path Via R4 is preferred because its metric, noted in the debugging as
"dist" is lower - 1564 and so it is chosen as the sole best path in the OSPF
RIB

Rack1R6#show ip ospf rib 150.1.3.3

OSPF local RIB for Process 1
Codes: * - Best, > - Installed in global RIB

* 150.1.3.3/32, Intra, cost 1564, area 0
     SPF Instance 38, age 00:00:03
     Flags: HiPrio, Transit, OldTrans
      via 155.1.146.4, GigabitEthernet0/0.146, flags: none
       LSA: 1/150.1.3.3/150.1.3.3

However - even though this is the best path, it can't be used because of
your distribute list which filters this best route from getting into the
Global RIB

Seen in debugging "update failed":
*Dec 9 22:53:09.064: OSPF-RIB-GLOBAL: Network update failed
150.1.3.3/255.255.255.255, via 155.1.146.4 on GigabitEthernet0/0.146,
distance 1564, flags (None), source 150.1.3.3, tag 0x0, type Intra, return:
3.

Now with "no capability transit":

Now the OSPF RIB only gets one path Via R1, the path via R4 is not allowed
because it is a non-backbone path and you just said thats not allowed with
"no capability transit":

via R1 - backbone ONLY
*Dec 9 22:52:37.428: OSPF-RIB-LOCAL: Add 150.1.3.3/255.255.255.255, area 0,
type Intra, dist 3783, forward 0, tag 0x0, via 155.1.146.1
GigabitEthernet0/0.146, route flags (None), path flags (none), source
150.1.3.3, spf 33, list-type change_list

R4 not allowed

now the OSPF RIB has the path via R1 (despite its worse metric) and not R4
(b/c it's not allowed now)

Rack1R6#show ip ospf rib 150.1.3.3

OSPF local RIB for Process 1
Codes: * - Best, > - Installed in global RIB

*> 150.1.3.3/32, Intra, cost 3783, area 0
     SPF Instance 36, age 00:00:34
     Flags: RIB, HiPrio, OldTrans
      via 155.1.146.1, GigabitEthernet0/0.146, flags: RIB
       LSA: 1/150.1.3.3/150.1.3.3

Now we get the ">" as in installed in the global table:

*Dec 9 22:52:37.428: OSPF-RIB-GLOBAL: Network update succeeded
150.1.3.3/255.255.255.255, via 155.1.146.1 on GigabitEthernet0/0.146,
distance 3783, flags (None), source 150.1.3.3, tag 0x0, type Intra, return:
0

And that's because this time your distribute list didn't block the route
this time since it wasn't from R4.

Phew - so after all that my conclusion is this (feel free to correct anyone
with more skills than me :-) ). When you allow the non backbone path with
"capability transit" (default) it is the best path in the OSPF RIB, but then
you blocked that path from being installed in the Global RIB with your
distribute list. When you don't allow the non backbone path with "no
capability transit" the best path is now not impacted/blocked by your
distribute list and is properly installed.

Regards,
David Mahler

Blogs and organic groups at http://www.ccie.net
Received on Thu Dec 09 2010 - 21:48:16 ART