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

S9300, S9300E, and S9300X V200R013C00

This document provides the explanations, causes, and recommended actions of alarms on the product.
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

BGP

BGP_1.3.6.1.2.1.15.7.1 bgpEstablished

Description

BGP/2/ESTABLISHED:OID [oid] The BGP FSM enters the Established state. (BgpPeerRemoteAddr=[BgpPeerRemoteAddrValue], BgpPeerLastError=[BgpPeerLastErrorValue], BgpPeerState=[BgpPeerStateValue])

Indicates that this trap was generated when the BGP FSM was in the Established state.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.15.7.1 Major communicationsAlarm(2)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

BgpPeerRemoteAddr

Indicates the address of the peer.

BgpPeerLastError

Indicates the error code of the BGP Notification when the neighbor relationship is disconnected for the last time.

The value is expressed in the format of [ErrorCode][ErrorSubCode]. [ErrorCode] refers to the error code and [ErrorSubCode] refers to the error subcode. Take the integer 35 as an example, figure 3 is the error code and figure 5 is the error subcode. For detailed information about the error code, refer to BGP Error Code.

If the value is 0, it indicates that no error occurs.

BgpPeerState

Indicates the status of the BGP peer.
  • 1 Idle: indicates that BGP denies any request of entering. This is the initiatory status of BGP.

    Upon receiving a Start event, BGP initiates a TCP connection to the remote BGP peer, starts the ConnectRetry Timer with the initial value, detects a TCP connection initiated by the remote BGP peer, and changes its state to Connect.

  • 2 Connect: indicates that BGP performs other actions after the TCP connection is set up.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value, initiates a TCP connection to the remote BGP peer, and stays in the Connect state.

  • 3 Active: indicates that BGP tries to set up TCP connection. This is the intermediate status of BGP.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value and changes its state to Connect.

    • If BGP initiates a TCP connection with an unknown IP address, the TCP connection fails. When this occurs, BGP restarts the ConnectRetry Timer with the initial value and stays in the Active state.

  • 4 OpenSent: indicates that BGP has sent one Open message to its peer and waits for the other Open message from the peer.
    • If there are no errors in the Open message received, BGP changes its state to OpenConfirm.

    • If there are errors in the Open message received, BGP sends a Notification message to the remote peer and changes its state to Idle.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

  • 5 OpenConfirm: indicates that BGP waits for a Notification message or a Keepalive message.
    • If BGP receives a Notification message, or the TCP connection fails, BGP changes its state to Idle.

    • If BGP receives a Keepalive message, BGP changes its state to Established.

  • 6 Established: indicates that BGP peers can exchange Update, Notification and Keepalive packets.
    • If BGP receives an Update or a Keepalive message, its state stays in Established.

    • If BGP receives a Notification message, BGP changes its state to Idle.

Impact on the System

The BGP neighbor relationship can be normally established.

Possible Causes

The BGP neighbor relationship was established.

Procedure

  1. This alarm message is informational only, and no action is required.

BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Description

BGP/2/BACKWARD:OID [oid] The BGP FSM moves from a higher numbered state to a lower numbered state. (BgpPeerRemoteAddr=[ipaddr], InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], InterfaceIndex=[integer], BgpPeerLastError=[octet], BgpPeerState=[integer], BgpPeerUnavaiReason=[gauge], InterfaceName=[octet])

Indicates that this trap was generated when the BGP state machine moved from a higher numbered state, namely, Openconfirm or Established, to a lower numbered state.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.15.7.2 Major communicationsAlarm(2)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

BgpPeerRemoteAddr

Indicates the address of the peer.

InstanceId

Instance ID

Afi

Address family

Safi

Sub-address family

PeerType

Peer type

PeerRemoteAddr

Peer address

InterfaceIndex

Interface index

BgpPeerLastError

Indicates the error code of the BGP Notification when the neighbor relationship is disconnected for the last time.

The value is expressed in the format of [ErrorCode][ErrorSubCode]. [ErrorCode] refers to the error code and [ErrorSubCode] refers to the error subcode. Take the integer 35 as an example, figure 3 is the error code and figure 5 is the error subcode. For detailed information about the error code, refer to BGP Error Code.

If the value is 0, it indicates that no error occurs.

BgpPeerState

Indicates the status of the BGP peer.
  • 1 Idle: indicates that BGP denies any request of entering. This is the initiatory status of BGP.

    Upon receiving a Start event, BGP initiates a TCP connection to the remote BGP peer, starts the ConnectRetry Timer with the initial value, detects a TCP connection initiated by the remote BGP peer, and changes its state to Connect.

  • 2 Connect: indicates that BGP performs other actions after the TCP connection is set up.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value, initiates a TCP connection to the remote BGP peer, and stays in the Connect state.

  • 3 Active: indicates that BGP tries to set up TCP connection. This is the intermediate status of BGP.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value and changes its state to Connect.

    • If BGP initiates a TCP connection with an unknown IP address, the TCP connection fails. When this occurs, BGP restarts the ConnectRetry Timer with the initial value and stays in the Active state.

  • 4 OpenSent: indicates that BGP has sent one Open message to its peer and waits for the other Open message from the peer.
    • If there are no errors in the Open message received, BGP changes its state to OpenConfirm.

    • If there are errors in the Open message received, BGP sends a Notification message to the remote peer and changes its state to Idle.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

  • 5 OpenConfirm: indicates that BGP waits for a Notification message or a Keepalive message.
    • If BGP receives a Notification message, or the TCP connection fails, BGP changes its state to Idle.

    • If BGP receives a Keepalive message, BGP changes its state to Established.

  • 6 Established: indicates that BGP peers can exchange Update, Notification and Keepalive packets.
    • If BGP receives an Update or a Keepalive message, its state stays in Established.

    • If BGP receives a Notification message, BGP changes its state to Idle.

BgpPeerUnavaiReason

Cause for the peer disconnection

  • 1 Configuration lead peer down: The configuration causes the peer disconnection.

  • 2 Receive notification: Notification packets are received.

  • 3 Receive error packet: Error packets are received.

  • 4 Hold timer expire: The Hold timer expires.

  • 5 Remote peer not reachable: The remote peer is unreachable.

  • 6 Direct connect-interface down: The directly connected interface is Down.

  • 7 Route limit: The number of routes exceeds the upper limit.

InterfaceName

Interface name

Impact on the System

The BGP neighbor will be disconnected, and the BGP route received from the neighbor will be deleted. The packet forwarding based on the BGP route will fail.

Possible Causes

1. The BGP holdtimer timed out and did not receive the Keepalive packet.

2. BGP received incorrect BGP packets.

3. The BGP neighbor relationship was reset and the neighbor relationship was automatically interrupted.

4. BGP received Notification packets from the neighbor.

Procedure

  1. Run the display bgp peer ipv4-addresses log-info command to check the check the Error field in the command output. You can view the Error Code and Sub Error Code in the received Notification in the form of [ErrorCode][ErrorSubCode].

    • If the error code of the Notification is 1, it indicates that the BGP module receives the packet with incorrect headers. Then, go to Step 23.

    • If the error code of the Notification is 2, it indicates that the BGP module receives the incorrect Open packet. Then, go to Step 23.

    • If the error code of the Notification is 3, it indicates that the BGP module receives the incorrect Update packet. Then, go to Step 23.

    • If the error code of the Notification is 4, it indicates that till the Holdtimer times out, the BGP module does not receive the Keepalive packet. Then, go to Step 4.

    • If the error code of the Notification is 5, it indicates that the finite state machine of the BGP module is faulty. Then, go to Step 23.

    • If the error code of the Notification is 6, go to Step 2.

  2. If the error code of the Notification is 6, it indicates that BGP automatically closes the connection. Then, you need to run the display bgp peer ipv4-address log-info command to view the Notification field and check whether the Notification is sent by the switch that generates the trap.

    • If "Send Notification" is displayed, it indicates that the local switch actively sends the Notification. Then, go to Step 3.

    • If "Receive Notification" is displayed, it indicates that the local switch receives the Notification. Then, go to Step 22.

  3. Search for the reset bgp all and reset bgp ipv4-address commands in the user logs to check whether BGP is reset on the local end; or search for the peer ipv4-address enable command to check whether the peer is enabled in other address families on the local, or parameters for the BGP connection are configured.

    • If so, it indicates that incorrect configurations cause the trap, and therefore no action is required. Then, go to Step 24.

    • If not, go to Step 23.

  4. If the error code is 4, it indicates that the BGP disconnection is caused by the timeout of the Holdtimer. Then, you need to check whether the address of the BGP neighbor can be pinged successfully.

    • If so, go to Step 21.

    • If not, go to Step 5.

  5. Run the display ip routing-table command to check whether the Destination/Mask field has the route to the peer address.

    • If so, go to Step 7.

    • If not, go to Step 8.

  6. Run the display acl all command to check whether the switch is configured with the ACL that disables TCP port 179.

    • If so, go to Step 9.

    • If not, go to Step 10.

  7. Run the display ip interface command to check whether the values of Physical and Protocol fields of the outbound interface are Up.

    • If so, go to Step 23.

    • If not, go to Step 11.

  8. Check the origin of the route with the BGP peer address.

    • If the route is originated from OSPF, go to Step 12.

    • If the route is originated from IS-IS, go to Step 13.

    • Else, go to Step 23.

  9. Delete the ACL that disables the TCP port 179, and check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 10.

  10. Check the BGP configuration to see whether loopback interfaces are used to establish BGP peers.

    • If so, go to Step 14.

    • If not, go to Step 15.

  11. Enter the view of the outbound interface, and run the display this command to check whether the interface is shut down.

    • If so, run the undo shutdown command to enable the interface.

    • If not, go to Step 22.

  12. Run the display ospf peer command to check whether the OSPF peer relationship is established.

  13. Run the display isis peer command to check whether the IS-IS peer relationship is established.

  14. Check whether the peer connect-interface is configured for specifying the source address.

    • If so, go to Step 15.

    • If not, go to Step 16.

  15. If BGP is the EBGP neighbor relationship and multiple hops exist between EBGP neighbors, check whether the peer ebgp-max-hop is configured.

    • If so, go to Step 17.

    • If not, go to Step 19.

  16. Configure the peer connect-interface command. The parameter in the command must be the local interface that establishes a connection with the peer. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  17. Check whether the peer valid-ttl-hops hops command is configured.

    • If so, go to Step 18.

    • If not, go to Step 23.

  18. If the peer valid-ttl-hops hops is configured, check whether the TTL of the packet to the peer ranges from [255-hops+1] to 255.

    • If so, go to Step 23.

    • If not, go to Step 20.

  19. Configure the peer ebgp-max-hop. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  20. Changed the value of the peer valid-ttl-hops hops and make it within the range from [255-hops+1] to 255. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  21. Run the display cpu-usage command to check whether the CPU usage whether the CPU usage remains 100% in a period.

    • If so, go to Step 23.

    • If not, go to Step 6.

  22. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer switch, the peer is enabled in other address families on the local, and parameters for BGP connection are configured. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  23. Collect alarm information and configuration information, and then contact technical support personnel.
  24. End.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed

Description

BGP/2/ROUTETHRESHOLDEXCEED:OID [oid] The number of routes received from the BGP peer exceeded the alarm threshold. (InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], MaxRouteNum=[gauge], AlarmThreshold=[gauge])

The number of routes received from the peer configured with the route limit exceeded the alarm threshold (MaxRouteNum x AlarmThreshold).

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.1 Major

qualityOfServiceAlarm(3)

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.

MaxRouteNum

Indicates the maximum number of routes that can be received from the peer.

AlarmThreshold

Indicates the alarm threshold (expressed in percentage) for the route limit on the peer.

Impact on the System

  • If the peer is configured with the peer route-limit command in which the alarm threshold is set to 100% and the keyword alert-only is not specified, the peer session will be interrupted, and all the received routes will be deleted.

  • If the peer is configured with other parameters, no services will be affected.

Possible Causes

The number of routes received from the peer configured with the route limit exceeded the alarm threshold.

Procedure

  1. Run the display bgp peer ipv4-address verbose command to view the Received total routes field and check whether the number of routes currently received from the peer exceeds the upper limit, which equals the maximum number of allowed routes multiplied by the alarm threshold (expressed in percentage).

    • If so, go to Step 2.

    • If not, go to Step 10.

  2. Check whether excessive routes are required to meet the requirements of actual applications.

    • If so, go to Step 8.

    • If not, go to Step 3.

  3. View the user log to check whether the local inbound policy is changed. For example, configuring the peer route-policy, peer ip-prefix, or peer filter-policy command causes excessive and unnecessary routes to be received.

    • If so, go to Step 4.

    • If not, go to Step 5.

  4. Update the local inbound policy. For example, configure the peer route-policy, peer ip-prefix, or peer filter-policy command to deny unnecessary routes. Then, go to Step 9.
  5. Contact the maintenance personnel of the remote device to check whether the routes advertised to the local device are necessary routes.

    • If so, go to Step 6.

    • If not, go to Step 7.

  6. Advise the maintenance personnel of the remote device to summarize routes so that the number of routes to be advertised can be reduced. Then, go to Step 9.
  7. Advise the maintenance personnel of the remote device to change the policy for importing or advertising routes so that the unnecessary routes can be withdrawn. Then, go to Step 9.
  8. Increase the maximum number of routes that can be received from the peer. Then, go to Step 9.
  9. Check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.2 hwBgpPeerRouteNumThresholdClear appears.

    • If so, go to Step 11.

    • If not, go to Step 10.

  10. Collect alarm information and configuration information, and then contact technical support personnel.
  11. End.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.2 hwBgpPeerRouteNumThresholdClear

Description

BGP/2/ROUTETHRESHOLDCLEAR:OID [oid] The number of routes received from the BGP peer decreased below the alarm threshold. (InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], MaxRouteNum=[gauge], AlarmThreshold=[gauge])

The number of routes received from the peer configured with the route limit decreased below the alarm threshold (MaxRouteNum x AlarmThreshold).

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.2 Major

qualityOfServiceAlarm(3)

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.

MaxRouteNum

Indicates the maximum number of routes that can be received from the peer.

AlarmThreshold

Indicates the alarm threshold (expressed in percentage) for the route limit on the peer.

Impact on the System

None.

Possible Causes

The number of routes received from the peer configured with the route limit decreased below the alarm threshold.

Procedure

  1. This alarm message is informational only, and no action is required.

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.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.9 hwBgpPeerEstablished

Description

BGP/2/HWESTABLISHED:OID [oid] The BGP FSM enters the Established state. (InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], PeerLastError=[octet], PeerState=[integer])

Indicates that this trap was generated when the BGP FSM was in the Established state.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.9 Major 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.

PeerLastError

Indicates the error code of the BGP Notification when the neighbor relationship is disconnected for the last time.

The value is expressed in the format of [ErrorCode][ErrorSubCode]. [ErrorCode] refers to the error code and [ErrorSubCode] refers to the error subcode. Take the integer 35 as an example, figure 3 is the error code and figure 5 is the error subcode. For detailed information about the error code, refer to BGP Error Code.

If the value is 0, it indicates that no error occurs.

PeerState

Indicates the status of the BGP peer.
  • Idle: indicates that BGP denies any request of entering. This is the initiatory status of BGP.

    Upon receiving a Start event, BGP initiates a TCP connection to the remote BGP peer, starts the ConnectRetry Timer with the initial value, detects a TCP connection initiated by the remote BGP peer, and changes its state to Connect.

  • Connect: indicates that BGP performs other actions after the TCP connection is set up.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value, initiates a TCP connection to the remote BGP peer, and stays in the Connect state.

  • Active: indicates that BGP tries to set up TCP connection. This is the intermediate status of BGP.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value and changes its state to Connect.

    • If BGP initiates a TCP connection with an unknown IP address, the TCP connection fails. When this occurs, BGP restarts the ConnectRetry Timer with the initial value and stays in the Active state.

  • OpenSent: indicates that BGP has sent one Open message to its peer and waits for the other Open message from the peer.
    • If there are no errors in the Open message received, BGP changes its state to OpenConfirm.

    • If there are errors in the Open message received, BGP sends a Notification message to the remote peer and changes its state to Idle.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

  • OpenConfirm: indicates that BGP waits for a Notification message or a Keepalive message.
    • If BGP receives a Notification message, or the TCP connection fails, BGP changes its state to Idle.

    • If BGP receives a Keepalive message, BGP changes its state to Established.

  • Established: indicates that BGP peers can exchange Update, Notification and Keepalive packets.
    • If BGP receives an Update or a Keepalive message, its state stays in Established.

    • If BGP receives a Notification message, BGP changes its state to Idle.

Impact on the System

The BGP neighbor relationship can be normally established.

Possible Causes

The BGP neighbor relationship was established.

Procedure

  1. This alarm message is informational only, and no action is required.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.10 hwBgpPeerBackwardTransition

Description

BGP/2/HWBACKWARD:OID [oid] The BGP FSM moves from a higher numbered state to a lower numbered state. (InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], InterfaceIndex=[integer], PeerLastError=[octet], PeerState=[integer], PeerUnavaiReason=[gauge], InterfaceName=[octet])

Indicates that this trap was generated when the BGP state machine moved from a higher numbered state, namely, Openconfirm or Established, to a lower numbered state.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.10 Major 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.

InterfaceIndex

Indicates the index of the interface.

PeerLastError

Indicates the error code of the BGP Notification when the neighbor relationship is disconnected for the last time.

The value is expressed in the format of [ErrorCode][ErrorSubCode]. [ErrorCode] refers to the error code and [ErrorSubCode] refers to the error subcode. Take the integer 35 as an example, figure 3 is the error code and figure 5 is the error subcode. For detailed information about the error code, refer to BGP Error Code.

If the value is 0, it indicates that no error occurs.

PeerState

Indicates the status of the BGP peer.
  • 1 Idle: indicates that BGP denies any request of entering. This is the initiatory status of BGP.

    Upon receiving a Start event, BGP initiates a TCP connection to the remote BGP peer, starts the ConnectRetry Timer with the initial value, detects a TCP connection initiated by the remote BGP peer, and changes its state to Connect.

  • 2 Connect: indicates that BGP performs other actions after the TCP connection is set up.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value, initiates a TCP connection to the remote BGP peer, and stays in the Connect state.

  • 3 Active: indicates that BGP tries to set up TCP connection. This is the intermediate status of BGP.
    • If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent.

    • If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value and changes its state to Connect.

    • If BGP initiates a TCP connection with an unknown IP address, the TCP connection fails. When this occurs, BGP restarts the ConnectRetry Timer with the initial value and stays in the Active state.

  • 4 OpenSent: indicates that BGP has sent one Open message to its peer and waits for the other Open message from the peer.
    • If there are no errors in the Open message received, BGP changes its state to OpenConfirm.

    • If there are errors in the Open message received, BGP sends a Notification message to the remote peer and changes its state to Idle.

    • If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active.

  • 5 OpenConfirm: indicates that BGP waits for a Notification message or a Keepalive message.
    • If BGP receives a Notification message, or the TCP connection fails, BGP changes its state to Idle.

    • If BGP receives a Keepalive message, BGP changes its state to Established.

  • 6 Established: indicates that BGP peers can exchange Update, Notification and Keepalive packets.
    • If BGP receives an Update or a Keepalive message, its state stays in Established.

    • If BGP receives a Notification message, BGP changes its state to Idle.

PeerUnavaiReason

Indicates the reason that the BGP peer down.

InterfaceName

Indicates the name of the interface.

Impact on the System

The BGP neighbor will be disconnected, and the BGP route received from the neighbor will be deleted. The packet forwarding based on the BGP route will fail.

Possible Causes

1. The BGP holdtimer timed out and did not receive the Keepalive packet.

2. BGP received incorrect BGP packets.

3. The BGP neighbor relationship was reset and the neighbor relationship was automatically interrupted.

4. BGP received Notification packets from the neighbor.

Procedure

  1. Run the display bgp peer ipv4-addresses log-info command to check the check the Error field in the command output. You can view the Error Code and Sub Error Code in the received Notification in the form of [ErrorCode][ErrorSubCode].

    • If the error code of the Notification is 1, it indicates that the BGP module receives the packet with incorrect headers. Then, go to Step 23.

    • If the error code of the Notification is 2, it indicates that the BGP module receives the incorrect Open packet. Then, go to Step 23.

    • If the error code of the Notification is 3, it indicates that the BGP module receives the incorrect Update packet. Then, go to Step 23.

    • If the error code of the Notification is 4, it indicates that till the Holdtimer times out, the BGP module does not receive the Keepalive packet. Then, go to Step 4.

    • If the error code of the Notification is 5, it indicates that the finite state machine of the BGP module is faulty. Then, go to Step 23.

    • If the error code of the Notification is 6, go to Step 2.

  2. If the error code of the Notification is 6, it indicates that BGP automatically closes the connection. Then, you need to run the display bgp peer ipv4-address log-info command to view the Notification field and check whether the Notification is sent by the switch that generates the trap.

    • If "Send Notification" is displayed, it indicates that the local switch actively sends the Notification. Then, go to Step 3.

    • If "Receive Notification" is displayed, it indicates that the local switch receives the Notification. Then, go to Step 22.

  3. Search for the reset bgp all and reset bgp ipv4-address commands in the user logs to check whether BGP is reset on the local end; or search for the peer ipv4-address enable command to check whether the peer is enabled in other address families on the local, or parameters for the BGP connection are configured.

    • If so, it indicates that incorrect configurations cause the trap, and thus no action is required. Then, go to Step 24.

    • If not, go to Step 23.

  4. If the error code is 4, it indicates that the BGP disconnection is caused by the timeout of the Holdtimer. Then, you need to check whether the address of the BGP neighbor can be pinged successfully.

    • If so, go to Step 21.

    • If not, go to Step 5.

  5. Run the display ip routing-table command to check whether the Destination/Mask field has the route to the peer address.

    • If so, go to Step 7.

    • If not, go to Step 8.

  6. Run the display acl all command to check whether the switch is configured with the ACL that disables TCP port 179.

    • If so, go to Step 9.

    • If not, go to Step 10.

  7. Run the display ip interface brief command to check whether the values of Physical and Protocol fields of the outbound interface are Up.

    • If so, go to Step 23.

    • If not, go to Step 11.

  8. Check the origin of the route with the BGP peer address.

    • If the route is originated from OSPF, go to Step 12.

    • If the route is originated from IS-IS, go to Step 13.

    • Else, go to Step 23.

  9. Delete the ACL that disables the TCP port 179, and check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.9 hwBgpPeerEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 10.

  10. Check the BGP configuration to see whether loopback interfaces are used to establish BGP peers.

    • If so, go to Step 14.

    • If not, go to Step 15.

  11. Enter the view of the outbound interface, and run the display this command to check whether the interface is shut down.

    • If so, run the undo shutdown command to enable the interface.

    • If not, go to Step 22.

  12. Run the display ospf peer command to check whether the OSPF peer relationship is established.

  13. Run the display isis peer command to check whether the IS-IS peer relationship is established.

  14. Check whether the peer connect-interface is configured for specifying the source address.

    • If so, go to Step 15.

    • If not, go to Step 16.

  15. If BGP is the EBGP neighbor relationship and multiple hops exist between EBGP neighbors, check whether the peer ebgp-max-hop is configured.

    • If so, go to Step 17.

    • If not, go to Step 19.

  16. Configure the peer connect-interface command. The parameter in the command must be the local interface that establishes a connection with the peer. Then, check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.9 hwBgpPeerEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  17. Check whether the peer valid-ttl-hops hops command is configured.

    • If so, go to Step 18.

    • If not, go to Step 23.

  18. If the peer valid-ttl-hops hops is configured, check whether the TTL of the packet to the peer ranges from [255-hops+1] to 255.

    • If so, go to Step 23.

    • If not, go to Step 20.

  19. Configure the peer ebgp-max-hop. Then, check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.9 hwBgpPeerEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  20. Changed the value of the peer valid-ttl-hops hops and make it within the range from [255-hops+1] to 255. Then, check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.9 hwBgpPeerEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  21. Run the the display cpu-usage command to check whether the CPU usage whether the CPU usage remains 100% in a period.

    • If so, go to Step 23.

    • If not, go to Step 6.

  22. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer switch, the peer is enabled in other address families on the local, and parameters for BGP connection are configured. Then, check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.9 hwBgpPeerEstablished appears later.

    • If so, go to Step 24.

    • If not, go to Step 23.

  23. Collect alarm information and configuration information, and then contact technical support personnel.
  24. End.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.11 hwBgpRouteThresholdExceed

Description

BGP/3/HWBGPROUTETHRESHOLDEXCEED:OID [oid] The number of BGP routes exceeded the threshold. (RouteTypeIndex=[integer], CurrentRouteNumber=[integer], RouteThreshold=[integer], MaximumNumber=[integer])

The ratio of BGP routes to the maximum number that is allowed exceeded the alarm threshold.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.11 Minor

qualityOfServiceAlarm

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

RouteTypeIndex

Index of the BGP route type
  • IPv4: IPv4 routes, including IPv4 public network and IPv4 VPN routes
  • IPv4 Public: IPv4 public network routes
  • IPv4 VRF: IPv4 VPN routes
  • IPv6: IPv6 routes, including IPv6 public network and IPv6 VPN routes
  • IPv6 Public: IPv6 public network routes
  • IPv6 VRF: IPv6 VPN routes
  • L2AD: BGP L2VPN-AD routes

CurrentRouteNumber

Current number of BGP routes of a specified type

RouteThreshold

Alarm threshold for the number of BGP routes of a specified type

MaximumNumber

Maximum number of BGP routes of a specified type

Impact on the System

The number of routes is approaching the maximum number that is allowed, and routes will no longer be accepted if the maximum number is reached, affecting services.

Possible Causes

The ratio of BGP routes to the maximum number that is allowed exceeded the alarm threshold.

Procedure

  1. Check whether this alarm is caused by configuration or topology errors.

    • If this alarm is caused by configuration or topology errors, go to Step 2.

    • If this alarm is not caused by configuration or topology errors, go to Step 3.

  2. Correct the configuration or topology errors.

    If the ratio of BGP routes to the maximum number that is allowed falls below the alarm threshold after the configuration or topology errors are corrected, go to Step 4.

  3. If all the routes are necessary, determine whether to implement capacity expansion and contact technical support personnel.
  4. End.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.12 hwBgpRouteThresholdClear

Description

BGP/3/HWBGPROUTETHRESHOLDCLEAR:OID [oid] The number of BGP routes decreased below the threshold. (RouteTypeIndex=[integer])

The ratio of BGP routes to the maximum number that is allowed fell below the clear alarm threshold.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.12

Minor

qualityOfServiceAlarm

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

RouteTypeIndex

Index of the BGP route type

  • IPv4: IPv4 routes, including IPv4 public network and IPv4 VPN routes
  • IPv4 Public: IPv4 public network routes
  • IPv4 VRF: IPv4 VPN routes
  • IPv6: IPv6 routes, including IPv6 public network and IPv6 VPN routes
  • IPv6 Public: IPv6 public network routes
  • IPv6 VRF: IPv6 VPN routes
  • L2AD: BGP L2VPN-AD routes

Impact on the System

Services will not be affected.

Possible Causes

The ratio of BGP routes to the maximum number that is allowed fell below the clear alarm threshold.

Procedure

  1. This alarm message is informational only, and no action is required.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.13 hwBgpRouteMaxExceed

Description

BGP/3/HWBGPROUTEMAXEXCEED:OID [oid] The number of BGP routes exceeded the maximum number. (RouteTypeIndex=[integer], MaximumNumber=[integer])

The number of BGP routes exceeded the maximum number that is allowed.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.13 Minor

qualityOfServiceAlarm

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

RouteTypeIndex

Index of the BGP route type
  • IPv4: IPv4 routes, including IPv4 public network and IPv4 VPN routes
  • IPv4 Public: IPv4 public network routes
  • IPv4 VRF: IPv4 VPN routes
  • IPv6: IPv6 routes, including IPv6 public network and IPv6 VPN routes
  • IPv6 Public: IPv6 public network routes
  • IPv6 VRF: IPv6 VPN routes
  • L2AD: BGP L2VPN-AD routes

MaximumNumber

Maximum number of BGP routes of a specified type

Impact on the System

BGP routes will no longer be accepted. As a result, services will be affected.

Possible Causes

The number of BGP routes exceeded the maximum number that is allowed.

Procedure

  1. Check whether this alarm is caused by configuration or topology errors.

    • If this alarm is caused by configuration or topology errors, go to Step 2.

    • If this alarm is not caused by configuration or topology errors, go to Step 3.

  2. Correct the configuration or topology errors.

    If the number of BGP routes falls below the maximum number that is allowed after the configuration or topology errors are corrected, go to Step 4.

  3. If all the routes are necessary, determine whether to implement capacity expansion and contact technical support personnel.
  4. End.

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.14 hwBgpRouteMaxClear

Description

BGP/3/HWBGPROUTEMAXCLEAR:OID [oid] The number of BGP routes decreased below the maximum number. (RouteTypeIndex=[integer])

The number of BGP routes fell below the maximum number that is allowed.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.177.1.3.14

Minor

qualityOfServiceAlarm

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

RouteTypeIndex

Index of the BGP route type

  • IPv4: IPv4 routes, including IPv4 public network and IPv4 VPN routes
  • IPv4 Public: IPv4 public network routes
  • IPv4 VRF: IPv4 VPN routes
  • IPv6: IPv6 routes, including IPv6 public network and IPv6 VPN routes
  • IPv6 Public: IPv6 public network routes
  • IPv6 VRF: IPv6 VPN routes
  • L2AD: BGP L2VPN-AD routes

Impact on the System

Services will not be affected.

Possible Causes

The number of BGP routes fell below the maximum number that is allowed.

Procedure

  1. This alarm message is informational only, and no action is required.

BGP Error Code

Error Code

Error Subcode

1: Message header error

  • 1: connection not synchronized

  • 2: error message length

  • 3: error message type

2: Open message error

  • 1: unsupported version number

  • 2: error peer AS

  • 3: error BGP identifier

  • 4: unsupported optional parameter

  • 5: authentication failed

  • 6: unacceptable hold-time

  • 7: unsupported capability

3: Update message error

  • 1: malformed attribute list

  • 2: unrecognized well-known attribute

  • 3: well-known attribute is missing

  • 4: attribute flags error

  • 5: attribute length error

  • 6: invalid origin attribute

  • 7: AS routing loop

  • 8: invalid Next-Hop attribute

  • 9: error optional attribute

  • 10: invalid network field

  • 11: abnormal AS-Path

4: Hold timer expired

0: no special definition of the error subcode

5: Finite state machine error

0: no special definition of the error subcode

6: Cease

  • 1: maximum number of prefixes reached

  • 2: administrative shutdown

  • 3: peer deleted

  • 4: administrative reset

  • 5: connection rejected

  • 6: other configuration change

  • 7: connection collision resolution

  • 8: out of resources

  • 9: BFD session Down

Translation
Download
Updated: 2019-04-09

Document ID: EDOC1100065855

Views: 3485

Downloads: 2

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