We help IT Professionals succeed at work.

Strange MTU size on Cisco Catalyst Express 520

Last Modified: 2012-05-06
We are currently having problems with a transparent wireless bridge between a UC520 and CE520.  After having two of the four wireless units replaced and the problem still existing, we are now digging deeper into the switch/router configuration at either side.

The current set up is a UC520 at one site, two Tranzeo wireless bridges with a switch between them, and then finally a CE520 at another site.  The two Cisco devices are set up as a 802.1Q trunk, with 3 VLans (one for each site + management traffic (1 + 2), and voice (100)).

Everything works fine most of the time, but between around 2 to 5 times per day, the wireless link between the sites appears to go down, or at least stop forwarding traffic.  This lasts approximately 1 - 3 minutes and appears to be happening at random times.  The link restores itself without intervention.

Users notice loss of connectivity to resources, IP Phones often lose registration, spanning-tree events can be seen as root elections take place following the loss of connectivity.  

I have noticed a strange MTU setting on the Catalyst Express 520, all the other devices are using an MTU of 1500, but the CE520 gives this output :-

Command was: show system mtu
System MTU size is 1998 bytes
System Jumbo MTU size is 1998 bytes
Routing MTU size is 1998 bytes

It is my understanding that the MTU should be set to 1500 (and the Cisco Output Interpreter also suggests this is the case).  After doing some research, I found a document which says on this device it is not possible to change the MTU "from the default of 1500" (and set system mtu gives invalid command error).

Why is the device reporting 1998 and not 1500 when the document says the (unchangeable) default is 1500?
Is there in fact a way to change this to 1500?
Is this MTU setting likely to be causing the issue?
Any ideas on what else could be the cause if this is not the problem?

Thanks in advance.
Watch Question

Top Expert 2014

Not sure if your switch is included in this but:


I think the 1998 includes overhead for various thinks like trunking, ISL, etherchannels, ect.


I'm still not understanding why the Catalyst Express is stuck with an MTU of 1998 when all the other devices are happy with 1500?

The link you suggest is the one I was getting my information from in the original post.  We have an Express 520, so I would *assume* that the information for the Catalyst Express 500 would be the closest match, and it clearly says:

""Catalyst 2940 / Catalyst Express 500 Series
The System MTU can only be set to 1500 bytes, the default. You cannot set the MTU on a per-interface basis."
Top Expert 2014

The MTU size will have nothing to do with your problem.  All that means is that the switch will support frames up to 1998.  The extra bytes are for things that are used when using VLAN's, trunks, and MPLS.  

As long as nothing uses MTU's larger than 1500 on your network, you have nothing to worry about.

What I would check is to make sure that all switch ports that are not trunks (that is they do not need to carry tagged VLAN traffic) are configured as access mode ports.

How far apart are the two wireless bridges?

You can change the the system mtu with the system mtu command. 1998 is the maximum on your switch. System mtus can be higher than 1500 in case the ddevive is being used for QinQ trunk carying or MPLS where entire ethernet frames are carried within other ethernet frames. This can be repeated several times, so sometimes higher than 1500 is necessarry. I see no harm or advantage in dropping it, but don't think this will help your wireless problem...


Thanks for the input so far.

I agree that the MTU is most likely not the cause, however i'm now at the stage of trying to rule out any possibility.  I cannot think of anything that would be using an MTU of higher than 1500 on the network, and have also tried sending oversized packets across the wireless link with the DF bit set to see if it caused any problems... nothing.

The link is not far at all, less than 1KM, just across the street in fact.  There is no direct line of sight, so we are using two seperate pairs of bridge to get from one site to the other.  Originally the two bridges were directly connected via ethernet, but since the problem occured we have added a switch in between the two bridges, but it hasn't changed the behaviour at all.

I have the trunk plugged into FastEthernet 0/1/8 on the UC520, and GigabitEthernet 1 on the CE520, as described in the quick start guide.  I am guessing normally the two devices would be sitting in the same rack, connected via Ethernet.  Is there any special configuration that needs to be considered to make this work optimally over wireless?

Because this is happening randomly for what (recently) seems to be the maximum of about a minute, I am still finding it hard not to point my finger at the wireless connection between sites, but welcome any other ideas as to the cause of the problem.

I don't know what model Tranzeo you have, but if there was any way to get it to send system logs that you could correlate to they wifi drops, it would help a lot.

For intermittant issues on a link I have found that running an application like whats up gold, or something home brewed that can regularly poll and detect connectivity with each of the elements of the link. (Switch,wireless bridge, wireless bridge,switch) is very useful.

The problem I have had with wifi bridges is that local wifi access pints were prone to disrupt the signal intermittently. This is not to say that this is your issue...
Top Expert 2014
This one is on us!
(Get your first solution completely free - no credit card required)


Sorry, tHe link is considerably *less than* 1KM - it is just across the street.  I described it as less than 1KM, as 1KM seems to be the minimum distance you can configure on the wireless devices themselves.

The Wireless is using the 5Ghz band.  There are three Vlans traveling over the wireless in the trunk, two data VLans and the voice.  We have done all possible to minimise the data travelling across the link, e.g. installing a local DFS server for access to files on a shared drive.

I do not believe the issue is at all bandwidth related - looking at SNMP statistics of each wireless device, the data travelling across the link for the majority of the time is extremely low, there is no degradation of voice call before dropping, and we have also used the TTCP utility to max out the link usage even whilst the network has been being used, and there is no problem caused from this.


Thanks for your assistance.  Much appreciated.

We are still working on the bigger issue of the link going down, however, as this question was more regarding the MTU size I will create a more relevent question and close this one.

Gain unlimited access to on-demand training courses with an Experts Exchange subscription.

Get Access
Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Empower Your Career
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

  • Troubleshooting
  • Research
  • Professional Opinions
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.