Prior to getting deeper into the involution and convolutions of BGP load balancing, we might as well get into the heart of the protocol known as BGP, which is a standardized gateway protocol that has been designed to exchange routing (as well as accessibility) information among autonomous systems on the Internet.
The protocol, incidentally, is sometimes categorized as path vector protocol, as also distance-vector routing protocol. The BGP or Border Gateway Protocol creates routing decisions based on network policies, paths, or rule-sets configured by any network administrator and are engrossed in making core routing decisions.
Border Gateway Protocol or BGP, to be precise, does not load balance, since (by default) it selects only a solo best path, while the reason that it does not load balance since it is an application and not a routing protocol. As for the sake of arguments, routing protocols such as RIP, EIGRP, IGRP, OSPF are capable of distributing the outgoing/ incoming traffic among multiple path.
Also, BGP is an attribute of the routing table negative to the interface, based on what you assign to your IGP is what could be promoted into BGP. True, BGP uses port 179 for transport, while OPSF uses port 89 and EIGRP 88 etc., but who does the routing lookup for the next hop destination – that is IGP not BGP. IGP will manage most load balance automatically but in the BGP scenario, it is done manually in order to allow multipath eBGP with the number of paths to install using the maximum-path which means that the next hop address for each path must also be different in order for that path to be taken into account. Therefore, unless you have your own “AS” on the internet BGP load balance is not suited for your network as because what happens when you have two different ISP?
However, mid-sized ISPs that have tried to implement BGP load balancing as a means to multi-home two or more gateways will concur about the technical difficulties involved in setting up BGP. Configuring the optimum route announcements to other BGP peers to achieve a balanced traffic flow is equally difficult. Especially load balancing inbound traffic to a multi-homed network over several inbound paths becomes positively challenging because of the limitations of the BGP route selection process. Fundamentally, BGP load balancing requires the network administrator to divide a large IP address block into smaller blocks and tweak the route announcement to spread the blocks so that they look optimal on the different routes, as otherwise the external networks may all pick a specific route and create congestion on that one specific route, creating chaos.
As by now, you must have already assumed that BGP load balancing is not suited for your network unless you have your own Autonomous Systems (AS) on the Internet. Apart from the difficulty of the BGP configuration and the difficulty in setting up the correct segregation of network blocks, maintaining a correct balance on the traffic is tricky too. What’s more, the granularity of the load balancing is very crude.
Therefore, what is the best alternative if you are a mid-sized ISP or a mid-sized enterprise with couple of hundred branch locations scheduling to implement load balancing? WAN Orchestrator devices, such as Broadband Bonding routers take a different approach to the multi-homing of WAN connections. When the load balancing decisions are pushed to the higher OSI layers (higher than the IP layer), you no longer are confined with the restrictions and complications of IP routing and difficulties associated with route convergence. Agreed, that the higher layer approach still needs to comply with the IP routing standards, but that is achievable via overlay networks such as WAN Virtualization and Broadband Bonding. Similar to VPN overlays on IP networks, load balancing can be engineered to facilitate packet level routing decisions and therefore can achieve aggregation at a much finer granularity.