OSPF Summary- Address (LONG) I think valuable

From: James D. Holley, Jr. (jholley@xxxxxxxxxxx)
Date: Fri Feb 18 2000 - 21:46:42 GMT-3


   
   I found something interesting about the command "summary address
   x.x.x.x 255.255.255.0" when trying to redistribute VLSM subnet into
   FLSM. See diagram:
   
   [R1]S0-------------S0[R2]S1-------------S0[R3]S1------------
   RIP[-----------------] [OSPF AREA 0] [OSPF AREA 1]
   
   R1 is running RIP S0- 172.16.1.x/24
   R2 is running RIP S0- 172.16.1.x/24 and S1- OSPF 172.16.2.4/30 Area 0
   Mutually Redistributing OSPF and RIP at R2
   R3 is running OSPF . S0- 172.16.2.4/30 and S1 172.16.3.0/24
   
   R1
   !
   S0
   ip add 172.16.1.1 255.255.255.0
   !
   router rip
   net 172.16.0.0
   
   R2
   !
   S0
   ip add 172.16.1.2 255.255.255.0
   !
   S1
   ip add 172.16.2.5 255.255.255.252
   !
   router rip
   net 172.16.0.0
   redist ospf 1 met 3
   pass s1
   distribute-list 1 out ospf 1
   !
   router ospf 1
   net 172.16.2.4 0.0.0.3 area 0
   net 172.16.3.0 0.0.0.255 area 1
   summary-address 172.16.2.0 255.255.255.0
   redistr rip sub met 1000
   distr list 2 rip out
   
   access-list 1 perm 172.16.2.0
   access-list 1 perm 172.16.3.0
   !
   access-list 2 permit 172.16.1.0
   
   The above config, if typed in correctly from memory (not a machine
   example), will summarize the VLSM 172.16.2.4/30 into a /24 for RIP to
   receive, but the "distribute-list 1 out ospf 1" will block the net
   from being advertised.
   
   CASE:
   Before the distribute list is applied, when the summary-address
   command is issued a type-5 LSA is generated in the OSPF Database on
   the ASBR (R2). You can see it by typing in "sh ip ospf data".
   Redistribution works perfectly.
   
   Now, if you apply the distribute-list 1, above and "debug ip ospf LSA"
   you can see that the LSA is becoming MAXAGED, and flushed. The
   distribute list, access-list 1, above is blocking the 172.16.2.4 net
   when the redistribution is done- (it doesn't match criteria). If
   you alter the access-list to explicitly let it in, or deny some routes
   and permit any, it will work. The following is an example of explicit
   access-list:
   Access-list 1 perm 172.16.2.0 0.0.1.255
   
   This may be why sometimes the command works and sometimes it seems it
   doesn't.
   (If you got this far, thank you. ) Thoughts?
   
   Special Thanks to Colby, Ed, and Scott at BroadWing's CCIE Practice
   Lab in Reston, VA (Look for my review of their LAB next week.)
   James D. Holley, Jr.
   Sprint ENS



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:22:53 GMT-3