Hosting and Over The Top Content providers, Enterprises and Public Organizations use more and more BGP (Border Gateway Protocol) multi-homing for the resilience and load balancing of WAN (Wide Area Network) and Internet connectivity .
Contrary to solutions using in-line, proprietary load balancers, BGP multi-homing exploits a well-known standard protocol (BGP) and does not require inserting expensive devices in between a site and its border routers.
However, BGP was mainly designed to guarantee the connectivity of the whole internet and is thus largely performance and cost unaware. Therefore, it often happens that BGP takes the “bad routing choice” either in terms of performance or transit costs.
BGP can sometimes take the “bad routing choice”, either in terms of performance (delay, jitter, packet loss) or ISP transit costs
NSI: smart BGP multi-homing
NSI (Non Stop Internet) overcomes the performance and transit cost unawareness of BGP multi-homing while keeping all the benefits of a standards based, offline and non-intrusive solution.
NSI requires a probe (GP-probe) in every BGP multi-homed site of a customer network. The GP-probe collects network configuration, traffic and routing information from the site’s BGP routers, using standard protocols: BGP, SNMP, NetFlow or sFlow. Based on this information, NSI automatically carries out active performance tests (Round Trip Delay, jitter, packet loss rate) to the destinations that matters more for the customer’s business. Performance tests do not require any configuration, because suitable responding targets in remote networks are automatically discovered. The test traffic is kept at a minimum level.
NSI overcomes the performance and transit cost unawareness of BGP multi-homing, while keeping all BGP’s benefits: a standards based, offline and non-intrusive solution
Results are continuously processed, and performance degradations due to non-optimal BGP routing are promptly detected and corrected by sending standard BGP commands to the site’s border routers.
Furthermore, NSI can also take into consideration the transit cost with each provider of a multi-homed site: the BGP traffic is thus balanced over multiple possible transits based on performance, traffic and cost considerations. For example, one transit can be preferred until an agreed CR (Committed Rate) and only beyond the CR level traffic is also routed via other providers.
Differently from inline load balancing solutions, NSI probes do not have to forward traffic and therefore can run on inexpensive hardware or Virtual Machines. NSI requires one GP-probe per each BGP site and one central server (GP-Server) per customer, running the optimization algorithms. A single GP-server can also serve multiple customers in multi-tenant mode if needed.
hosting provider: ISP transit cost control
A hosting provider had bought guaranteed CR from two transit ISPs. A 100 Mbit/s CR was bought from the expensive and well performing ISP1; another 80 Mbit/s was bought from the less expensive ISP2 for hosting excess traffic in peak times.
Unfortunately, despite the attempt to manually define routing policies, ISP1 was almost always the preferred transit, thus wasting the 80 Mbit/s bought from ISP2 and forcing the hosting provider to pay ISP1 for busting extra traffic in excess of the agreed 100 Mbit/s.
NSI was configured with the specific knowledge of the two ISPs contracts and their traffic-dependent order of preference. By sending standard BGP commands to the customer’s BGP routers made the traffic always stay below the contracted (and already paid) CR for both providers, using the cheaper but less performing ISP2 only when needed.
NSI could implement transit cost optimization policies that was impossible to control manually, due to the continuously changing traffic conditions
e-commerce site: performance control
A popular e-commerce site multi-homed to two transit providers was experiencing a lot of conversion rate variability, and interviews with real users established that one of the main factors discouraging them to finalise a purchase was the slow responsiveness of the site during certain times of the day.
A test deployment of NSI (without the automatic rerouting functionality enabled) showed that for a certain set of destinations BGP was always routing traffic through the same provider, although depending on the time of the day (and thus on traffic conditions) this was not always the optimal choice for the Round Trip Delay. The variation between BGP’s choice and the optimal choice was sometimes up to several tens of milliseconds. Furthermore, the CR on the transit ISP with the lower delay was heavily under-utilised.
After activating the automatic rerouting option of NSI the average Round Trip Delay for the affected destinations lowered, and the utilization of the already purchased CR for the affected transit ISP increased considerably.
The visible effect after the full deployment of NSI was the overall stabilization of the conversion rate of the e-commerce site.
NSI could implement an ISP transit cost optimization policy impossible to manually enforce due to highly fluctuating traffic
NSI could optimise performances for an e-commerce site by always choosing the best performing ISP transit