一、实验
1、拓扑图
2、基础配置
AR1
<Huawei>sys
[Huawei]un in e
[Huawei]sysname AR1
[AR1]int g0/0/0
[AR1-GigabitEthernet0/0/0]ip address 12.1.1.1 24
AR2
<Huawei>sys
[Huawei]un in e
[Huawei]sysname AR2
[AR2]int g0/0/0
[AR2-GigabitEthernet0/0/0]ip address 12.1.1.2 24
3、我们在AR1 g0/0/0抓包
4、配置BGP
AR1
[AR1]bgp 1
[AR1-bgp]peer 12.1.1.2 as-number 2
AR2
[AR2]bgp 2
[AR2-bgp]peer 12.1.1.1 as-number 1
查看一下，要多等一会
一般来说，邻居指向完成之后（[AR1-bgp]peer 12.1.1.2 as-number 2），路由器就要去指定的路由器接口发送三次握手请求，三次握手成功之后，就进入Established状态
它等待建立的时间有一个名词：Start事件
因为在华为里，它认为BGP是一个很复杂的协议，华为在设计的时候，它就给操作者一个预留的时间，这个时间就是start事件，32秒
所以在华为里，建立三次握手之间呢，需要一个start事件，在32秒内，BGP是不会做任何事情，等待32过去以后，它才会主动发起三次握手，或接受别人的三次握手
二、BGP邻居状态机
1、idle
触发条件：
BGP初始状态，一旦配置了BGP的peer以后，或者重置了已存在的peer之后，就会进入这个状态，在这个状态下BGP不会向这个peer发送TCP三次握手，同时也会拒绝这个peer发来的TCP3次握手。
关键机制：
在 进 入 这 个 状 态 时 有 一 个 start 事 件 ， 这 个 事 件 会 维 持 32 秒 。 在 这 个 之 后 开 始 建 立 该 peer 的 TCP3 次 握 手 ， 开 始 建 立 TCP 连 接 ， 发送 SYN 以 后 ， 进 入 到 connect 状 态 。
常见的几种idle状态原因：
1、如果没有去往peer的路由，那么就无法SYN，此时该peer会一直卡在idle
2、收到了错误信息，回退到了idle
3、 手动挂起邻居[AR1-bgp]peer 12.1.1.2 ignore （一般来说两端都要配置）
2、connect（连接状态）
关键动作：
在这个状态下，BGP会启动连接重传定时器（connect retry 默认32秒），等待TCP3此握手完成
状态转换：
a、向邻居发起SYN以后就会进入这个状态，在这个状态要完成TCP3次握手
b、如果TCP3此握手完成，则向邻居发送open报文，然后转换到opensent状态
c、 如果TCP3此握手失败，则将会把这个peer状态改为active
d、 如果重传计时器超时，BGP没有收到邻居的响应，那么会卡在connect状态
常见的几种connect状态原因：
1、邻居没有给我响应
2、我的SYN在沿途中可能遇到了阻碍，没有到达对方（也可能是在沿途中没有到达的路由所致）
3、 EBGP邻居没有配置TTL多跳
总结一句话，就是SYN没有被邻居响应
3、Active（活跃的）
触发条件：
当TCP三次握手失败，才会进入这个状态
关键机制：
在这个状态下，BGP总是试图去建立TCP3次握手
1、如果在多次尝试下，TCP3次握手成功了，那么BGP会向该peer发送open报文，关闭重传定时器，转至opensent状态
2、如果在多次尝试下，TCP3次握手仍然失败，那么BGP会将该peer停留在Active状态
3、如果重传定时器超时（32s），且没有得到该peer的响应，那么会转至connect状态
4、opensent（open报文已发送）
核心逻辑：
在这个状态下，BGP已经向该peer发送了OPEN报文，在等待对方给我发送OPEN报文
1、如果收到了对方发送的OPEN报文，参数协商成功，则会向该peer发送keeplive报文，然后转到openconfirm状态
2、如果收到了对方发送的OPEN报文，参数协商失败，则会发送notification报文，然后转到idle状态
5、openconfirm（open报文已确认）
状态验证：
1、在这个状态下 BGP等待对方的keepalive报文，如果收到了对方的keepalive报文则转换为established状态
2、在这个状态下 BGP如果收到了notification报文，则转换为idle状态
6、established（连接已建立）
正常运行状态：
在这个状态下说明邻居建立完毕。在这个状态下可以交互的报文有：update，notification，keepalive，router-refresh
1、如果在这个状态下，收到正确的update或keepalive报文，那么BGP会认为邻居处于正常运行状态，继续保持
2、如果在这个状态下，收到错误的update或keepalive报文，那么BGP会认为邻居处于异常运行状态，会发送notification报文，并转到idle状态
router-refresh报文的发送是不会影响邻居关系
三、BGP报文：
BGP报文默认是由两部分组成，分别是BGP报文头，和具体报文内存
1、BGP报文头
Marker：占用16字节，默认全F，用于检查BGP邻居头部的消息是否完整
Length：占用2字节，用于描述BGP报文的总长度，包括了头部和具体部分
Type ：类型，用于描述当前BGP报文类型，分为1 2 3 4 5 ，如下
1、open报文
用于建立BGP邻居的连接，协商BGP参数的报文
2、update报文
用于BGP邻居之间交互路由信息的报文
3、notification报文
差错报文，用于报错，且中断邻居关系的报文
4、keepalive报文
用于保持邻居连接的报文，用于保活
5、router-refresh报文
用于在策略改变之后，请求邻居重新发送路由信息，并且只有支持路由刷新能力的设备才会响应这个报文
2、open报文
version ：BGP版本，默认都是版本4
my as ：描述发送此报文的路由器所处的AS号，如果对端的AS号和本地配置不一致，则协商失败，发送notification报文
hold time：描述路由器邻居失效时间，默认情况是keepalive的3倍，当两端hold time不一致时，需要协商为数值低的使用
bgp id ：用来描述该发出该报文的路由器BGP router-id
optional parameters length：BGP协商参数字段长度
optional parameters：BGP协商参数
3、update报文
withdrawn routes length：用来描述失效的路由长度
total path attribute length：用来描述携带的属性长度
path attributes：携带的属性信息
NLRI：网络层可达信息，用来描述所携带的路由的网络号和掩码长度
针对属性不同的路由条目，需要分开update报文发送
具有相同属性的路由条目，可以在一条update报文发送
withdrawn routes length：如果这个参数不为空，那么下面就会显示携带的需要删除的路由信息
如图
4、注：
报文这个东西，最主要的就是看open报文和update报文，像keepalive这种没什么看头，它就是一个keepalive信息，我截几张图，给大家看一下
keepalive
notification
这种信息只用看它的BGP报文头Type，知道它是那类就行
四、抓包与故障排查要点
报文交互流程
先等待32s 的start事件（这期间是不会发送tcp报文的）
1、三次握手建立（发送tcp报文）
2、发送open报文（协商 AS 号、Hold Time、BGP ID 等参数）
3、这是什么呢？拆链报文，因为BGP的TCP握手是双向的，最后建立的TCP连接呢，是俩组（4个），当它每次建立三次握手之后，它要将其中一个拆掉。我们看图，建立TCP是12.1.1.1向12.1.1.2发起的，拆链是12.1.1.2向12.1.1.1发起的，保留的是12.1.1.1建立的TCP握手
邻居地址详细信息
这里有个命令可以修改keepalive时间和hold time时间[Huawei-bgp]timer keepalive 50 hold 150，但是这样会影响邻居，导致重新建立。
协商规则
hold time：
默认情况下hold time是keepalive的3倍关系，keepalive默认60s
如果从邻居接受到达hold time和自己的hold time相同，则不做改变
如果从邻居接受到达hold time和自己的hold time不同，则协商结果是使用数值小的hold time执行
如果协商后的hold time/3，和自己的keepalive值不同，选用数值小的执行，如下图
至此结束
扫一扫
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
