Network Troubleshooting

Introduction

Use this technical note to get advice on network troubleshooting.

Discussion

Purpose

This technical note is for IAR Systems customers who need to troubleshoot network issues with the RMS License Server.

This technical note includes troubleshooting hints for Windows and Linux, but the same logic applies to other platforms too.

The reader should have basic knowledge of networking concepts.

This technical note implies that IAR Systems software has been deployed in supported environments where the product is expected to work.

Note that this technical note is not intended to be used for product deployment, but for network troubleshooting only.

IAR License Server Tools is based on the RMS License Server, which is added when the IAR License Server Tools package is installed.

Please note that Virtual Private Networks (VPN) are not officially supported by Sentinel RMS. However, since the RMS can actually work across VPNs, taking into the consideration of possible issues due to slow networks, the information provided in this technical note can be useful in VPN scenarios and VPN related hints are also included.

Applies to

IAR Systems products that use IAR License Server Tools and IAR License Manager version 2.15.3 and later.

Disclaimer(s)

IAR Systems does not provide technical support on general network connection itself, that is, when it comes to problems using/setting up your network, such as VPN, involve your IT Department and/or the VPN provider.

Possible symptoms

These are possible symptoms of network issues:

• The client computer cannot fetch licenses from the RMS License Server or loses the connection with the RMS License Server. This includes:
  • isolated client computers
  • groups of clients in remote networks
  • client computers connecting through a VPN to the server network to fetch a license from the RMS License Server.
• The connection from the server and the clients is stable although slow. However, sometimes the clients cannot fetch the license even though no packet drops are observed.
• The installation or commuting, transfer, check-out of licenses fails from remote clients, but succeeds from clients in the same subnet as the server.
• Licenses are not downloaded on all client computers that reside in a different subnet than the server.

Sanity tests

This section provides troubleshooting advice, starting from the ‘least invasive’ for the user.

Verify the port and the protocols

UDP Port 5093 must be open for both inbound and outbound traffic on the computer hosting the RMS License Server.

Note: Only IPv4 protocols are supported.

To verify the port:

On Windows:

1. On the server computer, open a command prompt with Admin privileges and type:
   netstat -naob > netstat.log
2. Open netstat.log and look for rows reporting lservnt.exe. Check which port it is using.

On Linux:

1. On the server computer, open a terminal and type:
   sudo ss -plnt | grep lserv > netstat.log
   (or without redirecting to the log file).
2. Check the output, in particular the fourth column, which should contain something like IP:PORT, and the last column which should contain the process name lserv64.

Verify that the server can be reached and that the license is seen

On the client side, IAR Light License Manager can be used to send a broadcast over UDP port 5093 where all responding license servers are displayed in a list. In addition to available servers, available network licenses are also shown.

Open a Windows command prompt or Linux terminal and type:
lightlicensemanager nwlics

For more information, refer to the Installation and Licensing Command Line User Guide and the release notes for IAR Light License Manager available from your product installation.

To verify that the selected server is in use:

On the client computer, the file Selected.package includes the name and address of the connected license server. Note that each installed product has its own selected package.

In this example, the installed product is assumed to be IAR Embedded Workbench for Arm.

On Windows:

1. Open the file
   C:\ProgramData\IARSystems\LicenseManagement\LicensePackages\ARM\EW\1\Selected.package
2. Check Server Name.

On Linux:

1. Open a terminal and type:
   cat /usr/local/etc/IARSystems/LicenseManagement/LicensePackages/ARM/EW/1/Selected.package | grep Server
2. Check the output, which should contain Server Name.

Verify that the network communication is stable

The network can be slow, but there must be no packet drops for proper communication. It is recommended that you validate the network stability with your IT department. If you are short-handed or require a quick test, you can use the simple method of opening a Windows command prompt or Linux terminal, and pinging the server.

Note:

• This simple test will not ensure that the license packets are not dropped or filtered, it just verifies that there is a direct and stable connection with small non-license related packets.
• To run this test, the server and its firewall must be configured to reply upon receiving ICMP packets.

On Windows:

ping –t ServerAddress > ping.log

On Linux:

ping ServerAddress > ping.log

In both cases, leave the console working long enough to replicate the problem, then stop it with Ctrl+C. Then, open the ping.log and check what the average delay is, and if there are any delay spikes or dropped packets.

Note that for proper communication, there must be no dropped packets at all, because RMS License Server direct communication has not been designed to work over unstable networks.

The latency can be relatively high, but it should not cause major issues as long as the connection is stable and the clients are not too many and are not making too many calls. There is no defined limit of what ‘high latency’ is for the RMS License Server to work. The term ’relatively high’ determines that the performance of the network should be enough for the number of packets and their size flowing across.

Resolution attempts

Lost packages

In the event of an unstable network (packet drops), contact your IT department. In this case, the network must be ’tuned’ until there are no lost packets.

Slow networks

If the network is just slow (high latency), a simpler and better approach is to upgrade the RMS License Server.

Note: The RMS License Server is part of the IAR License Server Tools installation.

Changing the Maximum Transmission Unit (MTU) might positively or negatively affect the connectivity between the client computer and the License Management Server, and might also affect all applications running in the same network. Therefore, it is recommended to only proceed with real tests or changes if you understand the modifications required and the effect that changing the MTU has. This option can be taken into consideration in parallel or as an alternative to upgrading the RMS License Server, but it requires testing directly on the affected network. For this reason, we recommend (as a minimum) upgrading the RMS License Server first.

Note: The MTU is the size of the largest packet the network can transmit without splitting it into multiple packets.

For successful communication between the client and license server, the MTU value should be set to 1474 or above. For larger packets (larger than the MTU size), packet fragmentation must be allowed.

Optimize the MTU

For ideal performance, the MTU send/receive size must be the same value for the client and the RMS License Server, and for the network instrumentation in between. However, the ideal MTU size also depends on RMS License Server payload, which can vary.

Note: These are other known limits:

• The MTU setting must be higher than 150 bytes (generally it exceeds 1000)
• If Windows XP or Windows Server 2003 needs to be in the network, the MTU should be set to a maximum of 1500 bytes, see http://support.microsoft.com/kb/824838.

To find the most effective packet size:

On Windows:

ping -l packetsize -t address > ping.log

On Linux:

ping -s packetsize address > ping.log

Note: 8 bytes of the ICMP header will be added to the packet size with the -s option.

The test should run both from the client towards the server address and vice versa.

Setting the MTU too low or too high might decrease network performance, while not having the same MTU set consistently across the network will cause packet fragmentation and might worsen the RMS License Server performance over VPN.

VPN products and MTU

Each VPN product might have specific MTU requirements, and if the correct size is not considered, packet fragmentation or drop might occur.

Some VPN products instead (by default) do not allow fragmented packets to flow over a VPN connection. This can be solved if the VPN allows fragmented packets forwarding—in some cases it is simply better to avoid fragmentation by setting the MTU correctly. Some VPNs use a virtual network card which is set to an MTU and which, because of additional secure VPN encapsulation, needs to be lower than the real network card + router. If such a virtual card MTU has been changed, it might also affect license performance.

Conclusion

This technical note can be seen as documentation of some common ways of troubleshooting a network license.

For more information, refer to the Installation and Licensing Command Line User Guide and the release notes for IAR Light License Manager available from your product installation.

All product names are trademarks or registered trademarks of their respective owners.