Reset Search
 

 

Article

Troubleshooting BGP Flaps due to MTU mismatch

« Go Back

Information

 
TitleTroubleshooting BGP Flaps due to MTU mismatch
Symptoms
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|30.1.1.3
Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend
30.1.1.3 10 ESTAB 42d10h21m 0 0 0 0

MLXe# sh ip route 30.1.1.3
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 30.1.1.0/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 30.1.1.3 | in segment
Maximum segment size: 1460
MLXe#

In the example above, 1460 is correct as 20 bytes is assigned to the TCP header and another 20 to the IP header.

Environment
Software Release: All NetIron Releases
Fixed in Version: N/A
Cause
MTU mismatches causing BGP neighbor flaps
Resolution
Ensure you complete these tasks on both BGP routers before you complete the procedures in this document:

Check the BGP configuration.
Verify that the BGP neighbor is reachable via Internet Control Message Protocol (ICMP) and no drops are observed.
Verify that the connected interface used to peer BGP is not oversubscribed and does not have any input/output drops or errors.
Check the CPU and memory utilization.

Here are some possible causes:

1. The interface MTU on both routers should be the same; run the show ip int | in MTU command in order to check the current MTU settings.

MLXe# sh ip int ve 30 | in mtu
encapsulation: ETHERNET, mtu: 1500
MLXe#

2. If the interface MTU on both routers are correct (for example, 1500) but the ping tests with DF bit set do not exceed 1300, then the Layer 2 domain on which the affected BGP session is formed might include inconsistent MTU configurations. Check each Layer 2 interface MTU. Correct the Layer 2 interface MTU in order to resolve the issue.

MLXe# ping 30.1.1.3 size 1500 no-fragment
Sending 1, 1500-byte ICMP Echo to 30.1.1.3, timeout 5000 msec, TTL 64, no fragment
Type Control-c to abort
Request timed out.
No reply from remote host.

MLXe# ping 30.1.1.3 size 1300 no-fragment
Sending 1, 1300-byte ICMP Echo to 30.1.1.3, timeout 5000 msec, TTL 64, no fragment
Type Control-c to abort
Reply from 30.1.1.3 : bytes=1400 time=1ms TTL=64
Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms
.
MLXe#

3. If you are unable to check/change the Layer 2 domain, you can use the ip tcp adjust-mss command in order to troubleshoot further; this command is configured at the interface level and affects all TCP sessions.

MLXe# conf t
MLXe(config)# int ve 30
MLXe(config-vif-30)#ip tcp adjust-mss 1300

Additional notes

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255