cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3129
Views
0
Helpful
12
Replies

Error on interfaces in cisco WS-C3650-24PS

dvecherkin1
Level 1
Level 1

Hello.

I have cisco WS-C3650-24PS and the IP-phones connected to  cisco, also we have computers which connected through IP-phone.  Cisco show errors in these ports - 12 and 15. However on other ports we don't have problems. Look errors in the attachments .

Help me solve the issue. How I can catch the problem and fix.

License Level: Ipbase
License Type: Permanent
Next reload license Level: Ipbase
cisco WS-C3650-24PS (MIPS) processor with 4194304K bytes of physical memory.
Processor board ID FDO2049E28A
1 Virtual Ethernet interface
28 Gigabit Ethernet interfaces
2048K bytes of non-volatile configuration memory.
4194304K bytes of physical memory.
252000K bytes of Crash Files at crashinfo:.
1611414K bytes of Flash at flash:.
0K bytes of Dummy USB Flash at usbflash0:.
0K bytes of at webui:.
Base Ethernet MAC Address : 08:96:ad:86:2b:80
Motherboard Assembly Number : 73-15899-06
Motherboard Serial Number : FDO20500BV5
Model Revision Number : P0
Motherboard Revision Number : A0
Model Number : WS-C3650-24PS
System Serial Number : FDO2049E28A

Switch Ports Model SW Version SW Image Mode
------ ----- ----- ---------- ---------- ----
* 1 28 WS-C3650-24PS 03.06.06E cat3k_caa-universalk9 INSTALL

____________________

12 Replies 12

nurbol555
Level 1
Level 1

what kind of errors is it? Pls show your logs

You can see it in the attachments in first post.

Mark Malone
VIP Alumni
VIP Alumni

Hi

Common Causes: A common cause of Xmit-Err can be traffic from a high bandwidth link that is switched to a lower bandwidth link, or traffic from multiple inbound links that are switched to a single outbound link. For example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a 100Mbps interface, this can cause Xmit-Err to increment on the 100Mbps interface. This is because the output buffer of the interface is overwhelmed by the excess traffic due to the speed mismatch between the inbound and outbound bandwidths.

are you using any form of qos on the switch

if its not effecting the traffic or user I would leave it as the fix for this is altering buffers or tweaking qos which could actually introduce real issues to the switch 

can you post the actual show interface from port 12 and 16 .. show interface x/x

interface GigabitEthernet1/0/16
switchport mode access
switchport voice vlan 1
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
switchport port-security
trust device cisco-phone
auto qos voip cisco-phone
macro description cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input AutoQos-4.0-CiscoPhone-Input-Policy
service-policy output AutoQos-4.0-Output-Policy
interface GigabitEthernet1/0/16
switchport voice vlan 1
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
switchport port-security
trust device cisco-phone
auto qos voip cisco-phone
macro description cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input AutoQos-4.0-CiscoPhone-Input-Policy
service-policy output AutoQos-4.0-Output-Policy

Hi

that's the running config , the actual command .... show interface g1/0/16

it will show if there are any errors you should be worrying about

show interface g1/0/16
GigabitEthernet1/0/16 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 0896.ad86.2b90 (bia 0896.ad86.2b90)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:40, output never, output hang never
Last clearing of "show interface" counters 00:04:58
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 7000 bits/sec, 7 packets/sec
40 packets input, 4400 bytes, 0 no buffer
Received 10 broadcasts (10 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 10 multicast, 0 pause input
0 input packets with dribble condition detected
3404 packets output, 430827 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

That interface is clean I wouldn't worry about those xmits , you don't even have any output drops

 why is the port 100mb is that all the phones can do ,are the pcs 1GB nics , if the phones can do gig set speed 1000 dup full , that's why you could be seeing xmits  1000-100mb -1000 , low link in the middle

We have Cisco IP Phone 7911G. Speed  - 100 Мb.

Statistic from phone:

Rx totalPkt 01662614
Rx crcErr 00000000
Rx alignErr 00000000
Rx multicast 00370585
Rx broadcast 00268106
Rx unicast 01023923
Rx shortErr 00000000
Rx shortGood 00000000
Rx longGood 00000000
Rx longErr 00000000
Rx size64 00937920
Rx size65to127 00394659
Rx size128to255 00544729
Rx size256to511 00309228
Rx size512to1023 00094866
Rx size1024to1518 00449620
Rx tokenDrop 00000000
Tx excessDefer 00000000
Tx lateCollision 00000000
Tx totalGoodPkt 01068408
Tx Collisions 00000000
Tx excessLength 00000000
Tx broadcast 00042943
Tx multicast 00029491
LLDP FramesOutTotal 00002663
LLDP AgeoutsTotal 00000000
LLDP FramesDiscardedTotal 00000000
LLDP FramesInErrorsTotal 00000000
LLDP FramesInTotal 00000000
LLDP TLVDiscardedTotal 00000000
LLDP TLVUnrecognizedTotal 00000000
CDP IP 10.82.130.7
CDP GigabitEthernet1/0/12

show interface g1/0/12
GigabitEthernet1/0/12 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 0896.ad86.2b8c (bia 0896.ad86.2b8c)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:57, output never, output hang never
Last clearing of "show interface" counters 00:05:13
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
5 minute input rate 49000 bits/sec, 18 packets/sec
5 minute output rate 268000 bits/sec, 37 packets/sec
7929 packets input, 2296696 bytes, 0 no buffer
Received 173 broadcasts (83 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 83 multicast, 0 pause input
0 input packets with dribble condition detected
14391 packets output, 13225063 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

But now we have errors on port 12
sh int gi 1/0/12
GigabitEthernet1/0/12 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 0896.ad86.2b8c (bia 0896.ad86.2b8c)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:42, output never, output hang never
Last clearing of "show interface" counters 01:04:59
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 67908
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
5 minute input rate 18000 bits/sec, 7 packets/sec
5 minute output rate 132000 bits/sec, 21 packets/sec
59319 packets input, 10737029 bytes, 0 no buffer
Received 2232 broadcasts (1041 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1041 multicast, 0 pause input
0 input packets with dribble condition detected
107380 packets output, 78082512 bytes, 0 underruns
67908 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

queue on port 12

Class-map: class-default (match-any)
0 packets
Match: any
Queueing
(total drops) 67908
(bytes output) 77817136
bandwidth remaining 25%
queue-buffers ratio 25

Yes output errors are a problem alright

The most likely cause of a large output errors number is that you are overrunning the output queue. Description: Cisco IOS sh interfaces counter. The sum of all errors that prevented the final transmission of datagrams out of the interface. Common Cause: This issue is due to the low Output Queue size.

Total output drops is the number of packets dropped because the output queue is full. A common cause of this might be traffic from a high bandwidth link being switched to a lower bandwidth link or traffic from multiple inbound links being switched to a single outbound link. For example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a 100Mbps interface, this might cause output drops to increment on the 100Mbps interface. This is because the output queue on that interface is overwhelmed by the excess traffic due to the speed mismatch between the inbound and outbound bandwidths.

BUT I would not touch the output queue to fix output errors its not recommended as all your doing is causing more traffic to be held causing latency per port , personally I would remove the qos from the port , clear the counters and see if the issue is still occurring , qos can cause as many issues as it fixes at layer 2

if that does not work you will need to look at tweaking the qos but that can be an issue as its auto qos

Hello!

We  disabled queue on interfaces, but errors don't disappear.

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 1785817
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 6000 bits/sec, 4 packets/sec
5 minute output rate 95000 bits/sec, 10 packets/sec
1286272 packets input, 310303215 bytes, 0 no buffer
Received 93811 broadcasts (30808 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 30808 multicast, 0 pause input
0 input packets with dribble condition detected
1681579 packets output, 605947120 bytes, 0 underruns
1785817 output errors, 0 collisions, 0 interface resets

Have you any ideas?

Review Cisco Networking for a $25 gift card