Why does BGP attempt to establish connections over 30 seconds after the peer is configured


Compared with IGP configuration, BGP configuration is more complex. In addition to the peer and AS, the egress, multi-hop, timer, and various capabilities need to be specified. Currently, BGP does not support dynamic capability negotiation. Therefore, these parameters, after being modified, need to be renegotiated.

To avoid frequent interruptions during the renegotiation, a proper time parameter is required to ensure that the relevant configurations are complete before the link establishment attempt. RFC4271 recommends 120s, whereas 32s is adopted by switch.

Other related questions:
Why does an S series switch try to establish a BGP connection over 30s after peer configuration
For S series switches that support BGP, it is more complex to configure BGP than IGP. Besides peers and ASs, outbound interfaces, multiple hops, timers, and various capabilities need to be configured. At present, BGP does not support dynamic capability negotiation. Therefore, the changes of these parameters need to be negotiated again. To prevent the BGP peer relationship from being interrupted frequently, a proper timer is required. Ensure that related configurations are complete before the attempt of setting up a BGP connection. In RFC 4271, you are advised to set the value of the timer to 120s. On Huawei devices, the value of the timer is set to 32s.

Why can BGP not immediately attempt to establish connections after the peer is configured
To prevent the Border Gateway Protocol (BGP) from frequently tearing down the neighbor relationship for renegotiation, the device waits for a proper period before establishing connections to ensure that related configurations are complete. The recommended period in RFC4271 is 120 seconds. The implementation in AR series routers is 32 seconds.

Why are BGP connections re-established after the peer connect-interface command is configured
Currently, the switch does not support BGP dynamic capability negotiation. Therefore, if certain capabilities of the BGP peer are changed, the BGP connection is automatically disconnected and then the capabilities of the neighbor are renegotiated. If the peer connect-interface command is configured, the BGP session needs to be set up by designating the egress. Therefore, the source address of the TCP connection may be changed and the TCP connection needs to be re-established by using the new source address.

Problem and solution when BGP peer cannot be established
The BGP peer establishment on the firewall needs to use port 179 to establish TCP sessions and requires that OPEN messages be properly exchanged. Perform as follows to rectify the issue: 1. Check whether the AS number and IP address among peers are correct by using the display bgp peer command. 2. Check whether the router IDs configured on both BGP peers are conflicting by using the display bgp peer command. 3. If the loopback interface is used, check whether the peer connect-interface command is configured to specify the loopback interface as the source interface for sending BGP packets. 4. If EBGP neighbors are not directly connected to the physical layer, check whether the peer ebgp-max-hop command is configured. 5. Check whether there are available routes to the peer in the routing table. 6. Check whether there are reachable routes to the specified connect-interface by using the ping -a source-ip-address host-address command. 7. Check whether the ACL that is used to disable TCP port 179 is configured.

Meanings of BGP peer status
In addition to the common Idle and Established status, BGP peer also has the following status: 1. active: indicates that the TCP connection of the BGP session has not been established. 2. no neg: indicates that the negotiation is not performed. If IPv4 Unicast is configured at one end, and IPv4 Unicast and IPv4 Multicast are configured at the other end, after the peer is established, you can discover that IPv4 Unicast negotiation succeeds, and the BGP peer is in Established status. However, the IPv4 Multicast is in no neg status in that IPv4 Multicast is not configured at one end. 3. Idle (Admin): indicates the BGP peer is proactively disabled, and there is no attempt to establish it again. If the peer ignore command is executed, or this peer is set to be down through the MIB, this peer remains in this status.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top