Messages

I don't know why people put off getting the packet capture... it's going to work, it's going to solve the problem, it's going to be the best thing you do all day. So why waste time with anything else?

I submit that the people that don't go directly to setting up a capture are either just being lazy, don't know how to do it, or are a combination of the two.

Lazy I can't help.

Not knowing how to do it? Google up "tcpdump", load Wireshark, and get busy.

Just had a case yesterday, lots of finger pointing, everybody blaming everyone else. The arguing had been going on for HOURS. I got parachuted in and asked the question, "What does the packet capture show?"

Silence.

Next thing I said was, "Get the packet capture on the server and it will show if there's any attempt to connect with the remote host."

They got the packet capture.

One hour later, they had the fix in place. 

If they had gone for the capture instead of the political posturing bullcrap, they would have had the fix, less arguing, and no need to make everyone mad with accusatory finger-pointing.

Evidence based assessment? Blasphemy!!! 

are you sure it was a bit flip or was that a random guess by a TAC guy wanting to close it out?

I still have the SP and RP crashfiles... here are the relevant bits from the SP crashfile:

Code Select Expand

Cache error detected!
  CPO_ECC     (reg 26/0): 0x00000089
  CPO_CACHERI (reg 27/0): 0xA0000000
  CP0_CAUSE   (reg 13/0): 0x00001C00

Real cache error detected.  System will be halted.

Error: Primary data cache, fields: data,
Actual physical addr 0x00000000,
virtual address is imprecise.

Imprecise Data Parity Error

Imprecise Data Parity Error

08:58:20 PDT Wed Jul 13 2011: Interrupt exception, CPU signal 20, PC = 0x40FEA860



--------------------------------------------------------------------
   Possible software fault. Upon reccurence, please collect
   crashinfo, "show tech" and contact Cisco Technical Support.
--------------------------------------------------------------------


-Traceback= 417BEE50
$0 : 00000000, AT : 42640000, v0 : 52D11A90, v1 : 45BF04F8
a0 : 52D11AC4, a1 : 52D44E3C, a2 : 40FEA848, a3 : 52D44E3C
t0 : 408B5698, t1 : 3400FF01, t2 : 3400F100, t3 : FFFF00FF
t4 : 417B13A8, t5 : 0000FFFF, t6 : 00000004, t7 : 0000030D
s0 : 52D44E3C, s1 : 00000002, s2 : 40FEA848, s3 : 52D44E3C
s4 : 43ECEF90, s5 : 00000004, s6 : 00000000, s7 : EFFFFFFA
t8 : 55BB5088, t9 : 00000000, k0 : 55B8DC94, k1 : 408EAE50
gp : 42647238, sp : 52D44D90, s8 : 9FBF04BE, ra : 40FEA860
EPC  : 417BEE50, ErrorEPC : 40FEA860, SREG     : 3400FF05
MDLO : 3B13B68E, MDHI     : 00000719, BadVaddr : 00000000
DATA_START : 0x42322420
Cause 00000000 (Code 0x0): Interrupt exception



The SP crash forced the RP to reload and then all hell broke loose....   more info

How is it possible when Cisco equipment uses ECC memory?

I can't answer that question but we have seen the parity errors on a Catalyst 6807, twice.

We have ~700 switches on campus. 2960G, 2960S, 3560G, 3560E, 3750E, 3750X, 3850.

My experience has been that 12.2(55) is a solid release.

15.0 is good for SOME models, like 2960S and 3750X.

15.0 locked us out of SSH on several of our 2960G, memory leak.