12-27-2007 07:24 PM - edited 03-05-2019 08:11 PM
Hi,
I have encounter one unusual case. I have one PC that is connected to one IP phone. This PC is working fine but the IP phone is not working.
The strange part is the IP phone may disconnected itself and would display "IP Configuring". Then it will auto-recover itself around 30 to 50 minutes. The problem is it will auto shutdown and auto recover and the time is unknown. I tried using my labtop but is tested fine and the IP phone is working.
Is there any way to solve the problem? What is the root cause of this problem? Why the data rate will exceed only at some part of the day? I have tried changing the switch ports and cables. However, the problem still persist. Below is the configuration, log and commands that i use to check.
interface FastEthernet/x
switchport access vlan y
switchport mode access
switchport voice vlan z
switchport port-security maximum 3
switchport port-security
switchport port-security aging time 5
switchport port-security violation restrict
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
macro description staff
auto qos voip cisco-phone
storm-control broadcast level 20.00 10.00
storm-control multicast level 20.00 10.00
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
ip verify source
ip dhcp snooping limit rate 15
end
%SW_DAI-4-PACKET_RATE_EXCEEDED: 16 packets received in 0 milliseconds on Fa/x. (SWITCH-A)
%PM-4-ERR_DISABLE: arp-inspection error detected on Fa/x, putting Fa/x in err-disable state (SWITCH-A)
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet/x, changed state to down
%LINK-3-UPDOWN: Interface FastEthernet/x, changed state to down
%SWITCH_QOS_TB-5-TRUST_DEVICE_LOST: cisco-phone no longer detected on port Fa/x, port set to untrusted.
-----------------------
-----------------------
%PM-4-ERR_RECOVER: Attempting to recover from arp-inspection err-disable state on Fa/x (SWITCH-A)
%SWITCH_QOS_TB-5-TRUST_DEVICE_DETECTED: cisco-phone detected on port Fa/x, port trust enabled.
%LINK-3-UPDOWN: Interface FastEthernet/x, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet/x, changed state to up
SWITCH-A# sh ip verify source interface fa/x
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- ----------------- ----------
Fa/x ip active zzz.zzz.zzz.zzz z
Fa/x ip active yyy.yyy.yyy.yyy y
SWITCH-A#sh ip dhcp snooping binding interface fa/x
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
zz:zz:zz:zz:zz:zz zzz.zzz.zzz.zzz 12708 dhcp-snooping z FastEthernet/x
yy:yy:yy:yy:yy:yy yyy.yyy.yyy.yyy 12966 dhcp-snooping y FastEthernet/x
Total number of bindings: 2
12-27-2007 07:33 PM
What is the reason why this port will receive more dhcp snooping packets than other ports?
Thanks!
The interface is:
SWITCH-A# sh int fa/x
FastEthernet/x is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is cccc.cccc.cccc (bia cccc.cccc.cccc)
MTU 1500 bytes, BW 100000 Kbit, 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/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:46, output 00:00:48, output hang never
Last clearing of "show interface" counters 1w6d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 56000 bits/sec, 39 packets/sec
895932 packets input, 162867066 bytes, 0 no buffer
Received 30623 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 22537 multicast, 0 pause input
0 input packets with dribble condition detected
26991774 packets output, 2986231512 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide