|
1 | 1 | --- |
2 | | -title: Troubleshoot connectivity in Azure Cache for Redis |
| 2 | +title: Troubleshoot connectivity |
3 | 3 | description: Learn how to resolve connectivity problems when creating clients with Azure Cache for Redis. |
4 | 4 |
|
5 | 5 |
|
6 | 6 |
|
7 | 7 | ms.topic: conceptual |
8 | | -ms.date: 12/12/2023 |
| 8 | +ms.date: 04/16/2025 |
9 | 9 | appliesto: |
10 | 10 | - ✅ Azure Cache for Redis |
11 | 11 | ms.custom: template-concept, ignite-2024 |
12 | 12 | --- |
13 | 13 |
|
14 | | -# Connectivity troubleshooting |
| 14 | +# Troubleshoot Azure Cache for Redis connectivity |
15 | 15 |
|
16 | | -In this article, we provide troubleshooting help for connecting your client application to Azure Cache for Redis. Connectivity issues are divided into two types: intermittent connectivity issues and continuous connectivity issues. |
| 16 | +This article explains how to troubleshoot common issues connecting your client application to Azure Cache for Redis. Connectivity issues might be caused by intermittent conditions, or by incorrect cache configuration. This article is divided into intermittent issues and cache configuration issues. |
17 | 17 |
|
18 | | -- [Intermittent connectivity issues](#intermittent-connectivity-issues) |
19 | | - - [Server maintenance](#server-maintenance) |
20 | | - - [Number of connected clients](#number-of-connected-clients) |
21 | | - - [Kubernetes hosted applications](#kubernetes-hosted-applications) |
22 | | - - [Linux-based client application](#linux-based-client-application) |
23 | | -- [Continuous connectivity issues](#continuous-connectivity) |
24 | | - - [Test connectivity using _redis-cli_](#test-connectivity-using-redis-cli) |
25 | | - - [Test connectivity using PSPING](#test-connectivity-using-psping) |
26 | | - - [Virtual network configuration](#virtual-network-configuration) |
27 | | - - [Private endpoint configuration](#private-endpoint-configuration) |
28 | | - - [Firewall rules](#third-party-firewall-or-external-proxy) |
29 | | - - [Public IP address change](#public-ip-address-change) |
30 | | -- [Geo-replication using VNet injection with Premium caches](#geo-replication-using-vnet-injection-with-premium-caches) |
| 18 | +**Intermittent issues: |
31 | 19 |
|
32 | | -## Intermittent connectivity issues |
| 20 | +- [Kubernetes-hosted applications](#kubernetes-hosted-applications) |
| 21 | +- [Linux-based client application](#linux-based-client-application) |
| 22 | +- [Number of connected clients](#number-of-connected-clients) |
| 23 | +- [Server maintenance](#server-maintenance) |
33 | 24 |
|
34 | | -Your client application might have intermittent connectivity issues caused by events such as patching, or spikes in the number of connections. |
| 25 | +**Configuration issues: |
35 | 26 |
|
36 | | -### Server maintenance |
| 27 | +- [Firewall rules](#third-party-firewall-or-external-proxy) |
| 28 | +- [Private endpoint configuration](#private-endpoint-configuration) |
| 29 | +- [Public IP address change](#public-ip-address-change) |
| 30 | +- [Virtual network configuration](#virtual-network-configuration) |
37 | 31 |
|
38 | | -Sometimes, your cache undergoes a planned or an unplanned server maintenance. Your application can be negatively affected during the maintenance. You can validate by checking the `Errors (Type: Failover)` metric on your portal. To minimize the effects of failovers, see [Connection resilience](cache-best-practices-connection.md#connection-resilience). |
| 32 | +## Test connectivity |
39 | 33 |
|
40 | | -### Number of connected clients |
| 34 | +You can test connectivity using the Redis command line tool _redis-cli_. For more information on Redis CLI, see [Use the Redis command-line tool with Azure Cache for Redis](cache-how-to-redis-cli-tool.md). |
41 | 35 |
|
42 | | -Check if the Max aggregate for `Connected Clients` metric is close or higher than the maximum number of allowed connections for a particular cache size. For more information on sizing per client connections, see [Azure Cache for Redis performance](https://azure.microsoft.com/pricing/details/cache/). |
| 36 | +If redis-cli is unable to connect, you can test connectivity by using `PSPING` in Azure PowerShell. |
43 | 37 |
|
44 | | -### Kubernetes hosted applications |
| 38 | +```azurepowershell-interactive |
| 39 | +psping -q <cachename>:<port> |
| 40 | +``` |
45 | 41 |
|
46 | | -- If your client application is hosted on Kubernetes, check that the pod running the client application or the cluster nodes aren't under memory/CPU/Network pressure. A pod running the client application can be affected by other pods running on the same node and throttle Redis connections or IO operations. |
47 | | -- If you're using _Istio_ or any other service mesh, check that your service mesh proxy reserves port 13000-13019 or 15000-15019. These ports are used by clients to communicate with a clustered Azure Cache for Redis nodes and could cause connectivity issues on those ports. |
| 42 | +If the number of sent packets is equal to the number of received packets, there is no drop in connectivity. |
48 | 43 |
|
49 | | -### Linux-based client application |
| 44 | +## Intermittent connectivity issues |
50 | 45 |
|
51 | | -Using optimistic TCP settings in Linux might cause client applications to experience connectivity issues. See [Connection stalls lasting for 15 minutes](https://github.com/StackExchange/StackExchange.Redis/issues/1848#issuecomment-913064646). |
| 46 | +Your client application might have intermittent connectivity issues caused by spikes in the number of connections or by events such as patching. |
52 | 47 |
|
53 | | -## Continuous connectivity |
| 48 | +### Kubernetes hosted applications |
54 | 49 |
|
55 | | -If your application can't connect to your Azure Cache for Redis, it's possible some configuration on the cache isn't set up correctly. The following sections offer suggestions on how to make sure your cache is configured correctly. |
| 50 | +If your client application is hosted on Kubernetes, check whether the pod running the client application or the cluster nodes are under memory, CPU, or network pressure. A pod running the client application can be affected by other pods running on the same node and might throttle Redis connections or IO operations. |
56 | 51 |
|
57 | | -### Test connectivity using _redis-cli_ |
| 52 | +If you're using _Istio_ or any other service mesh, make sure that your service mesh proxy reserves port 13000-13019 or 15000-15019. Clients use these ports to communicate with nodes in a clustered Azure Redis cache, and could cause connectivity issues on those ports. |
58 | 53 |
|
59 | | -Test connectivity using _redis-cli_. For more information on CLI, [Use the Redis command-line tool with Azure Cache for Redis](cache-how-to-redis-cli-tool.md). |
| 54 | +### Linux-based client application |
60 | 55 |
|
61 | | -### Test connectivity using PSPING |
| 56 | +Using optimistic TCP settings in Linux might cause connectivity issues for client applications. For more information, see [TCP settings for Linux-hosted client applications](cache-best-practices-connection.md#tcp-settings-for-linux-hosted-client-applications) and [Connection stalls lasting for 15 minutes](https://github.com/StackExchange/StackExchange.Redis/issues/1848#issuecomment-913064646). |
62 | 57 |
|
63 | | -If _redis-cli_ is unable to connect, you can test connectivity using `PSPING` in PowerShell. |
| 58 | +### Number of connected clients |
64 | 59 |
|
65 | | -```azurepowershell-interactive |
66 | | -psping -q <cache DNS endpoint>:<Port Number> |
67 | | -``` |
| 60 | +Check if the **Max** aggregate for the **Connected Clients** metric is close to or higher than the maximum number of allowed connections for your cache size. For more information on sizing per client connections, see [Azure Cache for Redis performance](https://azure.microsoft.com/pricing/details/cache/). |
68 | 61 |
|
69 | | -You can confirm the number of sent packets is equal to the received packets. Confirming ensures no drop in connectivity. |
| 62 | +### Server maintenance |
70 | 63 |
|
71 | | -### Virtual network configuration |
| 64 | +Your cache might undergo planned or unplanned server maintenance that negatively affects your application during the maintenance window. You can verify this issue by checking the **Errors (Type: Failover)** metric on your cache in the Azure portal. To minimize the effects of failovers, see [Connection resilience](cache-best-practices-connection.md#connection-resilience). |
72 | 65 |
|
73 | | -Steps to check your virtual network configuration: |
| 66 | +## Connectivity configuration issues |
74 | 67 |
|
75 | | -1. Check if a virtual network is assigned to your cache from the "**Virtual Network**" section under the **Settings** on the Resource menu of the Azure portal. |
76 | | -1. Ensure that the client host machine is in the same virtual network as the Azure Cache for Redis. |
77 | | -1. When the client application is in a different virtual network (VNet) from your Azure Cache for Redis, both VNets must have VNet peering enabled within the same Azure region. |
78 | | -1. Validate that the [Inbound](cache-how-to-premium-vnet.md#inbound-port-requirements) and [Outbound](cache-how-to-premium-vnet.md#outbound-port-requirements) rules meet the requirement. |
79 | | -1. For more information, see [Configure a virtual network - Premium-tier Azure Cache for Redis instance](cache-how-to-premium-vnet.md#how-can-i-verify-that-my-cache-is-working-in-a-virtual-network). |
| 68 | +If your application can't connect to your Azure Redis cache at all, some cache configuration might not be set up correctly. The following sections offer suggestions on how to make sure your cache is configured correctly. |
| 69 | + |
| 70 | +### Firewall rules |
| 71 | + |
| 72 | +If you have a firewall configured for your Azure Cache for Redis, ensure that your client IP address is added to the firewall rules. On the Azure portal page for your cache, check **Firewall** under **Settings** in the left navigation menu. |
| 73 | + |
| 74 | +If you use a third-party firewall or proxy in your network, make sure they allow the Azure Cache for Redis endpoint `*.redis.cache.windows.net` and the ports `6379` and `6380`. You might need to allow more ports when you use a clustered cache or geo-replication. |
80 | 75 |
|
81 | 76 | ### Private endpoint configuration |
82 | 77 |
|
83 | | -Steps to check your private endpoint configuration: |
| 78 | +Check your private endpoint configuration as follows: |
84 | 79 |
|
85 | | -1. `Public Network Access` flag is disabled by default on creating a private endpoint. Ensure that you set the `Public Network Access` correctly. When you have your cache in Azure portal, look under **Private Endpoint** in the Resource menu on the left for this setting. |
86 | | -1. If you're trying to connect to your cache private endpoint from outside your virtual network of your cache, `Public Network Access` needs to be enabled. |
87 | | -1. If you delete your private endpoint, ensure that the public network access is enabled. |
88 | | -1. Verify if your private endpoint is configured correctly. For more information, see [Create a private endpoint with a new Azure Cache for Redis instance](cache-private-link.md#create-a-private-endpoint-with-a-new-azure-cache-for-redis-instance). |
89 | | -1. Verify if your application is connecting to `<cachename>.redis.cache.windows.net` on port 6380. We recommend avoiding the use of `<cachename>.privatelink.redis.cache.windows.net` in the configuration or the connection string. |
90 | | -1. To verify that the command resolves to the private IP address for the cache, run a command like `nslookup <hostname>` from within the virtual network (VNet) that is linked to the private endpoint. |
91 | | - |
92 | | -### Firewall rules |
| 80 | +- Ensure that **Public Network Access** is set correctly. In the Azure portal, select **Private Endpoint** in the left navigation menu for your cache. |
93 | 81 |
|
94 | | -If you have a firewall configured for your Azure Cache for Redis, ensure that your client IP address is added to the firewall rules. You can check **Firewall** on the Resource menu under **Settings** on the Azure portal. |
| 82 | + - Public network access is disabled by default when you create a private endpoint. |
| 83 | + - To connect to your cache private endpoint from outside your cache virtual network, you must enable **Public Network Access**. |
| 84 | + - If you delete your private endpoint, make sure to enable public network access. |
95 | 85 |
|
96 | | -#### Third-party firewall or external proxy |
| 86 | +- Make sure your private endpoint is configured correctly. For more information, see [Create a private endpoint with a new Azure Cache for Redis instance](cache-private-link.md#create-a-private-endpoint-with-a-new-azure-cache-for-redis-instance). |
97 | 87 |
|
98 | | -When you use a third-party firewall or proxy in your network, check that the endpoint for Azure Cache for Redis, `*.redis.cache.windows.net`, is allowed along with the ports `6379` and `6380`. You might need to allow more ports when using a clustered cache or geo-replication. |
| 88 | +- Make sure your application connects to `<cachename>.redis.cache.windows.net` on port 6380. Avoid using `<cachename>.privatelink.redis.cache.windows.net` in the configuration or the connection string. |
99 | 89 |
|
| 90 | +- To verify that a command resolves to the private IP address for the cache, run a command like `nslookup <hostname>` from within the virtual network that's linked to the private endpoint. |
| 91 | + |
100 | 92 | ### Public IP address change |
101 | 93 |
|
102 | | -If you configure any networking or security resource to use your cache's public IP address, check to see if your cache's public IP address changed. For more information, see [Rely on hostname not public IP address for your cache](cache-best-practices-development.md#rely-on-hostname-not-public-ip-address). |
| 94 | +If you configure any networking or security resource to use your cache's public IP address, check to see whether your cache's public IP address changed. For more information, see [Rely on hostname not public IP address](cache-best-practices-development.md#rely-on-hostname-not-public-ip-address). |
103 | 95 |
|
104 | | -## Geo-replication using VNet injection with Premium caches |
| 96 | +### Virtual network configuration |
105 | 97 |
|
106 | | -While it's possible to use virtual network (VNet) injection with your Premium caches, we recommend Azure Private Link. |
| 98 | +Check your virtual network configuration as follows: |
107 | 99 |
|
108 | | -For more information, see: |
| 100 | +- Make sure a virtual network is assigned to your cache. In the Azure portal, select **Virtual Network** under **Settings** in the left navigation menu for your cache. |
| 101 | +- Ensure that the client host machine is in the same virtual network as the cache. |
| 102 | +- If the client application is in a different virtual network from the cache, enable peering for both virtual networks within the same Azure region. |
| 103 | +- Verify that the [Inbound](cache-how-to-premium-vnet.md#inbound-port-requirements) and [Outbound](cache-how-to-premium-vnet.md#outbound-port-requirements) rules meet the port requirements. |
109 | 104 |
|
110 | | -- [Migrate from VNet injection caches to Private Link caches](cache-vnet-migration.md) |
111 | | -- [What is Azure Cache for Redis with Azure Private Link?](cache-private-link.md) |
| 105 | +For more information, see [Configure virtual network support for a Premium Azure Cache for Redis instance](cache-how-to-premium-vnet.md). |
| 106 | + |
| 107 | +#### Geo-replication issues using virtual network injection with Premium caches |
| 108 | + |
| 109 | +Geo-replication between caches in the same virtual network is supported. Geo-replication between caches in different virtual networks is also supported, with the following caveats: |
112 | 110 |
|
113 | | -Geo-replication of caches in virtual network (VNet)s is supported with caveats: |
| 111 | +- If the virtual networks are in the same region, you can connect them using [virtual network peering](/azure/virtual-network/virtual-network-peering-overview) or a [VPN Gateway VNet-to-VNet connection](/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal). |
114 | 112 |
|
115 | | -- Geo-replication between caches in the same VNet is supported. |
116 | | -- Geo-replication between caches in different VNets is also supported. |
117 | | - - If the VNets are in the same region, you can connect them using [VNet peering](../virtual-network/virtual-network-peering-overview.md) or a [VPN Gateway VNet-to-VNet connection](../vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal.md). |
118 | | - - If the VNets are in different regions, geo-replication using VNet peering isn't supported. A client VM in VNet 1 (region 1) isn't able to access the cache in VNet 2 (region 2) using its DNS name because of a constraint with Basic internal load balancers. For more information about VNet peering constraints, see [Virtual Network - Peering - Requirements and constraints](../virtual-network/virtual-network-manage-peering.md#requirements-and-constraints). We recommend using a VPN Gateway VNet-to-VNet connection. |
| 113 | +- If the virtual networks are in different regions, geo-replication using virtual network peering isn't supported. A client virtual machine in VNet 1 (region 1) can't access a cache in VNet 2 (region 2) by using its DNS name because of a constraint with Basic internal load balancers. Instead, use a VPN Gateway VNet-to-VNet connection. For more information about virtual network peering constraints, see [Virtual Network peering requirements and constraints](/azure/virtual-network/virtual-network-manage-peering#requirements-and-constraints). |
119 | 114 |
|
120 | | -To configure your virtual network (VNet) effectively and avoid geo-replication issues, you must configure both the inbound and outbound ports correctly. For more information on avoiding the most common VNet misconfiguration issues, see [Geo-replication peer port requirements](cache-how-to-premium-vnet.md#geo-replication-peer-port-requirements). |
| 115 | +To configure your virtual network effectively and avoid geo-replication issues, you must configure both the inbound and outbound ports correctly. For more information on avoiding the most common virtual network misconfiguration issues, see [Geo-replication peer port requirements](cache-how-to-premium-vnet.md#geo-replication-peer-port-requirements). |
121 | 116 |
|
122 | | -## Related Content |
| 117 | +While it's possible to use virtual network injection with Premium caches, it's preferable to use Azure Private Link. For more information, see: |
| 118 | + |
| 119 | +- [Migrate from VNet injection caches to Private Link caches](cache-vnet-migration.md) |
| 120 | +- [What is Azure Cache for Redis with Azure Private Link?](cache-private-link.md) |
123 | 121 |
|
124 | | -These articles provide more information on connectivity and resilience: |
| 122 | +## Related content |
125 | 123 |
|
126 | 124 | - [Best practices for connection resilience](cache-best-practices-connection.md) |
127 | 125 | - [High availability for Azure Cache for Redis](cache-high-availability.md) |
0 commit comments