Vincent,
Thanks for the response, but...
1) IOS 11.2 doesn't support this command (I agree, it's a useful command,
and I run it on other routers with a higher IOS level).
2) That's how I know about the CRC errors, BECNs/FECNs, dropped broadcasts
etc. Anything in particular you suggest looking out for?
JMcL
---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 11/05/2001
08:38 am ---------------------------
"Vincent Chong" @groupstudy.com on 10/05/2001
07:10:00 pm
Please respond to "Vincent Chong"
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: OSPF dropouts [7:3964]
1) First I will suggest you that you use log-adjancey-change command.
By apply the command, the router will send a syslog message when
an OSPF neighbor state changes. It can provides a higher level
view of changes to the state of the peer relationship with less output.
2) Check the physical interface status, like show interface etc.
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]
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=4098&t=3964
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
