[j-nsp] SSH/Telnet session hanging

[Jeff Wheeler]

On Wed, Jun 1, 2011 at 12:14 PM, Mark Tinka <mtinka at 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 <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts