From: Kenneth Wygand (KWygand@customonline.com)
Date: Sun Jul 04 2004 - 13:24:02 GMT-3
For those of you that are interested, I've illustrated exactly how changing the MTU size on a 3550 actually works.
If anyone has any questions, ask away! :)
Ken
------------------------------------------
First lets see what files are in Flash.
------------------------------------------
Sw2#dir flash:
Directory of flash:/
2 -rwx 0 Mar 1 1993 01:41:31 +00:00 env_vars
3 -rwx 252 Mar 1 1993 00:29:17 +00:00 info
4 drwx 192 Mar 1 1993 00:32:49 +00:00 c3550-i5q3l2-mz.121-20.EA2
6 -rwx 2625 Mar 1 1993 03:34:59 +00:00 config.text
170 -rwx 252 Mar 1 1993 00:32:49 +00:00 info.ver
24 -rwx 916 Mar 1 1993 00:25:16 +00:00 vlan.dat
25 -rwx 346 Mar 1 1993 01:41:31 +00:00 system_env_vars
26 -rwx 5 Mar 1 1993 03:34:59 +00:00 private-config.text
15998976 bytes total (8273920 bytes free)
Sw2#
------------------------------------------
Note that all files in here have a date
of 1993. Let's set the clock to 2004.
------------------------------------------
Sw2#
Sw2#clock set 11:55:00 4 july 2004
Sw2#
------------------------------------------
Now lets check the contents of the
"env_vars" file (ASCII text file)
------------------------------------------
Sw2#more env_vars
Sw2#
------------------------------------------
As you can see, the file is blank.
This isn't surprising because the file
size from the "show flash:" illustrated
a size of '0'.
Now let's configure the system mtu to be
a size of 1504.
------------------------------------------
Sw2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Sw2(config)#system mtu 1504
Changes to the System MTU will not take effect until the next reload is done.
Sw2(config)#
Sw2(config)#exit
Sw2#
------------------------------------------
Let's now check the files in flash again.
------------------------------------------
Sw2#dir flash:
Directory of flash:/
2 -rwx 346 Jul 4 2004 11:55:32 +00:00 system_env_vars
3 -rwx 252 Mar 1 1993 00:29:17 +00:00 info
4 drwx 192 Mar 1 1993 00:32:49 +00:00 c3550-i5q3l2-mz.121-20.EA2
6 -rwx 2625 Mar 1 1993 03:34:59 +00:00 config.text
7 -rwx 16 Jul 4 2004 11:55:32 +00:00 env_vars
170 -rwx 252 Mar 1 1993 00:32:49 +00:00 info.ver
170 -rwx 252 Mar 1 1993 00:32:49 +00:00 info.ver
26 -rwx 5 Mar 1 1993 03:34:59 +00:00 private-config.text
15998976 bytes total (8273408 bytes free)
Sw2#
------------------------------------------
Note that two of the files now have modified
dates of 2004: system_env_vars and env_vars.
The system_env_vars file is merely an update
and does not contain any actual changes, so
we'll ignore this file.
Let's take a look at the contents of the
env_vars file now:
------------------------------------------
Sw2#
Sw2#more env_vars
SYSTEM_MTU=1504
------------------------------------------
As you can see, the contents of the env_vars
file have changed to reflect the new MTU
we have configured.
When the switch boots up, it will read this
file prior to loading the startup configuration
------------------------------------------
Sw2#
------------------------------------------
Now lets check the current system MTU
------------------------------------------
Sw2#
Sw2#sh system mtu
System MTU size is 1500 bytes
On next reload, system MTU will be 1504 bytes
------------------------------------------
Since the env_vars file is only read at
startup, the change will not take effect
until the switch is restarted.
Well, if this file is read at startup,
what happens if we delete the file from
flash? What MTU will the switch start up
with on next reboot?
------------------------------------------
Sw2#del env_vars
Delete filename [env_vars]?
Delete flash:env_vars? [confirm]
Sw2#
------------------------------------------
Now that the file is deleted, what does the
loaded system image *think* the new MTU
will be at startup?
------------------------------------------
Sw2#sh system mtu
System MTU size is 1500 bytes
On next reload, system MTU will be 1504 bytes
Sw2#
------------------------------------------
Well, even though the env_vars file has
been deleted, the switch still thinks
the MTU will be changed from the default
when it restarts.
Looks like the IOS provides stale information
and was not designed to perform a check on
the env_vars file before indicating
what the MTU will be on restart!
Let's restart and see what happens:
------------------------------------------
Sw2#
Sw2#reload
System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm]
Base ethernet MAC Address: 00:0d:bd:6b:21:00
Xmodem file system is available.
The password-recovery mechanism is enabled.
Initializing Flash...
!!!STARTUP SEQUENCE CLIPPED FOR BREVITY!!!
------------------------------------------
Now let's check the post-boot MTU.
------------------------------------------
Sw2#
Sw2#
Sw2#show system mtu
System MTU size is 1500 bytes
Sw2#
As we can see, since there was no env_vars file in flash at startup, the MTU is back to the default MTU size of 1500 bytes.
Hope this helps!
Ken
________________________________
From: nobody@groupstudy.com on behalf of Tom Rogers
Sent: Sun 7/4/2004 12:07 PM
To: Richard Dumoulin; ccielab@groupstudy.com
Subject: RE: OSPF MTU problem
Richard,
You need set system mtu back again to 1500, wr erase will not work
Tom
Richard Dumoulin <richard.dumoulin@vanco.es> wrote:
But even after erasing the config and reloading I often find the mtu to be
1504 in my own rack. I used to type "ip mtu 1500" but it had happened once
that the change would not take effect so I opted for the ip ospf mtu ignore.
Is there a reason or should we doubt about the default setting being 1500 ?
--Richard
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: sabado, 03 de julio de 2004 19:47
To: barrerj1@hotmail.com; Shibu Nair
Cc: ccielab@groupstudy.com
Subject: RE: OSPF MTU problem
Jorge,
Is this an IE rack? If so the MTU has most likely been changed
because someone was practicing 802.1q tunneling. In the case of a .1q
tunnel the MTU must be increased to at least 1504 to account for the second
dot1q header that in prepended to the packet, which could cause a packet
that is already at MTU to exceed 1500 bytes.
The workarounds are either to change the system mtu back to 1500 and
reload the switch (reload is required to apply the change) or to issue the
ip ospf mtu ignore command.
This problem also used to occur when combining the mixed media
modular token ring interfaces of the 2600/3600 with the fixed config 2500s.
The 2500s had an MTU of 4000 something while the modular interfaces had 8000
something. This also is a problem in IS-IS, as the hello packet is padded
to the MTU of the interface. This can be disabled with the "no
hello-padding" command under the IS-IS process.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> barrerj1@hotmail.com
> Sent: Saturday, July 03, 2004 11:46 AM
> To: 'Shibu Nair'
> Cc: ccielab@groupstudy.com
> Subject: RE: OSPF MTU problem
>
> Ok.
>
>
>
>
>
> I get it
>
>
>
>
>
> Thanks to all
>
>
>
> JB
>
>
>
> -----Original Message-----
> From: Shibu Nair [mailto:shinair@cisco.com]
> Sent: Saturday, July 03, 2004 10:37 AM
> To: barrerj1@hotmail.com
> Cc: ccielab@groupstudy.com
> Subject: Re: OSPF MTU problem
>
>
>
> I think you are using VLAN interface as the L3 interface on the switch
> side. When you use the vlan interface on the switchside, MTU size is
> little more than 1500.
> So manual setup the mtu as the same on both sides or "ip ospf
> mtu-ignore" interface
> command should solve the issue.
> Try out
> Regards
> Shibu
> At 06:26 AM 7/3/2004 -0500, barrerj1@hotmail.com wrote:
>
>
>
> Hi all!
>
>
>
> While doing an OSPF practice lab, I was encountered by the following
> problem.
>
>
>
> 2 routers connected to a 3550 and running OSPF between them, the state
> was stuck in EXSTART and couldn't complete the adjacency.
>
>
>
> I checked CCO and found that the problem was an MTU mismatched.
> However, the CCO doc points this problem to be a common when you
connect
> to another vendor's router. In my case all devices are CISCO.
>
>
>
>
>
>
>
>
> Neighbors Stuck in Exstart/Exchange State
>
>
> The problem occurs most frequently when attempting to run OSPF between
a
> Cisco router and another vendor's router. The problem occurs when the
> maximum transmission unit (MTU) settings for neighboring router
> interfaces don't match. If the router with the higher MTU sends a
packet
> larger that the MTU set on the neighboring router, the neighboring
> router ignores the packet.
>
>
http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a
> 0080093f0d.shtml
>
>
>
>
>
>
>
> Can any one explain why this behavior as I did not change any of the
MTU
> configurations before the problem occurred?
>
>
>
>
>
> Thanks
>
> JB
>
>
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:46 GMT-3