End-to-End Example

DE-CIX PDM Team Updated by DE-CIX PDM Team

End-to-End Example: Deploying a Cloud ROUTER with Terraform

This example demonstrates complete Cloud ROUTER deployment using the IX-API Terraform provider. This is an advanced example demonstrating a multi-service Cloud ROUTER deployment.

The scenario includes:

- 1 Cloud ROUTER (VRF)

- 2 Cloud VC connections

- 1 P2P VC connection

- 1 Prefix List

- 1 Routing Policy

- 1 Static Route

- verification data sources

This example is intended to show how a customer might attach multiple services to a single Cloud ROUTER and manage them consistently through Terraform.

Scenario

In this example:

- Cloud VC 1 represents connectivity to a first cloud environment

- Cloud VC 2 represents connectivity to a second cloud environment

- P2P VC represents a private site-to-site or partner connection

The Cloud ROUTER acts as the central routing instance and terminates all three BGP sessions.

Prerequisites

- Terraform v1.0 or later

- Valid IX-API credentials

- A Cloud ROUTER product offering ID

- Existing network service IDs for:

- 2 Cloud VCs

- 1 P2P VC

- A physical connection ID for the P2P VC

- BGP passwords for all sessions

Step 1 – Define Variables

variable "account_id" {
  description = "DE-CIX account ID"
  type        = string
}

variable "product_offering_id" {
  description = "Cloud ROUTER product offering ID"
  type        = string
}

variable "p2p_vc_network_service_id" {
  description = "Network service ID for the P2P VC"
  type        = string
}

variable "cloud_vc_network_service_id_1" {
  description = "Network service ID for Cloud VC 1"
  type        = string
}

variable "cloud_vc_network_service_id_2" {
  description = "Network service ID for Cloud VC 2"
  type        = string
}

variable "network_connection_id" {
  description = "Physical connection ID for the P2P VC"
  type        = string
}

variable "bgp_password_p2p" {
  description = "BGP password for the P2P VC session"
  type        = string
  sensitive   = true
}

variable "bgp_password_cloud_1" {
  description = "BGP password for Cloud VC 1"
  type        = string
  sensitive   = true
}

variable "bgp_password_cloud_2" {
  description = "BGP password for Cloud VC 2"
  type        = string
  sensitive   = true
}

Step 2 – Configure the Provider

terraform {
  required_providers {
    ixapi = {
      source  = "registry.terraform.io/ix-api-net/ixapi"
      version = "~> 1.0"
    }
  }
}

provider "ixapi" {
  api                                    = "https://ixapi.de-cix.net/api/v2"
  api_key                                = var.api_key
  api_secret                             = var.api_secret
  extension_de_cix_cloud_router_enabled  = true
}

Step 3 – Create the Cloud ROUTER

resource "ixapi_de_cix_cloud_router" "main" {
  managing_account  = var.account_id
  consuming_account = var.account_id
  billing_account   = var.account_id

  product_offering  = var.product_offering_id
  asn               = 65000
  capacity          = 1000
  external_ref      = "customer-cloud-router-prod"
}

Step 4 – Attach the P2P VC

This attachment can represent a private connection to a site, partner, or on-premises environment.

resource "ixapi_de_cix_cloud_router_network_service_config_p2p_vc" "site_a" {
  managing_account   = var.account_id
  consuming_account  = var.account_id
  billing_account    = var.account_id

  cloud_router       = ixapi_de_cix_cloud_router.main.id
  network_service    = var.p2p_vc_network_service_id
  network_connection = var.network_connection_id

  address            = "10.0.1.1/30"
  bgp_neighbor       = "10.0.1.2"
  bgp_neighbor_asn   = 64512
  bgp_password       = var.bgp_password_p2p
  admin_status       = "enabled"
  bfd_enabled        = true
  external_ref       = "site-a-p2p"

  vlan_config {
    vlan_type = "dot1q"
    vlan_id   = 100
  }
}

Step 5 – Attach Cloud VC 1

This attachment can represent connectivity to a first cloud environment.

resource "ixapi_de_cix_cloud_router_network_service_config_cloud_vc" "cloud_1" {
  managing_account  = var.account_id
  consuming_account = var.account_id
  billing_account   = var.account_id

  cloud_router      = ixapi_de_cix_cloud_router.main.id
  network_service   = var.cloud_vc_network_service_id_1

  address           = "10.0.2.1/30"
  bgp_neighbor      = "10.0.2.2"
  bgp_neighbor_asn  = 64513
  bgp_password      = var.bgp_password_cloud_1
  admin_status      = "enabled"
  bfd_enabled       = true
  handover          = 1
  external_ref      = "cloud-vc-1"
}

Step 6 – Attach Cloud VC 2

This attachment can represent connectivity to a second cloud environment or a second cloud region.

resource "ixapi_de_cix_cloud_router_network_service_config_cloud_vc" "cloud_2" {
  managing_account  = var.account_id
  consuming_account = var.account_id
  billing_account   = var.account_id

  cloud_router      = ixapi_de_cix_cloud_router.main.id
  network_service   = var.cloud_vc_network_service_id_2

  address           = "10.0.3.1/30"
  bgp_neighbor      = "10.0.3.2"
  bgp_neighbor_asn  = 64514
  bgp_password      = var.bgp_password_cloud_2
  admin_status      = "enabled"
  bfd_enabled       = true
  handover          = 2
  external_ref      = "cloud-vc-2"
}

Step 7 – Create a Prefix List

This example prefix list matches customer address space and can be referenced by routing policies.

resource "ixapi_de_cix_cloud_router_prefix_list" "customer_nets" {
  name              = "customer-networks"
  managing_account  = var.account_id
  consuming_account = var.account_id

  match_list {
    prefix     = "10.10.0.0/16"
    min_length = 24
    max_length = 28
  }

  match_list {
    prefix     = "172.20.0.0/16"
    max_length = 24
  }
}

Step 8 – Create a Routing Policy

This policy accepts matched customer prefixes and assigns a higher local preference. All other routes are rejected.

resource "ixapi_de_cix_cloud_router_policy" "inbound" {
  name              = "inbound-policy"
  managing_account  = var.account_id
  consuming_account = var.account_id

  entries {
    sequence_number   = 10
    match_prefix_list = ixapi_de_cix_cloud_router_prefix_list.customer_nets.name

    action {
      filter           = "accept"
      local_preference = 200
    }
  }

  entries {
    sequence_number = 20

    action {
      filter = "reject"
    }
  }
}

Step 9 – Create a Static Route

This example creates an aggregate route and associates it with selected network service configurations.

resource "ixapi_de_cix_cloud_router_static_route" "internal_aggregate" {
  name                    = "internal-aggregate"
  prefix                  = "10.100.0.0/16"
  next_hop                = "aggregate"
  network_service_configs = [
    ixapi_de_cix_cloud_router_network_service_config_p2p_vc.site_a.id,
    ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_1.id
  ]
}

Step 10 – Add Verification Data Sources

These data sources can help confirm that the Cloud ROUTER and attached sessions are operational after deployment.

data "ixapi_de_cix_cloud_router_routes" "main" {
  vrf = ixapi_de_cix_cloud_router.main.id
}

data "ixapi_de_cix_cloud_router_bgp_state" "p2p" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_p2p_vc.site_a.id
}

data "ixapi_de_cix_cloud_router_bgp_state" "cloud_1" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_1.id
}

data "ixapi_de_cix_cloud_router_bgp_state" "cloud_2" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_2.id
}

data "ixapi_de_cix_cloud_router_bfd_state" "p2p" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_p2p_vc.site_a.id
}

data "ixapi_de_cix_cloud_router_bfd_state" "cloud_1" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_1.id
}

data "ixapi_de_cix_cloud_router_bfd_state" "cloud_2" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_2.id
}

Step 11 – Initialize, Review, and Apply

Initialize the working directory, review the execution plan, and then apply the configuration.

terraform init
terraform plan
terraform apply

Optional: Verify BGP Session State

After deployment, you can verify whether the configured BGP sessions have reached the expected operational state.

There are two useful approaches:

- Terraform data sources, for validation within the Terraform workflow

- Direct API calls, for troubleshooting and external verification

A healthy session is typically expected to reach the Established state.

data "ixapi_de_cix_cloud_router_bgp_state" "p2p" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_p2p_vc.site_a.id
}

data "ixapi_de_cix_cloud_router_bgp_state" "cloud_1" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_1.id
}

data "ixapi_de_cix_cloud_router_bgp_state" "cloud_2" {
  nsc_id = ixapi_de_cix_cloud_router_network_service_config_cloud_vc.cloud_2.id
}

You can also query the BGP session state directly via the API for a specific network service configuration.

curl --request GET \
  --url 'https://api.de-cix.net/api/v3/decix-vrf-v1/network-service-configs/<network_service_config_id>/bgp-state' \
  --header 'Authorization: Bearer <token>'

Possible BGP states include:

  • Idle
  • Connect
  • Active
  • Open Sent
  • Open Confirm
  • Established

For an operational session, Established is typically the expected target state.

Step 12 – Clean Up

To remove all resources managed by this example, destroy the Terraform configuration.

terraform destroy

Expected Result

After a successful deployment:

  • the Cloud ROUTER is created
  • 3 network service configurations are attached
  • 3 BGP sessions are configured
  • routing policy objects are available
  • a static route is present
  • operational state can be queried through data sources

Notes

  • This example uses illustrative IP addressing and ASNs. Replace these values with the parameters required for your environment.
  • The exact network service IDs, handover values, and BGP settings depend on your provisioned services.
  • Cloud VC and P2P VC resources follow similar patterns, but their required attributes differ based on the service type.

How did we do?

State Management

Get in touch