High Availability L2TP

HAL, or High Availability L2TP, is a new feature that was added in teh 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 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.


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

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
  • 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 etherent 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-site example:

FireBrick High Availability L2TP
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 packetloss.

Outside broadcast example:

HAL-outside-broadcast
HAL in use with an outside broadcast facility via 4G

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.

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 get in touch if you have any queries though.

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.

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.

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.

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.

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!

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.

L2TP is a lightweight protocol that already exists in FireBrick code, and allowed this feature to be added relatively easily

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.

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.

No. It's simply two FireBricks in separate places joined up by tunnels over the normal internet.

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 (Head end):

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:


FireBrick-L2TP-HAL-Status-Sessions

FireBrick-L2TP-HAL-Status-Sessions2

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.

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.

Sales & Dealer Enquiries

email sales@firebrick.co.uk
phone 01344 400 500
Mon - Fri, 9am-5pm,
calls are recorded
sms 01344 400 500

Support Contact

email support@firebrick.co.uk
phone 01344 400 500
Mon-Fri 9am-5pm,
calls are recorded
sms 01344 400 500