Wireless STM-1 link
Mike
mike-nanog at tiedyenetworks.com
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-
More information about the NANOG
mailing list