Firewall – Cisco ASA5510 Bandwidth Shaping/Limiting

ciscocisco-asafirewall

This question is in two parts:

Shape

How can I limit the bandwidth on a ASA5510 to less than 10Mbps?

Currently I have:

policy-map shape_policy
class class-default
 shape average 9000000 36096
!
service-policy shape_policy interface outside

But when I look at the traffic on the outside interface it seems it sometimes busts the 10Mbps.

Police

Also, is it possible to limit the bandwidth taken by each users on the ASA? I've tried something like that (although it is not running at the moment):

police input 3000000 51200 conform-action transmit exceed-action drop
police output 3000000 51200 conform-action transmit exceed-action drop

Is it the way to go or is there a better way?

Thanks!

// Addendum:

I should add I'm using version 8.0(4) of the firmware as it can help provide proper configurations for the latest ASAs.

// Status:

I've opened up a bounty. I got two interesting answers although not definite. One seems to be outdated in terms of supported commands, the other one does not answer the second part of the question and leave me unsatisfied. Cisco experts needed!

Best Answer

This:

  shape average 9000000 36096

actually gives your ASA license to burst the the bandwidth you've allocated, if there#s been a suitably quiet period. If you want a guarantee that you never exceed a given bandwidth, using policing is a better option (on the other hand, with policing, any packets that exceed the bandwidth will be dropped instead of delayed).

Related Solutions

Cisco ios config

I am not quite sure what you want, but if you just want to map port 80 of an external to ip to an internal ip port 80. I think you pretty much have it, but I think you might just need to change:

ip nat inside source static tcp  80 10.10.10.60 80 extendable

to

ip nat inside source static tcp 98.123.123.94 80 10.10.10.60 80 extendable

But besides this, if this is production, once you have it working the way you think you want. You might want to pay a consultant to come in and check your work, it doesn't get much more important than the router.

Cisco – Hubs/switches taking out switches

We operate a couple network implementations where third-party connections are linked up to a centralized Cisco backbone (i.e. multi-tenant setup). I can say I've seen a bunch of diverse (okay, ghetto) devices connected up to the Catalyst platform, and if there's one thing I've learned, it's that the Cisco platform is remarkably resilient to these kinds of things.

There is one achilles heel, though - A cheap hub in the right configuration can easily bring down an entire network with a broadcast storm, and it's not even the Cisco platform's fault. I discovered this in a production configuration, and the only real research I did was finding the closest trash can for that hub, but here's how it happened:

Connect hub to Cisco switch as normal, with uplink port
Connect a workstation to a hub port (in our case, running Windows XP OS, but shouldn't matter)
Connect two other ports together on the hub (either directly, with a single CAT5 or indirectly through another hub).

Everything runs smoothly until that workstation sends out a broadcast announcement. While the hub and the Cisco are smart enough to prevent a broadcast storm on other broadcast packets, the hub isn't smart enough to detect that two of its ports are connected to each other, and will use up almost 100% of its processing power to broadcast that packet in an infinite loop back and forth, as well as out all the other ports (i.e. the uplink to your Cisco).

If this is the case in your configuration, you will notice that across your network, all of the ports on that broadcast VLAN will go nuts, up until the hub can't sustain the capacity and drops the magical looping packet (could be a couple minutes depending on the competing traffic), and then all is back to normal.

In this situation SNMP won't help you since all the ports on that VLAN go crazy with traffic. However, Wireshark is your friend here, since it's easy to capture which IP (and sometimes machine name if it's a broadcast packet) caused the loop, and quickly locate the offending device.

May not be the exact case you're experiencing, but this one bit us hard and might give you some ideas to research with your situation.

Related Topic