[c-nsp] static into OSPF redistribution problem

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Blaine Kahle wrote:
> What causes a router to STOP redistributing a static route into OSPF if
> it starts seeing that same external route from a neighbor? i.e. the
> type-5 LSA is generated fine until another router starts sending a
> similar LSA.
> 
> RTR1 and RTR2 are neighbors and DR/BDR on a FastEthernet link with the
> following OSPF configuration on each:
> 
> router ospf 1
>  log-adjacency-changes
>  area 0 authentication
>  redistribute connected metric-type 1 subnets
>  redistribute static metric-type 1 subnets
>  network 10.100.0.0 0.0.255.255 area 0
>  network 10.101.0.0 0.0.255.255 area 0
>  maximum-paths 2
> 
> RTR1#sh ip ospf int br
> Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
> Fa0/1        1     0               10.101.0.4/28      1     DR    1/1
> Lo0          1     0               10.100.0.129/32    1     LOOP  0/0
> 
> RTR2#sh ip ospf int br
> Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
> Fa0/1        1     0               10.101.0.5/28      1     BDR   1/1
> Lo0          1     0               10.100.0.130/32    1     LOOP  0/0
> 
> 
> If my defined static routes are:
> 
> RTR1: ip route 0.0.0.0 0.0.0.0 a.b.c.d
> RTR1: ip route 10.100.4.0 255.255.255.0 10.101.0.1
> 
> RTR2: nothing
> 
> Then RTR1 redistributes and advertises the static via OSPF fine:
> 
> RTR1#sh ip ro 10.100.4.0
> Routing entry for 10.100.4.0/24
>   Known via "static", distance 1, metric 0
>   Redistributing via ospf 1
>   Advertised by ospf 1 metric-type 1 subnets <------- See here
>   Routing Descriptor Blocks:
>   * 10.101.0.1
>       Route metric is 0, traffic share count is 1
> 
> 
> 
> But if I add the same static router to RTR2, RTR1 stops
> advertising:
> 
> RTR1#sh ip ro 10.100.4.0
> Routing entry for 10.100.4.0/24
>   Known via "static", distance 1, metric 0
>   Redistributing via ospf 1                  <---- "Advertised" is gone
>   Routing Descriptor Blocks:
>   * 10.101.0.1
>       Route metric is 0, traffic share count is 1
> 
> RTR2#sh ip ro 10.100.4.0
> Routing entry for 10.100.4.0/24
>   Known via "static", distance 1, metric 0
>   Redistributing via ospf 1
>   Advertised by ospf 1 metric-type 1 subnets <-----on RTR2, but not RTR1
>   Routing Descriptor Blocks:
>   * 10.101.0.1
>       Route metric is 0, traffic share count is 1
> 
> 
> I need both routers to advertise the static route so that I can do
> load-balancing on a third router. What OSPF fundamental behavior am I
> overlooking the TFM?
> 
> Both RTR1 and RTR2 are:
> 
> Cisco 2811 (revision 53.51) with 251904K/10240K bytes of memory.
> Cisco IOS Software, 2800 Software (C2800NM-IPBASEK9-M), Version 12.4(5),
> RELEASE SOFTWARE (fc3)
> System image file is "flash:c2800nm-ipbasek9-mz.124-5.bin"
> 
> 
> 

Looks like you are including the redistributed route in your OSPF process
which means the forwarding address will be set and non-zero.  Where is the
next-hop 10.101.0.1 for the static route?  From
http://www.cisco.com/warp/public/104/type5_lsa.html

"When the metric of the redistributed route from multiple ASBRs are equal
as illustrated in the document, the forwarding address changes the behavior
of the type 5 LSA path selection. When a router receives two type 5 LSAs to
the same destination with the forwarding addresses set on both LSAs, the
router makes a comparison based on the metric to the forwarding addresses.
The LSA with a forwarding address that offers the smaller metric is placed
into the routing table.

If the metric of the redistributed routes are different, the routers prefer
the route with the lowest metric and not the lowest metric to the
forwarding address."

If RTR2 offers a better metric to 10.101.0.1 than RTR1, then RTR1 will also
select RTR2's route which should override RTR1's static route and hence
it's subsequent advertisement.

I'd check both the metric to the next-hop in the routing table and look at
the LSA entries for more details.


- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD4/Y/E1XcgMgrtyYRAkuGAJwJQqsD2xvhnRRehAJSO48xBZOOPQCePhAE
63NFh5H/Y13Wiri3r6jT/Ig=
=iS6p
-----END PGP SIGNATURE-----