This help contains the following topics:

·     Introduction

¡     Default context and non-default contexts

¡     Assigning resources to a context

¡     Collecting information

¡     Rate limiting

·     Restrictions and guidelines

¡     Restrictions and guidelines: Stopping a context

¡     Restrictions and guidelines: VLAN assignment

¡     Restrictions and guidelines: Interface assignment

¡     Restrictions and guidelines: Information collection

·     Configure a context

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.

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 the CPU resources cannot meet the processing requirements from contexts, the system allocates CPU resources as follows:

1.     Identifies the CPU weights of all contexts.

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

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

A large number of sessions occupy too much memory. This degrades context performance and affects other contexts. When the maximum number is reached, no additional sessions can be established. To solve this issue, set the maximum number of concurrent unicast sessions for a context.

This feature does not affect local traffic, such as FTP traffic and Telnet traffic.

If the maximum number you set is smaller than the number of existing concurrent unicast sessions, this setting still takes effect. The context does not delete extra existing concurrent unicast sessions and allows new unicast sessions to be created only when the number of concurrent unicast sessions drops below the maximum number.

Setting the upper limit of the session establishment rate

This feature limits the number of sessions that can be established per second for a context. If a context establishes sessions too frequently, other contexts will not be able to establish sessions because of inadequate CPU processing capacity. 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 and Telnet traffic.

Setting the maximum number of security policy rules

This feature limits the number of security policy rules that can be configured for a context. Security policy rules occupy memory space. Configuring too many security policy rules might affect operation of other features. When the upper limit is reached for a context, no additional security policy rules can be configured.

If the maximum number you set is smaller than the number of existing security policy rules, this setting still takes effect. The context does not delete extra existing security policy rules and allows new  security policy rules to be created only when the number of security policy rules drops below the maximum number.

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.

If the maximum number you set is smaller than the number of SSL VPN users that already have logged in to a context, this setting still takes effect. The context does not log out the currently logged-in users and allows new users to log in only when the number of the logged-in users drops below the maximum number.

Setting a throughput threshold

This feature limits the throughput for a context to prevent it from occupying too many shared resources on the device. 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: Stopping a context

Stop a context with caution. Stopping a context stops all services on the context and logs out all users on the context.

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.

Configure a context

1.     Display assignment and configuration information about interfaces.

2.     Create a context.

3.     Assign resources to the context:

¡     Assign VLANs and interfaces to the context.

¡     Assign CPU, disk, and memory resources to the context

¡     Set the maximum number of concurrent unicast sessions.

¡     Set the upper limit of the session establishment rate.

¡     Set the maximum number of security policy rules.

¡     Set the maximum number of SSL VPN login users.

¡     Set the throughput threshold.

4.     Monitor resource usage on the context.