[c-nsp] debug fastethernet

[Anton Kapela]

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Adam Greene
> Sent: Tuesday, October 17, 2006 4:34 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] debug fastethernet
> 
> Hi ...
> 
> We're seeing some OSPF dead timers between a 3750 and a 
> 2621XM on two sides of a wireless link. The setup is as follows:

If you're using ISM/UNII radios without solid ARQ in any moderately
"rf-busy" location and running igp's with default timers, then you will
likely experience trouble. If this is your case, and your distances are
short enough, you might want to investigate moving to licensed systems
in the 11, 13, 18, 23, or even 38ghz bands, depending on your locale.
There's lots of gear to chose from given various failures (such as the
spectacular Winstar) over the years. 

Suggestions I would make include verifying link-layer serviceability
through frequent polling of phy/air-layer receiver errors, discards or
drops, ARQ activity (retries, dupe acks, failed retries, etc), and any
'rate shifting' or 'dynamic frequency selection' activity. I've come
across more than one radio which behaves badly during the transitions
between various PHY rates or channel tunings, so try to record
information related to these activities.

Finally, verify all ethernet port interfaces are not showing any signs
of loss. If the entire path is in fact 'clean' end to end then perhaps
you've hit an honest to god ospf hello bug, but this would seem
unlikely. 

-Tk