Andrew Feren schrieb:
I'd like to make/propose a change to the default colorization rules.
The scenario:
In sampled mode sFlow datagrams include the headers of sampled
packets. Wireshark very nicely calls the appropriate dissectors to
nicely display the sampled headers.
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.
Possible solution:
Create a default colorization rule using the same color as UDP traffic
and the rule "udp && sflow". This would need to be the first rule in
the list (or at least a head of "Bad TCP" which is first in my current
install.
Caveats:
sFlow can be sent over TCP as well as UDP (I'm not using sFlow over
TCP so I'm willing to ignore this for now ;-). I'm not quite sure how
to deal with this situation. Creating a "tcp && sflow" rule ahead of
the "Bad TCP" rule sort of defeats the purpose if there are errors in
the sFlow TCP. On the other hand having the contents of the sFlow
message colorize tends to create a lot of noise and mask any real TCP
errors.
Other thoughts:
Should there be a different color to indicate that colorizing has been
short circuited. So instead of colorizing sflow over UDP as UDP color
all sflow (over UDP and TCP) in a unique way. I'm not sure if there
are other protocols that might need something like this.
Final question:
If I want to create a patch to change the default colorization which
file(s) do I need to modify?
Thanks for any suggestions/thoughts/comments,
-Andrew
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?!?
BTW: The coloring rules wasn't meant as a normative reference, but as an
example that coloring is possible.
Regards, ULFL
