In our new release of Scrutinizer version 19.1.0, we have included a handful of new reports that help to provide more information on the NetFlow collected from your network. These are the Client – Server reports, which can show directionality of requests and responses to give insight into who is asking for what and what kind of responses they get.
The client-server relationship
This is the basic client-server model we all know and love: a client reaches out to a server to get some information, and the server responds in kind. The communication can be anything from a web page to an API call to streaming video. In some cases the request and response are reasonably symmetrical, but in others the directionality is very lopsided. If you’re interested in seeing this information, we have the reports for you!
The client-server reports
We have eight new reports relating to the client-server relationship to provide insight into what these communications look like in your environment:
- Client Apps
- Client Server
- Client Server Flags
- Client Server Apps
- Client Server Apps Flags
- Server Apps
These reports can help you find out what the traffic looks like between hosts acting as servers and/or clients. These reports investigate if initial flows have a response to their requesting host and classify either side of the conversation into client and server respectively. We then have different methods to view this information and then add other elements to investigate, like applications and TCP flags (if your exporter supports these). Here is an example of a Client Server Apps report:
This report shows the client IP address, the server IP address, and the application (port and protocol) of each conversation under the graph. The two right-side columns show the directionality and bandwidth for each conversation.
Below we have a Server Flags report, which includes the TCP flags for each conversation:
These TCP flags can be useful in troubleshooting why clients are failing to connect to servers. Overall, these new reports can assist in troubleshooting these types of conversations on your network and give insight into the client-server relationship.
Why would I need these reports?
These reports can be useful because they show a directionality to the flow conversations that wouldn’t normally be obvious if you are just running something like a host-to-host report. Treating a host as a client or server can put some perspective into troubleshooting that could clarify if and why things are failing. For example, a single direction of requests from a client with no response from the server could even indicate that the server is not working as intended or not replying to requests from clients. You can even set threshold reports to alarm you when there is too much or too little traffic from a particular server or client.
If you have any questions regarding the client and server reporting, please reach out to support!