BGP邻居协商过程

bu

作者：cunshen    出处：SoUrCe
今天来说说BGP的邻居协商过程，在整理过程中，发现了这样一个问题.
BGP有5种message
1.  Open （code 1）：用于建立连接，包含版本号（如BGP3/BGP4）Hold Time＝180s（是一个协商的过程，以较小的Hold Time为准），Router-ID（OSPF和BGP可以手动配置），AS号(范围从1～65535，其中64512～
65535 的AS编号范围留作私有)；
2.   KeepAlives（code 4）：周期发送用于维护连接检查路径（这个包是不可靠的）,T＝Hold Time/3, Hold Time=0 => No KeepAlive.，keepalive 是个19 字节周期发送的BGP 消息头标，没有数据域。
3.   Update（code 2）：消息包含了三个组件：网络层可达性消息（NLRI）、路径属性和被撤销的路由。包括到达目的网络的路径和属性，更新路由信息用，一次更新只有一条路径，但可以有多条网络。Update可以删除（宣告不可达）和增加（宣告可达）路由.其内容是前缀的长度。
4.   Notification（code 3）：网络中出现错误（Error），检测到后断开连接并发送通知给对方。
5．Route-Reflesh message：一个可选的message (negotiated during capability advertisement) that is sent to request dynamic BGP route updates from the Adj-RIB-Out table of a remote BGP speaker
  协商过程基本上是：Idel，connect，open sent，open confirm，establish。
BGP邻居建立会话的5种状态：
1.       Idle：查找路由表，该过程BGP对它的资源进行初始化，复位一个连接重试计时器，发起一条TCP 连接，并开始倾听远程对等体所发起的连接。
2．  Connect：找到路由表后进行TCP三次握手，TCP 连接成功，则转到OpenSent状态，TCP连接失败，则转到active 状态,将尝试再次连接。
3．  Open Sent：握上手后发送Open message消息，等待其对等体发送打开消息，如果出错，则发送一条出错消息并退回空闲状态，如果无错，则开始发送Keepalive 并复位keepalive 计时器。
4．  Open Confirm：收到对方发来的Open消息，如果收到keepalive 消息，BGP 就进入established状态，邻居关系协商完成；如果系统收到一条更新或keepalive 消息，它将重新启动保持计时器；如果收到Notification消息，BGP 就退回到空闲状态。
5．  Established：会话建立，邻居关系协商过程最终状态；这时BGP将开始与它的对等体交换路由更新数据包。
PS: Active状态：当路由器发送出OPEN包给邻居等待回应，如果长时间未接收到回应则超时，超时后状态更改为Idle还是connect状态？试图发起TCP连接获得对等体，成功转到Open Sent状态，连接重试计时器超时，退回连接状态，这是由于TCP链路上出现了问题所致。？？
产生问题的原因主要有：
1.         Neighbor命令后面的ip-address配置有错；
2.         没有打上Neighbor命令（两边都要）
3.         更新源错误，或者更新源不可达。
  
answer:
1.当BGP speaker处于active状态，BGP尝试通过初始化传输协议连接来形成peer。如果传输连接建立，则进入OpenSent状态。（同时发送OPEN信息）。如果ConnectRetry 计时器超时，BGP重启ConnectRetry计时器，并且退回到Connect 状态。只有当系统中止，或者人为地把TCP中止时才退到Idle状态。
2.问：在IBGP关系中，在sh ip b的时候看到的那个next-hop的ip 地址。下一跳地址，就是通告该路由的IBGP 的 更新源。？？？还是Router-id？？？
answer：next-hop的IP地址是更新源地址。Router-ID其实只是路由器的一个标识而已，没有太多的意义。可以是虚拟的。比如，它通常就是loopback地址。不要求一定TCP可达。但是更新源必须TCP可达。否则怎么保障路由信息更新的一定传达目的地？对吧。
还有一个解决方法关键看sh ip bgp nei里面的tcp会话那一块，又还是没有。如果没有，检查路由和acl。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/18307/showart_176966.html