In deploying a number of Cisco 2960X Switch Stacks containing between 4 and 8 members I’ve observed the following error message logged:

Failed to send hrpc non blocking message

The issue appeared after upgrading from 15.0(2)EX2 to 15.0(2)EX3 and persists through to 15.0(2)EX5. Following extensive troubleshooting both internally and with Cisco, the problem was narrowed down to the device classifier. Whenever a new MAC is learned the switch will create a new device classifier session and associate a corresponding session ID. This needs to be synchronised across all stack members. Due to issues with the device classifier the switches are unable to maintain this synchronisation.

Cisco released their new ASAv virtual appliance, an updated virtual offering for the ASA platform. I suspect at least part of the driver for this is their work on Cisco Modeling Labs, a new tool to help build and simulate environments.

The ASAv copes well in terms of performance and allows for yet more physical devices to be virtualized, however it only supports VMware environments that make use of vCenter. This leaves those wishing to use the ASAv for their learning, or testing having to setup vCenter. For home labs this is going to eat up more memory and discourage some. Thankfully working around this if fairly straightforward if you have access to a vCenter environment to import and then export the VM from.

I wrote instructions for how to configure Wake On Lan forwarding using a Cisco IOS device, this article will focus on how to configure a Cisco ASA firewall.

Wake On LAN is an Ethernet standard that allows for a device to be powered on when receiving a specially crafted “magic packet”. The “magic packet” is a broadcast frame consisting of 6 bytes of 255 (FF FF FF FF FF FF) followed by sixteen repetitions of the 48-bit MAC address. Turned off computers receiving the broadcast don’t actually process the message up the protocol stack, they are just looking out for a matching 102-byte string.

From what I can tell, unlike Cisco IOS the ASA doesn’t support “IP Directed Broadcasts”, likely to prevent Smurf Attacks. However with some clever NAT rules it’s possible to achieve something similar by using NAT to translate the inbound unicast packet and send it on to the broadcast address for your internal subnet.