Wasn't it supposed to be enabled by default for all BGP neighbors?
I think that's the point...
-----Mensagem original-----
De: [email protected]
[mailto:[email protected]] Em nome de Jared Mauch
Enviada em: quarta-feira, 11 de fevereiro de 2009 13:49
Para: Gergely Antal
Cc: Antonio M. Soares; [email protected]
Assunto: Re: [c-nsp] BGP MSS=576 bytes
You want to enable
'ip tcp path-mtu-discovery'
globally. This will allow it to scale outside the default 536,
and
if you are using jumbo mtu, may cause significantly reduced convergence
times since it takes fewer packets to send those bgp updates.
- Jared
On Wed, Feb 11, 2009 at 04:46:17PM +0100, Gergely Antal wrote:
> is "ip mtu 1500" set on the interfaces?
>
> Antonio M. Soares wrote:
> > Hello group,
> >
> > I have a 6500 running 122-18.SXF7 with lots of BGP peers and all of
the BGP sessions have negotiated a MSS of 536 bytes. Here's an
> > example:
> >
> > ++++++++++++++++++++++++++
> > 6500>sh ip bgp neighbors x.x.x.x
> >
> > ...
> >
> > Datagrams (max data segment is 536 bytes):
> >
> > Rcvd: 439340 (out of order: 252), with data: 406672, total data
bytes: 94316052
> >
> > Sent: 296303 (retransmit: 727), with data: 35046, total data bytes:
994215
> >
> > 6500>
> > ++++++++++++++++++++++++++
> >
> > The documentation says that PMTUD is enabled by default so this
should not be happening:
> >
> > ++++++++++++++++++++++++++
> > BGP Neighbor Session TCP PMTUD
> >
> > TCP path MTU discovery is enabled by default for all BGP neighbor
sessions, but there are situations when you may want to disable
> > TCP path MTU discovery for one or all BGP neighbor sessions. While
PMTUD works well for larger transmission links (for example,
> > Packet over Sonet links), a badly configured TCP implementation or a
firewall may slow or stop the TCP connections from forwarding
> > any packets. In this type of situation, you may need to disable TCP
path MTU discovery. In Cisco IOS Release 12.2(33)SRA,
> > 12.2(31)SB, 12.2(33)SXH, 12.4(20)T, Cisco IOS XE Release 2.1, and
later releases, configuration options were introduced to permit
> > TCP path MTU discovery to be disabled, or subsequently reenabled,
either for a single BGP neighbor session or for all BGP sessions.
> > To disable the TCP path MTU discovery globally for all BGP
neighbors, use the no bgp transport path-mtu-discovery command under
> > router configuration mode. To disable the TCP path MTU discovery for
a single neighbor, use the no neighbor transport
> > path-mtu-discovery command under router or address family
configuration modes.
> > ++++++++++++++++++++++++++
> >
> > I have for example a direct eBGP peering over TenGiga interfaces
where i see the same problem:
> >
> > ++++++++++++++++++++++++++
> > 6500>sh int tenGigabitEthernet x/x | inc MTU
> > MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
> > 6500>
> > 6500>
> > 6500>sh ip int tenGigabitEthernet x/x | inc MTU
> > MTU is 1500 bytes
> > 6500>
> > ++++++++++++++++++++++++++
> >
> >
> >
> > Any explanation to this strange behavior ?
> >
> >
> > Thanks.
> >
> > Regards,
> >
> > Antonio Soares, CCIE #18473 (R&S)
> > [email protected]
> >
> > _______________________________________________
> > cisco-nsp mailing list [email protected]
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Jared Mauch | pgp key available via finger from [email protected]
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
