This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 7.000000000000001%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMK%3C/text%3E%3C/svg%3E)
I am referring to the diagram attached (which is taken from Azure doc - route through an NVA)
Here is my understanding of the routing :
The 10.20.0.0/24 VNET is going to propagate the route to HUB default route table. This route will have a longer prefix that the static route added on the eastusconn. So when a VM in VNET1 tries to connect to green VM (10.2.0.16), shouldn't HUB1 bypass the static route - because in routing preference, longer prefix always win.
So what is the use of the setting "bypass next hop ip" - I am not sure I understand
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(54.400000000000006, 71%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGP%3C/text%3E%3C/svg%3E)
Greetings!
Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.
Yes, you are correct that the longer prefix always prevails.
According to the diagram,
If Vnet1 (10.1.0.0/24) wants to communicate with Vnet2 (10.2.0.0/24), they will directly communicate with each other as both are directly connected to VHUB.
However, if Vnet1 needs to communicate with Vnet5 (10.2.1.0/24) and Vnet6 (10.2.2.0/24), these two Vnet ranges are unknown to Vnet1 due to the lack of direct communication.
In such cases, it will utilize the default route table configured for the destination (10.2.0.0/16). Since the ranges of Vnet5 and Vnet6 fall within this route table range, it will use the NVA to reach the destinations.
Hope this clarifies!
If above is unclear and/or you are unsure about something add a comment below.
Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Regards,
Ganesh
@Anonymous
I understand VNET1 will use the NVA to communicate with VNET5 & 6. That is perfectly understood.
However the question is :
VNET1 --> VNET2.
The bypass next hop setting - would allow VNET1 to access VNET2 bypassing the NVA.
However that is how it should be working even without this setting, because as you just said longer prefix wins.
So what is the point of having this setting if even without this setting that is how it behaves?
I hope you understand my question -
@Anonymous
VNET1--> VNET5/6 it is well understood that the traffic will go through NVA.
However the question is : VNET1->VNET2, as you described as well as my understanding the traffic will not go through NVA (because of longer prefix prevails).
So if this is the case, then what purpose is bypass next hop IP is serving ?
With or without that setting, VNET1 --> VNET2 traffic is not going through next hop NVA.
This is my question and hope you understand my ask
VNET1 to VNET5/6 it is well understood that the traffic will go through NVA. However the question is : VNET1 to VNET2, as you described as well as my understanding the traffic will not go through NVA (because of longer prefix prevails). So if this is the case, then what purpose is bypass next hop IP is serving ? With or without that setting, VNET1 --> VNET2 traffic is not going through next hop NVA. This is my question and hope you understand my ask
Hello Martin Kallukalam
We appreciate your Patience!
NOTE: The bypass next hop setting allows you to explicitly define which traffic should bypass the NVA. This is important in some scenarios where you want to ensure that certain traffic flows directly between VNets without being processed by the NVA, regardless of any UDRs that might exist.
Hope this clarifies!
If above is unclear and/or you are unsure about something add a comment below.
Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Regards,
Ganesh
Hello Martin Kallukalam
We appreciate your Patience!
I hope this has been helpful!
Your feedback is important so please take a moment to accept answers. If you still have questions, please let us know what is needed in the comments so the question can be answered. Thank you for helping to improve Microsoft Q&A!
If you are still facing any further issues, please don't hesitate to reach out to us.
We are happy to assist you.
Looking forward to your response and appreciate your time on this.
Regards,
Ganesh
Hello Martin Kallukalam
We appreciate your Patience!
I hope this has been helpful!
Your feedback is important so please take a moment to accept answers. If you still have questions, please let us know what is needed in the comments so the question can be answered. Thank you for helping to improve Microsoft Q&A!
If you are still facing any further issues, please don't hesitate to reach out to us.
We are happy to assist you.
Looking forward to your response and appreciate your time on this.
Regards,
Ganesh
@Anonymous
On your comment "The bypass next hop setting allows you to explicitly define which traffic should bypass the NVA"
I understand what the setting is meant to do. However as I was pointing out earlier, the NVA VNET publishes a larger specific cidr into the hub. So I cant really think of any scenario where the traffic to NVA subnet would go through NVA. Would you be able to describe either via a diagram or just describe an example where this setting would be actually come into play?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(134.4, 59%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECM%3C/text%3E%3C/svg%3E)
Thank you for reaching out.
I went through the discussion above. I understand you wish to know what is the use of bypass next hop ip setting when there is already a propagated more specific route to the vnet containing the NVA. As this specific route will be chosen anyway and the default route will not be applied regardless of the bypass next hop setting value.
Based on my understanding above.
In the initial days of Azure WAN, the option to bypass next hop ip was not present and all the traffic was forced through NVA by default. Later this feature was released, and it was implemented as toggle so that customer choose the option based on their requirement.
To describe a scenario here on why this setting can be used is. Suppose in the vnet containing NVA (VNET 2) has a subnet containing multiple Jump servers and there is no need to send private traffic intended towards this server IPs via NVA . Then instead adding /32 static routes for so many jump server IP's you toggle the bypass next hop ip setting to true so that default NVA route is not picked (This scenario is described in the tutorial here). This setting can also be used if there is an Internal Load Balancer deployed before the NVA.
Now I understand your question about the more specific route present for the VNET.
Can you please let us know if you have configure BGP peering for the Vnet connection here?
When you have enabled BGP peering for the Vnet connection here and one of the considerations in this case is as below
Traffic destined for addresses in the virtual network directly connected to the virtual hub can't be configured to route through the NVA using BGP peering between the hub and NVA. This is because the virtual hub automatically learns about system routes associated with addresses in the spoke virtual network when the spoke virtual network connection is created. These automatically learned system routes are preferred over routes learned by the hub through BGP.
If you are using static routes, the you can go through this documentation here for adding more specific routes in connection route tables.
Thank you!
Chaitanya
@ChaitanyaNaykodi-MSFT
Here is my lab setup - pls see attached diagram
I have a static route on spoke2conn as below
NVA is a Linux machine with ip forwarding enabled to server as a router.
With this static route, VM1 can ping NVA , VM2, VM3, VM4. So far so good. Everything working as expected.
I turn off NVA and that stops VM1 --> VM2 ping.
I understand "bypass next hop" setting will resolve this as well as adding a static route which says 10.2.0.4/32 next hop 10.2.0.4.
I fully understand this is the resolution for bypassing NVA.
But my question is really this:
When I look at the hub1 route table (below)
I see destination route to 10.2.0.0/24 which uses spoke2connection and destination route to 10.2.0.16 which will use the NVA as next hop.
When VM1 ping VM2 (10.2.0.4) the route that should take precedence is the route with longest prefix ie 10.2.0.0/24 which is spoke2conn without NVA.
So my Q is : - why is this not the case ?
If longest prefix is the preferred route, then VM1 ->VM2 should have bypassed NVA without needing the "bypass next hop setting". So I am trying to understand what is the thing with vwan hub where it doesnt honor the longest prefix route preference in this specific scenario
@ChaitanyaNaykodi-MSFT Here is my lab setup - pls see attached diagram I have a static route on spoke2conn as below NVA is a Linux machine with ip forwarding enabled to serve as a router. With this static route, VM1 can ping NVA , VM2, VM3, VM4. So far so good. Everything working as expected. I turn off NVA and that stops VM1 --> VM2 ping. I understand "bypass next hop" setting will resolve this as well as adding a static route which says 10.2.0.4/32 next hop 10.2.0.4. I fully understand this is the resolution for bypassing NVA. But my question is really this: When I look at the hub1 route table (below) I see destination route to 10.2.0.0/24 which uses spoke2connection and destination route to 10.2.0.16 which will use the NVA as next hop. When VM1 ping VM2 (10.2.0.4) the route that should take precedence is the route with longest prefix ie 10.2.0.0/24 which is spoke2conn without NVA. So my Q is : - why is this not the case ?
If longest prefix is the preferred route, then VM1 ->VM2 should have bypassed NVA without needing the "bypass next hop setting". So I am trying to understand what is the thing with vwan hub where it doesnt honor the longest prefix route preference in this specific scenario
Thank you for getting back and sharing additional information here.
Thank you!
Chaitanya
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(35.2, 57.00000000000001%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDV%3C/text%3E%3C/svg%3E)
It is not for every design/scenario, Please take a look at https://www.georgeollis.com/azure-virtual-wan-understanding-bypass-next-hop-ip-for-workloads-within-this-vnet/ for an example.
I will read through the scenario you describe and will post if I have any questions.
Thank you for the quick response.
@Didier Van Hoye
Okay so I did read in the full the article you posted. The scenario is the same as the diagram I posted .
The article you posted, says it is how it works (ie the traffic to a VM inside the same spoke vnet would pass through the firewall/NVA without explaining why )
My question is really trying to understand the behavior - why?
Because the propogate route should and would be publishing a longer prefix route into hub routing table which should have higher priority than static route.
Can you shed light on why this is not the case ?