Problem with Undersized Packets on 3560G

[texnut]

Hello all,

We are having some odd issues on our 3560G. I've tried everything I can think of to trouble shoot this issue, so any advice is much appreciated.

It's a little odd, so let me start off by showing you the architecture:

1721 Router <-> 2950 Switch (external switch) <-> PIX506 <-> 3560G Switch (internal switch) <-> rest of network ...

Everything from the router all the way down to the 3560G is set to 100Full.

All the interface couters suggest absoultly NO errors what-so-ever (all runts, giants, etc are Zero) however when I look at the switch via the Cisco Network Assistant and graph the "Link State, Packet Drops & Errors" for the port that connects to the PIX (G0/1), I get a steady flow of Errors. Looking at the counters via the GUI suggests these are all Received Undersized Packets.

Looking at the counters via the console suggestes no errors at all!

Also, performance on the network doesn't seem to be affected.

Any thoughts on tracking this down? I've even changed the cables incase that was the problem, but it didn't help.

Thanks all,

S

 

[vipergg]

Sounds like a software bug if you are seeing with one tool and not the other . Never have liked the gui so I can't speak to that . I wouldn't spend a lot of time on it if net performance isn't being affected . You could check for bugs on cisco's website.

 

[ADB100]

There is a known software bug that records frames between 64 and 67 bytes long as undersized on 802.1q VLAN Trunks and access ports using Voice VLANs.

For trunk ports or access ports configured with 802.1Q tagging, inconsistent statistics might appear in the show interfaces counters privileged EXEC command output. Valid 802.1Q frames of 64 to 66 bytes are correctly forwarded even though the port LED blinks amber, and the frames are not counted on the interface statistics. There is no workaround. (CSCec35100).

If you issue the command 'show interface counters errors' and you have anything in the Undersize column you are probably seeing this issue, it is however cosmetic and doesn't affect the forwarding of the switch.

It has been resolved in later IOS releases, the most current is 12.2(37)SE1 and is free as long as you don't attempt to change the feature set (i.e. go from IP Base to IP Services etc).

HTH

Andy

 

[texnut]

Guys - thanks a million. I actually feel better knowing that it's a software bug. I'm going to go ahead and get the latest release of the software - we are currently running 12.2(25)SEE2-IP-BASE.

Thanks!

 

[burtsbees]

I thought that you could raise the MTU for this issue---have you tried doing an extended ping from the PIX to the switch? I don't know if it is the same in a PIX, but in Cisco routers, you can type
router#ping
for an extended ping, and for extended commands, select yes, validate data reply and data pattern, accept the defaults (just hit return), and set df bit in IP header, select yes---this is the "don't fragment" option, and is used for testing MTU on interfaces. Also, for Loose, Strict, Record, Timestamp, Verbose, select r, sweep ranges of sizes---yes, min size of 500, max of 2000, and interval of 500. Then it will ping, and when the MTU is discovered, it will report "unreachable", and say what the MTU of the path to the destination IP address you select in the beginning is.

Burt

 

[ADB100]

Burt

The bug is a cosmetic one that is only applicable to received 802.1q frames. If a valid frame is received on a trunk and it is between 64 and 67 bytes long it gets incorrectly flagged as undersized, however the switch forwards the packet correctly.

I did think 12.2(25)SEE2 contained the fix, however I could be wrong?

Andy

 

[texnut]

Not sure really - I've downloaded the new image but haven't applied it yet.

Although, all the symptoms fall on our config - i.e. we are using that port as a trunk port w/ 802.1q frames.

Over the weekend I will apply the update and see if it fixes things.

Thanks all