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]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=3967&t=3964
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
