# wan-bridge: the DC WAN segment as a libvirt BRIDGE onto an existing host
# bridge (D-125, Model B bridge-in), NOT a NAT. Sibling to modules/site-wan:
# - site-wan = NAT'd /24 simulated ISP, egresses via ITS HOST's default route
# (correct at vcloud level; the `office1-wan` / `vr1-dc0-uplink`
# pattern -- there is exactly ONE such NAT = the simulated ISP).
# - wan-bridge = no subnet, no NAT: it hands the site edge's WAN leg straight
# onto a pre-existing Linux bridge (`br-vr1-dc0-wan`) that the
# node-host bootstrap builds by enslaving vvr1-dc0's IP-less
# uplink NIC. The edge WAN then lives on the vcloud ISP /24 and
# the single NAT is at vcloud (D-125). Use this INSIDE a
# containment VM whose real egress is a bridged uplink port.
#
# Why a bridge and not a NAT here: under D-123 Model B this network is created
# INSIDE vvr1-dc0, whose only routed leg is the East-West-only transit (SEC-010
# FORWARD-drops it). A NAT here would have no egress (OBS-3). Bridging the edge
# WAN through to the vcloud ISP NAT restores independent per-DC egress with a
# single NAT hop.
variable "network_name" {
description = "libvirt network name, e.g. \"vr1-dc0-wan\" (the edge's wan_network_name)."
type = string
}
variable "host_bridge" {
description = <<-EOT
Name of a PRE-EXISTING Linux host bridge this libvirt network attaches to,
e.g. "br-vr1-dc0-wan". The bootstrap (site-headend-install.sh node-host
mode) MUST create this bridge and enslave the IP-less uplink NIC BEFORE the
inner tofu apply -- libvirt does not create it in bridge forward mode. The
edge WAN interface then takes a STATIC address on the vcloud ISP /24 (set in
the edge config, D-113), reaching the vcloud NAT gateway across this bridge.
EOT
type = string
}
variable "mtu" {
description = "WAN-segment MTU. Default 1500 (the ISP-uplink domain; NEVER jumbo -- matches site-wan)."
type = number
default = 1500
}