I had a strange error on a new ASA where doing tracert to a host returned the correct number of hops, but always displayed the destination host at each hop. Adding inspect icmp error fixed it right up.
inspect icmp error
via Issue with Traceroute with Cisco ASA’s | Firewalling | Cisco Support Community | 5966 | 12628436.
I’ve run into a nasty bug in the latest Kaspersky Antivirus. It seems to kill any Jabber calls. After a couple minutes, Jabber won’t be able to make any calls. It just dead air.
I have commented on a couple forum posts but I haven’t found any definitive fix other than uninstalling Kaspersky.
I’m using KES10 (10.2.4.674) with SP1 MR2 on Win8.1 (x64) and Win10 (x64). And I’ve tried several versions of Jabber:
It’s really annoying. At least, Win7 x86 doesn’t seem to be affected by this bug.
Update 2016-03-14: It looks like it’s related to the Kaspersky Network filter driver klwfp.sys. After disabling system protection, renaming that driver, and rebooting, Jabber works after the two minute mark.
Update 2016-04-08: Kaspersky contacted me today. I am currently testing out a new driver for them and it seems to be working. I’ll need to do more testing on Monday, but so far so good. (knock on wood)
Update 2016-04-12: The fix worked and I learned that once you get used to hands-free calling with Jabber it’s very difficult to go back to a regular phone.
I noticed that my Cisco Jabber became very laggy when typing and sending chat messages. A little google-fu found this page from Cisco. Apparently Microsoft’s KB3038314 is the cause of it. I uninstalled the KB and Jabber is back to it’s snappy self. I’m running the latest version of Jabber (10.6.3) and I hope that Cisco can get around this in the next version.
Update: It looks like the lag is fixed in v10.6.4 build 63238.
I had a switching loop the other day. Nasty and annoying business. It didn’t bring the network down, but it was quite disruptive. Our switches had bpduguard enabled and this did prevent the switching loop, but the switches also had some errdisable recovery options enabled as well. So, after the switching loop was detected and the ports disabled to save the network (yay!), the ports were reenabled 60 seconds later, thus causing another loop and causing the ports to be disabled.
The loops existed just long enough to cause an issue then disappear. Like I said… quite annoying.
Here are the errdisable options I removed from our switches:
no errdisable recovery cause bpduguard
no errdisable recovery cause link-flap
no errdisable recovery interval 60
Once I removed the errdisable options the ports stayed in an errdisable state and the loop cleared up. The user was forced to call into the Help Desk and the issue was resolved.
Now I’m brushing up on my Spanning Tree Protocol and I have a couple good things to note:
spanning-tree portfast does not disable STP on that port. This is how bpduguard still functions. You can have portfast on your access ports and still sleep easy at night.
- I’m liking
spanning-tree portfast bpduguard default much more after this little looping incident. This is a global command and will enable bpduguard on all portfast ports.
I had a dozen Cisco 3560 switches I needed to wipe, but I couldn’t give the intern the password to the switches. These steps let the intern wipe the switches quickly and easily.
- Boot up the switch.
- Hold the Mode button for a few seconds. The LEDs will blink then go solid. Let go of the button and the switch will reboot with a blank config. The original configs will be renamed and backed up on flash.
- Skip the Initial Configuration dialog then run the regular commands to wipe the switch.
Switch# write erase
Switch# delete flash:vlan.txt.renamed
To reload a specific switch in Cisco stack (n is the switch number):
reload slot n