BGP MTU discovery

[CSCO12099251]

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

[Julio E. Moisa]

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

:-)

[Peter Paluch]

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

[Joseph W. Doherty]

I believe I've noticed, if you enable general PMTUD on a router, BGP then, by default, uses it.

Julio and Peter have also mentioned different MTU sizes along a path between BGP peers, but I believe I've also noticed if PMTUD isn't enable, BGP will use an MTU of 576 for "off-net" destinations. I.e. in situation where you know you have standard 1500 MTU Ethernet, it won't be used without PMTUD enabled.

In general, I think it useful to always have in enabled. Exceptions would be for cases where using is going to cause an issue.

Also on the subject of enabling PMTUD, I've also found increasing the default size of the device's TCP RWIN might also increase BGP initial route transfers between peers.