HCNP Routing&Switching之BGP报文结构、类型和状态

2021-10-19

  前文我们了解了BGP的邻居建立条件、优化以及BGP认证相关话题,回顾请参考https://www.cnblogs.com/qiuhom-1874/p/15395723.html;今天我们来聊一聊BGP报文结构、类型和状态相关话题;

  BGP报文结构和类型

  提示:BGP工作在应用层,其端口号为179;报文结构是7层封装,BGP报文主要由两种报文头部组成,公共头部和类型头部;公共头部主要用来描述bgp AS号,包头长度,报文类型,版本信息等等信息,类型头部主要用来描述不同类型的BGP报文相关属性;BGP报文类型有5种,分别是open包、update包、Notification包、keepalive和route-refresh;其中open包主要用来建立邻居使用,在邻居建立以后相互发送一次,后续不再发送;keepalive包主要作用是维护邻居关系,默认情况下bgp是每60秒发送一次keepalive包向邻居通告自己还“活”着;如果连续三个周期没有收到邻居的keepalive包,此时本端会认为邻居挂掉;update包主要用来路由更新,其包里的内容主要是用来描述更新的路由信息和属性;只要有路由更新对应都会向邻居发送更新;notification包主要用来发送当检测到错误,发送后关闭BGP连接的信息;Route-refresh包主要用来触发请求邻居重新通告路由;

  BGP邻居状态

  提示:BGP邻居状态有6种,分别是idle,connect,active,open-sent,open-confirm,established,其中idel状态是最开始状态,表示邻居为空,没有邻居;当配置好邻居信息以后,如果在对应路由表中找到去往邻居的路由,此时邻居关系会从idel转变为connect;如果没有路由,则还是原来的idle状态,即没有发送tcp三次握手请求报文的状态;connect状态表示发起TCP连接,等待tcp连接完成,即本端发送TCP三次握手请求,等待对端回复完成tcp三次握手的状态,该状态会有一个超时时长,如果在规定的时间内还是没有建立tcp连接,该状态会超时重试,即没有邻居回复本端的三次握手请求的状态;active状态表示tcp建立失败,继续尝试tcp连接,即tcp三次握手的报文已经发送,但是由于某些错误导致tcp三次握手没能正常建立的状态,该状态会有一个尝试时间,如果尝试tcp连接还是失败则该状态保持,如果tcp建立超时,则会从active状态转变为idle状态,如果tcp建立成功则会从active状态转变为open-sent状态表示tcp连接成功,并已发送一次open包后的状态;即本端三次握手成功建立,发送open包以后的状态;open-confirm表示对端收到本端发送的open包后的状态,如果没有收到对端的open包,此时会从open-sent状态进入active状态,表示tcp连接失败,或者错误的TCP连接,或者对端不认可和本端建立邻居;established表示邻居建立完成的状态;即收到对端的发送到keepalive包以后的状态;open-sent/open-confirm/established这三种状态一旦发生错误都会返回到idle状态;

  BGP邻居建立过程和状态转换

  提示:idle和connect状态主要发生在邻居建立初期,tcp三次握手阶段,如果三次握手正常交互,对应状态会从idle转变为connect状态,表示发送了tcp三次握手请求,等待完成tcp三次握手;三次握手成功以后,如果发送了open包,对应状态会从connect状态转变为open-sent状态,如果正确接收到对端的open包以后,对应状态会从open-sent状态转变为open-confirm状态,并向对端发送keepalive包,通告本端的存活状态;如果对端收到本端发送的keepalive包以后,对应状态会从open-confirm状态转变为established状态;以上是bgp邻居建立过程中几种状态切换过程;在established状态下,BGP路由器可以和邻居交换update、keepalive、Route-refresh报文和notification报文;

  实验:如下拓扑,配置BGP

  R1的配置

sys
sys R1
int g0/0/0
ip add 12.0.0.1 24

bgp 12
router-id 1.1.1.1
peer 12.0.0.2 as 12
View Code

  R2的配置

sys
sys R2
int g0/0/0
ip add 12.0.0.2

bgp 12
router-id 2.2.2.2
peer 12.0.0.1 as 12
View Code

  只配置了R1未配置R2时,R1bgp邻居状态验证

  提示:此时R1并未发送tcp三次握手请求,所以对应邻居状态还是idle状态;表示正在查找路由表去往邻居的路由;

  在R1查找到对应去往邻居的路由以后,发送TCP三次握手请求后,对应邻居状态

  提示:R1发送三次握手请求后,对应邻居从idle状态转变为connect状态,表示发送了三次握手请求,等待三次握手完成;

  在R1上抓包

  提示:在R1上抓包只有arp包,其原因是R2没有配置,R1找不到R2的mac地址,所以一直发送广播请求R2的mac地址;

  配置R2接口地址

  验证:在R1上查看bgp邻居状态,看看有什么变化没有?

  提示:可以看到对应邻居状态一直处于connect状态;

  在R1上抓包,查看对应tcp三次握手的情况

  提示:可以看到R1向R2的179端口发起三次握手请求,对端R2一直发送重试;其原因是R2没有配置bgp,当然179端口并不会处于监听状态;所以R1请求R2的179端口,对应R2回复重试;

  配置好R2 bgp邻居信息

  在R1上查看邻居关系

  提示:可以看到对应R1的邻居关系为established,这个过程相对较快,中间的状态我们看不到,但从上面的提示可以看到对应established的前面一个状态为openconfirm状态;

  查看R1上的抓包过程

  提示:可以看到R1向R2发起三次握手请求,对应R2响应确认并向R1发起建立连接请求,对应R1确认,对应发送open包,再后续发送keepalive包;

  在R1上配置邻居2.2.2.2 对应as号为12

  查看邻居状态

  提示:可以看到我们配置的2.2.2.2,对应邻居状态为idle,表示没有发送tcp三次握手请求;其原因是本地没有去往2.2.2.2的路由,所以对应邻居会一直处于idle状态;

  验证:在R1上添加静态路由去往2.2.2.2,看看对应邻居状态是否发生变化?

  提示:可以看到在R1上添加静态路由以后,对应bgp邻居状态从idle状态变为了connect状态;说明R1通过查找路由表,已经向2.2.2.2发起tcp三次握手请求;

  验证:查看R1的抓包,看看R1是否向2.2.2.2发起tcp三次握手?

  提示:可以看到对应R1的确在向2.2.2.2发送tcp三次握手请求;

  在R2上新建lo接口并配置接口地址为2.2.2.2/32

  再次验证R1上2.2.2.2的邻居状态是否发生变化?

  提示:可以看到R1上2.2.2.2邻居状态从connect状态转变为active状态,这是为什么呢?我们知道active状态是tcp三次握手失败,对应状态;

  在R1抓包查看tcp三次握手情况

  提示:可以看到R1向2.2.2.2发起三次握手请求,对应2.2.2.2也回复并建立起tcp连接,对应R1向2.2.2.2发送了open包以后,对应2.2.2.2又给R1发送了断开连接请求;说明R1和2.2.2.2并没有建立起TCP连接,即tcp连接建立失败,所以从connect转态转变为active状态;其实这里的原因是R2回复R1的包其源地址为12.0.0.2和R1配置的邻居2.2.2.2地址不匹配导致的;

  验证:在R2上更改更新源为lo2接口地址,看看邻居状态的变化

  提示:在R2上更改更新源以后,对应和12.0.0.1邻居状态从established变为了idle,这是因为更新源发生变化导致tcp连接错误;所以从established状态转变为idle状态;

  在R1上验证邻居状态

  提示:可以看到此时R1上和2.2.2.2建立起邻居,但是对应和12.0.0.2的邻居状态变为了active,这是因为从R2过来的包,其源地址为2.2.2.2,和本端配置的邻居12.0.0.2不匹配,所以导致tcp连接建立失败,所以在R1上看到和2.2.2.2正常建立tcp连接,邻居正常,和12.0.0.2建立不起来TCP连接,邻居状态处于active状态;

  总结:指向bgp数据包源ip地址的路由不存在,即没有邻居路由,对应邻居关系为idle;邻居与错误地址建立对等关系,即源地址不匹配,导致邻居状态为active状态;不存在该路由器的邻居声明,即对端未配置本端为邻居,邻居状态会卡在active(如果对端未配置bgp会卡在connect状态);as号配置错误会导致对应邻居状态为active;以上原因都可能导致邻居状态在idle/active状态循环;