3.6eBGP and policy-based routing

BGP thinks differently from an IGP. Where an IGP aims to compute the shortest path, BGP exists to express organizational policy—which ISP to prefer, which traffic goes where—through route attributes. Troubleshooting BGP is therefore not about "why was a non-shortest path chosen" but about tracing which step of the best-path selection algorithm settled the decision. This section ties that ordering to real intent (are you controlling inbound or outbound traffic) and then covers PBR for requirements BGP cannot express.

3.6.1Establishing an eBGP session

• BGP runs over TCP port 179 and does not auto-discover peers—you specify them explicitly with neighbor <ip> remote-as <as>. A different AS number makes it eBGP (AD 20) and the same AS number makes it iBGP (AD 200). As the AD implies, eBGP routes are preferred over IGP routes (lower than OSPF 110 or EIGRP 90).
• eBGP assumes directly connected peers by default and sends packets with TTL 1. Peering between loopbacks therefore requires both neighbor <ip> ebgp-multihop 2 and neighbor <ip> update-source Loopback0 (the first extends TTL, the second makes the source address match what the peer expects). With only one of them the session stays stuck in Active.
• Read session state from show ip bgp summary. Persistent Idle points to unreachability of the peer IP or a wrong AS number; repeated Active points to TCP 179 being unreachable (an ACL or firewall block, or an update-source inconsistency); Established is healthy and makes PfxRcd (prefixes received) meaningful. The rule is: when routes are missing, first confirm the session is up.

3.6.2The best-path selection algorithm

• As a prerequisite, a route whose next hop is unreachable is not even a candidate (no > in show ip bgp). Skipping this check and endlessly tweaking attributes is the most common detour. Only when multiple candidates exist does the following comparison run, top down, until one wins.
• The order is (1) highest weight (Cisco-specific, effective only on that router and never propagated), (2) highest LOCAL_PREF (propagated AS-wide to unify outbound exit selection), (3) locally originated routes, (4) shortest AS_PATH, (5) best ORIGIN (IGP < EGP < incomplete), (6) lowest MED (signals a preferred entry point to the neighboring AS), (7) eBGP over iBGP, (8) lowest IGP metric to the next hop, and thereafter the older eBGP route, lower router ID, and so on.
• The practical core is that the direction you want to control determines which attribute to use. Outbound (how traffic leaves your AS) is yours to decide, so LOCAL_PREF is the first choice (or weight for a single router). Inbound (how traffic enters from the peer AS) is the peer's decision, so all you can do is indirect influence: AS_PATH prepend to make your route look longer, or MED to state a preference (which the peer is not obliged to honor).

3.6.3PBR (policy-based routing)

• Normal routing decides forwarding by destination address alone. PBR overrides that, letting you forward based on source address, protocol, port, packet length, and more. It answers requirements that cannot be expressed by destination, such as "send only traffic from the accounting subnet over the dedicated encrypted circuit" or "put only backup traffic on the cheap link."
• It is built with a route map: select traffic with match ip address <ACL> and set the forwarding target with set ip next-hop <ip> (or set interface). Apply it with ip policy route-map <name> on the ingress interface where the packets arrive (not the egress side—a frequent mistake). To apply it to packets the router itself originates, use ip local policy route-map <name>.
• A route map is evaluated top down and settled by the first matching entry. It also ends with an implicit deny, but in PBR "denied (not matched)" means falling back to normal routing, not dropping the packet. To fall back to normal routing when the specified next hop goes down, combine it with set ip next-hop verify-availability.

Suppose your organization is multihomed to two ISPs (ISP-A and ISP-B) over eBGP. The requirement: "prefer the higher-bandwidth ISP-A for outbound traffic, falling over to ISP-B only when ISP-A fails." Yet show ip bgp shows paths via ISP-B chosen as best (>) for many destinations. Thinking "let me lower the interface cost toward ISP-A" is an error of importing IGP thinking: in BGP best-path selection the IGP metric matters only once you have descended to step eight. Checking attributes with show ip bgp <prefix> reveals weight 0 on both, LOCAL_PREF at the default 100 on both, neither locally originated, and a shorter AS_PATH via ISP-B—so the decision was settled at step four. Since the requirement is to prefer ISP-A, you must settle the decision at a step above AS_PATH, and LOCAL_PREF is the right tool. Applying set local-preference 200 via a route map to routes received from ISP-A makes them win at step two against the default 100 via ISP-B, so ISP-A is chosen regardless of AS_PATH length. Using weight is possible, but weight is effective only on that one router and is never propagated within the AS, so with multiple border routers it becomes a partial solution in which exit decisions vary per router. LOCAL_PREF unifies the choice AS-wide and is the appropriate fit here. Next comes an added requirement: "pull inbound traffic toward us over ISP-A as well." Touching LOCAL_PREF accomplishes nothing here, because the peer AS makes the inbound path decision. All you can do is AS_PATH prepend your own AS several times on the routes advertised to ISP-B to deliberately look longer, or signal preference with MED—both merely indirect influence that the peer's policy may ignore. Finally comes: "traffic from the accounting subnet must traverse a dedicated audited circuit regardless of destination." That cannot be expressed by destination-based routing or by BGP attributes, so PBR is the answer. Build an ACL matching the accounting subnet as source, match ip address it in a route map, set ip next-hop to the dedicated circuit, and apply ip policy route-map on the ingress interface where accounting traffic arrives. Applying it to the egress interface is the classic misconfiguration, and in that case PBR does nothing at all.

3.6.4Section summary

• eBGP runs on TCP 179 with AD 20, beating IGPs; loopback peering needs both ebgp-multihop and update-source
• Best path goes weight -> LOCAL_PREF -> locally originated -> AS_PATH -> ORIGIN -> MED -> eBGP over iBGP -> IGP metric, with next-hop reachability as the prerequisite
• Outbound uses LOCAL_PREF (AS-wide) or weight (one router), while inbound can only be influenced indirectly via AS_PATH prepend or MED; for non-destination criteria, apply PBR on the ingress interface