Information Technology Reference
In-Depth Information
Outbound Traffic Load Balancing
Many more control options are available for balancing traffic outbound. This is because
there is the potential to accept more than 120,000 specific pieces of routing information, or
prefixes defining the remote destinations. When balancing inbound, only a few prefixes are
advertised. The granularity at which traffic can be manipulated is based on the number of
prefixes being used.
The simplest method of balancing traffic is to use default routes only. This provides an even
traffic balance; however, it creates a very high probability of suboptimal routing. If the
enterprise is multihomed to a single upstream provider, using default routes is quite likely
the simplest solution.
When the enterprise is multihomed to different upstream providers, more creativity is
required to obtain adequate load sharing. The simplest method is to request partial routes
from both upstream providers, which can be combined with static default routes to provide
full reachability. This in itself might provide acceptable load sharing, in addition to a
reasonable level of routing optimization.
If using provider-advertised partial routes in conjunction with default routes does not
provide adequate load sharing, the next step is to request full Internet tables from the
upstream providers. The enterprise should then perform inbound filtering to create its own
partial tables. The most effective form of filtering is AS_PATH filtering. Just make sure you
do not block the AS directly upstream, meaning your provider's AS. Also, use a default
route in conjunction with your specially created partial tables, or you might have only
partial connectivity!
A slight modification to this method is to lower the local preference on the nonpreferred
prefixes instead of filtering them. This shifts traffic to the higher-preference prefixes and
retains the backup paths that have lower preference. This method removes the need for the
presence of default routes to maintain reachability during a failure scenario.
Multiple Sessions to the Same Provider
When the enterprise connects to the upstream provider via BGP and uses multiple links for
additional bandwidth between the two routers, there is the potential for only one of those
links to be used. This scenario has multiple links between a single enterprise edge router
and a single provider edge router.
It is considered a best practice to tie eBGP sessions directly to physical interfaces. If a
single eBGP session is used, the next hop of the prefixes received is the IP address of that
interface on the provider router, and only that link is used. If that link fails, the eBGP
session is torn down, even though other links between the two routers might still be
operational.
