BGP MED Selection and Confederation Route Reflection
AS 65010 uses a BGP confederation with sub-AS 65001 (core) and 65002 (edge). Each sub-AS has one route reflector: RR1 in 65001, RR2 in 65002. R5 is a route-reflector client in 65002 and advertises 203.0.113.0/24 learned from two eBGP peers in AS 64500, one primary and one backup. Both paths have the same AS_PATH length and origin. The primary path has MED 50; the backup path has MED 10. R5 selects the backup path, and outbound traffic to 203.0.113.0/24 leaves through the smaller backup circuit. All routers use default BGP timers. RR1 and RR2 are not directly peered; they are connected through a non-client router R6 in 65001. The operations team wants deterministic primary/backup selection without increasing AS path length or using static routes, and it also needs R5's prefix to reach RR1's clients.
1. Why does R5 prefer the backup eBGP path, and what attribute change would make the primary path deterministic?
Read the worked answer
Both paths are from the same neighboring AS 64500, have the same AS_PATH length and origin, and R5 has no weight or local preference applied. BGP compares MED before eBGP-over-iBGP and IGP cost, and lower MED wins when the paths come from the same neighbor AS. The backup path has MED 10 versus 50 on the primary, so it is selected even though the circuit is smaller. To make the primary deterministic, influence an earlier attribute: set a higher local preference on the primary inbound route, for example 200 versus default 100, with a route-map, or set a higher weight on the primary. Local preference is the cleaner choice because it is propagated within the AS and is not MED-dependent. If you change MED instead, set the primary lower than the backup, but remember MED is only compared between paths from the same neighboring AS. Verify with show ip bgp 203.0.113.0/24 and show ip bgp best-path reason.
2. R5's prefix must reach RR1's clients. What is wrong with the route-reflector and confederation design, and what would you change?
Read the worked answer
Route reflection is per sub-AS. RR2 can reflect R5's route to its clients and to non-clients in 65002, but it does not automatically cross into 65001. A non-client such as R6 must be fully meshed with the RRs and other non-clients in its own sub-AS; it is not a substitute for a confederation peering between sub-ASs. To get the prefix into 65001, RR2 or a border router in 65002 needs a confederation eBGP session to RR1 or another 65001 border router, with bgp confederation identifier 65010 and bgp confederation peers 65001 65002 configured consistently. If RR1 is the entry point, RR1 then reflects the route to its clients. Also check next-hop reachability across the sub-AS boundary and use next-hop-self on the confederation session if the original next hop is not reachable in 65001. Avoid making R6 a transit non-client without a full iBGP mesh; that creates a split-horizon hole.