BGP neighbors form; however, at the time of prefix exchange, the BGP state drops and the logs generate missing BGP hello keepalives or the other peer terminates the session.
Complete these steps in order to determine if the MTU causes the BGP neighbors to flap:
1. Use the below commands in order to check which neighbor is affected and the connected interface on both BGP routers. If the peering address is a loopback address, check the connected interface through which the loopback is reachable. Also, check for the BGP ToSend on both peering routers. The consistent non-zero ToSend
is a strong indication that updates do not reach the peer due to an MTU issue in the path.
MLXe# show ip bg summary | in ToS|188.8.131.52
Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend
184.108.40.206 10 ESTAB 42d10h21m 0 0 0 0
MLXe# sh ip route 220.127.116.11
Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link
STATIC Codes - d:DHCPv6
Destination Gateway Port Cost Type Uptime src-vrf
1 18.104.22.168/24 DIRECT ve 30 0/0 D 34d23h -
2. Confirm the TCP agreed max data segment for both BGP speakers:
MLXe# sh ip bgp nei 22.214.171.124 | in segment
Maximum segment size: 1460
In the example above, 1460 is correct as 20 bytes is assigned to the TCP header and another 20 to the IP header.