Delen via

VNet-ondersteuning (virtueel netwerk) configureren voor een Premium Azure Cache voor Redis-exemplaar

  • Van toepassing op: ✅ Azure Cache for Redis

Belangrijk

Azure Cache voor Redis heeft de tijdlijn voor buitengebruikstelling aangekondigd voor alle SKU's. We raden je aan om je Azure Cache voor Redis-instances zo snel mogelijk te verplaatsen naar Azure Managed Redis.

Voor meer informatie over de buitengebruikstelling:

Azure Virtual Network-implementatie biedt verbeterde beveiliging en isolatie, samen met: subnetten, toegangsbeheerbeleid en andere functies om de toegang verder te beperken. Wanneer een Azure Cache voor Redis-exemplaar is geconfigureerd met een virtueel netwerk, is het niet openbaar adresseerbaar. In plaats daarvan kan het exemplaar alleen worden geopend vanuit virtuele machines en toepassingen binnen het virtuele netwerk. In dit artikel wordt beschreven hoe u ondersteuning voor virtuele netwerken configureert voor een Premium-laag Azure Cache voor Redis exemplaar.

Notitie

Het klassieke implementatiemodel wordt in augustus 2024 buiten gebruik gesteld. Zie Cloud Services (klassiek) implementatiemodel op 31 augustus 2024 buiten gebruik gesteld voor meer informatie.

Belangrijk

Azure Cache voor Redis raadt u aan om Azure Private Link te gebruiken, wat de netwerkarchitectuur vereenvoudigt en de verbinding tussen eindpunten in Azure beveiligt. U kunt vanuit uw virtuele netwerk verbinding maken met een Azure Cache-exemplaar via een privé-eindpunt, waaraan een privé-IP-adres in een subnet binnen het virtuele netwerk is toegewezen. Azure Private Links worden aangeboden in alle lagen en bevatten Azure Policy-ondersteuning en vereenvoudigd beheer van NSG-regels. Zie de Private Link-documentatie voor meer informatie. Zie Caches met VNet-injectie migreren naar Private Link-caches om uw caches met VNet-injectie te migreren naar Private Link.

Beperkingen van VNet-injectie

  • Het maken en onderhouden van configuraties voor virtuele netwerken is vaak foutgevoelig. Het oplossen van problemen is ook lastig. Onjuiste configuraties voor virtuele netwerken kunnen leiden tot problemen:
    • geblokkeerde overdracht van metrische gegevens van uw cache-exemplaren
    • fout van replicaknooppunt om gegevens te repliceren van primair knooppunt
    • mogelijk gegevensverlies
    • mislukte beheerbewerkingen, zoals schalen
    • onregelmatige of volledige SSL/TLS-fouten
    • het niet toepassen van updates, inclusief belangrijke verbeteringen op het gebied van beveiliging en betrouwbaarheid
    • in de meest ernstige scenario's, verlies van beschikbaarheid
  • Wanneer u een in VNet geïnjecteerde cache gebruikt, moet u uw VNet bijgewerkt houden om toegang te verlenen tot cacheafhankelijkheden, zoals certificaatintrekkingslijsten, openbare sleutelinfrastructuur, Azure Key Vault, Azure Storage, Azure Monitor en meer.
  • In VNet geïnjecteerde caches zijn alleen beschikbaar voor Premium-laag Azure Cache voor Redis, niet voor andere lagen.
  • U kunt een bestaand Azure Cache voor Redis exemplaar niet injecteren in een virtueel netwerk. U moet deze optie selecteren wanneer u de cache maakt .
  • Azure Portal biedt geen ondersteuning voor het configureren van VNET-injectie tijdens het maken van resources

Ondersteuning voor virtueel netwerk instellen

Raadpleeg az redis create.

Veelgestelde vragen over virtuele netwerken voor Azure Cache voor Redis

De volgende lijst bevat antwoorden op veelgestelde vragen over Azure Cache voor Redis netwerken.

Wat zijn enkele veelvoorkomende problemen met onjuiste configuratie met Azure Cache voor Redis en virtuele netwerken?

Wanneer Azure Cache voor Redis wordt gehost in een virtueel netwerk, worden de poorten in de volgende tabellen gebruikt.

Belangrijk

Als de poorten in de volgende tabellen worden geblokkeerd, werkt de cache mogelijk niet correct. Het blokkeren van een of meer van deze poorten is het meest voorkomende probleem met onjuiste configuratie wanneer u Azure Cache voor Redis in een virtueel netwerk gebruikt.

Vereisten voor de uitgaande poort

Er zijn vereisten voor netwerkconnectiviteit voor Azure Cache voor Redis nodig voor uitgaande connectiviteit met andere afhankelijkheidsservices die nodig zijn om de cache te laten functioneren, of zelfs intern voor het Redis-subnet voor communicatie tussen knooppunten.

Poorten Richting Transportprotocol Doel Lokaal IP-adres Extern IP-adres
80, 443 Uitgaand TCP Redis-afhankelijkheden van Azure Storage, PKI (internet), besturingssysteem, infrastructuur en antivirus (Redis-subnet) * 4
443 Uitgaand TCP Redis-afhankelijkheid van Azure Key Vault en Azure Monitor (Redis-subnet) AzureKeyVault, AzureMonitor 1
12000 Uitgaand TCP Redis-afhankelijkheid van Azure Monitor (Redis-subnet) AzureMonitor 1
53 Uitgaand TCP/UDP Redis-afhankelijkheden op DNS (internet/virtueel netwerk) (Redis-subnet) 168.63.129.16 en 169.254.169.254 2 en eventuele aangepaste DNS-server voor het subnet 3
123 Uitgaand UDP Afhankelijkheid van besturingssysteem op NTP (Redis-subnet) *
1688 Uitgaand TCP Afhankelijkheid van besturingssysteem voor activering (Redis-subnet) *
8443 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
10221-10231 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
20226 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
13000-13999 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
15000-15999 Uitgaand TCP Interne communicatie voor Redis en geo-replicatie (Redis-subnet) (Redis-subnet) (Geo-replica-peersubnet)
6379-6380 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)

1 U kunt de servicetags AzureKeyVault en AzureMonitor gebruiken met netwerkbeveiligingsgroepen (NSG's) van Resource Manager.

2 Deze IP-adressen die eigendom zijn van Microsoft, worden gebruikt om de host-VM te adresseren die azure DNS dient.

3 Deze informatie is niet nodig voor subnetten zonder aangepaste DNS-server of nieuwere Redis-caches die aangepaste DNS negeren.

4 Zie Aanvullende vereisten voor virtuele netwerkconnectiviteit voor meer informatie.

Vereisten voor geo-replicatie peer-poort

Als u geo-replicatie tussen caches in virtuele Azure-netwerken gebruikt: a) deblokkeren poorten 15000-15999 voor het hele subnet in zowel binnenkomende als uitgaande richtingen, en b) naar beide caches. Met deze configuratie kunnen alle replicaonderdelen in het subnet rechtstreeks met elkaar communiceren, zelfs als er een toekomstige geo-failover is.

Vereisten voor inkomende poort

Er zijn acht binnenkomende poortbereikvereisten. Binnenkomende aanvragen in deze bereiken zijn binnenkomend van andere services die worden gehost in hetzelfde virtuele netwerk. Of ze zijn intern voor de communicatie van het Redis-subnet.

Poorten Richting Transportprotocol Doel Lokaal IP-adres Extern IP-adres
6379, 6380 Inkomend TCP Clientcommunicatie met Redis, Azure-taakverdeling (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer 1
8443 Inkomend TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
8500 Inkomend TCP/UDP Azure-taakverdeling (Redis-subnet) AzureLoadBalancer
10221-10231 Inkomend TCP Clientcommunicatie met Redis-clusters, interne communicatie voor Redis (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer
13000-13999 Inkomend TCP Clientcommunicatie met Redis-clusters, Azure-taakverdeling (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer
15000-15999 Inkomend TCP Clientcommunicatie met Redis-clusters, Azure-taakverdeling en geo-replicatie (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer, (geo-replica peersubnet)
16001 Inkomend TCP/UDP Azure-taakverdeling (Redis-subnet) AzureLoadBalancer
20226 Inkomend TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)

1 U kunt de servicetag AzureLoadBalancer gebruiken voor Resource Manager of AZURE_LOADBALANCER voor het klassieke implementatiemodel voor het ontwerpen van de NSG-regels.

Aanvullende vereisten voor virtuele netwerkconnectiviteit

Er zijn vereisten voor netwerkconnectiviteit voor Azure Cache voor Redis nodig voor uitgaande connectiviteit met andere afhankelijkheidsservices die nodig zijn om de cache te laten functioneren, of zelfs intern voor het Redis-subnet voor communicatie tussen knooppunten.

Azure Cache voor Redis vereist dat alle volgende uitgaande connectiviteitsitems correct werken wanneer ze in een virtueel netwerk worden gebruikt:

Hostnaam Protocol Uitgaande poort Doel Servicetag
*.vault.azure.net HTTPS 443 Azure Key Vault AzureKeyVault
*.table.core.windows.net HTTPS 443 Azure Storage Storage
*.blob.core.windows.net HTTPS 443 Azure Storage Storage
*.queue.core.windows.net HTTPS 443 Azure Storage Storage
*.file.core.windows.net HTTPS 443 Azure Storage Storage
ocsp.digicert.com/* HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
crl4.digicert.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
ocsp.msocsp.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
mscrl.microsoft.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
crl3.digicert.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
cacerts.digicert.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
oneocsp.microsoft.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
crl.microsoft.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
cacerts.geotrust.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
www.microsoft.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
cdp.geotrust.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
status.geotrust.com HTTP 80 Azure Publieke Sleutelinfrastructuur N.v.t.
shoebox3.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
shoebox3-red.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
shoebox3-black.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
azredis.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
azredis-red.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
azredis-black.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
global.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
gcs.prod.monitoring.core.windows.net HTTPS 443 Azure Monitor AzureMonitor
*.prod.warm.ingest.monitor.core.windows.net HTTPS 443 Azure Monitor AzureMonitor
*.servicebus.windows.net HTTPS 443 Azure Monitor EventHub
*.update.microsoft.com HTTPS 443 Updateservice van besturingssysteem AzureCloud
*.windowsupdate.com HTTP/HTTPS 80, 443 Updateservice van besturingssysteem N.v.t.
*.delivery.mp.microsoft.com HTTP/HTTPS 80, 443 Updateservice van besturingssysteem AzureCloud
go.microsoft.com HTTP/HTTPS 80, 443 Antivirus N.v.t.
*.wdcp.microsoft.com HTTPS 443 Antivirus AzureCloud
*.wdcpalt.microsoft.com HTTPS 443 Antivirus AzureCloud
*.wd.microsoft.com HTTPS 443 Antivirus AzureCloud
definitionupdates.microsoft.com HTTPS 443 Antivirus N.v.t.
azurewatsonanalysis-prod.core.windows.net HTTPS 443 Interne diagnostische gegevens AzureCloud
shavamanifestazurecdnprod1.azureedge.net HTTPS 443 Interne diagnostische gegevens N.v.t.
shavamanifestcdnprod1.azureedge.net HTTPS 443 Interne diagnostische gegevens N.v.t.
*.data.microsoft.com HTTPS 443 Interne diagnostische gegevens AzureCloud
  • De DNS-configuratie voor het virtuele netwerk moet alle eindpunten en domeinen in de eerdere tabelvermeldingen kunnen oplossen. Aan deze DNS-vereisten kan worden voldaan door ervoor te zorgen dat een geldige DNS-infrastructuur is geconfigureerd en onderhouden voor het virtuele netwerk.

Hoe kan ik controleren of mijn cache in een virtueel netwerk werkt?

Belangrijk

Wanneer u verbinding maakt met een Azure Cache voor Redis exemplaar dat wordt gehost in een virtueel netwerk, moeten uw cacheclients zich in hetzelfde virtuele netwerk bevinden of in een virtueel netwerk met peering van virtuele netwerken ingeschakeld binnen dezelfde Azure-regio. Wereldwijde peering van virtuele netwerken wordt momenteel niet ondersteund. Deze vereiste is van toepassing op alle testtoepassingen of hulpprogramma's voor diagnostisch pingen. Ongeacht waar de clienttoepassing wordt gehost, moeten NSG's of andere netwerklagen zodanig worden geconfigureerd dat het netwerkverkeer van de client de Azure Cache voor Redis kan bereiken.

Nadat de poortvereisten zijn geconfigureerd zoals beschreven in de vorige sectie, is opnieuw opstarten in de meeste gevallen nodig om ervoor te zorgen dat de wijzigingen correct worden weergegeven. Anders kunnen er verbindingsproblemen optreden. U kunt controleren of uw cache werkt door de volgende stappen uit te voeren:

  • Start alle cacheknooppunten opnieuw op . De cache kan niet opnieuw worden opgestart als alle vereiste cacheafhankelijkheden niet kunnen worden bereikt---as gedocumenteerd in de vereisten voor binnenkomende poorten en vereisten voor uitgaande poorten.
  • Nadat de cacheknooppunten opnieuw zijn opgestart, zoals gerapporteerd door de cachestatus in Azure Portal, kunt u de volgende tests uitvoeren:

    • Ping het cache-eindpunt met behulp van poort 6380 vanaf een computer die zich binnen hetzelfde virtuele netwerk bevindt als de cache, met behulp van tcping. Voorbeeld:

      tcping.exe contosocache.redis.cache.windows.net 6380

      Als het tcping hulpprogramma meldt dat de poort is geopend, is de cache beschikbaar voor verbinding vanaf clients in het virtuele netwerk.

    • Een andere manier om te testen: maak een testcacheclient die verbinding maakt met de cache en voegt vervolgens enkele items uit de cache toe en haalt deze op. De testcacheclient kan een consoletoepassing zijn met behulp van StackExchange.Redis. Installeer de voorbeeldclienttoepassing op een virtuele machine die zich in hetzelfde virtuele netwerk bevindt als de cache. Voer deze vervolgens uit om de verbinding met de cache te controleren.

Wanneer ik verbinding probeer te maken met mijn Azure Cache voor Redis exemplaar in een virtueel netwerk, waarom krijg ik een foutmelding waarin wordt aangegeven dat het externe certificaat ongeldig is?

Wanneer u verbinding probeert te maken met een Azure Cache voor Redis exemplaar in een virtueel netwerk, ziet u een certificaatvalidatiefout zoals deze:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

De oorzaak kan zijn dat u verbinding maakt met de host door het IP-adres. U wordt aangeraden de hostnaam te gebruiken. Gebruik met andere woorden de volgende tekenreeks:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Vermijd het gebruik van het IP-adres dat lijkt op de volgende verbindingsreeks:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Als u de DNS-naam niet kunt oplossen, bevatten sommige clientbibliotheken configuratieopties zoals sslHost, die worden geleverd door de StackExchange.Redis-client. Met deze optie kunt u de hostnaam overschrijven die wordt gebruikt voor certificaatvalidatie. Voorbeeld:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Als bovendien het subnet waar Azure Cache voor Redis wordt gehost TCP-uitgaande verbindingen via poort 80 blokkeert voor SSL-/TLS-functionaliteit, kunnen clients onregelmatige validatiefouten met TLS-certificaten ondervinden.

Kan ik virtuele netwerken gebruiken met een standaard- of basiscache?

Virtuele netwerken kunnen alleen worden gebruikt met Premium-laag-caches.

Waarom mislukt het maken van een Azure Cache voor Redis exemplaar in sommige subnetten, maar niet in andere?

Als u een Azure Cache voor Redis exemplaar implementeert in een virtueel netwerk, moet de cache zich in een toegewezen subnet bevinden dat geen ander resourcetype bevat. Als er een poging wordt gedaan om een Azure Cache voor Redis-exemplaar te implementeren in een subnet van een virtueel Resource Manager-netwerk dat andere resources bevat--- zoals Azure-toepassing Gateway-exemplaren en uitgaande NAT---de implementatie mislukt meestal. Verwijder de bestaande resources van andere typen voordat u een nieuw exemplaar van Azure Cache voor Redis maakt.

U moet ook voldoende IP-adressen beschikbaar hebben in het subnet.

Wat zijn de adresruimtevereisten voor het subnet?

Azure reserveert een aantal IP-adressen binnen elk subnet en deze adressen kunnen niet worden gebruikt. Het eerste en het laatste IP-adres van de subnetten worden gereserveerd voor protocolconformiteit en dan zijn er nog drie adressen voor Azure-services. Raadpleeg Zijn er beperkingen voor het gebruik van IP-adressen in deze subnetten? voor meer informatie.

Naast de IP-adressen die worden gebruikt door de infrastructuur van het virtuele Azure-netwerk, gebruikt elke Instantie van Azure Cache voor Redis in het subnet twee IP-adressen per cluster-shard, plus IP-adressen voor meer replica's, indien van toepassing. Er wordt nog een IP-adres gebruikt voor de load balancer. Een niet-geclusterde cache wordt beschouwd als één shard.

Kan ik verbinding maken met mijn cache vanuit een virtueel peernetwerk?

Als de virtuele netwerken zich in dezelfde regio bevinden, kunt u deze verbinden met behulp van peering van virtuele netwerken of een VNET-naar-VNET-verbinding voor VPN Gateway.

Als de gekoppelde virtuele Azure-netwerken zich in verschillende regio's bevinden: een client-VM in regio 1 heeft geen toegang tot de cache in regio 2 via het IP-adres met gelijke taakverdeling vanwege een beperking met eenvoudige load balancers. Dat wil gezegd, tenzij het een cache is met een standaard load balancer, wat momenteel alleen een cache is die is gemaakt met beschikbaarheidszones.

Zie Virtual Network - Peering - Vereisten en beperkingen voor meer informatie over peeringbeperkingen voor virtuele netwerken. Een oplossing is het gebruik van een VPN Gateway-VNET-naar-VNET-verbinding in plaats van peering van virtuele netwerken.

Werken alle cachefuncties wanneer een cache wordt gehost in een virtueel netwerk?

Wanneer uw cache deel uitmaakt van een virtueel netwerk, hebben alleen clients in het virtuele netwerk toegang tot de cache. Als gevolg hiervan werken de volgende cachebeheerfuncties op dit moment niet:

  • Redis Console: Omdat Redis-console wordt uitgevoerd in uw lokale browser---usually op een ontwikkelcomputer die niet is verbonden met het virtuele netwerk---it kan vervolgens geen verbinding maken met uw cache.

Wordt VNet-injectie ondersteund in een cache waarvoor Azure Lighthouse is ingeschakeld?

Nee, als voor uw abonnement Azure Lighthouse is ingeschakeld, kunt u VNet-injectie niet gebruiken op een Azure Cache voor Redis exemplaar. Gebruik in plaats daarvan privékoppelingen.

ExpressRoute gebruiken met Azure Cache voor Redis

Klanten kunnen een Azure ExpressRoute-circuit verbinden met hun virtuele netwerkinfrastructuur. Op deze manier breiden ze hun on-premises netwerk uit naar Azure.

Een nieuw expressRoute-circuit maakt standaard geen gebruik van geforceerde tunneling (aankondiging van een standaardroute, 0.0.0.0/0) in een virtueel netwerk. Hierdoor is uitgaande internetverbinding rechtstreeks vanuit het virtuele netwerk toegestaan. Clienttoepassingen kunnen verbinding maken met andere Azure-eindpunten, waaronder een Azure Cache voor Redis-exemplaar.

Een algemene klantconfiguratie is het gebruik van geforceerde tunneling (adverteren van een standaardroute), waardoor uitgaand internetverkeer wordt gedwongen om on-premises te stromen. Deze verkeersstroom breekt de connectiviteit met Azure Cache voor Redis als het uitgaande verkeer vervolgens on-premises wordt geblokkeerd, zodat het Azure Cache voor Redis exemplaar niet kan communiceren met de afhankelijkheden.

De oplossing is het definiëren van een of meer door de gebruiker gedefinieerde routes (UDR's) in het subnet dat het Azure Cache voor Redis-exemplaar bevat. Een UDR definieert subnetspecifieke routes die worden gehonoreerd in plaats van de standaardroute.

Gebruik indien mogelijk de volgende configuratie:

  • De ExpressRoute-configuratie adverteert 0.0.0.0/0 en forceert standaard al het uitgaande verkeer on-premises.
  • De UDR die is toegepast op het subnet dat het Azure Cache voor Redis-exemplaar bevat, definieert 0.0.0.0/0 met een werkroute voor TCP/IP-verkeer naar het openbare internet. Het volgende hoptype wordt bijvoorbeeld ingesteld op internet.

Het gecombineerde effect van deze stappen is dat de UDR op subnetniveau voorrang heeft op de geforceerde ExpressRoute-tunneling en dat zorgt voor uitgaande internettoegang vanaf het Azure Cache voor Redis exemplaar.

Het maken van verbinding met een Azure Cache voor Redis exemplaar vanuit een on-premises toepassing met behulp van ExpressRoute is vanwege prestatieredenen geen typisch gebruiksscenario. Voor de beste prestaties moeten Azure Cache voor Redis clients zich in dezelfde regio bevinden als het Azure Cache voor Redis-exemplaar.

Belangrijk

De routes die in een UDR zijn gedefinieerd, moeten specifiek genoeg zijn om voorrang te krijgen op alle routes die worden aangekondigd door de ExpressRoute-configuratie. In het volgende voorbeeld wordt gebruikgemaakt van het brede adresbereik 0.0.0.0/0 en kan mogelijk per ongeluk worden overschreven door routeadvertenties die meer specifieke adresbereiken gebruiken.

Waarschuwing

Azure Cache voor Redis wordt niet ondersteund met ExpressRoute-configuraties die onjuist routes van het Microsoft-peeringpad naar het privépeeringspad adverteren. ExpressRoute-configuraties waarvoor Microsoft-peering is geconfigureerd, ontvangen routeadvertenties van Microsoft voor een grote set IP-adresbereiken van Microsoft Azure. Als deze adresbereiken onjuist worden geadverteerd op het privé-peeringpad, is het resultaat dat alle uitgaande netwerkpakketten van het subnet van het Azure Cache voor Redis exemplaar onjuist geforceerd worden geforceerd naar de on-premises netwerkinfrastructuur van een klant. Deze netwerkstroom breekt Azure Cache voor Redis. De oplossing voor dit probleem is het stoppen van cross-advertising routes van het Microsoft-peeringpad naar het privépeeringspad.

Achtergrondinformatie over UDR's is beschikbaar in routering van virtueel netwerkverkeer.

Zie het technische overzicht van ExpressRoute voor meer informatie over ExpressRoute.

Gerelateerde inhoud

Meer informatie over Azure Cache voor Redis functies.