tunnel IP mtu

[milan.kulik]

Hello,

I can see on my router:

router1#sh ip int fa 0/1
FastEthernet0/1 is up, line protocol is up
Internet address is 10.123.0.66/26
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes

router1#sh int fa 0/1
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is 0017.e096.0d21 (bia 0017.e096.0d21)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255

When I configure a GRE tunnel, I can see:

router1#sh ip int tunnel 100
Tunnel100 is up, line protocol is up
Internet address is 10.10.10.11/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes

It makes a sense, as GRE overhead is 24 Bytes.

But why do I see:

router1#sh int tunnel 100
Tunnel100 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.10.10.11/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec

??

More:

router1(config-if)#ip mtu 1500
%Warning: MTU set 1500 is greater than default 1476, fragments will happen

router1#sh ip int tunn 100
Tunnel100 is up, line protocol is up
Internet address is 10.10.10.11/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes

But still:

router1#sh  int tunn 100
Tunnel100 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.10.10.11/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

I'm able to Ping the other end of the tunnel with 1500-Byte Ping packets now:

router1#ping 10.10.10.10 df-bit size 1500

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
router1#

Which means the packets have to be fragmented even while D-F bit is set!

Does anybody know what happens with the fragmented packets on the other side of the tunnel?

Are they being reassembled? Or is "ip virtual-reassembly" necessary to configure?

What happens with the D-F bit in the packet header?

I know I could build a lab and capture the packets.

But possibly somebody knows the answer or has found any Cisco document describing details?

Thanks,

Milan

[Eehab Suliman]

You are correct.

On this device mtu size on gre tunnel is set as 1514 bytes. This may be influenced by bug CSCsi95211

[sandeep1983]

The MTU size that you see as output of command "sh ip int tunnell 100" is the IP MTU, which is the size of max possible IP packet. However the output of command "sh int tunnel 100" shows the size of interface MTU, which is the size of max possible frame on the interface. This is the reason that even though you change the IP MTU size by giving command "ip mtu 1500" the size of interface MTU doesn't change; and you get error message because the size you have set is not the recommended size for IP MTU.

[milan.kulik]

Hi,

yes, I'd also expect "sh int tunnel 100" to show the size of max possible frame on the interface.

But where does the value 1514 come from?

When the FastEtherent interface is showing 1500 only?

Thanks,

Milan

[milan.kulik]

I built a lab and realised:

When I use

ip mtu 1500

the large packest fragmented due to the tunnel MTU are reassembled on the other tunnel side!

Even without "ip virtual-reassembly" used.

So it's good to know,  I can run PMTUD without any problem through the tunnel.

I still don't understand where does the   MTU 1514 bytes value come from in

router1#sh  int tunn 100
output, but it's a minor issue, it's possible caused by the bug mentioned below.

BR,

Milan

[thiland]

14 bytes is the size of the 802.3 ethernet header (source MAC, dest MAC, type/length) without 802.1Q tagging.  802.1Q would add another 4 bytes.

1500b is the standard L3 IP MTU

1514b is the L2 header + L3 IP MTU

1518b is the L2 header + 802.1Q header + L3 IP MTU