From: Aaron T. Hassan (tyang@xxxxxxxxxxxx)
Date: Tue Nov 20 2001 - 13:05:34 GMT-3
My 2621 is always running freakly busy, the CPU usage is constantly at
around 80%, I had tried different IOS versions but nothing help much. The
MRTG report shows the bandwidth usage is just at 400k/ps in max, no
throttles on both Eth interfaces. Why the CPU usage is so high? I had
eliminated the hardware issue(pls see sh ver below). I wonder it relates to
the VoIP traffic, which cause more processing power, Cisco document suggests
to change MTU to 500. Anyone knows about this? will it help? or do you
experience the similar problems? thanks.
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-I-M), Version 12.0(4)T, RELEASE SOFTWARE
(fc1)
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Wed 28-Apr-99 16:50 by kpma
Image text-base: 0x80008088, data-base: 0x806B44EC
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
ptime uptime is 2 days, 13 hours, 52 minutes
System restarted by reload
System image file is "flash:c2600-i-mz.120-4.T.bin"
cisco 2621 (MPC860) processor (revision 0x102) with 26624K/6144K bytes of
memory.
Processor board ID JAB0416013M (3352220023)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
2 FastEthernet/IEEE 802.3 interface(s)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
----- Original Message -----
From: "Knellinger, Mark" <KnelliMS@tvratings.com>
To: "'afiddler'" <afiddler@wi.rr.com>; "Ccielab (E-mail)"
<ccielab@groupstudy.com>
Sent: Tuesday, November 20, 2001 10:33 AM
Subject: RE: MTU mismatch on token-ring OSPF network
> Just set the MTU on the interface manually on one side.
> conf t
> int to 0
> mtu ?
>
>
> Mark
>
> -----Original Message-----
> From: afiddler [mailto:afiddler@wi.rr.com]
> Sent: Monday, November 19, 2001 4:53 PM
> To: Ccielab (E-mail)
> Subject: MTU mismatch on token-ring OSPF network
>
>
> For you token-ring fans (all three of you):
>
> I have a few older routers (2500's) and a one newer router (3640) with
> token-ring interfaces. I have run across an OSPF MTU mismatch problem
that
> I consider to be a "gotcha" if you don't know about it. The old routers
> with an MTU of 4464 on their token-ring interfaces will not neighbor up
with
> the newer router that has an MTU of 8136. I see debug messages as follows
> on the older routers, which also reflects their ability to detect the MTU
> mismatch:
>
> 01:57:32: OSPF: Nbr 200.0.0.1 has larger interface MTU
>
> CCO has a tech note about this problem (URL is below). The tech note
> indicates that MTU mismatch detection was introduced in 12.0(3) to comply
> with the OSPF RFC. The "IP OSPF MTU-IGNORE" command was introduced in
> 12.1(3) to optionally "turn off" mismatch detection. Note that the v12.2
> OSPF command documentation erroneously indicates the "IP OSPF MTU-IGNORE"
> was introduced in 12.0(3). Instead, I believe there is a gap in the IOS
> between the version that supports detection of MTU mismatch and the
version
> that provides the "MTU-IGNORE" command.
>
> The tech note indicates that the IOS does not support changing MTU on a
LAN
> interface. With respect to the OSPF problem, that is not the case. In
> fact, it's the only way I am able to get OSPF to neighbor up on a
token-ring
> network with my older routers running 12.0(18) code. I just change the
MTU
> on the router with the default MTU of 8136, down to 4464, and they
neighbor
> up immediately.
>
> The tech note also indicates that the need for the IP OSPF MTU-IGNORE
> statement is rare. I am not clear on their reasoning, particularly
because
> they also say that you can't change the MTU on a LAN interface. What else
> can you do (besides not use token-ring anymore ;-)?
>
> This problem is not specific to the mix of "older" and "newer" routers. I
> ran into the same problem recently when I attended a training class,
setting
> up OSPF over token-ring between two seemingly identical 2600 routers!
>
> It would have to be something to watch for anytime you set up OSPF over a
> token-ring supporting more than one router and the routers are running
> 12.0(3) and up but less than 12.1(3). With these IOS versions, the
routers
> would detect MTU mismatches but would lack the OSPF parameter to ignore
> them. The only other option is to change the MTU on the token-ring
> interface of the larger MTU router to match the smaller MTU router using
the
> interface command "mtu nnnn", where the n's represent the lower MTU in
> bytes.
>
> If I am not mistaken, a similar issue exists with IS-IS routers on a
> token-ring network. I tried the same test with ISIS defined instead of
OSPF,
> but was unable to resolve the MTU mismatch by reducing the MTU on my newer
> router. CCO has a tech note on this issue as well (see URL below), but
> their example involves two serial interfaces (also note that the link to
> this URL from the Cisco > Service & Support > Technical Assistance Center
>
> Technologies > Integrated Intermediate System-to-Intermediate System
(IS-IS)
> > Implementation and Configuration menu points to a different URL). As
> they do in the OSPF tech note, they suggest setting the MTU to the same
> value on all ISIS routers on the network. This method did not work
> successfully for me, even when manually setting MTU on both the old and
new
> routers. Their other suggestion was to use the "no isis hello padding" on
> both routers. To test this, I upgraded my 2504 to v12.1(5)T10, since this
> command is not supported in 12.0(18). I tried this separately and in
> combination with setting the MTU on the 3640 to match the MTU on the 2504,
> to no avail. Just to verify my results, I configured the two older
routers
> with ISIS to see if they neighbored up. They did immediately.
>
> Does anyone know to circumvent the problem on routers running ISIS over
> token-ring with mismatched MTU's?
>
> http://www.cisco.com/warp/public/104/12.html
>
> http://www.cisco.com/warp/public/97/isis_mtu.html
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:19 GMT-3