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

3. Building Blocks of Routing Policy

Welcome back. In this lecture we’ll talk about the building blocks of routing policies. What does a routing policy look like and what is it made up of? That is what we’re going to discuss in this lecture. Let’s begin. All right, so let’s start by talking about the components of a routing policy. All policies are composed of the following components that we configure. Number one, we have match conditions. Number two, we have actions.

A combination of actions and match conditions creates what is known as a term. So match conditions are criteria against which a route or packet is compared. You can configure one or more criteria to match. If all criteria match, one or more actions are applied. Actions are what happens. If all criteria match, you can configure one or more actions. What’s a term? Well, a term is a name structure in which match conditions and actions are defined. So it’s essentially a combination of match conditions and actions. We can define one or more terms inside a policy. Terms are basic building blocks of all Juno’s policies. They are essentially if then statements.

If all the match conditions specified in the from statement are true, all the actions in the then statement are executed. We can give names to terms for identification. The name has no effect on the evaluation of the term. Rather, it provides a meaningful identifier that we can use when referring to the term. This is a graphical representation of what a policy looks like. A routing policy can be made up of just one term or multiple terms, and each term has from and then statements. If everything in the from portion matches, then the then portion is evaluated. If we do not have a match, we move on to the next term and so on. So essentially, routing policies are made up of terms, and terms are made up of from statements and then statements.

All right, so how is a routing policy evaluated? The route is evaluated against the first term. When I say route, we’re actually trying to say incoming route or outgoing routes, right? So incoming and outgoing routes are evaluated against the first term. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and evaluation of the route ends. However, if the route does not match, or if no action is specified, or if the next term action is specified, evaluation continues to the next term. What this basically means is if the route is not a match, or if no actions have been specified, or the action is to move to the next term, then evaluation continues to the next term.

If the route matches no terms in the routing policy, the accept or reject action specified by the default policy is taken. This one is a graphical illustration of how a route is evaluated. So when we have an incoming route or an outgoing route, we try to evaluate that against a policy. Inside the policy, we look at term one. The action of term one is taken which could be accept or reject. If there is no action, or if the action is to move to the next term, we move on to the next term.

We keep moving this way, and when we reach the last term, the default action which could be accept or reject is applied if nothing else matches. All right, so we’ve been talking about routing policies all along. How does it actually look like? Right, so this is how a routing policy looks like. You have a policy statement and then you have a policy name. In this case, the name of the policy is my policy. You can see that the policy has a couple of terms. The first term is called as accept direct routes, and the second term is called as reject rip routes. The first term has a from statement and event statement. The from portion tries to match anything that comes from the protocol called direct and on the Interface Fe zero zero. If that matches, the route is accepted.

The second term, called reject rip routes, tries to match anything that comes from the rip protocol, and the action is to reject. It pretty simple, isn’t it? So it’s just a combination of from and then statements. And we can put some match conditions in the from portion and the actions in the then portion. All right, now let’s talk about routing policy match conditions. What are the conditions that we can try and match with? So each term in a routing policy can include two statements from and to. So far, we have only been talking about from statements, but we also have something called the to statement. We’ll understand what is the difference? So each term in a routing policy can include two statements, from and to define the conditions that a route must match for the policy to apply. In the from statement, you define the criteria that an incoming route must match.

That’s the key word. Incoming routes are associated with from statements. You can specify one or more match conditions, just like we saw right now. We looked at protocol direct, and Interface Fe zero. If you specify more than one match condition, they all must match the route for a match to occur. The from statement is optional. If you omit the from statement, all routes are considered to be a match. All routes then take the configured actions of the policy term. In the two statement, you define the criteria that an outgoing route must match. That’s the key word. Two statements apply to outgoing routes. You can specify one or more match conditions.

If you specify more than one, they all must match the route for a match to occur. The two statement is optional. If we omit both the from statement and the two statement, all the routes are considered to be a match. Now let’s talk about the actions that we can define in routing policy terms. Each term in a routing policy can include a vent statement which defines the actions to take. If a route matches all conditions in the firm statement and the two statement of the term, you can specify one or more actions in the then statement. There are three types of actions. Number one, we have flow control actions, which affect whether to accept or reject the route, and whether to evaluate the next term or next routing policy. Number two, we have actions that manipulate route characteristics.

And number three, we have trace actions which logs the route matches. We’ve spoken about trace actions in the earlier sections. I hope you’ve not forgotten that then statements are optional. If you omit it, one of the following will occur. Number one, the next term in the routing policy, if one present is evaluated. Number two, if there are no more terms in the routing policy, the next routing policy, if one present is evaluated. Number three, if there are no more terms or no more routing policies, the accept or reject action specified by the default policy is taken.

All right, so that’s all for this lecture. I know this might have been slightly confusing. There’s a bunch of things that we discussed over here. I’m going to encourage all of you to replay this lecture and take a look at it again. If you have any questions, please let me know in the discussions area. In the next lecture, we’ll talk about prefixed lists. I’d like to thank you for watching, and I’ll catch you in the next lecture. Thank you.

4. Prefix Lists

Welcome back. This is a short lecture on a topic called prefix lists. Let’s begin. All right, so what do we mean by a prefix list? Well, a prefix list is a named list of IP addresses configured under the Edit policy options hierarchy. So essentially a prefix list is just a list list of IP addresses which has been assigned and named. Once configured, these can be used in multiple places. So we can reference prefix list in multiple terms in a single policy or in different policies.

A prefix list can be used for both routing policies and firewall filters. And we are going to talk about firewall filters pretty soon. In this section, a prefix list can be used with two different commands. The first one is prefix and the second one is prefix filter. This is how a prefix list is actually configured. You have a name for the prefix list, which in this case is RFC 1918. And then you have the list of IP addresses.

And you can see that the prefix list called RFC 1918 is actually referenced in the policy called as my policy. And I’m going to show you on the screen how to actually configure a prefix list. So let’s dive straight into the terminal. All right, so I’m at the terminal. I’m going to enter configuration mode with the edit command and I’m going to type in Edit policy options. Hit enter. So right now we are under edit policy options. Irkey let’s start configuring a prefix list. So I’m going to say edit and the keyword is prefix list and we need to give a name.

So I’m going to say RFC 1918, hit enter. And now we can start adding the IP address ranges. So I’m going to say set. We can do a question mark. And you can see over here it says enter your address prefix. So I’m going to say set 100, zero, eight. And I’m also going to add one, 7216, twelve. And I’m also going to add set 192, 168, 00:24. We can do a show. And there we have it. So that’s our prefix list. I can now start using the prefix list in the from statements and the two statements of my routing policies to match incoming or outgoing routes. Let me show you one more example. Over here we have a prefix list which is called as customer list. And we have two routes over here.

Ten dot, one dot, one dot zero slash 24 and one 7216 dot 16, dot zero slash 24. We then have a policy which is called as my policy, which has two terms. The first term is called as customers and the second term is called as others. In the first term we have a firm statement which tries to match anything that has a prefix list of customer hyphen list. This configuration means it will try to match any incoming route that is pointed towards ten one. If it matches the action is to accept the route into the routing table. Otherwise, it would hit the second term, which is called as term others. And the action for that term is to reject the route. All right. Now let’s talk about prefix hyphen list hyphen filter. Like we just understood, prefix list can be used with two commands.

The first one is prefix hyphen list, which we saw right now. And the second one is prefix hyphen list hyphen filter. With prefix list filter, you can specify a match type of exact longer or or longer on the listed prefixes. You can also specify an optional action to be taken. If the filter matches, this action is executed immediately after the match occurs and the then statement is not evaluated. I know this sounds a little confusing right now.

What this actually means is if you’re going to use your prefix list with the prefix list filter command, we can optionally specify a match type which could be exact longer or or longer. And along with the match type, we can also specify an action. Normally, the action part happens in the Zen statement, but with prefix list filter, we can specify the action in the command itself. So what happens is we never actually reach the then statement.

As a result, the action specified in the then statement is not evaluated. Let me show you an example. All right, so we have the same prefix list over here which is called as RFC 1918. And we have the three address subnets. We also have a policy which is called as my policy. My policy has a firm statement which uses the command called prefix list filter. Over here, we have specified the name of the prefix list which is RFC 1918. We have also specified a match type which is or longer. And then you have an action that follows that. As you can see over here, the action is specified in the from statement itself. This happens with the command called prefix list filter.

Since the command has the action on it, we are never going to evaluate the action specified in the then statement. Having said that, what does it mean by exact longer or or longer? We are going to understand that in the next lecture. So in the next lecture, the discussion is going to be on route filters where we’ll understand these different types of matches. I’d like to thank you for watching, and I’m going to catch you in the next lecture. Thank you.