MTU 1500

Folks,
I keep reading in this forum that in an MPLS network if the MTU is 1500 bytes (default), a lot of packets would get dropped as the labels added to the original packet make it bigger than 1500 bytes(4 bytes per lable).
So i did a test today, I built a small network of three routers. I connected one of the routers to the internet and connected my laptop of the 3rd router on the far end. Had the router connected to the internet advertise a default route in a vrf to the router on the far end. I made sure that my traffic was being tag switched inside the core before going to the internet.
All interfaces inside my core had only 1500 mtu set.
to my surprise, i was able to go to yahoo, msn, hotmail, cnn and many other sites without any problem.
Does anyone know of a site that marks the packet as df=1 so that it is not fragmented inside the core?
I used the extended ping test with mtu of 1504 and df=1 and it failed as suspected.
does anyone know of an other application I can use to prove that mtu of 1500 would not work in an MPLS network rather than using a ping?
How will i know that packets were dropped because the mtu was more than the interface that support?
Thanks,

Parwal,
Since your packets were label switched inside your small core, DF value has no significance, since IP headers were not visible to LSRs. Obviously in this environment PMTUD is not relevant because of the same reason.
When accessing web sites, you usually get the data in spikes and not in constant stream as for example with file transfers (FTP). With these spikes TCP never reaches full speed, so IP packet size stays below 1500bytes.
Try to do an FTP file transfer through your network and you will see it "hang" very quickly. This is an indication that you're running into MTU issues, which you will :-)
David

Similar Messages

NSX Lab on Workstation 11 - Nested ESX crashes with unrecoverable error when trying to test VTEP connectivity with MTU 1500

I'm trying to install and configure NSX 6.1.2 / ESX 5.5 in a nested environment using VMware Workstation lastest bits "VMware-workstation-full-11.1.0-2496824"
I've configured the MTU on the virtual adapter (VMNet1) used by the VXLAN transport network to 9000 bytes.
C:\Users\admin>netsh int ipv4 show int
Idx     Met         MTU          State                Name
1          50 4294967295 connected     Loopback Pseudo-Interface 1
19          25        1500 connected     Wireless Network Connection 4
16          40        1500 disconnected Bluetooth Network Connection
11           5        1500 disconnected Local Area Connection
20           5        1500 disconnected Wireless Network Connection 5
18           5        1400 disconnected Local Area Connection* 11
31          20        9000 connected     VMware Network Adapter VMnet1
when I test VTEP connectivity between ESXi nested host with MTU > 1500, using the following command,
ping ++netstack=vxlan -d -s 1572 -I vmk2 192.168.192.102
the ESXi crashes with the following error
2015-05-21T11:20:47.180+02:00| vcpu-1| I120: Coredump encountered overflow 10218:10218 (2172 duplicates)
2015-05-21T11:20:48.969+02:00| vcpu-1| I120: Backtrace:
2015-05-21T11:20:48.970+02:00| vcpu-1| I120: backtrace[00] frame 0x0881eb38 IP 0x13f0820de params 0 0xa6 0x64e 0x312d75706376 ??? [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x000310de]
2015-05-21T11:20:48.971+02:00| vcpu-1| I120: backtrace[01] frame 0x0881f460 IP 0x13f068129 params 0x13f78dc30 0x13f890928 0x2ce 0x3fff ??? [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x00017129]
2015-05-21T11:20:48.971+02:00| vcpu-1| I120: backtrace[02] frame 0x0881f8b0 IP 0x13f4498bc params 0x13fb8e840 0x3a63ec0 0x13f050000 0x13fb8e840 opus_decoder_destroy + 0x1dec0c [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x003f88bc]
2015-05-21T11:20:48.972+02:00| vcpu-1| I120: backtrace[03] frame 0x0881f8e0 IP 0x13f6809a2 params 0x161 0x35a59e0 0 0xa36333237 opus_repacketizer_get_nb_frames + 0x163fc2 [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x0062f9a2]
2015-05-21T11:20:48.972+02:00| vcpu-1| I120: backtrace[04] frame 0x0881f920 IP 0x13f6b8229 params 0x258 0 0 0 opus_repacketizer_get_nb_frames + 0x19b849 [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x00667229]
2015-05-21T11:20:48.973+02:00| vcpu-1| I120: backtrace[05] frame 0x0881faa0 IP 0x13f680d3c params 0x13f809d60 0x13f7c7374 0x5 0x13fd65da0 opus_repacketizer_get_nb_frames + 0x16435c [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x0062fd3c]
2015-05-21T11:20:48.973+02:00| vcpu-1| I120: backtrace[06] frame 0x0881fb00 IP 0x13f20c736 params 0 0 0 0 ??? [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x001bb736]
2015-05-21T11:20:48.976+02:00| vcpu-1| I120: backtrace[07] frame 0x0881fb08 IP 0x76ee59cd params 0 0 0 0 BaseThreadInitThunk + 0x000d [C:\Windows\system32\kernel32.dll base 0x76ed0000 0x0001:0x000149cd]
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: backtrace[08] frame 0x0881fb38 IP 0x7701b891 params 0 0 0 0 RtlUserThreadStart + 0x0021 [C:\Windows\SYSTEM32\ntdll.dll base 0x76ff0000 0x0001:0x0002a891]
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: Msg_Post: Error
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.log.error.unrecoverable] VMware Workstation unrecoverable error: (vcpu-1)
2015-05-21T11:20:48.980+02:00| vcpu-1| I120+ VERIFY d:/build/ob/bora-2496824/bora/devices/vmxnet3/vmxnet3_hosted.c:718
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "X:\vCACupdate\Capricornus\vmware.log".
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.windowsOrLinux]
2015-05-21T11:20:48.980+02:00| vcpu-1| I120+ To collect data to submit to VMware support, choose "Collect Support Data" from the Help menu.
2015-05-21T11:20:48.980+02:00| vcpu-1| I120+ You can also run the "vm-support" script in the Workstation folder directly.
2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.
Any help is appreciated.

One detail:
I use Vcloud from my work, so I changed iPv4 addresses of machines. For example, DC1 192.168.2.101,
Internet names are 192.169.2.101 and so on.
I mean it is fine that IP addresses differ from mentioned in guide

Flood protection MTU 1500 fragmented

Hello,
I've just recently been faced with a flood on a 3750 that I can't seem to handle and would greatly appreciate any help offered.
I have the following setup:
24 interface used out of 48 on a Cisco 3750.
The C3750 has unicast storm control which prevents it from faillin in case of a flood with many small packets.
All this was fain until recently when the users behind it started a flood that look like this:
1) each pachet has size=ethernet MTU=1500
2) each packet has the same ID and different offsets so they are made to look like fragmented packets
3) On my Linux border router (plugged into the C3750) with tcpdump -n -i eth1 -vvv I see:
21:00:52.941148 IP (tos 0x0, ttl 127, id 28639, offset 11840, flags [+], length: 1500) 86.104.102.16 > 70.84.247.164: udp
21:00:52.941271 IP (tos 0x0, ttl 127, id 28639, offset 13320, flags [+], length: 1500) 86.104.102.16 > 70.84.247.164: udp
21:00:52.941394 IP (tos 0x0, ttl 127, id 28639, offset 14800, flags [+], length: 1500) 86.104.102.16 > 70.84.247.164: udp
21:00:52.941517 IP (tos 0x0, ttl 127, id 28639, offset 16280, flags [+], length: 1500) 86.104.102.16 > 70.84.247.164: udp
21:00:52.941640 IP (tos 0x0, ttl 127, id 28639, offset 17760, flags [+], length: 1500) 86.104.102.16 > 70.84.247.164: udp
As you can see it has no udp source port or destination port in the packet header.
When this happens although the C3750 CPU is not more than 30%, all traffic that is routed through it has a loss of 80-90%.
Has anyone ever encountered this ?
Is there a way to filter it in the future ?
Any advice or some links in regard to this would be greatly appreciated.
Sorry if I have misplaced the list for problems like this.

Your problem is not very clear to me. If someone is flooding your switch with strange packets, why not tell them not to do so, or even use an ACL to block that traffic from entering the switch, if you know the real source of the traffic.
Is the destination address that you see is geniune? If not, I am guessing that the high packet loss is due the fact the switch is unable to route them and is simply dropping them.

Mtu 1500 shows in vcenter but service profile template is at 9000

I have 2 iscsi nics configured on my service profile and they are set to 9000
but in vcenter it is still showing the nics at 1500mtu
any idea?

this is what i see.... Looks like it is not enabled?
sh policy-map
Type qos policy-maps
====================
policy-map type qos ISCSI
class class-default
set cos 5
Type queuing policy-maps
========================
policy-map type queuing default-in-policy
class type queuing in-q1
queue-limit percent 50
bandwidth percent 80
class type queuing in-q-default
queue-limit percent 50
bandwidth percent 20
policy-map type queuing default-out-policy
class type queuing out-pq1
priority level 1
queue-limit percent 16
class type queuing out-q2
queue-limit percent 1
class type queuing out-q3
queue-limit percent 1
class type queuing out-q-default
queue-limit percent 82
bandwidth remaining percent 25
policy-map type queuing default-4q-8e-in-policy
class type queuing 2q4t-8e-in-q1
queue-limit percent 10
bandwidth percent 50
class type queuing 2q4t-8e-in-q-default
queue-limit percent 90
bandwidth percent 50
policy-map type queuing default-4q-8e-out-policy
class type queuing 1p3q1t-8e-out-pq1
priority level 1
class type queuing 1p3q1t-8e-out-q2
bandwidth remaining percent 33
class type queuing 1p3q1t-8e-out-q3
bandwidth remaining percent 33
class type queuing 1p3q1t-8e-out-q-default
bandwidth remaining percent 33
Type control-plane policy-maps
==============================
policy-map type control-plane copp-system-p-policy-strict
class copp-system-p-class-critical
set cos 7
police cir 39600 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-important
set cos 6
police cir 1060 kbps bc 1000 ms conform transmit violate drop
class copp-system-p-class-management
set cos 2
police cir 10000 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-normal
set cos 1
police cir 680 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-normal-dhcp
set cos 1
police cir 680 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-normal-dhcp-relay-response
set cos 1
police cir 900 kbps bc 500 ms conform transmit violate drop
class copp-system-p-class-redirect
set cos 1
police cir 280 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-exception
set cos 1
police cir 360 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-monitoring
set cos 1
police cir 130 kbps bc 1000 ms conform transmit violate drop
class copp-system-p-class-l2-unpoliced
police cir 8 gbps bc 5 mbytes conform transmit violate transmit
class copp-system-p-class-undesirable
set cos 0
police cir 32 kbps bc 250 ms conform drop violate drop
class copp-system-p-class-l2-default
police cir 100 kbps bc 250 ms conform transmit violate drop
class class-default
set cos 0
police cir 100 kbps bc 250 ms conform transmit violate drop
Type network-qos policy-maps
============================
policy-map type network-qos default-nq-4e-policy
class type network-qos c-nq-4e-drop
congestion-control tail-drop
mtu 1500
class type network-qos c-nq-4e-ndrop-fcoe
pause
mtu 2112
class type network-qos c-nq-4e-ndrop
pause
mtu 2112
policy-map type network-qos default-nq-6e-policy
class type network-qos c-nq-6e-drop
congestion-control tail-drop
mtu 1500
class type network-qos c-nq-6e-ndrop-fcoe
pause
mtu 2112
class type network-qos c-nq-6e-ndrop
pause
mtu 2112
policy-map type network-qos default-nq-7e-policy
class type network-qos c-nq-7e-drop
congestion-control tail-drop
mtu 1500
class type network-qos c-nq-7e-ndrop-fcoe
pause
mtu 2112
policy-map type network-qos default-nq-8e-policy
class type network-qos c-nq-8e
congestion-control tail-drop
mtu 1500

MTU keeps changing from 1500 to 576

I wanted to lock the MTU to 1500 for my Internet port so I made the following changes:
In rc.local I placed the command
ifconfig eth0 mtu 1500
In /etc/conf.d/dhcpcd I added:
nohook mtu eth0
Note that the eth0 port is set up to use dhcp in rc.conf.
So it boots correctly, MTU is set to 1500, and Internet access is fine. Sometime during the day the MTU changes to 576.
Does anyone know what process is doing this? Is it something I can change?
Thanks in advance.
Mark

walterjwhite wrote:576 as that would dramatically slow down
MTU is a can of worms - I've played with it, to try to get my ADSL modem reliable, and now do:
ip route replace default via 192.168.1.1 mtu 1460
So now for me this works:
ping -s 3000 www.dslreports.com
576 is the *safest* value, AFAICT, because all IPV4 networks need to support it, as a minimum. And increasing the MTU is a trade-off between responsiveness and throughput, with the risk that MTU negotiation (via ICMP) can fail.
It would be interesting to know the rationale. Maybe it's a case of, "if you have to ask for the MTU, we'll answer with the safest MTU value."

MTU option of IPv6 router advertisement ignored

I recently turned up an IPv6 tunnel from Hurricane Electric (http://tunnelbroker.net/) to my home router, which is a Cisco 1921 ISR. The IPv6 tunnel works great, save for one small problem. That being that the MTU of the tunnel is 1480 and the MTU on my Mac is 1500. If I manually set the MTU on my Mac to 1480, everything works as expected. However, part of IPv6 autoconfig is setting the MTU for situations like this where there is a tunnel or the more common PPPoE, both of which require a lower MTU. The router is configured to set this option, and I can see it via tcpdump and radvdump:
[root@strongbad]# tcpdump -i en0 -n -XX icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:36:09.218626 IP6 fe80::ca9c:1dff:fed6:17a0 > ff02::1: ICMP6, router advertisement, length 64
    0x0000: 3333 0000 0001 c89c 1dd6 17a0 86dd 6e00 33............n.
    0x0010: 0000 0040 3aff fe80 0000 0000 0000 ca9c ...@:...........
    0x0020: 1dff fed6 17a0 ff02 0000 0000 0000 0000 ................
    0x0030: 0000 0000 0001 8600 1266 4000 0708 0000 .........f@.....
    0x0040: 0000 0000 0000 0101 c89c 1dd6 17a0 0501 ................
    0x0050: 0000 0000 05c8 0304 40c0 0027 8d00 0009 ........@..'....
    0x0060: 3a80 0000 0000 2001 0470 e9ba 0001 0000 :........p......
    0x0070: 0000 0000 0000                           ......
[root@strongbad]# radvdump
# radvd configuration generated by radvdump 1.6
# based on Router Advertisement from fe80::ca9c:1dff:fed6:17a0
# received by interface en0
interface en0
    AdvSendAdvert on;
    # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
    AdvManagedFlag off;
    AdvOtherConfigFlag off;
    AdvReachableTime 0;
    AdvRetransTimer 0;
    AdvCurHopLimit 64;
    AdvDefaultLifetime 1800;
    AdvHomeAgentFlag off;
    AdvDefaultPreference medium;
    AdvSourceLLAddress on;
    AdvLinkMTU 1480;
    prefix 2001:470:e9ba:1::/64
        AdvValidLifetime 2592000;
        AdvPreferredLifetime 604800;
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr off;
    }; # End of prefix definition
}; # End of interface definition
You can plainly see the MTU is at 1500, when it should be 1480:
[root@strongbad]# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:16:cb:ab:af:0d
    inet6 fe80::216:cbff:feab:af0d%en0 prefixlen 64 scopeid 0x4
    inet 192.168.1.44 netmask 0xffffff00 broadcast 192.168.1.255
    inet6 2001:470:e9ba:1:216:cbff:feab:af0d prefixlen 64 autoconf
    media: autoselect (1000baseT <full-duplex>)
    status: active
[root@strongbad]# netstat -in
Name Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs Coll
lo0   16384 <Link#1>                        800471     0   800471     0     0
lo0   16384 ::1/128     ::1                 800471     -   800471     -     -
lo0   16384 fe80::1%lo0 fe80:1::1           800471     -   800471     -     -
lo0   16384 127           127.0.0.1         800471     -   800471     -     -
gif0* 1280 <Link#2>                             0     0        0     0     0
stf0* 1280 <Link#3>                             0     0        0     0     0
en0   1500 <Link#4>    00:16:cb:ab:af:0d 24352460     0 36285322     0     0
en0   1500 fe80::216:c fe80:4::216:cbff: 24352460     - 36285322     -     -
en0   1500 192.168.1     192.168.1.44    24352460     - 36285322     -     -
en0   1500 2001:470:e9 2001:470:e9ba:1:2 24352460     - 36285322     -     -
fw0   2030 <Link#5>    00:1c:b3:ff:fe:9b:6d:d0        0     0        0     0     0
en1   1500 <Link#6>    00:1c:b3:b0:41:f0        0     0        0     0     0
vmnet 1500 <Link#7>    00:50:56:c0:00:01        0     0        0     0     0
vmnet 1500 172.16.130/24 172.16.130.1           0     -        0     -     -
vmnet 1500 <Link#8>    00:50:56:c0:00:08        0     0        0     0     0
vmnet 1500 172.16.123/24 172.16.123.1           0     -        0     -     -
On my Mac in System Preferences > Network > Ethernet > Advanced > Ethernet the "Configure" value is set to "Automatically". I discovered a manual sysctl setting that looked promising, but had no noticeable effect:
[root@strongbad]# sysctl -w net.inet6.ip6.accept_rtadv=1
net.inet6.ip6.accept_rtadv: 0 -> 1
I'm running the latest version of Snow Leopard (10.6.7) on my Mac, and there doesn't appear to be any updates for it. Just for fun, here's the kernel banner:
[root@strongbad]# uname -a
Darwin strongbad.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
Any ideas on how to get my Mac to honor the MTU in IPv6 router advertisements and set the MTU automatically?
Thanks in advance,
-Lex

I was wrong. The MTU in IPv6 router advertisements is not ignored by my Mac. In fact, it works great. A few things threw me off here:
1. The IPv6 MTU is not relected in ifconfig and netstat output if it's different than IPv4.
2. The MTU size was wrong. The IPv6 MTU also has to account for ADSL PPPoE overhead the same as any other protocol. PPPoE adds 8 bytes overhead per packet. That means with the 6in4 tunneling overhead of 20 bytes, the true MTU for an IPv6 packet over a 6in4 tunnel over PPPoE is 1472.
3. The firewall was correctly configured to pass ICMPv6, so PMTUD was working. However, this created the illusion that some destinations were working and some were not. I wrongly assumed that mucking with the MTU to and from 1480 was making a difference. In reality, it was PMTUD doing its thing, albeit slowly and on a strict destination by destination basis.
In sum, setting the MTU on the router interface closest to my Mac to 1472, made it all work beautifully. I had to wait for a few route advertisements to pass by, but my Mac did end up doing the right thing.
One last thing worth noting. On a Cisco router, setting the "ipv6 mtu" to something non-default will be reflected in the IPv6 route advertisements it sends out.
Hope this helps,
-Lex

MTU size

Is there a way to check the current MTU size (as per the document 1500 is the default size) on CUCM?
we have a customer who is using cucm with nice recording server, there is some issue in the recording and as per them they are getting MTU size 1340 from CUCM in their logs.
Please let me know if there is any command to check the current MTU size.

Hi Pawan,
You can try the following command:
admin:show network route detail
It will give you the MTU setting towards the bottom of the output, something like below from my lab server
ff00::/8 dev eth0 table 255 metric 256 expires 20098217sec mtu 1500 advmss 14
HTH
Manish

MTU used by ECI modem/HH3

For whatever reason my MTU value seems to be set at 1452 from the ECI modem/HH3, any idea why this would be the case rather than 1492?
More importantly is there any way to change this as I'm convinced this is too low and would like to try the default of 1492 for PPPoE as my downloads seem to be quite erratic?

the MTU for BT router will be set automatically at 1500 on the computer side for FTTC (WAN socket I am sure you know there is software that can adjust these settings
MTU adjustments where needed sometimes on the old ADSL routers, not needed for Fibre these days !
you can change the windows side of the MTU back to 1500 using this , open up the comman prompt as administrator
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent

Confused about mpls mtu command

hi,
i confuse about mpls mtu command
test platforms are 76 pfc3b,mpls,gigabit sip400 spa interface
if i didn't config mpls mtu command ,using default,ping command is successful,if more than 1496 packets, i can see fragment from show ip traffic.
if i config mpls mtu override 1504,ping command is sucessful too. there is fragment too when i use 1501 byte packet.
if i config mpls mtu override 1524 byte.
ping command failed if i use packet more than 1500, , all packet are droped,even 1501 byte.only 1500 byte packet can success.
all config above interface mtu is 1500.
this confused me.
why i use default 1500 interace mtu, mpls mtu override 1504 ,ping packet can fragment,ping success, but i use mpls mtu override 1524, i can see fragment in show ip traffic,but ping command failed. i can't see packet in destination router,how this work.
thank you!
jun

topology is simple
7609-1--sip GE spa----7609-2--pos---7609-3--flexwan E1-----7604-1--ge--ce
i config mpls mtu 1524 between 7609-1 and 7609-2 . and keep interface mtu 1500 default.
ping packet from 7609-1 to 7604-1 loopback 0.
ping 1500 byte packet is ok, but ping 1501 byte packet is totally lost.then i config mtu 1524 between 7604-1 and 7609-3, it is useless,notwork, i can't see packet coming from 7609-1 on 7604-1.
but i add config mtu 1524 between 7609-1 and 7609-2. config mtu 1500 between 7604-1 and 7609-3,ping 1501 bytes from 7609-1 to 7604-1 loopback0 is ok. but i can see fragment from show ip traffic command in 7609-3.
i have a question, why we need mpls mtu command. if we don't change interface mtu,just only config mpls mtu 1524, it doesn't work, if we just change mpls mtu,how it work in the ios. if we config interface mtu 1524,interface mtu size is big enough, it seems mpls mtu command is useless, we don't need mpls mtu command, just interface mtu 1524 is ok.
why we need mpls mtu command. we just only change interface mtu is enough.
thank you!
jun

Changing MTU for local-zone

I'm getting ready to go to gigabit jumbo frame (MTU 9000) network, but I'm not there yet.
I have some nice Intel NICs, and I set them so they can do a MTU 16128 but fix the MTU at 1500 until I make the change.
But the local-zones interface won't change with the global:
e1000g1: flags=1001000803<UP,BROADCAST,MULTICAST,IPv4,FIXEDMTU> mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ether 0:e:c:c4:48:a8
e1000g1:1: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 16128 index 3
zone test-zone
inet 10.0.0.191 netmask ffffff00 broadcast 10.0.0.255
I would like the local-zone's virtual interface to have a MTU of 1500 just like it's proud parent.
I've tried a /etc/hostname.e1000g1:1 with 'mtu 1500'. That creates a virtual interface with the proper MTU, but the zone's interface becomes e1000g1:2 still with a MTU of 16128.
How can I set the MTU of the local-zone?
Thanks.

Its now a few months since i last played with networking in zones, but i don't think you can do that. IIRC there are only a limited set of options which can be set to a shared interface which belongs to a zone.
I think that in order for this to work you would have to dedicate an interface to the zone (i.e. 'exclusive mode'), then you can probably change the MTU from inside the zone.
However this is my guess, i haven't tested or verified it..
.7/M.

GRE tunnel default MTU

Anybody know the default mtu setting on a gre tunnel interface such as this?:
interface Tunnel1
description "xxx"
ip address x.x.x.x 255.255.255.252
tunnel source Loopback1
tunnel destination x.x.x.x
I'm asking cause on the core redundant to this one where I've copied code from, the config line 'ip mtu 1500' is configured. I want to make sure these are matched up.
Thanks in advance.
/rls

Robert,
Sorry, I spoke too soon. I should have focused on your question, which is "IP MTU" and referred you to the command "show ip interface Tu0" instead of "show interface tu0".
GRE packets are formed by the addition of the original packets and the required GRE
headers. These headers are 24-bytes in length and since these headers are added to the
original frame, depending on the original size of the packet we may run into IP MTU
problems.
Even though the maximum IP datagram has been defined as 64K, most links enforce a smaller
maximum size for the packets. This maximum size is known as MTU (Maximum Transmission
Unit) and as you also know, different types of media have different MTU sizes they can
accommodate and transport. The most common IP MTU is 1500-bytes in length (Ethernet).
The IP implementation, as we know it, provides a mechanism to allow routers the
fragmentation and transmission of packets larger if there are differences in the MTU and a
packet is larger than what the outgoing media will support. Once a packet has been
fragmented to be sent over a media that will not support the original packet size, the end
station is responsible for the reassembly of the different fragments the original packet
was broken into.
GRE tunnels normally calculate their IP MTU size based on the physical link they will use
as the outgoing interface.
What you see in âshow interface Gig Xâ is the MTU of the interface and NOT the IP MTU.
In order for you to see the IP MTU you need to use the âshow ip interface Gig Xâ
When the tunnel is created, it deducts the 24-bytes it needs to encapsulate the passenger
protocols and that is the IP MTU it will use.
For example, if we are forming a tunnel over FastEthernet (IP MTU 1500) the IOS calculates
the IP MTU on the tunnel as:
1500-bytes from Ethernet - 24-bytes for the GRE encapsulation = 1476-Bytes
Let me explain this with a simple set up:
Lets say I configure a Tunnel interface and sourcing it via a physical interface which has an MTU of 1500, then the Tunnel
interface will have IP MTU of 1476, leaving space for the 24 byte GRE Header.
In my case, I am sourcing the packets from Gig0/0 which has physical interface of MTU 1500, so when I do a "show ip int Tu0",
You will see that the IP MTU is 1476.
Router#sh run int gi0/0
Building configuration...
Current configuration : 118 bytes
interface GigabitEthernet0/0
ip address 10.89.245.253 255.255.255.0
duplex auto
speed auto
media-type rj45
end
Router#sh run int tu0
Building configuration...
Current configuration : 127 bytes
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 10.89.245.1
end
Router#sh int gi 0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.89.245.253/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
Router#sh ip int tu 0
Tunnel0 is up, line protocol is up
Internet address is 1.1.1.1/30
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes
Now, lets say I lower the IP MTU value on Gi0/0 to 1400, What should be the default new value on the tunnel interface?? You
are absolutely right, 1376 :-)
Router#sh run int gi0/0
Building configuration...
Current configuration : 131 bytes
interface GigabitEthernet0/0
ip address 10.89.245.253 255.255.255.0
ip mtu 1400
duplex auto
speed auto
media-type rj45
end
Router#sh ip int tu0
Tunnel0 is up, line protocol is up
Internet address is 1.1.1.1/30
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1376 bytes
Please standby.... More to follow in the second post due to character limitation
Regards,
Arul
** Please rate all helpful posts **

7200/7301 MTU issue on Port-Channel

Hi guys,
I have an issue with MTU on port-channel :
When I create a port-channel interface, I can set MTU to 1530 max
When I configure an interface in this port-channel, I can set port-channel MTU to 9216 max.
But when I reload, "mtu 9216" command is rejected and port-channel MTU is set to 1500 :
mtu 9216
^
% Invalid input detected at '^' marker.
%Interface MTU set to channel-group MTU 1500.
IOS version is 12.4(25g)
Thank you so much.

Hi guys,
I have an issue with MTU on port-channel :
When I create a port-channel interface, I can set MTU to 1530 max
When I configure an interface in this port-channel, I can set port-channel MTU to 9216 max.
But when I reload, "mtu 9216" command is rejected and port-channel MTU is set to 1500 :
mtu 9216
^
% Invalid input detected at '^' marker.
%Interface MTU set to channel-group MTU 1500.
IOS version is 12.4(25g)
Thank you so much.

[Solved] MTU settings lost with wifi connection

Hi
After reboot the
ip link show | grep mtu
shows me
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000
But after a few second if I ran again this command it's show me
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 576 qdisc mq state UP mode DORMANT qlen 1000
I cannot ran anything except Tilda, but mtu is changing from 1500 to 576
My /etc/rc.local is
#!/bin/bash
# /etc/rc.local: Local multi-user start-up script.
ip link set wlan0 mtu 1500
Why it's change without any reason?
Last edited by saalty (2012-11-11 09:17:26)

Are you using dhcp? If so, dhcpd will helpfully adjust your MTU to what the network claims it wants. However, this can cause problems in various cases. (It stopped me accessing aur from home, for example.) If you would rather it not do this, comment the line in /etc/dhcpd.conf like so:
#option interface_mtu

MTU error (Path too long) with linux-3.6.2

I have a PC running 24/7, with an OpenVPN connection up all the time as well. I also have a (shared) ssh connection open, through said vpn. Every night an rsync job is ran, to backup some stuff over said VPN, through a shared ssh connection.
Starting a few days ago (Oct 17) I've had trouble with this, as in after rsync started, it would not be able to finish its job, getting "interrupted" (or, hanged) quite early on.
Looking in the journal, I can see error messages such as those (right after rsync starts, which happens at 02:23) :
Oct 17 02:23:05 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:07 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:09 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:13 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:39 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:24:13 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:25:20 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:27:21 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:29:21 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:31:21 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:33:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:35:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:37:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
This eventually led to the ssh connection timing out, and the rsync job failing to complete.
Also, restarting OpenVPN seems to "fix" the issue, without the need to change any settings.
That's when I realized this started happening since upgrading the kernel to 3.6.2, so I then downgraded to 3.5.6 (Oct 19) and, since then, haven't had any issue.
So I'm thinking this is some kind of bug/regression in the 3.6 kernel, but I'm not really sure what to do now.
Note: I see 3.6.3 is out (and in testing), but only looked at the changelog so far (and didn't see anything that seem related to this issue?).

Thanks for your answers (and sorry about the delay).
I'm not sure how to read the error message actually, but I use default settings and `ip addr show` reports a MTU of 1500 indeed. Also, (on linux-3.6.2) I tried using OpenVPN's --mtu-test option to see what it would say (even though early on I never have a problem), and here it is:
NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1541,1541] remote->local=[1541,1541]
I'm nor really sure what it means, that I could (should?) use 1541 instead of 1500? And if so, how come it says I could go higher while I get errors with Path-MTU=1460 ? And actually, right before this result I do have a couple of those Path-MTU errors in the log, so I really don't know what to make of it, could it fail at 1460 but work higher? Does that even make sense?
I still don't know if it's really an MTU issue or not, since the kernel 3.5.6 isn't affected. Anyhow, I'll probably install 3.6.3 and see, hopefully it'll be back to normal.... if not I guess I'll have to try and set an MTU, though I'm not sure to what.
Also, would that require the OpenVPN server to have its MTU set that way as well (Since currently it also uses default settings, so MTU 1500) ?

6506 - SUP720-3B MTU size

Due to MPLS environment on our WAN, we need to increase MTU size on the lan.
We configure 6500 to use only layer 2 interfaces (switchport activate on each interface)
Do i need to configure MTU size on each interface (i think i need to do it if i want to use this interface at layer 3) or can i configure only global MTU (system jumbomtu 9216)
Is there a command to verify jumbomtu size set on the switch ?

you can use the MTU per VLAN on the 6500.
'set vlan 10 mtu "576-18190"' (catOS)
or
'vlan 10'
'mtu "1500-18190"' (IOS)
this command sets the MTU for VLAN 10; values are from 576 to 18190.
please see the following link for more info: (IOS)
http://www.cisco.com/en/US/products/hw/switches/ps708/products_command_reference_chapter09186a00801eaeec.html#wp1011172
please see the following link for more info: (catOS)
http://www.cisco.com/en/US/products/hw/switches/ps708/products_command_reference_chapter09186a00802debd1.html#wp1027906

MTU 1500

Similar Messages

Maybe you are looking for