Nokia BGP Fundamentals for Services cheat sheet

BGP is a path-vector EGP running over TCP port 179; it exchanges reachability with full AS-path to detect loops and apply policy, not to compute a shortest path by metric.

Four message types: OPEN (version, AS, hold time, BGP identifier, optional parameters/capabilities), UPDATE (withdrawn routes, path attributes, NLRI), KEEPALIVE (19 bytes, no payload), NOTIFICATION (error code/subcode, then session close).

A message header is 19 bytes: 16-byte marker (all ones), 2-byte length (19-4096), 1-byte type. Maximum UPDATE size is 4096 bytes including header.

Path attributes fall into four classes: well-known mandatory (ORIGIN, AS_PATH, NEXT_HOP), well-known discretionary (LOCAL_PREF, ATOMIC_AGGREGATE), optional transitive (AGGREGATOR, COMMUNITIES), optional non-transitive (MED, ORIGINATOR_ID, CLUSTER_LIST).

Missing well-known mandatory attribute in an UPDATE triggers NOTIFICATION error code 3, subcode 1 (Malformed Attribute List) or subcode 3 (Missing Well-known Attribute).

AS_PATH is a sequence of AS_SEQUENCE and AS_SET segments; loop detection checks whether the local AS number already appears in the received AS_PATH.

ORIGIN values: 0 = IGP (i), 1 = EGP (e), 2 = INCOMPLETE (?); lower value is preferred in best-path selection.

iBGP peers must be fully meshed or use route reflectors/confederations because iBGP does not re-advertise a route learned from another iBGP peer to a third iBGP peer (split-horizon rule).

BGP runs over TCP/179; TCP provides ordered, reliable delivery, so BGP itself has no retransmission, no sequence numbers and relies on TCP keepalive plus BGP KEEPALIVE for liveness.

eBGP peers typically connect directly (TTL=1 by default); multihop eBGP requires ebgp-multihop and a route to the peer address, and is often combined with TTL security (GTSM).

iBGP neighbors need an IGP route to the peer loopback; eBGP neighbors usually use the directly connected interface address to avoid recursive next-hop dependence on the IGP.

A BGP session state machine: Idle, Connect, Active, OpenSent, OpenConfirm, Established. Stuck in Active usually means TCP connect failure (no route, ACL, wrong address); stuck in OpenSent/OpenConfirm indicates OPEN or capability mismatch.

Peer types: transit provider, customer, and lateral/private peer. iBGP is used inside one AS; eBGP between ASes. Route reflector and confederation are iBGP scaling variants.

Authentication options: TCP MD5 (RFC 2385) and TCP-AO (RFC 5925). Mismatch produces NOTIFICATION subcode 2 (Bad Peer AS) or connection reset with no BGP message.

Hold time is negotiated as the lower of the two OPEN hold times; KEEPALIVE interval is typically one-third of hold time. Hold time 0 disables keepalives (not recommended).

BGP identifier (router ID) is a 32-bit value, usually the highest loopback IPv4 address; duplicate router IDs break route-reflector loop detection and should be avoided.

Cisco-style best-path order: 1) highest Weight (local only), 2) highest LOCAL_PREF, 3) locally originated (network/redistribute/aggregate), 4) shortest AS_PATH, 5) lowest ORIGIN, 6) lowest MED (only among paths from the same neighbor AS by default), 7) eBGP over iBGP, 8) lowest IGP metric to NEXT_HOP, 9) oldest eBGP path (or lowest router ID with bgp bestpath compare-routerid), 10) lowest neighbor router ID, 11) lowest neighbor address.

LOCAL_PREF is exchanged only between iBGP peers; it is never sent to eBGP neighbors and is used for outbound preference within the local AS.

MED is exchanged between eBGP peers and is used as a hint to the neighboring AS for inbound traffic; by default it is not propagated across ASes, and only compared for paths from the same AS unless bgp always-compare-med is set.

Weight is a Cisco-specific value local to the router, default 0, and is preferred over LOCAL_PREF; it is not carried in any BGP message.

AS_PATH length counts AS_SEQUENCE hops; an AS_SET counts as 1 regardless of size. AS-path prepending lengthens the path to influence inbound selection.

The NEXT_HOP for eBGP-learned routes is the eBGP peer address; for iBGP routes it stays the original eBGP next-hop, so the IGP must resolve it (or use next-hop-self / a route reflector).

Multipath: bgp maximum-paths enables ECMP when the first N best-path criteria (up to the configured tie-break) are equal; the IGP cost criterion is skipped for multipath candidates.

A route is eligible only if it is valid (next-hop resolvable) and the best path is installed; a valid-but-not-best route stays in the Loc-RIB and is not advertised unless bgp advertise-best-external or add-path is used.

A route is advertised only if it is the best path AND permitted by outbound policy; inbound policy affects best-path selection, outbound policy only affects what is sent.

network statement originates a prefix only if a matching route exists in the routing table; redistribute injects routes from other protocols, and both can be gated by route-maps.

Prefix-lists match prefix and length (e.g., permit 10.0.0.0/8 ge 16 le 24 matches subnets of 10/8 with mask 16-24). Distribute-lists apply per-neighbor prefix filtering.

AS-path access-lists match via regex; ^$ matches locally originated routes, ^65001_ matches paths starting with 65001, 65001 matches 65001 anywhere.

Route-maps are ordered lists of match/set clauses; an implicit deny at the end drops unmatched routes. Use an explicit permit at the tail when you intend to allow the rest.

BGP communities (RFC 1997) are 32-bit attributes, standard format AS:value; well-known values NO_EXPORT (0xFFFFFF01), NO_ADVERTISE (0xFFFFFF02), NO_PEER (0xFFFFFF04) control propagation.

Large communities (RFC 8092) are 96-bit, three 32-bit fields (global:local1:local2), useful when the AS number is 4-byte or the operator wants more structure.

RPKI origin validation yields Valid, Invalid, or NotFound; invalid routes can be dropped or deprioritized via a route-map matching the validation state (e.g., set local-pref lower).

Default route origination: default-information originate injects 0.0.0.0/0 into BGP if a default exists in the RIB (or unconditionally with the always keyword).

A route reflector reflects iBGP routes from a client to other clients and non-clients; it does not reflect routes from a non-client to another non-client (standard iBGP rule still applies).

ORIGINATOR_ID and CLUSTER_LIST are loop-prevention attributes added by the RR; a router that sees its own router ID in ORIGINATOR_ID or its cluster ID in CLUSTER_LIST drops the route.

Cluster ID defaults to the RR's router ID; set a unique cluster-id per RR cluster. A route with a cluster ID already in CLUSTER_LIST is discarded, preventing reflector loops.

Multiple RRs in one cluster must share the same cluster-id so clients treat them as one cluster; redundancy is achieved by clients peering with both RRs.

Confederations divide one AS into sub-ASes (member-AS); eBGP-like rules apply between member-ASes, but AS_PATH is not prepended across member-ASes (AS_CONFED_SEQUENCE is used instead).

Confederation member-AS numbers are stripped from AS_PATH when the route leaves the confederation, so external peers see only the confederation's public AS.

Peer groups apply shared outbound policy to many neighbors, reducing configuration and UPDATE generation overhead; per-neighbor overrides can be applied on top.

Peer templates (session and policy templates) separate session parameters (timers, transport, authentication) from policy (route-maps, filters) and are inherited by neighbors.

Dynamic neighbors (bgp listen range) allow peering with a range of peers without per-neighbor configuration, useful for large-scale customer or data-center fabrics.

MP-BGP (RFC 4760) uses the MP_REACH_NLRI (attribute 14) and MP_UNREACH_NLRI (attribute 15) attributes to carry non-IPv4-unicast families; the AFI/SAFI pair identifies the family.

AFI/SAFI examples: IPv4 unicast (AFI 1, SAFI 1), IPv6 unicast (AFI 2, SAFI 1), VPNv4 (AFI 1, SAFI 128), VPNv6 (AFI 2, SAFI 128), EVPN (AFI 25, SAFI 70), labeled unicast (AFI 1, SAFI 4).

Capability negotiation happens in the OPEN message via the Multiprotocol Capability (code 1); a family is only exchanged if both peers advertise it, otherwise the NLRI is not sent.

VPNv4 routes carry an 8-byte Route Distinguisher (RD) and a 3-byte MPLS label; the RD makes otherwise identical prefixes unique, while the Route Target (extended community) controls import/export into VRFs.

Route Targets are extended communities (type 0x00 for 2-byte AS, 0x02 for 4-byte AS); a VRF imports routes whose RT matches its import list and exports with its export RT.

EVPN (RFC 7432) uses MP-BGP to distribute MAC/IP reachability; route types include Type 1 (Ethernet Auto-Discovery), Type 2 (MAC/IP Advertisement), Type 3 (Inclusive Multicast Ethernet Tag), Type 4 (Ethernet Segment), Type 5 (IP Prefix).

EVPN Type 2 routes carry a MAC, optional IP, an MPLS label or VNI, and an ESI; Type 5 carries an IP prefix and is used for inter-subnet routing in EVPN fabrics.

IPv6 next-hop handling: MP_REACH_NLRI carries a next-hop field whose length depends on AFI; for IPv6 it can be 16 or 32 bytes (global + link-local).

Default timers: KEEPALIVE 60 s, hold time 180 s (Cisco). The negotiated hold time is the lower of the two OPEN values; KEEPALIVE is typically one-third of hold time.

MinRouteAdvertisementInterval (MRAI): eBGP default 30 s, iBGP default 0 s on Cisco (5 s in some implementations). MRAI dampens UPDATE churn at the cost of convergence time.

BGP graceful restart (RFC 4724) uses the Graceful Restart capability and End-of-RIB marker; the receiving peer keeps stale routes while the restarting peer rebuilds, provided the forwarding state is preserved.

BGP additional paths (add-path, RFC 7911) advertises multiple paths per prefix using path identifiers, improving convergence and multipath availability without waiting for best-path changes.

BGP route dampening penalizes flapping routes with a figure-of-merit; it is largely deprecated because it can suppress legitimate prefixes for long periods.

BGP PIC (prefix-independent convergence) pre-installs a backup path so that failure of a primary next-hop triggers fast local repair without waiting for BGP reconvergence.

BGP next-hop tracking: when the IGP route to the next-hop disappears, the BGP route is invalidated; BFD can accelerate this detection to sub-second.

Long-lived graceful restart (LLGR) extends GR for long outages and is negotiated via a capability; it is used for provider edge routers that may be down for extended maintenance.

Typical SP design: iBGP full mesh or RRs inside the PoP, eBGP to customers and peers, and a separate address family (or session) for VPNv4/VPNv6 to carry L3VPN service.

Customer edge peering: static or eBGP with the customer; inbound filtering should allow only the customer's registered prefixes (prefix-list + max-prefix) to prevent leaks.

Max-prefix limits (with a warning threshold and shutdown or restart option) protect against a misbehaving peer flooding the RIB; combine with route dampening only when justified.

RPKI-based origin validation plus prefix filters is the standard defense against route leaks and hijacks; IRR-based filters are still common but depend on accurate registry data.

Troubleshooting order: check session state (show bgp summary), then received/advertised counts, then the specific prefix (show bgp ), then policy (route-maps, prefix-lists, distribute-lists) on both sides.

Common NOTIFICATION codes: 1 Message Header Error, 2 Open Message Error, 3 Update Message Error, 4 Hold Timer Expired, 5 Finite State Machine Error, 6 Cease (with subcodes such as 2 Administrative Shutdown, 4 Administrative Reset, 5 Connection Rejected).

Asymmetric routing is normal in BGP; verify with traceroute and check that return path exists. Missing return route is the most common cause of "BGP is up but traffic fails".

Logging and monitoring: enable bgp log-neighbor-changes, syslog for NOTIFICATION, SNMP traps for session down, and NetFlow/sFlow to confirm traffic actually follows the intended path.

Route reflection and confederation designs must be documented per PoP; a common failure is a client peering with only one RR and losing routes when that RR fails, so dual-RR peering is standard.