TCP sessions normally use 536 if they are established between IPs which
are not directly connected. You may see the same on MSDP peerings.
Enabling Path MTU Discovery allows the actual end to end MSS to be
determined, provided the ICMP type 3 code 4 messages are not blocked
along the way.
Paul.
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)
amsoa...@netcabo.pt
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
