Wireless STM-1 link

Thu Sep 10 16:35:25 UTC 2009

Kenny Sallee wrote:
> Seems everyone has focused on GE as the problem.  You can quickly rule that
> out by looking at interface error counters and doing PING tests from the
> wireless router/device to something on the local network on both sides.  If
> OSPF is flapping because of missed HELLO packets then I'm thinking you have
> a problem with either saturation on the link or actual wireless issues.
>  When PING does work what do the times look like? I'd look at static routing
> for a bit (if practical) or changing your OSPF HELLO intervals to see if
> that does anything.  Here's a good link on troubleshooting
> OSPF adjacency changes:
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050.shtml
>   

I'd like to second the above. Wireless can, and often does, suffer from 
isses that other media such as copper and fiber media do not, and you 
need to be looking closely at the device's RF statistics (combined with 
your own monitoring of link rssi, error blocks, retrans, and others... 
you are monitoring and graphing this, yes?). Some of the variations you 
can expect in wireless include -

    Interference (if using unliscensed band gear - do NOT assume your 
little corner of the world doesn't have anyone else using the band 
occasionally!)
    Thermal inversion fade
    Water build up - especially inside of antennas and antenna elements, 
this can take your -36 rssi and make it drop to -86 and then all of a 
sudden come back in the space of 30 seconds. This can be the hardest 
problem to find - look at your connectors, the seal up job, anywhere 
they would have had to seal would be a place of penetration.
    Birds, trucks, anything causing occasional multipath reflections or 
blockage between the two sides

    Also it is my direct experience that wireless devices from all 
manufacturers also are more bug ridden and usually have far more exotic 
corner cases where their gear just does the wrong thing occasionally. 
Corrupt frames at the RF layer may not be detected due to various mac 
layer defeciencies, with the result being incorrect reassembly and 
framing of the junk as an ethernet frame and even including a valid fcs 
in the ethernet header but corrupt junk in the packet itself.  Sometimes 
the RF device's own bridging tables get corrupted as a result, causing 
you to lose connectivity as bridge entries are relearned.  There's all 
kinds of stuff that can go wrong here that is not your ordinary every 
day cisco 4-byte asn bug variety.

    My advice only is, be suspecious and be a good detective.

Mike-