Today, let’s talk about the neighbor negotiation process of BGP. During the collation process, such a problem was discovered.
There are 5 messages in BGP
1. Open (code 1): used to establish a connection, including version number (such as BGP3/BGP4) Hold Time = 180s (is a negotiation process, subject to a smaller Hold Time), Router-ID (OSPF and BGP can be configured manually), AS number (range from 1 to 65535, of which the AS number range of 64512 to 65535 is reserved for private);
2. KeepAlives (code 4): Periodic sending is used to maintain the connection check path (this packet is unreliable), T=Hold Time/3, Hold Time=0 => No KeepAlive., keepalive is a BGP message header sent in 19-byte cycles, without a data field.
3. Update (code 2): The message contains three components: network layer accessibility message (NLRI), path attributes, and revoked routes. It includes the path and attributes to the destination network, which can be used to update routing information. There is only one path at a time, but there can be multiple networks. Update can delete (declare unreachable) and add (declare accessible) routes. The content is the length of the prefix.
4. Notification (code 3): An error occurred in the network. After detection, it was disconnected and a notification was sent to the other party.
5. Route-Reflesh message: an optional message (negotiated during capability advertising) that is sent to request dynamic BGP route updates from the Adj-RIB-Out table of a remote BGP speaker
The negotiation process is basically: Idel, connect, open sent, open confirm, and establish.
5 states of BGP neighbors establishing sessions:
1. Idle: Look up the routing table. The process BGP initializes its resources, resets a connection retry timer, initiates a TCP connection, and starts listening to the connection initiated by the remote peer.
2. Connect: After finding the routing table, performing TCP three-way handshake. If the TCP connection is successful, it will go to the OpenSent state. If the TCP connection fails, it will go to the active state and try to connect again.
3. Open Sent: After holding hands, send an Open message message, wait for its peer to send an open message. If an error occurs, send an error message and return to the idle state. If there is no error, start sending Keepalive and resetting the keepalive timer.
4. Open Confirm: When receiving an Open message from the other party, if the keepalive message is received, BGP will enter the established state and the neighbor relationship negotiation is completed; if the system receives an update or keepalive message, it will restart the hold timer; if the Notification message is received, BGP will return to the idle state.
5. Established: Session establishment, the final state of the neighbor relationship negotiation process; at this time, the BGP will start exchanging route update packets with its peers.
PS: Active status: When the router sends an OPEN packet to the neighbor to wait for a response, if no response is received for a long time, the timeout will be timed out. After the timeout, the status will change to Idle or connect? Trying to initiate a TCP connection to obtain a peer, successfully transfer to the Open Sent state, the connection retry timer timed out, and the connection state is back, which is caused by a problem on the TCP link. ? ?
The main reasons for the problems are:
1. The ip-address configuration after the Neighbor command is wrong;
2.
3. The update source is incorrect, or the update source is unreachable.
answer:
1. When the BGP speaker is in an active state, BGP tries to form a peer by initializing the transmission protocol connection. If the transfer connection is established, it enters the OpenSent state. (Send OPEN information at the same time). If the ConnectRetry timer timed out, BGP restarts the ConnectRetry timer and returns to the Connect state. It will only retreat to the Idle state when the system aborts, or if TCP is artificially aborted.
2. Question: In the IBGP relationship, the next-hop ip address I see when sh ip b. The next hop address is the update source that advertises the route's IBGP. ? ? ? Or Router-id? ? ?
answer: The IP address of next-hop is the update source address. Router-ID is actually just an identifier of the router and does not have much meaning. It can be virtual. For example, it is usually the loopback address. There is no requirement that TCP can be reached. However, the update source must be accessible by TCP. Otherwise, how to ensure a certain communication destination for routing information updates? Right.
There is another solution that depends on the tcp session in sh ip bgp nei, but it still doesn't. If not, check the route and acl.
Article entry: csh Editor in charge: csh