Unsolved
This post is more than 5 years old
4 Posts
0
29298
December 16th, 2014 08:00
Power connect 6224 stack problem
Hi Guys,
I have similar problem as andycrisp had in subject ' Issues with 4 stacked 6248's '. I have 2 stacked switches 6224. Normally everything works fine. But during peak I can't log in to switch in any way but console cable. Pining from any part of network works awful, which means any one of the 15 pings reaches destination. When network stabilize everything works perfect. Both stuck switches run firmware 3.3.9.1 In logs I can see only repeating all the time error :
DEC 16 10:52:18 10.10.10.2-2 DNS_CLIEN[217288320]: dns_client_txrx.c(371)
612 %% DNS Client: osapiSocketRecvFrom returned error for addr 0xCF38D90. Indica
tes there is a stack error in receiving the DNS response packet from the server.
Which is strange cause configured DNS server is different.
I would be grateful for any suggestions.
Cheers!
Pawel


paw_kol
4 Posts
0
December 18th, 2014 00:00
Hi Daniel,
Yeah I should add it from begining:
SESW002#show cp process cpu
Memory Utilization Report
status bytes
------ ----------
free 26385488
alloc 188344160
CPU Utilization:
PID Name 5 Sec 1 Min 5 Min
---------------------------------------------------------
3374cd0 tNetTask 0.00% 0.02% 0.01%
35611b0 ipnetd 0.00% 0.02% 0.00%
3573750 tXbdService 0.00% 0.04% 0.36%
358e790 osapiTimer 0.79% 1.07% 0.96%
3680060 bcmL2X.0 0.15% 0.21% 0.30%
36af160 bcmCNTR.0 0.15% 0.37% 0.17%
3cbfc40 bcmRX 1.74% 1.61% 1.85%
3cdfe30 bcmNHOP 0.00% 0.04% 0.01%
3cf2180 bcmATP-TX 0.00% 0.04% 0.02%
--More-- or (q)uit
3cfb680 bcmATP-RX 0.00% 0.00% 0.01%
3ef5e70 MAC Send Task 0.47% 0.42% 0.45%
3eff370 MAC Age Task 0.15% 0.07% 0.01%
4a7f1c0 bcmLINK.0 0.47% 0.36% 0.27%
5180350 tL7Timer0 0.00% 0.02% 0.15%
51a5c30 osapiMonTask 0.00% 0.00% 0.09%
5e94860 simPts_task 0.00% 0.07% 0.15%
62c8e50 dtlTask 0.95% 0.91% 0.85%
6323400 hapiBpduTxTask 0.00% 0.06% 0.00%
6331740 hapiRxTask 0.31% 0.52% 0.64%
637f1d0 tEmWeb 0.00% 0.04% 0.01%
697b520 DHCP snoop 0.00% 0.04% 0.00%
6a11a30 Dynamic ARP Inspection 0.00% 0.02% 0.00%
76533b0 dot1s_timer_task 0.47% 0.40% 0.61%
76661a0 dot1s_task 0.00% 0.02% 0.00%
848b160 unitMgrTask 0.15% 0.07% 0.00%
862be10 snoopTask 0.00% 0.05% 0.04%
9564f50 spmTask 0.00% 0.06% 0.00%
95ed280 ipMapForwardingTask 1.11% 0.66% 0.60%
9a9cb50 VRRPdaemon 0.15% 0.06% 0.02%
9aeb960 IpHelperTask 0.00% 0.02% 0.15%
9afd740 tRtrDiscProcessingTask 0.00% 0.02% 0.00%
a239040 mgmdMapTask 0.00% 0.00% 0.15%
--More-- or (q)uit
ca88a70 ip6MapLocalDataTask 0.00% 0.02% 0.00%
ca9b4d0 ip6MapNbrDiscTask 0.00% 0.02% 0.00%
cbdcc20 lldpTask 0.00% 0.27% 0.14%
d8bde50 isdpTask 0.31% 0.14% 0.05%
e0bfd40 RMONTask 0.15% 0.09% 0.30%
e0cbfe0 boxs Req 0.15% 0.08% 0.15%
---------------------------------------------------------
Total CPU Utilization 7.67% 7.93% 8.52%
SESW002#show memory cpu
Total Memory................................... 262144 KBytes
Available Memory Space......................... 25767 KBytes
Regarding to counters only different thing I found is :
SESW002#show interfaces counters ethernet 1/g2
Port InOctets InUcastPkts InMcastPkts InBcastPkts
---------------- ---------- ----------- ----------- -----------
1/g2 1727155014124 1390998377 55969235 2113202
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
---------------- ---------- ------------ ------------ ------------
1/g2 715018722864 878169439 2777606 889673
FCS Errors: ................................... 0
Single Collision Frames: ...................... 0
Late Collisions: .............................. 0
Excessive Collisions: ......................... 0
Multiple Collisions: .......................... 0
Oversize Packets: ............................. 1042611377
Internal MAC Rx Errors: ....................... 0
Received Pause Frames: ........................ 0
Transmitted Pause Frames: ..................... 0
Receive Packets Discarded: .................... 1388
Transmit Packets Discarded: ................... 112019
But as far as I know it is nothing which we should concern as long as bcmRX process is around 1%
SESW002#show interfaces counters ethernet 1/xg3
Port InOctets InUcastPkts InMcastPkts InBcastPkts
---------------- ---------- ----------- ----------- -----------
1/xg3 29637975089 88668861 553371 541833
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
---------------- ---------- ------------ ------------ ------------
1/xg3 87041284194 106072182 2063816 1089896
FCS Errors: ................................... 0
Single Collision Frames: ...................... 0
Late Collisions: .............................. 0
Excessive Collisions: ......................... 0
Multiple Collisions: .......................... 0
Oversize Packets: ............................. 0
Internal MAC Rx Errors: ....................... 0
Received Pause Frames: ........................ 1413689
Transmitted Pause Frames: ..................... 0
Receive Packets Discarded: .................... 584
Transmit Packets Discarded: ................... 20
Pause frames comes cause port on second switch has smaller bandwidth set
Regarding time, problem which I mentoined intensify during office hours.
And what does :
DEC 16 10:52:18 10.10.10.2-2 DNS_CLIEN[217288320]: dns_client_txrx.c(371)
612 %% DNS Client: osapiSocketRecvFrom returned error for addr 0xCF38D90. Indica
tes there is a stack error in receiving the DNS response packet from the server.
notification means?
Any suggestions?
Cheers!
Pawel
paw_kol
4 Posts
0
January 13th, 2015 14:00
Hi again,
Sorry for late answer. Yes, all output has been colleted while issue has been occuring. 1/g2 is connected to other 6224 switch which is connected to inter alia Vmware server farm, but to be honnest I do not think it can caused the problem(bcmRX process is around 2%).
Any suggestions?
Cheers
Pawel
paw_kol
4 Posts
0
January 21st, 2015 06:00
Hi Daniel,
I've just upgraded firmware:
image1 : default image
image2 :
Images currently available on Flash
--------------------------------------------------------------------
unit image1 image2 current-active next-active
--------------------------------------------------------------------
1 3.3.12.1 3.3.9.1 image1 image1
2 3.3.12.1 3.3.9.1 image1 image1
I did failover (just to be sure I procedure for failover was:
Switch(config-stack)# initiate failover
Unfortunately problem still exist.
Regards