Azure-docs: Traffic between 2 spokes when Peering is turned on

[DMoonesinghe]

A peering is established between two virtual networks. Peerings are not transitive. If you create peerings between:

VirtualNetwork1 & VirtualNetwork2
VirtualNetwork2 & VirtualNetwork3
In this document you say
"There is no peering between VirtualNetwork1 and VirtualNetwork3 through VirtualNetwork2. If you want to create a virtual network peering between VirtualNetwork1 and VirtualNetwork3, you have to create a peering between VirtualNetwork1 and VirtualNetwork3."

Yet under Allow Forward Traffic
You say "For example, consider three virtual networks named Spoke1, Spoke2, and Hub. A peering exists between each spoke virtual network and the Hub virtual network, but peerings don't exist between the spoke virtual networks. A network virtual appliance is deployed in the Hub virtual network, and user-defined routes are applied to each spoke virtual network that route traffic between the subnets through the network virtual appliance. If this checkbox is not checked for the peering between each spoke virtual network and the hub virtual network, traffic doesn't flow between the spoke virtual networks because the hub is not forwarding the traffic between the virtual networks "

Isn't that a contradiction between my quotation 1 & quotation 2?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4e439c62-035c-47f0-a03d-c70e66f2887b
• Version Independent ID: d745a499-f6bf-ca46-f378-c64535df626f
• Content: Create, change, or delete an Azure virtual network peering
• Content Source: articles/virtual-network/virtual-network-manage-peering.md
• Service: virtual-network
• GitHub Login: @jimdial
• Microsoft Alias: anavin

[KetanChawda-MSFT]

@DMoonesinghe Thank you for your feedback! We will review and provide an update as appropriate.

[SubhashVasarapu-MSFT]

@DMoonesinghe , VNet peering is a non-transitive relationship between two VNets. If you require spokes to connect to each other, consider adding a separate peering connection between those spokes.
However, if you have several spokes that need to connect with each other, you will run out of possible peering connections very quickly due to the limitation on number of VNets peerings per VNet. In this scenario, consider using user defined routes (UDRs) to force traffic destined to a spoke to be sent to an NVA acting as a router at the hub VNet. This will allow the spokes to connect to each other.

[DMoonesinghe]

Subash!

I know you are copying word for word from the document to answer me. But
what you copied is exactly where little bit more clarification is needed.
[image: image.png]
If Hub VNet is the only one that has peerings to Spoke1 and Spoke2. If
there isn't a NVA on the Spoke then it is correct to say, that in that
configuration there is no transitive path for traffic from Spoke 1 to Spoke

1. But I see people who are only exposed to the cloud may think so.

But the moment you put NVA on the Spoke and you put UDRs on each spoke
pointing to the other spoke and saying go through the NVA. Hub becomes a
transitive network. At that point hub is allowing traffic from spoke 1
or 2 to transit through it.

Therefore it is not accurate to say VNet peering is non-transitive. Or to
assert that " If you require spokes to connect to each other, consider
adding a separate peering connection between those spokes." Yes it is not
transitive in its native mode. But all you need is a NVA and 2 UDR's.
Then it becomes transitive.

I think that is a important point to emphasis. You may think I am quibbling
about semantics. But semantics is important. We reading these technical
docs for their meaning. Majority of us are moving from traditional
networking to the cloud. To us all networks can be made transitive, simply
add a few networking components like routers and routes.

It is point few of my fellow network engineer's were confused about. As to
why you say it is not transitive. In most complex network design's you end
up with a NVA on the hub. Then all it takes is UDR's on both ends.

So hopefully you see the importance for need for more clarity from the
readers perspective.

-Deepal

On Tue, Apr 16, 2019 at 4:41 PM SubhashVasarapu-MSFT <
[email protected]> wrote:

@DMoonesinghe https://github.com/DMoonesinghe , VNet peering is a
non-transitive relationship between two VNets. If you require spokes to
connect to each other, consider adding a separate peering connection
between those spokes.
However, if you have several spokes that need to connect with each other,
you will run out of possible peering connections very quickly due to the
limitation on number of VNets peerings per VNet
https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits#networking-limits.
In this scenario, consider using user defined routes (UDRs) to force
traffic destined to a spoke to be sent to an NVA acting as a router at the
hub VNet. This will allow the spokes to connect to each other.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/29195#issuecomment-483834806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlFSphtY8JPy7VNklGYy3svMyKQURHEeks5vhjVmgaJpZM4coijv
.

--
Deepal Moonesinghe
[phone]
deepal.[email protected]

"We must accept finite disappointment, but we must never lose infinite
hope."
~ Martin Luther King, Jr. ~

[mundayn]

This page has a bit more information, and has a lab which I'm just running through now to understand this further: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke#deploy-the-solution

[SubhashVasarapu-MSFT]

@DMoonesinghe , Agreeing with all your valuable points mentioned above and adding a simple note here for making this context much simpler for better understanding and to avoid further confusions. We will also assign this issue to author for making changes to the document accordingly to make it a reader friendly document.
Coming to the context, VNet peering is Non-Transitive. In order to implement spoke to spoke communication, there are ways to achieve this,

1.Exclusively allowing peering between spokes:

We can allow peering between spokes. However, if you have several spokes that need to connect with each other, you will run out of possible peering connections very quickly due to the limitation on number of VNets peerings per VNet.

2.Placing a virtual appliance in the hub and direct traffic using UDR’s:

We can create connectivity between spokes by placing NVA in the hub and directing traffic to respective spokes using UDR’s. This kind of architecture helps you to segregate/separating the workloads/infrastructure accordingly between teams and even provides better management during the access of resources/resource groups by using RBAC .
Assigning this issue to @anavinahar for visibility and document enhancement considerations.

[anavinahar]

@DMoonesinghe the scenario with NVA forwarding the traffic via a UDR doesn't make it transitive as the two spokes cannot directly communicate with each other w/o going through the NVA in the hub.

[DMoonesinghe]

Anavi I understand your point. But I was pointing out that it would be
much more clear if you explicitly state that:

"When peering in a hub and spoke topology traffic is Non-Transitive between
spokes in it's native mode (without a NVA in the hub). Yet the traffic
between spokes can be made transitive through the hub by adding a NVA
into the hub network."

On Mon, Apr 29, 2019 at 7:44 PM Anavi N [e-mail] wrote:

@DMoonesinghe https://github.com/DMoonesinghe the scenario with NVA
forwarding the traffic via a UDR doesn't make it transitive as the two
spokes cannot directly communicate with each other w/o going through the
NVA in the hub.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/29195#issuecomment-487781061,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJIVFJXJVPIU3CRQSJ6UXR3PS6B5BANCNFSM4HFCFDXQ
.

--
Deepal Moonesinghe
[phone]
deepal.[email protected]

"We must accept finite disappointment, but we must never lose infinite
hope."
~ Martin Luther King, Jr. ~

[x3nc0n]

I agree this needs to be made clearer in the article. Also, the limit of peerings per Vnet is 500. The way it is called out, I would have thought that number to be much lower and a harder constraint.

https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits#azure-resource-manager-virtual-networking-limits

[atambawala]

@DMoonesinghe , thanks for the feedback. I have incorporated it for the next revision of the doc.

[allegradomel]

Thanks @atambawala! I am closing this issue now since the change has been made #please-close