High Availability L2TP

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.

Key Points

  • 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

Site Example:

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.

Use Cases

Live broadcasting – send real-time audio-visual streams between sites.

  • Point to point real-time communications
  • Low bandwidth, but high-reliability scenarios

FAQ

Here are some answers to some common questions. Feel free to contact us if you have any queries though. T: 020 7517 4900

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 packet loss.

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 to combine the bandwidth of multiple links.

HAL is designed for increasing resilience rather than increasing throughput.

Can I mix slow and fast links for resilience?

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 packet loss.
This in itself isn’t a problem, as packets will still be going over the faster link. However, resilience will be lost if the slow link gets full and has high latency or packet loss, 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 link 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 didn’t reference 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 packet loss themselves, which meant the overall link will suffer jitter if there is a small amount of packet loss 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:

  • establish multiple tunnels between a pair of FireBricks
  • send the traffic across these tunnels simultaneously
  • accept the packet that arrives first
  • discard the duplicates that arrive after

Example config

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

<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>

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

<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 into different routing tables accordingly.

Going further

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.