anually Interfaces must be allocated System Context Root Context All other contexts are created from within the system context Figure 28-4. Context types within an ASA context. The system context is where all failover is configured and managed. You can think of the system context as a sort of root context. The system context is not a usable virtual firewall like other contexts, since interface and security rules are not applied in the system context with the exception of failover interfaces. With the ASA in multicontext mode, the speed and duplex on interfaces can be set only in the system context. This will likely drive you nuts the first time you use contexts; if you're like me, you'll quietly swear at Cisco for making a device that apparently can't support 10 Mb or 100 Mb devices, ignorant of the fact that the speed can be changed, just not in the context you're in. The interfaces can only be changed in the system context because physical inter- faces can be shared between contexts. It wouldn't do to have customer A changing the duplex on an interface being shared with customer B, now would it? Admin context The admin context behaves like any other nonsystem context; however, when ad- ministering the admin context, you can jump both to the system context and other contexts. There can be only one admin context, and it can be any context of your choosing. You perform tasks such as upgrading code through the admin context. Context A context is a virtual firewall, as previously outlined. This type of context is spe- cifically not one of the other two types. When you're in a context, there may be no indications that you are in a virtual device except that some normally available configurations such as failover and interface speed/duplex commands don't exist. You may not be able to jump to other contexts unless you first arrived there from a system or admin context. Failover within the context (but not for other contexts) may be triggered from within the context, depending on the global failover configuration. Manag