Networking Forums  

Go Back   Networking Forums > Networking Newsgroups > Linux Networking

PMTU discovery

Reply
 
Thread Tools Display Modes
  #1  
Old 05-15-2005, 07:48 AM
Default PMTU discovery



Hello,
I am checking ip_forward.c file and found there is no provision
for packet fragmentation. Is that corret?
I think its because in current world all pcs start to use PMTU
discovery right? There is only checking condition that whether
forwarding packet requires fragmentation if yes then send ICMP frag
needed packet.
Is there any probability that besided PMTU packet can be
fragmented or rejected?
regards,
cranium



cranium.2003@gmail.com
Reply With Quote
  #2  
Old 05-15-2005, 11:10 AM
Horst Knobloch
Guest
 
Posts: n/a
Default Re: PMTU discovery

(E-Mail Removed) <(E-Mail Removed)> wrote:

> I am checking ip_forward.c file and found there is no provision
> for packet fragmentation. Is that corret?


Depending on the kernel version you are looking to, yes.
However if it isn't in ip_forward then the IP fragmentation
is done in ip_output.c (at least in linux-2.6.11.8).


> I think its because in current world all pcs start to use PMTU
> discovery right?


No.

> There is only checking condition that whether
> forwarding packet requires fragmentation


and has the Don't-Fragment Flag set

> if yes then send ICMP frag
> needed packet.


HTH

Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn
Reply With Quote
  #3  
Old 05-15-2005, 01:55 PM
cranium.2003@gmail.com
Guest
 
Posts: n/a
Default Re: PMTU discovery

hello,
> Depending on the kernel version you are looking to, yes.
>However if it isn't in ip_forward then the IP fragmentation is

done in ip_output.c (at least in linux-2.6.11.8).

what is difference between kernel 2.4 and 2.6 with respect to ip
fragmentation as you said it is?
I am talking about linux routers not end hosts. In that case
once packet processed at ip layer its given to ip_forward.c and there
is condition to check MTU len and DF bit and depending on that packet
is given to ip_output.c or discarded.
Is there change in kernel 2.6.11.8 that id stops checking
condition so that packet directly appear in ip_output.c from
ip_forward.c? I am using kernel 2.4.24.

>> I think its because in current world all pcs start to use

PMTU
>> discovery right?


>No.

But i got reference at http://www.netheaven.com/pmtu.html
that says that pmtu used in 2002 in 80%

Reply With Quote
  #4  
Old 05-15-2005, 09:26 PM
Horst Knobloch
Guest
 
Posts: n/a
Default Re: PMTU discovery

(E-Mail Removed) <(E-Mail Removed)> wrote:

> > Depending on the kernel version you are looking to, yes.
> > However if it isn't in ip_forward then the IP fragmentation is
> > done in ip_output.c (at least in linux-2.6.11.8).

>
> what is difference between kernel 2.4 and 2.6 with respect to ip
> fragmentation as you said it is?


Looks like the kernel hackers have rearranged where the things
are done a little bit. In 2.4.24 fragmentation of forwarded
packets is done in ip_send() from include/net/ip.h which is
called by ip_forward_finish() from ip_forward.c.

The call chain is

ip_forward() -> ip_forward_finish() -> ip_send() ->
ip_fragmentation() -> ip_finish_output()


> I am talking about linux routers not end hosts. In that case
> once packet processed at ip layer its given to ip_forward.c and there
> is condition to check MTU len and DF bit and depending on that packet
> is given to ip_output.c or discarded.


See above.


....
>>> I think its because in current world all pcs start to use

> PMTU
>>> discovery right?

>
>>No.

> But i got reference at http://www.netheaven.com/pmtu.html
> that says that pmtu used in 2002 in 80%


And what about the remaining 20%? In addition some network
admins are plain dumb and have their firewall drop all
incoming ICMP traffic what breaks PMTUD quite well. So
sometimes you surrender and disable PMTUD if you have to
access these sites (or lower the MTU).

PMTUD is a good thing but you can't enforce it for IPv4
hosts so intermediate routers must still handle fragmentation.


Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn
Reply With Quote
  #5  
Old 05-16-2005, 09:57 AM
cranium.2003@gmail.com
Guest
 
Posts: n/a
Default Re: PMTU discovery


Horst Knobloch wrote:
> (E-Mail Removed) <(E-Mail Removed)> wrote:
>
> > > Depending on the kernel version you are looking to, yes.
> > > However if it isn't in ip_forward then the IP fragmentation is
> > > done in ip_output.c (at least in linux-2.6.11.8).

> >
> > what is difference between kernel 2.4 and 2.6 with respect to ip
> > fragmentation as you said it is?

>
> Looks like the kernel hackers have rearranged where the things
> are done a little bit. In 2.4.24 fragmentation of forwarded
> packets is done in ip_send() from include/net/ip.h which is
> called by ip_forward_finish() from ip_forward.c.
>
> The call chain is
>
> ip_forward() -> ip_forward_finish() -> ip_send() ->
> ip_fragmentation() -> ip_finish_output()
>
>
> > I am talking about linux routers not end hosts. In that case
> > once packet processed at ip layer its given to ip_forward.c and

there
> > is condition to check MTU len and DF bit and depending on that

packet
> > is given to ip_output.c or discarded.

>
> See above.
>

hello,
Can you please check ip_forward.c and there ip_forward() function
where condition is written as

if (skb->len > mtu && (ntohs(iph->frag_off) & IP_DF))
goto frag_needed;

What this indicates? Doesn't it throw away packet before it go to
ip_fragmentation? I agree that linux kernel packet forwarding code on
linux router does fragmentation by calling ip_fragment not in
ip_forward() but in ip_send().

Also in following function skb->dst->pmtu is pmtu of next hop in packet
forwarding PATH right?
static inline int ip_send(struct sk_buff *skb)
{
if (skb->len > skb->dst->pmtu)
return ip_fragment(skb, ip_finish_output);
else
return ip_finish_output(skb);
}

> ...
> >>> I think its because in current world all pcs start to use

> > PMTU
> >>> discovery right?

> >
> >>No.

> > But i got reference at http://www.netheaven.com/pmtu.html
> > that says that pmtu used in 2002 in 80%

>
> And what about the remaining 20%? In addition some network
> admins are plain dumb and have their firewall drop all
> incoming ICMP traffic what breaks PMTUD quite well. So
> sometimes you surrender and disable PMTUD if you have to
> access these sites (or lower the MTU).
>
> PMTUD is a good thing but you can't enforce it for IPv4
> hosts so intermediate routers must still handle fragmentation.


So that mean If suppose PMTU is implemented with ICMP enable then is
there still any possibility of packet fragmenta
tion?(Just a thought)
So at any Router in a internet packet path if PMTU not used
then router code always have pmtu values of next hop touter. Is that
correct?

>
> Ciao, Horst
> --
> »When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn


Reply With Quote
  #6  
Old 05-16-2005, 04:39 PM
Horst Knobloch
Guest
 
Posts: n/a
Default Re: PMTU discovery

(E-Mail Removed) <(E-Mail Removed)> wrote:

> Horst Knobloch wrote:
>> (E-Mail Removed) <(E-Mail Removed)> wrote:
>>

[Where is fragmentation done?]
>> The call chain is
>>
>> ip_forward() -> ip_forward_finish() -> ip_send() ->
>> ip_fragmentation() -> ip_finish_output()
>>

....
> Can you please check ip_forward.c and there ip_forward() function
> where condition is written as
>
> if (skb->len > mtu && (ntohs(iph->frag_off) & IP_DF))
> goto frag_needed;
>
> What this indicates? Doesn't it throw away packet before it go to
> ip_fragmentation?


Yes, but only the packets which are not allowed to be
fragmented (DF flag set). The IP packets which have the
DF flag *not* set are allowed to be fragmented and for
those packets the condition holds not true. Thus the
packet is fragmented later if it is bigger than the MTU
of the outgoing interface.

For packets with the DF flag set, the IP stack is not
allowed to fragment and therefore it sends back the ICMP
error indicating that the packet couldn't be delivered
because it was bigger than the MTU. To support the PMTUD
done by the end hosts it returns the allowed MTU in the
ICMP error. So the end host can send smaller packets at
the next try.


> I agree that linux kernel packet forwarding code on
> linux router does fragmentation by calling ip_fragment not in
> ip_forward() but in ip_send().


Ah, at least. ;-)

> Also in following function skb->dst->pmtu is pmtu of next hop in packet
> forwarding PATH right?


Yes. However even if the variable is named pmtu, what
implies path mtu, it contains the mtu of the outgoing
interface in *this* circumstance.


> static inline int ip_send(struct sk_buff *skb)
> {
> if (skb->len > skb->dst->pmtu)
> return ip_fragment(skb, ip_finish_output);
> else
> return ip_finish_output(skb);
> }


....
> So that mean If suppose PMTU is implemented with ICMP enable then is
> there still any possibility of packet fragmenta
> tion?(Just a thought)


If PMTUD is performed by the end host, it sets the DF flag
on the packets it sends and it is not allowed to fragment
those packets along the path. This means whether packets
can be fragmented or not is controlled by the hosts and
not by intermediate routers.


> So at any Router in a internet packet path if PMTU not used
> then router code always have pmtu values of next hop touter. Is that
> correct?


Hm, I'm not sure whether I understand your question.
PMTUD is done by the end hosts not the routers[1]. The
routers along the path must just send back ICMP errors
with the next hop's MTU value to support PMTUD.
The next hop's MTU is known by the router because it
is the configured MTU size of the interface to which the
next hop router is connected to.


HTH

Ciao, Horst


1) Of course a router can also be a host in certain cases,
e.g. if you telnet to it.

--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn
Reply With Quote
Reply

Tags
discovery, pmtu

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 07:55 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.