C.2.a) “Show ip bgp summary”
This command allows us to see if the router has been able to set up the Ibgp and Ebgp session with the other peers.
1. The command “show ip bgp summary” will give some useful information.
a) The “BGP table version” which increases and tracks the changes of the router which has been advertised to the peers.
This table should always increment and never be static. It is important to compare the table version of the router with the table version of each neighbor.
As you can deduce, if the table version of the neighbor is lower than the main table version, it means that the neighbor is not yet fully updated. The BGP timer advertisement value is by default 30 seconds.
b) The up/down time session will indicate if you are a victim of flap issues (transmission line or IP) with your neighbor.
Generally, by ruling an ISP, the session should not flap, and the up/down should not be reset often. If the up/down is resetting every day or week, it can deteriorate your quality of service given to your customers. Some upstream/transit providers also process to a damping case if flaps occurred too many times from a customer.
c) The number of prefixes that you receive from your neighbor.
In case of an Ebgp speaker, if you ask the full internet routing table to be sent, you should receive at least 400k prefixes.
The other common case is to ask only the default route (“0.0.0.0/0”); then you should receive just one prefix.
d) How long the neighbor has been in the current state and the name of the current state (the state “Established” is not printed out).
e) The “InQ” shows how many messages have been received but not yet processed. A high InQ number indicates an insufficiency of CPU resources to process the input.
“OutQ” shows how many outgoing messages are queued. A high OutQ number indicates a lack of bandwidth to transmit on the outgoing messages or CPU overload from the other router.
f) The amount of memory that is being used for the BGP data structures. This information is very important to check and compare with the “show memory command”, in order to see if the router has enough memory or if the memory is not fragmented.
2. For RT-B and RT-A, we get the resulting outputs.
• As said previously, we could see that the table version of the router is slightly different to the one of the BGP neighbors. This is a correct result; BGP neighbor updates are correctly incremented to the router (BGP and main routing table).
• The InQ and OutQ columns are empty, and additionally, all memory outputs, show that the router is perfectly capable of handling the multiple BGP sessions.
• We can note that there is not any indication on the nature of the BGP peers (Ebgp or Ibgp). For RT-B, we can see the three BGP peers, ISP-B, ISP-C and ISP-A(“RT-A”). Regarding the Ibgp session, we can observe that RT-A sends the Internet table to RT-B. This result, as expected, is used in order to allow the outgoing traffic to leave through RT-A, in case of cut of ISP-B and ISP-C links.
3. For information, here is the output of RT-A. We can check that Customer-C is advertising us three prefixes.