80. Route Filters
Let’s talk about roof filters. What are root filters? Well, rock filters are list of prefixes configured to be used within a single routing policy or policy term. Unlike a prefix list, which is configured once and used multiple times within a configuration, a root filter is configured within a single routing policy or a policy term. Unlike prefix lists, these are not reusable, but rather are specific to the policy or term in which they are configured. Like with the prefix list, philtre statement and optional action can be specified to be taken if the root filter statement matches root filters, support the following match types exact or longer, longer up to and prefix lenth range. Let’s talk about each one of these in detail.
We’ll start with the first match type exact. Here’s the configuration statement from Root Filter and then we have the prefix which is one seven two 16 0 0 select 16. And the match type is exact. In this case, only roots that match that given prefix exactly are considered to be a match in the above example. Only one seven to . 16 . 0.01. Last 16 is considered to be a match. Here’s a configuration example. We have a policy statement called My Policy, a term called Term A that is configured to match a root filter, which is one seven two 16 0 0 last 16. The match type is exact and the action is except notice that the action is part of the firm statement. We do not need to specify if then statement.
This is similar to prefix list filter that we talked about earlier. The second match type is or longer. Here’s the configuration statement from Routt filter. The prefix range. One seven two 16 0 0. Last 16. And the match type or longer. In this case, only roots within the specified prefix with prefix length equal to or greater than the given prefix lenth are considered to be a match. So here. One seven two 16 0 0 last 16 is an exact match and also roots within the subset of one seven two 16 0 0 as last 16 with a prefix lenth between Sless 17 and Sless 32 are considered to be a match. Remember, the bigger your subnet mask, the longer your prefix length. And the maximum number of bits in a subnet mask is/32. So that’s the longest. You can go. So all routes within the subset of the given prefix.
One seven two 16, 0 zeros, less 16 with a prefix length between/17 and/32 are considered to be a match. Let’s look at an example of what matches and what doesn’t match. Here we have examples of prefixes that will match. Notice that every prefix over here is a subset of one seven two 16 0 0 SLAs 16 and has a longer subnet mask. So its last 17/twenty/twenty four,/twenty six/twenty nine. But all of these belong to the subset of the original prefix. Here’s an example of what does not match. One seven two 16 0 0 /. Fifteen. That’s a shorter prefix lend. So that is not considered as a match. 172 17 0 0, sless 16. That’s a completely different prefix. So that is not considered as a match. And you also have one 90 to 168.00/24 and 10.0.0.0/eight.
Here’s a configuration example. We have the same policy statement, same term from root filter one seven two 16 0 0 last 16. The match type is or longer. The action is set to reject. Let’s look at the third match type called longer. Here’s the configuration statement from Routt Filter. The prefix and the match type, which is longer. In this case, only roots within the specified prefix with prefix lent greater than the given prefix lenth are considered to be a match. So here. One seven two 16 0 citrus last 16 is not a match. Because we are looking for longer prefixes. Root within the subset of one seven two 16 0 0 last 16 with a prefix length between/17 and/32 are considered to be a match. But the prefix itself is not a match because that is an exact match and we are looking for longer matches. Here we have examples of what matches. So one seven two 16 0 0 is less 17. That’s going to be a match.
And all longer prefixes will be considered as a match. Examples of not matches. Given prefix itself, which is one seven two 16 0 0 last 16, is not considered a match. One seven two 16 0 0 /ed. Fifteen is not a match because that’s a shorter prefix. One seven two 17, 0 0 last 16. That’s a completely different prefix. So that’s not considered as a match. Here’s a configuration example. From root filter one seven to 16, 0 0, let 16 longer reject. Let’s look at the fourth match type, which is up to. Here’s the configuration statement from Routt filter one seven two 16 0 0, SLAPP 16 up to/24. The up to match type is similar to or longer match type. Except that it provides an upper limit to the acceptable prefix lenth.
Only routes within the specified prefix with prefix lend greater than or equal to the given prefix lend. But less than or equal to the up to prefix lenth are considered to be a match. Let’s look at examples of matches and not matches. So in this case, one seven two 16 0 0 last 16 is a match and roots within the subset of one seven two 16 0 0 last 16 with a prefix lent between/17 and/24 are considered to be a match. Let’s look at examples of matches. So one seven two 16, 0 0 slat 17.
That’s a match. And any prefix within the subset. Up to/twenty four is a match. Example of not matches. You’ll notice here we have prefixes longer than /ed. Twenty four, for example, one seven two 16. 12. 128,/26. Here is a configuration example from Routt filter. One seven two 16 0 0 sliced 16 up to/24 reject. Let’s look at the last match type, which is prefix lend range. Here’s the configuration statement from Routt Filter one seven two 16 0 0 last 16 prefix lenth range./twenty two./twenty four. The prefix lenth 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 lenth. Only routes within the specified prefix with prefix lend greater than or equal to the first given prefix lenth but less than or equal to the second prefix lenth are considered to be a match.
So in this case, one seven two 16 0 0 is less, 16 is not a match. Because they’ve given prefix has a length of slack. Sixteen. What we’re looking for a length between/twenty and/twenty four. Roots within the subset of one seven two 16 0 0 is less 16, with a prefix length between/20 and/24 are considered to be a match. Here we have examples of what matches.
So one seven two, 16, 30, 2.0/20. That’s a match. One seven two 16, 38, . 0/twenty four. That is also a match because the prefix LAN has to be between/20 and/24. Here’s examples of what does not match their given prefix itself is not matching because the prefix lenth is not what we’re looking for. And then we have other examples of not matches include one seven two 16, 12. 128,/26, because the prefix lent is greater than what we are looking for. Here’s a configuration example from Routt filter. One seven two 16 0 0 sliced 16 prefixed lenth range/26 to/29 reject. So the key takeaway here is that route filters are similar to prefix lists. They are a list of prefixes, but they are configured to be used within a single policy or a single term. And they have five match types, exact longer or longer, up to and prefixed length range.
81. Policy Chaining
Let’s talk about policy changing. If we have multiple routing policies configured on the device and each of these policies has multiple terms configured within them, how is a route evaluated against these policies and terms? That’s what we’re going to understand in this lecture. On the screen now, I have an illustration containing multiple policies and multiple terms when we have an incoming or an outgoing route. How are these policies applied on that route? Well, let’s talk about it. So when we have an incoming or an outgoing route, the route is evaluated against the first term in the first routing policy. If it matches, the specified action is taken. If the action is to accept or reject the route that action is taken. An evaluation of the route ends. However, if the next term action is specified or if no action is specified, or if the route does not match, the evaluation will move on to the second term, which is described in step number two. So there are three possibilities to move to the next term. The action next term could be specified or no action has been specified or the route may not have matched the first term in each of these cases. The evaluation will move to the second term.
We’ll talk about that in step number two. On the other hand, if the next policy action is specified, any accept or reject action specified in this term, meaning the first term is skipped, all remaining terms in this policy are skipped. Any other actions will be taken and the evaluation will continue to the second policy, which is described in step number three. Let’s now talk about step number two, where the second term will be evaluated. The route is evaluated against the second term in the first routing policy, if it matches, the specified action is taken, if the action is to accept or reject the route that action is taken and the evaluation of the route ends. However, if the next term action is specified or if no action is specified, or if the route does not match, the evaluation continues in a similar fashion. And moves on to the third term, fourth term and so on until it reaches the last term in the first routing policy. If the next policy action is specified, any accept or reject action specified in this term, meaning the second term is skipped all remaining terms in this policy or skipped any other actions are taken.
And the evaluation continues to the second policy, which is described in step number three. Let’s now move on to step number three. If the route does not match a term or matches a term with a next policy action in the first routing policy, it is evaluated against the first term in the second routing policy. The evaluation continues in a similar fashion until the route matches a term with an accept or reject action defined or until there are no more routing policies to evaluate. If there are no more robbing policies, then the accept or reject action specified by the default policy is taken. Let’s summarize this with the illustration.
So we have an incoming or an outgoing route. It will first be evaluated against the first policy and the first home within the first policy. If the action is to accept or reject the route that will be taken and evaluation will stop, or if no action is specified or the next term action is specified, or if the route has not matched, it will move on to term two. And the same evaluation pattern will continue. It will try to look for and accept or reject route and move on. If the route has not matched any term in policy one or if it has matched a term with a next policy action evaluation will move on to policy to and we’ll continue to evaluate in a similar fashion. Moving on in a similar fashion will reach the last policy policy in. Here again, we’ll try to see if we have an accept or reject action. When there are no more terms or no more policies left to evaluate, we’ll take the accept or reject action defined in the default policy.
82. Applying Routing Policies
Now that we’ve understood what a routing policy is and what it can do for us, let’s understand how to apply a routing policy. Depending on the routing protocol, you can apply import and export policies at multiple levels of the Iraqi. For example, a rip import policy can be applied either at the global or the group level or the neighbor level. This will affect routes from either all peers or from a specific neighbor. A group export policy may only be applied at the rap group level, allowing you to alter routing knowledge for a specific set of peers. Only. For Border Gateway Protocol, it’s likely a different BTP import and export policies can be applied at the global group or neighbor level for SPF. It’s even more different or SPF allows only protocol level. Import and export policies. So from a configuration standpoint, this is how it looks like here, we’re looking at a configuration example for RIP. And as you can see here, under the edit protocols hierarchy, you can apply an import policy only. But when we go down to the group level, we can apply in import or export policy.
But when we go down further to the neighbor level, we can only apply any import policy. Talking about BGP, you can apply both import and export policies at the protocol level. You can apply both import and export policies at the group level and the same thing applies at the neighbor level. When we talk about, oh, SPF, you can only apply import and export policies at the protocol level or the global level. Let’s take a look at this on the Junos terminal. All right, I’m here at the Junos terminal and I’m already in the configuration mode. I’ll first do edit protocols, question mark, and here we have the different protocols that we can configure. Let’s go to the RIP routing protocol. So added protocols, RIP. By the way, we do not have to know the configuration of these protocols at the JNCIA level. Right now we are only trying to understand how we can apply a routing policy. So edit protocols rip when we do set space question. You will notice that here we are only able to apply an import policy. So if we did set import question mark. You will notice that I have the different rip policies that I can apply as an import policy. This goes back to what we discussed earlier, a routing policy by itself does not mean that it’s an import or an export policy. It depends on the way you apply it. So, for example, if I wanted to use this as an import policy, I can call that over here. Or I could also call that as an export policy. A policy by itself does not define whether it is going to be used as an import or an export policy. It depends on how we can figure it. So at the added protocols level for rip routing protocol, you can only apply an import policy.
Now let’s go down to the group level. So from here, let’s do edit group’s. Or edit group, and we’ll need to provide a group name. Let’s just call this as group one. And if I do set space question mark, you will notice at the group level we can apply both import and export policies. Now, let’s go down one level to the neighbor. So if we did set neighbor and I’m just going to provide the interface name over here. So that’s my neighbor, said neighbor. And if I do a question mark here, you’ll notice I can only apply an import policy. So talking about RIP, you can apply an import policy at the global level, group level or NABOR level. But an export policy can only be applied at the group level. Now, let’s take a look at BGP. We’ll go to the top and we’ll say edit protocols BGP. And if we do a sex based question mark, you will notice we have the option to apply an export policy or we can also apply an import policy. Now, let’s go down to the group level. So ctrl c two exit set group.
And if we do a question mark here, we need to provide a group name. Let’s just call it group one. And if I do a question mark here, we can apply an export policy and an import policy. Now, let’s go down to the neighbor level ctrl c to exit out neighbor, and let’s do a question mark. Willing to provide a neighbor address. So I’m going to say one one, one, one question mark. And you’ll notice over here we can apply an export policy or an import policy. So for border. Get a protocol. You can apply import and export policies at all levels, at the global level, at the group level and at the neighbor level. Let’s take a look at SPF control you to erase the command. We’ll go to the top. Let’s do edit protocols or SPF.
And let’s do sex based question, Mogg. And here we have the option to apply an import policy or an export policy. With SPF, you have the concept of an area. Let’s try to get into an area. So let’s do set area. 0.0.0.0. And if I do a question mark here, you’ll notice we do not have the option to apply here policy. So for SPF, you can only apply import and export policies at the global level. The important thing to keep in mind is that the level at which you can apply a policy depends on the protocol that you’re configuring. Also, keep in mind, routing policies by themselves do not define if they are an export policy or an import policy. It depends on how we apply it.
