HCIP-17  BGP基础2

一、bgp的路由黑洞问题

1.bgp的同步功能

ipv4-family unicast  IPV4的地址簇

undo synchronization  关闭BGP同步功能

bgp的同步功能原理

当边界路由器从ibgp邻居收到一条路由后，会使用该路由和igp路由表进行比较。

如果在igp路由表中存在该路由即BGP同步

如果在igp路由表中不存在该路由即BGP不同步

如果bgp同步，边界路由器将会把该路由条目传递给其他的ebgp邻居。

如果bgp不同步，边界路由器将不会把该路由条目传递给其他ebgp邻居。

2.将bgp路由引入igp

不推荐。

原理上可以，但是，从路由承载能力上不行

3.as内部采用全互联模式（fullmesh）

4.使用gre隧道技术

[R2]int Tunnel 0/0/0

[R2-Tunnel0/0/0]ip add 24.1.1.2 24

[R2-Tunnel0/0/0]tunnel-protocol gre

[R2-Tunnel0/0/0]source g0/0/0

[R2-Tunnel0/0/0]destination 34.1.1.4

[R4]int Tunnel 0/0/0

[R4-Tunnel0/0/0]ip add 24.1.1.4 24

[R4-Tunnel0/0/0]tunnel-protocol gre

[R4-Tunnel0/0/0]source g0/0/1

[R4-Tunnel0/0/0]destination 23.1.1.2

5.通过lsp隧道解决路由黑洞

二、bgp的路由是如何产生的

1.通过network宣告路由表中已存在的路由条目

2.import-route 引入路由

被引入的路由需要在全局路由表加表。

3.自动聚合产生的路由条目

只能聚合import-route进来的路由条目，进行主类聚合。

被聚合的明细路由会被抑制。无法进行传递，只会传输聚合后的主类的路由

4.手动聚合产生

[R1-bgp]aggregate 172.16.2.0 255.255.254.0 detail-suppressed   手动抑制明细。

三、bgp报文open报文

open报文

它就相当于OSPF里面的hello报文。用于建立bgp的邻居的连接，协商bgp参数的报文

update报文用于bgp邻居之间交互路由信息及路由属性的报文。

notification报文，差错报文。用于报错的信息的传递，并且中断邻居关系的报文。

keepalive报文用于保持邻居连接的报文

refresh报文用于在改变策略之后。请求邻居重新发送路由信息，并且只有支持刷新能力的设备才能响应这个报文

四、bgp的邻居状态机

1.idle叫初始状态，bgp初始状态。

在进入这个idle状态时，会触发华为的start事件，这个事件时间为32秒。

在这个时间之后，才开始建立该peer的三次握手。建立TCP连接，在发送了syn以后。

进入到connect状态

常见的几种idle状态的原因：

如果没有去往该peer的路由，就无法发送syn。此时，该peer会一直卡在idle状态。

收到了notification报文之后会回退到idle状态。

手动挂起邻居：在邻居表中表现为idle (admin)。

2.connect状态（连接状态）

在这个状态下，bgp会启动连接重传定时器（connect retry默认为32秒钟），用于等待TCP完成三次握手。

向邻居发起syn后，就会进入到这个状态。在这个状态完成TCP三次握手。

如果TCP三次握手完成，则向该邻居发送open报文，然后转到opensent状态。

如果TCP三次握手失败，将会把这个peer状态改为active。

如果重传定时器超时，bgp没有收到邻居的响应。那么会卡在connect状态

常见的几种connect状态原因。

邻居没有给我响应。

我发出的syn在沿途中遇到了阻碍，没有到达对方。沿途路由不可达

ebgp邻居没有配置ttl多跳。

总结：卡在connect状态其实就是邻居没有给我响应。

3.active状态（活跃的状态）

当TCP三次握手失败时。才会进入这个状态。

如果在多次尝试下，TCP三次握手成功了。那么bgp会向该peer发送open报文。关闭重传定时器，转至opensent状态

如果在多次尝试下，TCP三次握手仍然失败，那么bgp会将该peer停留在active状态。

如果重传定时器32秒超时，且没有得到该peer的响应那么会转至connect状态

4.opensent状态（open报文已发送状态）

在这个状态下。bgp已经向该peer发送了open报文，在等待对方给我发送open报文

如果收到了对方发来的open报文并且参数协商成功，则会向该pere发送keepalive报文，然后转到openconfirm状态

如果收到了对方发来的open报文参数，协商失败，则会向该pere发送notification报文，然后转到idle状态。

5.openconfirm状态

在这个状态下bgp等待对方的keepalive报文。

如果收到了对方发来的keepalive报文则转换为establisheded。

在这个状态下bgp如果收到了notification报文，则转换为idel状态

6.Establisheded（链接已建立），

在这个状态下说明邻居已经建立完毕，这个状态下可以交互的报文：

update；Notification；keepalive；Route-refresh

如果在这个状态下收到正确的update和keepalive报文。bgp会认为邻居处于正常状态，继续保持。

如果在这个状态下收到了错误的update.和keepalive，那么bgp会认为邻居处于异常状态，会发送notification报文，转到idle状态。

Route-refresh报文的发送不影响邻居关系。

七、bgp的报文细节

主要由两部分组成，分别是bgp报文头和具体报文内容

bgp报文头：

Marker：占用16个字节。默认为全f。用于检查bgp邻居头部的消息是否完整

Length：占用两字节，用于描述bgp报文的总长度，包括报文头+具体报文内容。

type是用于描述当前bgp报文类型的分为12345。

1.具体报文：

version：bgp版本。默认都是四，

my as用于描述发出该open报文的路由器所属as号，同时校验对端的as号和本地配置的as号是否一致

Hold time是描述路由器邻居失效时间的。默认情况为keepalive时间的3倍。

当两端holdtime时间不一致时，需要协商为数值较低的执行

<R1>dis bgp peer 12.1.1.2 verbose 查看该邻居的具体信息。

BGp id描述发出该open报文的路由器bgp router ID

Optional parameter length  ：bgp协商参数字段长度

Optional parameters ：bgp协商参数