--- Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Andrew Feren schrieb:
[ snip ]
> > The problem:
> > Many sFlow packets get colorized to reflect perceived errors from the
> > sampled headers. Black for "Bad TCP" is very common since we are only
> > looking at a sample of traffic we can expect sequence numbers to be
> > missing/unseen.
[ snip ]
> Hi Andrew!
>
> Maybe I'm missing the point (I don't know sflow and you hesitate
> explaining what it is): if you are using UDP only, why is the "Bad TCP"
> rule triggering anyway?!?
The "Bad TCP" rule is triggering because there are sampled TCP headers in the
sflow packet and the TCP dissector is being called to display the information
in the TCP header. (Well actually the ip dissector is being called, but it
eventually works its way down to TCP.)
An analogous situation is the headers included in ICMP error responses. The
ICMP dissector also calls the ip dissector. For ICMP this is less of an
issue since even if TCP headers were included in an ICMP error the packet
would be colored black in either case.
For sFlow it is normal operation to include headers. Having packets marked
black that are 100% normal seems wrong. The only reason the packets are
black is that the sequence numbers in the sampled headers don't happen to
sync up with anything else.
> BTW: The coloring rules wasn't meant as a normative reference, but as an
> example that coloring is possible.
OK. Does that rule out making improvements? I can just update my
environment and forget about it.
On a related note it would be nice if there were a way to know which rule
triggered a particular color.
-Andrew
-Andrew Feren
acferen@xxxxxxxxx