On Wed, Jun 1, 2011 at 12:14 PM, Mark Tinka <mti...@globaltransit.net> wrote: > It's probably time to break out the 'tcp-mss' option for > BGP.
This is exactly the reason that BGP implementations used to default to MSS 536 for all iBGP sessions. The change in default behavior has happened over the past five years or so, and it is not without peril. Customers and vendors have thought that raising the MSS will improve convergence speed, and they are correct that it has shown to result in some improvement; however the same improvement could be had with larger TCP windows and less stupidity with respect to TCP inside BGP daemons. This has been a "pet peeve" of mine for many years. The reason 536 used to be the default is it is based on the minimum allowable MTU of 576 for IP. There should never be any router or link used for IP that cannot forward a 576 octet packet, or in the absence of extra IP options, a 536 octet TCP segment. So no matter how the IGP path within the network changes, you always knew that an iBGP session using 536 MSS would work correctly. Path MTU detection was not needed but it was not left out of iBGP by accident -- the implementors knew that one part of your backbone might support 9000 MTU and another part might support 1500 MTU, and that an IGP topology change could cause an already-established iBGP session to swing from a path supporting 9000 MTU to one supporing a smaller size, causing BGP session failure. eBGP differs in this regard because (in the absence of eBGP multihop or loopback peering) the correct MTU will be known and stable. The path taken by the eBGP TCP session can't change from one path to another with potentially different MTU. This is the reason that eBGP sessions often did not use 536 MSS and instead calculated the MSS based on the interface MTU toward the eBGP neighbor. I believe that vendors have made a mistake by changing this default, but it is inconsequential to most networks because they have a consistent MTU across their whole backbone. If you don't, you should base the iBGP TCP MSS on the smallest value which is safe for your network, and not use Path MTU Detection. You can decide to figure this on a per-session basis, but this simply produces complexity for minimal gain in convergence time. -- Jeff S Wheeler <j...@inconcepts.biz> Sr Network Operator / Innovative Network Concepts _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp