From: alsontra@hotmail.com
Date: Sun Feb 22 2004 - 06:33:14 GMT-3
Are you saying that ospf removed a connected interface from its LSA database
when you used the redistribute connected command on another interface?
Alsontra
I noticed this behavior a few days ago, after the fact. This time I
caught it red handed. What a nightmare in the lab this could be.
Here's what I was doing, the local isis interface didn't get
redistributed, which is normal.
I use tags, so I included the local interface (s0.24 136.10.24.0/29)
with the proper tag for isis into ospf, fixing what isis should have
done. (step 1)
Immediately my rip (s1 136.10.12.0/24) connected route which was
perfectly stable dropped out of ospf. (step 2)
I did nothing to effect the redistribution between rip and ospf! It has
to be some logic being turned off by a specific redistribute connected
cmd being present in the ospf config.
To fix it, I added another statement to my route-map using the right tag
for rip, and the route came back. (step 3)
Remote router watching ospf routes
Step 1) -
RT: add 136.10.24.0/29 via 136.10.56.5, ospf metric [110/1065]
Step 2)
RT: del 136.10.12.0/24 via 136.10.56.5, ospf metric [110/1065]
RT: delete subnet route to 136.10.12.0/24
Step 3)
RT: add 136.10.12.0/24 via 136.10.56.5, ospf metric [110/1065]
------------------------------------------------------------------------
---- Step 1) redistribute connected metric 1000 metric-type 1 subnets route-map connectedisis route-map connectedisis permit 10 match interface Serial0.24 set tag 444 Step 3) route-map connectedisis permit 15 match interface Serial1 set tag 111 ------------------------------------------------------------------------ ---- Is this normal? Maybe a bug in my ios? I hadn't noticed it before, but I notice a lot more now than I used to.
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:54 GMT-3