Tech Blog

Restart a single context on an ASA with virtual instances

The Cisco ASA firewall can run as virtual host for multiple virtual ASA’s known as contexts.  We recently ran into an issue where a memory leak made one context inoperable.  Rather than reload the entire ASA and take out the other contexts we wanted to only restart the context that was having problems.  Unfortunately there is no way to reboot an individual context as the reload command does not exist inside a context.  The solution is to delete the context and recreate it.  This may sound daunting, but it takes a few seconds and your config is restored. read more…

Troubleshoot Ruckus AP not connecting to Virtual SmartZone cloud controller

Here are a list of things to troubleshoot when a Ruckus AP is not registering to a Virtual SmartZone (VSZ) cloud controller.

  1. Ensure that the public IP address of the site where the AP resides is permitted through the firewall protecting the VSZ.
  2. Check that the AP has a valid private IP address and is pingable from the router at that site.
  3. SSH into the AP.  default credentials are super/sp-admin).  If those credentials don’t work then the AP has received its config from the controller and the zone credentials must be used.

read more…

Upgrading IOS-XE firmware on a 4000 series router

Had an issue where I was not able to successfully upgrade the IOS firmware on a Cisco 4351 router.  This model of router runs IOS-XE and has some slight differences in feature set compared to legacy IOS.  For example “ip dns server” was not an available command in the version the customer was running and so we needed to upgrade to the latest version which had support for running a DNS server.

I had uploaded the firmware (which was a whopping 470MB) to the flash and then entered in:

boot system flash isr4300-universalk9.03.16.00c.S.155-3.S0c-ext.SPA.bin

I then saved and rebooted the device, but the old firmware was still loaded.  I discovered that the proper syntax for this series of router needs to be:

boot system bootflash:/isr4300-universalk9.03.16.00c.S.155-3.S0c-ext.SPA.bin

After a save and reboot we were on the new firmware and sure enough “ip dns server” was now a supported command.

Barracuda ADC Load Balancer – How to show client IPs and not the proxy IP address – Part 2

In my first post on showing the client IP addresses through a Barracuda ADC load balancer, I showed how to get Direct Server Return to work for clients on the same network by adding loopback interfaces on the back-end servers.  In this post I will discuss a problem when using a layer 7 proxy service with Client Impersonation enabled on a multi-homed ADC.

One of the requirements for client impersonation is that the back-end servers must use an ADC IP address as the default gateway.  In traditional two-armed deployments where the real servers sit behind the ADC this is not a problem.  However when the network is more complex and the ADC has interfaces in different networks and both VIPs and real servers sit on each of these networks then there can be some unexpected behaviors when it comes to the routing of packets. read more…

Barracuda ADC Load Balancer – How to show client IPs and not the proxy IP address – Part 1

In order to see the client origination IP address on the real back-end servers when a Barracuda ADC load balancer is used there are two options.  The first is to use layer 4 load balancing on the service type.  The other option is to use a layer 7 proxy service and enable client impersonation (while setting the default gateway to the ADC - but this causes other problems that I’ve discussed in part 2 of this post).  Both of these options work ok for clients outside of the back-end server network, but these do not work if the clients are in the same layer 2 network.  (For example if your virtual IP is and the back-end servers are, and your client is, then neither of these options will work).  This is because when the back-end server sees that the IP address is on the same network, it will not send the return packets back through the Barracuda ADC, but rather straight to the client and thus break the TCP stream. read more…

Speed up mailbox migration to Exchange 2013 – They’re too slow!

Moving mailboxes from Exchange 2007 or 2010 to Exchange 2013 can often go very slowly, even when the network and server resources are fast and abundant!  The Exchange Mailbox Replication Service (MRS) has extensive resource throttling enabled by default in order to prevent mailbox moves from choking out the rest of the users.  Because of this you may see mailboxes with a status of RelinquishedWlmStall and if you look at the details of the Get-MoveRequestStatistics report you will see mailboxes have a lot of time sitting idle under the TotalStalledDueToWriteThrottle counter.

Mailbox Move Stall

read more…