Nokia BGP for Internet Routing cheat sheet
Nokia BGP for Internet Routing · Keep the key ideas within reach.
BGP Fundamentals and Protocol Operation
BGP is a path-vector EGP running over TCP port 179; it carries reachability plus path attributes rather than link metrics, and loop prevention relies on AS_PATH (eBGP) and the cluster list/ORIGINATOR_ID (iBGP route reflection).
Four message types: OPEN (version, AS number, hold time, BGP identifier, optional parameters/capabilities), UPDATE (withdrawn routes, NLRI, path attributes), KEEPALIVE (19 bytes, header only, no body), NOTIFICATION (error code/subcode then session close).
UPDATE messages carry only one set of path attributes per NLRI group; identical attribute sets share an UPDATE, differing next-hop or MED forces separate UPDATEs.
eBGP default behavior: TTL 1 (GTSM-compatible multihop changes this), next hop rewritten to the advertising peer's address, AS_PATH prepended with the sender's AS, LOCAL_PREF not propagated.
iBGP rules: no AS_PATH prepend, next hop unchanged, split horizon prevents re-advertising an iBGP-learned route to another iBGP peer unless route reflection or confederation is used.
Well-known mandatory attributes: ORIGIN, AS_PATH, NEXT_HOP. Well-known discretionary: LOCAL_PREF, ATOMIC_AGGREGATE. Optional transitive: AGGREGATOR, COMMUNITY. Optional non-transitive: MED, ORIGINATOR_ID, CLUSTER_LIST.
ORIGIN values: IGP (0) < EGP (1) < INCOMPLETE (2); lower is preferred in best-path selection.
Hold time negotiates to the lower of the two peers' values; KEEPALIVE is sent at one-third of hold time, and hold time 0 disables keepalives entirely.
BGP Session Establishment and Neighbor Configuration
Session FSM states in order: Idle, Connect, Active, OpenSent, OpenConfirm, Established; Active means the router is listening/retrying TCP, not that the session is up.
OPEN collision handling: if both sides open simultaneously, the router with the higher BGP router ID (or higher AS in older rules) keeps its session; the other is closed.
eBGP requires directly connected peers by default (TTL 1); multihop eBGP needs explicit multihop configuration plus a route to the peer loopback and typically an update-source.
iBGP full mesh requirement: every iBGP speaker must peer with every other, or use route reflectors/confederations; a route learned from one iBGP peer is not forwarded to another.
Authentication options: TCP MD5 (RFC 2385) keyed per neighbor, or TCP-AO (RFC 5925) with key chains; mismatched keys cause OPEN failures and NOTIFICATION code 6 subcode 5/7.
Nokia SR OS: configure with 'configure router bgp neighbor peer-as ' and 'authentication-key'; enable families per neighbor with 'family ipv4/ipv6' and 'type internal/external'.
BGP identifier (router ID) must be unique and nonzero; Nokia SR OS derives it from 'configure router router-id' or the highest loopback address if unset.
Passive mode ('passive' in SR OS) prevents outbound connection attempts; useful for hub-and-spoke where only the hub initiates.
Route Selection and Best-Path Decision Process
Standard best-path order: highest LOCAL_PREF, then shortest AS_PATH, then lowest ORIGIN, then lowest MED (same neighbor AS by default), then eBGP over iBGP, then lowest IGP cost to next hop, then oldest route, then lowest router ID, then lowest peer address.
Nokia SR OS default tie-breakers follow the same order; 'best-path-selection' knobs (e.g., 'always-compare-med', 'ignore-router-id') change individual steps, so document deviations per node.
MED is only compared between paths from the same neighboring AS unless 'always-compare-med' is enabled; MED is non-transitive and not propagated beyond the receiving AS by default.
AS_PATH length counts AS numbers, not hops; AS_SET counts as one regardless of size, and confederation segments are excluded when comparing external paths.
Weight (Cisco-style) is not a standard BGP attribute; on Nokia SR OS use LOCAL_PREF or a route preference/tag to achieve the same local-first effect.
Multipath requires equal attributes up to the multipath step; configure 'maximum-ipv4-routes'/'multipath' with 'ebgp' or 'ibgp' to allow ECMP installation.
'AIGP' (RFC 7311) accumulates IGP metric across ASes and can be used as a tie-breaker before the IGP-cost step when enabled.
Route reflectors and confederations do not change the best-path algorithm; they only alter how routes are propagated within the AS.
BGP Attributes and Policy Control
LOCAL_PREF is iBGP-only; it is not sent to eBGP peers, and on receipt from an eBGP peer it is ignored. Default value is 100 on most implementations including Nokia SR OS.
AS_PATH prepend is the standard outbound tool to influence inbound traffic; prepending more copies of your AS makes the path longer and less preferred for remote ASes.
COMMUNITY is a 32-bit value written as AS:value; well-known communities: NO_EXPORT (0xFFFFFF01), NO_ADVERTISE (0xFFFFFF02), NO_PEER (0xFFFFFF04), and BLACKHOLE (65535:666) used for RTBH.
Extended communities (RFC 4360) are 64-bit and used for route targets, site-of-origin, and origin validation; they carry type, subtype, and value fields.
Policy structure in Nokia SR OS: 'policy-options policy-statement entry from to ' with default-action accept/reject; entries are evaluated in ascending order and the first match wins.
Match conditions include prefix-list, community, as-path, protocol, neighbor, and next-hop; actions include accept, reject, next-entry, community add/remove/replace, as-path prepend, local-preference, and metric.
Damping uses a penalty system (RFC 2439): each flap adds a penalty, suppressed above the suppress threshold, reused when penalty decays below the reuse threshold; not recommended for modern stable links.
Aggregation with 'aggregate' and 'summary-only' suppresses more-specifics; the ATOMIC_AGGREGATE and AGGREGATOR attributes mark the resulting route.
Scaling and Convergence (Route Reflectors, Confederations, Timers)
Route reflector rules: routes from a client are reflected to all other clients and non-clients; routes from a non-client are reflected only to clients and other non-clients (never back to the originator).
ORIGINATOR_ID carries the router ID of the route's originator and prevents loops; CLUSTER_LIST is a list of cluster IDs and is checked like AS_PATH.
Confederation design: sub-AS numbers (private AS range 64512-65534 typically) form a confederation; external peers see only the confederation identifier as the AS number, and AS_PATH_CONFED segments are used internally.
Timers: default keepalive 60s / hold 180s (3:1 ratio); faster convergence on LAN peers can use 3/9 or 10/30; timer tuning should respect CPU and link stability.
BGP graceful restart (RFC 4724) preserves forwarding during control-plane restart; it requires capability negotiation and a restart time advertised in the OPEN.
BGP add-path (RFC 7911) allows advertising multiple paths per prefix; Nokia SR OS enables via 'add-paths ipv4 send/receive' on the neighbor.
Route reflector clusters should be designed so that clients peer only with RRs; a client peering with two RRs in the same cluster still receives one copy per prefix due to ORIGINATOR_ID/CLUSTER_LIST checks.
'next-hop-self' on an RR or border router ensures iBGP peers can resolve the next hop in their own IGP; without it, routes may be unusable at the receiver.
Internet Multihoming and Traffic Engineering
Single-homed vs multihomed: multihoming to two ISPs provides redundancy but requires provider-independent address space or NAT to avoid renumbering.
Inbound TE levers: AS_PATH prepend, MED (only effective between the same ISP), community-based ISP traffic engineering (each ISP publishes its own community scheme), and more-specific prefix announcements.
Outbound TE levers: LOCAL_PREF (highest wins), IGP metric to next hop, and route maps matching on communities or AS_PATH.
BGP communities are the standard way ISPs accept customer TE requests; the customer tags the route and the ISP's inbound policy interprets the tag.
RTBH (RFC 3882/5635): a host route /32 (or /128) with community 65535:666 is blackholed by the ISP; the trigger is usually an iBGP route injected by the customer's edge.
Traffic engineering with BGP-LS or PCEP is out of scope for pure BGP; pure BGP TE relies on attributes and prefix engineering only.
Multihoming with the same ISP but different PoPs can use MED to bias inbound; with different ISPs MED is not comparable, so use prepending or communities.
Anycast uses the same prefix announced from multiple sites; BGP picks the closest exit per receiver, and the origin AS should be consistent to avoid path-length surprises.
BGP Security and Route Filtering
RPKI/ROA validation: origin AS in the route is compared to the ROA; result is Valid, Invalid, or NotFound. Invalid routes should be dropped by 'validation' policy in SR OS.
Nokia SR OS: 'configure router bgp origin-validation' enables RPKI; use 'policy-statement ... from validation invalid' to reject, and 'valid' to prefer.
Prefix filters: always apply inbound prefix-lists on eBGP peers to prevent leaks; bogon and martian filters (RFC 1918, 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/4, etc.) are baseline.
AS_PATH filtering: reject paths containing your own AS (loop prevention), private AS numbers (64512-65534) from external peers, and unexpected first-AS values (peer's AS).
Maximum-prefix limits protect against session-wide overload: set a limit with a warning threshold and optionally 'shutdown' or 'idle-timeout' behavior.
GTSM (RFC 5082) checks TTL on BGP packets to protect against spoofed sessions; set TTL to 255 on both ends and verify the hop count.
TCP MD5 / TCP-AO protect against session hijacking; they do not protect against route leaks from a legitimate peer, which requires prefix and AS-path policy.
Route leak detection: monitor for unexpected AS_PATH lengths and sudden prefix count changes; IRR-based filters and RPKI reduce but do not eliminate leaks.
IPv6 and Address-Family Support in BGP
MP-BGP (RFC 4760) carries IPv6 NLRI via the MP_REACH_NLRI and MP_UNREACH_NLRI attributes; AFI 2, SAFI 1 for unicast IPv6.
Nokia SR OS: enable per-neighbor with 'family ipv6' (and 'family ipv4' for v4); both families can share one TCP session or use separate sessions.
IPv6 next hop is carried in MP_REACH_NLRI, not in the legacy NEXT_HOP attribute; for eBGP it is the peer's global or link-local address depending on configuration.
Link-local next hop requires the receiving router to have an interface on the same link; in iBGP, next-hop-self or an explicit next-hop is needed for global reachability.
AS_PATH, LOCAL_PREF, MED, and communities work identically for IPv6; policy structures match on 'family ipv6' or prefix-list ipv6.
IPv6 prefix filters use prefix-list ipv6 with lengths up to /128; bogon filtering includes ::/8, 2001:db8::/32 (documentation), and fc00::/7 (ULA).
Dual-stack peers can use a single BGP session with both families enabled, or separate sessions per family; the choice affects convergence and policy granularity.
RPKI ROAs for IPv6 use the same validation logic; ensure the ROA prefix length and origin AS match the announced /32 or /48.
Nokia SR OS BGP Implementation and Troubleshooting
Key show commands: 'show router bgp summary', 'show router bgp neighbor ', 'show router bgp routes detail', and 'show router bgp routes hunt' to see all candidate paths and the selected best path.
'show router bgp neighbor detail' shows negotiated capabilities, hold time, message counters, and last error/notification - the first stop for session issues.
'show router bgp routes detail' prints per-path attributes and the reason a path was not selected; use it to verify LOCAL_PREF, AS_PATH, and MED behavior.
'monitor router bgp neighbor ' streams updates in real time; useful for verifying policy changes without waiting for a full table refresh.
'clear router bgp neighbor soft' (or 'soft-reconfig inbound') re-applies policy without tearing down the session; requires 'soft-reconfig' or route-refresh capability.
'admin save' and 'admin display-config' persist and display configuration; 'compare' shows differences between candidate and running config before commit.
Common failure causes: AS mismatch (NOTIFICATION code 2 subcode 2), hold-time mismatch, missing route to peer, TCP MD5 mismatch (code 6 subcode 5), and capability mismatch.
Logs: 'show log log-id ' or 'show log application' surfaces BGP state changes and NOTIFICATION reasons; correlate with neighbor detail output.