This help contains the following topics:

·     Introduction

¡     Default context and non-default contexts

¡     Security engine and security engine groups

¡     Assigning resources to a context

¡     Collecting information

¡     Rate limiting

·     Restrictions and guidelines

¡     Restrictions and guidelines: Security engine groups

¡     Restrictions and guidelines: VLAN assignment

¡     Restrictions and guidelines: Interface assignment

¡     Restrictions and guidelines: Information collection

Introduction

A physical firewall or an IRF fabric can be virtualized into multiple logical firewalls called contexts. Each context is assigned separate hardware and software resources, and operates independently of other contexts. From the user's perspective, a context is a standalone firewall.

Default context and non-default contexts

A device supporting contexts is considered to be a context. This context is called the default context. The default context always uses the name Admin and the ID 1. You cannot delete it or change its name or ID.

When you log in to the physical firewall, you are logged in to the default context. On the default context, you can perform the following tasks:

·     Manage the entire physical firewall.

·     Create and delete non-default contexts.

·     Assign non-default contexts resources, including CPU resources, disk space, memory space, interfaces, and VLANs.

You cannot create contexts on a non-default context.

A non-default context can use only resources assigned to it. Resources that are not assigned to non-default contexts belong to the default context.

Unless otherwise stated, the term "context" on webpages refers to a non-default context.

Security engine and security engine groups

The firewall is equipped with hardware security engines. A context can run and provide services only after you assign it to a security engine group.

To simplify management, the firewall manages security engines by using security engine groups.

By default, the firewall has a default security engine group, which is named Default and numbered 1. All security engines belong to the default security engine group.

A security engine can belong to only one security engine group.

A security engine group can have multiple security engines. The system automatically elects one security engine as the main security engine. Other security engines act as backup security engines. When the main security engine cannot operate correctly, the system automatically elects another security engine as the main security engine.

Assigning resources to a context

You can assign a context CPU resources, disk space, memory space, interfaces, and VLANs.

Assigning VLANs to a context

When you create a context, you can specify whether the context share VLAN resources with other contexts.

·     Shared mode—Share VLAN resources with other contexts. The VLANs can be created and managed only on the default context. Non-default contexts can use only VLANs assigned from the default context. A VLAN can be used by multiple contexts. After receiving a packet, the physical device forwards the packet to the context that matches the incoming interface and VLAN tag of the packet. This mode applies scenarios where multiple contexts share the same VLANs.

·     Exclusive mode—Do not share VLAN resources with other contexts. Administrators of the context must log in to the context and create VLANs for the context. This mode applies scenarios where contexts require their independent VLANs.

Assigning interfaces to a context

By default, all interfaces belong to the default context. A non-default context cannot use any interfaces. To enable a non-default context to communicate, you must assign it interfaces.

You can assign interfaces to contexts in exclusive or shared mode:

·     Exclusive mode—An interface assigned to a context in this mode belongs to the context exclusively. After logging in to the context, you can see the interface and use all commands supported on the interface.

·     Shared mode—When you assign an interface to multiple contexts in shared mode, the system creates a virtual interface for each context. The virtual interfaces use the same name as the physical interface but have different MAC addresses and IP addresses. They forward and receive packets through the physical interface. The shared mode improves interface usage.

You can see the physical interface and perform all commands supported on the interface from the default context. The administrator of a context can only see the context's virtual interface and use the shutdown, description, and network- and security-related commands.

Specifying a CPU weight for a context

When you assign a context to a security engine group, the system automatically assigns CPU resources on the security engines to the context. All contexts residing on the same security engine share and compete for the engine's free CPU resources. To prevent a context from occupying too many CPU resources, specify a CPU weight for the context.

When the CPU resources on a security engine cannot meet the processing requirements from contexts, the system allocates CPU resources on the engine as follows:

1.     Identifies the CPU weights of all contexts on the engine.

2.     Calculates the percentage of each context's CPU weight among the CPU weights of all contexts.

3.     Allocates CPU resources to contexts based on their CPU weight percentages.

For example, three contexts share the same CPU. You can assign a weight of 2 to the key context and a weight of 1 to each of the other two contexts. When the system is running out of CPU resources, the key context can use approximately two times of the CPU resources that each of the other two contexts can use.

Assigning disk and memory resources to a context

When you assign a context to a security engine group, the system automatically assigns disk space and memory space resources on the security engines to the context. All contexts residing on the same security engine share and compete for the engine's free disk and memory resources. To prevent one context from occupying too many disk or memory resources, specify a disk space percentage and a memory space percentage for the context.

	Before you specify a disk or memory space percentage for a context, start the context and view the amount of disk or memory space that the context is using. Make sure the disk or memory space you assign to a context is sufficient for the context to start and operate correctly.

 

Setting the maximum number of concurrent unicast sessions

When you assign a context to a security engine group, the system automatically assigns resources on the security engines to the context. All contexts residing on the same security engine share and compete for the engine's free resources. A large number of sessions occupy too much memory and affects other contexts in the same security engine. This feature limits the number of concurrent unicast sessions for a context on each security engine. When the maximum number is reached, no additional sessions can be established.

	This feature does not affect local traffic, such as FTP traffic, Telnet traffic, SSH traffic, HTTP traffic, and HTTP-based load balancing traffic. If packets are processed on multiple security engines, the actual limit is greater than the setting.

 

Setting the upper limit of the session establishment rate

When you assign a context to a security engine group, the system automatically assigns resources on the security engines to the context. All contexts residing on the same security engine share and compete for the engine's free resources. If a context establishes sessions too frequently, other contexts in the same security engine will not be able to establish sessions because of inadequate CPU processing capacity. This feature limits the number of sessions that can be established per second for a context on each security engine. When the upper limit is reached for a context, no additional sessions can be established.

	This feature does not affect local traffic, such as FTP traffic, Telnet traffic, SSH traffic, HTTP traffic, and HTTP-based load balancing traffic. If packets are processed on multiple security engines, the actual limit is greater than the setting.

 

Setting the maximum number of SSL VPN users

This feature limits the number of SSL VPN users that can log in to a context. When the maximum number is reached, the context will reject the login requests of new SSL VPN users.

You can specify a maximum number that is smaller than the number of online SSL VPN users for a context. The context does not log out online users, but it allows new users to log in only when the number of online users drops below the maximum number.

Setting a throughput threshold

When you assign a context to a security engine group, the system automatically assigns resources on the security engines to the context. All contexts residing on the same security engine share and compete for the engine's free resources. This feature limits the throughput for a context to prevent it from occupying too many shared resources on a security engine.

A context has the same throughput threshold on all security engines.

This feature drops service packets preferentially to ensure forwarding of protocol packets.

Collecting information

On the default context, you can collect log messages, diagnostic information, and configuration information about multiple or all contexts.

Rate limiting

Rate limiting takes effect only on active contexts that share interfaces with other contexts.

Rate limiting controls the numbers of incoming broadcast packets and multicast packets in a second on contexts. This feature prevents a context from using too many resources and degrading the service processing capabilities of other contexts.

This feature uses the following limits:

·     Total broadcast rate limit—Limit on the total number of incoming broadcast packets in a second on the device.

·     Total multicast rate limit—Limit on the total number of incoming multicast packets in a second on the device.

·     Per-context broadcast rate limit—Limit on the number of incoming broadcast packets in a second on a context.

·     Per-context multicast rate limit—Limit on the number of incoming multicast packets in a second on a context.

When both a per-context limit and the corresponding total limit are reached, the device drops subsequent packets of the type that arrive at the context.

Setting a total limit to 0 disables the corresponding rate limiting feature.

If an effective per-context limit is smaller than 1000, the value is the default limit. A default limit is the corresponding total limit divided by the number of active contexts that share interfaces with other contexts.

If an effective per-context limit is equal to or greater than 1000, the value might be the default limit or the configured limit.

Restrictions and guidelines

Restrictions and guidelines: Security engine groups

·     A context can be assigned to only one security engine group. A security engine group can be associated with multiple contexts.

·     A security engine can join only one security engine group. A security engine group can have multiple security engines.

·     If you remove the last security engine from a non-default security engine group, the system automatically deletes the non-default security engine group.

·     If you move a security engine from one security engine group to another security engine group, the system automatically reboots the security engine and the service on the engine stops. Configure security engine groups before configuring features for the security engine groups.

·     For the system to operate correctly, the default security engine group must have at least one security engine that is operating correctly.

Restrictions and guidelines: VLAN assignment

·     VLANs to be shared must already exist. Before assigning VLANs to contexts, you must create the VLANs on the default context.

·     The following VLANs cannot be shared among contexts:

¡     VLAN 1.

¡     Default VLANs of ports.

¡     VLANs for which VLAN interfaces have been created.

Restrictions and guidelines: Interface assignment

·     Physical interfaces can be assigned to a context in shared or exclusive mode. Logical interfaces such as subinterfaces and aggregate interfaces can be assigned to a context only in shared mode.

·     After assigning a subinterface to a context, you cannot assign its primary interface to any contexts. After assigning a primary interface to a context, you cannot assign its subinterfaces to any contexts.

·     After assigning an interface to one context in shared mode, you cannot assign the interface to other contexts in exclusive mode before reclaiming the interface from the context.

·     When the device operates in IRF mode, do not assign IRF physical interfaces to a non-default context.

·     Member interfaces of an aggregate interface cannot be assigned to a context.

·     A member interface of a Reth interface cannot be assigned to a context. If a member interface of a Reth interface is a subinterface, the corresponding primary interface cannot be assigned to a context either.

Restrictions and guidelines: Information collection

·     On the default context, you cannot collect log messages for a non-default context that is never started.

·     On the default context, you cannot collect configuration information for a non-default context that is not started.