ntries on any context for the destination IP address, and no NAT entries to reference. In this case, the classifier may actually drop the packet. Unless you will be NATing outside addresses in a limited environment, sharing inside interfaces is not recommended. Sharing inside and outside interfaces It is theoretically possible to share interfaces on the inside and the outside of a multi- context ASA (Figure 28-9). This is not recommended, SO don't do it. Simply put, it will drive the classifier, and likely you, quite mad. Cascading contexts Contexts can be cascaded. Cascaded contexts are configured to be in front of or behind one another. The preceding examples show interfaces being shared, but all the shared interfaces occur on the same side on each context. For example, we might share all of Chapter 28: ASA Firewall Configuration VLAN 10 Single Multicontext Firewall Context 2 Context 3 Context 4 VLAN 50 Figure 28-9. Multiple contexts sharing both outside and inside interfaces the outside interfaces in an ISP scenario where the outside is a common public-IP segment. You can cascade contexts by making the inside interface of one context shared with the outside context of another (Figure 28-10). VLAN 60 Single Multicontext Firewall Context 3 Single Shared Interface - Not necessarily a switch VLAN Context 2 Context 4 VLAN 100 VLAN 300 Figure 28-10. Cascaded contexts This configuration might be useful where a single firewall controlled by the ISP needs to secure the network in addition to the security supplied by individual customers. Take care with this scenario, as you will likely need to replicate rules on each layer to allow traffic to flow. Managing Contexts Configuring Contexts ASA firewalls that support contexts can operate in two modes: single and multiple. Single mode is a typical ASA appliance that supports all the features you've come to expect from an ASA. Multiple mode is what I like to call multicontext mode, where the ability to support multiple virtual firewalls is traded for all those cool features 