📚 Browse docs

Networking

A guest that boots at the recovery site is useless if it lands on a bridge that doesn’t exist there, or keeps an IP that belongs to a subnet the recovery site has never heard of. Networking is where you answer that once, per DR Site Pair, so every protected guest inherits the right answer instead of you fixing each one by hand during an outage.

Everything on this page is a pair-level default. Individual guests can override it, and the page shows you which ones do.

These settings are recovery-owned: the recovery site holds the truth, because it’s the side that has to make them work. When you open the page from the source site, Asternodis reads them through the peer, so you see and edit the same values from either end.

Failover networking mode

The pair-wide choice for what happens to a guest’s addressing when it comes up at the recovery site:

  • Keep VM IPs (your network): the guest boots with the addresses it already had, on a bridge you provide. Right when the two sites share a stretched L2 or you’re failing over a whole subnet.
  • Keep VM IPs (Asternodis gateway): the guest keeps its addresses, and Asternodis builds the network for it: a DR edge gateway on the recovery node routes an isolated bridge that mirrors the production subnet, with NAT and port-forwarding to the recovery site’s uplink. For applications that hard-code addresses and cannot be re-IP’d. See the gateway below.
  • Re-IP to the recovery subnet: the guest’s addresses are rewritten for the recovery network. Right when the recovery site is a different subnet, which is the common case for a second building or a colo.

The DR edge gateway

Choosing Keep VM IPs (Asternodis gateway) opens the gateway editor:

  • Router: run the gateway as nftables rules on the recovery node itself, or as a dedicated LXC appliance.
  • Isolated bridge: the Asternodis-managed bridge recovered guests attach to (vmbrdr0 by default). It is created for you, and every failover applies the gateway before the guest boots; with the recovery-node router the bridge is also persisted so it survives a node reboot.
  • Uplink interface: the recovery node’s outward-facing interface (auto-detected, or pick one). With the LXC appliance this is the uplink bridge the appliance’s second interface attaches to.
  • Mirrored source subnet and gateway IP: the production subnet the bridge reproduces, and the address recovered guests use as their default gateway.
  • Appliance uplink IP (blank = DHCP) and Appliance uplink gateway (for a static IP) (LXC appliance only): the appliance’s own address on the uplink, as a CIDR, or blank to take a DHCP lease; the gateway field appears once a static address is entered.
  • Port forwards: uplink port → recovered guest address:port, so services stay reachable from outside the mirrored subnet.

Save stores the configuration; Save & apply now also builds the bridge and rules immediately, and Teardown removes them from the node. The page shows the resulting effective behaviour line, as it does for the other two modes. If applying couldn’t fully replace the gateway’s previous firewall rules, the result carries a warning alongside the applied configuration: a rule it failed to remove could still be routing traffic to a target the new configuration no longer names.

Network mapping

The source → recovery bridge and VLAN map. For each bridge a protected guest uses at the source, you say which bridge it should attach to at the recovery site, with an optional VLAN tag.

There’s a separate column for DR test so a non-disruptive test can land on an isolated bridge: the test boots a real copy of the guest, and you rarely want that copy on the production network answering for the same addresses.

Unmapped bridges are the single most common reason a failover boots a guest with no reachable network, so map every bridge your protected guests actually use. Asternodis checks it for you. Before a failover, the preflight resolves each NIC’s target bridge exactly as the failover will and checks that it exists on the node that will run the guest (a Linux or an Open vSwitch bridge alike). A bridge that is missing there is a definite failure you must acknowledge before the failover runs; one the check could not read is reported as unverified, never as present. Between failovers, the critical recovery_bridge_missing alert is raised while a protected guest’s target bridge is missing on the node that would run it (checked every five minutes), and clears by itself once the bridge exists. Saving a mapping, or the pair’s default recovery bridge, is refused when the bridge provably does not exist on the recovery cluster’s nodes.

The Source bridge field suggests names drawn from the guests already protected in this pair, so you’re rarely typing a bridge name from memory. If Asternodis can’t read those suggestions, it says so: an empty list means the pair has none, not that the read failed.

Re-IP default

The subnet rewrite guests inherit when they have no explicit per-guest re-IP: the recovery subnet, gateway, and how source addresses translate into it. Set this and you generally don’t need to touch individual guests at all.

The Gateway and Nameserver fields ride along with the subnet rewrite and only take effect once both subnets are filled in. Setting one of them, or only one of the two subnets, without completing the rewrite is refused with a message naming what’s missing.

When the mode and the default disagree

If the mode says Keep IPs but a re-IP default is set, the effective behaviour is Re-IP: the default wins, because it’s the more specific instruction. Rather than leave that as a trap, the page computes the effective behaviour live and offers two one-click fixes:

  • Clear re-IP default, so Keep IPs genuinely keeps IPs, or
  • Switch to Re-IP mode, so the label matches what already happens.

Either is correct. What matters is that the page never quietly does something other than what it says.

DNS

An Asternodis-managed dnsmasq that the recovery node runs for the pair. When guests are re-IP’d, their names have to resolve to the new addresses or half your estate still points at dead ones. This gives the recovery site a zone that answers for the recovered guests without you touching production DNS.

Per-VM networking

The per-guest view of the same settings: which guests inherit the pair defaults and which carry their own re-IP override, with a link into each guest’s detail page to edit it.

Use the defaults for the bulk of your estate and reserve overrides for the handful of guests that genuinely need a fixed address at the recovery site: domain controllers, load balancers, anything else hard-coded elsewhere.