Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

# Troubleshooting Policer Configuration

## Incomplete Count of Packet Drops

### Problem

#### Description

Under certain circumstances, Junos OS might display a misleading number of packets dropped by an ingress policer.

If packets are dropped because of ingress admission control, policer statistics might not show the number of packet drops you would expect by calculating the difference between ingress and egress packet counts. This might happen if you apply an ingress policer to multiple interfaces, and the aggregate ingress rate of those interfaces exceeds the line rate of a common egress interface. In this case, packets might be dropped from the ingress buffer. These drops are not included in the count of packets dropped by the policer, which causes policer statistics to underreport the total number of drops.

### Solution

This is expected behavior.

## Counter Reset When Editing Filter

### Problem

#### Description

If you edit a firewall filter term, the value of any counter associated with any term in the same filter is set to 0, including the implicit counter for any policer referenced by the filter. Consider the following examples:

• Assume that your filter has `term1`, `term2`, and `term3`, and each term has a counter that has already counted matching packets. If you edit any of the terms in any way, the counters for all the terms are reset to 0.

• Assume that your filter has `term1` and `term2`. Also assume that `term2` has a `policer` action modifier and the implicit counter of the policer has already counted 1000 matching packets. If you edit `term1` or `term2` in any way, the counter for the policer referenced by `term2` is reset to 0.

### Solution

This is expected behavior.

## Invalid Statistics for Policer

### Problem

#### Description

If you apply a single-rate two-color policer in more than 128 terms in a firewall filter, the output of the `show firewall` command displays incorrect data for the policer.

### Solution

This is expected behavior.

## Policers Can Limit Egress Filters

### Problem

#### Description

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 additional 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.)

### Solution

You can prevent this problem 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.