Troubleshooting Azure Redis Connectivity Issues

Scenario:

You want to test the connectivity of REDIS endpoint from your machine using the non-SSL port 6379 or SSL port 6380 as per requirement.

Actions:

There are different options available to test the connectivity of your Azure Redis cache endpoint from your machine. Let’s check on few of them.

1. Test the connectivity using REDIS CLI and STUNNEL

You can test the connectivity for REDIS for your machine on non-SSL port 6379 and SSL port 6380 using REDIS CLI tool. To test the connectivity to non-SSL port, kindly use the below syntax:

redis-cli.exe -h <YOUR CACHE ENDPOINT> -p 6379 -a <ACCESS KEY>

To test the connectivity on SSL port 6380, you need to make use of STUNNEL and make an entry in the configuration file as depicted below. Please reload the configurations after making the entry.

In case the entry is missing or the configuration isn’t loaded correctly, you may receive errors like “No connection could be made because the target machine actively refused it”, “Connection Reset by Peer” or “Unknown Error” etc.

Once configuration has been loaded successfully, try connecting to REDIS using the below syntax:

redis-cli.exe -p 6380 -a <ACCESS KEY>

In both the above tests, we made of simple PING command and received a PONG back.

2. Test the connectivity using PSPING

You can test whether you are getting response from the REDIS end point on the desired port or not by making use of PSPING. The tool can be downloaded from the below link:
https://docs.microsoft.com/en-us/sysinternals/downloads/psping

Please try the below syntax to test the connectivity and check on the number of packets being sent and received as part of testing.

psping -q <YOUR CACHE ENDPOINT>:<Port Number>

If the number of sent packets are not equal to the received packets, it points to drop in connectivity.

3. Test the connectivity using Port Query tool

You can also make use of the Port Query tool in order to test the connectivity and the tool can be downloaded from the below link:
https://www.microsoft.com/en-in/download/details.aspx?id=24009.

You need to mention the REDIS endpoint in the destination section and provide the port for which the connectivity needs to be tested. If the port is open, you will be getting the status as ‘LISTENING’ as shown below and if the port is blocked, the status will be shown as ‘FILTERED’. The below 2 screenshots depicts how the status will get reflecting depending upon the port status.

If you are not getting successful response from any of the above methods, please try checking on the below parameters to isolate the issue further.

4. Checking the Firewall Rule

Check if there is any firewall rule configured over the REDIS. This can be checked from the Azure Portal under the Settings blade. Below is the screenshot for the same:

If there is/are any rule configured, the connection to REDIS will only be allowed from the mentioned IP or the IP ranges. In case you try to connect from an IP outside the firewall rule mentioned, you will get an error. Below is an example of a connectivity test using REDIS CLI from an IP outside the firewall rule.

5. Checking the VNET configurations and NSG rules

In case you are using a Premium cache which has a VNET configuration assigned to it, the most common test can be done from the REDIS console. Incase there are any missing configurations, you will get and error like below :

In this case, you can try validating the below pointers:

• The client application/source and the REDIS are under same regions. The below example shows to check the location/region configuration of a VM and a Azure REDIS instance

• The client application/source and the REDIS are under same VNET. The below example shows to check the Virtual Network configuration of a VM and a Azure REDIS instance. You can check if a VNET is assigned to your cache or not from the “Virtual Network” section under the Settings blade from the Azure Portal     .

• In case the client application/source are under different VNET’s, both the VNET’s should have VNET peering enabled within the same Azure region. Global peering is not supported yet.
• All the Inbound and Outbound rules are in place as per the requirement.

From isolation standpoint, the above mentioned one is a sample rule that can added  be to both inbound & outbound configurations in order to allow all the ports/protocols/sources and destination and test the connectivity. Please note that the rule precedence or “Priority” should be higher for rule to get implemented.

6. Check REDIS endpoint being whitelisted

Last but not the least, in case you are using a firewall or proxy in your network, please ensure that the REDIS endpoint is whitelisted with the port number i.e. *.redis.cache.windows.net should be whitelisted for the port 6379 and port 6380 as per requirement.

Hope this helps!