11-20-2007 08:12 AM - edited 03-03-2019 07:37 PM
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
Solved! Go to Solution.
11-20-2007 08:33 AM
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
11-20-2007 08:33 AM
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
11-20-2007 09:01 AM
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
11-20-2007 09:13 AM
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
11-20-2007 09:55 AM
IP MTU only affects IP packets while MTU affects non-IP packets (like routing protocols - OSPF comes to mind :)).
11-20-2007 09:47 AM
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
11-20-2007 01:44 PM
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
11-21-2007 01:28 AM
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
11-21-2007 07:02 AM
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
11-21-2007 07:55 AM
on the router:
ping [destination host] source [tunnel-loopback-if/ip] df-bit size 1500
11-21-2007 08:01 AM
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.
11-21-2007 08:12 AM
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. :-(
11-21-2007 11:38 AM
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)"
11-21-2007 12:21 PM
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
11-21-2007 05:50 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide