You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/network-watcher/view-relative-latencies.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: View relative latencies to Azure regions from specific locations | Microsoft Docs
2
+
title: View relative latencies to Azure regions from specific locations
3
3
description: Learn how to view relative latencies across Internet providers to Azure regions from specific locations.
4
4
services: network-watcher
5
5
documentationcenter: ''
@@ -20,7 +20,7 @@ ms.custom:
20
20
> [!WARNING]
21
21
> This feature is currently in preview and still being tested for stability.
22
22
23
-
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.
23
+
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.
## Compare relative network latencies to a single Azure region from a specific location
43
43
44
-
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:
44
+
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:
Copy file name to clipboardExpand all lines: articles/networking/connectivty-interoperability-configuration.md
+91-91Lines changed: 91 additions & 91 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: 'Interoperability in Azure back-end connectivity features: Configuration details | Microsoft Docs'
2
+
title: 'Interoperability in Azure: Configuration details'
3
3
description: This article describes configuration details for the test setup you can use to analyze interoperability between ExpressRoute, a site-to-site VPN, and virtual network peering in Azure.
4
4
documentationcenter: na
5
5
services: networking
@@ -14,7 +14,7 @@ ms.author: rambala
14
14
15
15
---
16
16
17
-
# Interoperability in Azure back-end connectivity features: Test configuration details
17
+
# Interoperability in Azure: Test configuration details
18
18
19
19
This article describes the configuration details of the [test setup][Setup]. The test setup helps you analyze how Azure networking services interoperate at the control plane level and data plane level.
20
20
@@ -50,100 +50,100 @@ The following figure shows the connection configuration between the ExpressRoute
50
50
51
51
The following list shows the primary CE router configuration for ExpressRoute private peering connectivity. (Cisco ASR1000 routers are used as CE routers in the test setup.) When site-to-site VPN and ExpressRoute circuits are configured in parallel to connect an on-premises network to Azure, Azure prioritizes the ExpressRoute circuit by default. To avoid asymmetrical routing, the on-premises network also should prioritize ExpressRoute connectivity over site-to-site VPN connectivity. The following configuration establishes prioritization by using the BGP **local-preference** attribute:
Copy file name to clipboardExpand all lines: articles/networking/connectivty-interoperability-control-plane.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: 'Interoperability in Azure back-end connectivity features: Control plane analysis | Microsoft Docs'
2
+
title: 'Interoperability in Azure : Control plane analysis'
3
3
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.
4
4
documentationcenter: na
5
5
services: networking
@@ -14,7 +14,7 @@ ms.author: rambala
14
14
15
15
---
16
16
17
-
# Interoperability in Azure back-end connectivity features: Control plane analysis
17
+
# Interoperability in Azure : Control plane analysis
18
18
19
19
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.
20
20
@@ -26,7 +26,7 @@ The following figure illustrates the network from the perspective of a hub virtu
26
26
27
27
![1][1]
28
28
29
-
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.
29
+
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.
30
30
31
31
The following figure shows a sample ExpressRoute route table:
32
32
@@ -42,7 +42,7 @@ Both on-premises Location 1 and the remote VNet are connected to the hub VNet vi
42
42
43
43
## On-premises Location 1 and the branch VNet perspective via a site-to-site VPN
44
44
45
-
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:
45
+
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:
0 commit comments