skip to content

In BGP, what do import and export policies decide on an eBGP session, and what does RFC 8212 require when none is configured?

level: middleimportance: must knowfreq 42%

answer

  1. two directions per session
  2. Adj-RIB-In, Loc-RIB, Adj-RIB-Out
  3. eligible vs announced
  4. missing policy fails closed

basics

~20 s

A BGP import policy decides which routes from a neighbour are eligible, with what attributes; an export policy decides which selected routes are announced to it. RFC 8212 makes an eBGP session without explicit policy accept and announce nothing.

solid answer

~40 s

Every BGP session has two policies. **Import** runs on what the neighbour sent (the Adj-RIB-In): it can reject a route or change attributes such as `LOCAL_PREF` or communities before selection. **Export** runs between the speaker's selected routes (the Loc-RIB) and what it announces to that neighbour (the Adj-RIB-Out), and can exclude routes or prepend, set MED or tag. RFC 4271 leaves the policy itself a local matter. **RFC 8212** updates it for eBGP: with no explicit import policy, received routes are not eligible for the decision process; with no explicit export policy, nothing is added to that peer's Adj-RIB-Out. A missing policy therefore fails closed instead of leaking routes.

go deeper

for a junior

Recall that BGP filters in two directions: what it accepts from a neighbour and what it announces to that neighbour, and that each session has its own rules.

for a middle

Explain where import and export run against Adj-RIB-In, Loc-RIB and Adj-RIB-Out, and state RFC 8212's eBGP default-reject on both sides.

for a senior

Show that a changed import policy must re-evaluate routes already received, how route refresh does that without a reset, and why failing closed prevents accidental transit.

for a principal

Discuss defaults as a safety property: why fail-closed policy defaults were standardised, and how to roll such a default change across a fleet without breaking existing sessions.

## Two directions of policy on every session A **BGP speaker** never simply passes on what it hears. On each session it runs two separate policies: - **Import policy** (inbound) runs on routes *received* from a neighbour. It decides whether each route is eligible at all, and it may change attributes before the route competes — set `LOCAL_PREF`, add a community, strip communities, rewrite a next hop. - **Export policy** (outbound) runs on routes the speaker could *announce* to a neighbour. It decides which of the selected routes go into the update for that neighbour, and it may change attributes on the way out — prepend the local AS, set `MULTI_EXIT_DISC`, tag a community. RFC 4271 does not define a policy language. It says the nature of the policy information is "a local matter" and calls the store of configured policies the **Policy Information Base (PIB)**. Prefix lists, AS-path filters and route maps are how implementations express that policy; the protocol only fixes *where* policy runs. ## Where policy sits in RFC 4271's model RFC 4271 describes three conceptual tables and three decision phases: 1. Routes arrive in an UPDATE and are stored, unprocessed, in the **Adj-RIB-In** for that peer. 2. **Phase 1** computes a degree of preference for each route. For a route from an *external* peer, RFC 4271 §9.1.1 says the speaker computes it "based on preconfigured policy information", and a route the policy marks ineligible does not go on to selection. This is the import policy. 3. **Phase 2** selects the best route per destination into the **Loc-RIB**. 4. **Phase 3** (§9.1.3) processes Loc-RIB routes into each **Adj-RIB-Out** "according to configured policy", which "MAY exclude a route" from a particular peer's Adj-RIB-Out. This is the export policy. | Table | Holds | Policy on its edge | |---|---|---| | Adj-RIB-In | what one peer sent, unprocessed | import policy reads from it | | Loc-RIB | the routes this speaker selected | — | | Adj-RIB-Out | what will be sent to one peer | export policy writes into it | The tables are conceptual: RFC 4271 says an implementation need not keep three copies. ## RFC 8212: no policy means no routes Early implementations treated a missing policy as "accept everything, announce everything". On an eBGP session that is exactly how a misconfigured network ends up re-announcing one provider's routes to another. **RFC 8212** (Standards Track, 2017) updates RFC 4271 for **eBGP sessions only**: - Routes in the Adj-RIB-In of an eBGP peer "SHALL NOT be considered eligible in the Decision Process if no explicit Import Policy has been applied". - Routes "SHALL NOT be added to an Adj-RIB-Out associated with an EBGP peer if no explicit Export Policy has been applied". So a new eBGP session with no policy reaches Established and exchanges KEEPALIVEs, but carries no usable routes in either direction until an operator writes a policy — even an explicit "accept all" counts. The RFC lets an implementation offer a configuration option to deviate, and describes migrating defaults across releases so existing networks are not broken by an upgrade. iBGP sessions are outside its scope. ## Changing a policy on a live session An import policy is applied when routes arrive, so a changed policy must re-evaluate the routes already received; many implementations start this automatically. Two ways to re-run it without resetting the session: - **Route refresh** (RFC 2918): both speakers advertise the Route Refresh Capability (capability code 2), and the speaker that changed its import policy sends a `ROUTE-REFRESH` message (message type 5) for an address family; the neighbour re-sends its Adj-RIB-Out. - **Stored copy**: keep an unmodified copy of everything the peer sent and re-evaluate it locally. RFC 2918 notes this costs memory and CPU for routes that rarely need it. An export-policy change needs neither: the speaker re-runs Phase 3 and sends UPDATEs or withdrawals itself. ## What a good answer adds - Import and export are **separate decisions**: accepting a route from a peer says nothing about announcing it to anyone else. - Policy is **per session**, so a customer, a settlement-free peer and an upstream each get different import and export rules. - RFC 8212 is a **safe default, not a policy**: it makes the absence of policy fail closed, but someone still has to write the right filters.

  • Does RFC 8212 apply to iBGP sessions as well?
    No. RFC 8212 adds its default-reject rule only for routes associated with an eBGP peer, both on import and export. iBGP sessions inside one AS still follow RFC 4271's rules, which is reasonable because the routers belong to one operator and filtering normally happens at the AS edge.
  • After tightening an import policy, how do you apply it to routes a peer already sent, without resetting the session?
    Send a `ROUTE-REFRESH` message (RFC 2918, message type 5) for that address family, provided both sides advertised the Route Refresh Capability; the neighbour re-sends its routes and the new import policy evaluates them. The alternative is keeping an unmodified copy of the peer's routes and re-evaluating locally, which costs memory.
  • Does RFC 8212 stop a BGP session from reaching Established when no policy exists?
    No. It changes which routes are eligible and which are added to the Adj-RIB-Out, not the session state machine. The session comes up and exchanges KEEPALIVEs; it simply carries no routes into the decision process or out to the peer until a policy is applied.

saying these in an interview costs you the question

  • Accepting a route from a peer means it will be announced to every other peer.
  • RFC 8212 tears down an eBGP session that has no policy configured.
  • RFC 4271 defines route maps and prefix lists as part of the protocol.
  • Changing an import policy always requires resetting the BGP session.
  • RFC 8212's default-reject also applies to every iBGP session.