HCIP-17 BGP基础2
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协商参数