TCP/UDP port query

Hi,

We have a situation where action are taking lots of time, sometime its more then 24hr hence checked network front for TCP/UCP port block & found action item fixed. However still we are facing same problem on different countries
so we want go for a deep analysis using BIGFIX to check for UDP communication -

  1. between endpoints to their Relay & root server
  2. Relay to their top relay or root server.

I have google it & found UDP messages status analysis for this task hence checked that but seems not very useful so my question is - Is there any fixlet or analysis which can be run on endpoint to get the output of UDP port communication on above mentioned 2 points.

or any suggestion which we can help us to get rid of this problem.

UDP communication is typically downstream, from an endpoint’s parent relay to an endpoint, or the BigFix server itself to an endpoint (if that’s the endpoint’s immediate parent). There’s no UDP communication from an endpoint to its parent relay, nor between relays.

If an action is taking a lot of time to run, and you think that the client is not getting the UDP signal to “do something”, check the BES client log for the word “GatherHashMV”. That’s usually indication that a client has received a UDP signal to do something. An easy way to do this is to create an empty action and then run that action on the endpoint.

You could also telnet from the top level relay to the next relay, etc, down to the parent relay, and then telnet the opposite way over port 52311 to ensure that port is open all the way through.

–Mark

2 Likes

Did the status analysis use the last command time inspector?

https://developer.bigfix.com/relevance/reference/client.html#last-command-time-of-client-time

This will indicate the last time the client received a UDP message from its immediate parent. While it doesn’t help specifically finding the cause it might give you some indications. I would always make sure the client has registered so making sure that this time is more recent than the relay select time

https://developer.bigfix.com/relevance/reference/time.html#last-relay-select-time-time

1 Like

Hi @vk.khurava please watch this OpenMic:

1 Like

It won’t address your UDP issues, but you can effectively set a minimum threshold by enabling Command Polling, which I strongly recommend to set for all clients that do not get UDP to something like once an hour. For clients that DO get the UDP notifications, I would still recommend setting it to something in the 3 hour to 6 hour time frame since clients will not get UDP notifications when they are sleeping or powered off or otherwise disconnected.

This analysis will provide some info about the state of UDP in your environment for your clients: https://bigfix.me/analysis/details/2994765

Enable command polling for endpoints not getting UDP messages: https://bigfix.me/fixlet/details/3798

Enable command polling once every 12 hours for all clients: https://bigfix.me/fixlet/details/3799 (could be changed to something else in the relevance and actionscript to be 3 hours or 6 hours)

3 Likes

Thanks all for sharing such useful info but still we want to check & capture results of UDP connectivity from all Relay to their endpoints, so that we can investigate it & forward these results to network team.

Previously I was working on endpoints to relay UDP port 52311 connectivity testing using port query & fetch their results in a text file & then call it using a Analysis. Now I am want to create same kind of fixlet/task to check UDP port 52311 connectivity from Relay to their endpoint where command will check/scan relay to endpoint’s whole subnet & capture those results in a text file.

I googled such kind of command parameters but no luck, can you please provide your expert advice or suggest something relevant to it, pls.

I’m still a little confused on what you are trying to do.

The clients don’t talk to the Relays using UDP at all. They use TCP for this.

Relays send UDP messages to the clients.

Are you trying to figure out which clients are getting UDP and which are not? or is there a different goal? What is the problem that you are trying to solve? It is very hard to help without more information.

It is pretty easy to determine which clients get UDP and which do not just by doing something to cause the Relay to send a UDP message and then check the last command time of the clients that are not sleeping at the time to see if it is set or updates.

You need to have UDP over port 52311 allowed incoming to all clients through all hardware firewalls and OS firewalls to help enable clients to get UDP. Generally the network team only needs to worry about configuring any hardware firewalls to allow UDP incoming over 52311.

Also, I believe the hardware firewalls are only an impediment if there isn’t a relay behind the firewall already.

Yes ! JGSTEW, this is what I want to achieve but I dont have complete trust on “UDP Message Status Analysis” thats why I want to run a command or script from relay to client’s subnet which will generate or capture UDP port 52311 connectivity in a result file, post capturing this data will analyse & share the same (evidence) with Network Team if there is any UDP port blockess from Relay to Client.

You can already do this because the client lets you know when it last got a UDP message. Just do something in the console that triggers a UDP message to be sent, then check the Last Command Time on the client. If it doesn’t update, then that means the UDP message didn’t arrive.

Otherwise just use normal networking generation and capture stuff that is completely unrelated to BigFix, but have it send a UDP message to 52311 on the client. You may need to turn off the BigFix agent first to property capture UDP.

2 Likes