BGP: study hub

Border Gateway Protocol carries reachability between autonomous systems — what the public internet runs on. It is not on the CCNA 200-301 blueprint: eBGP peering and best-path selection sit in CCNP ENCOR, the heavier policy work in ENARSI, and Cisco revises blueprints, so confirm current scope on Cisco's exam page. BGP discovers nothing: you name every peer by address and AS number, the session runs over TCP port 179, and each router advertises one best path per prefix with the attributes describing it. Administrative distance is 20 for eBGP and 200 for iBGP, so an external BGP route outranks OSPF's 110 and an internal one does not.

Everything starts with a session reaching Established. neighbor 10.0.13.2 remote-as 65002 is the whole definition: a different AS number makes the session external, the same one makes it internal, and eBGP sends packets with a TTL of 1, so the peer must be directly connected unless you add ebgp-multihop. Idle and Active both mean down: Idle usually means no route to the neighbor address, Active a TCP connection that keeps failing while BGP retries. A wrong remote-as never settles into a state you can read — it fails during the OPEN exchange and is recorded as the last reset reason.

A session that is up advertises nothing on its own. network 172.16.1.0 mask 255.255.255.0 is a condition, not an injection: originate that prefix only if the routing table already holds that exact network and mask. A /24 in the table against a /16 in the statement produces silence, not an error. The alternatives differ: redistribute takes what the IGP or a static route already holds and marks the origin incomplete; aggregate-address advertises a summary built from more specific prefixes already in the BGP table.

Inside one AS, two rules catch people out. A route learned from one iBGP peer is never re-advertised to another, so every iBGP speaker has to hear a prefix directly — classically a full mesh, with route reflectors as the ENARSI answer. And a prefix learned over eBGP keeps its external next hop when it crosses to an iBGP peer, so the far router holds a path whose next hop it cannot reach, and BGP marks it inaccessible rather than selecting it. next-hop-self rewrites the next hop, and update-source Loopback0 peers over loopbacks the IGP already carries.

BGP picks exactly one best path per prefix, comparing candidates step by step and stopping at the first difference; a path whose next hop is unreachable never enters the comparison. Weight comes first: highest wins, 0 on learned paths and 32768 on those this router originates, and it is never advertised. Local preference is next: highest wins, default 100, and it travels to every iBGP peer, so it is how a whole AS agrees on an exit. Then locally originated paths, the shortest AS path, the origin code and the lowest MED. To steer traffic coming back, you lengthen the path with set as-path prepend, which the neighbor AS may ignore.

Policy is applied per neighbor and per direction, which decides whether a filter does anything. A prefix-list matches a network and mask, with ge and le opening the mask into a range, and ends in an implicit deny; an AS-path access-list matches the path itself with a regular expression, where ^$ matches an empty path: a route originated inside your own AS. Nothing takes effect until you refresh the peer in the direction you changed: clear ip bgp <ip> soft in for inbound policy, clear ip bgp <ip> soft out for outbound. Work the guides in order, keep the BGP Commands Cheat Sheet open for syntax, and let the graded labs say whether the policy you wrote is the one the router applied.