HAL, or High Availability L2TP, is a new feature that was added in the factory release version 1.54 and was available in later alpha and beta version of 1.53.
The feature gives extra resilience and near-zero packet loss when you have multiple L2TP tunnels between sites by duplicating and de-duplicating packets over multiple L2TP tunnels between FireBricks.
RAID 1 for Packets
Bonding of multiple internet connections has been a feature of FireBrick ever since the first model. You have many ways to bond traffic – whether that is per-packet bonding of multiple PPP links or load balancing with NAT, FireBrick gives you the flexibility to use the bandwidth that multiple internet connections give you.
With the new HAL feature, you can use multiple L2TP tunnels between FireBricks in a similar way to RAID 1 with multiple hard drives.
Duplication and De-duplication
When using multiple L2TP tunnels with HAL enabled, packets are duplicated and set up all the tunnels.
The FireBrick at the far end then routes the one that was received first and discards the subsequent duplicated packets. Exactly the same happens in reverse.
This means the packet that arrives the fastest wins.
- You can use (and should use) multiple ISPs for resilience
- Public IPs at one end required, in order to establish the L2TP tunnel
- The fastest packet is accepted, rest are discarded – improves latency
- Multiple L2TP tunnels can be set for HAL
- Zero failover time in event of a line/tunnel going down
- Can be used for any IP traffic
- Can be used over 3G/4G connections (eg a dongle or 3G/4G/5G ethernet routers)
- Combine with IPsec or ETUN to link separate networks
- Ideal for site-site, or site-datacentre links where packet loss is not desired
- Ideal for real-time protocols such as VoIP, video streaming/broadcasting
- FireBrick supports up to three separate sets of grouped HAL tunnels
- Ensure you don’t over utilise any slow links in the set
HAL in use between two sites
Here we have two sites, each connected to the internet via multiple and separate ISPs. Two tunnels are established between the sites over diverse routes, and HAL is enabled.
The result: Traffic passing between the sites are duplicated and de-duplicated and the loss of a link does not result in any packet loss.
Outside broadcast example:
HAL in use with an outside broadcast facility via 4G
Here we have an FB2900A, the DC PSU variant running of 12-24v from an outside broadcast truck. The internet connectivity is via multiple mobile, using 3G/4G, depending on what’s available.
A live audio/video stream takes place and is sent to the headquarters where they mix it into the live broadcast.
By simultaneously sending traffic over both mobile networks, the chance of dropped packets or interruptions to the live stream is minimised. We show here two mobile dongles being used, but in practice more can be used, and we’d recommend using separate mobile networks to minimise the chance of interruptions. Either dongle can be connected to the FireBrick (via a USB hub) or separate Ethernet Mobile routers can be used.
Live broadcasting – send real-time audio-visual streams between sites.
- Point to point real-time communications
- Low bandwidth, but high-reliability scenarios
Here are some answers to some common questions. Feel free to contact us if you have any queries though. T: 020 7517 4900
These examples are still under construction and at the moment assume some existing knowledge of FireBrick configuration.
Site 1 (Headend):
The head end may be the head office or a FireBrick in a datacentre. It has a public IP of 192.0.2.1. We’ll have two tunnels configured for a remote end to use. We’ll assign the tunnels an IP address from our LAN.
The L2TP config is found in the web UI: Tunnels – L2TP settings – Incoming L2TP connections
<incoming name=”remote” remote-hostname=”remote” local-hostname=”head” bgp=”false” lcp-timeout=”5″ tcp-mss-fix=”true” ha-set=”A” comment=”HAL Tunnels to Remote”>
<match graph=”remote.1″ username=”remote.1″ password=”secret” remote-ip=”10.0.0.250″/>
<match graph=”remote.2″ username=”remote.2″ password=”secret” remote-ip=”10.0.0.250″/>
Site 2 (Remote end):
The remote side has two internet connections, the two internet connections are put in to separate routing tables (table 1 and table 2) The LAN, is on the default routing table, table 0.
The L2TP config is found in the web UI: Tunnels – L2TP settings – Outgoing L2TP connections
<outgoing name=”head1″ hostname=”remote” secret=”test” server=”192.0.2.1″ graph=”L2TP-remote-1″ table=”1″ payload-table=”0″ username=”remote.1″ password=”test” lcp-rate=”1″ lcp-timeout=”5″ tcp-mss-fix=”true” ha-set=”A” comment=”HAL tunnel #1 to head office”/>
<outgoing name=”head2″ hostname=”remote” secret=”test” server=”192.0.2.1″ graph=”L2TP-remote-2″ table=”2″ payload-table=”0″ username=”remote.2″ password=”test” lcp-rate=”1″ lcp-timeout=”5″ tcp-mss-fix=”true” ha-set=”A” comment=”HAL tunnel #2 to head office”/>
Once the tunnels are configured, you should see the status of them in Status – L2TP:
You can now look at routing traffic over the Tunnels. This will depend on how you want to use it. As it stands with our example, the L2TP tunnels are in the default routing table (0), and so will be used for outgoing traffic.
The remote end has been given the IP of 10.0.0.250, and so devices on either end of the tunnels should be able to route traffic to eachother.
Further configuration can be done to use separate or different routing tables, and the use of Firewall rules will allow traffic to be described and then put into different routing tables accordingly.
You can then run other protocols over the top of your L2TP tunnels – you may have a site to site VPN, or you could link two ethernet segments using FireBrick’s ETUN tunnel.