• Download Software
• Research a Problem 
• Case Management 
• Contract & Product Management 
• Technical Documentation
  • Advanced Search
  • Documentation Archive
  • Documentation Bug Report
  • Enterprise MIBs
  • File Format Help
  • Glossary
  • Portable Libraries
• End-of-Life Products
• Contact Support
• Guidelines and Policies
• Security Resources

Guidelines for Firewall Configuration in Logical Systems

As a general rule, firewall filters configured under a logical system must be complete and self-contained. Typically, the filters cannot reference firewall elements configured at the [edit firewall] hierarchy level or at another [edit logical-systems logical-system-name] hierarchy level. If no firewall filters are configured for a logical system, the firewall filters at the [edit firewall] hierarchy level are applied.

In some situations, firewall statements that are valid under the [edit firewall] hierarchy are not supported under the [edit logical-systems logical-system-name firewall] hierarchy. There are three scenarios to consider:

• Scenario 1. An object in the firewall hierarchy references another object in the hierarchy; for example, when a firewall filter references a firewall policer.
• Scenario 2. An object outside the firewall references an object inside the firewall hierarchy; for example, a firewall filter is applied to an interface.
• Scenario 3. An object in the firewall hierarchy references an object outside the firewall hierarchy; for example, when a firewall filter references a prefix list (defined under the [edit policy-options] hierarchy).

This section includes the following topics:

• Scenario 1: Firewall Objects Reference Other Firewall Objects
• Scenario 2: Nonfirewall Objects Reference Firewall Objects
• Scenario 3: Firewall Objects Reference Nonfirewall Objects

Scenario 1: Firewall Objects Reference Other Firewall Objects

If a firewall object references a subordinate object (for example, a policer or prefix list), that subordinate object must be defined within the firewall object. For example, if a firewall filter configuration references a policer, that policer must be configured under the same firewall object as the filter. This rule applies even if the same policer is configured under the main firewall configuration or if the same policer is configured as part of a firewall in another logical system.

In this example, the filter1 filter references the pol1 policer. Both filter1 and pol1 are defined under the same firewall object. This configuration is valid. If pol1 were defined under another firewall object, the configuration would not be valid.

Scenario 2: Nonfirewall Objects Reference Firewall Objects

When an object is configured within a logical system (but is not included in the firewall configuration for the logical system) and that object references a firewall object, the following logic is used to resolve the configuration:

• If firewall configuration statements are defined within the same logical system, the [edit logical-systems logical-system-name firewall] hierarchy is searched to resolve the configuration. The main [edit firewall] hierarchy is not searched.
• If no firewall configuration statements are defined within the same logical system, the firewall configuration defined at the [edit firewall] hierarchy level is searched to resolve the configuration. This search option is provided for legacy purposes. The main [edit firewall] hierarchy is searched only if firewall configuration statements are not defined within the same logical system.
• Firewall configurations that belong to other logical systems are not searched.

In the following example, the filter fred is applied to an interface in the logical system ls1. However, fred is defined in the main firewall configuration instead of in the ls1 firewall configuration. Therefore, in this first example, the configuration is not valid.

To fix this example, define filter fred under logical system ls1. In this case, the filter fred applied to interface fe-0/3/2 looks for source address 10.1.0.0/16 rather than 11.1.0.0/16.

If, however, the [edit logical-systems logical-system-name] hierarchy does not contain any firewall statements, then the main firewall configuration is used for any filter or policer references. For example, the following configuration is also allowed:

Scenario 3: Firewall Objects Reference Nonfirewall Objects

In many cases, a firewall configuration references objects outside the firewall configuration. As a general rule, the referenced object must be defined under the same logical system as the referencing object. However, there are cases when the configuration of the referenced object is not supported at the [edit logical-systems logical-system-name] hierarchy level.

In the following example, the service filter inetsf1 references prefix list prefix1. The service set fred cannot be defined under the logical system lr1. In this case, the [edit services] hierarchy is searched for the definition of the fred service set. This configuration is allowed because the [edit logical-systems logical-system logical-system-name] hierarchy already had the capability to reference service sets outside the logical system hierarchy.

Unsupported Configuration Statements, Actions, and Action Modifiers

Table 1 lists statements that are supported at the [edit firewall] hierarchy level but not at the [edit logical-systems logical-system-name firewall] hierarchy level.

Table 2 includes a list of the firewall filter actions and action modifiers that are supported at the [edit firewall] hierarchy level, but not supported at the [edit logical-systems logical-system-name firewall] hierarchy level.