09-07-2017 04:40 AM - edited 03-05-2019 09:05 AM
Hi,
Can someone help me getting any brief document on PMTUD support for BGP? How it works, when to enable, when to disable etc?
I have tried several Cisco sites, but did not able to find a brief one.
Thanks for your help.
Regards,
Godwin. S
09-07-2017 04:53 AM - edited 09-07-2017 05:06 AM
Hi
It is useful when you have devices with different MTU configured basically packets passing through of different devices with different MTU configured on their interfaces.
To configure: neighbor x.x.x.x transport path-mtu-discovery ( also check the attachment, reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/configuring-bgp-neighbor-session-options.pdf )
This link could be useful:
http://nagendrakumar-nagendra.blogspot.com/2010/03/bgp-path-mtu-discovery.html
:-)
09-07-2017 06:19 AM
Hi Godwin,
In addition to Julio's points, let me share some thoughts.
You already know the obvious: Path MTU Discovery helps two communcating endpoints discover the maximum size of a packet that can pass between them unfragmented. This is done by sending out packets with the DF bit set, and listening to incoming ICMP Fragmentation Needed messages to understand whether the packets toward a particular peer should be made smaller.
The mechanism of PMTUD is not really BGP-specific; it is implemented in IP and TCP drivers, and BGP just sets the necessary options on the TCP socket when it creates it so that the PMTUD in the TCP/IP stack of the router can kick in. If you are interested in the nitty-gritty details, check out RFC 1191 for the PMTUD mechanism itself, and perhaps also RFC 2923 for a discussion of some pitfalls that have been discovered since.
Note that PMTUD does not make sense for eBGP peers that are directly connected back-to-back. These peers share the same link, and so are supposed to be using the same MTU; different MTUs on both sides of this link would constitute a misconfiguration, and would not be detected by PMTUD anyway.
So the PMTUD makes only sense for iBGP or eBGP neighbors that are at least one hop away of each other; note that for eBGP, this is a rare scenario. As a matter of rule, PMTUD is always a good thing if you can ensure that the ICMP Fragmentation Needed messages will not be blocked somewhere along the path. Sadly, exactly because many firewall and ACL implementations are overzealous, these messages are often dropped, breaking the PMTUD entirely.
Whether the PMTUD will make any difference is questionable. Assuming that you would use the PMTUD for iBGP neighbors, it is still your network, your AS, and you're the "master of all things" there, including MTUs. Usually, if possible, MTUs are the same along the entire network so PMTUD would not really be kicking into action. In situations where you have mixed MTUs, PMTUD would obviously be useful to have.
A couple of things to consider... :)
Best regards,
Peter
09-07-2017 06:28 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide