In FNMS does Beacon/App Server do multicasting

[nagaeendra]

We are trying to understand multicast traffic from FNMS Beacon/App Server perspective and if FNMS does multicast, when and why does it do and is it still useful.
Has anyone come across network congestion caused by fnms with multicast traffic.

[ChrisG · Accepted solution]

Really old versions of the beacon technology (from 10-15 years ago, even before the "FlexNet Manager Suite" product name was first used) provided capabilities to send Wake on LAN packets across the network to remotely turn on computers - I think this may have been able to be done using a multi-casting approach. However to my knowledge, current beacon and app server components don't do any operations that involve multi-casting.

[ChrisG · Accepted solution]

I've talked to the engineer who worked on Case Number 01931068 with you, and I think he interpreted and understood your question differently from how I've interpreted it. I understand that you are asking about IP multicasting, being the method of sending IP datagrams to multiple receivers in a single transmission across the network (as described here). After discussing with some colleagues who are familiar with this area, we all can't think of any way that the beacon would generate this type of IP multicasting network traffic. 

In relation to the following comment:

"Yes, currently the released version of beacon (2019 R1 or earlier) , the beacon designed behavior will do DNS lookup for all target devices, which does create traffic concern from IT point of view. However as long as we heard it didn't cause significant issue. [...]"

---

In case it helps your understanding in relation to the DNS lookup operations mentioned here, these are performed using the System.Net.Dns.GetHostEntry API. The comments quoted above about DNS lookups are accurate, except that the DNS lookups discussed in this comment do not generate IP multicasting network traffic of the type I am referring to.

I hope that clarifies!

[ChrisG · Accepted solution]

Really old versions of the beacon technology (from 10-15 years ago, even before the "FlexNet Manager Suite" product name was first used) provided capabilities to send Wake on LAN packets across the network to remotely turn on computers - I think this may have been able to be done using a multi-casting approach. However to my knowledge, current beacon and app server components don't do any operations that involve multi-casting.

[nagaeendra]

Hi Chris,
Thanks you for your reply, Appricate if you can help to check if your understanding is right, cos i happen to find this "This version reduces FlexNet Beacon engine’s DNS lookups, avoiding situations where too many DNS reads occur. As well, it limits DNS reads so that there are no reads outside a particular FlexNet Beacon's assigned subnet." from https://docs.flexera.com/FlexNetManagerSuite2019R2/EN/features/index.html#FeatureList/2019R2/RN_chg_InvBeacon.html

[ChrisG]

The particular matter related to DNS lookups you've referred to there is not related to multicasting. DNS queries are made using a point-to-point (not multicast) communication from the beacon to a DNS server.

The network discovery process performed by beacons also makes various points-to-point connections (e.g. using TCP & ICMP) to ranges of IP addresses according to what you have configured the discovery process to do. For example, if you have configured a discovery job to scan the IP range 10.12.0.0/16 then the discovery process will attempt to make individual connections to all 65,536 IP addresses in that range. A term for this could be "unicasting" to many devices. I still believe that IP multicasting techniques (i.e. simultaneous one-to-many communication) are not used in that process.

[nagaeendra]

Hi Chris,

Thanks again for your reply which give a different perspective which is kind of surprisingly confusing, cos we were earlier give this understanding by Flexera through this case Case Number: 01931068

for our query as “Does FNMS Beacon generate multicast communication with agents.”

And  Revert for which states as

“ Yes, currently the released version of beacon (2019 R1 or earlier) , the beacon designed behavior will do DNS lookup for all target devices, which does create traffic concern from IT point of view. However as long as we heard it didn't cause significant issue.

Good news is there is an existing enhancement request ticket raised from other customer -- IOJ-1919319  Enhancement request to have beacon engine reduce DNS look up for all the targets.   What good is this enhancement has been included in the coming release of  2019 R2. ETA of release date is mid of Nov this year. 

Hope it helps. please let me know if this case can be closed as clarified. “

 and apparently then we were also pointed to the same link which is shared earlier. Now which one are we suppose to take  🙂  

[ChrisG · Accepted solution]

I've talked to the engineer who worked on Case Number 01931068 with you, and I think he interpreted and understood your question differently from how I've interpreted it. I understand that you are asking about IP multicasting, being the method of sending IP datagrams to multiple receivers in a single transmission across the network (as described here). After discussing with some colleagues who are familiar with this area, we all can't think of any way that the beacon would generate this type of IP multicasting network traffic. 

In relation to the following comment:

"Yes, currently the released version of beacon (2019 R1 or earlier) , the beacon designed behavior will do DNS lookup for all target devices, which does create traffic concern from IT point of view. However as long as we heard it didn't cause significant issue. [...]"

---

In case it helps your understanding in relation to the DNS lookup operations mentioned here, these are performed using the System.Net.Dns.GetHostEntry API. The comments quoted above about DNS lookups are accurate, except that the DNS lookups discussed in this comment do not generate IP multicasting network traffic of the type I am referring to.

I hope that clarifies!

[ChrisG]

Somebody has pointed out to me that name resolution in some networks can use some multicast-based communications, as described on the following pages:

• Multicast DNS
• Link-Local Multicast Name Resolution

I'm not too familiar with this, but if the environment you are working in is set up such that name resolution generates multicast traffic (instead of the more common unicast traffic to a DNS server) then I guess you would likely see that sort of multicast traffic from computers in the environment (including beacons) whenever they do name resolution operations.

[nagaeendra]

Hi Chris,

Thanks, point taken, so from Appication stand point how can we show with evidence that the Application as such is not doing any multicast. 

[kclausen · Accepted solution]

@nagaeendra - As mentioned by Chris, the FNMS Application does not have any built into the product that would generate multicasting traffic.

Any traffic that is multicast would be the result of how your internal DNS Servers are configured, as highlighted by the two links in the post from Chris.

[nagaeendra]

Hi @kclausen 

Thank you for the update. 

I understand that  " the FNMS Application does not have any built into the product that would generate multicasting traffic "  

Having said that, from the FNMS stand point,  can we show when DNS lookup operation is triggered and at what frequency. 

[kclausen]

@nagaeendra - Yes, your Network Administration Team should be able to monitor and report on the Agent Traffic using their existing network tools.

[rwiltshire]

Thanks for all the replies.

I'll pass the info on to our network teams.

In our case, the network team observes the traffic and the impact on our DNS appliances.

[ChrisG]

---

@nagaeendra wrote:

Having said that, from the FNMS stand point,  can we show when DNS lookup operation is triggered and at what frequency. 

---

The heaviest DNS activity generated by the beacon is likely to occur when the beacon is performing discovery and possibly remote execution (zero touch) operations. This will occur according to the schedule & frequency that you have configured for these operations.