BGP has 5 kinds of message
1.Open (Code 1): Used to establish a connection, including a version number (such as BGP3/BGP4) Hold time=180s (is a negotiated process, whichever is the smaller Hold time), Router-id (OSPF and BGP can be manually configured), as number ( The range is from 1~65535, wherein the 64512~65535 as number range is reserved for private);
2.KeepAlives (code 4): Cycle send to maintain connection checking path (this packet is unreliable), T=hold time/3, Hold time=0 => no keepalive.,keepalive is a 19-byte cycle-sent BGP message headers, no data fields.
3.Update (Code 2): Message contains three components: Network layer Accessibility Message (NLRI), path attributes, and revoked routes. Includes paths and attributes to the destination network, updating routing information with only one path for one update, but can have multiple networks. Update can delete (declare unreachable) and increase (announce to reach) the route. Its content is the length of the prefix.
4.Notification (Code 3): Error in Network, disconnect after detection and send notification to each other.
5. Route-reflesh message: An optional message (negotiated during capability advertisement) which is sent to request dynamic BGP Route Updates from the Adj-rib-out table of a remote BGP speaker
The consultation process is basically: Idel,connect,open sent,open confirm,establish.
BGP neighbors establish 5 states of a session:
1.Idle: Locate the routing table, which BGP initializes its resources, resets a connection to retry the timer, initiates a TCP connection, and begins listening to the connection initiated by the remote peer.
2. Connect: TCP Three handshake after the routing table was found, TCP connection succeeded, then go to opensent State, TCP connection failed, then go to active state, will try to connect again.
3. Open Sent: After the grip, send an open message, wait for its peer to send open messages, if there is an error, send an error message and return to the idle state, if there is no error, then start to send keepalive and reset the keepalive timer.
4. Open Confirm: Received the open message from the other side, if you receive KeepAlive message, BGP into the established state, the neighbor relationship negotiations completed; If the system receives an update or keepalive message, it restarts the hold timer If the notification message is received, BGP returns to its idle state.
5. Established: Session establishment, the final state of the neighbor negotiation process; Then BGP begins to update the packet with its peer exchange route.
Ps:active Status: When the router sends an open packet to the neighbor to wait for a response, if the long time did not receive a response timeout, after the timeout state to idle or connect state? An attempt was made to initiate a TCP connection to obtain a peer, successfully go to the open sent State, connect retry timer timeout, return connection status, due to a problem on the TCP link.
The main causes of the problem are:
The ip-address configuration behind the 1.Neighbor command is faulty;
2. No neighbor command (both sides)
3. Update source error, or update source is not reached.
1. When BGP speaker is in an active state, BGP attempts to form peer by initializing a transport protocol connection. If the transport connection is established, it enters the opensent state. (The open message is also sent). If the connectretry timer times out, BGP restarts the Connectretry timer and returns to the Connect state. Only when the system is aborted, or the TCP is aborted artificially, is it back to the idle state.
2. Q: In the IBGP relationship, the IP address of the next-hop that is seen at the time of SH IP b. The next hop address is the IBGP update source that informs the route. Or Router-id???
The IP address of the answer:next-hop is the update source address. Router-id is actually just a logo for the router, not too much meaning. can be virtual. For example, it is usually the loopback address. Does not require a certain TCP to reach. However, the update source must be TCP accessible. Otherwise, how to protect the routing information update must convey the destination? Right.
There is also a solution to the key to see the SH IP bgp nei inside the TCP session that piece, or not. If not, check the routing and ACLs.