Skip to main content

dtcloud_router_static_route (Resource)

Adds one static route to a router: traffic for a destination is sent to a next hop instead of out of the gateway.

Example Usage​

resource "dtcloud_router_static_route" "branch" {
  router_id   = dtcloud_router.main.id
  destination = "192.168.50.0/24"
  next_hop    = "10.0.10.20"

  # The interface the next hop sits behind cannot be detached while this route
  # exists, and nothing in the API reports that dependency. Say it here.
  depends_on = [dtcloud_router_interface.app]
}

# Several routes, one resource per entry.
variable "branch_networks" {
  type = map(string)
  default = {
    "192.168.51.0/24" = "10.0.10.21"
    "192.168.52.0/24" = "10.0.10.22"
  }
}

resource "dtcloud_router_static_route" "branches" {
  for_each = var.branch_networks

  router_id   = dtcloud_router.main.id
  destination = each.key
  next_hop    = each.value

  depends_on = [dtcloud_router_interface.app]
}
note

There is nothing to change in place. A route is its destination and next hop, so changing either is a different route. Both ends are checked during terraform plan, so a malformed one is an error before anything is sent.

Schema​

Required​

  • destination (String) Destination network in CIDR notation, for example 192.168.50.0/24. Changing this forces a new resource to be created.
  • next_hop (String) Address traffic for the destination is sent to. IPv4, without a prefix length. Changing this forces a new resource to be created.
  • router_id (String) ID of the router the route is added to. Changing this forces a new resource to be created.

Optional​

Read-Only​

  • id (String) The ID of this resource.

Nested Schema for timeouts​

Optional:

  • create (String)
  • delete (String)

Behaviour worth knowing​

  • Routes on one router are applied one at a time. The platform applies a route by rewriting the router's entire route list, so two routes written at the same moment both read the list as it was before either, and the second write drops the first. The provider serialises the routes of a single router, which means a router with many routes takes proportionally longer to apply; routes on different routers still go in parallel. What it cannot protect you from is something else writing to the same router at the same time -- another run, or the web console.
  • A route removed elsewhere comes back. The next refresh drops it from state and the next apply adds it again. That is also the provider's answer to the overwrite above: converge again.
  • A route pins the interface it points through. If next_hop sits on a network attached with dtcloud_router_interface, that interface cannot be detached while the route exists, and Terraform cannot work that out on its own. Say it with depends_on.
  • Routes are not a list on the router. Adding one does not rewrite the router resource, and a route added outside Terraform is not silently deleted by the next apply. To see all of them, managed or not, read dtcloud_router_static_routes.

Timeouts​

create and delete each default to 10 minutes. Create does not return until the route is actually listed on the router, and delete not until it has gone: reading the value back is the only honest confirmation available, because the platform acknowledges these writes before applying them.

Import​

# <router-id>:<destination>:<next-hop>
terraform import dtcloud_router_static_route.branch 3f2a1c9e-77b4-4a01-9d3e-2b6c81f4e5a7:192.168.50.0/24:10.0.10.20

Everything round-trips -- the id carries the whole resource.