BGP Cease Subcode definition

wangguan

BGP Cease Subcode definition
When you deal with Cisco and BGP, you probably know syslog messages like this:
Apr 11 16:34:38 ROUTER 1026843: Apr 11 16:34:38.010 CET: %BGP-3-NOTIFICATION: received from neighbor 80.x.x.x 6/2 (cease) 0 bytes
Apr 17 14:13:41 ROUTER 30082: Apr 17 14:13:41.126 CET: %BGP-3-NOTIFICATION: received from neighbor 80.x.x.x 6/0 (cease) 0 bytes
Apr 27 05:30:39 ROUTER 1028828: Apr 27 05:30:39.833 CET: %BGP-3-NOTIFICATION: received from neighbor 80.x.x.x 6/3 (cease) 0 bytes
May  5 08:12:03 ROUTER 38467: May  5 08:12:03.644 CET: %BGP-3-NOTIFICATION: received from neighbor 80.x.x.x 6/4 (cease) 0 bytes
May  7 06:06:04 ROUTER 38956: May  7 06:06:04.092 CET: %BGP-3-NOTIFICATION: received from neighbor 80.x.x.x 6/6 (cease) 0 bytes
May 10 13:28:39 ROUTER 4366: May 10 13:28:38.919 CET: %BGP-3-NOTIFICATION: received from neighbor 80.x.x.x 6/7 (cease) 0 bytes
I think in backbone environments, your BGP should be stable and you don’t want to see lots of these messages. But at a big peering point, it’s the normal “noise”….
According to
RFC4486
, Cisco reports the Subcode of Cease Notification Message (blue) in the log message.
Here’s an overview of subcode definition:
Subcode
Meaning
1
Maximum Number of Prefixes Reached
2
Administrative Shutdown
3
Peer De-configured
4
Administrative Reset
5
Connection Rejected
6
Other Configuration Change
7
Connection Collision Resolution
8
Out of Resources
and here comes a deeper explanation (also taken from the RFC):

• If a BGP speaker decides to terminate its peering with a neighbor because the number of address prefixes received from the neighbor exceeds a locally configured upper bound,  then the speaker MUST send to the neighbor a NOTIFICATION message  with the Error Code Cease and the Error Subcode “Maximum Number of Prefixes Reached“.
  
• If a BGP speaker decides to administratively shut down its peering with a neighbor, then the speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode “Administrative Shutdown“.
  
• If a BGP speaker decides to de-configure a peer, then the speaker  SHOULD send a NOTIFICATION message with the Error Code Cease and the  Error Subcode “Peer De-configured“.
  
• If a BGP speaker decides to administratively reset the peering with a neighbor, then the speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode “Administrative Reset“.
  
• If a BGP speaker decides to disallow a BGP connection (e.g., the peer is not configured locally) after the speaker accepts a transport protocol connection, then the BGP speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode “Connection Rejected“.
  
• If a BGP speaker decides to administratively reset the peering with a neighbor due to a configuration change other than the ones described above, then the speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode “Other Configuration Change“.
  
• If a BGP speaker decides to send a NOTIFICATION message with the Error Code Cease as a result of the collision resolution procedure then the subcode SHOULD be set to “Connection Collision Resolution“.
  
• If a BGP speaker runs out of resources (e.g., memory) and decides to reset a session, then the speaker MAY send a NOTIFICATION message with the Error Code Cease and the Error Subcode “Out of Resources“.

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/88305/showart_2055204.html