ASA Resource Classes: Stopping One Context From Eating the Firewall

Once you slice a Cisco ASA into multiple security contexts, you have created a shared-resource problem. All those virtual firewalls draw from the same finite pools: connections, translations, host entries, inspection capacity, and more. Nothing stops one badly behaved or busy context from consuming so much of a pool that the others are starved. Resource classes are the mechanism that stops that, letting you cap and guarantee slices of the firewall's capacity per context. This article is part of the Cisco ASA series, and it carries the same honest caveat as the rest of the multi-context family: the feature lives only in multiple context mode, and our virtual lab appliance cannot enter that mode. We will show the real rejection rather than fake a demo.

The Problem: One Context Eating the Firewall

Imagine three tenants sharing one ASA in multiple context mode. Tenant A runs a normal web workload. Tenant B gets hit by a connection flood (a scan, a misbehaving application, or an outright attack) and starts opening connections and building translations as fast as the firewall will let it. Because all three contexts draw from the same global limits, tenant B's surge consumes the shared connection and xlate pools, and now tenant A and tenant C cannot open new connections either. One tenant's problem has become everyone's outage. This is the noisy-neighbor problem in firewall form, and it is exactly what multi-tenancy is supposed to prevent. Administrative separation without resource separation is only half of isolation.

Resource classes close that gap. By assigning each context to a class that caps how much of each resource it may consume, you ensure that tenant B can exhaust only its own allocation, not the whole appliance. The other contexts keep working because their share was never available for tenant B to take. This is the same principle as CPU and memory limits on virtual machines or containers, applied to firewall data-plane resources.

How Resource Classes Work

A resource class is a named policy that sets limits on the resources a member context can use. You create the class in the system context, set limits inside it, and then assign one or more contexts to membership of that class. A context that is not explicitly placed in a class belongs to the default class, which by convention allows unlimited use of most resources (so if you do nothing, you have the very noisy-neighbor exposure described above).

Limits come in two flavors, and understanding the difference is the whole art of the feature:

• Limits (maximums). A hard ceiling on how much of a resource a context may consume. This is the noisy-neighbor guard: the context simply cannot exceed it, protecting the pool for everyone else.
• Guarantees (minimums, expressed as a percentage of the total). A reserved floor that other contexts cannot eat into. This is the starvation guard from the other direction: even if every other context is busy, this context is promised at least its reserved share.

You can express many limits either as an absolute number or as a percentage of the platform's total for that resource. Common resources you cap include concurrent connections, connection setup rate per second, address translations (xlates), host entries, ASDM and Telnet/SSH management sessions, MAC addresses (in transparent mode), and inspection rates. The two you care about most in practice are usually concurrent connections and the connection rate, because that is what a flood consumes fastest.

Configuring a Resource Class on a Supported Platform

On a physical ASA in multiple context mode, the configuration is compact. In the system context you define the class, set the limits and guarantees, and then join contexts to it:

! system context
class GOLD
 limit-resource conns 50000
 limit-resource rate conns 5000
 limit-resource xlates 40000
 limit-resource hosts 30000
!
context CUSTOMER-A
 member GOLD
 config-url disk0:/ctx-a.cfg
!
context CUSTOMER-B
 member GOLD
 config-url disk0:/ctx-b.cfg

Here the GOLD class caps each member context at 50,000 concurrent connections, 5,000 new connections per second, 40,000 translations, and 30,000 host entries. CUSTOMER-A and CUSTOMER-B are both members, so each is independently held to those ceilings. If CUSTOMER-B is flooded, it hits its own 5,000-per-second setup ceiling and stops, and CUSTOMER-A's capacity is untouched. You verify the live picture with show resource usage, which reports current and peak usage against the limits per context, and flags any resource that has hit its cap (a denied count that is climbing is your signal that a context is bumping its ceiling).

The design workflow is to build a few tiers (for example GOLD, SILVER, BRONZE) with different ceilings and guarantees, then place tenants into the tier they pay for or the tier their risk profile warrants. A high-value tenant gets a guaranteed minimum so it is never starved; a low-trust tenant gets a tight maximum so it can never become the noisy neighbor.

The Honest asav Note

Resource classes only exist inside multiple context mode. They are configured in the system context and they operate on contexts, so with no contexts there is nothing to limit. That is the exact wall we hit in the lab. Our firewalls are virtual asav 9.24 instances, and the virtual appliance cannot enter multiple context mode, which we confirmed on the real device:

Because mode multiple is rejected by the parser, there are no contexts to place into a class, and the class and limit-resource commands have nothing to act on. Resource classes are therefore a physical-ASA, multiple-context feature that the asav cannot demonstrate. There is no workaround to expose them on the virtual appliance; the honest position is that this is hardware territory, and the single line above is the proof. If you want to study resource classes hands-on for CCIE Security, do it on a physical ASA or a hardware-accurate environment, not asav.

What Protects a Virtual ASA Instead

On a single-context asav you do not have per-context resource classes, but you are not defenseless against resource exhaustion. A single-context firewall has one owner of its resources, so the noisy-neighbor problem between tenants does not exist in the first place (there is only one tenant). Where you still want protection is against a single flooding source or runaway application eating the box, and for that the tools are connection limits and embryonic (half-open) connection limits applied through your policy, plus per-VM resource sizing at the hypervisor. If your goal was multi-tenant fairness, the virtual answer is the same one we reach for elsewhere in this series: run a separate asav per tenant so each tenant gets its own appliance and its own full set of resources, which is a harder isolation boundary than contexts anyway. That approach pairs naturally with the shared-interface context discussion, where we reach the same conclusion: on virtual, separate instances beat one appliance sliced into contexts.

Limits vs Guarantees: A Worked Example

The interplay between maximums and minimums is where resource classes earn their keep, so it helps to see it play out. Suppose an ASA platform supports 100,000 concurrent connections in total, and you have four contexts. You give one context a guarantee of 40 percent, which reserves 40,000 connections that no other context can ever consume, even when that context is idle. The remaining 60,000 connections form a shared pool the other three contexts compete for, unless you also cap them. If you then place those three in a class with a limit of 25,000 connections each, none of them can individually exceed 25,000, so even all three flooding at once cannot touch the 40,000 you reserved for the important tenant.

Notice that guarantees and limits solve opposite failure modes. A guarantee protects an important context from being starved by others; a limit protects everyone else from a greedy context. In a well-designed multi-tenant firewall you usually use both: guarantees for the tenants you must never let fail, and limits for the tenants you do not fully trust. Be careful not to over-commit guarantees, though. If you hand out guaranteed minimums that sum to more than 100 percent of a resource, the ASA cannot honor them all simultaneously, and the configuration is either rejected or leaves you with promises the hardware cannot keep. Keep the sum of guarantees comfortably under the total so there is headroom for the contexts that have no guarantee at all.

Common Resource-Class Mistakes

Three mistakes account for most resource-class trouble on hardware. The first is leaving everything in the default class, which allows effectively unlimited use, and then being surprised when one context takes down the others; the default class is a trap precisely because it looks like it is doing something when it is not protecting anyone. The second is capping concurrent connections but forgetting the connection rate: a flood is often more about setup rate than steady-state count, so a context can hammer the CPU building and tearing down connections while never hitting a concurrent-connection ceiling. Cap both. The third is setting limits and then never watching show resource usage, so you never learn that a context is routinely bumping its ceiling and dropping legitimate traffic. The denied counter in that output is the feedback loop: a steadily climbing denied count means either an attack or a limit set too low for the tenant's real workload, and you cannot tell which without looking. Resource classes are not a set-and-forget control; they are a policy you tune as you learn each tenant's genuine demand.

Key Takeaways

• In multiple context mode all contexts draw from shared resource pools, so one context can exhaust connections, xlates, or host entries and starve the others.
• Resource classes cap and guarantee per-context resource usage: limits set hard maximums (noisy-neighbor guard), guarantees reserve minimum shares (starvation guard).
• You define a class with limit-resource entries in the system context, then join contexts with member; verify live usage with show resource usage.
• The resources most worth capping are concurrent connections and connection setup rate, because that is what a flood consumes fastest.
• Resource classes require multiple context mode, which asav cannot enter: mode multiple returns % Invalid input detected at '^' marker., so the feature is physical-ASA only.
• On a virtual ASA, use per-policy connection limits and per-VM sizing, or run a separate asav per tenant for true isolation. See the shared-interface contexts guide and the Cisco ASA pillar.