Planning the Number of Firewall Filters to Create
Maximum Number of Supported Firewall Filters
Table 1 shows the maximum number of firewall filters that each switch supports. The total number of filters are applied in aggregate. For example, on the QFX5200 and QFX5210 switches, you can apply a total of 768 terms in the input direction and 1024 terms in the output direction. The actual number of filters that a switch supports depends on how the filters are stored in ternary content addressable memory (TCAM).
For for QFX5120-48Y and EX4650 switches running Junos OS Release 20.3R1 or later, you can enable the [set chassis loopback-firewall-optimization command to increase the default system limit for loopback filter terms to 768 for IPv6, and 1152 terms for IPv4.
To see how many filters are already programmed on the switch, enter the show pfe filter hw summary command. On QFX5220 switches, use shell mode to see the number of filters. To enter shell mode, enter the start shell command and type cli-pfe at the prompt to access PFE CLI mode.
Table 1: Maximum Number of Supported Firewall Filters
|Filter Type||QFX3500, QFX3600||QFX5100, EX4600||QFX5120, EX4650||QFX5110||QFX5200, QFX5210, QFX5220||QFX10000|
1024 or 2048
How to Increase the Number of Firewall Filters
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 5 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.
All of the above examples also apply to egress filters. The difference is that four memory slices are used because IPv4 and IPv6 Layer 3 filters are stored in separate slices. The memory slices for egress filters are the same size as those for ingress filters, so the maximum number of filters will be the same (1024).
Avoid Configuring too Many Filters
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.
Make sure that you delete the excessive filters (for example, the remaining 44 ingress Layer 3 filters) from the configuration before you reboot the device. If you reboot a device that has a noncompliant configuration, it’s hard to predict which filters were installed after the reboot. Using the example above, the 44 ingress Layer 3 filters that were originally rejected might be installed, and 44 of the port filters that were originally accepted might be rejected.
Configuring TCAM Error Messages
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.
How Policers can Limit Egress Filters
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.
Planning for Filter-Specific Policers
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.
Planning for Filter-Based Forwarding
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.
Filter-based forwarding does not work with IPv6 interfaces on some Juniper switches.