Problem on CIsco 7204VXR/NPE400 ==> input errors...

Main Page | Report this Page

Computers Forum Index » Computer - DCOM - Cisco » Problem on CIsco 7204VXR/NPE400 ==> input errors...

Page 1 of 1

Problem on CIsco 7204VXR/NPE400 ==> input errors...

Author

Message

Mag...

Posted: Thu Nov 05, 2009 6:16 am

Guest

Hi

i have a problems with one of my cisco 7204VXR/NPE400:

C7204#sh interfaces gigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is 000c.cf56.6008 (bia
000c.cf56.6008)
Description: Link with C6500
Internet address is xx.xx.xx.xx/30
MTU 1548 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 12/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 14:23:01
Input queue: 0/75/0/1 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 47152000 bits/sec, 6064 packets/sec
5 minute output rate 7602000 bits/sec, 1489 packets/sec
363166224 packets input, 238477403742 bytes, 0 no buffer
Received 20953 broadcasts, 0 runts, 0 giants, 0 throttles
133 input errors, 0 CRC, 0 frame, 24 overrun, 109 ignored
0 watchdog, 20953 multicast, 0 pause input
0 input packets with dribble condition detected
182611031 packets output, 112428021686 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

i have a quantity of:
133 input errors and 109 ignored

And i don't know why. on the Cisco 6500, no errors.

C7204-1.STE01#sh ver
Cisco IOS Software, 7200 Software (C7200-JS-M), Version 12.4(19),
RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Sat 01-Mar-08 04:40 by prod_rel_team

ROM: System Bootstrap, Version 12.2(4r)B2, RELEASE SOFTWARE (fc2)
BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY
DEPLOYMENT RELEASE SOFTWARE (fc1)

C7204 uptime is 45 weeks, 4 days, 19 hours, 56 minutes
System returned to ROM by power-on
System restarted at 09:34:32 UTC Sat Dec 20 2008
System image file is "disk0:c7200-js-mz.124-19.bin"

Cisco 7204VXR (NPE400) processor (revision A) with 491520K/32768K bytes
of memory.
Processor board ID 29812082
R7000 CPU at 350MHz, Implementation 39, Rev 3.3, 256KB L2 Cache
4 slot VXR midplane, Version 2.7

Last reset from power-on

PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth
points.
Current configuration on bus mb0_mb1 has a total of 600 bandwidth points.
This configuration is within the PCI bus capacity and is supported.

PCI bus mb2 (Slots 2, 4, 6) has a capacity of 600 bandwidth points.
Current configuration on bus mb2 has a total of 600 bandwidth points
This configuration is within the PCI bus capacity and is supported.

Please refer to the following document "Cisco 7200 Series Port Adaptor
Hardware Configuration Guidelines" on Cisco.com <http://www.cisco.com>
for c7200 bandwidth points oversubscription and usage guidelines.

1 Ethernet interface
2 FastEthernet interfaces
2 Gigabit Ethernet interfaces
125K bytes of NVRAM.

215040K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102

Not a problems of bandwidth point ...

C7204-1.STE01#sh proc
CPU utilization for five seconds: 13%/12%; one minute: 16%; five
minutes: 15%

not a full charge of the router .....

but i see:

C7204#sh buffers
Buffer elements:
1118 in free list (1119 max allowed)
470134315 hits, 0 misses, 619 created

Public buffer pools:
Small buffers, 104 bytes (total 50, permanent 50, peak 284 at (no spam) 7w0d):
45 in free list (20 min, 150 max allowed)
342390803 hits, 79105 misses, 60160 trims, 60160 created
20208 failures (0 no memory)
Middle buffers, 600 bytes (total 25, permanent 25, peak 391 at (no spam) 7w0d):
21 in free list (10 min, 150 max allowed)
52903004 hits, 34984 misses, 47823 trims, 47823 created
7142 failures (0 no memory)
Big buffers, 1536 bytes (total 50, permanent 50, peak 116 at (no spam) 7w0d):
50 in free list (5 min, 150 max allowed)
83483682 hits, 1234 misses, 1530 trims, 1530 created
570 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 13 at (no spam) 7w0d):
10 in free list (0 min, 100 max allowed)
11025564 hits, 338 misses, 18 trims, 18 created
338 failures (0 no memory)
Large buffers, 5024 bytes (total 1, permanent 0, peak 4 at (no spam) 7w0d):
1 in free list (0 min, 10 max allowed)
20 hits, 318 misses, 2856 trims, 2857 created
318 failures (0 no memory)
Huge buffers, 18024 bytes (total 1, permanent 0, peak 5 at (no spam) 5w6d):
1 in free list (0 min, 4 max allowed)
236 hits, 307 misses, 2854 trims, 2855 created
303 failures (0 no memory)

In "Public buffer pools" a lot of "failures".

i see to:
Big buffers, 1536 bytes (total 50, permanent 50, peak 116 at (no spam) 7w0d):

total= 50
Permanent = 50
and peak at 116

i don't know what is this detail, if i understand, the system want use
in peak 116 and he have only 50 ?

thanks for your help
Mag

Jesper Skriver...

Posted: Thu Nov 05, 2009 1:34 pm

Guest

On Thu, 05 Nov 2009 06:24:06 +0100, Mag wrote:

Quote:

out of 363166224 packets, so < 0.00003% of the packets, nothing to
worry about.

Almost certainly happened because the input queue monentarily ran
full, perhaps because a control plane operation had disabled
forwarding briefly, but the input queue overran.

But with these numbers, nothing to worry aboute.

/Jesper

Gabriele Beltrame...

Posted: Thu Nov 05, 2009 7:25 pm

Guest

"Jesper Skriver" <harvest at (no spam) wheel.dk> ha scritto nel messaggio
news:slrnhf53gc.f09.harvest at (no spam) freesbee.wheel.dk...

Quote:

On Thu, 05 Nov 2009 06:24:06 +0100, Mag wrote:
Hi

i have a problems with one of my cisco 7204VXR/NPE400:

C7204#sh interfaces gigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is 000c.cf56.6008 (bia
000c.cf56.6008)
Description: Link with C6500
Internet address is xx.xx.xx.xx/30
MTU 1548 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 12/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 14:23:01
Input queue: 0/75/0/1 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 47152000 bits/sec, 6064 packets/sec
5 minute output rate 7602000 bits/sec, 1489 packets/sec
363166224 packets input, 238477403742 bytes, 0 no buffer
Received 20953 broadcasts, 0 runts, 0 giants, 0 throttles
133 input errors, 0 CRC, 0 frame, 24 overrun, 109 ignored
0 watchdog, 20953 multicast, 0 pause input
0 input packets with dribble condition detected
182611031 packets output, 112428021686 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

i have a quantity of:
133 input errors and 109 ignored

out of 363166224 packets, so < 0.00003% of the packets, nothing to
worry about.

Almost certainly happened because the input queue monentarily ran
full, perhaps because a control plane operation had disabled
forwarding briefly, but the input queue overran.

But with these numbers, nothing to worry aboute.

/Jesper

Hi,

yes, nothing to worry about.
overruns are usually due to a traffic spike which caused an interface
receive ring buffers exaustion (due to CPU overload).
ignored packets are usually caused by lack of private/public buffers
available to replenish the ring buffers (due to a traffic spike).

Regards,
Gabriele

bod43...

Posted: Sat Nov 07, 2009 12:43 am

Guest

On 5 Nov, 14:25, "Gabriele Beltrame" <bel... at (no spam) drvsource.net> wrote:

Quote:

"Jesper Skriver" <harv... at (no spam) wheel.dk> ha scritto nel messaggionews:slrnhf53gc.f09.harvest at (no spam) freesbee.wheel.dk...

On Thu, 05 Nov 2009 06:24:06 +0100, Mag wrote:
Hi

i have a problems with one of my cisco 7204VXR/NPE400:

C7204#sh interfaces gigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is 000c.cf56.6008 (bia
000c.cf56.6008)
Description: Link with C6500
Internet address is xx.xx.xx.xx/30
MTU 1548 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 12/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 14:23:01
Input queue: 0/75/0/1 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 47152000 bits/sec, 6064 packets/sec
5 minute output rate 7602000 bits/sec, 1489 packets/sec
363166224 packets input, 238477403742 bytes, 0 no buffer
Received 20953 broadcasts, 0 runts, 0 giants, 0 throttles
133 input errors, 0 CRC, 0 frame, 24 overrun, 109 ignored
0 watchdog, 20953 multicast, 0 pause input
0 input packets with dribble condition detected
182611031 packets output, 112428021686 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

i have a quantity of:
133 input errors and 109 ignored

out of 363166224 packets, so < 0.00003% of the packets, nothing to
worry about.

Almost certainly happened because the input queue monentarily ran
full, perhaps because a control plane operation had disabled
forwarding briefly, but the input queue overran.

But with these numbers, nothing to worry aboute.

/Jesper

Hi,

yes, nothing to worry about.
overruns are usually due to a traffic spike which caused an interface
receive ring buffers exaustion (due to CPU overload).
ignored packets are usually caused by lack of private/public buffers
available to replenish the ring buffers (due to a traffic spike).

I agree that this error rate is low. No point in
concering yourself with it.

Ignored are a result of the CPU being too busy.

On traditional Ethernet (10Mbps) overruns are as I
recall the receipt of additional bits after the frame has finished.
Of course with GBE we no longer use bits but symbols
using 10B/8B encoding. I guess it is the result of some
signalling errors of some kind.

Not quite sure what it means on GBE . The IEEE may well
have 802.3z and 802.3ab available for free download. If not
you can always consider paying:-)

7204VXR is quite likely pretty stressed by wire rate GBE.
A few drops are to be expected.

Page 1 of 1

All times are GMT The time now is Sun Nov 22, 2009 9:52 am Computers Forum Index