01-16-2019 07:01 PM - edited 03-08-2019 05:03 PM
Hello everyone,
We have a cisco 3850 which version is 03.07.04.E
I have found that the delay is so high when I telnet 10.80.1.241 . And I knock to command being delay.But at the same time other switches' delay is normal except 10.80.1.241 . after a while it recovery to normal.
ping form switch:
c3560#ping 10.80.1.241
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.80.1.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/142/218 ms
c3560#ping 10.80.1.242
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.80.1.242, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms
Abnormal:
C:\>ping 10.80.1.241
Pinging 10.80.1.241 with 32 bytes of data:
Reply from 10.80.1.241: bytes=32 time=85ms TTL=255
Reply from 10.80.1.241: bytes=32 time=47ms TTL=255
Reply from 10.80.1.241: bytes=32 time=124ms TTL=255
Reply from 10.80.1.241: bytes=32 time=22ms TTL=255
Ping statistics for 10.80.1.241:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 124ms, Average = 69ms
Normal:
C:\>ping 10.80.1.241
Pinging 10.80.1.241 with 32 bytes of data:
Reply from 10.80.1.241: bytes=32 time=1ms TTL=255
Reply from 10.80.1.241: bytes=32 time=2ms TTL=255
Reply from 10.80.1.241: bytes=32 time=2ms TTL=255
Reply from 10.80.1.241: bytes=32 time=1ms TTL=255
Ping statistics for 10.80.1.241:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms
I think the circuit is normal and the C3850 seem to normal too ,because other functions work properly.
I would appreciate any help.
Thanks you
Solved! Go to Solution.
01-16-2019 08:01 PM
Have you checked the processor while it was delayed? If not, please look at the output of show proc cpu history. We were having similar issue recently with 3850s, a stack of 7, and the cpu utilization was close to 100% at the time we experience the delay and some packet drops. The main processes which were consuming most of the cpu were SISF Switcher Thread and SISF Main Thread. The processor load usually goes away when we either disabled dhcp snooping completely (removed all dhcp snooping related commands from the switch) or did limit the dhcp snooping to one vlan (eg. ip dhcp snooping vlan 2).
HTH,
Meheretab
01-16-2019 07:26 PM
Hi @tianwen.zha,
You could make a trace to the addresses you show to verify the path the packets take to the destinations.
Regards
01-16-2019 11:25 PM
01-16-2019 08:01 PM
Have you checked the processor while it was delayed? If not, please look at the output of show proc cpu history. We were having similar issue recently with 3850s, a stack of 7, and the cpu utilization was close to 100% at the time we experience the delay and some packet drops. The main processes which were consuming most of the cpu were SISF Switcher Thread and SISF Main Thread. The processor load usually goes away when we either disabled dhcp snooping completely (removed all dhcp snooping related commands from the switch) or did limit the dhcp snooping to one vlan (eg. ip dhcp snooping vlan 2).
HTH,
Meheretab
01-17-2019 12:51 AM
01-17-2019 01:51 AM
Hello,
on a side note, what is the uptime of the switch (sh ver) ? Sometimes long uptimes (>1 year) can cause devices to respond slowly...
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