Merge pull request #109770 from KumudD/march31updates

Metadata update

Author: GitHubber17

articles/network-watcher/view-relative-latencies.md

@@ -1,5 +1,5 @@
 ---
-title: View relative latencies to Azure regions from specific locations | Microsoft Docs
+title: View relative latencies to Azure regions from specific locations
 description: Learn how to view relative latencies across Internet providers to Azure regions from specific locations.
 services: network-watcher
 documentationcenter: ''
@@ -20,7 +20,7 @@ ms.custom:
 > [!WARNING]
 > This feature is currently in preview and still being tested for stability.
 
-In this tutorial, learn how to use the Azure [Network Watcher](network-watcher-monitoring-overview.md) service to help you decide what Azure region to deploy your application or service in, based on your user demographic. Additionally, you can use it to help evaluate service providers’ connections to Azure.  
+In this tutorial, learn how to use the Azure [Network Watcher](network-watcher-monitoring-overview.md) service to help you decide what Azure region to deploy your application or service in, based on your user demographic. Additionally, you can use it to help evaluate service providers' connections to Azure.  
 
 
 [!INCLUDE [updated-for-az](../../includes/updated-for-az.md)]
@@ -41,7 +41,7 @@ New-AzNetworkWatcher -Name NetworkWatcher_eastus -ResourceGroupName NetworkWatch
 
 ## Compare relative network latencies to a single Azure region from a specific location
 
-Evaluate service providers, or troubleshoot a user reporting an issue such as “the site was slow,” from a specific location to the azure region where a service is deployed. For example, the following command returns the average relative Internet service provider latencies between the state of Washington in the United States and the West US 2 Azure region between December 13-15, 2017:
+Evaluate service providers, or troubleshoot a user reporting an issue such as "the site was slow," from a specific location to the azure region where a service is deployed. For example, the following command returns the average relative Internet service provider latencies between the state of Washington in the United States and the West US 2 Azure region between December 13-15, 2017:
 
 ```powershell
 Get-AzNetworkWatcherReachabilityReport `

articles/networking/connectivty-interoperability-control-plane.md

@@ -1,5 +1,5 @@
 ---
-title: 'Interoperability in Azure back-end connectivity features: Control plane analysis | Microsoft Docs'
+title: 'Interoperability in Azure : Control plane analysis'
 description: This article provides the control plane analysis of the test setup you can use to analyze interoperability between ExpressRoute, a site-to-site VPN, and virtual network peering in Azure.
 documentationcenter: na
 services: networking
@@ -14,7 +14,7 @@ ms.author: rambala
 
 ---
 
-# Interoperability in Azure back-end connectivity features: Control plane analysis
+# Interoperability in Azure : Control plane analysis
 
 This article describes the control plane analysis of the [test setup][Setup]. You can also review the [test setup configuration][Configuration] and the [data plane analysis][Data-Analysis] of the test setup.
 
@@ -26,7 +26,7 @@ The following figure illustrates the network from the perspective of a hub virtu
 
 ![1][1]
 
-The ASN of the VNet's Azure ExpressRoute gateway is different from the ASN of Microsoft Enterprise Edge Routers (MSEEs). An ExpressRoute gateway uses a private ASN (a value of **65515**) and MSEEs use public ASN (a value of **12076**) globally. When you configure ExpressRoute peering, because MSEE is the peer, you use **12076** as the peer ASN. On the Azure side, MSEE establishes eBGP peering with the ExpressRoute gateway. The dual eBGP peering that the MSEE establishes for each ExpressRoute peering is transparent at the control plane level. Therefore, when you view an ExpressRoute route table, you see the VNet’s ExpressRoute gateway ASN for the VNet’s prefixes. 
+The ASN of the VNet's Azure ExpressRoute gateway is different from the ASN of Microsoft Enterprise Edge Routers (MSEEs). An ExpressRoute gateway uses a private ASN (a value of **65515**) and MSEEs use public ASN (a value of **12076**) globally. When you configure ExpressRoute peering, because MSEE is the peer, you use **12076** as the peer ASN. On the Azure side, MSEE establishes eBGP peering with the ExpressRoute gateway. The dual eBGP peering that the MSEE establishes for each ExpressRoute peering is transparent at the control plane level. Therefore, when you view an ExpressRoute route table, you see the VNet's ExpressRoute gateway ASN for the VNet's prefixes. 
 
 The following figure shows a sample ExpressRoute route table: 
 
@@ -42,7 +42,7 @@ Both on-premises Location 1 and the remote VNet are connected to the hub VNet vi
 
 ## On-premises Location 1 and the branch VNet perspective via a site-to-site VPN
 
-Both on-premises Location 1 and the branch VNet are connected to a hub VNet’s VPN gateway via a site-to-site VPN connection. They share the same perspective of the topology, as shown in the following diagram:
+Both on-premises Location 1 and the branch VNet are connected to a hub VNet's VPN gateway via a site-to-site VPN connection. They share the same perspective of the topology, as shown in the following diagram:
 
 ![3][3]