Why does Get-AzNetworkServiceTag not have parity with the weekly JSON file

[lymedo]

Description

The results of Get-AzNetworkServiceTag does not have parity with the weekly JSON file

20.123.128.0/17 is included in the weekly JSON file under AzureCloud and AzureCloud.westeurope, however, the CIDR range is not returns by the Get-AzNetworkServiceTag for the westeurope location.

` Connect-AzAccount

$serviceTags = Get-AzNetworkServiceTag -Location "westeurope"

$azCloudWest = $serviceTags.Values | Where-Object { $_.Name -eq "AzureCloud" } $cidrRangesWest = $azCloudWest.Properties.AddressPrefixes

$rangeToCheck = "20.123.128.0/17"

$cidrRangesWest -Contains $rangeToCheck

Disconnect-AzAccount

Script or Debug output

False

Environment data

No response

Module versions

No response

Error output

No response

[dingmeng-xue]

Thanks for reporting. We believe this inconsistency should be resolve by service side. I reply team member to look into it further.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

Issue Details

---

### Description The results of Get-AzNetworkServiceTag does not have parity with the weekly JSON file 20.123.128.0/17 is included in the weekly JSON file under AzureCloud and AzureCloud.westeurope, however, the CIDR range is not returns by the Get-AzNetworkServiceTag for the westeurope location. ` Connect-AzAccount $serviceTags = Get-AzNetworkServiceTag -Location "westeurope" $azCloudWest = $serviceTags.Values | Where-Object { $_.Name -eq "AzureCloud" } $cidrRangesWest = $azCloudWest.Properties.AddressPrefixes $rangeToCheck = "20.123.128.0/17" $cidrRangesWest -Contains $rangeToCheck Disconnect-AzAccount ### Script or Debug output ```PowerShell False ``` ### Environment data _No response_ ### Module versions _No response_ ### Error output _No response_

Author:	lymedo
Assignees:	SaurabhSharma-MSFT
Labels:	`Network`, `Service Attention`, `question`, `customer-reported`, `CXP Attention`
Milestone:	-

[SaurabhSharma-MSFT]

@aznetsuppgithub Can you please help.

[andreamichaelmsft]

Generally, the JSON and Discovery API are not guaranteed to have immediate parity since they are refreshed at different cadences. In this case, it seems this issue can be closed since the API now has parity (i.e., the range 20.123.128.0/17 is now included in AzureCloud westeurope ranges returned by the API). Waiting for @SaurabhSharma-MSFT to confirm and close!

[lymedo]

The quoted CIDR range was only one example and there are many more.

I don't understand why the Discovery API has a different refresh cadence to the JSON file. The docs suggest that the Discovery API is the solution to provide developers an alternative to downloading a JSON file, therefore it must have parity otherwise the Discovery API is incorrect and cannot be trusted as a valid source of information.

I recommend that this issue is not closed until the refresh cadence is synchronised.

[andreamichaelmsft]

Hi lymedo, apologies for the late response. The reason Discovery API has a different refresh cadence to the JSON file is because the API follows safer deployment procedures, and rolls out through regions one at a time. The JSON has no such procedures or validation, and so is released globally every week. The API and JSON will never be able to have complete parity -- the JSON doesn't check for bogus ranges / tag info, and the API won't always take an exact duration to complete its refresh across regions. I'd like to stress that the API is NOT incorrect -- it can take a week or two longer to expose range info. In terms of trust, because the API does go through multiple checks and safe rollouts, it's a safer and more valid source of info than the JSON.

[lymedo]

@andreamichaelmsft I completely appreciate what you say. My issue is that there is infrastructure in Azure which reports as not trusted by this API - for example Azure DevOps hosted agents. Following strict rules by only allowing trusted agents to interact with our resource, results in our release pipelines failing. In an ideal world the release of new ranges used by these agents should be aligned with this API; vice-versa.

[KenSpur]

Hey, I have also noticed that the Get-AzNetworkServiceTag function does not return the region specific tags for LogicApps

[fozturner]

Hey, I have also noticed that the Get-AzNetworkServiceTag function does not return the region specific tags for LogicApps

LogicApps still do not return region specific tags

[andreamichaelmsft]

I no longer own the service tags area and have forwarded this thread to the new owner to elaborate on why the API doesn't include region-specific tags for LogicApps.

From my POV though: LogicApps is not documented to return region-specific tags (see https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview). In the JSON file, the region-specific ranges are given, but those ranges have an attribute:value where "networkFeatures: null" -- if intended to show up in the DiscoveryAPI, networkFeatures would include a value of "API".