I85PREP
⌘ K
Nokia BGP Fundamentals for Services study materials
Nokia BGP Fundamentals for Services study resources

Nokia BGP Fundamentals for Services: BGP Sessions, Peering Types, and Transport

Nokia BGP Fundamentals for Services · Work through your exam, one topic at a time.

All guide sections

BGP Sessions, Peering Types, and Transport

This domain covers how the TCP session is built and protected, and how the peering type (eBGP transit/customer/peer, iBGP internal) changes transport rules and attribute handling.

Session transport rules

  • TCP 179, one session per peer, sourced from an address you choose with local-address (typically the system/loopback interface).
  • eBGP defaults to TTL 1, so loopback-to-loopback eBGP requires multihop <ttl> plus an IGP route to the peer address. iBGP uses TTL 255 and needs no multihop.
  • Protection options: authentication-key (TCP MD5, stored with hash/hash2), TCP-AO where supported, and ttl-security (GTSM), which drops packets whose TTL is lower than expected and blocks off-path spoofing.
  • passive stops active open attempts; both sides passive means the session never forms.
  • Hold time is negotiated to the lower of the two values; keepalive is one third of it. Hold time 0 disables both, leaving dead-peer detection to BFD.
  • Capabilities exchanged in OPEN decide what can be carried: address families, route refresh, graceful restart, add-paths.

Peering types

Transit (default route plus full table), customer (partial routes, strict inbound filters), settlement-free peer (customer or own prefixes only), and iBGP internal peers (full mesh, route reflector client, or confederation member). eBGP peers normally rewrite NEXT_HOP to themselves; iBGP peers leave it unchanged, which is why edge routers need next-hop-self toward iBGP.

Worked example

Two PEs peer iBGP between loopbacks 10.0.0.1 and 10.0.0.4 in AS 65000. Configure neighbor 10.0.0.4 with peer-as 65000 and local-address 10.0.0.1; no multihop is needed because iBGP uses TTL 255. If the same design were eBGP across the core, omitting multihop 2 (or more) leaves the session stuck in Active forever, since the SYN expires after one hop.

Traps

  • Forgetting local-address, so the session sources from a link address and flaps whenever that link does.
  • peer-as mismatch: session reaches OpenSent then sends a NOTIFICATION - not a TCP failure.
  • MD5 key mismatch looks like silent connect timeouts, not an authentication error message.