Network Next Hop Metric LocPrf Weight Path Origin codes: i - IGP, e - EGP, ? - incomplete Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
BGP FULL MESH INSTALL
R4 sends the best paths to R1 and R2 and those clients install best-paths with the next hop of R4: Rack1R2#show ip bgpīGP table version is 22, local router ID is 150.1.2.2 R4 and R6 exchange this information and every route-reflector prefers the directly connected exit point and advertises best path to its route-reflector clients.
Here is what happens:īB3 advertises AS54 prefixes to R4 and BB1 advertises the same set of prefixes to R6. Thus, the exit point that R1 and R2 consider optimal may not be optimal for R5. The problem here is that R5 receives external BGP prefixes from a different RR than R1 and R2 use.
At the same time, R1 and R2 peer with another RR, and R5 is on the forwarding path between R1, R2 and R4. Look at the topology below, where R5 peers with the RR that is not the one closest to it in terms of IGP metrics. Here is an example of what could happen in the situation where this rule is not observed. This also translates in the design principle where iBGP peering sessions closely follow the physical (geographical) topology. A known design rule used to avoid this is to place Route Reflectors along the packet forwarding paths between the RR clients in different clusters. This may result in inconsistent best-path selection by clients and end up in routing loops. However, using Route Reflectors (RRs) - a common solution to the full-mesh problem, will not result in the same behavior, as RRs only propagate best-paths to the clients, thus hiding the complete routing information from edge routers. This unavoidable loss of additional information may result in suboptimal routing or routing loops, as illustrated below.Īs mentioned above, a full mesh of BGP peering sessions eliminates intra-AS routing loops. Known solutions to this problem - Route Reflectors and BGP Confederations - prevent all BGP speakers from having full information on all potential AS exit points due to the best-path selection process. However, implementing full-mesh is not possible for a large number of BGP routers. Optimally, intra-AS routing loops could be prevented by ensuring a full mesh of BGP peering between all routers in the AS. In addition to that, BGP was designed for inter-AS loop detection based on the AS_PATH attribute and therefore cannot detect intra-AS routing loops.
For example, prepending the AS_PATH attribute may not result in proper global path manipulation if an upstream AS performs additional prepending. When those different policies come to interact, the resulting behavior might not be the same as expected by individual policy developers. The fact that BGP is mainly used for Inter-AS routing results in different routing policies used inside every AS. The main reason for this is the fact that BGP is a path-vector protocol, much like a distance-vector protocol with optimal route selection based on policies, rather than simple additive metrics. It may seem that BGP is a robust and stable protocol, however the way it was designed inherently presents some anomalies in optimal route selection.
BGP FULL MESH SERIES
In this series of posts, we are going to review some interesting topics illustrating unexpected behavior of the BGP routing protocol.
0 kommentar(er)
