Cisco Cisco ASR 5700 Guía Para Resolver Problemas
Solution
Question
If the incident was at 13:51:45 per the traps/logs, would it not be expected for the peers to go down no sooner
than the period of time of the BGP hold timer?
than the period of time of the BGP hold timer?
Answer
The BGP settings for all these peers are the same as this:
timers bgp keepalive-interval 10 holdtime-interval 60
While configured for 60 seconds, the negotiation with the peer honors the lower value, which is 30 seconds:
******** show ip bgp neighbors *******
Saturday June 13 14:42:38 UTC 2015
BGP neighbor is 55.55.245.4, remote AS 22394, local AS 64873, external link
BGP version 4, remote router ID 55.54.244.197
BGP state = Established,up for 5d04h29m
Hold time is 30 seconds, keepalive interval is 10 seconds
Configured Hold time is 60 seconds, keepalive interval is 10 seconds
How can the peers that go down between 13:52:00 and 13:52:10 be explained when the event was at
13:51:45?
13:51:45?
The answer is that it is possible that connectivity was compromised as a result of the Network Processor Unit
(NPU) issue before the first log was displayed. For example, make an assumption of 5 seconds at 13:51:40.
Each BGP peer pair sends/receives keep-alives every 10 seconds, each on their own "cycle". BGP peer pairs
are not all synced to one another with regards to the keep-alive intervals, though each pair does have the same
setting of 10 seconds. You can assume that in any 10 second interval of time, all peers have sent keepalives
since the keepalive interval is 10 seconds. If connectivity broke at 13:51:40, then all peer pairs sent their last
keepalives sometime between 13:51:30 and 13:51:40 based on what their cycles were (remember each pair is
unrelated to any other pair). In this case, with no further keepalives received after this time range, it means
that the 30 second expiry would occur in the range of 13:52:00 - 13:52:10, which is precisely when all the
peers were marked down.
(NPU) issue before the first log was displayed. For example, make an assumption of 5 seconds at 13:51:40.
Each BGP peer pair sends/receives keep-alives every 10 seconds, each on their own "cycle". BGP peer pairs
are not all synced to one another with regards to the keep-alive intervals, though each pair does have the same
setting of 10 seconds. You can assume that in any 10 second interval of time, all peers have sent keepalives
since the keepalive interval is 10 seconds. If connectivity broke at 13:51:40, then all peer pairs sent their last
keepalives sometime between 13:51:30 and 13:51:40 based on what their cycles were (remember each pair is
unrelated to any other pair). In this case, with no further keepalives received after this time range, it means
that the 30 second expiry would occur in the range of 13:52:00 - 13:52:10, which is precisely when all the
peers were marked down.
In short, after the point in time that connectivity is broken (whether that is able to be determined or not is
another question), BGP would be expected to be marked down some time between the hold time interval and
the hold time interval minus the agreed keepalive interval. In this case that would be between 20 and 30
seconds.
another question), BGP would be expected to be marked down some time between the hold time interval and
the hold time interval minus the agreed keepalive interval. In this case that would be between 20 and 30
seconds.
Related Information
ASR5000 System Administration Guide - Cisco Systems
•
Technical Support & Documentation - Cisco Systems
•
Updated: Jul 31, 2015
Document ID: 119157