[117500] in North American Network Operators' Group
RE:
daemon@ATHENA.MIT.EDU (Brian Dickson)
Tue Sep 15 16:40:47 2009
From: Brian Dickson <Brian.Dickson@concertia.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, Michael Ruiz
<mruiz@telwestservices.com>
Date: Tue, 15 Sep 2009 17:39:33 -0300
In-Reply-To: <alpine.DEB.1.10.0909141937460.20805@uplift.swm.pp.se>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
And more specifically, possibly an interface MTU (or ip mtu, I forget which=
).
If there is a mismatch between ends of a link, in one direction, MTU-sized =
packets get sent, and the other end sees those as "giants".
I've seen situations where the MTU is calculated incorrectly, when using so=
me technology that adds a few bytes (e.g. VLAN tags, MPLS tags, etc.).
On Cisco boxes, when talking to other Cisco boxes, even.
Take a look at the interfaces over which the peering session runs, at both =
ends.
I.e., is this the only BGP session *over that interface*, for the local box=
?
(It might not be the end you think it's at, BTW.)
Oh, and if you find something, please, let us know.
War stories make for great bar BOFs at NANOG meetings. :-)
Brian
-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20
Sent: September-14-09 2:39 PM
To: Michael Ruiz
Cc: nanog@nanog.org
Subject: Re: <Keepalives are temporarily in throttle due to closed TCP wind=
ow>
On Mon, 14 Sep 2009, Michael Ruiz wrote:
> I am having difficulty maintaining my BGP session from my 6509 with
> Sup-7203bxls to a 7206 VXR NPE-400. The session bounces every 3
> minutes. I do have other IBGP sessions that are established with no
> problems, however, this is the only IBGP peer that is bouncing
> regularly.
>
> What does exactly the message mean and how do I stabilize this? Any
> help will be appreciated.
This is most likely an MTU problem. Your SYN/SYN+ACK goes thru, but then=20
the first fullsize MSS packet is sent, and it's not getting to the=20
destination. 3 minutes is the dead timer for keepalives, which are not=20
getting thru either because of the stalled TCP session.
--=20
Mikael Abrahamsson email: swmike@swm.pp.se
