[f-nsp] MLX-4 SFLOW issues?

[Josh Galvez]

Skylar,

This is a bug in 5.6.0a.

See:
https://puck.nether.net/pipermail/foundry-nsp/2014-June/004396.html

in 5.6b (but fixed in 5.6c):
Defect ID: DEFECT000502305
Technical Severity: Medium Probability: High
Product: Multi-Service IronWare Technology: Management
Reported In Release: NI 05.6.00 Technology Area: SFLOW
Closed In Release(s): NI 05.6.00c(Fixed)
Symptom: An incorrect raw packet header length in the sFlow protocol is
observed.
Condition: Issue is seen while running L3 traffic along while enabling
sFlow on an interface. sFlow enabled interfaces send sFlow data packets
to an sFlow collector. At the collector the raw packet header length is
less than what was originally sent.

In 5.6c (not in 5.6b, no fix yet):
Defect 505978
BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP
cpnnection is in SYN-SENT state.
It will occur if you peer using loopback address with /128 mask.
It will be fixed in 5.6d which is not released yet.
Current workaround would be to not use /128 mask or to downgrade your code



On Tue, Jul 15, 2014 at 2:01 PM, Skylar MacMinn <skylar at crissic.net> wrote:

>  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.
>
>
>
> 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.
>
>
>
> Our current installed firmware is the following:
>
>  IronWare : Version 5.6.0aT177 Copyright (c) 1996-2013 Brocade
> Communications Systems, Inc.
>
> Compiled on Dec  5 2013 at 11:08:04
>
>
>
>
>
> 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.
>
>
>
> Cordially Yours,
>
>
>
> Skylar MacMinn
>
> www.crissic.net
> Crissic Solutions, LLC
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20140715/fc22677d/attachment.html>