BGP troubleshooting follows a fixed sequence. Confirm the session, confirm what was received, confirm what was selected, confirm what was advertised. Each vendor answers those four questions with different syntax and, in two cases, with different prerequisites.
The commands
| Question | Cisco IOS | Juniper | Alcatel, Nokia SR OS | Huawei VRP |
|---|---|---|---|---|
| Session summary | show ip bgp summary | show bgp summary | show router bgp summary | display bgp peer |
| Session detail | show ip bgp neighbors | show bgp neighbor | show router bgp neighbor | display bgp peer verbose |
| Local table | show ip bgp | show route protocol bgp | show router bgp routes | display bgp routing-table |
| One prefix | show ip bgp 10.0.0.0/24 | show route 10.0.0.0/24 detail | show router bgp routes 10.0.0.0/24 | display bgp routing-table 10.0.0.0 24 |
| Received from a peer | show ip bgp neighbors 1.1.1.1 received-routes | show route receive-protocol bgp 1.1.1.1 | show router bgp neighbor 1.1.1.1 received-routes | display bgp routing-table peer 1.1.1.1 received-routes |
| Advertised to a peer | show ip bgp neighbors 1.1.1.1 advertised-routes | show route advertising-protocol bgp 1.1.1.1 | show router bgp neighbor 1.1.1.1 advertised-routes | display bgp routing-table peer 1.1.1.1 advertised-routes |
The last two rows are the ones that matter during an incident and the ones most likely to disappoint.
Received routes may not be stored
A router is not obliged to keep paths that inbound policy rejected, and by default several platforms discard them at the point of receipt to save memory.
The command then returns nothing, which looks identical to a neighbour that advertised nothing. Retaining them requires either soft reconfiguration, which stores an unmodified copy and costs memory proportional to the table, or the route refresh capability, which asks the neighbour to resend and is the modern approach.
The distinction between received routes and routes actually accepted is worth keeping clear, because the two commands answer different questions and a policy that drops everything is invisible if only one of them is checked.
The summary line carries more than it appears to
The state column shows established or a numeric prefix count depending on platform, and where a number appears the session is up and that is how many prefixes were accepted.
A session cycling between states is a different fault from one that is established with zero prefixes. The first is reachability, authentication, or a mismatched autonomous system number. The second is policy, and no amount of examining the session will reveal it.
Reading a single prefix is faster than reading the table
The per prefix command shows every path received, which one was selected, and on most platforms the reason the others lost. That is the fastest route to understanding a selection outcome that seems wrong.
It also exposes the next hop actually installed, which is where internal sessions most often fail. A path can be present, valid, and unusable because its next hop is not reachable through the interior protocol, and the per prefix output states that plainly while the table view does not.
Where the platforms diverge most
Juniper separates the routing table from the protocol view more strictly than the others, so several questions are answered from the route command with a protocol filter rather than from a BGP command.
Nokia scopes everything under the router instance, which is consistent and verbose. Huawei follows the Cisco structure closely while replacing show with display and neighbour with peer, so the translation is largely mechanical once those two substitutions are made.
Note: before concluding that a neighbour is not advertising a prefix, confirm that received routes are being retained. On a router without soft reconfiguration or route refresh, the command reports an empty result whether the neighbour sent nothing or the policy discarded everything.