Skip to contentSkip to conversation

New: gretap does not fragment IP packets

Bugme-new Andrew Morton 5 participants 9 messages Dec 18, 2009 – Jan 10, 2010 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author
#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 33 lines · On Fri, 18 Dec 2009 23:10:01 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=14837

           Summary: gretap does not fragment IP packets
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.32
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: No

When gretap is used to encapsulate Ethernet packets into IP packets, the encapsulated IP packets are larger than the original Ethernet packet, as expected.

Let's say you create a gre0 interface with a 1500 bytes MTU (since this interface will latter be inserted in a bridge interface, its MTU must be 1500). And Let's say the GRE encapsulated packet (now larger than 1500 bytes) is going to be routed over an IP interface with a 1500 bytes MTU.

The expected behavior would be that the encapsulated packet be fragmented. The observed behavior is that any encapsulated packets over 1500 bytes are simply dropped and an ICMP "fragmentation needed" message is sent to ... who knows.

My feeling is that DF bit is not playing nice here.

#2 lore raw
Quoted 7 lines · On Fri, 18 Dec 2009 15:32:09 -0800 Andrew Morton <[email protected]>…
Quoted 7 lines

The expected behavior would be that the encapsulated packet be fragmented. The observed behavior is that any encapsulated packets over 1500 bytes are simply dropped and an ICMP "fragmentation needed" message is sent to ... who knows.

My feeling is that DF bit is not playing nice here.

TCP uses DF bit to do path mtu discovery. If your firewall et all, doesn't do ICMP correctly, then this is the classic TCP path MTU discovery ICMP blackhole problem.

http://www.ietf.org/rfc/rfc2923.txt

#3 lore raw
In reply to Andrew Morton
Quoted 36 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 30 lines · On Fri, 18 Dec 2009 23:10:01 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=14837

           Summary: gretap does not fragment IP packets
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.32
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: No

When gretap is used to encapsulate Ethernet packets into IP packets, the encapsulated IP packets are larger than the original Ethernet packet, as expected.

Let's say you create a gre0 interface with a 1500 bytes MTU (since this interface will latter be inserted in a bridge interface, its MTU must be 1500). And Let's say the GRE encapsulated packet (now larger than 1500 bytes) is going to be routed over an IP interface with a 1500 bytes MTU.

The expected behavior would be that the encapsulated packet be fragmented. The observed behavior is that any encapsulated packets over 1500 bytes are simply dropped and an ICMP "fragmentation needed" message is sent to ... who knows.

Sending back an ICMP is good behavior. Sending it "who knows" is not ;-> Make sure it is sent to the originator of the packet. The originator of the packet should play nice and reduce the path mtu.

One work around is to reduce the gre device mtu to something less than 1500B.

cheers,
jamal

#4 lore raw
Quoted 4 lines · jamal

Sending back an ICMP is good behavior. Sending it "who knows" is not ;-> Make sure it is sent to the originator of the packet. The originator of the packet should play nice and reduce the path mtu.

Quoted 8 lines

One work around is to reduce the gre device mtu to something less than 1500B.

cheers,
jamal

As I explained in my original message, the gre device MTU must be 1500 bytes (since it is used in an Ethernet bridge). To reproduce the problem, I did a very simple setup with two machines (A & B) connected with an Ethernet cable (so no router between them).

On machine A :

# ip link add gre0 type gretap local <A> remote <B>
# ifconfig gre0 mtu 1500
# ifconfig gre0 192.192.192.1 up

On machine B:

# ip link add gre0 type gretap local <B> remote <A>
# ifconfig gre0 mtu 1500
# ifconfig gre0 192.192.192.2 up

On machine A:

# ping 192.192.192.2 => working
# ping -s 1434 192.192.192.2 => working, match a GRE packet of 1500 bytes
# ping -s 1435 192.192.192.2 => not working, match a GRE packet of 1501 bytes (1435+8+20+38)
# ping -s 1472 192.192.192.2 => not working, match an IP packet of 1500 bytes

Doing a tcpdump on the machine (like tcpdump -pni any) shows that ICMP packets are simply dropped!

Using tracepath 192.192.192.2, a tcpdump -pni lo shows :
IP 192.192.192.1 > 192.192.192.1: ICMP 192.192.192.2 unreachable - need to frag (mtu 1500), length 556

Regards,
Benoit

#5 lore raw
Quoted 3 lines · Benoit PAPILLAULT
Quoted 1 line

As I explained in my original message, the gre device MTU must be 1500 bytes (since it is used in an Ethernet bridge).

Ok, sorry i missed this bit. I didnt realize that the bridge device had such draconian enforcement. Bridge picks whatever the lowest common denominator is for MTU (I suspect so as to not keep track of all the interfaces; good policy, IMO, should allow a user to shoot themselves in the toe while defaulting to the min mtu).

Quoted 1 line

From the looks of it, this enforcement could be changed with a one line

patch - but not being privy to the reasoning it would be unfair of me to do so from my comfortable couch. Stephen?

Quoted 7 lines

To reproduce the
problem, I did a very simple setup with two machines (A & B) connected with an Ethernet cable (so no router between them).

On machine A :

# ip link add gre0 type gretap local <A> remote <B>
# ifconfig gre0 mtu 1500

What i meant is try to ifconfig gre0 to something small like 1420B

cheers,
jamal

#6 lore raw

First of all, my best wishes for year 2010!

Any comments on the patch I sent? Should I send it on a mailing list for a broader audience?

Regards,
Benoit

#7 lore raw

Salut Benoit,

I didnt see any patch...

Also did you try changing the mtu per suggestion i made? People tend to be busy and sometimes dont read the mailing list. To get proper answers, always CC the maintainers. In this case CC Stephen Hemminger - he maintains the bridging code. I am ccing Herbert Xu as well - he may have opinions on the gre side of things. My suggestion is you repost your issue along with your patch and describe why it solves your problem.

cheers,
jamal

Quoted 12 lines · Benoit PAPILLAULT

First of all, my best wishes for year 2010!

Any comments on the patch I sent? Should I send it on a mailing list for a broader audience?

Regards,
Benoit

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw

Hello Jamal,

Quoted 6 lines · jamal

Salut Benoit,

I didnt see any patch...

Also did you try changing the mtu per suggestion i made?

I cannot changed the MTU by design since I need to have the gretap interface be part of an Ethernet bridge.

Quoted 7 lines

People tend to be busy and sometimes dont read the mailing list. To get proper answers, always CC the maintainers. In this case CC Stephen Hemminger - he maintains the bridging code. I am ccing Herbert Xu as well - he may have opinions on the gre side of things. My suggestion is you repost your issue along with your patch and describe why it solves your problem.

I know people can be busy, I am just trying to push things forward. Original bug is there :
http://bugzilla.kernel.org/show_bug.cgi?id=14837

Patch is available here :
http://bugzilla.kernel.org/attachment.cgi?id=24332

This patch fixes my issue since either packets get fragmented or an ICMP error packet is sent back to the sender.

Regards,
Benoit
PS: Congrats to Herbert Xu which fixes a bug in gretap before I had the time to report it (was about the broadcast addr which was incorrect).

Quoted 4 lines

cheers,
jamal

#9 lore raw
Quoted 10 lines · Benoit PAPILLAULT

I know people can be busy, I am just trying to push things forward. Original bug is there :
http://bugzilla.kernel.org/show_bug.cgi?id=14837

Patch is available here :
http://bugzilla.kernel.org/attachment.cgi?id=24332

This patch fixes my issue since either packets get fragmented or an ICMP error packet is sent back to the sender.

I was actually working on this back in November before getting side-tracked by travelling.

I'll look into this again.

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt