-
Bug
-
Resolution: Done
-
Major
-
netobserv-1.3
-
None
-
None
-
False
-
None
-
False
-
-
-
NetObserv - Sprint 240, NetObserv - Sprint 241, NetObserv - Sprint 242
-
Moderate
This is the same bug as NETOBSERV-696 but applied to conversations.
The patch for NETOBSERV-696 was to reinterpret direction. It's not done for conversation, hence this new bug.
Note that it is also probably necessary to update the "swap" algorithm to also swap direction in FLP.
— Old bug recap:
(With conversation tracking enabled, and the flow table showing conversations)
In Network Traffic. under Query Options, the last sentence in the tooltip for "Reporter node" says:
Cluster ingress traffic is only reported by destination nodes, and cluster egress by source nodes.
However, the opposite is happening.
Steps to reproduce the problem:
- In Network Traffic, in Query Options, select "Destination". This is the default.
- Filter on a pod where you will make a web request.
- ssh into that pod.
- Make a curl request to a web site. It's easier to see if you use an IP address to avoid DNS traffic. Example:
curl -kL https://52.200.142.250
- In the Flow table, you will only see traffic from that pod going out to the Internet to dest port 443 (see 01-dest.png, 1st row). There will be no return traffic. This means it is the source node reporting egress traffic, even though "Destination" is selected.
- Now in Query Options, select "Source". Do the same curl request. This time, it shows only the return traffic from the web site to your pod (see 02-source.png, 1st row). This means it is the destination node reporting ingress traffic.
- clones
-
NETOBSERV-696 Reporter node behaves the opposite of what it says
- Closed
- is related to
-
NETOBSERV-1235 Reporter option issues
- Closed
-
NETOBSERV-1268 Wrong counters reported for large volume downloads
- Closed
- relates to
-
NETOBSERV-1088 Conversation tracking improvements
- To Do
-
NETOBSERV-915 Duplicate Conversation events triggered
- Closed
-
NETOBSERV-1099 UI: remove reporter option
- Closed
- links to