SupportDocumentationWLANAPAirEngine 5700&6700&8700&9700DTroubleshootingMaintenance Handbook

WLAN Troubleshooting Guide (V600)

Troubleshooting Guidelines for BGP

Troubleshooting Guidelines for BGP

This chapter describes common BGP faults and provides troubleshooting methods, troubleshooting cases, and FAQs.

BGP Peer Relationship Fails to Be Established

Symptom

A BGP peer relationship cannot be established after BGP is configured.

Possible Causes

This type of fault is commonly caused by the following:

  • BGP messages fail to be forwarded.

  • An ACL filters out TCP port 179.

  • Router IDs of peers conflict.

  • The configured peer AS number is incorrect.

  • Loopback interfaces are used to establish a peer relationship, but the peer connect-interface command is not configured.

  • Loopback interfaces are used to establish an EBGP peer relationship, but the peer ebgp-max-hop command is not configured.

  • The peer valid-ttl-hops configuration is incorrect.

  • The number of routes received from the peer end exceeds the maximum limit configured using the peer route-limit command.

  • The peer ignore command is configured at the peer end.

  • The address families of the two ends do not match.

Procedure

  1. Run the ping command to check whether the BGP peer can be pinged.

    • If the BGP peer can be pinged, there are available routes between them, and the link between the two ends is normal. In this case, go to 2.

      Run the ping –a source-ip-address –s packetsize host or ping ipv6 –a source-ipv6-address –s byte-number destination-ipv6-address command to check the connectivity between the two ends. You can specify the source address to check whether the routes on the two ends are normal, and specify the size of each ping packet to check whether large packets can be normally transmitted over the link.

    • If the ping operation fails, rectify the link transmission fault according to the ping failure troubleshooting.

  2. Check whether ACL rules are configured to filter out the packets carrying TCP port 179.

    Run the display acl all command on the two devices to check whether ACL rules are configured to filter out the packets carrying TCP port 179.

    <HUAWEI> display acl all
Basic ACL 3001, 2 rules
ACL's step is 5
ACL's match-order is config
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp

    • If ACL rules are configured to filter out the packets carrying TCP port 179, run the undo rule rule-id destination-port and undo rule rule-id source-port commands to delete such rules.

    • If no ACL rules are configured to filter out the packets carrying TCP port 179, go to Step 3.

  3. Check that the peer router ID does not conflict with the local router ID.

    Check whether the peer router ID conflicts with the local router ID. For example, if the IPv4 unicast peer relationship fails to be established, run the display bgp peer command to check whether the peer router ID conflicts with the local router ID. The following is an example of the command for displaying the router ID:

    <HUAWEI> display bgp peer
 BGP local router ID : 1.1.1.1
 Local AS number : 65001
 Total number of peers : 12                Peers in established state : 4
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  10.9.0.8        4         100     1601     1443     0 23:21:56 Established   10000
  10.10.0.10      4         200     1565     1799     0 23:15:30 Established    9999
    The commands used to check peer information in other address families are as follows:
    • The display bgp vpnv4 all peer command is used to check information about all VPNv4 peers.
    • The display bgp ipv6 peer command is used to check information about IPv6 peers.
    • The display bgp vpnv6 all peer command is used to check information about all VPNv6 peers.

    • If the peer router ID conflicts with the local router ID, run the router id command in the BGP view to change either of the two router IDs so that the router IDs are different. In most cases, the IP address of a loopback interface is used as the local router ID.

    • If the peer router ID does not conflict with the local router ID, go to Step 4.

  4. Check that the peer AS number is configured correctly.

    Run the display bgp peer command on each device to check whether the displayed peer AS number is the same as the remote AS number. 

    <HUAWEI> display bgp peer
 BGP local router ID : 1.1.1.1
 Local AS number : 41976
 Total number of peers : 12                Peers in established state : 4
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  10.9.0.8        4         100     1601     1443     0 23:21:56 Established   10000
  10.10.0.10      4         200     1565     1799     0 23:15:30 Established    9999

    • If the peer AS number is configured incorrectly, change it to the remote AS number.

    • If the peer AS number is configured correctly, go to Step 5.

  5. Check whether BGP configurations affect the establishment of the BGP peer relationship.

    Run the display current-configuration configuration bgp command to check BGP configurations.

    Check Item

    Description

    peer connect-interface { interface-type interface-number | ipv4-source-address }

    If the two devices use loopback interfaces to establish the BGP peer relationship, run the peer connect-interface command to specify the loopback interface as the source interface to send BGP messages or specify an IP address as the source IP address.

    peer ebgp-max-hop hop-count

    When two directly connected devices use loopback interfaces to establish an EBGP peer relationship or two indirectly connected devices establish an EBGP peer relationship, run the peer ebgp-max-hop command to specify the maximum number of hops between the two devices.

    • When two directly connected devices use loopback interfaces to establish the EBGP peer relationship, the hop-count can be any number greater than 1.

    • When two indirectly connected devices establish the EBGP peer relationship, specify hop-count according to the actual situation.

    peer valid-ttl-hops hops

    If the peer valid-ttl-hops hops command is configured, check whether the command is configured correctly. If hops is configured, the valid TTL range of detected packets is [255 – hops + 1, 255]. hops specifies the number of hops between two ends of a BGP session. The hop count between the two directly connected devices is 1.

    NOTE:

    The peer valid-ttl-hops command must be configured on both ends of a BGP session.

    peer route-limit limit

    If the peer route-limit limit command is configured, check whether the number of routes received from the peer exceeds the upper limit specified by limit. If the upper limit is exceeded, reduce the number of routes received from the peer, and run the reset bgp ip-address command to reset the BGP peer relationship.

    peer ignore

    If the peer ignore command is configured on the remote end, the remote end does not want to establish a peer relationship with the local end temporarily. If a peer relationship is required, the undo peer ignore command needs to be run on the remote end.

    Address family capability

    Check the configuration files on both ends of the BGP session to determine whether their address family capabilities match. For example, to establish a BGP VPNv4 peer relationship, the peer enable command must be configured in the BGP-VPNv4 address families of both devices. If this command is configured on one device only, the BGP peer relationship state displayed on the other device is No neg.

  6. If the fault persists, contact technical support personnel and provide the following information:

    • Results of the preceding procedure
    • Configuration, log, and alarm information

BGP Peer Relationship Is Interrupted

Symptom

After BGP is configured, a BGP peer relationship is interrupted.

Possible Causes

This type of fault is commonly caused by the following:

  • The holdtime expires because no Keepalive message is received from the peer for a long time.
  • The number of routes exceeds the upper limit.
  • The memory usage exceeds the threshold.
  • Configurations change.
  • The route on which peer relationship establishment depends flaps.
  • The link is disconnected, for example, the interface goes down.
  • BFD detects a link fault and instructs BGP to disconnect the link.
  • The peer end proactively requests the local end to disconnect the connection and the local end does accordingly.

Procedure

  1. Run the display bgp peer log-info command to check the IP address of the BGP peer. Based on Error Code or Error Subcode in the command output, check whether the corresponding event has occurred. For details, see Table 21-41.

    <HUAWEI> display bgp peer 10.8.200.26 log-info 
 2021-02-10 19:17:00.436 
 Peer : 61.8.200.26
 Date/Time     : 2021-02-06 18:44:21+00:00
 State         : Up

 Date/Time     : 2021-02-06 18:34:31+00:00 //Disconnection time
 State         : Down
 Error Code    : 6(CEASE)                                                
 Error Subcode : 2(Administrative Shutdown)          //The local end proactively shuts down the link.
 Notification  : Send Notification                                  //Send Notification indicates that the local end proactively shuts down the link, and Receive Notification indicates that the peer end proactively shuts down the link.

 Date/Time     : 2021-02-04 17:10:11+00:00
 State         : Up

 Date/Time     : 2021-02-04 17:09:16+00:00
 State         : Down
 Error Code    : 4(Hold Timer Expired)                         //The hold timer expires.
 Error Subcode : 0(UnSpecific)
 Notification  : Send Notification
    Table 21-41 BGP error codes

    Error Code

    Error Subcode

    1: message header error

    1: Connection unsynchronized.

    2: Incorrect message length.

    3: Incorrect message type.

    2: Open message error

    1: Unsupported version number.

    2: Incorrect peer AS.

    3: Incorrect BGP identifier.

    4: Unsupported optional parameter.

    5: Authentication failure.

    6: Unacceptable hold time.

    7: Unsupported capability.

    3: Update message error, indicating that an error Update message is received.

    1: Malformed attribute list.

    2: Unrecognized well-known attribute.

    3: Missing well-known attribute.

    4: Incorrect attribute flag.

    5: Incorrect attribute length.

    6: Invalid Origin attribute.

    7: AS routing loop.

    8: Invalid Next_Hop attribute.

    9: Incorrect optional attribute.

    10: Invalid network field.

    11: Malformed AS_Path.

    4: The hold timer expires, leading to the peer relationship interruption.

    0: No special error subcode is defined. The hold timer expires. In this case, check the link connectivity.

    5: FSM error

    1: An unexpected message is received in the OpenSent state.

    2: An unexpected message is received in the OpenConfirm state.

    3: An unexpected message is received in the Established state.

    6: The interruption is triggered by manual configuration.

    1: The number of prefixes exceeds the maximum value.

    2: The peer relationship is manually shut down.

    • View user operation logs to check whether the shutdown command has been executed for the peer.
    • View configurations to check whether the peer ignore command has been executed for the peer.

    3: The peer is deleted.

    4: The peer is manually reset. View user operation logs to check whether the reset bgp command has been executed for the peer.

    5: The connection fails.

    6: The peer's configuration is changed. In this case, view user operation logs to check whether the configuration of the specified peer has been changed, for example, whether the peer ebgp-max-hop command configuration is changed.

    This error code is also displayed in other cases, such as fast detection of faults on directly connected EBGP interfaces and BGP resource threshold-crossing.

    7: Connection conflict.

    8: Resource shortage.

    9: The BFD session is disconnected, indicating that the BFD session is down.

    7: The Capability message is incorrect.

    1. The sequence numbers do not match.

    2. Capability Length is incorrect.

    3. The format of Capability Value is incorrect.

    4. The Capability Code is not supported.

  2. Run the pads diagnose neighbor bgp command in the diagnostic view to check the reason why the BGP peer relationship is interrupted. For details, see the pads diagnose neighbor bgp command description in the command reference.

    [~HUAWEI] diagnose
[~HUAWEI-diagnose] pads diagnose neighbor establish-abnormal bgp history-record
Start diagnose at 2018-04-17 08:07:51, Estimated time:80 seconds.
........
End diagnose at 2018-04-17 08:07:59, Actual time:8 seconds.
Diagnose report:

Diagnose information for public instance :
BGP local router ID : 10.1.1.2 
------------------------------------------------------------------------------------------------------------------
NBR-Peer-IP                             Last-Detect-Time State       Reason
1.1.1.1                                 01-27 20:23:49   OpenConfirm The shutdown command is run in the BGP view. 
2.2.2.2                                 01-27 20:23:49   Idle        The peer ignore command is configured for the BGP peer.

  3. Run the display bgp peer state command in the diagnostic view to check the peer status.

    [~HUAWEI] diagnose
[~HUAWEI-diagnose] display bgp peer 10.1.11.15 state 

Last   Read     : 2023-08-16 22:38:53-03:00 
Last   Write    : 2023-08-16 22:39:30-03:00 
Last Try Connect: 2023-08-16 08:04:21-03:00 
Last Try Creat Connect Fail Reason: 
Last Peer Down Reason: Peer down other                                 //Reason for the latest BGP peer relationship interruption
Last Recv Msg Time: ----- 
Last Send Msg Time: ----- 
Send Update Buffer Count: 5
BFD State: 0, BFD PrevState: 0, BFD Fsm Event: 4
GFD State: 0, GFD PrevState: 0, GFD Fsm Event: 0

Event Timers:
 TimerID      Name        Type        Mode        TimerLeft(ms)     ExpireTime
 0            CRTimer     CYCLIC      IDLE        -----             0         
 2933177596   KATimer     CYCLIC      RUNNING     50000             1003      
 2954844384   HLTimer     CYCLIC      RUNNING     169000            1003      
 0            IHTimer     CYCLIC      IDLE        -----             0         
 0            DOTimer     CYCLIC      IDLE        -----             0         

Out interface(4294967295) current state: 7

Rely-state interface(4294967295) current state: 0

                     Listen SOCKET       Main SOCKET         Second SOCKET       
 Socket ID:          2                   18                  0                   
 Option Flag:        0                   0                   0                   
 Current State:      2                   2                   0                   
 Prev State:         1                   2                   0                   
 Fsm Event:          49                  53                  0                    
 Out Pipe(id/state): (4294967295/0)      (524311/2)          (0/0)               
 In Pipe(id/state):  (4294967295/0)      (1074266136/2)      (0/0)               
 InBD State:         0                   3                   0                   
 OutBD State:        0                   3                   0                   
 BD Require:         false               false               false               
 Congestion Flag:    0                   0                   0                   
 Congestion Times:   0                   1                   0                   
 Close Flag:         0                   0                   0                   

                LastCreateFail                 LastNotifyError               LastCreateSeqError            LastCloseSocketSeqError       
 Socket ID:     15                             -1                            -1                            -1                            
 Error Code:    100003                         0                             0                             0                             
 Occur Time:    2023/08/16 08:05:50-03:00      -----                         -----                         -----                         
Refresh Information:


Option of socket instance

--------------------------------
Option Type: VRP_IP_TOS
OFF: Current value: 192, Default value: 0
Option of socket instance

--------------------------------
Option Type: VRP_IP_TTL
NOT CONFIRMED: Current value: 255, Default value: 255
Option of socket instance

--------------------------------
Option Type: VRP_SO_VRP_APP_PROTOID
NOT CONFIRMED: Current value: 6
Option of socket instance

--------------------------------

Option of socket instance

--------------------------------
Option Type: VRP_TCP_MD5SIG
Current setting: OFF, SIG_KEY: ***
Option of socket instance

--------------------------------
Option Type: VRP_IP_GTSM
LAddr: 0x1010b17 LPort: 179 FAddr: 0x1010b0f FPort 64042: Max 0 Min: 0

Option of socket instance

--------------------------------
Option Type: VRP_TCP_PATH_MTU
Current setting: OFF, Current value: 1400
Option of socket instance

--------------------------------
Option Type: VRP_TCP_KEY_CHAIN
Current setting: OFF, Current value: 0
Option of socket instance

--------------------------------
Option Type: VRP_TCP_MAXSEG
Current value: 0
Statistics of socket instance
-------------------- Display SOCKET Statistics -------------------
Cid: 0x80650569    FD: 18    Handle: 18219008  CreateTime: 2023-08-16 08:05:57-03:00 746      //Time when the current BGP TCP connection was created
BD State: 6   FSM state: Protected  SwitchTime: 2023-08-16 08:05:58-03:00 559
CVerify: 0   SrcVerify: 0      KCID: 0   Error: 0   PktInterval: 180 
AppCid: 0x8013056A
TlsFlag: false
InfoFlag: 0x20020000
PathInfo:    SessionInfo:
Packet Statistics:
    From LDM: 6211434 Pkt   3232882720 Byte
    From LDM TCP Control: 547 Pkt   10940 Byte
    From LDM TCP Data: 6210887 Pkt   3108641762 Byte
    From APP: 1010 Pkt    19429 Byte
    From IPV4Lib: 6211434 Pkt    3232881382 Byte
    To LDM: 4648325 Pkt    185952391 Byte
    To APP: 6210789 Pkt    2984364889 Byte
    Flow Control To App: 8    Long Cong Time:0
Pipe Statistics:
    Congestion: 1    Decongestion: 1
    Pipe To APP: 524312    Pipe From APP: 1074266135
    Pipe State To APP: 2  Pipe State From APP: 2
Socket Receive Buf:
    cc: 0     c: 0  hiwat: 33600    mbcnt: 0  max: 57507840    state: 
Socket Send Buf:
    cc: 0     c: 0  hiwat: 33600    mbcnt: 0  max: 57507840    state: 
Bumper Statistics:
    Inbumper Count: 0    Win:10   Seq:6211437 
    OutBumper Count: 0   Win:10   Seq:1010  
TCP Statistics:
    Input SYN:0 Pkts
    Input FIN:0 Pkts
    Tcp Retrans:0 Times                                                     //TCP retransmission count. If a large number of packets are retransmitted, the link is unstable or packet loss occurs on the peer end.
Packet Discard Statistics:        
    Malloc: 0                Invalid State: 0         No Pipe CB: 0            
    Path Invalid: 0          GetMbufTag: 0            Dettached: 0             
    Make Continues: 0        GetIpid: 0               GetFileFailed: 0         
    ProtoType: 0             Socket Closed: 0         PathCacheFail: 0         
    SendInstance: 0          GetInpcb: 0              PipeWriteFail: 0         
    Keychain: 0              MD5: 0                   RawCopyFailed: 0         
    Listen RcvPkt: 0         Closing: 0               Tcp Error: 0             
    SendValidate: 0          VRPSend:0                Path Seg:0               
    InbumperLen: 0           OutBumperLen: 0          AllocBN:0                
    InbumperAck: 0           OutBumperAck: 2          Other: 0                 
    LastDropPktTime: 2023-08-16 08:05:58-03:00        LastDropPktLabel: 265    
-----------------------------------------------------------------

Statistics of socket instance
-------------------- Display SOCKET Statistics -------------------
Cid: 0x80650569    FD: 2    Handle: 17170432  CreateTime: 2023-08-16 08:04:59-03:00 408        //Time when the BGP TCP connection was created for the last time
BD State: 6   FSM state: Protected  SwitchTime: 2023-08-16 08:05:47-03:00 704
CVerify: 0   SrcVerify: 0      KCID: 0   Error: 0   PktInterval: 0 
AppCid: 0x8013056A
TlsFlag: false
InfoFlag: 0x1
PathInfo:    SessionInfo:
Packet Statistics:
    From LDM: 5 Pkt   327 Byte
    From LDM TCP Control: 2 Pkt   44 Byte
    From LDM TCP Data: 3 Pkt   181 Byte
    From APP: 0 Pkt    0 Byte
    From IPV4Lib: 5 Pkt    325 Byte
    To LDM: 1 Pkt    44 Byte
    To APP: 0 Pkt    0 Byte
    Flow Control To App: 0    Long Cong Time:0
Pipe Statistics:
    Congestion: 0    Decongestion: 0
    Pipe To APP: 4294967295    Pipe From APP: 4294967295
    Pipe State To APP: 0  Pipe State From APP: 0
Socket Receive Buf:
    cc: 0     c: 0  hiwat: 32768    mbcnt: 0  max: 57507840    state: 
Socket Send Buf:
    cc: 0     c: 0  hiwat: 32768    mbcnt: 0  max: 57507840    state: 
Bumper Statistics:
    Inbumper Count: 0    Win:10   Seq:0 
    OutBumper Count: 0   Win:10   Seq:0  
TCP Statistics:
    Input SYN:1 Pkts
    Input FIN:0 Pkts
    Tcp Retrans:0 Times                                                    //TCP retransmission count
Packet Discard Statistics:        
    Malloc: 0                Invalid State: 0         No Pipe CB: 0            
    Path Invalid: 0          GetMbufTag: 0            Dettached: 0             
    Make Continues: 0        GetIpid: 0               GetFileFailed: 0         
    ProtoType: 0             Socket Closed: 0         PathCacheFail: 0         
    SendInstance: 0          GetInpcb: 0              PipeWriteFail: 0         
    Keychain: 0              MD5: 0                   RawCopyFailed: 0         
    Listen RcvPkt: 0         Closing: 0               Tcp Error: 0             
    SendValidate: 0          VRPSend:0                Path Seg:0               
    InbumperLen: 0           OutBumperLen: 0          AllocBN:0                
    InbumperAck: 0           OutBumperAck: 0          Other: 0                 
    LastDropPktTime: 0000-00-00 00:00:00              LastDropPktLabel: 0      
-----------------------------------------------------------------

  4. If the fault persists, contact technical support personnel and provide the following information:

    • Results of the preceding procedure
    • Configuration, log, and alarm information

BGP Public Network Traffic Is Interrupted

Symptom

BGP public network traffic is interrupted after BGP is configured.

Possible Causes

This type of fault is commonly caused by the following:

  • The route is inactive because its next hop is unreachable.

  • The route fails to be advertised or accepted because a routing policy is not configured correctly.

  • The received routes are discarded because the number of routes exceeds the upper limit.

Procedure

  1. Check that the next hop of the route is reachable.

    Run the display bgp routing-table network { mask | mask-length } command on the route sender to check whether the target route is active and whether the route has been sent to the route receiver. network specifies the prefix of the target route.

    The route 10.0.0.0/8 is used as an example. The command output shows that this route is valid and best (optimal) and sent to the peer at 3.3.3.3. The original next hop and recursive next hop (Relay IP Nexthop) of this BGP route are 1.1.1.1 and 172.16.1.1, respectively.

    <HUAWEI> display bgp routing-table 10.0.0.0 8
 BGP local router ID : 10.1.1.1
 Local AS number : 100
 Paths:   1 available, 1 best, 1 select
 BGP routing table entry information of 10.0.0.0/8:
 From: 1.1.1.1 (192.168.1.1)
 Route Duration: 4d21h29m39s
 Relay IP Nexthop: 172.16.1.1
 Relay IP Out-Interface: GE0/0/3 
 Original nexthop: 1.1.1.1
 Qos information : 0x0
 AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
 Aggregator: AS 100, Aggregator ID 192.168.1.1
 Advertised to such 1 peers:
    3.3.3.3

    • If the target route is inactive, check whether there is a route to the original next hop in the IP routing table. If no route to the original next hop exists, the BGP route is not advertised because its next hop is unreachable. In this case, determine why there is no route to the original next hop. Note that this fault is generally associated with IGP or static routes.

    • If the target route is active and has been selected but there is no information indicating that this route is sent to the peer, perform Step 2 to check the export policy on the local device.

    • Run the display bgp routing-table network { mask | mask-length } command on the route receiver to check whether it has received the target route.

      • If the target route has been received, perform Step 1 again to check whether the next hop of the route is reachable and optimal.

      • If the target route has not been received, perform Step 2 to check the import policy on the peer.

    In BGP4+ networking, the display bgp routing-table ipv6-address prefix-length command is used to check whether the target route is received.

  2. Check that the routing policies are configured correctly.

    Run the display current-configuration configuration bgp command on both ends to check whether the BGP export and import policies are configured.

    <HUAWEI> display current-configuration configuration bgp
#
bgp 100
 peer 1.1.1.1 as-number 100
 #
 ipv4-family unicast
  filter-policy ip-prefix aaa import
  filter-policy ip-prefix aaa export
  peer 1.1.1.1 enable
  peer 1.1.1.1 filter-policy acl-name acl-name import
  peer 1.1.1.1 filter-policy acl-name acl-name export
  peer 1.1.1.1 as-path-filter 1 import
  peer 1.1.1.1 as-path-filter 1 export
  peer 1.1.1.1 ip-prefix prefix-name import
  peer 1.1.1.1 ip-prefix prefix-name export
  peer 1.1.1.1 route-policy policy-name import
  peer 1.1.1.1 route-policy policy-name export
 #
 ipv4-family vpnv4
  policy vpn-target
  peer 1.1.1.1 enable
#
return

    • If export and import policies are configured on the two devices, check whether the route is filtered out by these policies.

    • If no export and import policies are configured on the two devices, go to Step 3.

  3. Check that the number of routes is lower than the upper limit.

    Run the display current-configuration configuration bgp | include peer destination-address command on the route receiver to check whether an upper limit is configured on the number of routes that can be accepted from the peer.

    For example, if the local end is allowed to accept a maximum of five routes from the remote end at 1.1.1.1 but excess routes are received, the excess routes are discarded and a log is recorded.

    <HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
 peer 1.1.1.1 as-number 100
 peer 1.1.1.1 route-limit 5 alert-only
  peer 1.1.1.1 enable

    If the BGP peer is added to a peer group, the command output may contain no route-limit configurations.

    <HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
 peer 1.1.1.1 as-number 100
 peer 1.1.1.1 group IBGP
  peer 1.1.1.1 enable
  peer 1.1.1.1 group IBGP

    In this case, run the display current-configuration configuration bgp | include peer group-name command to check the configurations of this peer group.

    <HUAWEI> display current-configuration configuration bgp | include peer IBGP
 peer IBGP route-limit 5 alert-only
  peer IBGP enable

    If the BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed alarm is generated during traffic interruption, the target route is discarded because the upper limit is exceeded. To resolve this issue, increase the upper limit on the local device.

    Changing the upper limit on the number of routes to be accepted from a peer may interrupt the BGP peer relationship. Therefore, configuring route summarization on the route sender to reduce the number of routes to be sent is recommended.

  4. If the fault persists, contact technical support personnel and provide the following information:

    • Results of the preceding procedure
    • Configuration, log, and alarm information

The BGP ORF-capable End (Route Sender) Cannot Receive ORF Information from the Peer End (Route Receiver)

Symptom

After BGP ORF is configured on the local end, the local end cannot receive ORF information from the peer end.

Possible Causes

This type of fault is commonly caused by the following:

  • A BGP IPv4 unicast peer relationship fails to be established.
  • The BGP ORF capability negotiation fails.
  • No peer-based import policy that references an IP prefix list is configured on the remote device (route receiver).
  • No IP prefix list is configured for the peer-based import policy that needs to reference an IP prefix list on the remote device (route receiver).

Procedure

  1. Check that a BGP unicast peer relationship has been set up.

    Run the display bgp peer command to check whether the BGP peer relationship is in the Established state.

  2. Check that the BGP ORF function is enabled on both ends of the BGP connection and that the two ends succeed in negotiating the BGP ORF capability.

    Run the display current-configuration configuration bgp command on both ends to check whether the peer ipv4-address capability-advertise orf ip-prefix command is configured in the IPv4 unicast address family view.

    <HUAWEI> display current-configuration configuration bgp
#
bgp 100
peer 7.1.1.1 as-number 100
#
 ipv4-family unicast
  peer 7.1.1.1 ip-prefix in import
  peer 7.1.1.1 capability-advertise orf ip-prefix both
#

    BGP ORF has three modes: send, receive, and both. In send mode, a device can send ORF information; in receive mode, a device can accept ORF information; in both mode, a device can send and accept ORF information. To enable the local device to accept ORF IP-prefix information, configure both or receive mode on the local device and both or send mode on the peer end.

    • If either end is not configured with the BGP ORF function, run the peer ipv4-address capability-advertise orf ip-prefix command in the BGP IPv4 unicast address family view to enable BGP ORF. Specify both or receive when you configure the local end, and specify both or send when you configure the remote end.

      <HUAWEI> system-view
[HUAWEI] bgp 100
[HUAWEI-bgp] ipv4-family unicast
[HUAWEI-bgp-af-ipv4] peer 7.1.1.1 capability-advertise orf ip-prefix both

      If BGP ORF is enabled on both ends, run the display bgp peer ipv4-address verbose command after a peer relationship is re-established to check whether the BGP ORF capability has been negotiated successfully. The command output shows the ORF capabilities on both ends.

      <HUAWEI> display bgp peer 7.1.1.1 verbose | include Address-Prefix
         Support Address-Prefix: IPv4-UNC address-family, rfc-compatible, both            
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both

      In this command output, the first line shows the ORF capability of the remote end, and the second line shows the ORF capability configured on the local end. The ORF capability code supported by non-Huawei devices may be different from that defined in the relevant standard. To enable a Huawei device to communicate with one of the non-Huawei devices, ensure that the same compatibility mode (non-standard-compatible or rfc-compatible) is configured on the two devices.

    • If the BGP ORF function is enabled on both ends and they succeed in negotiating the BGP ORF capability, go to Step 3.

  3. Check that an IP prefix list-based import policy is configured on the remote end (route receiver).

    Run the display current-configuration configuration bgp command on the remote end to check whether the peer ipv4-address ip-prefix ip-prefix-name import command is configured in the IPv4 unicast address family view.

    <HUAWEI> display current-configuration configuration bgp
#
bgp 100
peer 7.1.1.1 as-number 100
#
 ipv4-family unicast
  peer 7.1.1.1 ip-prefix in import
  peer 7.1.1.1 capability-advertise orf ip-prefix both
#

    • If no IP prefix list-based import policy is configured on the remote end, run the peer ipv4-address ip-prefix ip-prefix-name import command in the BGP IPv4 unicast address family view to configure one.

      <HUAWEI> system-view
[HUAWEI] bgp 100
[HUAWEI-bgp] ipv4-family unicast
[HUAWEI-bgp-af-ipv4] peer 7.1.1.1 ip-prefix in import

    • If an IP prefix list-based import policy has been configured on the remote end but the local end cannot receive ORF prefix information from the remote end, go to Step 4.

  4. Check that the IP prefix list specified in the import policy is configured on the remote peer (route receiver).

    Run the display ip ip-prefix ip-prefix-name command on the remote BGP peer to check whether the IP prefix list specified in the import policy is configured.

    <HUAWEI> display ip ip-prefix in

    If the IP prefix list is not configured, run the ip ip-prefix ip-prefix-name index index-number permit ipv4-address mask-length command in the system view to configure it.

    <HUAWEI> system-view
[HUAWEI] ip ip-prefix in index 10 permit 10.1.1.0 24

    After completing this configuration, run the display ip ip-prefix ip-prefix-name command on the remote peer to check whether the IP prefix list specified in the import policy is successfully configured.

    <HUAWEI> display ip ip-prefix in
ip-prefix in
 total permitted: 0             denied: 0                                      
    index 10           permit 10.1.1.0/24

    This output shows that the prefix list in has been successfully configured. After completing these steps, if the local end still fails to receive ORF information from the remote end, go to Step 5.

  5. Collect the following information and contact technical support personnel:

    • Results of the preceding procedure
    • Configuration, log, and alarm information

Translation
Favorite
Download
Update Date：2025-04-29
Document ID：EDOC1100372040
Views：80678
Downloads：896
Average rating：5.0Points

Related Documents

Digital Signature File

digtal sigature tool