Checking for optimal egress points in iBGP routing

Abstract

The Border Gateway Protocol (BGP) is used today by routers of all Autonomous Systems (AS) in the Internet. BGP is responsible for end-to-end reachability in the Internet. BGP routers have to exchange routes towards about 200,000 prefixes (blocks of IP addresses). Inside each AS, routers are using internal iBGP sessions to exchange their best route with other routers. The objective of an iBGP topology is to redistribute BGP routes inside the whole AS. In large ASs, some BGP routers are used as route reflectors because it reduces the total number of sessions needed for this route redistribution. Checking the correctness of iBGP configuration [1] and detecting potential problems inside the iBGP [2] are particularly difficult when route reflection [3] is used. The scalability of route reflection compared to an iBGP full-mesh comes at the cost of opacity in the choice of the best routes by the routers inside the AS. This opacity induces problems like suboptimal route choices in the IGP cost, deflection and forwarding loops. We propose to check for the optimality of the routes choice in a route reflection graph. We do so without requiring to simulate the complex operations of the BGP protocol. Our check procedure is applied to a tier-1 AS. Our simulations show that a significant fraction of suboptimal path choices may occur, between 10 and 30% in realistic cases.

Impact of routing parameters on route diversity and path inflation

“…Nevertheless, we find that 70% of all route decisions in defaultSetup are reached based on other steps of the BGP decision process than local-preference and shortest AS path, confirming previous findings [6,33]. To investigate, we now compare defaultSetup against a simulation where we replace the route reflector hierarchies inside large domains with a full mesh (factor iBGP) and another simulation where we assign IGP weights randomly rather than applying geographicaware weights (factor IGP), see Table 2.…”

Designing Optimal iBGP Route-Reflection Topologies

“…To guarantee that only valid iBGP paths can be built, we use the graph transformation introduced in [5]. We transform each vertex of V bgp into a meta-node composed of two nodes (called source-node and target-node) and an arc (called internal arc) according to Figure 2.…”

“…Ideally, the network should converge to the same final state as in a full-mesh. Such a topology is said to be fm-optimal [5].…”

“…2. The best routes are selected according to the hot-potato routing steps of the BGP decision process: "prefer a route learned by eBGP over a route learned by iBGP", and "prefer a route with a closest BGP next-hop" (see [5]). …”

Humpty Dumpty: Putting iBGP Back Together Again

“…The network solution, that is, the decision of all routers in the network for a particular destination, is dependent on the subset of AS-wide routes which are learned at each individual router. Hence, it is not valid to assume all AS-wide routes are learned at each router for selection [5]. The iBGP configuration employed, such as full mesh or route-reflection [6], determines whether all routes or a subset of routes are available at every router.…”