No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Alarm Handling

AR100, AR120, AR160, AR1200, AR2200, AR3200, and AR3600 V300R003

This document provides the trap description, attributes, parameters, impact on the system, possible causes, procedures, and references. This document provides a complete set of traps, through which intended readers are kept of the running status of the device so as to locate faults.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.3 hwBgpPeerGRStatusChange

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.3 hwBgpPeerGRStatusChange

Description

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.3

Minor

communicationsAlarm(2)

Parameters

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:
  • 1: ipv4

  • 2: ipv6

  • 25: vpls

  • 196: l2vpn

Safi

Indicates the sub-address family:
  • 1: unicast

  • 2: multicast

  • 4: mpls

  • 65: vpls

  • 128: vpn

PeerType

Indicates the address type of the peer:
  • 1: ipv4

  • 2: ipv6

PeerRemoteAddr

Indicates the address of the peer.

GrStatus

Indicates the GR status of the peer:
  • 1: peerNotBeingHelped

  • 2: peerRestarting

  • 3: peerFinishRestart

  • 4: peerHelping

Impact on the System

  • 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.

Possible Causes

The GR status of either BGP peer that succeeded in the GR capability negotiation changed.

Procedure

  1. Do as follows according to the value of the parameter GrStatus:

    • 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.

  2. Run the display ip routing-table ipv4-address command to check whether the address of the peer exists.

    • 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.

  3. During GR, active/standby switchover is complete. In this case, you need to check whether the local end performs active/standby switchover actively.

    • If so, go to Step 5.

    • If not, go to Step 4.

  4. Collect alarm information and configuration information, and then contact technical support personnel.
  5. End.

Related Information

None.

Translation
Download
Updated: 2019-03-06

Document ID: EDOC1100041475

Views: 75117

Downloads: 47

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next