Managing network connectivity issues - Support and Troubleshooting

Managing network connectivity issues Issue  Users are unable to connect to the instance. The instance is slow or sometimes unavailable. Users are able to connect to the instance, but cannot authenticate or log in. Cause There is no network connectivity. The instance is not able to connect to the Lightweight Directory Access Protocol (LDAP) server. Resolution To troubleshoot network connectivity issues in your ServiceNow instance, you must initially gather data from each network. Until this data is collected, there is no way to determine if the issue originated from the ServiceNow network, the internet service provider, your own internal network, or a combination of these. As a general recommendation, if the browser is producing an error, capture the error number or take a screenshot of the page to help with the troubleshooting process.

The steps for troubleshooting network connectivity issues are listed in logical, sequential order. Please do not skip any step.

Important: If you are able to connect to the instance but cannot authenticate or log in, skip to the To verify connectivity from the instance to your LDAP server section. To verify the network connectivity Open a Terminal session on your computer using the following menu path: From the Windows Start Menu: Start > Run > cmd Once in the Terminal, type ping to test the connectivity to the instance and press Enter to initiate the ping command. The following image displays the results after running the ping command. The output displays the hostname of the instance needed to troubleshoot the network issue. The Internet Protocol (IP) address can also be used, and in this case, the IP address is 199.91.140.73. Depending on the computer, the ping command can run indefinitely, so use + C to kill the transaction, if necessary. The ping command output shows that there are three packets, each of 64 bytes, and the round trip time or latency is approximately 100ms.

The following image reflects the result of running ping on an IP address with no response. If there is no response, but it is possible to ping from another location successfully, then a routing issue exists between the user and the instance. If so, run the ping command on another target, for example, www.google.com. If the site cannot be reached, then the issue is likely on the user's side.

Important: If you are able to reach the objective site but not the instance, escalate the issue to the Technical Support - Network Engineering team for further investigation. Some useful options for the ping command is to set the count limit, change the number of packets per second, or increase the packet size, depending on the troubleshooting scenario. Unless you have a reason to change either of these settings, the default is usually the best option. For more options using the ping command, use the manual ( man ) pages for ping on Mac or help on Windows:

Mac: man ping Windows: ping /?

Use the traceroute command to test the route (path) and measure transit delays of packets across the instance IP network. The image below indicates that the last hop is service-now.car1.washington1.level3.net. This means the packets are reaching the ServiceNow data center provider. Additional information may be needed to determine whether the address is a ServiceNow provider.

Note: The Traceroute command will always timeout before reaching the destination due to the ServiceNow proxy configuration. Ping and traceroute are point-in-time snapshots. To obtain a more accurate image, run these commands multiple times and calculate an average. Interpreting the response times depends on the user location and the type of Internet connection.

As a reference, ping times are usually within the following ranges:

100ms within the United States. 100 - 150ms from the United Kingdom to the United States. 200 - 300ms from the United States to Europe, the Middle East and Africa. Important: Results may vary greatly. Running multiple ping tests using multiple web sites is highly recommended. If latency (ping times) or packet loss is suspected to be part of the issue, escalate the issue to the Technical Support - Network Engineering team for further investigation. To verify connectivity from the instance to your LDAP server Note: If you are part of the ServiceNow Technical Support team, please refer to Verifying connectivity from an instance to a LDAP server for details on the internal process. Note: The following steps use a fake instance name that is experiencing network connectivity issues. The IP address in the LDAP server record is a Google web server, and port 80 is used for the connection. LDAP commonly uses port 389 and Secure LDAP (LDAPS) uses port 636, but both can be modified if necessary. It is important to test the connection using the port that is configured in the same instance that is presenting network issues. Navigate to System LDAP > LDAP Servers to obtain the LDAP IP and port information.

Navigate to System Diagnostics > Stats to determine the name of the server hosting the instance.

Log in to the server where the instance is hosted. Run the telnet command to the IP of the LDAP server and specify the port that is being used. In the image below, please note that there is a successful connection to 75.125.226.243 on port 80. If there is a successful connection here, but you are not able to establish a connection using the Test Connection link in the instance, then examine the credentials and verify that the customer's LDAP server allows connections from the outgoing IP address. For more details, refer to the IP Information article in the ServiceNow Datacenter Knowledge Base.

If the issue continues to exist after following the steps in this article:

Clearly identify the issue or question. Visit the ServiceNow product documentation . Search the ServiceNow Community . Post a question on the ServiceNow Community forums . New users must create an account on the ServiceNow Community in order to post. Contact ServiceNow Customer Support . Related Links For more information on related topics, review the following product documentation articles:

MID Server System Requirements Active Directory Application Mode (ADAM) ODBC Driver LDAP Integration Network Response Times For more topic-related issues, review the following knowledge base article:

Troubleshooting slow performance