[c-nsp] tag-switching mtu question

[Joost greene]

Let me try to summarize.

Basicly there were TCP MSS, IP MTU and Phsyical MTU and later on MPLS MTU

TCP MSS will be used only by the TCP hosts(end-to-end), but can be
configured for re-write.

IP MTU can be configured on an Interface and it will set the size of the IP
packet before it reaches the interfaces buffers

Physical is the last stage, if the IP is set to something less than
physical, frame will be caped at layer 2 ?

MPLS MTU is because most of interface MTUs are 1500 and you need more so you
force it to receive more to be able to put the 1500 bytes packet into an
MPLS packet.

Thanks alot

On 6/26/06, Gert Doering <gert at greenie.muc.de> wrote:
>
> Hi,
>
> On Mon, Jun 26, 2006 at 01:40:25PM +0300, Joost greene wrote:
> > Is anyone willing to explain to me the diff. between IP MTU, physical
> MTU,
> > MPLS MTU and MSS, i am confused.
>
> OK, I'll give it a try.
>
> All of this is "as it works inside Cisco", as this is nothing a standard
> would define, but how a multiprotocol router would handle things.
>
> "mtu" is what the "default" MTU for *all* sorts of packets going in and
> out, and (unless configured differently) is inherited for IP, IPv6, MPSL,
> etc.
>
> "IP MTU" is the maximum size of an IP packet sent out of that interface.
>
> The distinction is relevant, because one could want larger packet sizes
> for MPLS (to be able to transport full-sized IP frames *inside* the MPLS
> packet), but only standard-sized IP packets (because there is something
> else in the same IP subnet that cannot handle larger IP packets).
>
> "MPLS MTU" -> maximum size for MPLS packets.
>
>
> In an ideal world, one could configure all of these MTUs independently,
> and the driver would program the chipset to the "largest MTU expected".
>
> In IOS, that's what happens (I think) if you set "MTU <nnn>".
>
> *Some* IOS trains had some confusion about usefulness of larger MTUs
> (or whatever), and forbid setting "mtu 1530" on an FastE interface - but
> for MPLS, you *need* more, so "mpls mtu 1530" was allowed (larger MPLS
> MTU than Interface MTU).  Which doesn't make too much sense, so it was
> changed again for 12.2SB, as far as I understand - so you can now
> configure
> larger "mtu" values again, and all protocols will inherit that value
> (but can manually be configured for smaller values).
>
>
> Now, TCP MSS is related to IP MTU, but not directly so.  If you have
> a network with links with different MTU, the sender usually cannot know
> this, and will send full-sized (1500 byte) packets.  The first router
> that wants to send this packet over a lower-MTU link needs to fragment
> it (expensive), or send back an "ICMP fragmentation required" packet
> (if the sender has set the DF, don't fragment, bit) - so the sender
> can reduce his packet size.
>
> In the time of broken load balancers, or broken firewall admins that
> filter out all ICMP packets (ICMP IS EVIL!!!), the sending host might
> never hear the ICMP "fragmentation required" packet, and thus will re-send
> his 1500 byte packet again and again, which has no chance to ever reach
> the receiver (path mtu discovery -> blackholing).
>
>
> TCP has a mechanism by which the receiver can advertise how large a TCP
> packet ("TCP segment", actually) he can handle - the TCP MSS value in the
> TCP header.  So if the receiver knows that the MTU needs to be smaller,
> he can advertise a smaller TCP MSS size, and thus make the sender send
> out smaller TCP packets.
>
> Inside IOS (and other routers), there is a hack, where you can make the
> router change the TCP MSS for packets going *through* the router.  So if
> you know that your DSL customers (for example) have issues with PMTU
> discovery, you can just configure your router to re-write your customer's
> TCP MSS's, and thus work around MTU/fragmentation problems.
>
>
> All of this sucks big time :-)
>
> (... and I'm sure that some part of the information above will be
> incomplete,
> incorrect, or just plain confusing.  Please correct the obvious, there's
> just not enough time to research all of this in even deeper detail now).
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
>