如上图所示,两台V5的路由器和一台V7的防火墙通过一台二层交换机互联,彼此建立IBGP邻居;通过BGP和BFD的联动,以实现链路的快速收敛。
相关配置完成后,发现RTA和防火墙FW之间的BFD session状态一直是down的状态,其它各IBGP邻居间的BFD session均是正常的up状态,如下显示:
首先,RTA ping防火墙互联地址可以通,路由可达,彼此IBGP邻居也都是established的;
然后,仔细整理了设备侧相关配置,如下:
FW:
bgp 64573
router-id 10.10.178.251
peer 10.10.178.247 as-number 64573
peer 10.10.178.247 connect-interface GigabitEthernet1/0/1
peer 10.10.178.247 bfd
peer 10.10.178.247 password cipher $c$3$LleCbqG4kg1dvrJYOddkW2yuJElqCtgW6WMw
peer 10.10.178.252 as-number 64573
peer 10.10.178.252 connect-interface GigabitEthernet1/0/1
peer 10.10.178.252 bfd
peer 10.10.178.252 password cipher $c$3$9hcbCdgmwEBDNFa+mLgcGH/D2xraCmfzMX3O
RTA:
bgp 64573
router-id 10.10.178.252
undo synchronization
peer 10.10.178.247 as-number 64573
peer 10.10.178.251 as-number 64573
peer 10.10.178.247 password cipher $c$3$E0Djv5GohGqts7xEspxmHOki0Oa7xo6TGxJK
peer 10.10.178.247 next-hop-local
peer 10.10.178.247 connect-interface GigabitEthernet0/1
peer 10.10.178.247 bfd
peer 10.10.178.251 password cipher $c$3$OemVzu7SaRyRyIHyuCWoMSzBQIyODlE60twG
peer 10.10.178.251 next-hop-local
peer 10.10.178.251 connect-interface GigabitEthernet0/1
peer 10.10.178.251 bfd
RTB:
bgp 64573
router-id 10.10.178.247
undo synchronization
peer 10.10.178.251 as-number 64573
peer 10.10.178.252 as-number 64573
peer 10.10.178.251 password cipher $c$3$24rwMOOagmkI5pmdwWjLQCazofrvFxNQ5Ukk
peer 10.10.178.251 next-hop-local
peer 10.10.178.251 connect-interface GigabitEthernet0/1
peer 10.10.178.251 bfd
peer 10.10.178.252 password cipher $c$3$EPGG2WlJyMfwyfi6mJWw8FDLsyd+XLem9MDW
peer 10.10.178.252 next-hop-local
peer 10.10.178.252 connect-interface GigabitEthernet0/1
peer 10.10.178.252 bfd
通过核对设备侧配置并查阅相关命令手册发现,V7设备在使用peer bfd命令时,后面是建议跟上multi-hop 或者single-hop参数,若在未指定该参数的情况下,是采用BFD多跳方式检测本地路由器和指定IBGP对等体之间的链路,而本地路由器和BGP对等体采用的BFD检测方式(单跳或多跳)必须相同,否则无法建立BFD会话。对于现场组网来讲,属于单跳的情况。
到此时,故障原因有了眉目,建议现场在防火墙侧peer bfd后面加上single-hop参数后,RTA和防火墙间的BFD session恢复up状态。
但是,疑问又来了,同样的配置和组网情况下,为什么防火墙和RTB间BGP BFD联动没有指定single-hop参数,之间的BFD session也是正常up的状态,于是建议现场在防火墙侧抓包反馈如下:
防火墙收到的报文:
防火墙发出的报文:
V7设备判断是否是直连的条件是端口号为3784并且ttl为255,现场抓包显示3784端口号的报文ttl为254,因此V7设备当做非直连处理,所以可以V7侧可以正常建立。如果V5侧收到端口号为4784、ttl为64的报文当作直连处理,就可以在V5侧也建立。
对于防火墙侧为什么收到报文的ttl值是254而不是255,怀疑是报文路径有问题,于是进一步查看设备侧的路由表信息确认。
RTA接口地址 10.10.178.252/25
RTB接口地址 10.10.178.247/24
防火墙接口地址 10.10.178.251/25
RTB路由表:
10.10.176.128/25 BGP 255 0 10.10.178.251 GE0/1
10.10.177.0/24 Static 60 0 10.10.178.253 GE0/1
10.10.178.0/24 Direct 0 0 10.10.178.247 GE0/1
10.10.178.128/25 OSPF 10 400 10.10.178.252 GE0/1(优先)
防火墙路由表:
10.10.178.0/24 BGP 255 0 10.10.178.247 GE1/0/1
10.10.178.128/25 Direct 0 0 10.10.178.251 GE1/0/1
RTA路由表:
10.10.178.128/25 Direct 0 0 10.10.178.252 GE0/1
由路由表可以看出,由于接口地址掩码长度的不同,RTB去往防火墙的路由会根据最长匹配原则,优选ospf学来的下一跳为RTA接口地址的路由,然后从RTA再匹配直连路由到达防火墙,导致报文根据路由转发经过了两跳(多跳),也就解释了上述现象。
至此,故障问题水落石出。建议现场修改了RTB的接口地址掩码为25后,复现了前面RTA和防火墙BFD 会话down的故障现象,然后在V7防火墙侧peer bfd后加上single-hop参数,问题解决。
1、V7设备侧peer bfd后加上single-hop参数,缺省是multi-hop方式;
2、规范互联接口地址掩码,保证路由选路得当。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作