The route filter in routing policy termterm_1matches the following incoming IPv4 route addresses:

10.1.0.0/24

10.1.2.0/24

10.1.4.0/24

10.1.6.0/24

10.1.8.0/24

10.1.10.0/24

10.1.12.0/24

10.1.14.0/24

The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.

The route filter in routing policy termterm_1matches the following incoming IPv4 route addresses:

10.1.0.0/24

10.1.2.0/24

10.1.4.0/24

10.1.6.0/24

10.1.8.0/24

10.1.10.0/24

10.1.12.0/24

10.1.14.0/24

The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.

The first two bytes of the netmask value are binary 1111 1111 1111 1111, which means that a candidate route address will fail the match if the first two bytes are not 10.1.

The third byte of the netmask value is binary 1111 0001, which means that a candidate route address will fail the match if the third byte is greater than 15 (decimal), an odd number, or both.

The prefix length of the match prefix address is 24 (decimal), which means that a candidate route address will fail the match if its prefix length is not exactly 24.

As an example, suppose that the candidate route address being tested in the policy is 10.1.8.0/24 (binary 0000 1010 0000 0001 0000 1000).

When the netmask value is applied to this candidate route address, the result is binary 0000 1010 0000 0001 0000 0000.

When the netmask value is applied to the configured destination prefix address, the result is also binary 0000 1010 0000 0001 0000 0000.

Because the results of both AND operations are the same, the match continues to the second match criteria.

Because the prefix lengths of the candidate address and the configured destination prefix address are the same (24 bits), the match succeeds.

As another example, suppose that the candidate route address being tested in the policy is 10.1.3.0/24 (binary 0000 1010 0000 0001 0000 0011).

When the netmask value is applied to this candidate route address, the result is binary 0000 1010 0000 0001 0000 0001.

However, when the netmask value is applied to the configured destination prefix address, the result is binary 0000 1010 0000 0001 0000 0000.

Because the results of the two AND operations are different (in the third byte), the match fails.

Accepting Incoming IPv4 Routes with Similar Patterns But Different Prefix Lengths

Accept incoming IPv4 route addresses of the form 10.*.1/24 or 10.*.1.*/32:

The route filter match criteria10.0.1.0/24 address-mask 255.0.255.0matches an incoming IPv4 route address of the form 10.*.1/24. The route’s prefix length must be exactly 24 bits long, and any value is acceptable in the second byte.

The route filter match criteria10.0.1.0/32 address-mask 255.0.255.0matches an incoming IPv4 route address of the form 10.*.1.*/32. The route’s prefix length must be exactly 32 bits long, and any value is acceptable in the second byte and the fourth byte.

Evaluation of an Address Mask Match Type with Longest-Match Lookup

This example illustrates how a longest-match lookup evaluates a route filter that contains twoaddress-maskmatch types. Consider the route filter configured in the routing policy termterm_3below:

Suppose that the incoming IPv4 route source address 10.1.1.0/24 is tested against the route filter configured in the policy termterm_3:

The longest-match lookup tree for routing policy termterm_3contains two match prefixes: one prefix for10.0.1.0/24 address-mask 255.0.255.0and one prefix for10.0.2.0/24 address-mask 255.240.255.0. When searching the tree for the longest-prefix match for a candidate, the longest-match lookup considers the number of contiguous high-order bits in the configurednetmask-valueinstead of the length of the configureddestination-prefix:

For the first route filter match criteria, the longest-match lookup entry is 10.0.0.0/8 because the netmask value contains 8 contiguous high-order bits.

For the candidate route address 10.1.1.0/24, the longest-match lookup returns the tree entry 10.0.0.0/12, which is corresponds to the route filter match criteria10.0.2.0/24 address-mask 255.240.255.0.

Now that the longest-match prefix interm_3has been identified for the candidate route address, the candidate route address is evaluated against the route filter match criteria10.0.2.0/24 address-mask 255.240.255.0:

To test the incoming IPv4 route address 10.1.1.0/24, the netmask value 255.240.255.0 is applied to 10.1.1.0/24. The result is 10.0.1.0.

To test the configured destination prefix address 10.0.2.0/24, the netmask value 255.240.255.0 is applied to 10.0.2.0/24. The result is 10.0.2.0.

Because the results are different, the route filter match fails. No actions, whether specified with the match criteria or with thethenstatement, are taken. The incoming IPv4 route address is not evaluated against any other match criteria.

*************************************HTH.Accept this as solution if it resolved your issue.Kudos would be appreciated too.

Re: Policy Statement

‎11-30-201708:02 PM

Unlike firewall filters, the default action on policy-statement is accept . So when you dont specify a default term to reject/deny everything else other than your match condition, everything else will be accepted. root> show configuration policy-optionspolicy-statement Test { term 1 { from { route-filter 2.2.2.2/32 address-mask 255.255.255.0; } then accept; }}

you need to add term 2 with action reject . If you have multiple policies use action as next-policy and configure reject on the last policy.