Sometimes it’s necessary to quickly shape some problem traffic rather than flat out deny it. We can use an acl, class map and policy map along with a relevant bandwidth statement for this. Typically this can be put in to stop a particular service consuming all the bandwidth on a non-QoS link.
Example: Shape ssh/scp/sftp traffic from 10.0.0.0/24 to 192.168.0.100 down to 15 percent of the link bandwidth (in this case 1.5mbps – 15% of 10Mbit/sec)
ip access-list extended ACL-Shaping
permit tcp 10.0.0.0 255.255.255.0 host 192.168.0.100 eq 22
class-map match-any Shaped-Applications
description -= Shape Appplications that are eating bandwidth! =-
match access-group name ACL-Shaping
shape average percent 15
service-policy output shaping-policy
Bear in mind that you should shape closest to the source, and also bear in mind that you need to set up the ACL in the correct direction, which may not be immediately obvious. EG: for HTTP downloads, you’ll have to set up the acl to be like:
permit tcp host [server IP] eq 80 [destination subnet] [destination mask]
And apply that acl on the server side router on the port outbound to the client.
NNMi9 (and iSPI for Metrics) allows threshold alerting on node components (or interface stats), however this needs to be set up at interface or node level within the monitoring configuration menus.
Example 1: Enabling CPU Threshold Alerting
Configuration > Monitoring Configuration
Edit Routers (or another monitoring group, which refers to the node group you want) and in the Threshold Settings Tab, Add a new count based threshold setting.
Select CPU 5Min Utilization and set thresholds as desired. It’s best to disable the low value completely by setting Low Value and Low Value Rearm to 0 as we’re only concerned with a high value. You may want to set the High Trigger Count to 2 or more rather than 1, considering the fact that config writes and other normal activity can cause CPU spikes.
Now Save and Close down to the Monitoring Configuration menu, then either Save or Save and Close from there.
Example 2: Interface Error Thresholds with iSPI for Metrics
Configuration > Monitoring Configuration > Interface Settings
Edit the desired interface configuration:
Add a new Count based Threshold, Select Input Error Rate and set as follows to alert for any amount of errors on any given poll.
Save & Close to Monitoring Configuration, then Save again. Repeat this for Output Error rate then save and close from the Monitoring Configuration menu.
To verify Interface Error threshold monitoring is working, you can go to Monitoring > Interface Performance like so:
Now you get alerts like the following in the alarm browser!
A Cisco ASA5550 was stuck on “Booting system, please wait…” after a power cycle (physically turning off and on, not just a reload). It was impossible to break into ROMMON from here.
After taking the cover off and doing some experimentation, the issue was found to be a faulty DIMM slot. We removed all DIMMs and replaced them one by one. Upon placing a DIMM in slot 1, the firewall failed to boot again. We swapped DIMMs 1 and 2, still no joy.
Removing the DIMM from slot 1 again meant that the firewall came back up.
Solution: If an RMA is going to take time, bring the firewall back up with less memory. Otherwise, swap the thing out straight away as you don’t know what else the power cycle has fried!
You can make your life easier doing the replacement by moving the old ASA’s compact flash card to the external (disk1) slot of the new one. You can then get the right OS on the replacement quickly at least.
NEWASA# copy disk1:/[IOS-image-name.bin] disk0:/[IOS-image-name.bin]
NEWASA# boot system disk0:/[IOS-image-name.bin]
NEWASA# wr mem
Note: you can copy the running-config on the old ASA to a visible file on CF (eg: copy running-config disk0:/myconfig.cfg), but copying that from disk1 to running-config on the replacement tends to not work very well if you have TACACS config in place. Good old copy and paste from a backup is the way forward.