对“ Down BGP”连接进行故障排除

昨天，当我们的BGP路由之一短时间中断时，我们的网络发生了短暂的中断。值得庆幸的是，几分钟后，我们的连接故障转移到了辅助BGP路由，并且在ISP端关闭/不关闭后，主路由开始运行。

我们正在运行2个运行iOS 12.2 58的堆叠式（背板）Cisco 3750e交换机。

在与ISP的对话中，他们无法给出原因的任何明确答案。我们可以做些什么来找出最终的原因，以避免将来再出现此问题？

错误时记录

172258: May  6 14:43:06: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Down BGP Notification sent
172259: May  6 14:43:06: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.12.34 4/0 (hold time expired) 0 bytes
172260: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Multicast topology base removed from session  BGP Notification sent
172261: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Unicast topology base removed from session  BGP Notification sent

记录ISP进行关闭/不关闭以重置BGP时的日志

172542: May  6 15:04:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to down
172543: May  6 15:04:16: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to down
172544: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 DOWN on interface GigabitEthernet2/0/49 non DR
172545: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 UP on interface GigabitEthernet2/0/49 
172546: May  6 15:04:16: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to xxx.xxx.12.35 on interface GigabitEthernet2/0/49
172547: May  6 15:04:18: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to up
172548: May  6 15:04:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to up

记录BGP连接最终从空闲状态变为Up的时间

172828: May  6 15:27:33: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Up

我们这端的BGP接口（注意：没有CRC，丢弃，冲突报告...）

GigabitEthernet2/0/49 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxx.xxxx
Internet address is xxx.xxx.12.35/31
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:12, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/52/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 14536000 bits/sec, 1655 packets/sec
5 minute output rate 1010000 bits/sec, 640 packets/sec
413176726 packets input, 428902543141 bytes, 0 no buffer
Received 143495 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 139275 multicast, 0 pause input
0 input packets with dribble condition detected
125748632 packets output, 42915625632 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

172259：5月6日14:43:06：％BGP-3-NOTIFICATION：发送给邻居xxx.xxx.12.34 4/0（保持时间已过期）0字节

这通常意味着连接的另一端在保持计时器内（默认为180秒）未响应任何保持活动状态。造成此问题的原因有很多。通常，它是layer3可达性问题。如果再次发生，则应通过ping和telnet（对端口179的telnet，查看其是否响应）进行测试，以排除第3层问题。

如果不是第3层可达性问题，那么邻居的一端存在问题（在这种情况下，更可能是远端）。

如果您只是想寻找“根本原因”，请执行以下操作：

您可能想问您的提供商，在此之前是否对他们的端进行了任何配置更改。在Cisco路由器上有一些实例（目前还不能100％保证目前的代码版本），当一侧删除并重新添加带有“ mpls-ip”和/或“ mtu”的“ route-map”时，BGP会话将震荡BGP对等中的配置。尽管这种维护不应该导致对等会话出现问题，但我听说过这种情况。

另外，我不确定他们是否需要深入研究以删除接口并将其恢复为“解决”问题。我认为只需重置对等会话就足够了，但是如果在发生故障时没有流量通过，则可以说他们放弃接口以使事情再次滚动并不重要。

这可能是MTU问题。有一阵子。启动正常，但是当收到具有很多路由的UPDATE时，由于MTU不匹配，它会丢失。另外，如果在两个路由器之间有L2设备（交换机？媒体转换器？），则有可能在接口不关闭的情况下中断连接。

不是从我所看到的。您的ISP的路由器停止响应来自路由器的问候消息，这就是为什么您失去BGP连接的原因。您的路由器也有可能退出了侦听来自ISP的问候消息的过程，但是我看不到任何明显的消息可以帮助您查明问题。也许更专注于ISP的人可以发表评论并阐明一些想法？