06-09-2010 04:18 AM - edited 03-04-2019 08:43 AM
I am troubleshooting a potential BGP issue with dropping neighbour relationships. Our provider suspects it is a PMTUD issue between our CE and their PE routers, and we get the following output from 'show bgp neigh' on our CE.
The 12.4 config guide indicates that PMTUD is enabled by default for BGP sessions, and I am having difficulty understanding what the PmtuAger counter is indicating in the output below:
We are seeing these across the majority of the routers connrcted into this particular WAN. I have checked routers part of a different WAN and do not get these counters increasing on the PmtuAger - and our provider says they do not see them on their side either. The provider is suggesting we enable 'ip tcp path-mtu-discovery' globally on the router - so our CE config matches their PE config - but I am doubtful this will resolve the issue.
Can anyone shed any light on this.
------
#sh bgp ne
<snip>
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x195BA7540):
Timer Starts Wakeups Next
Retrans 68648 491 0x0
TimeWait 0 0 0x0
AckHold 68840 67774 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 13433335 13433334 0x195C339D8
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 457483099 snduna: 458778564 sndnxt: 458778564 sndwnd: 15700
irs: 1842507960 rcvnxt: 1843884990 rcvwnd: 15814 delrcvwnd: 570
SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 4 ms, maxRTT: 500 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable, md5
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
06-09-2010 04:33 AM
My understand is i beleive the BGP default MSS is 536 bytes. As you mentioned newer IOS versions state that the PMTU discovery process is turned on by default which helps optimize BGP TCP packet sizes and in turn make it more efficient based on the media the BGP updates are traversing.
PmtuAger = A path MTU age timer is an interval that displays how often TCP estimate the PMTU with a larger maximum segement size (MSS). when the age timer is used, TCP path MTU becomes a dynamic process. If the MSS is smaller than what the peer connection can manage, a large MSS is tried everytime the age timer expires.
See this for better explanation https://www.cisco.com/en/US/docs/ios/12_4t/12_4t2/ht_socop.pdf
Francisco.
https://www.cisco.com/en/US/docs/ios/12_4t/12_4t2/ht_socop.pdf
06-09-2010 04:37 AM
Also TCP path MTU discovery is enabled by default for all BGP neighbor sessions, but you can disable, and subsequently enable, the TCP path MTU globally for all BGP sessions or for an individual BGP neighbor session.
06-09-2010 04:39 AM
Thanks Francisco,
So based on what you are saying the coutner is increasing as we are sending packets with an MSS larger than 536 and this shouldnt be a problem?
Do yo uthink the provider suggested 'fix' of enabling ip tcp path-mtu-discovery globally would have an impact on the behaviour?
06-09-2010 04:50 AM
The tcp path-mtu-discovery command should take care of the problem for you without any impact
All TCP sessions are bounded by a limit on the number of bytes that can
be transported in a single packet. This limit, known as the Maximum
Segment Size (MSS), is 536 bytes by default. In other words, TCP breaks
up packets in a transmit queue into 536 byte chunks before passing
packets down to the IP layer. Use the show ip bgp neighbors | include
max data command to display the MSS of BGP peers:
Router# show ip bgp neighbors | include max data
Datagrams (max data segment is 536 bytes):
Datagrams (max data segment is 536 bytes):
Datagrams (max data segment is 536 bytes):
Datagrams (max data segment is 536 bytes):
The advantage of a 536 byte MSS is that packets are not likely to be
fragmented at an IP device along the path to the destination since most
links use an MTU of at least 1500 bytes. The disadvantage is that
smaller packets increase the amount of bandwidth used to transport
overhead. Since BGP builds a TCP connection to all peers, a 536 byte MSS
affects BGP convergence times.
The solution is to enable the Path MTU (PMTU) feature, using the ip tcp
path-mtu-discovery command. You can use this feature to dynamically
determine how large the MSS value can be without creating packets that
need to be fragmented. PMTU allows TCP to determine the smallest MTU
size among all links in a TCP session. TCP then uses this MTU value,
minus room for the IP and TCP headers, as the MSS for the session. If a
TCP session only traverses Ethernet segments, then the MSS will be 1460
bytes. If it only traverses Packet over SONET (POS) segments, then the
MSS will be 4430 bytes. The increase in MSS from 536 to 1460 or 4430
bytes reduces TCP/IP overhead, which helps BGP converge faster.
After enabling PMTU, again use the show ip bgp neighbors | include max
data command to see the MSS value per peer:
Router# show ip bgp neighbors | include max data
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):
Hope the info i have provided you is helpful. Pls rate if so.
Francisco
06-09-2010 04:56 AM
One last query - If this is enabled by default as shown under the show bgp neighbor command outputand my max data segment is showing as 1460 - is it still necessary to enable it globally?
#show bgp neigh
Transport(tcp) path-mtu-discovery is enabled
Datagrams (max data segment is 1460 bytes):
I guess I should just apply the command and see what happens..
06-09-2010 05:06 AM
Sorry I messed up the rating!
06-11-2010 06:29 AM
Hello,
I was doing a bug scrub for something else and i came across this bug SCsz97239.
Check it out. It might be applied to you or not.
Francisco.,
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: