Practice Exams:

Juniper JNCIA JN0-103 – Routing Policy and Firewall Filters Part 3

  1. Prefix List vs. Prefix List Filter

Welcome back. In this lecture, we’re going to talk about the difference between prefix list and prefix list filter. Originally, I had planned to talk about route filters in this lecture. However, after the previous lecture on prefix list and prefix list filter, I got a feeling that I might have left you too confused. Which is why I decided let’s do one more lecture on the differences between prefix list and prefix list filter. Hopefully, this one should clear the confusion, if any. Let’s begin. All right, so I have a prefix list configuration on the screen right now. The prefix list is named as RFC 1918, and it has three IP addresses ten 000817, 2160 00:12, and 192-1680 00:16. This prefix list is used in the firm statement of a policy called My Policy, and the action is to accept the route.

Let’s take a look at what happens to an incoming route when evaluated against my policy. On the left hand side, I have the policy configuration, and on the right hand side, I have a Juno’s device. Like we know, every Juno’s device has a routing table. Let’s assume that we have a routing table with just the default route zero. I know this routing table is not complete. Apart from the destination, we also have something called as the route type, which is like static route or local routes or OSPF routes and so on. And then we also have the next top IP address. Right now, we are only trying to understand what happens to an incoming route based on the destination.

 So right now, we have a routing table which has the default route in it, which is zero, zero, zero, slash zero. Let’s say there’s a new incoming route. The route is for the destination 100 zero, zero slash eight. Comparing the incoming route with the prefix list RFC 1918, we see that it is an exact match. And if it belongs to prefix list 1918, the action is to accept the route and import it into the routing table. So now the updated routing table would look like this. Now let’s try this one more time for a new destination. So there’s an incoming route for one 72160 zero. We compare this with the prefix list RFC 1918. We can see that it is an exact match, which means this route will be accepted and installed into the routing table. However, what happens if we have an incoming route that looks like this? The incoming route is for a destination of 170 2160 00:24.

Looking at this one, we can quickly figure out it is not an exact match. The prefix list states one 72160 zero, while the incoming route is one 7216 00:24. These are not exact. However, since we now know subnetting, we can quickly figure out that one 72160 00:24 is a subset of one 7216 dot zero 00:12. Will this route be accepted into the routing table? The answer is no. If we are using the command called prefix list. It always looks for an exact match. Since this one is not an exact match, it will not be accepted into the routing table. And this is where prefix list filter comes into the picture. With prefix list filter, we can specify additional match types like longer or or longer. Let’s take a look at it. All right, so now we have a new configuration. The prefix list is the same RFC 1918 with the three IP addresses. The policy statement is the same my policy.

But the from statement has changed. We are not using prefix list anymore. We are using prefix list filter for the prefix RFC 1918 with the match type or longer, and the action is to accept it. We have the default route in the routing table, which is for zero, zero, zero. Let’s assume that we have an incoming route for 170 216 00:24. This IP address is a subset of the IP address defined in the prefix list. One, 72160, zero. However, the prefix list filter command says if the incoming route is longer than the route defined in the prefix list, it’s okay to be accepted.

So now this route will also be imported into the routing table. This is the difference between prefix list and prefix list filter. Prefix list can only do an exact match, but prefix list filter can do additional match types like longer or longer and so on. We are going to take a look at the additional match types in the next lecture on route filters. I hope that I have been able to clarify the difference between prefix list and prefix list filter. If you still have a question, please let me know in the discussions area. In the next lecture, we’ll start with a topic called route filters. I’d like to thank you for watching and I’ll catch you in the next lecture. Thank you.

  1. Route Filters

Welcome back. In this lecture we’ll talk about route filters. Let’s begin. All right, so what do we mean by route filters? Well, route filters are very similar to prefix lists and prefix list filters, but with some small differences. Let’s take a look at it. Route filters are list of prefixes configured within a single route policy or policy term. Unlike prefixed list, they are not reusable, but rather are specific to the policy or term in which they are configured. So a route filter is similar to a prefix list, but its scope is only within a single routing policy or a single policy term. Like with the prefix list filter statement, you can specify an optional action to be taken if the route filter statement matches like we did accept or reject with the prefix list filter command. We can also do that with route filters. This action is executed immediately after the match occurs and the then statement is not evaluated. We’re going to talk about the following different match types.

You have exact. You have or longer and there’s no space in between. It should be or longer as a single word. You have longer, you have up to and you have prefixed length range. Let’s take a look at them one by one. The first one is exact and I have a command on the top which is an example of how you would use the exact keyword. So from route filter and then you have your prefix, which is 100 zero eight and the match type is exact. Only routes that match the given prefix exactly are considered to be a match. In the example above, there’s only one match and that is 100 zero eight. And I have a policy configuration example. So you have policy statement, which is my policy. You have a term which is term one which has a from statement that includes a route filter for the prefix 100 zero eight with the match type as exact. And the action is to accept the route.

The next one is or longer. An example for that would be from route filter 170 2160 00:16 or longer. Only routes within the specified prefix with the prefix length equal to or greater than the given prefix length are considered to be a match, which means anything that falls within 170 216 00:16 having a prefix length of equal to or greater than 16 is considered to be a match. So in the above example, one 72160 slash 16 is an exact match. Also, routes within the subset of 170 2160 00:16 with a prefix length between 17 and 32 are considered to be a match. Examples of matches one 7216 dot zero zero slash 17, one 7216 dot 128 dot zero slash 17, one 7216, dot 32 dot zero slash 20 because it falls between slash 17 and slash 32 and then one 7216 dot 38 dot zero slash 24 and so on. Examples of not Matches one 72160 00:15 because the prefix length is lower than 16 one 7217 16. This one is not a match because it does not fall within one 7216.

It is actually one 7217 and then 192, so on. Here’s a configuration example policy Statement my policy term is term one from RouteFilter 170 216 16, or longer reject, so anything that falls within that prefix or longer will be rejected. The next one is longer. An example for that would be from route filter 170 2160 00:16 longer. Only routes within the specified prefix with prefix length greater than the given prefix length are considered to be a match. The difference between this one and the previous one is or longer allows an exact match or anything greater than that, while longer only allows for anything that is greater than the given prefix. So in this example, one 7216 00:16 is not a match. Routes within the subset 170 216 00:16 with a prefix length between 17 and 32 are considered to be a match. Examples of matches one 7216 17, one 7216 128 00:17, one 7216 32 00:20, and so on.

Examples of not matches would be one 7216 00:15, one 7217 00:16, and so on. A configuration Example the same policy, the same term from route filter 170 2160 00:16 longer reject. The next one is interesting.

It is called as up to from route filter one 72160 00:16 up to 24. The upto match type is similar to the or longer match type, except that it provides an upper limit to the acceptable prefix length. Only routes within the specified prefix with prefix length greater than or equal to the given prefix length but less than or equal to the up to prefix length are considered to be a match. In the above example 170 2160, one six is a match, and routes within the subset 170 2160 one six with a prefixed length between 17 and 24 are considered to be a match. Examples of matches one 7216 00:17, one 7216 128 00:17, one 7216 320217 216 38 00:24. Examples of not matches one 7216 twelve 128 26 it becomes greater than 24, hence it is not acceptable. Similarly, one 7216 1192-2917 216 15, and so on.

A configuration Example the policy statement is my policy. The term name is term one from RouteFilter ten dot up to slash 31 reject. That means anything that falls within that prefix length range will be rejected. The next statement says route filter zero. This statement will match anything that does not match the above statement, and the action for that would be from the then statement, which is to accept it. So this policy rejects everything that falls within the given prefix length and accepts everything else.

The next one is prefix length range, and this one is very similar to the previous one, called up to. An example from route filter 170 2160 00:16 prefix length range slash 20 to slash 24. The prefix length range match type is similar to the up to match type, except that it provides both a lower and an upper limit to the acceptable prefix length. Only routes within the specified prefix with prefix length greater than or equal to the first given prefix length but less than or equal to the second prefix length are considered to be a match.

In this example, one 7216 00:16 is not a match because the prefix length of slash 16 does not fall within 20 and 24 routes within the subset of one 7216 16 with a prefix length between 20 and 24 are considered to be a match. Examples of matches one 7216, 320217, 216, 38, 00:24 and so on. Examples of not matches one 7216 00:17, one 7216, twelve, 128-2617, 216, 1192-2917, 216, 00:15 and so on. An example configuration would look like this policy statement. My policy term name is term one from route filter 192, 168, 100, slash 24 prefix length range between slash 26 and slash 29 reject.

You have a then statement with an action of accept. However, if the route matches the route filter statement, the action is specified right over there, which is to reject the route. Before we end this lecture, I’d like to take you to the terminal and show you where do we have this option called route Filter. I’m sure you’ve already guessed it looking at the configuration, but I just want to show you for a second. So I’m back at the terminal. As you can see, I’ve already logged in.

I’m going to first enter configuration mode with the edit command and then I’m going to enter edit policy options. Let’s start by creating a new policy. I’m going to call it as my policy. All right? Now let’s start configuring with the set command. Let’s do a question mark first. Let’s do set from and let’s do a question mark over here. All right, so here we have all the three options. The first option, called Prefix list, is available over here. The second option, called Prefix list filter, is available over here. And the third option that we discuss right now, called Route filter, is also available over here.

Right? So when you are defined your policies, you can be flexible with any one of these options. You can use any one of them depending on your use cases. All right, so that’s all for this lecture. In the next lecture, we’ll talk about policy chaining. I’d like to thank you for watching and I’ll catch you in the next lecture. Thank you.