[117499] in North American Network Operators' Group
Re:
daemon@ATHENA.MIT.EDU (Richard A Steenbergen)
Tue Sep 15 16:34:00 2009
Date: Tue, 15 Sep 2009 15:31:19 -0500
From: Richard A Steenbergen <ras@e-gerbil.net>
To: Michael Ruiz <mruiz@telwestservices.com>
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0444F03C@tw-xchange01.TWC.local>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Tue, Sep 15, 2009 at 03:10:52PM -0500, Michael Ruiz wrote:
> Below is snap shot of the neighbor in question.
>
> Datagrams (max data segment is 4410 bytes):
> Rcvd: 6 (out of order: 0), with data: 4, total data bytes: 278
> Sent: 6 (retransmit: 5), with data: 2, total data bytes: 4474
>
> Could there be a problem with the total data bytes size exceeds the size
> of the max data segment?
The maximum BGP message size is 4096 and there is no padding, so you
would need a heck of a lot of overhead to get another 300+ bytes on
there. I'd say the answer is no, unless you're running this over a MPLS
over GRE over MPLS over IPSec over MPLS over... well... you get the
picture. :)
It's possible that your link isn't actually capable of passing 4096-ish
byte packets for whatever resaon. A quick way to validate or eliminate
that theory is to do some pings from the router with different size
payloads, sourced from your side of the /30 and pinging the far side,
and using the df-bit to prevent fragmentation. Failing that, make sure
you aren't doing anything stupid with your control plane policiers,
maybe try turning those off to see if there is an improvement.
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
