Received, Chosen, Announced
Three tables, and why a route can arrive and never be used
Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.
What you'll be able to do
- ▸Name the three tables a BGP speaker keeps and say what each holds
- ▸Explain why a route in the Adj-RIB-In may never reach the routing table
- ▸Read an inbound filter's effect from a capture where nothing looks wrong
Before this lesson — it builds directly on:
Every other routing protocol in this course has one table: what it learned. BGP has three, and the reason is that BGP is a policy protocol.
If all you keep is what you chose, you cannot answer "what did they actually send me?" — and that is the first question in almost every BGP investigation. If all you keep is what you were told, you cannot express "I have this route and I am deliberately not passing it on", which is most of what an operator does with BGP.
So: what was received, what was chosen, what is announced. Three tables, kept separately, because the differences between them are where all the decisions live.
Watch these fields in the lab: bgp.type
- Adj-RIB-In
- What each peer told you, exactly as they said it. One per peer, and no decision has been applied to it.
- Loc-RIBglossary
- What you chose. The decision process runs over the Adj-RIB-In and selects one path per prefix; this is what feeds the routing table.
- Adj-RIB-Out
- What you tell each peer. One per peer, and shaped by outbound policy — you can choose a route and still not pass it on.
✓ Concept check — before you open the packets
These test the idea, not the trace. You should be able to answer them from the explanation above.
Now that you understand the concept, observe how it appears in the packet exchange.
The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.