I.3) Bandwidth Planning and Provisioning for load-balancing features:
1. We will define four various traffic zones or classes of customers provided by ISP-A, for simplicity and modularity. These classes shall continue being a reference in the dry configurations included in this document.
2. Since the document aims to be a tutorial or a straightforward know-how on BGP basis, we will not debate about these zones traffic choices.
Let’s simply say the design wants to use each links efficiently with a medium average use of 65-70% of the capacity (keep always 30% for congestion period and saving-time for extension), in order not to lose revenue.
It is well-known that an ISP always wants to use its links at its maximum efficiency/rentability possibilities.
Let’s note that bad manipulation of controlling ingress traffic can provoke a loss of revenue additionally.
If traffic destined to a particular customer is coming not through the correct link but another one, additional bandwidth is used and by so provoking fees on the incorrect link, making the other link unused to its role of providing the customer. For more information, please check paragraph A.2.c).
3. Regarding the symmetrical routing process for a customer, we can notice that we are sending the ingress/egress or upload/download traffic for each customer’s zone exclusively through the same provider.
Rational people will inquire why we are complicating the design through this way.
The main reason is about congestions and locations of your network, your country/continent, and your provider’s POPs.
For instance, let’s conceive that customers of Zone-C (because of default bgp-configuration) have their ingress traffic routed through ISP-D, and egress traffic routed to ISP-B. If ISP-D’s POP is in Europe as well as ISP-B’s POP, there is no need to reroute the In/Out traffic through the same interface or ISP, since latencies are small between those two providers in Europe who exchange Internet traffic between them.
However, if ISP-D’s POP is in Middle-East or in Asia and ISP-B’s one in Europe, it makes the traffic to a big useless way out, which higher considerably the latencies between the In/Out traffic.
Strange reactions can appear during an application process which needs sensible rate synchronization.
For example, a gamer in a 2vs2 fighting game will hit its opponent with a delay input of 150ms, but will receive damage hits with a delay of 300ms. Banks application, voices and other e-government systems are commonly victim of these issues too. SLA will often ask a symmetrical delay input.
4. Regarding the definition of multihoming. Within an ISP, multihoming is a mechanism tool which allows us to configure one device network with more than one network interface and multiple IP addresses. It provides enhanced and reliable Internet provision without compromising efficient performance. In terms of advantages, the multiple simultaneous Internet connections make system failure less likely than with a system with a single Internet connection. Multihoming contribute to load-balancing and networks to work with the lowest downtime. It is very efficient for for network maintenance and management during disaster and recovery for the ISP and its customers.
The two main types of multihoming are IPV4 and IPV6. The document will focus only the IPV4 one. When any link or route fails, Inbound/Outbound traffic is automatically rerouted. IPv4’s major weakness is its central connection point (shared on transmission line and/or edge router) for at least two ISPs, which can result in failure of the entire network if the central point fails. The BGP will be used for these multihoming purposes.Below you will find the topology of the study case.
See below (plz click on the gallery to zoom in and full size, or go in media galerie):
Figure I.1: BGP & Static topology of ISP-A, regarding Internet transit connectivity and provisions.
Figure I.2 : Traffic Engineering targeted configuration for ISP-A