kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: michi1@michaelblizek.twilightparadox.com (michi1 at michaelblizek.twilightparadox.com)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Question on path mtu and IP fragmentation in Linux kernel 3.0
Date: Sun, 13 Jul 2014 09:48:52 +0200	[thread overview]
Message-ID: <20140713074851.GA4303@grml> (raw)
In-Reply-To: <CAP0SO-EGtbd0_53ihaLjTmJiiC30i-kCPbKE8G63bDqGesPRgQ@mail.gmail.com>

Hi!

On 01:47 Sun 13 Jul     , Sudharsan Vijayaraghavan wrote:
> Hi,
> 
> i find that even when /proc/sys/net/ipv4/ip_no_pmtu_disc is 0 (default
> value), that
> is path mtu is enabled, IP layer fragments the packets if it exceeds MTU
> 
> For example MTU is 1500, i do ping -s 15000 <ip addr>, IP layer nicely fragments
> the packets, how is that possible?

Path mtu discovery basically means that "fragmentation" is done on layer 4
(e.g. TCP) and not on layer 3 (IP). If it is enabled the "do not fragment" bit
in the IP header is set. If such a packet is about to be sent via a link with
a small MTU instead of being fragmented an "fragmentation needed" header is
sent back to the sender. The sender will then sent smaller packets. Generating
packets with the right size at the sender is supposed to be faster than
fragmenting them in the middle of a route.

Protocols like ICMP or UDP cannot do "fragmentation" themself. This is why
path mtu discovery does not have any effect on them.

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com

      reply	other threads:[~2014-07-13  7:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-12 20:17 Question on path mtu and IP fragmentation in Linux kernel 3.0 Sudharsan Vijayaraghavan
2014-07-13  7:48 ` michi1 at michaelblizek.twilightparadox.com [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140713074851.GA4303@grml \
    --to=michi1@michaelblizek.twilightparadox.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).