netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "R.Mielnik" <r.mielnik@rm-it.pl>
To: netdev@vger.kernel.org
Subject: linux kernel and route mtu calculation
Date: Wed, 30 Dec 2015 14:00:26 +0100	[thread overview]
Message-ID: <5683D56A.2030601@rm-it.pl> (raw)


debian, kernel 3.2.54/60/73. i'm using gre interfaces on top of ipsec 
tunnels. these gre interfaces have mtu 1400 on my entire network. 
normally i see this kind of tracepath output:

1?: [LOCALHOST]                                         pmtu 1500
  1:  10.xxx.101.1                                         13.625ms
  1:  10.xxx.101.1                                         13.178ms
  2:  10.xxx.101.1                                         13.973ms pmtu 
1400
  2:  192.168.yyy.251                                      56.555ms
  3:  192.168.yyy.92                                      643.252ms
  4:  192.168.yyy.28                                      417.291ms
  5:  192.168.zzz.129                                     517.893ms reached

but for some reason i got one case when tracepath gives different result:

  1?: [LOCALHOST]                                         pmtu 1500
  1:  10.xxx.101.1                                         13.625ms
  1:  10.xxx.101.1                                         20.857ms
  2:  10.xxx.101.1                                         11.954ms pmtu 
1400
  2:  192.168.yyy.251                                      46.456ms
  3:  192.168.yyy.251                                      45.563ms pmtu 
1376
  3:  10.zzz.251.1                                         56.648ms
  4:  10.zzz.255.111                                       55.212ms reached

all gre interfaces on 192.168.yyy.251 have mtu 1400, all are configured 
identically. the 10.zzz.251.1 router doesn't send any ICMP fragm needed 
packets, gre interface of course with mtu 1400. 192.168.yyy.251 
generates ICMP fragm needed but i have no clue why. ip route get 
10.zzz.255.111 on 192.168.yyy.251 router shows:

10.zzz.255.111 from 10.xxx.101.253 tos lowdelay via 10.zzz.251.1 dev 
GRE_OUTPUT_INTERFACE  src 192.168.yyy.251  mark 0x2071
     cache  expires 264sec ipid 0x607b mtu 1376 iif GRE_INPUT_INTERFACE

additionally from time to time (i suspect it depends on traffic) mtu of 
the route changes and gets heavily lowered and for 10mins (mtu cache 
expiry) i can't make any new connections that need bigger packets -- but 
old established connections are working fine. so how the kernel 
calculates mtu for routes? what else except mtu of outgoing interface is 
taking its part in pmtu calculation?




-- 
  ...  Rafał Mielnik
  ...  RM-IT Usługi Informatyczne
  ...  +48608025394
  ...  r.mielnik@rm-it.pl

                 reply	other threads:[~2015-12-30 13:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=5683D56A.2030601@rm-it.pl \
    --to=r.mielnik@rm-it.pl \
    --cc=netdev@vger.kernel.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).