[c-nsp] tag-switching mtu question

Gert Doering gert at greenie.muc.de
Mon Jun 26 07:45:30 EDT 2006


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


More information about the cisco-nsp mailing list