Planning the Number of Firewall Filters to Create

You can increase the number of firewall filters on your device several ways:

• (QFX5220) To create more than 512 egress VLAN filters, specify the first VLAN ID as 6, the second VLAN ID as 7, the third VLAN ID as 8 and so forth. For each VLAN that you configure, the number increases by 1 and continues through VLAN ID 1029. If you want to create fewer than 512 egress VLAN filters, but want the total number of terms in those filters to be more than 512, make sure that you number your VLAN IDs this same way. Otherwise, the total number of allowed terms or filters will be less than 1024 and will remain at 512.

• Starting in Junos OS Release 19.1R1, you can increase the number of egress VLAN firewall filters on the QFX5110 from 1024 to 2048 by using the egress-to-ingress option. You include this option under the from statement at the [edit firewall] hierarchy.

  Starting in Junos OS Evolved Release 19.4R2, you can configure up to 2000 egress firewall filters on the QFX5220 by including the egress-scale option under the eracl-profile statement at the [edit system packet-forwarding-option firewall] hierarchy level. This feature is supported only in the egress direction (routed traffic exiting the device).

  Consider this following when configuring this feature:

  • You cannot apply filters with the same match conditions to different egress VLANs or Layer 3 interfaces.

  • You cannot apply egress scaling on GRE interfaces.

  • If a packet matches multiple filters with different qualifiers and you apply on different egress interfaces, this can lead to unpredictable behavior.

  • You can only configure the egress-scale option in global mode. The new cli configuration will be provided in global mode. Once a user configures ERACL group in egress-scale (egress to ingress) mode, he will not be able to configure ERACL the older way i.e., without using IFP tcam space. In other words, ERACL in mixed mode will not be supported.

Ternary content addressable memory (TCAM) for firewall filters is divided into slices that accommodate 256 terms. When you configure a firewall filter, all terms in a memory slice must be in filters of the same type and applied in the same direction. A memory slice is reserved as soon as you commit a filter. For example, if you create a port filter and apply it in the input direction, a memory slice is reserved that only stores ingress port filters. If you create and apply only one ingress port filter and that filter has only one term, the rest of this slice is unused and is unavailable for other filter types.

For example, let’s say that you create and apply 256 ingress port filters with one term each so that one memory slice is filled. This leaves two more memory slices available for ingress filters. (In this case, the maximum number of ingress terms is 768.) If you then create and apply an ingress Layer 3 filter with one term, another memory slice is reserved for ingress Layer 3 filters. As before, the rest of the slice is unused and is unavailable for different filter types. Now there is one memory slice available for any ingress filter type.

Now assume that you create and apply a VLAN ingress filter. The final memory slice is reserved for VLAN ingress filters. Memory allocation for ingress filters (once again assuming one term per filter) is:

• Slice 1: Filled with 256 ingress port filters. You cannot commit any more ingress port filters.

• Slice 2: Contains one ingress Layer 3 filter with one term. You can commit 255 more terms in ingress Layer 3 filters.

• Slice 3: Contains one ingress VLAN filter with one term. You can commit 255 more terms in ingress VLAN filters.

Here is another example. Assume that you create 257 ingress port filters with one term per filter–that is, you create one more term than a single memory slice can accommodate. When you apply the filters and commit the configuration, the filter memory allocation is:

• Slice 1: Filled with 256 ingress port filters. You cannot apply any more ingress port filters.

• Slice 2: Contains one ingress port filter. You can apply 255 more terms in ingress port filters.

• Slice 3: This slice is unassigned. You can create and apply 256 terms in ingress filters of any type (port, Layer 3, or VLAN), but all the filters must be of the same type.

If you violate any of these restrictions and commit a configuration that is not in compliance, Junos OS rejects the excessive filters. For example, if you configure 300 ingress port filters and 300 ingress Layer 3 filters and try to commit the configuration, Junos OS does the following (again assuming one term per filter):

• Accepts the 300 ingress port filters (storing them in two memory slices).

• Accepts the first 256 ingress Layer 3 filters it processes (storing them in the third memory slice).

• Rejects the remaining 44 ingress Layer 3 filters.

If you lack TCAM space and are unable to install a firewall filter, you can configure your switch to send error messages the following ways:

• Enter set system syslog file filename pfe emergency to send error messages to a syslog file.

• Enter set system syslog console pfe emergency to send error messages to the console.

• Enter set system syslog user user-login pfe emergency to send error messages to an SSH terminal session.

When you configure a firewall filter, the term statement in the firewall filter configuration provides an extensive set of match conditions. Match conditions are the fields and values that a packet must contain to be considered a match. You can define a single or multiple match conditions based on your requirement. When a packet matches a filter, the device takes the action specified in the term. The scalability of firewall filters generally depends on the number of match conditions used.

In typical deployment scenarios, you will only need to use a subset of match conditions. With the introduction of profiles, you can use one of the available firewall filter profiles with pre-defined match conditions to increase the number of firewall filters used to achieve maximum scale.

You can configure firewall filters profiles for family inet and Ethernet-based switching. Use the profiles configuration statement at the [edit system packet-forwarding-options firewall] hierarchy level to configure firewall filter profiles.

The following table describes the firewall filter profiles and the pre-defined match conditions for inet and Ethernet-based switching.

You can use the show pfe filter hw profile-info CLI command to view the details of the firewall filter profiles.

To achieve maximum firewall filter scale, it is recommended to apply interface level (Layer 2 or Layer 3) filters and distribute the filters equally across the interfaces of different packet processing pipelines. Each set of interfaces is mapped to a packet processing pipeline which handles the packets received on those interfaces. In this case, the firewall filters are installed to the packet processing pipeline’s TCAM memory space mapped to the respective interface.

When a packet enters an interface, the firewall filter performs filtering actions on the packet in the packet processing pipeline based on the match conditions before exiting an egress interface. In the case of multiple packet processing pipelines, when packets enter a device through multiple interfaces, the firewall filter performs filtering actions on the packets passing through the respective packet processing pipelines. Having the interface level filters distributed equally across the interfaces of different packet processing pipelines gives better scale

You can use the show pfe filter hw port-pipe-info CLI command to view the details of the packet processing pipeline that each physical interface is mapped to. The output of this CLI command also provides information about the firewall filters installed on a packet processing pipeline. You can use this information to plan and distribute firewall filters across pipelines to achieve maximum scale.

The following sample output of the show pfe filter hw port-pipe-info CLI command show the details of the packet processing pipeline that each physical interface is mapped to:

On some switches, the number of egress policers you configure can affect the total number of allowed egress firewall filters. Every policer has two implicit counters that take up two entries in a 1024-entry TCAM. These are used for counters, including counters that are configured as action modifiers in firewall filter terms. (Policers consume two entries because one is used for green packets and one is used for nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any more egress firewall filters that have terms with counters. For example, if you configure and commit 512 egress policers (two-color, three-color, or a combination of both policer types), all of the memory entries for counters get used up. If later in your configuration file you insert additional egress firewall filters with terms that also include counters, none of the terms in those filters are committed because there is no available memory space for the counters.

Here are some more examples:

• Assume that you configure egress filters that include a total of 512 policers and no counters. Later in your configuration file you include another egress filter with 10 terms, 1 of which has a counter action modifier. None of the terms in this filter are committed because there is not enough TCAM space for the counter.

• Assume that you configure egress filters that include a total of 500 policers, so 1000 TCAM entries are occupied. Later in your configuration file you include the following two egress filters:

  • Filter A with 20 terms and 20 counters. All the terms in this filter are committed because there is enough TCAM space for all the counters.

  • Filter B comes after Filter A and has five terms and five counters. None of the terms in this filter are committed because there is not enough memory space for all the counters. (Five TCAM entries are required but only four are available.)

You can stop this problem from happening by ensuring that egress firewall filter terms with counter actions are placed earlier in your configuration file than terms that include policers. In this circumstance, Junos OS commits policers even if there is not enough TCAM space for the implicit counters. For example, assume the following:

• You have 1024 egress firewall filter terms with counter actions.

• Later in your configuration file you have an egress filter with 10 terms. None of the terms have counters but one has a policer action modifier.

You can successfully commit the filter with 10 terms even though there is not enough TCAM space for the implicit counters of the policer. The policer is committed without the counters.

You can configure policers to be filter-specific. This means that Junos OS creates only one policer instance no matter how many times the policer is referenced. When you do this, rate limiting is applied in aggregate, so if you configure a policer to discard traffic that exceeds 1 Gbps and reference that policer in three different terms, the total bandwidth allowed by the filter is 1 Gbps. However, the behavior of a filter-specific policer is affected by how the firewall filter terms that reference the policer are stored in ternary content addressable memory (TCAM). If you create a filter-specific policer and reference it in multiple firewall filter terms, the policer allows more traffic than expected if the terms are stored in different TCAM slices. For example, if you configure a policer to discard traffic that exceeds 1 Gbps and reference that policer in three different terms that are stored in three separate memory slices, the total bandwidth allowed by the filter is 3 Gbps, not 1 Gbps.

To prevent this unexpected behavior from happening, use the information about TCAM slices above to organize your configuration file so that all the firewall filter terms that reference a given filter-specific policer are stored in the same TCAM slice.

You can use firewall filters along with virtual routing instances to specify different routes for packets to travel in their networks. To set up this feature–called filter-based forwarding, you specify a filter and match criteria and then specify the virtual routing instance to send packets to. Filters used in this way also consume memory in an additional TCAM. See Understanding FIP Snooping, FBF, and MVR Filter Scalability for more information. The section FBF Filter VFP TCAM Consumption in this topic specifically addresses the number of supported filters when using filter-based forwarding.