From: barrerj1@hotmail.com
Date: Sat Jul 03 2004 - 12:23:09 GMT-3
Thanks for all the replies!
The switch is sending 1504 MTU
SW1#sh system mtu
System MTU size is 1504 bytes
I used to have my own lab and never experience this problem before.
Now that I'm using a rental rack, I'm experiencing the MTU issue which
is OK I learning even more now.
The ip ospf mtu-ignore fixes the problem, however is this a normal
behavior of OSPF?
Could be the IOS version running on the devices?
R1 is running
R1#sh ver
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-JK9O3S-M), Version 12.2(15)T12, RELEASE
SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 24-Mar-04 23:05 by cmong
Image text-base: 0x80008098, data-base: 0x81F2FA38
ROM: System Bootstrap, Version 12.2(7r) [cmong 7r], RELEASE SOFTWARE
(fc1)
ROM: C2600 Software (C2600-JK9O3S-M), Version 12.2(15)T12, RELEASE
SOFTWARE (fc1)
Rack1R1 uptime is 5 hours, 9 minutes
System returned to ROM by reload
System image file is "flash:c2600-jk9o3s-mz.122-15.t12.bin"
SW1 is running
SW1#
Rack1SW1#sh ver
Cisco Internetwork Operating System Software
IOS (tm) C3550 Software (C3550-I5K2L2Q3-M), Version 12.1(20)EA1a,
RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 19-Apr-04 22:16 by yenanh
Image text-base: 0x00003000, data-base: 0x0095E2C4
ROM: Bootstrap program is C3550 boot loader
Rack1SW1 uptime is 13 hours, 31 minutes
System returned to ROM by power-on
System image file is "flash:/c3550-i5k2l2q3-mz.121-20.ea1a.bin"
The point I'm trying to make is that in a lab environment with 2 routers
and a 3550 all devices running OSPF and I do not manually change MTU
values, what's the possibility of MTU changes on the 3550 due to
topology arrangements like trunking, tunnels or something else.
Is this a normal OSPF behavior with all Cisco devices?
Int vlan 10
10.10.10.10/24
3550----------------10.10.10.1/24---fa0/0R1
|
|
|
|
10.10.10.2/24
fa0/0
R2
All devices in area 0
Thanks!
JB
-----Original Message-----
From: Aekasit [mailto:aekasit@ait.co.th]
Sent: Saturday, July 03, 2004 7:40 AM
To: samccie2004@yahoo.co.uk; barrerj1@hotmail.com;
ccielab@groupstudy.com
Subject: Re: OSPF MTU problem
Try command "ip ospf mtu-ignore" on LAN Interface of router and you can
continue your lab.
I used to found that sometimes switch set MTU on its interface to be
1504
and LAN interface of router
usually use 1500 as MTU. You may not be able to change default MTU.
Consequently, this will cause MTU Mismatch problem and OSPF state will
be
stucked in EXSTART state.
----- Original Message -----
From: <samccie2004@yahoo.co.uk>
To: <barrerj1@hotmail.com>; <ccielab@groupstudy.com>
Sent: Saturday, July 03, 2004 7:07 PM
Subject: RE: OSPF MTU problem
> Are iu trunking , if so u might be adding more to MTU due to dot1q.
>
> Just a guess, pls correct me if I am wrong.
>
> Sam
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> barrerj1@hotmail.com
> Sent: 03 July 2004 13:26
> To: ccielab@groupstudy.com
> Subject: OSPF MTU problem
>
>
> 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