Articles
BGP Interview Questions: Route Selection, Missing Routes, and Policy Debugging
Practice BGP interview questions with route snapshots covering next-hop validity, best-path selection, RIB failure, import policy, and missing advertisements.
BGP interview questions become easier when you stop treating “the route exists” as one fact. A prefix can arrive from a neighbor, fail import policy, lose eligibility because its next hop is unreachable, win BGP selection, lose installation to another protocol, or never reach an intended peer. Your answer should identify that boundary before proposing a configuration change.
For a foundation check, try Compare Core Networking and Language Runtime Concepts, then apply the route-specific drills below.
This article uses three original route snapshots and a policy-debugging ledger. Official facts come from the linked protocol and vendor documentation. Candidate reports: none are used to establish interview frequency or employer expectations. Preparation guidance and inference are labeled as such; the snapshots are synthetic exercises, not captures from a production router. Cisco-specific selection rules and FRRouting defaults are identified separately.
BGP interview questions: start with the route's state
A useful working definition is: BGP exchanges reachability information and applies routing policy to select and advertise paths. Its decisions do not, by themselves, prove that an application can communicate successfully.
Official protocol fact: RFC 4271 describes received, selected, and advertised routing information through Adj-RIBs-In, Loc-RIB, and Adj-RIBs-Out. These are conceptual information structures; do not assume a command exposes three physically separate tables. RFC 4271
Preparation guidance: write the following questions beside an unfamiliar prefix:
- Did the correct neighbor send it in the correct address family?
- Did local policy accept it?
- Is its next hop resolvable?
- Which accepted, eligible path won, and why?
- What entered the routing table and forwarding table?
- What was advertised to the intended peer?
Specify the router, VRF, address family, exact prefix, and observation time. Without those coordinates, two outputs can appear contradictory while describing different routing contexts. “The route is missing” is a symptom until you say where you expected to see it.
An Established session is useful evidence about the session. It is insufficient evidence about one prefix's acceptance, installation, export, or packet delivery. Keep the control-plane question separate from the forwarding question throughout your answer.
Snapshot 1: can an unreachable path win?
Original exercise. Router R1 receives two paths for 203.0.113.0/24. Both pass import policy, contain no local-AS loop, and have equal weight and other earlier preferences. The simplified inputs are:
Path A: next hop 192.0.2.10, unresolved
local preference 250, AS path 64510 64520
Path B: next hop 192.0.2.20, resolved
local preference 100, AS path 64530 64520
Which route should you explain first?
Start with A's eligibility, rather than its attractive local preference. Official protocol fact: an unresolvable next hop excludes a route from the relevant selection phase. Cisco likewise lists inaccessible next hops among paths that cannot qualify for its best-path comparison. RFC 4271, section 9.1.2.1, Cisco best-path selection
Worked answer: A cannot win under these assumptions. B is the remaining eligible path. Lowering A's local preference would not repair the missing next-hop reachability; it would change a later decision while leaving the earlier failure intact.
Ask for the next-hop route in R1's relevant routing context. Then inspect whether the expected underlay route exists, whether recursive resolution succeeds, and whether a next-hop transformation was intended. Cisco's troubleshooting material demonstrates an iBGP-learned route with an unreachable preserved next hop. That example supports checking resolution; it does not justify applying next-hop-self everywhere. Cisco BGP troubleshooting
Follow-up inference: if resolution is restored, A may become eligible and change the selected path. Re-run the comparison with the new inputs. Do not keep reporting B as best because it was best before the underlay repair.
This exercise rewards a short proof: identify the failed prerequisite, name the output that could confirm it, and explain which later comparisons are currently irrelevant.
Snapshot 2: shortest AS path or highest local preference?
Original exercise, using Cisco's documented order for the attributes shown. Compare paths to the same prefix. Both next hops resolve, weight is equal, neither path is locally originated, and no unlisted earlier setting changes the outcome.
Path C: iBGP, local preference 200, AS path 64510 64511 64520
Path D: eBGP, local preference 100, AS path 64530 64520
Worked answer: C wins at local preference. D's shorter AS path and eBGP origin do not rescue it because those comparisons occur later in this scoped example. A strong answer names the first decisive difference rather than reading an entire memorized tie-break list aloud.
Official vendor fact: Cisco's documented sequence includes weight, local preference, local origination, AS-path length, origin, MED, and eBGP versus iBGP, followed by further checks. Weight is Cisco-specific and local to the router. Confirm the implementation and configured exceptions before treating this ordering as universal. Cisco best-path selection
Now change the exercise: set both local preferences to 100. With the earlier assumptions unchanged, D wins on the shorter AS path. Changing one field at a time helps you prove which rule actually decided the result.
Why “lower MED wins” needs a qualification
Official vendor fact: Cisco's default MED comparison is normally restricted to paths from the same neighboring AS; settings such as bgp always-compare-med change that boundary. Cisco best-path selection
Original follow-up: two otherwise tied paths arrive from different neighboring ASes with MED values 5 and 50. You cannot conclude that the first wins on MED without confirming the comparison policy. Ask whether MED is comparable in this case, then continue through the applicable rules.
Do not conflate AS-path length with latency, monetary cost, or available bandwidth. A count of AS numbers is a routing attribute. If the interviewer asks for a performance decision, request performance evidence and explain how policy would express the intended preference.
Snapshot 3: best in BGP, absent from the routing table
Original exercise. The BGP view identifies path E as best for 203.0.113.0/24. Its next hop resolves. The IP routing table already contains a static route for the exact same prefix, with a better administrative distance in the stated platform configuration. The BGP output marks a RIB failure.
Worked answer: BGP selection and installation are different decisions. The preferred BGP candidate can lose installation to the static route. This is not evidence that BGP chose a different AS path.
Official vendor fact: Cisco documents a competing route with lower administrative distance as one cause of BGP RIB failure. Its troubleshooting guidance identifies show ip bgp rib-failure as the command for examining the reason. Cisco BGP troubleshooting
A useful response has three parts: report E's BGP selection, report the installed static route, and ask whether that static route is intentional. Deleting it simply to make the BGP view look cleaner could change production traffic. Verify the intended failover contract first.
Does RIB failure prevent advertisement?
Avoid a universal answer. Cisco documents circumstances in which a RIB-failed path is still advertised and explains how bgp suppress-inactive interacts with this behavior, including next-hop matching details. Inspect the relevant setting and advertised-route evidence. Cisco RIB failure and suppress-inactive
Preparation guidance: add two separate entries to your incident note: “installed route” and “advertised route.” Neither should be inferred from the word best alone.
Similarly, compare BGP candidates for the same prefix before discussing packet lookup across different prefix lengths. A /24 and a covering /16 are not simply two competing copies of one route. RFC 4271 discusses the relationship between overlapping routes; preserve that distinction when explaining an aggregate and a more specific destination. RFC 4271, section 9.1.4
An Established peer has no useful routes: inspect policy boundaries
Official implementation fact: FRRouting's bgp ebgp-requires-policy requires incoming and outgoing filters. A missing incoming filter prevents acceptance; a missing outgoing filter prevents announcements. Its documentation distinguishes the traditional profile, where this is enabled by default, from the datacenter profile. Do not apply that default indiscriminately to another vendor or profile. FRRouting BGP documentation
RFC 8212 supplies the standards background for default eBGP behavior without configured import or export policy. It is a policy boundary, not a promise that every existing deployment has identical defaults. RFC 8212
Original debugging ledger: an upstream operator says it sent 203.0.113.0/24, but a downstream peer cannot see it.
| Boundary | Evidence and next question |
|---|---|
| Upstream export | Does its advertised view include the exact prefix for this peer and address family? |
| Local import | Does the applicable filter permit this prefix length and origin? Separate received information from accepted information. |
| Local selection | Which paths remain eligible, and which attribute makes the winner decisive? |
| Routing-table installation | Is a competing route installed? Is next-hop recursion consistent with the intended context? |
| Downstream export | Does the outbound filter permit the selected route, and does the peer's received view confirm arrival? |
Suppose the intended import rule permits exactly /24, while the upstream actually advertises a /25. The disagreement may be an intentional prefix-length boundary. Before broadening the rule, establish which prefix the contract permits. A policy change that fixes one symptom can admit an unwanted route set.
Preparation inference: treat the route filter like an access policy. Explain a narrow permitted case, a neighboring prefix-length case, and a forbidden prefix. After a change, confirm both the intended acceptance and the continued rejection. A positive test alone cannot establish that the policy remained constrained.
State how updated policy is applied on the actual platform. Avoid a casual session reset recommendation; describe the supported refresh or re-evaluation mechanism and its operational impact only after the implementation is known.
A routing explanation should end with a discriminating check
If both peers show the prefix, investigate the packet path independently. Request the installed route, forwarding lookup, next-hop adjacency, relevant interface state, and the reverse path for a specified source and destination. A routing advertisement is not an application health check.
Original interview drill: one source reaches the destination while another cannot. Before changing BGP preference, compare their VRFs, source addresses, destination lookup, and return routes. A successful probe from the router itself may use a different source from the affected application.
Preparation guidance: phrase your conclusion as “this output supports X; it does not yet establish Y.” For example: “The prefix is accepted locally and path C wins. I still need the installed route and downstream advertised view before concluding that this router forwards and exports it as intended.” That answer is testable and leaves a clear next action.