Troubleshooting Azure Redis Connectivity Issues.
Scenario:
To test the connectivity of REDIS endpoint from the 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 the Azure Redis cache endpoint from the machine. Check on few of them.
- Test the connectivity using REDIS CLI and STUNNEL
Test the connectivity for REDIS for the machine on non-SSL port 6379 and SSL port 6380 using REDIS CLI tool. To test the connectivity to non-SSL port, use the below syntax:
redis-cli.exe -h -p 6379 -a
To test the connectivity on SSL port 6380, 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 is not loaded correctly, errors like “No connection could be made because the target machine actively refused it”, “Connection Reset by Peer” or “Unknown Error” etc may be thrown.
Once configuration has been loaded successfully, try connecting to REDIS using the below syntax:
redis-cli.exe -p 6380 -a
In both the above tests, we made of simple PING command and received a PONG back.
- Test the connectivity using PSPING
Test whether response is obtained 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
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 :
If the number of sent packets are not equal to the received packets, it points to drop in connectivity.
- Test the connectivity using Port Query tool
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.
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, the status ‘LISTENING’ is obtained 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 not getting successful response from any of the above methods, try checking on the below parameters to isolate the issue further.
- 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 tried to connect from an IP outside the firewall rule mentioned, an error will be obtained. Below is an example of a connectivity test using REDIS CLI from an IP outside the firewall rule.
- Checking the VNET configurations and NSG rules
If 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, error like below will be thrown,
In this case, 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 an Azure REDIS instance. Check if a VNET is assigned to the 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.
- Check REDIS endpoint being whitelisted
If using a firewall or proxy in the network, 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.