BGP/3/GRSTATUSCHANGE:OID [oid] The graceful restart status of the BGP peer changed. (InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], GrStatus=[integer])
The GR status of either BGP speaker that succeeded in the GR capability negotiation changed.
| Alarm ID | Alarm Severity | Alarm Type |
|---|---|---|
1.3.6.1.4.1.2011.5.25.177.1.3.3 |
Minor |
communicationsAlarm(2) |
| Name | Meaning |
|---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceId |
Indicates the index of the instance to which the peer belongs. |
Afi |
Indicates the address family:
|
Safi |
Indicates the sub-address family:
|
PeerType |
Indicates the address type of the peer:
|
PeerRemoteAddr |
Indicates the address of the peer. |
GrStatus |
Indicates the GR status of the peer:
|
If an alarm of the type peerNotBeingHelped(1) is generated, it indicates that the local end fails to function as the GR Helper during the restart of the BGP peer. As a result, services will be interrupted until the peer session is reestablished and all routes are converged.
If an alarm of the type peerRestarting(2) is generated, it indicates that the local end detects that the BGP peer is performing graceful restarting. When the routing protocol on which BGP route iteration depends has the GR capability, services will not be affected. Otherwise, services will be interrupted.
If an alarm of the type peerFinishRestart(3) is generated, it indicates that the BGP peer session becomes normal. In this case, no services will be affected.
If an alarm of the type peerHelping(4) is generated, it indicates that the BGP peer is helping the local end to perform GR. When the routing protocol on which BGP route iteration depends has the GR capability, services will not be affected. Otherwise, services will be interrupted.
The GR status of either BGP peer that succeeded in the GR capability negotiation changed.
If an alarm of the type peerNotBeingHelped(1) is generated, it indicates that the BGP peer will not be helped during restarting. Then, go to Step 4.
If an alarm of the type peerRestarting(2) is generated, it indicates that the BGP peer is detected restarting. Then, go to Step 2.
If an alarm of the type peerFinishRestart(3) is generated, it indicates that the BGP peer finishes the latest GR. In this case, no action is required. Then, go to Step 5.
If an alarm of the type peerHelping(4) is generated, it indicates that the BGP peer is helping the local end to perform GR. Then, go to Step 3.
If so, it indicates that the local end is performing GR. In this case, no services will be affected, and no action is required. Then, go to Step 5.
If not, go to Step 4.
If so, go to Step 5.
If not, go to Step 4.