1400 and 1360 are safe values. Is Lab2 a GRE tunnel or DMVPN. Ignore the values in that lab for DMVPN. You would run into some fragmentation with the values provided. But the question only stated to get it working. Simply changing the MTU to 1400 would have solved the problem as well for the lab.
1492 is the size for a dialer when running PPPoE as the PPP encapsulation adds 8 bytes to the header. The Regards, Tyson Scott - CCIE #13513 R&S, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: <mailto:[email protected]> [email protected] Telephone: +1.810.326.1444, ext. 208 Live Assistance, Please visit: <http://www.ipexpert.com/chat> www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at <http://www.ipexpert.com/communities> www.ipexpert.com/communities and our public website at <http://www.ipexpert.com/> www.ipexpert.com From: [email protected] [mailto:[email protected]] On Behalf Of Jimmy Larsson Sent: Thursday, July 08, 2010 2:11 PM To: Kingsley Charles Cc: OSL Routing and Switching; [email protected] Subject: Re: [OSL | CCIE_RS] [OSL | CCIE_Security] DMVPN tunnel interface with mtu 1400 Yes, that explains most of it. But still I dont understand why it kills eigrp neighborships. It uses multicast, right? what is the default values? Are we lowering or raising them when adding those 2 commands with the values discussed above? And most of all; why isn´t it just fragmentet to be transported anyway? and of course, both mth and adjust tcp-mss are interface-commands. This is another question that imho should be crossposted in the r/s-list. I hope someone like Marko will beat my ass and explain it all. :-) I include my original question again since the discussion has been redistributed to another thread: ------------ Most often when we configure dmvpn we use eigrp. Configuration guides states setting ip mtu size as well as ip tcp adjust-mss. DocCD uses mtu 1400 and tcp adjust-mss 1360, but in an example from ipexpert (ILT Lab2) they (Well, Tyson I guess. ;) ) set mtu to 1492 and tcp mss to 1452. What is the reason for eigrp not running thru a default-"sized" GRE-tunnel and which are the preferred values? Default values? Within which ranges should we stay? ----------------- /J 2010/7/8 Kingsley Charles <[email protected]> Jimmy hope this mail thread would answer your query on DMVPN mtu size. Also I don't think, the mtu is configured for EIGRP rather for DMVPN tunnels. With regards Kings ---------- Forwarded message ---------- From: Piotr Matusiak <[email protected]> Date: Sat, May 22, 2010 at 2:57 AM Subject: Re: [OSL | CCIE_Security] DMVPN tunnel interface with mtu 1400 To: Kingsley Charles <[email protected]> Cc: [email protected] Hi Kings, I must disagree. You can configure Tunnel or Transport mode under the IPSec transform set and use it for DMVPN or GREoIPSec deployments. Although, there is no difference in outer IP header (an interface tunnel IP addresses are there in both cases) the ESP packet is different in size due to additional inner IP header in Tunnel mode. This IP header is the same as the outer IP header, thus there is not much value in such deployment. that's why the Transport mode is recommended in DMVPN (and GRE) scenarios. For example. When using Tunnel mode, the packet (regular ping for instance) will look like: ETHER=14 IP=20 ESP=36 GRE=24 IP=20 ICMP=8 + 72(payload) TOTAL=194 In case of the same packet in Transport mode: ETHER=14 IP=20 ESP=36 GRE=24 ICMP=8 + 72(payload) TOTAL=174 HTH, Piotr 2010/5/21 Kingsley Charles <[email protected]> Hi Piotr For GRE based IPSec like DMVPN or GREoIPSec, I don't think there is a concept of transport or tunnel mode. Irrespective of whether you configure transport or not, the IP packet format is same. Always there are three IP headers - ESP or AH IP header, GRE IP header and Payload IP header. Even when you configure tunnel mode, it has only the above three IP headers. It is always tunnel mode, meaning the original IP header is wrapped in GRE and then into ESP. With regards Kings On Fri, May 21, 2010 at 7:20 PM, Piotr Matusiak <[email protected]> wrote: Kings, It depends on many things like: - what IPSec encryption you use - do you use ESP alone or ESP with AH - transport or tunnel mode For example in ESP-3DES/ESP-MD5 with transport mode it should look like: ESP - 36 GRE - 24 IP - 20 Hence the router add 80 bytes to the packet. If you use IP MTU 1400 you're safe. When you use Tunnel mode you're adding 20 bytes for new IP header. TCP MSS is for changing TCP header to instruct the server (or host, whatever) to decrease the payload size. We configure 1360 to accommodate larger TCP header (by default 20 bytes, but can be larger due to TCP options like MD5 hash or something). HTH, Piotr 2010/5/21 Kingsley Charles <[email protected]> Hi all Usually we configure ip mtu 1400 for DMVPN tunnel interface and there is a standard calculation for it. I did it long time ago and trying to see, if I am having the right understanding now. Ethernet MTU - 1500 IPSec IP header - 20 bytes GRE IP header - 20 bytes Payload IP header - 20 bytes TCP header - 20 bytes Total of 80 bytes. 1500 - 80 = 1420 Including others like ESP header & trailer, GRE header etc, we round it to 1400. Hence, we add ip mtu of 1400 to DMVPN tunnel interface, to avoid fragmentation.in between. Correct me, if I am wrong. TCP MSS TCP MSS => IP MTU - TCP header size which is 1400 - 20 = 1380 bytes We usually configure "tcp adjust-mss 1360". Any idea why it is 1360 instead of 1380? With regards Kings _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com -- ------- Jimmy Larsson Ryavagen 173 s-26030 Vallakra Sweden http://blogg.kvistofta.nu -------
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
