Make eBGP default-reject a tested policy, not a surprise outage

An eBGP session being established does not mean it should exchange routes. Default-reject behavior reduces accidental propagation, but an upgrade that activates it before policies are attached can remove legitimate reachability just as effectively as a bad filter.

Source fact:

IETF RFC 8212 specifies a safer default for external BGP. When an explicit import policy has not been applied, routes received from an eBGP neighbor are not eligible for route selection. When an explicit export policy has not been applied, routes are not added to that neighbor’s outbound advertisement set. The intent is to avoid accidental route exchange caused by the historical assumption that an unconfigured session may accept and advertise broadly.

The RFC also recognizes transition reality. An implementation can provide a configuration option that retains the previous behavior, and existing deployments may need a migration period. That accommodation makes release notes, default settings, and configuration inheritance important parts of the change—not merely the route-map text visible on one neighbor.

Boundary

Default-reject is a baseline behavior, not a complete routing-security policy. An explicitly attached policy can still be overly broad, refer to stale prefix data, or apply in the wrong direction. Platform semantics differ on what counts as an explicit policy, especially with templates, address-family activation, route servers, and generated configurations. The RFC does not validate the business authorization for any prefix.

Applicability questions

• Which routers and releases implement RFC 8212 behavior, and what is each device’s current default?
• Does every active eBGP address family have an intentional import and export policy?
• Are inherited, empty, or pass-all policies treated as explicit by the platform?
• Which prefixes and communities should be received and advertised for each relationship?
• Is an out-of-band recovery path available if management reachability depends on the changed session?

DSE recommendation:

Export the running neighbor inventory and normalize it by device, virtual routing instance, peer, and address family. For every direction, link the attached policy to an approved prefix and community expectation. Flag missing attachments, empty policy objects, and compatibility knobs. Resolve those gaps before changing the default.

Stage the behavior in a representative lab or a single controlled peer. Capture received routes, selected routes, and advertised routes before the change. Apply or verify explicit policies, enable the target behavior, and compare the same data. Roll out in small groups with route-count, reachability, and session-state monitoring. Keep a time-bounded rollback step that restores the known setting without discarding the new policy objects.

Verification and evidence

Evidence should include the device and software matrix, neighbor/address-family inventory, approved prefix expectations, policy definitions and attachment points, pre/post route snapshots, external route-collector observations where available, and change records. A useful negative test establishes that a session with no policy exchanges no routes. A positive test establishes that adding the approved policy restores only the expected routes.

Official references

• IETF RFC 8212
• IETF RFC 4271, A Border Gateway Protocol 4