Routing and tunneling

This page describes how traffic is routed and tunneled in a Bonded Internet environment.

Without Private WAN

Logical layout

The diagram below shows the logical relationship between the partner core network, aggregator, bonder, and customer firewall.

This reflects the virtual tunnel between the bonder and aggregator, acting as a direct connection between the two hosts. This is how the end-user experiences Bonded Internet—their access to the Internet is through the bonder, aggregator, and then the partner network.

Physical layout

The physical layout in the diagram below shows the real connections between hosts.

This figure shows that the bonder and aggregator are separated by the Internet. Traffic from the bonder to the aggregator goes through the legs to the Internet, then to the partner’s core network, where it is finally delivered to the aggregator. Internet-bound traffic is then sent back through the partner core network to the Internet. This results in each packet being seen twice at the partner’s core routers—first, the tunneled packet coming from the bonder to the aggregator, and then the real packet going from the aggregator to the Internet. Traffic from the Internet to the bonder is also seen twice—first the routers receive the packet from the Internet being routed to the bonder via the aggregator, and then they see the tunneled packet going from the aggregator to the bonder. For more details on tunneling and encapsulation, see the Tunnel encapsulation section below.

With Private WAN

Routing and tunneling of traffic is handled differently in a PWAN environment compared to a non-PWAN environment, and depends on the mode of PWAN. Refer to the private WAN documentation for specific network integration details.

Logical layout

Compared to a non-PWAN environment, there is one additional hop in the route from a PWAN-enabled bonder to an Internet host. After leaving the aggregator, a packet from an end-user going to the Internet first goes to the active PWAN router in the aggregator’s routing group, then is forwarded either to a dedicated gateway for the space, or to the partner’s core router, depending on the type of gateway configured for the space. If the packet is destined for a host in the space, the PWAN router will route the packet to another aggregator in the same routing group or to a PWAN router in a different routing group.

Physical layout

PWAN supports a variety of physical layouts. In the example below, the aggregation server is on the same network segment as the PWAN router, and they route traffic between them using an encrypted tunnel. However, other layouts are supported, including having the PWAN router in the same datacentre as the aggregators but a different Ethernet or IP subnet, or having the PWAN router in a completely different datacentre as the aggregators.

Connection example

The following example describes how traffic is tunneled and routed when a connection is initiated from the customer’s firewall to a host on the Internet.

First, the firewall sends a packet to the bonder.

The bonder encapsulates the original packet and sends it over a leg to the aggregator via the Internet.

The tunneled packet is received by the aggregator from the partner core network.

The aggregator removes the encapsulation in the tunnel packet and sends the original packet to the Internet via the partner core network.

The response to the connection takes the reverse path—the partner core network routes the response to the aggregator, the aggregator encapsulates the response and sends it to the bonder via the Internet, the bonder removes the encapsulation, and the response is sent to the customer’s firewall.

Tunnel encapsulation

Bonded Internet uses a tunnel application and protocol to move traffic between the bonder and aggregator. This process is similar to methods employed by other tunnels, such as OpenVPN, although Bonded Internet uses a proprietary UDP protocol designed for efficiency and security.

When a packet bound for the Internet is received by the bonder from the customer firewall, the following steps are taken:

1. The packet is received by the bonder from the customer’s LAN. Let’s call this packet C, for client.
2. The packet is encapsulated with a proprietary header. This header contains information such as whether or not the packet is compressed, the packet’s sequence in its flow, and an optional security tag. This can be represented as B(C), where B stands for Bonded Internet. This shows that the original packet C is encapsulated with the Bonded Internet header B.
3. The tunnel process on the bonder selects the best leg on which to send the packet to the aggregator. UDP and IP headers are added by the bonder operating system and the packet is sent on the selected leg. The packet can now be represented as I(U(B(C))), where I represents the IP header and U represents the UDP header.
4. The encapsulated packet I(U(B(C))) is sent from router to router on the Internet until it reaches the aggregator.
5. The IP and UDP headers are stripped away by the aggregator operating system. The tunnel process on the aggregator reads the packet B(C).
6. The aggregator tunnel process handles the packet according to the contents of the Bonded Internet header. The header is stripped away, leaving only the original client packet C.
7. The client’s original packet C is sent to its destination based on routes in the aggregator’s routing table.

When receiving packets from the Internet bound for a bonder, the same process occurs in reverse.

The following diagram shows the above process graphically.

C: packet from customer’s LAN

B: Bonded Internet tunnel header

U: Tunnel UDP header

I: Tunnel IP header