Hard to say. It can’t be managed or pinged right now. But it is still
active and working which is strange.
We had this happen once or twice before. Updated the firmware and
haven’t had a problem in a while.
-Tim
*From:*Af [mailto:[email protected]] *On Behalf Of *Josh Reynolds
via Af
*Sent:* Friday, October 24, 2014 1:53 PM
*To:* [email protected]
*Subject:* Re: [AFMUG] Dragonwave latency issues
Is it possible the v1810 is seeing large amounts of multicast or
broadcast traffic that could saturate the CPU? You said you were
unable to manage it, correct?
Josh Reynolds, Chief Information Officer
SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com>
On 10/24/2014 12:34 PM, Timothy D. McNabb via Af wrote:
The one malfunctioning is a V1810-48G. The one I put together to
replace for the trunking as temp is a 2824. The other side is J4904A.
All of our switches of various models we have purchased are
managed and support Dynamic LACP and link aggregation. The
interfaces and cooling (fan vs fanless) are the only differences
in the ones we have. The older units run a Java GUI whereas the
newer units have an HTTP setup.
-Tim
*From:*Af [mailto:[email protected]] *On Behalf Of *Josh
Reynolds via Af
*Sent:* Friday, October 24, 2014 12:25 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
Which model procurve? Many of them are very different.
Josh Reynolds, Chief Information Officer
SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com>
On 10/24/2014 11:13 AM, Timothy D. McNabb via Af wrote:
This is really cool. I’m going to check into this and see what
I come up with JThanks for the input! I love what LACP does in
theory, I know in some practices it’s not optimal and not
everyone’s first choice. It is however the recommended method
from DW and the only one they will support. :-P
A couple of things that continue to interest me is that the 48
port that is unmanageable. Assuming it is malfunctioning, by
DEFAULT HP Procurve switches have dynamic LACP across all
ports, preventing network loops automatically but also making
it cumbersome to troubleshoot this particular issue. Knowing
that, and the possibility of something running FUBAR on one of
the switches, I think it’s quite possible that the LACP that
was originally configured on the malfunctioning switch could
be the culprit for the inbalance. I am programming a 24-port
Procurve that we have as a spare to handle the trunk to test
the theory.
The older Procurves have lots of options in regards to LACP
(their console is very much like a Cisco) so I may be able to
setup something similar to what you’re suggesting. I’ll update
as I find out more.
Thanks for the discussion and I love the progression, getting
lots of ideas from the conversation. J
Gino, unfortunately because of the Horizon Compact I don’t
believe we have that option, at least not to get the full
800Mb/s (theoretical) from the radios LIt’s been awhile since
I went through the manual for the setup, but I recall there
were some negative aspects to linking the radios through port
2 or something along those lines.
And for Bill, since we’re running a large bridged network
currently (but so happy we’re changing it soon!!) we’re not
running any routers at the base of our towers. I agree totally
if we were segmented that OSPF in combination with a few other
protocols would handle the job and give us some other
troubleshooting capabilities not available to us in our
current config. Even packet captures would be cumbersome L
-Tim
*From:*Af [mailto:[email protected]] *On Behalf Of *Mark
Radabaugh via Af
*Sent:* Friday, October 24, 2014 10:10 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
Tim,
Obviously you want to fix the radio issue but I can give you a
little advice on LACP.
The switch (or router) doing LACP can take various headers
into account when doing the 'hashing' to decide how to send
the flows. If LACP is what you are stuck with (Gino suggested
a layer 1 method) and you have control over the devices doing
LACP take a look at the LACP Hashing options. Typical
options are MAC SRC/DST, MAC Src/Dst + L3 port, or some other
options. If most of your traffic is flowing between two
interfaces (a router at each end) the MAC src/dst hashing
sends everything over one of the links. You want to find a
hashing method that has more randomness to it. In at least
one case where we use that we had to resort to not using the
LACP functionality the radio manufacturer provided and use the
better LACP options in our Juniper and Cisco switches in order
to make the traffic balance on the interfaces.
Mark
On 10/24/14, 12:38 PM, Timothy D. McNabb via Af wrote:
We have now been able to trace to the heart of the
problem, though unfortunately still attempting to
determine the cause. To give you a rough background, we
have a main link that “bonds” 2 Dragonwaves together to
form one unit (using the dual radio mount). The DW manual
states for this to work when doubling the throughput, it
is required to use LACP trunking. We have this in place
and it has been working fine up until recently. The trunk
is still active (no network loop) however one radio is
working more than the other, eventually saturating one of
the two links and causing the latency. The second set of
radios aren’t performing in terms of actual traffic
(signal is ok) but at most they’ve moved 200Mb/s even
though they are licensed for 400Mbs.
The link with the LACP has more or less load-balanced
itself in the past, however they are now performing very
asymmetrical at this point with over a 200Mb/s difference.
I understand that LACP does not actively load balance but
that’s what has been observed in the past. I suspect the
issue is being caused by one of the switches doing the
trunking (we just discovered it is unmanageable but still
operating, again no network loop). It’s either that or the
one leg of the link itself with the low bandwidth usage is
not working properly despite indications otherwise.
We’ll investigate our theories but always looking for
additional input J
-Tim
*From:*Af [mailto:[email protected]] *On Behalf Of
*Josh Reynolds via Af
*Sent:* Thursday, October 23, 2014 1:47 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
You can do a bit more with metro-e style NIDS... those
have the layer2 tools to do proper testing.
Josh Reynolds, Chief Information Officer
SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com>
On 10/23/2014 12:37 PM, Eric Kuhnke via Af wrote:
it's going to be really hard to do any meaningful
diagnostics with a layer 2 switch on each end, not
routers... you could be seeing a broadcast flood of
some type.
On Thu, Oct 23, 2014 at 1:10 PM, Timothy D. McNabb via
Af <[email protected] <mailto:[email protected]>> wrote:
Unfortunately there is no QoS and flow control is off
on the switches L
Dragonwave was contacted as well. No determination yet
though.
-Tim
*From:*Af [mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Peter
Kranz via Af
*Sent:* Wednesday, October 22, 2014 1:36 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
Backpressure from the switches in terms of
flow-control can show as latency on dragonwave links.
Disable any QOS features on the dragonwave if you are
using them.
Email dragonwave support
*Peter Kranz
*Founder/CEO - Unwired Ltd
www.UnwiredLtd.com <http://www.unwiredltd.com/>
Desk: 510-868-1614 x100
Mobile: 510-207-0000
[email protected] <mailto:[email protected]>
*From:*Af [mailto:[email protected]] *On Behalf Of
*Timothy D. McNabb via Af
*Sent:* Wednesday, October 22, 2014 1:15 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
No routers between, just switches.
-Tim
*From:*Af [mailto:[email protected]] *On Behalf Of
*Paul Conlin via Af
*Sent:* Wednesday, October 22, 2014 12:22 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
Could the routers at each end be the limiting factor?
What is their CPU utilization when the link is
loaded? What happens to latency if you stress the
link at 200 Mbps with a speed test? Those radios
should be able to do close to 400 Mbps all day long
with no latency.
PC
Blaze Broadband
*From:*Af [mailto:[email protected]] *On Behalf Of
*Joshua Heide via Af
*Sent:* Wednesday, October 22, 2014 3:06 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
Yes it’s a horizon compact
Bandwidth of the unit is 400mbs
Bandwidth usage between 150-200mbs during peak hours.
No QOS
Yes during non-peak hours its sits at 1ms
SNR 35.00 dB
From our prtg graphs this issues has started end of
September and latency has gotten worse during peak
times as we have deployed more 450 gear to that tower.
I currently have HAAM enabled on the link and it stays
at 256qam unless we have some bad weather.
Josh Heide
Velociter Wireless
(office) 209-838-1221
(fax) 209-838-1800
www.velociter.net <http://www.velociter.net/>
*From:*Af [mailto:[email protected]] *On Behalf Of
*Bill Prince via Af
*Sent:* Wednesday, October 22, 2014 11:47 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] Dragonwave latency issues
So it's a Horizon Compact?
What is the total bandwidth, and what percentage are
you using? Have you set up any QOS? 180 ms sounds
like a lot; especially when ours are typically less
than 1 ms.
-38 is right in the game. What are the other
parameters besides signal level?
bp
On 10/22/2014 11:18 AM, Joshua Heide via Af wrote:
We have a dragonwave that has latency issues that
coincide with traffic peak times. As our traffic
peaks so does that latency at 180ms. Any ideas
that could cause this?
Signal is -38
Current HAAM Mode hc50_364_256qam
Thanks,
Josh Heide
Velociter Wireless
(office) 209-838-1221
(fax) 209-838-1800
www.velociter.net <http://www.velociter.net/>
--
Mark Radabaugh
Amplex
[email protected] <mailto:[email protected]> 419.837.5015 x 1021
