Clustering

From securityrouter.org, an OpenBSD-based firewall
Jump to: navigation, search

Clustering and high availability is a concept that spans a broad range of features within the router. This document is divided into sections targeting different audiences.

Zero-configuration clustering

For administrators that wish to deploy two routers in a high availability cluster with as little manual intervention as possible, the zero-configuration clustering is a very good start. Its main characteristics are:

  • It works both on new deployments (installing two routers from scratch) and existing deployments (adding a backup router)
  • It automatically converts the configuration, although some manual adjustments might be necessary depending on its complexity
  • It only requires one WAN (Internet) IP address; shared by both routers
  • The routers communicate over a cluster synchronization interface, which by default is the last (highest number) Ethernet interface
  • The clustered units synchronise such things as firewall states and SA/SPD (IPsec) states with each other.

Enabling automatic clustering

  1. Go to the web administration of the node you wish to use as master
  2. Go to Cluster > Configure (in the upper right corner, which might either have a cloud or a house icon).
    • In case you see a message saying that you have no dedicated cluster synchronization interface, press the "Convert" button.
  3. Connect the two nodes (for example using a network cable) on the interface that is specified in bold font (normally the last Ethernet port).
  4. Press "Next" (this will synchronize the node's cluster certificates, used for authentication and encryption hereafter).
    • In case you see a password error, make sure all nodes have the same password
  5. Press "Activate"
    • In case you are not satisfied with the configuration changes that are suggested; otherwise press "Edit", make some changes, and then "Apply".
  6. You are now clustering!

Add private configuration values

When clustering is enabled, the configuration is synchronized to all your configured cluster { peer's. It may however be usable to have some private configuration per unit like hostname, advskew or a separate management address. Replacement rules may be added by using the cluster statement, either manually using the plain-text editor, or from the cluster menu's "Configure" page.

cluster {
   peer 169.254.100.1 {
      hostname1
      212.37.18.195
      advskew 1
   }
   peer 169.254.200.2 {
      hostname2
      212.37.18.196
      advskew 50
   }
}

When the configuration is synchronized to peer 169.254.200.2 coming from peer 169.254.100.1 search for hostname1 and replace with hostname2 through the configuration (text-matching).

Clustering with different hardware

If you're cluster with different hardware, the replacement rules may be used to rename hardware interfaces in the configuration.

cluster {
   peer 169.254.100.1 {
      em0
      em1
   }
   peer 169.254.200.2 {
      bge0
      bge1
   }
}
interface em0 {
   ...

CARP without clustering

Normally, routers share only one address per interface. One disadvantage of that approach is that it's difficult to reach the routers separately. They do not have their own unique addresses. To use both shared and unique addresses, consider the following configuration. Differences between the master and backup router is marked by red and green colors. Important details are emphasized with blue colors.

interface em0 {
   group "wan"
   address 212.37.18.195/27 # on master router
   address 212.37.18.196/27 # on backup router
   interface carp0 {
      group "wan"
      address 212.37.18.194/32 # use all-ones mask for aliases
      ...
   }
   route default 212.37.18.193
   ...
}
...
firewall {
   match out on wan inet from (lan:network) nat-to (carp0:0) # nat on carp0 instead of the wan group
   ...
}

In the above example, the routers have their own unique addresses (.195 and .196) as well as the shared address (.194). The prefix lengths (masks) are emphasized; it's recommended to use /32 on the shared address, and the actual mask (/27 in this case) on the unique addresses (as described in on the addressing page). In this way, routing works even when a router is in backup mode. It's also recommended to change the NAT in order to use the first address of the WAN CARP interface (carp0) instead of the interface group "wan" (because it contains two addresses; both the unique and the shared address, and it's usually not a good idea to round-robin between those two).

Cluster management

Controlling who's master

You shouldn't ever have to manually control who's master, but it's possible. The system that's currently master can be forced to hand over to the slave by running (on the master)

ifconfig -g carp carpdemote 100

If, for some reason, you need to force the the slave into becoming master, you could run the command below (not recommended)

ifconfig carpX state master

Or, the reverse

 ifconfig carpX state backup