BGP Attributes and Policy Control
BGP Attributes and Policy Control
This domain tests the attributes you can manipulate and the SR OS route-policy mechanics used to set, match and propagate them.
Attributes worth knowing
LOCAL_PREF is a 32-bit value, higher is better, exchanged only between iBGP speakers - it is never sent to an eBGP peer. MED is optional nontransitive: it may be sent to an eBGP peer but is not propagated beyond that AS. AS_PATH is the loop-prevention and path-length attribute; prepending lengthens it. ORIGIN records how the route entered BGP. NEXT_HOP defines the forwarding address. ATOMIC_AGGREGATE and AGGREGATOR describe aggregation. COMMUNITIES (RFC 1997) tag routes for later matching; large communities (RFC 8092) carry three 32-bit fields and avoid the 16-bit ASN limitation.
SR OS policy structure
A policy-statement contains ordered entry blocks with from match clauses (protocol, prefix-list, community, as-path) and an action (accept or reject, plus set operations such as local-preference, metric for MED, as-path-prepend, community add). default-action decides anything unmatched. Policies attach as import or export under the group or neighbor.
Worked example
You want routes learned from a specific peer to be preferred inside your AS. On the import policy, match the neighbor's prefixes and action accept community add "preferred". Then a second policy statement matches community "preferred" and sets local-preference 200. Because LOCAL_PREF is iBGP-only, the preference stays inside your AS while the community can optionally be passed onward.
Traps
Expecting LOCAL_PREF to cross an eBGP boundary; assuming MED propagates past the first AS; forgetting that policy entries are evaluated in order and that default-action rejects when left unset in many templates; and matching communities exactly when a regular expression was intended.