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

Nokia BGP Fundamentals for Services: Service Provider BGP Design and Troubleshooting

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

All guide sections

Service Provider BGP Design and Troubleshooting

This domain tests the design decisions that make a provider network predictable and the ordered method for finding why a session or prefix is broken.

Design baseline

  • Separate route reflectors per address family or service, placed in the core, with clients only on PEs.
  • PE-CE eBGP with inbound prefix-lists, AS_PATH filters, prefix-limit (with a warning threshold and optional log-only), and origin-validation where RPKI is deployed.
  • ASBRs apply next-hop-self toward iBGP peers so PE next hops are reachable across the core.
  • eBGP protection: MD5 or TCP-AO plus ttl-security, BFD for fast detection, and local-as during acquisitions so the old AS number survives the cutover.
  • RTBH via a well-known community for DDoS scrubbing, and consistent community tagging for customer/peer/transit classes.

Troubleshooting order

Work bottom-up: physical and IGP reachability, then TCP 179, then the BGP state machine, then negotiated capabilities, then policy and RIB. State meanings: Idle/Connect/Active indicate a transport or reachability problem (TTL, ACL, no route); OpenSent/OpenConfirm indicate a protocol mismatch (peer-as, router ID conflict, capability); Established with missing routes indicates family mismatch, policy rejection, next-hop reachability or best-path loss.

Useful commands: show router bgp summary (state and up/down time), show router bgp neighbor <ip> (negotiated capabilities, timers, families, counters), show router bgp neighbor <ip> received-routes (pre-policy) versus show router bgp routes <prefix> (post-policy, with best/invalid flags).

Worked example

A customer session is Established but the router shows zero prefixes received. First check negotiated families in show router bgp neighbor: if the customer sends IPv6 and only ipv4 is enabled locally, nothing arrives. If families match, compare received-routes with routes: entries present in the first and absent in the second mean an import policy is rejecting them. If both show the prefix but it is not best, the cause is path selection, not peering.

Traps

  • Treating Established as healthy; family negotiation and policy both fail silently afterwards.
  • Overlooking a prefix-limit shutdown, which can idle a peer that was working yesterday.
  • Assuming inbound and outbound policies mirror each other when only one side was updated.