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.
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.
|
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.
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.
|
BgpPeerUnavaiReason |
Cause for the peer disconnection
|
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
- Run the display bgp peer ipv4-addresses log-info command to 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Run the display ospf peer command to check whether the OSPF peer relationship is established.
If so, go to Step 23.
If not, refer to the solution provided in the case of trap OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange.
- Run the display isis peer command to check whether the IS-IS peer relationship is established.
If so, go to Step 23.
If not, refer to the solution provided in the case of trap ISIS_1.3.6.1.3.37.2.0.13 isisRejectedAdjacency.
- 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.
- 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.
- 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.
- Check whether the peer valid-ttl-hops hops command is configured.
If so, go to Step 18.
If not, go to Step 23.
- 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.
- 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.
- 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.
- Run the display cpu-usage command to check whether the CPU usage remains 100% in a period.
If so, go to Step 23.
If not, go to Step 6.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
BGP Error Code
Error Code |
Error Subcode |
---|---|
1: Message header error |
|
2: Open message error |
|
3: Update message error |
|
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 |
|