Learn how to set up OVHcloud Connect using OVHcloud APIv6.
Requirements
NOTE: To ensure the correct operation of this service, you must be aware of the technical capabilities and limitations of the OVHcloud Connect solution and configure your network devices accordingly.
- An OVHcloud Connect service
- Access to the OVHcloud APIv6 (create your credentials by consulting this guide)
Instructions
Step 1: Configuring vRack
As a mandatory first step, the service must be interconnected with a vRack to enable the configuration.
To get the UUIDs of eligible services, use the following call:
To link your OVHcloud Connect service with the vRack:
Information required:
- The serviceName of your vRack
- The ovhCloudConnect UUID
Step 2: Configuring the PoP
This step is important because you have to choose between L2 and L3.
NOTE: Please be aware of the ramifications of this decision. To switch between L2 and L3 later, you will have to delete the whole configuration.
Obtaining the interface ID
To obtain the ID of the interface dedicated to your service, use the following call:
The following call provides more service details:
The LightStatus parameter is refreshed every 5 minutes for monitoring purposes.
Configuration
To create a Layer 2 configuration, use the following call:
Information required:
- Your OVHcloud Connect serviceName
- The interfaceID found in the previous step
- type: "l2"
The Layer 3 configuration is more complex because of the required BGP settings:
Information required:
- Your OVHcloud Connect serviceName
- The customerBgpArea (your BGP ASN, configured on your device, which will be used for peering)
- The interfaceID found in the previous step
- The ovhBgpArea (your BGP ASN, configured on the OVHcloud routing instance, pertaining to BGP session and AS path)
- subnet (a /30 IPv4 block)
- type: "l3"
Step 3: Configuring the data center (DC)
If an OVHcloud Connect service is already configured in the vRack, the second service will inherit the data center configuration.
Obtaining available data centers
You can list available data centers for configuration using the following calls:
Information required:
- Your OVHcloud Connect serviceName
Information required:
- The id of your datacenter
- Your OVHcloud Connect serviceName
Configuration
Only the ID of the data center is needed for the L2 configuration:
Information required:
- The popId created in Step 2
- Your OVHcloud Connect serviceName
- The datacenterId previously obtained
More parameters have to be provided for the L3 configuration:
Information required:
- The popId created in Step 2.
- Your OVHcloud Connect serviceName
- The datacenterId previously obtained
- The ovhBgpArea (you need to assign an ASN for the OVHcloud routing instance; it will appear in AS path and can be different from the PoP ASN)
- The subnet (an IPv4 block; sizes starting at /28 are accepted)
By default, the data centre will be configured with a VRRP instance. You have to proceed with the next steps for static routing or dynamic routing using BGP.
Layer 3 option: Static route
A static route is needed when you have one or more subnets behind a gateway. This may be a Linux gateway (with IP forwarding enabled), an NSX edge, or any instance capable of routing.
Information required:
- The datacenterId previously obtained
- The popId created in Step 2.
- Your OVHcloud Connect serviceName
- nextHop (the IP address in the subnet range acting as the gateway)
- subnet (a prefix using the CIDR notation)
- type: "network"
Layer 3 option: BGP session
A BGP session enables dynamic routing from your routing instance with OVHcloud Connect. Announcements are dynamically managed using the BGP protocol. Enabling a BGP session disables the VRRP configuration. You cannot have a BGP session and a static route in the same DC configuration.
Information required:
- The datacenterId previously obtained
- The popId created in Step 2.
- Your OVHcloud Connect serviceName
- bgpNeighborArea (your BGP ASN)
- bgpNeighborIp (your IP address in the subnet range)
- type: "bgp"
Removing resources
Each resource can be deleted individually, but deleting a parent resource like a DC or PoP will automatically delete all sub-resources. However, recursive deletion is slower than a sequential deletion of each resource.
Global deletion
The following call recursively deletes the entire configuration of an OVHcloud Connect service:
Each sub-resource’s status will change from active to toDelete, but it takes some time to see the status change.
Only one task ID is created.
Deleting by resource
Each resource can be deleted individually using the following call that will delete the smallest resource (extra):
The following call removes the DC configuration and recursively deletes any additional sub-resources:
When all sub-resources have been deleted, the PoP configuration can be safely removed:
If a DC configuration is shared between two or more OVHcloud Connect services, deleting the PoP configuration of only one will not affect the DC resource.
Go further
For more information and tutorials, please see our other Network support guides or explore the guides for other OVHcloud products and services.
If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.