Welcome everyone! This video is an overview of ASA multi-mode, also known as contexts. We’ll start by looking at why you might want to use this feature.
Suppose you have an environment like this. A single ASA on the edge of the network, a DMZ, and several business units. Each network is a different interface on the ASA.
Your network is growing, and a single ASA on the edge is not working as well as it used to. Rather than one firewall on the edge, you would prefer to have separate firewalls for each network…
It’s a reasonable design, but it comes with a downside.
It’s going to cost more, take up more space in your racks, and require extra hardware support contracts
Fortunately, multi-mode provides you with another option…
Contexts allow us to use a single physical ASA, while running several virtual ASA’s on top.
As long as there’s enough physical resources, this works well.
So can any ASA use multi-mode?
If you have a 5506, unfortunately you’re out of luck…
Contexts are not available on this platform. The same goes for ASAv’s, which are already virtualised.
If you have a 5512, you can have contexts, but you will need the security plus license
If you have a 5515 or larger, you’re good to go.
You’ll get two contexts out of the box, but any more will require extra licenses.
Please be aware that there are also some feature limitations.
For example, a lot of inspections and VPN topologies are not available.
Check out the Cisco site for a supported feature list.
So how does multi-mode work?
Firstly, there’s the ‘system context’, also known as the ‘system execution space’.
This is a special context that is used for managing the underlying hardware.
From here, firewall contexts are created.
In a basic sense, the system space is a bit like a hypervisor that manages virtual machines.
This is also where the interfaces are configured and assigned.
For example, physical ports can be bundled into etherchannels.
The etherchanels are then assigned to contexts.
The same ports or etherchannels can be assigned to more than one context.
The System context only manages hardware.
It has no firewalling or network capability of its own.
So what happens when it needs to download an update, or send a message to syslog?
For this, the admin context is used.
This is a special role that, by default, is assigned to the first context created.
The role can be reassigned to any other context later on.
When the system needs to access the network, it will use the admin context.
When packets arrive at a physical interface, the system needs to classify them, so they can be delivered to the correct virtual ASA.
If there’s only one context with that interface allocated, classification is easy. It only has one place it can go.
This is common for transparent mode deployments
It’s a bit trickier when an interface has been assigned to more than one context.
In this case, the MAC address is used to classify the packet.
This requires each interface in each context to have a unique vMAC.
This can be done manually or auto-generated.
If individual vMACs are not used, the physical interface’s MAC is used for every context.
If vMAC’s are not assigned, then NAT tables are inspected to decide how to classify the packet.
And that’s it for the basics of ASA multi-mode.
Please see the website for more information, and a configuration walk-through.
Please ‘like’ the video if you’ve enjoyed it, or leave a comment below.
Follow me on twitter or subscribe to this channel to be notified of new articles and videos.
Thanks for watching!