Nokia BGP Fundamentals for Services flashcards
Nokia BGP Fundamentals for Services · Build recall with a focused review session.
39 cards. Read the term and the definition here. The deck at the top of this page is optional.
- BGP transport port
- BGP runs over TCP port 179, providing reliable ordered delivery. BGP itself has no retransmission or sequencing and relies on TCP plus KEEPALIVE messages for liveness.
- BGP message types
- Four message types: OPEN (session parameters and capabilities), UPDATE (withdrawn routes, path attributes, NLRI), KEEPALIVE (19-byte header only), and NOTIFICATION (error code and subcode, then close).
- Well-known mandatory attributes
- ORIGIN, AS_PATH, and NEXT_HOP must appear in every UPDATE carrying reachability. Their absence triggers a NOTIFICATION with an Update Message Error, closing the session.
- AS_PATH loop detection
- A BGP speaker rejects any route whose AS_PATH already contains its own AS number. AS_SEQUENCE segments are ordered hops; AS_SET segments count as one hop for length.
- iBGP split-horizon rule
- A route learned from one iBGP peer is not re-advertised to another iBGP peer. This forces full mesh or route reflectors/confederations to distribute iBGP routes within an AS.
- ORIGIN attribute values
- ORIGIN is well-known mandatory: 0 = IGP (i), 1 = EGP (e), 2 = INCOMPLETE (?). Lower values are preferred during best-path selection, so IGP-originated routes beat redistributed ones.
- BGP state machine
- States: Idle, Connect, Active, OpenSent, OpenConfirm, Established. Stuck in Active usually means TCP connect failure; stuck in OpenSent or OpenConfirm indicates OPEN or capability mismatch.
- eBGP multihop and TTL
- eBGP defaults to TTL 1, requiring directly connected peers. Multihop eBGP needs ebgp-multihop and a route to the peer address; TTL security (GTSM) is often added.
- BGP hold time negotiation
- Each OPEN carries a hold time; the effective value is the lower of the two. KEEPALIVE is typically one-third of hold time. Hold time 0 disables keepalives entirely.
- BGP router ID
- A 32-bit BGP identifier, usually the highest loopback IPv4 address. Duplicate router IDs break route-reflector loop detection and ORIGINATOR_ID checks, so uniqueness matters.
- BGP authentication options
- TCP MD5 (RFC 2385) and TCP-AO (RFC 5925) authenticate BGP sessions at the TCP layer. Mismatched keys cause connection resets or Bad Peer AS notifications rather than BGP-level errors.
- iBGP versus eBGP next-hop
- eBGP-learned routes carry the eBGP peer address as NEXT_HOP. iBGP preserves that original next-hop, so the IGP must resolve it unless next-hop-self or a route reflector is used.
- LOCAL_PREF scope
- LOCAL_PREF is exchanged only between iBGP peers and never sent to eBGP neighbors. It expresses outbound preference within the local AS and is compared before AS_PATH length.
- MED scope and comparison
- MED is sent between eBGP peers as an inbound hint. By default it is compared only among paths from the same neighbor AS and is not propagated across AS boundaries.
- Weight attribute
- Weight is a Cisco-local value, default 0, never carried in any BGP message. It is the first best-path criterion and outranks LOCAL_PREF, so it is used for local route preference only.
- Best-path order summary
- Weight, LOCAL_PREF, locally originated, shortest AS_PATH, lowest ORIGIN, lowest MED, eBGP over iBGP, lowest IGP metric to next-hop, oldest eBGP path, lowest router ID, lowest neighbor address.
- BGP multipath ECMP
- bgp maximum-paths installs multiple equal paths when the first N best-path criteria tie. The IGP-cost criterion is skipped for multipath candidates, enabling ECMP across parallel links.
- AS-path prepending
- Prepending repeats the local AS number in AS_PATH to lengthen the path seen by neighbors. It influences inbound traffic selection because shorter AS_PATH is preferred earlier than MED.
- network versus redistribute
- A network statement originates a prefix only if a matching route exists in the routing table. Redistribute injects routes from other protocols. Both can be gated by route-maps.
- Prefix-list matching
- A prefix-list entry matches prefix and mask length; ge and le specify the allowed range. For example, permit 10.0.0.0/8 ge 16 le 24 matches subnets of 10/8 with masks 16 through 24.
- AS-path regex anchors
- In AS-path access-lists, ^$ matches locally originated routes, ^65001_ matches paths starting with 65001, and _65001_ matches 65001 anywhere in the path.
- Well-known communities
- NO_EXPORT (0xFFFFFF01) prevents advertisement outside the AS or confederation. NO_ADVERTISE (0xFFFFFF02) prevents advertisement to any peer. NO_PEER (0xFFFFFF04) blocks advertisement to peers.
- RPKI origin validation states
- A route is Valid if a ROA covers its prefix and origin AS, Invalid if a ROA covers the prefix but not the origin AS, and NotFound if no ROA exists. Invalid routes are usually dropped or deprioritized.
- Route reflector reflection rules
- An RR reflects client routes to other clients and non-clients, and non-client routes to clients only. Non-client to non-client is not reflected, preserving standard iBGP split-horizon behavior.
- ORIGINATOR_ID and CLUSTER_LIST
- The RR adds ORIGINATOR_ID (the originating router ID) and CLUSTER_LIST (cluster IDs traversed). A router seeing its own router ID or cluster ID in these attributes discards the route.
- Confederation AS_PATH handling
- Within a confederation, member-AS numbers are carried in AS_CONFED_SEQUENCE and not prepended to the public AS_PATH. They are stripped when the route leaves the confederation.
- Peer groups and templates
- Peer groups apply shared outbound policy to many neighbors, cutting configuration and UPDATE generation. Peer templates separate session parameters from policy and are inherited by neighbors.
- MP_REACH and MP_UNREACH
- MP-BGP carries non-IPv4-unicast families in MP_REACH_NLRI (attribute 14) and MP_UNREACH_NLRI (attribute 15). The AFI/SAFI pair identifies the address family and subsequent address family.
- AFI/SAFI pairs
- Common pairs: IPv4 unicast (1/1), IPv6 unicast (2/1), VPNv4 (1/128), VPNv6 (2/128), EVPN (25/70), labeled unicast (1/4). Both peers must negotiate the family in OPEN.
- Route Distinguisher and Target
- The RD (8 bytes) makes identical prefixes unique in VPNv4. The Route Target extended community controls VRF import and export, determining which VPN sites can reach each other.
- EVPN route types
- EVPN route types include Type 1 Ethernet Auto-Discovery, Type 2 MAC/IP Advertisement, Type 3 Inclusive Multicast, Type 4 Ethernet Segment, and Type 5 IP Prefix for inter-subnet routing.
- MRAI timer
- MinRouteAdvertisementInterval dampens UPDATE churn. Cisco defaults are 30 s for eBGP and 0 s for iBGP (5 s in some implementations), trading convergence speed for stability.
- BGP graceful restart
- Graceful restart (RFC 4724) uses a capability and End-of-RIB marker. The receiving peer keeps stale routes while the restarting peer rebuilds, provided forwarding state is preserved.
- BGP additional paths
- Add-path (RFC 7911) advertises multiple paths per prefix using path identifiers. It improves convergence and multipath availability without waiting for a best-path change.
- BGP next-hop tracking
- When the IGP route to a BGP next-hop disappears, the BGP route becomes invalid. BFD accelerates this detection to sub-second, triggering faster reconvergence or PIC repair.
- Max-prefix protection
- A per-neighbor maximum-prefix limit with a warning threshold and shutdown or restart action protects the RIB from a misbehaving peer flooding routes. It is standard on SP edge sessions.
- BGP NOTIFICATION codes
- 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 Administrative Shutdown or Reset.
- SP edge inbound filtering
- SP edge routers should filter customer announcements with prefix-lists tied to registered prefixes, plus max-prefix limits and RPKI validation, to block leaks and hijacks at the boundary.
- BGP session troubleshooting order
- Check session state first, then received and advertised prefix counts, then the specific prefix, then policy on both sides. Verify return path exists because asymmetric routing is normal.