<div dir="ltr">Skylar,<div><br></div><div>This is a bug in 5.6.0a.</div><div><br></div><div>See:</div><div><a href="https://puck.nether.net/pipermail/foundry-nsp/2014-June/004396.html">https://puck.nether.net/pipermail/foundry-nsp/2014-June/004396.html</a><br>
</div><div><br></div><div><div>in 5.6b (but fixed in 5.6c): </div><div>Defect ID: DEFECT000502305 </div><div>Technical Severity: Medium Probability: High </div><div>Product: Multi-Service IronWare Technology: Management </div>
<div>Reported In Release: NI 05.6.00 Technology Area: SFLOW </div><div>Closed In Release(s): NI 05.6.00c(Fixed) </div><div>Symptom: An incorrect raw packet header length in the sFlow protocol is </div><div>observed. </div>
<div>Condition: Issue is seen while running L3 traffic along while enabling </div><div>sFlow on an interface. sFlow enabled interfaces send sFlow data packets </div><div>to an sFlow collector. At the collector the raw packet header length is </div>
<div>less than what was originally sent. </div><div><br></div><div>In 5.6c (not in 5.6b, no fix yet): </div><div>Defect 505978 </div><div>BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP </div><div>
cpnnection is in SYN-SENT state. </div><div>It will occur if you peer using loopback address with /128 mask. </div><div>It will be fixed in 5.6d which is not released yet. </div><div>Current workaround would be to not use /128 mask or to downgrade your code</div>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 2:01 PM, Skylar MacMinn <span dir="ltr"><<a href="mailto:skylar@crissic.net" target="_blank">skylar@crissic.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">We recently swapped off of an RX-4 to an MLX-4, we are using WANGUARD with SFLOW to monitor our network traffic. The RX-4 worked well enough. The issue with our MLX-4 is SFLOW is recording on average about 80-100Mbps vs the 800-1000Mbps
we run regularly. SNMP appears to record data fine, but the SFLOW is inaccurate by a very large degree.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We’ve worked with wanguard on it, as well as used other methods of validating the sflow data – at this time we have verified that the issue is with SFLOW itself on the router, and not a configuration issue within the software we are using
to monitor the data.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Our current installed firmware is the following:<br>
<br>
<u></u><u></u></p>
<p>IronWare : Version 5.6.0aT177 Copyright (c) 1996-2013 Brocade Communications Systems, Inc.<u></u><u></u></p>
<p>Compiled on Dec 5 2013 at 11:08:04<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Any and all help is greatly appreciated! For the time being we’d prefer to keep using SFLOW until we can transition into something more reliable, but this should be working fine. We have validated that configuration of sflow is where it
should be, so the results should at least be somewhat closer to reality.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Cordially Yours,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Skylar MacMinn<u></u><u></u></p>
<p class="MsoNormal"><a href="http://www.crissic.net" target="_blank"><span style="color:blue">www.crissic.net</span></a><br>
Crissic Solutions, LLC<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<br>_______________________________________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br></blockquote></div><br></div>