HAL, or High Availability L2TP, is a new feature that was added in the factory release version 1.54 for the FB2900. The feature gives extra resilience and near zero packetloss when you have multiple L2TP tunnels between sites by duplicating and de-duplicating packets over multiple L2TP tunnels between FireBricks.
This page is still under construction, but will serve as a good starting point to understanding the High-availability L2TP features of FireBrick. Send feedback and support requests to support@firebrick.co.uk.
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 give 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.
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.
Site-site example:
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 packetloss.
Outside broadcast example:
Here we have a 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 in to the live broadcast.
By simultaneously sending traffic over both mobile networks, the chance of dropped packets or interruptions to the live stream are 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 dongles 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.
Here are some answers to some common questions, feel free to get in touch if you have any queries though.
What's the difference between HAL and regular FireBrick PPP bonding?
PPP bonding is where the FireBrick, and the LNS at the far end, send alternate packets over the PPP links - this means increased throughput, as you can make use of the combined bandwidth of all the lines. If a link fails, there will be a short amount of time for the link to timeout and to stop being used. This is usually 10-60 seconds, but during this period there will be packetloss.
With HAL, packets are sent simultaneously, and a drop and packetloss on one of the links won't affect the end-to-end packetloss, and a drop of a tunnel or link won't be noticed.
Does this help overall speed/throughput?
No. If you have links that are of different speeds, then you want to ensure that your application is able to work over the slower link. You will want to look at per-packet bonding (eg by using FireBrick L2TP) if you are wanting combine the bandwidth of multiple links.
HAL is designed for increasing resilience rather than increasing throughput.
Can I mix slow and fast links for resilinece?
Yes. But ensure that your application is able to work over the slower link. You also want to be aware of over utilising the slow link will cause it to have packetloss. This in itself isn't a problem, as pasckets will still be going over the faster link. However, resilience will be lost if the slow link gets full and has high latency or packetloss, as the idea of duplicating packets becomes redundant as they are not lost or delayed over the slow link.
It is fine to mix fast and slow links, but remember that you don't want to over utilise the slow link.
Is the traffic encrypted?
The L2TP tunnels themselves are not encrypted, but you can put encrypted traffic over the top. You could run IPSec or other VPN traffic through the L2TP as required.
Is this SD-WAN?
SD-WAN is one of those acronyms that means different things to different people, and different vendors implement SD-WAN style features in different ways. By some definitions FireBrick's HAL feature is a type of SD-WAN. It allows low cost and diverse types of connections to be utilised for high resilience, and supports the ability to run other protocols over the top.
Are there any licence costs?
The HAL feature is available on the FB2900 Fully loaded model. It's not on the 'Base' model, or the older FB2700 or FB2500 models. There are licence fees, there are no per-user or per-seat fees. Once you've purchased your FireBrick it's yours, software updates are free, as usual, too!
Is there an RFC for duplicating L2TP traffic like this?
RFCs are documents that describe internet protocols. L2TP itself is RFC 2661. FireBrick's HAL implementation is its own. There isn't a RFC for this.
RFC7198, from 2014, describes a method for duplicating RTP streams, so the idea of duplicating and de-duplicating traffic has been around a long time. Again, this RFC wasn't references in the design of the FireBrick protocol, but RTP (and other real-time protocols) can be sent over FireBricks' HAL.
Why L2TP?
L2TP is a lightweight protocol that already exists in FireBrick code, and allowed this feature to be added relatively easily
Can technologies be mixed, eg DSL and 5G?
Yes, you can mix ADSL, VDSL, FTTP, and mobile data connections. All that matters is that the L2TP tunnels come up and then packets be be sent over all available links.
What limits the speed/bandwidth?
Packets will be sent over all available links and the overall speed will be limited by that of the fastest link - however, the slower links will get full and will suffer packetloss themselves, which meant the overall link will suffer jitter if there is a small amount of packetloss on the faster link. As a rule of thumb: You will want to ensure that your application is able to work on the slower link, as if the faster link fails you want your application to carry on working! Also be aware if any of your links have usage quotas on them as traffic will be going over all links simultaneously.
Does this use the 'cloud'?
No. It's simply two FireBricks in separate places joined up by tunnels over the normal internet.
Is this magic?
No. Our solution is technically quite simple:
These examples are still under construction and at the moment assume some existing knowledge of FireBrick configuration.
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
<l2tp>
<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"/>
</incoming>
</l2tp>
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
<l2tp>
<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"/>
</l2tp>
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 in to 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.
