The Routing Information Base (RIB) is one of the key workings of the BGP protocol on a router. The RIB is not just a routing table, it’s a dynamic repository of all the information that a router has learned from BGP Neighbours, along with a host of associated other attributes, such as the route’s AS Path, MED, local preference and so on. The RIB as a whole makes a comprehensive set of data that forms the foundation for the BGP decision process, that allows a router to evaluate and select the best path for traffic.
The article will be quick piecemeal, where i’ll throw in a number of different topics that, up until now we’ve not covered at all or only briefly mentioned.
Structure of the RIB
The RIB is split into three main parts which are summarised below, but depending on the vendor and the different names for things, it can get a bit confusing.
So to be clear, the BGP RIB has three parts, the Adj-RIB-In (RIB-In), the Local RIB (Loc-RIB) and the Adj-RIB-Out (RIB-Out).
Adj-RIB-In (RIB-In)
The Adj-RIB-In collects all the routes (prefixes) from BGP Neighbours (peers). It’s just all the routes in raw form, before any modifications or policy filtering. So potentially within this you’ll find routes that your filters (policy) will discard too.
Local RIB (Loc-RIB)
When the router receives the routes (from the Adj-RIB-In), it runs them through the various filters and policies after which the result is stored in the Local RIB. It is the Local RIB that contains only the routes that are active and “best” and compliant with any of the policies will make it in here and be actually used to govern the flow of traffic through the router onto its further destinations – when put into the Routing Table (Global RIB, FIB Forwarding Information Base).
Adj-RIB-Out (RIB-Out)
Opposite to the Adj-RIB-In is the Adj-RIB-Out, this repository contains all the routes (prefixes) that a router is going to advertise to its BGP Neighbours. However, BGP ensures that only the “best” and validated routes (prefix) are only shared with its neighbours after they have been subject to any policy filtering (and/or manipulation).
Routing Table (Global RIB, FIB – Forwarding Information Base)
Note that network engineers often use the terms “Routing Table” and “RIB” interchangeably, but they are different. The RIB is the database of all routing information “warts and all” so to speak, while the Routing Table (or Global RIB or FIB – Forwarding Information Base) is the list of active routes that are being actively used by the Router to forward traffic.
OK, that might be a bit confusing, so think of it like this. The BGP RIB has three parts, the incoming routes (RIB-In), the best selected routes that are compliant with policies etc. (Loc-RIB) and the outgoing routes (RIB-Out). The “best selected routes” from the (Loc-RIB) are the ones that go into the “Routing Table” (a.k.a Global RIB, FIB or CEF in Cisco-land) and are used in actually determining the forwarding of packets through the router.
Administrative Distance (AD) also known as Route Priority
The Administrative Distance (AD) is a locally used value that indicates the trustworthiness of different routing sources (which come from different protocols), it is not carried in BGP, it is not visible to neighbours and is only used when installing routes into the Routing Table (Global RIB/FIB) which will then be used in actually determining the forwarding of packets through the router.
And sometimes it doesn’t apply, because in terms of BGP (or any other protocol): BGP does NOT compete using AD inside BGP. The AD only matters when competing against other routing protocols if two or more identical routes (network prefixes) are received via different protocols and the router needs a way to “tie-break” (referee) these to decide which is actually used by the router in forwarding packets.
A vendor neutral list is of the Administrative Distance is shown below:
| Protocol | AD |
|---|---|
| Connected | 0 |
| Static | 1 |
| eBGP | 20 |
| EIGRP (internal) | 90 |
| OSPF | 110 |
| RIP | 120 |
| iBGP | 200 |
Where is it Applied?
So if you remember the flow: Adj-RIB-In → Loc-RIB → Routing Table (Global RIB)
Then the Administrative Distance is evaluated at this stage: Loc-RIB → Routing Table (Global RIB), and is done for multiple protocols (if they exist) to act as the “tie-breaker” of if to install a route into the Routing Table (Global RIB) if the router learns the same route (network prefix) via more than one network protocol at once.
Metric
Before looking at some examples, we’ll quickly review what a Metric is, because we have three similar sounding things: Administrative Distance (Route Preference in EXOS), Route Metric, BGP attributes (like MED, LocalPref).
The Metric is a value that is either set (or derived by the routing protocol a.k.a. the Origin) and used where we have two (or more) routes from the same protocol with the same destination (network/route prefix), for example two routes learned via eBGP, it is at this point the Metric would be used. And of course although not important here, within BGP itself, attributes are used to select the “Best Path”.
Although for static routes, here’s an example for the 10.10.10.128/25 network, you can see it has two routes for the same network prefix, but different metrics 100 and 200, so within the same Origin (or routing protocol) the route with the lower metric (100) would win and be used.
Switch # show iproute
Ori Destination Gateway Mtr Flags VLAN Duration
#s 10.10.10.128/25 10.10.10.129 100 UG---S-um--f- Default 0d:0h:2m:41s
s 10.10.10.128/25 10.10.10.130 200 UG---S-um---- Default 0d:0h:2m:40sSo in our case the Administrative Distance (AD) a.k.a. Preference is only used where you have two (or more) routes from different protocols with the same destination (network/route prefix). For example, two routes for 10.10.10.128/25, where one is being learned via OSPF and the other via eBGP, different protocols; so same route, different protocols, AD is the tiebreaker.
| Decision Layer | What Decides |
|---|---|
| Between protocols | Administrative Distance |
| Within one protocol | Metric |
| Within BGP only | BGP decision process (attributes) |
Where can I see the AD for a route?
Everything I have found on this seems to indicate you can’t see the AD alongside a route in the routing table, like another column, it doesn’t appear to be possible to see this value in the output.
What you can see is the “Origin”, which is where the route has come from (been learned from), with this you are then able to determine the AD (from the table above – or your router’s configuration), to then understand why the route that is appearing in this output below (which is the Routing Table – Global RIB) is, or is not the one you were expecting to see!
Example 1 – eBGP vs OSPF
Let’s say on Router K, we’ve learned the route: 10.5.1.0/24 via eBGP from Router L. But we have also learned this same route via OSPF from Router L.
If we examine the Administrative Distance (AD) of each of these they are:
- eBGP (AD 20)
- OSPF (AD 110)
So although the route was installed in the BGP Loc-RIB and the OSPF LSDB, only the eBGP learned route is actually installed into the Routing Table (Global RIB) for use to govern the forwarding of packets through the router.
Example 2 – iBGP vs OSPF
For the second example let’s assume that on Router F we’ve learned the route 10.5.0.0/24 from Router K via iBGP, but we have also learned this same route via OSPF from Router K too.
We can see the route (for this network prefix) in the Loc-RIB for BGP. We can also see the route (for this network prefix) in the OSPF LSDB too. But there can be only one winner. So which would it be? Which origin would make it into the Routing Table (Global RIB) and be used to actually route packets?
Now if we examine the AD value of each of these two routes, these are:
- iBGP (AD 200)
- OSPF (AD 110)
Which means that in this case the OSPF route will win, and will be used in the Routing Table to forward traffic.
This is called an “RIB Failure” (from a BGP perspective), BGP has selected what it thinks is the “best path” but it can’t install it into the Routing Table (Global RIB) because a lower-AD route already exists; OSPF in this example.
Example 3 – Static Route vs (e)BGP
For the third and final example, let’s assume that on Router L we have a static route to 0.0.0.0/0 (i.e. a default route) that has been configured on Router L, but Router L has also learned this same static (default) route via eBGP (from Router K), what happens?
If we examine the AD value of each of these two routes:
- Static (AD 1)
- eBGP (AD 20)
In this case the Static route will win and will be preferred and installed into the Routing Table (Global RIB).
Again this is considered to be a “RIB Failure” from a BGP perspective, however BGP will advertise this “best path” to its neighbours (subject to policy/filters of course).
Why is eBGP preferred over iBGP or for any other internal routing protocol for that matter?
Why is eBGP preferred over iBGP? Why are other IGP protocol routes (e.g. Static, OSPF, EIGRP etc) preferred over iBGP?
Good questions, firstly think about what eBGP is being used for. It’s used to learn about Internet (outside) routes, so you’d want these preferred over any internal routes. Why would the route to a network prefix used by Google (outside your network) learned via eBGP be preferred over the same network prefix learned via OSPF for example? You wouldn’t want this to work like that, you’d generally want external routes (prefixes) to override any IGP protocols; so that the Internet edge behaviour makes sense.
So why is the iBGP AD so high? It’s so that if you have an internal route learned via iBGP and another IGP protocol such as Static or OSPF, that these (i.e. Static or OSPF) would take preference, so you don’t break internal connectivity.
Adjusting Administrative Distance
Being that AD is only considered locally (within the Router), you can tweak the Administrative Distance; to then change the behaviour of your router in certain circumstances. Bear in mind this must be done with great care, changing the default AD ordering directly affects the behaviour of the routing and can have unintended consequences if your routing table is very complicated and/or if you (or someone else) makes a design decision in future based on what they think should happen, unexpected behaviour can result.
The Extreme Networks article EXOS / Switch Engine : How to change the administrative distance of routes describes how to change the AD values.
An example of when this might happen or need to happen is say if you are learning a route via iBGP, but a route from eBGP is taking preference, but you don’t want it to, you can adjust the AD of the routing protocol to tweak this, but as mentioned this can have unintended consequences so it is worth understanding fully and testing in a lab environment before you do so.
RIB Failure
A term you’ll come across is RIB Failure. Essentially RIB Failure is a state whereby BGP has selected its “best path”, but it was unable to install it into the Routing Table (i.e. the Local RIB) for the router to actively use to forward/route packets.
So why can this happen? There are a few common reasons, such as:
- A route (to that network prefix) with better administrative distance is already present, therefore this route BGP has selected can’t be installed.
- A route’s next-hop address, i.e. the router the packet needs to be routed to reach that network, is not able to be reached by the router, because of this, it can’t install the route. We came across this in earlier articles, think: next-hop-self and the use of an IGP to ensure that the next-hop addresses are routable, even if the router is using a route learned by another routing protocol (IGP) such as OSPF.
- A memory failure exists, perhaps faulty memory within the router.
- Too many routes exist in the Route Table and/or the number of routes within a VRF (see next section) exceeds the route-limit configured. So even though the router knows about the route it doesn’t have capacity to install it and use it because of either physical or logical constraints on the memory.
VRF (Virtual Routing and Forwarding)
A technology that enables multiple independent routing tables to exist on a single router (hardware), its essentially allowing multiple Virtual Routers to run on a single hardware router.
Each VRF has:
- Its own routing table
- Its own interfaces
- Its own BGP/OSPF sessions
- Its own default route
- Its own forwarding decisions
And they do not see each other’s routes unless explicitly configured to.
Relating this to BGP, a VRF would allow a provider to allow multiple BGP route tables for multiple customers to exist on the same physical hardware (and network) where the IP addresses overlap, but the customers and their networks are kept separate.
VRFs are great tool in creating multi-tenant (multi-customer) networks. Relating it to the BGP RIB, each VRF would have its own fully functional BGP RIB, so each customer would see their own BGP RIB just for them.
BGP Debug Logging
Working out what is happening when something goes wrong is key to identifying the issue and remediating it.
Check the Router Logs
A quick place to start is to look at the Router Logs, for example the below using “show log | include BGP”, and then filtering for BGP (as shown in the output below).
However, it is often helpful to just check the logs for any other issues which may be affecting BGP, rather than BGP itself.
Perhaps a link has gone down, or a route has been removed from another routing protocol (e.g. OSPF) for example.
tris-routerK.7 # show log | include BGP
03/06/2026 08:52:41.00 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has entered Established state, holdtime: 45, passive:0
03/05/2026 13:07:08.83 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has left Established state, holdtime: 45, passive:0
03/05/2026 13:07:08.83 <Warn:BGP.DecisnCoord.StorNbrPfxMaxExcd> [VR 0x00000002] The maximum number of prefixes stored for a neighbor would be exceeded.
03/05/2026 13:07:08.83 <Warn:BGP.DecisnCoord.StorNbrPfxMaxExcd> [VR 0x00000002] The maximum number of prefixes stored for a neighbor would be exceeded.
03/05/2026 13:07:08.83 <Warn:BGP.DecisnCoord.StorNbrPfxMaxExcd> [VR 0x00000002] The maximum number of prefixes stored for a neighbor would be exceeded.
03/05/2026 13:06:26.28 <Warn:BGP.DecisnCoord.NumPeerPfxRchWarnThrsh> [VR 0x00000002] The number of prefixes from a peer has reached the warning threshold.
03/05/2026 13:06:26.24 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has entered Established state, holdtime: 45, passive:0
03/05/2026 12:56:19.66 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has left Established state, holdtime: 45, passive:0
03/05/2026 12:56:19.66 <Warn:BGP.DecisnCoord.StorNbrPfxMaxExcd> [VR 0x00000002] The maximum number of prefixes stored for a neighbor would be exceeded.
03/05/2026 12:56:19.66 <Warn:BGP.DecisnCoord.StorNbrPfxMaxExcd> [VR 0x00000002] The maximum number of prefixes stored for a neighbor would be exceeded.
03/05/2026 12:56:19.66 <Warn:BGP.DecisnCoord.StorNbrPfxMaxExcd> [VR 0x00000002] The maximum number of prefixes stored for a neighbor would be exceeded.
03/05/2026 12:56:19.66 <Warn:BGP.DecisnCoord.NumPeerPfxRchWarnThrsh> [VR 0x00000002] The number of prefixes from a peer has reached the warning threshold.
03/05/2026 12:53:44.64 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has entered Established state, holdtime: 45, passive:0
03/05/2026 12:53:29.73 <Warn:BGP.NeighborMgr.BfdMsgRcvNotCorr> A BFDI message was received that could not be correlated to a BGP connection 192.168.100.66
03/05/2026 12:53:29.73 <Warn:BGP.NeighborMgr.BfdMsgRcvNotCorr> A BFDI message was received that could not be correlated to a BGP connection 192.168.100.66
03/05/2026 12:53:29.63 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has left Established state, holdtime: 45, passive:0
03/05/2026 12:48:07.79 <Warn:BGP.DecisnCoord.NumPeerPfxRchWarnThrsh> [VR 0x00000002] The number of prefixes from a peer has reached the warning threshold.
03/05/2026 12:48:07.75 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has entered Established state, holdtime: 45, passive:0
03/05/2026 12:47:52.80 <Warn:BGP.NeighborMgr.BfdMsgRcvNotCorr> A BFDI message was received that could not be correlated to a BGP connection 192.168.100.66
03/05/2026 12:47:52.80 <Warn:BGP.NeighborMgr.BfdMsgRcvNotCorr> A BFDI message was received that could not be correlated to a BGP connection 192.168.100.66
03/05/2026 12:47:52.74 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has left Established state, holdtime: 45, passive:0
03/03/2026 10:33:28.13 <Noti:BGP.NeighborMgr.PeerEstTrans> [VR 2] Peer 192.168.100.66 (0) has entered Established state, holdtime: 45, passive:0Check BGP Neighbours
When attempting to determine what is going on, checking the BGP Neighbours is a good point to start. Are all the expected BGP Neighbours up and in ESTABLISHED state?
Remember the previous article that goes into the FSM (BGP Finite State Machine) and the states that BGP goes through, again these can be helpful to determine what is happening at any particular time.
tris-routerK.2 # show bgp neighbor
Peer AS Weight State InMsgs OutMsgs(InQ) Up/Down
------------------------------------------------------------------------------------------------------------
Ie-- 1.1.1.6 65004 1 ESTABLISHED 34258 34282 (0 ) 20:16:28:43
Ee-- 192.168.100.66 65005 1 ESTABLISHED 33133 33124 (0 ) 5:0:04:14
Flags: (d) disabled, (e) enabled, (E) external peer, (I) internal peer
(m) EBGP multihop, (r) route reflector client
BGP Peer Statistics
Total Peers : 2
EBGP Peers : 1 IBGP Peers : 1
RR Client : 0 EBGP Multihop : 0
Enabled : 2 Disabled : 0If not, looking into why is a good place to start investigating. You can of course dive in deeper to a particular neighbour to see what is happening with:
tris-routerK.3 # show bgp neighbor 1.1.1.6
Peer Description :
IBGP Peer : 1.1.1.6 AS : 65004
Enabled : Yes OperStatus : Up
Weight : 1 Shutdown-Priority : 1024
ConnectRetry : 120 MinAsOrig : 5
HoldTimeCfg : 180 KeepaliveCfg : 60
Source Interface : 1.1.1.12 RRClient : No
EBGP-Multihop : No Remove Private AS : No
BFD : Off BFD Status : Not Required
Capabilities Config : ipv4-unicast,ipv4-multicast,4-Byte-As,route-refresh (old & new)
Policy for NLRI Type ipv4-unicast
In Policy : None
Out Policy : None
NextHopSelf : Disabled Send Communities : No
Soft Input Recfg : Disabled Allow Looped AS-Path: No
Policy for NLRI Type ipv4-multicast
In Policy : None
Out Policy : None
NextHopSelf : Disabled Send Communities : No
Soft Input Recfg : Disabled Allow Looped AS-Path: No
Policy for NLRI Type vpnv4
In Policy : None
Out Policy : None
NextHopSelf : Disabled Send Communities : Standard, Extended
Soft Input Recfg : Disabled Allow Looped AS-Path: No
Policy for NLRI Type ipv6-unicast
In Policy : None
Out Policy : None
NextHopSelf : Disabled Send Communities : No
Soft Input Recfg : Disabled Allow Looped AS-Path: No
Policy for NLRI Type ipv6-multicast
In Policy : None
Out Policy : None
NextHopSelf : Disabled Send Communities : No
Soft Input Recfg : Disabled Allow Looped AS-Path: No
Policy for NLRI Type ipv4-vxlan
In Policy : None
Out Policy : None
NextHopSelf : Enabled Send Communities : No
Soft Input Recfg : Disabled Allow Looped AS-Path: No
State : ESTABLISHED
FSM Up since : Wed Feb 18 16:28:12 2026
(Duration: 20:16:31:35)
Remote Addr : 1.1.1.6 Local Addr : 1.1.1.12
Remote Port : 179 Local Port : 41736
Remote RouterId : 1.1.1.6 Local RouterId : 1.1.1.12
HoldTimeNegotiated : 180 KeepAliveNegotiated : 60
FsmTransitions : 1
InUpdateElapsedTime : 11:23:49:46 InMsgElapsedTime : 11:23:49:46
InUpdates : 33 OutUpdates (in TxQ) : 51 (0)
InTotalMsgs : 34261 OutTotalMsgs : 34286
InRouteRefreshes : 0 OutRouteRefreshes : 0
Route Statistics for NLRI Type ipv4-unicast
Received : 10 Accepted : 10
Rejected : 0 Active : 10
Suppressed : 0
Route Statistics for NLRI Type ipv4-multicast
Received : 0 Accepted : 0
Rejected : 0 Active : 0
Suppressed : 0
Capabilities Tx : ipv4-unicast,ipv4-multicast,4-Byte-As,route-refresh (old & new)
Capabilities Rx : ipv4-unicast,ipv4-multicast,4-Byte-As,route-refresh (old & new)
NLRI for the session: ipv4-unicast,ipv4-multicast
Last State : ESTABLISHED Last Event : RX_KEEP
LastError : 'None'
BGP Peer Statistics
Total Peers : 2
EBGP Peers : 1 IBGP Peers : 1
RR Client : 0 EBGP Multihop : 0
Enabled : 2 Disabled : 0Here you can see the errors, last state, but also verify you are getting messages from the BGP neighbour or not, which may help you identify any issues.
Transmitted, Received, Rejected and Accepted Routes
If the BGP Neighbour appears to be in the correct state, examining the routes being transmitted, received, rejected and accepted will help determine if you’re expecting to see some routes, but no longer getting them, what your next steps might need to be.
show bgp neighbor 1.1.1.6 accepted-routes all
show bgp neighbor 1.1.1.6 rejected-routes all
show bgp neighbor 1.1.1.6 recieved-routes all
show bgp neighbor 1.1.1.6 transmitted-routes all
show bgp neighbor 1.1.1.6 suppressed-routes allAn example output would be something like:
If you’re expecting to see a route, but it is not appearing, here you can see if its being rejected (for some reason).
BGP Local RIB (Loc-RIB)
Checking the BGP Local RIB is another key step in troubleshooting. Remember this is the BGP Local RIB, so what BGP’s view of the world is, but it’s not what is actually used by the router to forward packets, that’s the Route Table (Global RIB) which we’ll look at in the next section.
tris-routerK.8 # show bgp routes all
Routes:
Destination Peer Next-Hop LPref Weight MED AS-Path
----------------------------------------------------------------------------------------------------------------
*>? 10.1.0.0/16 1.1.1.6 192.168.100.41 100 1 0 65001.0
*>i 10.1.0.0/24 1.1.1.6 192.168.100.41 100 1 0 65001.0
*>i 10.1.1.0/24 1.1.1.6 192.168.100.41 100 1 0 65001.0
*>i 10.1.2.0/24 1.1.1.6 192.168.100.41 100 1 0 65001.0
*>i 10.1.3.0/24 1.1.1.6 192.168.100.41 100 1 0 65001.0
*>? 10.1.5.0/24 1.1.1.6 192.168.100.41 100 1 0 65001.0
*>i 10.2.0.0/24 1.1.1.6 192.168.100.45 100 1 0 65002
*>i 10.2.1.0/24 1.1.1.6 192.168.100.45 100 1 0 65002
*>i 10.2.2.0/24 1.1.1.6 192.168.100.45 100 1 0 65002
*>i 10.4.0.0/24 1.1.1.6 1.1.1.6 100 1 0
*>i 10.5.0.0/24 192.168.100.66 192.168.100.66 100 1 0 65005
*>i 10.5.1.0/24 192.168.100.66 192.168.100.66 100 1 0 65005
*>i 10.5.2.0/24 192.168.100.66 192.168.100.66 100 1 0 65005
*>i 10.5.3.0/24 192.168.100.66 192.168.100.66 100 1 0 65005
Flags: (*) Preferred BGP route, (>) Active, (d) Suppressed, (h) History
(s) Stale, (m) Multipath, (u) Unfeasible
Origin: (?) Incomplete, (e) EGP, (i) IGP
BGP Route Statistics
Total Rxed Routes : 15
Feasible Routes : 14
Active Routes : 14
Rejected Routes : 1
Unfeasible Routes : 0
Route Statistics on Session Type
Routes from Int Peer: 10
Routes from Ext Peer: 4Here we can see the status of the routes (described below) you may also see multiple routes for the same network prefix.
The first column which contains the *>i in these particular examples is the status flags (and origin) for the route.
Route Status options include:
- Preferred BGP Route ( * ) – The preferred route by BGP, meaning the “best” route, the one that is being used (and put into the Routing Table (Global RIB)). If you see multiple routes which have the same route prefix (and you don’t have ECMP enabled) then you may see a route without an asterisk ( * ) for a particular network prefix, this is just another route which is not considered to be “best” at this time.
- Suppressed (d) – This route has been suppressed, meaning BGP knows about it, but is not using (or advertising it) for some reason. It could be because there is a summary route, i.e. a route prefix that covers multiple route prefixes, so rather than advertising (or using in the Route Table) 3 route prefixes, instead one could be used. For example, 10.0.0.0/23 being used instead of 10.0.0.0/24 and 10.0.1.0/24, making these latter two “suppressed” routes. A route may also be suppressed if it is flapping, due to dampening.
- History (h) – This route is kept in memory to retain flap-dampening statistics. This route is not currently announced by the peer.
- Stale (s) – The route is marked as stale, it is not actively used.
- Multipath (m) – We had a previous article on this, if you have two or more network prefixes (routes) with the same destination, and you also have ECMP enabled, then you will see two (or more) best routes which are identified by the “m”.
- Unfeasible (u) – We saw this in very early articles, it’s a route that BGP has received from a BGP neighbour, but it can’t install it (for the router to use) because its unfeasible, which basically means that the router has no route to the “next-hop” IP. This was where things like the IGP come in, to distribute the point to point link subnets/networks, so routers within the AS can get to the various destinations, and install a route.
Route Table (Global RIB)
Checking the Routing Table (Global RIB) which is what the router actually uses to forward the packets around, these are the actual installed routes in live use. The Route Table (Global RIB) is an aggregation of all the route tables of the various protocols that might be running on the router, for example, BGP, EIGRP, OSPF, Static etc. You may of course see a network prefix (route) in the BGP Loc-RIB, which doesn’t appear in the Route Table (Global RIB) perhaps because there is another protocol with a lower AD (discussed earlier) that is stopping it from being installed.
tris-routerK.33 # show iproute
Ori Destination Gateway Mtr Flags VLAN Duration
#oa 1.1.1.6/32 192.168.100.61 12 UG-D---um--f- RK-RF 20d:17h:34m:33s
#d 1.1.1.12/32 1.1.1.12 1 U------um--f- RouterK-LP 20d:17h:34m:56s
#bi 10.1.0.0/16 192.168.100.61 1 UG-D---um--f- RK-RF 0d:0h:6m:22s
#bi 10.1.0.0/24 192.168.100.61 1 UG-D---um--c- RK-RF 12d:1h:6m:9s
#bi 10.1.1.0/24 192.168.100.61 1 UG-D---um--c- RK-RF 14d:23h:51m:56s
#bi 10.1.2.0/24 192.168.100.61 1 UG-D---um--c- RK-RF 14d:23h:51m:56s
#bi 10.1.3.0/24 192.168.100.61 1 UG-D---um--c- RK-RF 12d:1h:6m:6s
#bi 10.1.5.0/24 192.168.100.61 1 UG-D---um--c- RK-RF 12d:0h:52m:28s
#bi 10.2.0.0/24 192.168.100.61 1 UG-D---um--f- RK-RF 12d:1h:6m:6s
#bi 10.2.1.0/24 192.168.100.61 1 UG-D---um--f- RK-RF 14d:23h:51m:52s
#bi 10.2.2.0/24 192.168.100.61 1 UG-D---um--f- RK-RF 14d:23h:51m:52s
#bi 10.4.0.0/24 192.168.100.61 0 UG-D---um--f- RK-RF 20d:17h:34m:17s
#d 10.4.1.0/24 10.4.1.1 1 U------um--f- RouterK-LAN1 20d:17h:34m:55s
#be 10.5.0.0/24 192.168.100.66 1 UG-D---um--f- RK-RL 0d:0h:5m:11s
#be 10.5.1.0/24 192.168.100.66 1 UG-D---um--f- RK-RL 0d:0h:5m:11s
#be 10.5.2.0/24 192.168.100.66 1 UG-D---um--f- RK-RL 0d:0h:5m:11s
#be 10.5.3.0/24 192.168.100.66 1 UG-D---um--f- RK-RL 0d:0h:5m:11s
#oa 192.168.100.40/30 192.168.100.61 4 UG-D---um--f- RK-RF 14d:23h:51m:57s
#oa 192.168.100.44/30 192.168.100.61 4 UG-D---um--f- RK-RF 14d:23h:51m:53s
#d 192.168.100.60/30 192.168.100.62 1 U------um--f- RK-RF 20d:17h:34m:56s
#d 192.168.100.64/30 192.168.100.65 1 U------um--f- RK-RL 20d:17h:34m:56s
Origin(Ori): (ap) Auto-peering, (b) BlackHole, (be) EBGP, (bg) BGP, (bi) IBGP,
(bo) BOOTP,(ct) CBT, (d) Direct, (df) DownIF, (dv) DVMRP,
(e1) ISISL1Ext, (e2) ISISL2Ext, (h) Hardcoded, (hm) Host-mobility
(i) ICMP,(i1) ISISL1 (i2) ISISL2,(is) ISIS, (mb) MBGP,
(mbe) MBGPExt, (mbi) MBGPInter, (mp) MPLS Lsp,
(mo) MOSPF (o) OSPF, (o1) OSPFExt1, (o2) OSPFExt2,(oa) OSPFIntra
(oe) OSPFAsExt, (or) OSPFInter, (pd) PIM-DM, (ps) PIM-SM,
(r) RIP, (ra) RtAdvrt, (s) Static, (sv) SLB_VIP, (un) UnKnown,
(*) Preferred unicast route (@) Preferred multicast route,
(#) Preferred unicast and multicast route.
Flags: (b) BFD protection requested, (B) BlackHole, (c) Compressed, (D) Dynamic,
(f) Provided to FIB, (G) Gateway, (H) Host Route,
(I) ICMP ping protection requested, (l) Calculated LDP LSP,
(L) Matching LDP LSP, (m) Multicast, (p) BFD protection active,
(P) LPM-routing, (R) Modified, (s) Static LSP, (S) Static,
(t) Calculated RSVP-TE LSP, (T) Matching RSVP-TE LSP, (u) Unicast,
(U) Up, (3) L3VPN Route.Route Aggregation
Route aggregation is a technique where the characteristics of several routes are combined so that they are advertised as a single route. Using aggregation reduces the amount of information that a BGP router (speaker) must store and exchange with other BGP routers (speakers). Meaning reduced information stores, exchanged and a smaller routing table, which is especially important when dealing with an Internet scale routing table.
Let’s say we have these two routes:
- 10.1.0.0/24
- 10.1.1.0/24
They can be summarised (aggregated) into:
- 10.1.0.0/23
Or, if there is a predictable and hierarchical IP space, it could be summarised (aggregated) into:
- 10.1.0.0/16
Which would mean additional network prefixes (routes) such as 10.1.2.0/24 and 10.1.3.0/24, and so on, could be added in future, and they would automatically be catered for by this summary (aggregated) route, without needing to add additional routes to the Route Table.
Example
Let’s try an example shall we? We have our current network topology, we’ll be specifically looking at Router K and Router L.
So Router K is learning its routes for network prefix 10.1.0.0/16 from Router F, which is in turn learning the network prefix from Router B (in AS Blue 65001).
But when examining the route table on Router K, we see the following set of routes, we first have the supernet 10.1.0.0/16, but then individual routes for all the network prefixes from within AS Blue that are also being advertised into BGP.
These are superfluous routes in reality. Although the more specific route will win when being evaluated, all the next-hop are the same, so in this case the first route 10.1.0.0/16 would send the traffic in the right direction, so all the others are just not required.
This is a very specific example with a few routes, but as you can see at a larger scale this could be considerably more!
So this is where Route Aggregation comes in and can be used to reduce this set of routes down to something more sensible for when they are passed on to its BGP Neighbour(s), Router L in this particular example.
Router K
On Router K, we enable BGP Aggregation, then we create a rule to summarise the 10.1.0.0/16 into a summary route (aggregated route) that would include a particular set of network prefixes: 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24 and 10.1.5.0/24 in this case.
enable bgp aggregation
configure bgp add aggregate-address 10.1.0.0/16 as-set summary-onlyThe 10.1.0.0/16 is the network prefix we wish to summarise under, i.e. the network prefix that will be sent instead.
The summary-only keyword enables the summarization of routes not included in routing updates, it creates the aggregate route and suppresses advertisements of more specific routes to all neighbours; ergo the more specific 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24 and 10.1.5.0/24 network prefixes are summarised behind: 10.1.0.0/16 instead.
There is also the settings for as-set and as-match and there are the advertise-policy and attribute-policy, we’ll discuss all these in a moment in more detail.
Verify
So now we have applied the aggregation and summarisation, if we examine Router L, which is getting the updates from Router K, we see both the supernet network prefix and the individual network prefixes listed as individual routes.
But, afterwards we see only the single network prefix (route) for the 10.1.0.0/16 supernet, being that all the next-hops for these routes were all the same they can be safely summarised.
So essentially Router K is suppressing the routes for: 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24 and 10.1.5.0/24 so they are not transmitted to Router L (or any of its other neighbours for that matter).
AS-Set (as-set) and AS-Match (as-match)
So here is a very important consideration within BGP when using aggregation (summerisation) and that is how an aggregated route’s (network prefix) AS-Path are shown once two (or more) routes have been aggregated (summarised).
Let’s say we have these two routes (network prefixes):
10.1.0.0/24 AS_PATH: 65001
10.1.1.0/24 AS_PATH: 65002So the routes: 10.1.0.0/24 and 10.1.1.0/24, could be summarised into 10.0.0.0/23 instead.
But what would the AS-Path be for this new summarised route?
Would it be 65001 or 65002 or both, or neither nor something else entirely?
This is where the AS-Set and AS-Match configurations come in.
No AS-Set or No AS-Match
Firstly, let’s have a look and if we do not enable AS-Set or AS-Match, but enable aggregation (summerise) on a route.
So in this example we are enabling summarisation on Router K with the following command, but without enabling AS-Set or AS-Match
configure bgp add aggregate-address 10.1.0.0/16 summary-onlyThen we observe what the route’s (network prefix’s) AS-Path looks like, as you can see circled in red, it just shows the source AS, in this case AS Red (65004), even though the 10.1.0.0/16 originally came from AS Blue (65001).
Ergo, without AS-Set or AS-Match all the AS-Path information is lost, and instead the receiving router just sees the transmitting AS, which in this case is 65004 (AS Red).
This loss of information may or may not be problematic depending on your situation, however without AS-Set or AS-Match, you risk:
- Routing loops, because eBGP can’t see previous AS’s in a route, so can re-advertise a route back to its source.
- Incorrect best-path decisions.
- Overly attractive aggregate routes, which send traffic in sub optimal ways.
So essentially, not having AS-Set or AS-Match enabled means you lose the AS-Path information in the aggregated (summerised) route.
AS-Set
An AS-Set is an unordered list of network prefixes (routes) which are included in the AS-Path, if you specify to use AS-Set when summarising (aggregating) routes.
So for example the command below will enable AS-Set on Router K, which will then summarise (aggregate) the routes within 10.1.0.0/16 together into a single route, but also by specifying the AS-Set option, we will preserve the AS-Path information in an unordered list which is an aggregation of all the ASs that make up the various routes being aggregated prepended with the source AS (AS Red 65004) in our case.
Now, in our example we have only one source AS within the aggregate routes, but let’s say we had three routes (network prefixes) being aggregated together each with their own source AS; 65001, 65002 and 65003.
Then the AS-Path for the aggregate route would be: 65004 {65001 65002 65003} , notice they are in incremental order (that’s how they are presented), but it is an unordered set.
configure bgp add aggregate-address 10.1.0.0/16 as-set summary-onlyWhich then gives us the following when we examine how they are seen at Router L:
We can now see the source AS, just one in this case inside curly braces.
A set is an unordered list, although BGP puts the AS Numbers in ascending order, they are an unordered list of all the ASs of all the network prefixes being summarised.
They are unordered, because it would make no sense for them to be ordered, what order would they have in any case when you are aggregating two or more network prefixes (routes) together anyway?
AS-Match
The AS-Match argument in Extreme Networks XOS means that it will preserve the order of AS Numbers in the AS-Path for a summarised, aggregate route, so unlike AS-Set which creates an unordered list, this creates an ordered list of AS of all the aggregate routes.
But wait, that doesn’t make any sense how would it do that? Perhaps it does not. Let’s find out with a quick test.
Router H
But what we are now going to do is add another two network prefixes 10.5.4.0/24 and 10.5.5.0/24 and put that under a different aggregate route 10.5.4.0/22 advertised from a completely different AS so we can see how its path changes
create vlan "RouterH-LAN2" tag 1030
configure vlan "RouterH-LAN2" ipaddress 10.5.4.1/24
enable ipforwarding "RouterH-LAN2"
enable loopback-mode vlan "RouterH-LAN2"
configure bgp add network 10.5.4.0/24Router G
create vlan "RouterG-LAN2" tag 1031
configure vlan "RouterG-LAN2" ipaddress 10.5.5.1/24
enable ipforwarding "RouterG-LAN2"
enable loopback-mode vlan "RouterG-LAN2"
configure bgp add network 10.5.5.0/24Now on Router K, we’ll add an aggregation and then observe the result on Router L.
Router K
We’ll now start summarising those two networks on Router K, ready to observe on Router L.
configure bgp add aggregate-address 10.5.4.0/22 as-match summary-onlyWithout Summarisation (with AS-Match)
We can see the two routes which are coming from different source AS, 10.5.4.0/24 from 65002 and 10.5.5.0/24 from 65001.0.
With Summarisation (with AS-Match)
But now with AS-Match summarisation, we see only a single route for 10.5.4.0/22 (which is our aggregate/summary route), but notice the AS-Path, we have 65004 which is where Router L is seeing it learnt from, but then its put the other two AS in a set.
With Summarisation (with AS-Set)
So now let’s compare the above as observed on Router L, with AS-Set used in the configuration instead.
As we can see it all looks exactly the same!
Thoughts
In our example here for all intents and purposes it makes no difference to use AS-Set or AS-Match. In combining routes from two different sources AS, the order can’t be preserved, so it is not, and instead it is added as an AS-Set, even though the configuration says to use AS-Match instead.
However, there is potential that it can and will make a difference in certain scenarios, but just not the ones we’re able to test within the lab.
Continued Investigation
So if we now remove the network 10.5.5.0/24 from Router G and instead put that network on Router H, along with 10.5.4.0/24, so they are both now originating from the same AS and then have as-match configured on Router K to summarise the routes going to Router L, what do we then see?
We see a single route with an AS-Path of 65004 and 65002 which is what we’d expect, it’s not an AS-Set (notice the missing curly braces), so this order is preserved.
Break a Link
So we’re now going to down the link between Router D and Router F, so AS Green (65002) and AS Red (65004) cannot directly communicate any more, they must go via AS Blue (65001) instead.
If we then observe what happens on Router L, what do we then see?
We see three AS numbers listed, all in the expected order, i.e. AS Green (65002) originating the route, it being learnt via AS Blue (65001.0) and then Router L learning it from AS Red (65004).
Conclusion
If we swap Router K to as-set instead, we see something very interesting, and that proves that the AS-Match is doing what it is expected to and preserve the order of the AS-Path, unlike AS-Set which does not.
Summary Only, Advertise Policy and Attribute Policy
We’ll quickly and briefly go over these additional parts of the aggregation configuration, which give you some additional control.
Summary Only
Using the Summary Only argument means that the router suppresses any routes that fall within the summary aggregate route. So in our example:
- The 10.5.4.0/24 and 10.5.5.0/24 are being summarised by 10.5.4.0/22, both these /24 routes are suppressed, and instead a single 10.5.4.0/22 route is transmitted.
This is a quite blunt instrument and might be fine depending on what you are trying to achieve, but you may also want some additional control.
Advertise Policy
The advertisement policy command can be specified, along with a policy file, which then defines the routes that are to be included within the aggregation.
So rather than summarising (aggregating) 10.5.4.0/22 and 10.5.5.0/22 into 10.5.4.0/22, perhaps we just want 10.5.4.0/24 to be summarised, but for 10.5.5.0/24 to be transmitted as a separate route (network prefix).
This is where the advertisement policy can apply a bit of nuance.
Router K
We first create the policy file called: 10_5_4_0-22_Agg.pol
entry no_aggregation {
if match any {
nlri 10.5.5.0/24 ;
}
then {
deny ;
}
}
entry yes_aggregation {
if match any {
nlri 10.5.4.0/24 ;
}
then {
permit ;
}
}Then we apply it as follows, notice we also use the summary-only command to ensure that the summary route is also being provided.
configure bgp add aggregate-address 10.5.4.0/22 as-match advertise-policy 10_5_4_0-22_Agg summary-onlyVerify
Then, if we examine the Route Table on Router L, we can see that we are indeed seeing the summary route of 10.5.4.0/22, but now only the excluded route (network prefix) 10.5.5.0/24, with the 10.5.4.0/24 route (network prefix) not being transmitted separately.
We can further confirm this by checking the transmitted routes from Router K to Router L, and within that we can see that 10.5.4.0/24 is no longer being transmitted as a separate route.
This functionality can also be known as: suppress-map: Allows for granular control, letting you choose which specific routes to suppress while allowing others to be advertised alongside the summary or an unsuppress-map: Allows you to selectively advertise specific, suppressed routes to certain neighbours
Attribute Policy
You also have an option to modify the attributes of an aggregated (summerised) route when it is transmitted onto downstream routers; so the BGP attributes such as Local Preference (Local-Pref), the MED, AS_Path Prepending, Community strings and so on.
The aggregate (summary) route does not inherit attributes from its component routes, so you need to explicitly add attributes to the summary aggregate route if you want them to be added.
You may want to do this because without any Attribute Policy, the summary (aggregate) route might be too attractive (and selected when you don’t want it to be), not attractive enough (and thus ignored) or break the traffic engineering, meaning perhaps you are advertising a summary route to via two links to the outside world, and expecting link A to be primary and link B to be backup, if the route is bare, the downstream ISP may not know this (due to the lack of attributes) and you’ll get unexpected or suboptimal use of the links and your network.
As an example, let’s just set an attribute MED on the transmitted summarised (aggregate) route from Router K, we’re not going to do anything with it on Router L, but we just want to see that it is being transmitted with this value. If we wanted then on Router L we could make routing decisions based on this value, perhaps to direct traffic via that link (between Router L and Router K) rather than another link to reach the same destination, i.e. the traffic engineering aspects.
Router K
We first create a policy file: 10_5_4_0-22_Agg-Attrib.pol with the following contents:
entry set-community {
if match any {
nlri 10.5.4.0/22;
} then {
med add 50;
permit;
}
}Then we apply it with:
configure bgp add aggregate-address 10.5.4.0/22 as-match advertise-policy 10_5_4_0-22_Agg summary-only attribute-policy 10_5_4_0-22_Agg-AttribVerify
Finally on Router L, let’s have a look at the route being sent and if it’s had its MED attribute changed or not. And as we can see it has, so this shows that the summary (aggregate) route indeed has its MED updated.
https://extreme-networks.my.site.com/ExtrArticleDetail?an=000120646
Conclusion
We’ve explored a number of different topics covering the RIB and Routing Tables, Administrative Distance and Route Aggregation (Summarisation), all sorts of different things that are worth understanding when working with BGP.
Additional Information
- https://documentation.extremenetworks.com/exos_32.7.1/downloads/EXOS_User_Guide_32.7.1.pdf
- https://documentation.extremenetworks.com/exos_commands_32.7.1/downloads/EXOS_Command_Reference_32.7.1.pdf
- https://documentation.extremenetworks.com/exos_32.6.1/GUID-21562F39-BB0D-46A3-B815-5B711D8DF508.shtml
- https://documentation.extremenetworks.com/VOSS/SW/84/VOSSUserGuide/GUID-D79352A9-532E-4AFB-9ADC-1C9A38D47577.shtml
- https://documentation.extremenetworks.com/exos_22.1/GUID-1B90BC12-6F57-436A-8DD7-227267F4FE9F.shtml
- https://support.huawei.com/enterprise/en/doc/EDOC1100516100/907e1c81/understanding-bgp-route-summarization#:~:text=BGP%20supports%20automatic%20and%20manual,summary%20route%20to%20BGP%20peers.
- https://www.analysisman.com/2025/05/extreme-troubleshooting-bgp.html