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

Nokia BGP Fundamentals for Services: Route Advertisement, Filtering, and Policy

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

All guide sections

Route Advertisement, Filtering, and Policy

This domain tests what a router is allowed to originate or re-advertise, and how SR OS policy statements filter and modify it in both directions.

What gets advertised

  • network statements originate a prefix only when an exact-match route exists in the route table.
  • Redistribution pulls in connected/static/IGP routes, with ORIGIN incomplete.
  • aggregate with summary-only suppresses the more-specific components.
  • BGP-learned routes follow split-horizon rules: an iBGP-learned route is not sent to another iBGP peer (unless via route reflection), and an eBGP-learned route is not normally re-advertised to another eBGP peer. SR OS provides advertise-external to permit eBGP-to-eBGP re-advertisement, but using it in a normal SP design usually indicates a policy mistake.

Policy framework in SR OS

configure router policy-options defines prefix-list, as-path expressions, community lists and policy-statement objects made of numbered entries with from/to match criteria and actions. Evaluation is first-match-wins from the lowest entry number; a policy statement's implicit default action is reject unless default-action accept is set. Policies attach at bgp, group or neighbor level as import (affects the RIB and best-path) or export (affects what is sent).

Worked example

A customer export policy: entry 10 matches prefix-list CUST-OUT and accepts, entry 20 matches community 65000:666 and rejects, with no default action configured. A prefix in CUST-OUT that carries 65000:666 is rejected by entry 20 only if entry 10 does not match first; because entry 10 accepts on prefix alone, the community entry never runs. Reversing the entry numbers - or adding the community check inside entry 10 - produces the intended blackhole behaviour.

Filtering discipline

Every eBGP edge should apply inbound prefix-lists (customer allocations plus bogon/own-prefix denial), AS_PATH filters, prefix-limit with a warning threshold, and RPKI origin-validation where available. Outbound, deny your own space to customers and tag no-export where required.

Traps

  • Expecting a network statement to advertise a less-specific covering route.
  • Forgetting policy entry order and the implicit reject default.
  • Applying export policy at neighbour level and accidentally overriding the group's richer filter.