I have had similar problems to this with OSPF. Wierd situations where
adjacencies would drop out or could not form adjacencies, and yet
everything looked good. In one instance it was a layer2 problem, and in
the other it had to do with CEF (the feature I have a love/hate
relationship with).
If your running CEF, it could possibly be doing something here. To me
however it smells of l2 problems. I assume you checked "sh frame pvc" and
made sure the counters look ok?
Brian
On Thu, 10 May 2001, [EMAIL PROTECTED] wrote:
> Hi all,
> This isn't directly certification-related, but maybe people can practise
> their trouble-shooting skills.
>
> I have a frame relay link that occasionally drops the OSPF adjacency across
> it (average once a day maybe, but it can go several days with no problems
> and then get several hits in a day). Apart from the brief disruption, this
> causes the ISDN backup to kick in, which is not something I want to happen
> unnecessarily since the call is from one side of Australia to the other :-)
> Each access supports other PVCs as well, which do not have problems.
> The PVC does not drop out.
>
> I have debug ip ospf events and debug ip ospf adjacency turned on. One
> side will announce that the other neighbour is dead, and start rebuilding
> the adjacency. The side that detects the problem first varies.
> There are a small number of CRC errors at one end, and some broadcasts are
> dropped at the other end, but the numbers are consistent with links
> throughout the rest of the network which are problem-free.
> Both routers have had the cables re-seated and have been reloaded.
> Traffic shaping is in effect and should be preventing traffic from
> overloading the smaller access rate. There are some FECN/BECN/DE packets,
> but again, nothing at unusual levels. I have no reason to believe that the
> traffic pattern on this link is different to others in the network.
>
> IOS is 11.2. One router is a 7505, the other a 4700M.
>
> I assume that hellos are being dropped occassionally (and fairly randomly)
> across the link, and that sometimes enough in a row get dropped that the
> timer expires. The links are monitored via MRTG, and there is some
> correlation between increased usage and the problem, but there are plenty
> of times of higher utilisation with no problems. Very short-term bursty
> traffic may not show up in MRTG, though.
>
> Any tips on what to check/fiddle with next? My thought is to get the
> carrier to check out the link and see whether they can see any problems in
> their cloud. I have no doubt the answer will be 'no', but they may fix
> something while they're looking :-).
>
> Ta,
> JMcL
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
-----------------------------------------------
We have MOVED!! Make note of our new address!!!
I'm buying / selling used CISCO gear!!
email me for a quote
Brian Feeny,CCDP,CCNP+VAS Scarlett Parria
[EMAIL PROTECTED] [EMAIL PROTECTED]
318-213-4709 318-213-4701
Netjam, LLC http://www.netjam.net
333 Texas St. VISA/MC/AMEX/COD
Suite 1401 30 day warranty
Shreveport, LA 71101 Cisco Channel Partner
p: 318-212-0245
f: 318-212-0246
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=4004&t=3964
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
