Seamless Supplement of Existing Multi-Office MPLS Network - MPLS and DSL bonding through SpeedFusion


Environment:

  • This organization has one head office with and two branch offices, with most of the crucial information stored in a server room at the head office.
  • They are connecting the offices together using a managed MPLS Solution. However, the MPLS Network is operating at capacity and upgrading the links is cost prohibitive.
  • As the organization grows, it needs a cost-efficient way to to add more bandwidth to its wide area network.
  • Internet access at the remote sites is sent via a web proxy at head office for corporate web filtering compliance.

Requirement:

  • User sessions need to remain uninterrupted
  • More bandwidth is required at the head office location for direct internet access.

Recommended Solution:

  • Form a SpeedFusion tunnel between the branch offices and head office to bond the MPLS and additional DSL lines.
  • SpeedFusion allows for hot failover, maintaining a persistent session while switching connections.
  • The DSLs at head office can be used for direct internet access providing lots of cheap internet bandwidth.
  • Head office can use outbound policies to send internet traffic out over the DSLs and only use the MPLS connection for speedfusion, freeing up bandwidth.

Devices Deployed: Balance 210, Balance 310, Balance 580

4 Likes

Dear Martin,

i have a similar scenario for the one you have, but i have 118 sites based in 26 countries globally, having MPLS and internet VPN connection, i wanted to know what is the sizing based on? and the bet practice design, should i apply a mesh scenario for sites in the same countries and all countries should be in a star-spoke design with the HQ?

appreciate your prompt reply

Hi,

You may refer here for the sizing.

All branches are recommended as star-spoke design with the HQ.

Hope this help.

1 Like

When we look to size a device for a role within a SpeedFusion WAN there are two key elements to consider, the SpeedFusion router throughput and the number of Supported SpeedFusion Peers.

You will need to do an analysis of the number of WAN connections at each location along with the available throughput, then consider any future gowth plans of that site to gauge which Balance router will be the best fit for the available bandwidth at the site.

As an example, if you had a small site using a pair of 10/12Mbps DSL connections then the Balance 210 would be fine. The 210 supports upto two WAN connections with 30Mbps of SpeedFusion throughput (you could also consider the 310 for future growth as you would have a free WAN link so you could add more bandwidth later).
However if you had a site with two 50Mbps FTTC connections then the 210 would be undersized and you would need to consider the Balance 580 (80Mbps SF Throughput) or 710 (160Mbps SF throughput) for this to make best use of the available bandwidth purely for WAN traffic.

A big element of a WAN design in the corporate environment is often web filtering. A lot of companies will have a centralised Web Proxy/Filter that they send all outbound internet traffic to that filters key categories of websites. If thats the case here, then you will definately need the bigger Balance devices as suggested above to match the SF throughput to the higher speed WAN links as all outbound internet access will need to go over SpeedFusion.

However if there is no centralized web proxy, then outbound traffic at a remote site can be split, so that internet access goes direct out over the local WAN connections and SpeedFusion is only used for site to site traffic (like VOIP and network file/web/print services). In this case a Balance 210/310 which supports 100Mbps of overall router throughput and 30Mbps of SpeedFusion VPN throughput is normally a good fit.

The next sizing factor is the number of SF Peers a device supports. This is the number of remote devices a single device can connect to simultaneously using SpeedFusion. A balance 210/310 can connect to two SpeedFusion Peers simultaneously and we would most often see one Peer as the main corporate datacenter and the other a a backup datacenter. A 380 Supports 20 Peers, a 580 50 peers, a 710 300 Peers etc etc (you can see the specs here http://www.peplink.com/products/balance/model-comparison/).

Obviously then, an important element of the SpeedFusion WAN design is inter-site traffic analysis. In most situations a hub and spoke WAN is fine (and preferred), with a larger enterprise device like a 580/710/1350 (or pair of devices for HA) in the Head office or datacenter (that supports the right number of SpeedFusion Peers to be able to connect to all the remote sites at the same time), and then smaller devices at the remote sites that connect back to it. In this configuration all sites can route traffic to each other via the central location as we provide dynamic route updates across SpeedFusion so that when a new site is added the exisiting sites know how to route traffic to it via the hub device.

There are some cases though, where you might want to add a direct SpeedFusion connection between the remote sites as well as having them connect to the central location. These are normally application or process based requirements. Consider for example a office location that sends large print jobs to a factory or warehouse site everyday. Print jobs tend to be bandwidth hogs, so it makes sense for that traffic to go direct between the sites themeselves rather than via the central location.

In your example of a network split across multiple countries, there will likely be teams split across these internal sites too - like marketing teams or design/CAD teams. Graphic design and CAD files can get big quick, so if they are planning to share large files (by pushing and pulling them to file servers at these locations) then connecting them together with direct SpeedFusion tunnels will reduce the bandwidth utilisation at their respective central hub locations.

In short then, without full knowledge of the client requirements I would expect this end design to consist of in country hub and spoke WANs using SpeedFusion (to keep all in country traffic local to reduce latency), with SpeedFusion tunnels between the hubs of all the countries (for VoIP traffic and other global core services like active directory / authentication). And then I would expect to see a handful of in country and global remote site to remote site SpeedFusion Tunnels added for specific traffic/application types to optimise data transit between teams.

Hope that helps, good luck with your design!

Martin

1 Like

Dear Martin

thanks for the reply,

first i wanted to know, if i have few sites that only depen on 1 VPN service(Internet), and others having MPLS and internet connections, thus i will only use the speedfusion license on those of two connectivity?

second the HQ balance, how will it be sized?should i add all the site’s bandwidth and that should determine the HQ balance?

as well i want to highlight the fact that we will be using peplink balance as a VPN concentrator , just if there are any best practices to apply

A SpeedFusino Peer refers to a single logical SpeedFusion connection between two of our devices. That logical SpeedFusion VPN could be using 10’s of different WAN links on bothe devices, but it is only connecting to one peer. Think of it as location to location.

When I am sizing the HQ balance I tend to ask the customer what connections they already have at the location and try and get an understanding of the usage across those links currently. Most customers have an idea about how much bandwidth they are using at their HQ site or can pull reports from providers to double check.

Then I look at the number of remote sites and factor in future company growth. Then I think about the applications in use now and ask about future plans. A lot of people are moving to cloud based apps now - especially for file sharing, so general site to site file transfers are reducing as traffic goes direct to the cloud.

In short you need to know (or calculate) bandwidth requirements now and estimate for the future, and you need to know the number of locations a hub site will support and again plan for future growth, then you can pick a Balance that can support the right amount of bandwidth and the right number of peers.

A few things worth mentioning, any of our SpeedFUsion enabled Balance devices can be in either a hub or client role (or indeed both), so in the future the customer could take an installed Balance in the HQ, replace it for a larger one and then use the old one at a remote site as a client device.
Customers can add our gear and create a SpeedFusion only segment that they can add to their WAN. We see customers test our devices with two or three sites with the HQ balance installed alongside their exisitng MPLS network, then add more locations as they gain confidence in the technology and do this alongside their exisitng MPLS networks. We also have customers who are very happy with their MPLS network and don’t want to make any changes to it who only use us for more challenging locations (like cellular bonding in vehicles or rapid deployment to temporary locations like portakabins or short term warehouses). There are lots of ways you can get our devices into a customer environment for them to test that will add value to them, so think about that too.

Have a good read of this case study from Pluss http://www.peplink.com/solutions/case-studies/pluss/ the technical deep dive document explains how they deployed our devices into their MPLS network with some useful diagrams. There is also a link on the page to a video demo showing our value add to VoIP services between sites too using our unbreakable VPN. We have more case studies on our MPLS alternative page too here http://www.peplink.com/solutions/mpls-leased-line-alternative/

1 Like

As far as best practices go my main recommmendation would be to do a staged deployment. Use our devices for one or two of their smaller sites initially as a proof of concept, this then allows you to discover any customer network challenges, and get real world customer usage information so that when you plan the migartion of the larger sites lots of the questions have already been answered.

It also gives the customer hands on experience of the devices and monitoring services Like InControl which can really help them see where our devices fit and how they can help improve their network, save costs and open opportunities for WAN extensions to places they might not have considered before (like Vehicles with the HD2 and HD4, M2M with the BR1, IP CCTV with the HD2 Mini, and even homeworkers using PepVPN on the Balance One).

1 Like

we are using peplink to replace cisco VPN concentrators

hi,

I already own a peplink balance 380

we have a data center with 2 isps upload speed 4&2mbps
and a firewall fortigate 90d with 3.5 Gbps throughput

my peplink 380 in saudi arabia and I want to basically maintain the current network in my data center,

get new isps

and connect a new peplink IN my lan (like a normal pc) and link to my data center through a speedfusion bonding

is this possible?

or am I forced to buy a bigger firewall

my goal is just to be able to just access my data
and these are my current specs
can a peplink model help me with my situation?

Hi,

It is possible based on your design. But please take note on the concerns below:-

  • Ensure routing is correct.
  • B380 only supports 60Mbps (with encryption) throughput for SpeedFusion. Please refer here for more details.
2 Likes

@kousoulides

So just to be clear. You don’t plan on using the existing fortigate connected ISPs for the Balance to Balance SF connection right (because of the fortigate appliance limitations and you don’t want to make changes to the existing network at the DC)? Instead the future balance will have its own (new) ISP connections?

If so then yes that will work fine. With the DC Balance LAN connected to the local switch fabric, and with new ISPs on its WAN you will be able to set up a pepVPN tunnel (with SpeedFusion) between the two Balance routers. The only thing to think about is how to make the existing DC LAN equipment aware of this new route to your remote LAN in SA.

Two options.
If you have management of the fortigate then you can simply add a static route for your remote SA LAN segment with the DC balance LAN IP as the gateway.
If you don’t have management access, then you can set the pepVPn profile on the DC balance to use NAT for the connection from SA. Local devices in the DC will only see connections coming from the new balance LAN IP and not your remote LAN segment so routing will work.

Hope that helps.

2 Likes

I am newbe for this forum, but i feel lucky after reading this thread.

We have a similar setup with 80 remove sites. About 30 have 3Mbps MPLS (bonded T1s). At the sites with the bonded T1s we have a router in place between our HD2 and the MPLS. HD2 has become unresponsive but the router is online and connected to the LAN. We’ve setup the Router to act at the default gateway until we can replace the HD2 or get it online again. The head end has a Balanced 1350. We can access the remote site from the head end but the remote site cannot access the Head end.
Trace route from remote site dies at the 1350.

It did require we setup an outbound policy in the 1350 to gain access the remote site from the head end.
I’ve been stumped all day on how to setup an “inbound policy” (that’s all I know to call it) to allow the remote site to get past the 1350 to the LAN.
Remote site can ping the LAN address of the 1350 but nothing past it.

Any help is greatly appreciated.

As in it was working but now isn’t or you have 80 sites and are trying to get something similar with a single B1350 and HD2 as a test?

Start a new thread. Dump a network diagram in it and we’ll work it out.

1 Like

Sorry I abandoned this thread, We replaced the Peplink and solved the root issue.
To answer your question Martin:
This was a stop gap measure to get the remote site working because the HD2 was down. We’ve used this option on previous setups before we deployed the Peplink solution and it worked fine.

Still not sure why strange that I was not able to route past the 1350