cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12835
Views
9
Helpful
15
Replies

MTU size on tunnel interface

bauer.juergen
Level 1
Level 1

hi netpros,

we are running a few GRE tunnels - so far without any problems.

now we have the first issue with large packets getting dropped. we changed the mtu size on the tunnel interface:

interface Tunnel41

ip address 192.168.a.b 255.255.255.252

ip mtu 1300

tunnel source Loopback2

tunnel destination 192.168.x.y

but a sh int t41 shows mtu size of 1514!?

Tunnel41 is up, line protocol is up

Hardware is Tunnel

Internet address is 192.168.a.b/30

MTU 1514 bytes

...

...

...

Is this just a display error or is it no error at all?

any help appreciated :-)

thanks and best regards,

juergen

1 Accepted Solution

Accepted Solutions

Edison Ortiz
Hall of Fame
Hall of Fame

You applied the 'ip mtu' not the hardware MTU.

The hardware MTU is done with the MTU command under the tunnel. However, this MTU is not adjustable.

Rack1R2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Rack1R2(config)#int tun 41

Rack1R2(config-if)#mtu 1300

% Interface Tunnel41 does not support adjustable maximum datagram size

____________

To find the 'ip mtu' value, the command is show ip interface tunnel 41

Tunnel41 is up, line protocol is up

Internet address is 192.168.1.1/30

Broadcast address is 255.255.255.255

Address determined by setup command

MTU is 1300 bytes

View solution in original post

15 Replies 15

Edison Ortiz
Hall of Fame
Hall of Fame

You applied the 'ip mtu' not the hardware MTU.

The hardware MTU is done with the MTU command under the tunnel. However, this MTU is not adjustable.

Rack1R2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Rack1R2(config)#int tun 41

Rack1R2(config-if)#mtu 1300

% Interface Tunnel41 does not support adjustable maximum datagram size

____________

To find the 'ip mtu' value, the command is show ip interface tunnel 41

Tunnel41 is up, line protocol is up

Internet address is 192.168.1.1/30

Broadcast address is 255.255.255.255

Address determined by setup command

MTU is 1300 bytes

Hi,

Could you explain a bit about the subtle difference between IP MTU and just MTU ? MTU subsumes the IP Header and the Frame Header, I presume. IP MTU is just the IP Packet plus the IP Header value ?

Thank you

Arav

yeah, would be nice. it was new to me that a kind if "non-physical" or virtual interface like a tunnel interface has a "hardware" mtu.

regards,

juergen

IP MTU only affects IP packets while MTU affects non-IP packets (like routing protocols - OSPF comes to mind :)).

Hi Juergen

ALL traffic that goes through a generic routing encapsulation (GRE) tunnel, must have

MTU size as 1436

i e,

MTU minus the size of the IP, TCP, and GRE headers

GRE tunnel supports maximum segment size as 1436 bytes

so how it is calculated

20 bytes as IP header

20 bytes as tcp header

24 bytes used for GRE encapsulation

so out of 1500 bytes ,maximum segment size has to be adjusted to 1436 (1500 -20-20-24 ) bytes becoz above this will packets will be dropped

we too faced similar problem in our network while implementing GRE tunnels over MPLS network

use command ip tcp adjust-mss 1436 on tunnel interface

i e

interface Tunnel41

ip address 192.168.a.b 255.255.255.252

ip tcp adjust-mss 1436 -->( This command is used to adjust the maximum segment size (MSS)

)

tunnel source Loopback2

tunnel destination 192.168.x.y

It also depends on teh device.

For example, on a L3 switch (like a 3550), you can do a "system mtu 1546" and default the MTU of the switch to > 1500, even for Fast Ethernet.

This allows you to run full-sized frames through a GRE tunnel.

I think it'll show the physical interface MTUs as 1546, and logical interfaces (lo0 or tunnels) will show MTU of 1514, but that is not including another 18 bytes (I think) of header space.

FWIW

Scott

Ok, now that the discussion started I will explain our topology and what I have learned so far :-)

We use the GRE tunnel on an internal router to encapsulate traffic to a remote branch which is connected via IPSec VPN (IPSec encryption is done on the internet firewall, not the router which builds the GRE tunnel).

So we have even more overhead:

24 bytes for GRE

56 bytes for ESP traffic in tunnel mode

What was new to me is the following (1):

"Remember that without the tunnel path-mtu-discovery command configured, the DF bit would always be cleared in the GRE IP header. This allows the GRE IP packet to be fragmented even though the encapsulated data IP header had the DF bit set, which normally wouldn't allow the packet to be fragmented."

We don't use pmtud on the tunnel and it works, we get full 1500 bytes through the GRE->IPSec tunnel (without mss ajustment) -- except for one branch. We don't know the MTU size on that internet connection and it's difficult to communicate with that provider.

Any comments appreciated.

Regards,

Jürgen

(1) http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml#more

You can test if you are indeed sending 1500 bytes without fragmentation by using the ping command.

At a windows machine:

ping [destination host] -f -l 1500

on the router:

ping [destination host] source [tunnel-loopback-if/ip] df-bit size 1500

A true test would be from a workstation sitting behind the router. This way, you can see if ICMP is doing its thing. ICMP will inform the workstation to reduce its MTU size and perhaps that's the reason you don't see fragmentation.

yes, but only if you have pmtud enabled on the tunnel interface - which is not the case at the moment. and I can not play around with that router at the moment. :-(

So, if it only works when pmtud is enabled then you are fragmenting the packets -or- I don't understand your previous reply.

You said:

"We don't use pmtud on the tunnel and it works, we get full 1500 bytes through the GRE->IPSec tunnel (without mss ajustment)"

confused ?-)

I never captured packets but - yes - I think it works like this - even though the df-bit is set in the original packet the GRE packet clears it and gets fragmented over the ipsec tunnel. So we get 1500 bytes through the tunnel.

Best regards,

Juergen

GRE won't clear a df-bit, you need a route-map for that task.

The ping approach from a device sitting behind the router is the best method for testing fragmentation issues.

If you send a packet with a size 1500 with df-bit set, you will receive the following:

ping www.cisco.com -l 1500 -f

Pinging www.cisco.com [198.133.219.25] with 1500 bytes of data:

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: