e contexts residing within a single physical firewall. Single Multicontext Firewall Context 2 Context 3 Context 4 Figure 28-3. Multiple contexts within a physical ASA Each context behaves as if it were a single standalone device, though there are ways that interfaces can be shared between contexts. Each context may have its own IP scheme, and networks can be replicated in multiple contexts without issue. Most of the normal ASA features are available within each context, but there are some important features that are not. Though the ASA appliance is capable of many functions such as VPN, IDS, and the like, most of these additional features are disabled in mul- ticontext mode. It bears repeating that multicontext mode disables the following features: Support for OSPF, RIP, and EIGRP Multicast routing; multicast bridging is supported Threat detection Phone proxy That's a pretty significant list! For many, the inability to support VPN alone may make contexts unusable. The disabled QoS and phone proxy features may also be serious negatives when you're considering contexts. In a nutshell, if you need many firewalls with traditional PIX-like features, multicontext mode will serve you well. I have used them in ecommerce websites and in data center environments where each context sup- ported a single customer. For these scenarios, contexts work quite well. Context Types There are three types of contexts in a multicontext ASA. They are the system context, the admin context, and what I call regular contexts or just contexts. Each of these contexts has features and limitations as shown in Figure 28-4: System context The system context is where all contexts are created and managed. When you first log into the console of a multicontext ASA, you will find yourself in the system Chapter 28: ASA Firewall Configuration System Context Admin Context Admin Single Multicontext Created by default Firewall Hardware Mgmt0 Int is here Any nonsystem context can ASA 5540 for example GAD-Tech be the admin context Regular Context Created by m