SD-WAN

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?

 

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?

 

I raised a similar question about two years ago regarding tunnel orchestration in SD-Branch environments.

[SD-BRANCH] Tunnel orchestration issue | SD-WAN

At the time, the only workaround was to rename the WAN uplink on the branch side so that OTO could correctly set affinity with the online WAN from the VPNC. I also had a chance to discuss this with one of the gateway PMs, who confirmed that the software didn't support this functionality back then.

However, I recently noticed that VPNCs now support WAN health checks. Given this update, I'm wondering if it's now possible to automatically disable downed uplinks-even when they're behind NAT.

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?

 

Multiple active uplinks on a VPNC is supported since 10.3.1.0 software release. It's only validated with hardware VPNC's. Please check also the documentation.

It's important to have a dedicated VLAN per uplink. Two uplinks means 2 VLANs on the VPNC (each with it's own default gateway). On the firewall you need to built two NAT policies. The orchestrator should push the second tunnel to the branch gateways. Important is to used different tags / names for each uplink. 

@Vairo, I believe your scenario should be possible when using multiple uplinks on the VPNCs

I raised a similar question about two years ago regarding tunnel orchestration in SD-Branch environments.

[SD-BRANCH] Tunnel orchestration issue | SD-WAN

At the time, the only workaround was to rename the WAN uplink on the branch side so that OTO could correctly set affinity with the online WAN from the VPNC. I also had a chance to discuss this with one of the gateway PMs, who confirmed that the software didn't support this functionality back then.

However, I recently noticed that VPNCs now support WAN health checks. Given this update, I'm wondering if it's now possible to automatically disable downed uplinks-even when they're behind NAT.

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?

 

Thanks for the responses.

We have a dedicated VLAN per uplink. So we do use two different NAT policies, apologies if it wasn't clear on the schematic.

Documentation:
Currently, OTO supports only one tunnel per uplink interface on the Branch Gateway irrespective of the number of INET interfaces available on the VPNC. For example, when a VPNC has 1 INET interface (inet1) and a Branch Gateway has 2 uplinks (link1 and link2), tunnels are established such that Branch Gateway uplinks link1 and link2 have 1 tunnel each to VPNC inet1. When you add a second INET interface (inet2) on VPNC, the existing link2 tunnel on the Branch Gateway to INET1 of VPNC is cleared and a new tunnel is established with VPNC inet2.

What I gather from this is that if we wouldn't use a LTE backup link, but only the primary ISP at the branches the branches would still have two tunnels. Both originating from the same inet on the branch side but to both uplinks on the VPNC. So the OTO doesn't take in account uplinks selected as backup. It still regards these as active towards the tunnel orchestration. 

Also in the documentation:

• VPNC WAN uplink health check is not considered in any decision making process, such as, traffic flow path selection.
• You cannot configure multiple WAN uplinks for VGWs and non-orchestrated tunnels.

So if we experience a INET issue at the VPNC side the WAN uplink health check does not influence the OTO. Our VPNC is a VGW, multiple WAN uplinks aren't even supported in this case? I don't immediately see why it being a VM or a hardware appliance would have any influence on this.

Further in the documententation:

• Tunnel negotiation is triggered for all tunnels when WAN configuration is added or deleted.
• Tunnel renegotiation is not triggered when a WAN uplink is down, or when a tunnel is down.

We have about a 30 branches and at any given time there's always at least one that is operating on LTE, so renaming the WAN uplink item on the VPNC side will not work either.

So I recon we have two options left:

• We rename the Active Uplink on each of the branches to match the OK ISP at VPNC side, but if a branch then encounters a failover to the LTE backup that tunnel won't come up either.
• We remove the WAN uplink object from the configuration in the VPNC and add it again when connectivity has been restored.

Or is there another option I'm missing?

Multiple active uplinks on a VPNC is supported since 10.3.1.0 software release. It's only validated with hardware VPNC's. Please check also the documentation.

It's important to have a dedicated VLAN per uplink. Two uplinks means 2 VLANs on the VPNC (each with it's own default gateway). On the firewall you need to built two NAT policies. The orchestrator should push the second tunnel to the branch gateways. Important is to used different tags / names for each uplink. 

@Vairo, I believe your scenario should be possible when using multiple uplinks on the VPNCs

I raised a similar question about two years ago regarding tunnel orchestration in SD-Branch environments.

[SD-BRANCH] Tunnel orchestration issue | SD-WAN

At the time, the only workaround was to rename the WAN uplink on the branch side so that OTO could correctly set affinity with the online WAN from the VPNC. I also had a chance to discuss this with one of the gateway PMs, who confirmed that the software didn't support this functionality back then.

However, I recently noticed that VPNCs now support WAN health checks. Given this update, I'm wondering if it's now possible to automatically disable downed uplinks-even when they're behind NAT.

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?

 

Bruno,

You summary is correct I think. (also to discuss this during a call with your Aruba SE).

OTO create 1 tunnel per uplink interface. If the VPNC has 2 uplinks there is one tunnel per branch link. I just tested adding a second uplink to my virtual VPNC and it works. I believe it's never QA tested.

OTO tries to make matches based on uplink name. So if your uplink is name ISP1 on both the VPNC and Branch side, OTO will push a tunnel from ISP1 to ISP1. If there is just one ISP at the VPNC side, there will be a tunnel from each branch uplink. However, I see your point on having a redundant ISP at both sides.

Is there an option to have two VPNC's running? Each VPNC can than be attached to a different ISP.

Thanks for the responses.

We have a dedicated VLAN per uplink. So we do use two different NAT policies, apologies if it wasn't clear on the schematic.

Documentation:
Currently, OTO supports only one tunnel per uplink interface on the Branch Gateway irrespective of the number of INET interfaces available on the VPNC. For example, when a VPNC has 1 INET interface (inet1) and a Branch Gateway has 2 uplinks (link1 and link2), tunnels are established such that Branch Gateway uplinks link1 and link2 have 1 tunnel each to VPNC inet1. When you add a second INET interface (inet2) on VPNC, the existing link2 tunnel on the Branch Gateway to INET1 of VPNC is cleared and a new tunnel is established with VPNC inet2.

What I gather from this is that if we wouldn't use a LTE backup link, but only the primary ISP at the branches the branches would still have two tunnels. Both originating from the same inet on the branch side but to both uplinks on the VPNC. So the OTO doesn't take in account uplinks selected as backup. It still regards these as active towards the tunnel orchestration. 

Also in the documentation:

• VPNC WAN uplink health check is not considered in any decision making process, such as, traffic flow path selection.
• You cannot configure multiple WAN uplinks for VGWs and non-orchestrated tunnels.

So if we experience a INET issue at the VPNC side the WAN uplink health check does not influence the OTO. Our VPNC is a VGW, multiple WAN uplinks aren't even supported in this case? I don't immediately see why it being a VM or a hardware appliance would have any influence on this.

Further in the documententation:

• Tunnel negotiation is triggered for all tunnels when WAN configuration is added or deleted.
• Tunnel renegotiation is not triggered when a WAN uplink is down, or when a tunnel is down.

We have about a 30 branches and at any given time there's always at least one that is operating on LTE, so renaming the WAN uplink item on the VPNC side will not work either.

So I recon we have two options left:

• We rename the Active Uplink on each of the branches to match the OK ISP at VPNC side, but if a branch then encounters a failover to the LTE backup that tunnel won't come up either.
• We remove the WAN uplink object from the configuration in the VPNC and add it again when connectivity has been restored.

Or is there another option I'm missing?

Multiple active uplinks on a VPNC is supported since 10.3.1.0 software release. It's only validated with hardware VPNC's. Please check also the documentation.

It's important to have a dedicated VLAN per uplink. Two uplinks means 2 VLANs on the VPNC (each with it's own default gateway). On the firewall you need to built two NAT policies. The orchestrator should push the second tunnel to the branch gateways. Important is to used different tags / names for each uplink. 

@Vairo, I believe your scenario should be possible when using multiple uplinks on the VPNCs

I raised a similar question about two years ago regarding tunnel orchestration in SD-Branch environments.

[SD-BRANCH] Tunnel orchestration issue | SD-WAN

At the time, the only workaround was to rename the WAN uplink on the branch side so that OTO could correctly set affinity with the online WAN from the VPNC. I also had a chance to discuss this with one of the gateway PMs, who confirmed that the software didn't support this functionality back then.

However, I recently noticed that VPNCs now support WAN health checks. Given this update, I'm wondering if it's now possible to automatically disable downed uplinks-even when they're behind NAT.

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?

 

Hi Willem,

Then I would need to get another VPNC license, but it seems to be a good work around on the current issue.

Thank you for testing and replying, I will see what's possible.

Bruno,

You summary is correct I think. (also to discuss this during a call with your Aruba SE).

OTO create 1 tunnel per uplink interface. If the VPNC has 2 uplinks there is one tunnel per branch link. I just tested adding a second uplink to my virtual VPNC and it works. I believe it's never QA tested.

OTO tries to make matches based on uplink name. So if your uplink is name ISP1 on both the VPNC and Branch side, OTO will push a tunnel from ISP1 to ISP1. If there is just one ISP at the VPNC side, there will be a tunnel from each branch uplink. However, I see your point on having a redundant ISP at both sides.

Is there an option to have two VPNC's running? Each VPNC can than be attached to a different ISP.

Thanks for the responses.

We have a dedicated VLAN per uplink. So we do use two different NAT policies, apologies if it wasn't clear on the schematic.

Documentation:
Currently, OTO supports only one tunnel per uplink interface on the Branch Gateway irrespective of the number of INET interfaces available on the VPNC. For example, when a VPNC has 1 INET interface (inet1) and a Branch Gateway has 2 uplinks (link1 and link2), tunnels are established such that Branch Gateway uplinks link1 and link2 have 1 tunnel each to VPNC inet1. When you add a second INET interface (inet2) on VPNC, the existing link2 tunnel on the Branch Gateway to INET1 of VPNC is cleared and a new tunnel is established with VPNC inet2.

What I gather from this is that if we wouldn't use a LTE backup link, but only the primary ISP at the branches the branches would still have two tunnels. Both originating from the same inet on the branch side but to both uplinks on the VPNC. So the OTO doesn't take in account uplinks selected as backup. It still regards these as active towards the tunnel orchestration. 

Also in the documentation:

• VPNC WAN uplink health check is not considered in any decision making process, such as, traffic flow path selection.
• You cannot configure multiple WAN uplinks for VGWs and non-orchestrated tunnels.

So if we experience a INET issue at the VPNC side the WAN uplink health check does not influence the OTO. Our VPNC is a VGW, multiple WAN uplinks aren't even supported in this case? I don't immediately see why it being a VM or a hardware appliance would have any influence on this.

Further in the documententation:

• Tunnel negotiation is triggered for all tunnels when WAN configuration is added or deleted.
• Tunnel renegotiation is not triggered when a WAN uplink is down, or when a tunnel is down.

We have about a 30 branches and at any given time there's always at least one that is operating on LTE, so renaming the WAN uplink item on the VPNC side will not work either.

So I recon we have two options left:

• We rename the Active Uplink on each of the branches to match the OK ISP at VPNC side, but if a branch then encounters a failover to the LTE backup that tunnel won't come up either.
• We remove the WAN uplink object from the configuration in the VPNC and add it again when connectivity has been restored.

Or is there another option I'm missing?

Multiple active uplinks on a VPNC is supported since 10.3.1.0 software release. It's only validated with hardware VPNC's. Please check also the documentation.

It's important to have a dedicated VLAN per uplink. Two uplinks means 2 VLANs on the VPNC (each with it's own default gateway). On the firewall you need to built two NAT policies. The orchestrator should push the second tunnel to the branch gateways. Important is to used different tags / names for each uplink. 

@Vairo, I believe your scenario should be possible when using multiple uplinks on the VPNCs

I raised a similar question about two years ago regarding tunnel orchestration in SD-Branch environments.

[SD-BRANCH] Tunnel orchestration issue | SD-WAN

At the time, the only workaround was to rename the WAN uplink on the branch side so that OTO could correctly set affinity with the online WAN from the VPNC. I also had a chance to discuss this with one of the gateway PMs, who confirmed that the software didn't support this functionality back then.

However, I recently noticed that VPNCs now support WAN health checks. Given this update, I'm wondering if it's now possible to automatically disable downed uplinks-even when they're behind NAT.

Hi community,

We are running the following toplogy:

1. 1 VPNC with 2 WAN uplinks, 1:1 Nat behind firewall
2. Branch gateways have 1 WAN and LTE configured as backup
3. Two tunnels get created by orchestration but the second tunnel is only online when the primary ISP on the branch fails.

If on the other hand ISP2 on the VPNC side fails then all branches using the LTE connection will have the same issue. Tunnel goes down.

Is there a way to get the tunnels to reinitiate automatically when one of the ISP's on the VPNC side fail?
Is it possible to get the orchestration to make 4 tunnels instead of 2, like in the example below?