Link Search Menu Expand Document

Overlay Tunnel Orchestrator (OTO)

The Overlay Tunnel Orchestrator (OTO) builds overlay mappings. The OTO discovers the WAN uplinks of the devices and associated attributes to orchestrate the tunnels between points. A tunnel agent registers each uplink and associated attributes with the OTO and gathers all necessary information from the tunnel agent running on every device.

The main functions of the OTO include:

  • Discovering public/private IP addresses and uplink attributes.

  • Exchanging keys and sending keys to devices.

  • Refreshing keying material before the old key expires.

  • Building IPSec tunnels.

To set up OTO, you need to configure uplinks on the VPNC. This allows the tunnel orchestrator to determine the WAN interfaces that will be used to terminate the IPSec tunnels. Similar to the BGW, the VPNC can have multiple WAN uplinks of different types from various service providers. The BGW has either a single uplink or multiple uplinks. Each uplink has a different link type and a label to identify the service provider for it. For more information about BGW, see HPE Aruba Networking SD-Branch Orchestrator.

The following figure illustrates the IPSec mapping that the OTO facilitates between the BGWs, EC gateways, and VPNCs. It shows two VPNCs in each data center with two uplinks at each site. The number of uplinks was selected to help explain the mechanism.

img OTO IPSec Mapping

In the diagram of the Overlay Tunnel Orchestrator, the labels for DC 1 and Branch 1 are ineta_inet (green) and red_mpls (red) with the suffixes of _inet and _mpls. During the deployment and configuration of the VPNCs and branch gateways, HPE Aruba Networking Central adds the suffix of either _inet or _mpls to the end of the WAN uplink name. The tunnels are then mapped according to the label name and suffix name. For example, if the WAN uplink does not match _mpls it then defaults to _inet.

The DC 1 VPNC BGW can match the WAN uplinks to Branch 1. DC 1 can also match WAN uplinks to Branch 2. DC 1 has the ineta_inet label (green) and Branch 2 has the INETA_inet label (purple). Even though Branch 2 has a different label name with capital letters, it still has the matching suffix _inet appended. Anything with the suffix _inet appended will be Internet but can also be Metro and LTE, as it is a bit loose in its selection. Labels with the suffix _mpls appended are solely for MPLS uplinks.

In DC2, the EdgeConnect is configured as a VPNC and has WAN labels ineta_inet (purple) and red_mpls1_mpls (orange). Branch 1 and Branch 2 have WAN uplinks with suffix _inet and _mpls, and can create the following tunnels to DC 2:

  • Branch 1 ineta_inet (green) matches to DC 2 ineta_inet (purple), so Branch 1 builds internet tunnels to DC 2 because they both have labels with the _inet suffix.

  • Branch 1 red_mpls (red) matches to DC 2 red_mpls1_mpls (red), so Branch 1 builds MPLS tunnels to DC 2 because they both have labels with the _mpls suffix.

  • Branch 2 INETA_inet (purple) matches to DC 2 ineta_inet (purple), so Branch 2 builds internet tunnels to DC 2 because they both have labels with the _inet suffix.

NOTE: Each Uplink on SDB/MB builds one tunnel per uplink to the EC Hub based on the closest label match. SDB/MB do not build cross-connect tunnels.

The following example shows when the MPLS WAN uplink does not match the label and a tunnel is not built. The tunnels are not orchestrated by OTO as there is no close string match in the label name.

img MPLS WAN Uplinks Do Not Match

The following example shows when the MPLS WAN uplink matches and a tunnel is built. The label red_mpls matches to the red_green_blue_mpls label because it has both a string match on “red” and the same suffix _mpls.

img MPLS WAN Uplinks Match

The following table describes the suffixes that apply to various circuit types.

Circuit Internet Suffix MPLS Suffix
MPLS N/A _mpls
Internet _inet N/A
Metro _inet N/A
LTE _inet N/A

The OTO uses the uplink configuration elements to select the correct topology mapping. The uplink type (INET/MPLS/Metro/LTE) field must match on both sides of the uplinks. The Internet uplink also matches for Metro and LTE if there is no exact match as they are only available on the branch.

  • MPLS Links

    • The label field must loosely match between VPNCs and BGWs.

    • Tunnels are only created between uplinks that match on both type and label. For label, it only needs to be a loose match.

  • Internet/Metro/LTE Links

    • The label field must match as closely as possible to create a tunnel through the same service provider network.

    • If the label matches, then it selects the corresponding pair of uplinks.

    • If the label does not match, then each WAN uplink on the BGW picks the first available INET uplink on VPNC to form a tunnel.

How SD-Branch and Microbranch Share Interface Details with OTO

The SD-Branch Gateway or Microbranch Access Point is always the tunnel initiator. The SDB or MB uses the STUN protocol to discover its public IP address to establish IPSec connectivity. It is important to know the label names being used for the SD-Branch gateway uplink as well as the Microbranch AP WAN uplink.

  1. In HPE Aruba Networking Central, go to the Branch group and select the SDB gateway.

  2. Navigate to Manage > WAN > Uplink. In the Uplink VLANs table, see the Link column. In the following example, DASLAB-Montpelier-BGW1 is selected and there are two links in the Link column, “red_mpls” and “ineta_inet”.

    img

  1. In HPE Aruba Networking Central, navigate to the Branch group and select the MB gateway.

  2. Navigate to Manage > WAN > WAN Uplink and click Device. In the WAN Uplinks table, see the Uplink column. In the following example, DASLAB-R7-MB1 is selected and there is one link in the Uplink column, “INETA”.

    img

How the EdgeConnect WAN Interface Shares Details with OTO

The WAN interface shares with OTO the WAN labels that are mapped on the Deployment tab in Orchestrator. The label names must have _inet or _mpls suffix attached. Along with labels (uplink names), the WAN IP address is shared with OTO.

The EdgeConnect headend gateway needs to match the uplinks from either the SDB or MB to the WAN labels on the deployment page. To verify or make changes to the labels on the headend gateways, navigate to the Deployment tab in Orchestrator.

  1. In Orchestrator, select the hub in the appliance tree.

  2. Navigate to Configuration > Networking > Deployment. On the Deployment tab, the WAN Labels Used column shows the WAN labels. In the following example, the WAN labels are “INETA_inet” and “inet1_inet”.

    img

  3. If the WAN labels shown in the WAN Labels Used column do not contain the suffixes _inet or _mpls, you need to add new label names that contain those suffixes, and then update the Deployment tab.

  4. Navigate to Configuration > Overlays & Security > Interface Labels.

  5. Click New Label.

  6. Enter a label name that contains the _inet suffix. For example, INETA_inet.

  7. Leave the default selection in the Topology field.

  8. Click Save.

  9. Navigate to Configuration > Networking > Deployment.

  10. Click the edit icon for the hub appliance.

  11. In the Label field, select the new WAN label from the menu, as shown in the following figure.

    img

  12. Click Save.

  13. In Orchestrator, to view the statistics for the OTO tunnels that are orchestrated by HPE Aruba Networking Central, navigate to Configuration > Networking > Tunnels.

  14. Click HPE ANW Central to filter the view, so it shows only OTO tunnels. To view the Link tag, in the Advanced Tunnel Options column click the info icon. Tunnel encryption information is available in HPE Aruba Networking Central.

    img

NAT Setting on EdgeConnect

The EdgeConnect shares the label name and that translates to the uplink name in OTO as well as the WAN IP address. NAT settings for EdgeConnects are configured on the Deployment tab on the Next Hop field. If an EdgeConnect is using NAT settings and it is set to “Not Behind NAT”, the interface IP address is shared with OTO as the WAN IP address. But if the NAT setting is set to “Behind NAT”, then whatever the NAT IP address configured or “Auto Discovered NAT IP” are shared with OTO as the WAN IP address.

img

Data Center (DC) Preference

The HPE Aruba Networking Central SD-WAN Orchestrator technical note specifies that on the BGW, the DC preference should be set to define the VPNCs to which the branch gateways will be connected. The DC preference can only be configured at the group level. The order of the DC preference has an impact on the following:

  • The route costs that the SD-WAN Orchestrator applies to the branch routes installed on the VPNCs in each hub site. The first hub receives a cost of 10 (preferred), while the second hub receives a cost of 20 (least preferred). For additional VPNCs, the cost increases by 10 for each VPNC based on their order.

  • On the BGW, the hub routes to the primary VPNC are installed in the overlay routing table with a cost of 10, and the routes to additional hubs are incremented by 10.

Cloud Survivability

In HPE Aruba Networking Central, there is a unique feature designed to mitigate traffic disruption between HPE Aruba Networking devices. This feature includes two timers for route and tunnel survivability. For example, it addresses what would happen if ORO or OTO gRPC goes down.

Graceful Reset Timer

The graceful reset timer is responsible for maintaining tunnels and route state on the device in the event of a loss of connectivity to the cloud. The timer can be set between 1 hour and 1 week, with a default value of 12 hours. During the establishment of the gRPC connection with ORO, EC is informed of the graceful restart timer value by the ORO if it is configured in HPE Aruba Networking Central. When EC loses the connection to ORO gRPC, the graceful restart timer activates, and the routes remain active in the EC/SDB/MB route table until the timer expires. If the graceful restart timer expires and the gRPC channel is still down, EC marks the routes as “down” until the channel is reestablished. After the gRPC channel is reestablished, the graceful restart timer counter is reset.

The Graceful reset timer value is configured in HPE Aruba Networking Central and its a global setting. To view or modify the settings log in to HPE Aruba Networking Central.

  1. Log in to HPE Aruba Networking Central.

  2. Navigate to Manage > Network Service > SD-WAN Overlay > Global Settings > Config.

  3. Enter a value in seconds for the timer.

    img

Tunnel Rekey Timer

The tunnel rekey timer specifies how often the keys are changed for the IPSec tunnels between the Branch Gateways and VPNCs. The rekey timer value can be set between 60 and 1209600 seconds (maximum 14 days). The default value is set to 86400 seconds (24 hours). For example, if it is enabled and left with the default setting, the first key is triggered at 20 hours after the tunnel is established, and the device sends a rekey request every 24 minutes for 10 times. This setting determines how long the OTO tunnels are available when the OTO gRPC connection fails. When the gRPC connection fails, the tunnel rekey timer kicks in, and the tunnel stays alive until the next rekey occurs. If the gRPC connection fails to come up before the tunnel rekey timer expires, then all the OTO tunnels are marked down until the gRPC connection is reestablished.

To change or view the tunnel rekey timer:

  1. Log in to HPE Aruba Networking Central.

  2. Navigate to Network Services > SD-WAN Overlay, Global Settings > Config.

  3. Enter a value in seconds for the timer.

    img

Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP.

For third-party trademark acknowledgements, go to Trademark Acknowledgements. All third-party marks are property of their respective owners.

To view the end-user software agreement, go to HPE Aruba Networking EULA.

Open Source Code:

This product includes code licensed under certain open source licenses which require source compliance. The corresponding source for these components is available upon request. This offer is valid to anyone in receipt of this information and shall expire three years following the date of the final distribution of this product version by Hewlett Packard Enterprise Company. To obtain such source code, please check if the code is available in the HPE Software Center at https://myenterpriselicense.hpe.com/cwp-ui/software but, if not, send a written request for specific software version and product for which you want the open source code. Along with the request, please send a check or money order in the amount of US $10.00 to:

Hewlett Packard Enterprise Company
Attn: General Counsel
WW Corporate Headquarters
1701 E Mossy Oaks Rd Spring, TX 77389
United States of America