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

7. Policy Chaining

Welcome back. In this lecture we’re going to talk about policy chaining. If we have multiple policies consisting of multiple terms, how does the evaluation actually happen? How are the policies interconnected? That is what we’re going to talk about in this lecture.

Let’s begin. On the screen right now, I have the illustration of a routing policy, in fact, multiple, multiple routing policies. On the top left hand side, we have a route. If we have an incoming or an outgoing route, how does the route actually match the policy? That’s what we are trying to understand. In this diagram.

We have Policy One, which consists of multiple terms, and then we have Policy Two, which consists of multiple terms and so on until we reach Policy N. Let’s say we have an incoming or an outgoing route that needs to be evaluated. So it first hits policy one. Inside policy one. It tries to match term One. If it matches, the action is applied, which could be to accept or reject the route.

However, if the term does not match, it moves on to the next term. It could also be possible the action on term One says move on to the next term. Even in that situation, it will move on to term Two, right and so on. We reach term three. If term three is not a match, it moves on to Policy Two. It evaluates term one, term two, term three of policy two, and so on until it finds a match. Let’s understand this in a bit more detail. Routing Policy Chain evaluation point number One the route is evaluated against the first term in the first routing policy, which is term one of Policy One. 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 next term action has been specified, or if no action has been specified, or if the route does not match, the evaluation continues to the second term as described in step number two.

So this means if the route does not match the first term, or if there is no action that has been specified, or if the action is to move on to the next term, we then move on to term two of Policy One, which is described in step number two. On the other hand, if the next policy action has been specified, any accept or reject action specified in this term is skipped. All remaining terms in the policy are skipped, all other actions are taken and evaluation continues to the second policy, which is described in step number three. This means if the action on the matching term is to move on to the next policy, we will move on to policy number two from policy number One and this is described in step number three. Let’s talk about step number two first.

Step number two is about evaluating the second term in the first policy. So 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 has been specified, or if no action has been specified, or if the route does not match, the evaluation continues in a similar manner against the last term in the first routing policy. So if nothing matches, it keeps moving on from one term to another until it reaches the last term of the first routing policy. However, if the next policy action has been specified, any accept or reject action specified in this term is skipped. All remaining terms in this policy are skipped, all other actions are taken, and evaluation continues to policy number Two, which is described in step number three. What is 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. So at this point we have moved on to Policy Two and Term number One of Policy Two. This evaluation continues 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 routing policies, then the accept or reject action specified by the default policy is taken.

Now this diagram should make more sense so we have an incoming route or an outgoing route that needs to be evaluated. It first hits policy one. We first try to match term one of policy one. If it matches, and if the accept or reject action has been specified, it is performed and evaluation stops. However, if term one is not matching or the next term action has been specified, we move on to Term Two. Similarly, we keep moving on from one term to another until we reach the last term of the first routing policy. If nothing matches, we move on to Policy Two. We may also move on to Policy Two. If any term in Policy One has the action as next policy, we keep evaluating this way until we reach the last policy. If nothing matches, we take the action defined in the default policy. I want to show this to you on the terminal. All right, I’m back over here.

I’m first going to enter the configuration mode with Edit and I’m going to enter Edit policy options and I’m going to do a show. Let’s look at this for a second. So I have a policy statement which is called as policy hyphen one. And in that I have three terms. Term one, term two and term three. Term One tries to match anything that comes from the protocol static. If yes, then it accepts the route. If Term One does not match we move on to term two, which tries to match routes on the interface Fe Zero. If it matches, the action is to move to the next term.

When we reach term three, we try to match anything that comes from the interface Fe 10. If it matches, it then moves on to the next policy. Don’t go by the logic of this policy. There is, as such, no logic in the way I built this policy. I did this just to show you how we can use next term and next policy. Otherwise, this policy does not make any sense at all. Right? We just need to understand how it looks like when we use next term and next policy. All right? So that was a small discussion on policy chaining. That’s all for this lecture. In the next lecture, we’ll talk about how to apply routing policies. I’d like to thank you for watching and I’ll catch you in the next lecture. Thank you.

8. Applying Routing Policies

Welcome back. In this lecture we’ll discuss how to apply routing policies. Let’s begin. So, we’ve been discussing about routing policies all along this section. We’ve understood what are routing policies, what are the building blocks of routing policies, what do we mean by import and export routing policies? What do we mean by prefix list, prefix list, filter, filter and route filters? We’ve understood the match types. We’ve also spoken about policy chaining. So we now know how to create routing policies. How do we put them into the configuration? How do we make use of them in the configuration? That is what we’re going to discuss. Let’s talk about it. Depending on the routing protocol, you can apply import and export policies at multiple levels of the Iraqi. So where you apply the routing policy depends on which routing protocol are you dealing with?

Routing information protocol has its own levels at which you can apply. BGP has its own levels and OSPF has its own levels where you can apply the routing policies. Talking about Rip first, rip import policies can be applied at either the global or the neighbor level. This will affect routes from either all peers or from a specific neighbor depending on where you applied the import policy. On the other hand, rip export policies may only be applied at the group level, allowing you to only alter routing knowledge for a specific set of peers. Talking about BGP or border gateway protocol for BGP import and export policies can be applied at global, group or neighbor levels. And talking about OSPF openshortest path first. It only allows protocol level import and export policies. Let me show you some examples. This configuration shows how to apply routing policies on the rip protocol. So you can see that we are in the rip configuration hierarchy.

We can apply the import policy at the global level and we can also apply the import policy down below at the neighbor level. But export policies can only be applied at the group level. Let me show this to you on the console. All right, I’m back over here. I’ll first enter configuration mode using the configure command and I’m going to do edit protocols rip. And when I do set question mark, you can see that I can apply an import policy over here, but I do not have the option to apply an export policy over here. So only import policies can be applied at the global level. Let’s try to create a group. So I’m going to say set group and I’m going to call this as group one.

By the way, you don’t have to remember this configuration. I’m just trying to show you where you can apply the import and export policies. Hit enter and I’m going to do set space question mark. You can now see that we can apply import policies over here as well. So import policies can be applied at the group level or at the global level, but I still do not have the option to apply an export policy. So I’m going to do this. I’m going to enter the group edit group one. In fact, I just realized that we are still at the global level. We have not entered the group. So what I said just a minute ago was just a repetition of what I said over here.

If you did not understand that, please forget it. So I’m going to enter Edit Group Group One and when I do a question mark over here, now I can apply both import and export policies. So inside the group we can apply both import and export policies, but at the global level we can only apply import policies. And I’m also going to do this Set Neighbor Question Mark and I’m going to put the interface name hit Enter. And when I do set, in fact I need to get into that neighbor edit Neighbor when I do a Set Space Question mark. Now you can see that we can only apply import policies. So that means export policies can only be applied at the group level, while import policies can be applied at the global level, at the neighbor level and at the group level.

This is for Rip routing information protocol on the screen. Now we have an example for border gateway protocol. You can see that we can apply import and export policies at the global level, at the group level and at the neighbor level. Let’s check this out on the console back over here. I’m first going to go to the top of the configuration and let’s do Edit protocols PGP hit Enter. Let’s do set space question mark. So you can see that we can apply export policies over here and we can also apply import policies over here, right? So let’s do edit group and let’s call this as group one. And let’s do a set over here, set Space Question Mark you can see that over here as well. We can apply export policies and import policies inside that group, right? And I’m also going to do Edit neighbor question mark let’s put a neighbor address one one hit Enter. Let’s do setspace. Question mark. You can see that we can apply export policies over here and import policies over here as well. So when it comes to BGP, we can apply import and export policies at the global level, at the neighbor level, and at the group level.

By the way, you don’t have to worry about all this configuration guys, this is not for the exam. We are just trying to understand the different levels at which we can apply the import and export policies. Let’s now talk about OSPF. With OSPF, things are pretty simple. We can only apply import and export policies at the global level or the protocol level, nowhere else. Let’s take a look at it back over here. I’m going to go to the top of the configuration and let’s do edit protocols. OSPF. OSPF. Hit enter. And when I do a set space question mark, we can see that we can apply export policies over here and import policies over here, right?

However, if I did something like this edit area space question mark, let’s do edit area zero zero. Now, we should know the concept of area zero in OSPF, right? So I’m going to say enter, and when I do a set space question mark, you’ll notice that we do not have the option to apply import or export policies. So with OSPF, it’s very simple. You just apply at the protocol level or the global level. All right, so that’s it for this discussion. On applying routing policies, in the next lecture, we’ll talk about firewall filter. If you have a question, please let me know in the discussions area. I’d like to thank you for watching, and I’ll catch you in the next lecture. Thank you.

9. Firewall Filters

Welcome back. In this lecture we are going to talk about a very interesting topic which is known as firewall filters. It is quite similar to routing policies that we discussed in the earlier lectures. Let’s begin. All right, so what do we mean by firewall filters? Firewall filters are used to control traffic passing through a Juno’s device. These are also called as access control list on some other vendor equipments. So what can a firewall filter do? Well, firewall filters can be used to do the following number one, we can use it to restrict traffic which is designed for the routing engine based on the source protocol and application. Number two, we can also use it to limit the traffic rate of packets designed for the routing engine to protect against flood or denial of service attacks.

Basically, firewall filters are configurations which can be used to protect or filter the packets which are designed for the routing engine itself. For example, ICMP packets, for example SSA sessions, telnet sessions and so on. Very important, firewall filters are stateless in nature, which means every packet is examined individually. Unlike a stateful firewall that tracks connections and allows you to specify an action to take on all packets within a flow, a stateless firewall has no concept of connections. So what is the difference between stateful and stateless? Well, with stateful connections or stateful firewalls, you allow traffic in one direction when the response traffic comes back.

You don’t have to allow that because it is part of the same connection which allowed the traffic inbound. So it maintains the session state or the connection state and allows the response back. With stateless firewalls it does not work that way. You allow connection one way and you also have to allow the response back. There is no concept of connection state because the system does not keep state information on connections. You must explicitly allow traffic in both directions for each connection that you want to permit. This is a very important concept is firewall filters are stateless in nature. There is no connection tracking or state tracking. What are the components of a firewall filter? Routing policies and firewall filters have a common structure. The fundamental building block of a firewall filter is what is known as a term. Firewall filters require at least one term.

A term contains match conditions and actions. If all match conditions are true, the action specified within the term is taken. If no match conditions are specified, all traffic matches the term and is subjected to the stated term. So structurally, firewall filters are same as routing policies. You have a term, a term has match conditions and actions. Firewall filters always include a default term that discards all packets that the configuration does not explicitly permit through the defined terms. This is very critical and very important to keep in mind when you’re designing firewall filters. At the end of all the terms is an implicit term or a default term which drops everything. So if there’s something that we have not allowed, it is definitely going to be dropped.

This is a very important design consideration when implementing firewall filters. Keep in mind that the order of terms is important and can impact the results. The order of terms is very important. In the next lecture, I’m going to show you an example which will demonstrate the importance of order of terms. It can completely change the way the traffic is processed. So talking about the default term, the default term is responsible for discarding all packets that do not match any term. And this is how it looks like. You have the implicit term which has an action of discard.

This is just for understanding purposes. When we look at firewall filters on the device, we’ll notice that there is no term like this. So this one is just shown for us to understand. As such, you don’t have a term called implicit rule. It is hidden, but it is there and it drops all unmatched packets. Some more information in the firm statement in a firewall filter term, you specify characteristics that the packet must have for the action. In the subsequent then statement to be performed, the characteristics are referred to as match conditions. This is exactly what we saw in routing policies. You have a firm statement that defines the match conditions. If it matches, you have a then statement that defines the actions that need to be taken.

If a firewall filter term contains multiple match conditions, a packet must match all match conditions to be considered a match for the firewall filter term. What this essentially means if the firm statement has multiple conditions that need to be matched, everything has to be matched for it to be considered as a match. For example, in the firm statement, if I specify the protocol and the source address, both of them have to match. It’s not that only the protocol can be a match or the source address can be a match. Both have to match for the action to be taken. The scope of match conditions that we specify in a firewall filter term depends on the protocol family under which the firewall filter is configured.

That means if the firewall filter is created for IPV four traffic, we’ll only have actions that apply for IPV four traffic. If the firewall filter has been created for IPV six traffic, the actions that we are presented with will only be those which are applicable to IPV six traffic. So we can define various match conditions, including the IP source address, IP destination address, TCP or UDP source portfolio, IP protocol field, ICMP packet type, IP options, TCP flags, incoming logical or physical interface, and outgoing logical or physical interface. We’ll take a look at some of these in the next lecture. The actions specified in a firewall filter term define the actions to take for any packet that matches the conditions specified in the term. Okay, so what are the action types? Well, firewall filter actions fall into the following categories number one, you have Terminating actions. Number two, you have flow control actions. And number three, we have action modifiers. Terminating actions cause the evaluation of the Firewall filter to stop, while flow control actions affect the flow of policy evaluation.

For example, the next term action causes Juno’s to evaluate the next term. Firewall filters do not have the next filter option. In routing policies, we have this option where you can move on to the next policy. In firewall filters, we don’t have this option where we can move on to the next filter. Lastly, we have action modifiers. One or more action modifiers can be specified with a terminating or flow control action. So along with terminating actions or along with flow control actions, we can also specify action modifiers. If you specify an action modifier, but you do not specify a terminating action, the system implies an action of accept. What are the terminating actions that we can use? Number one, we have Accept, which causes the system to accept the packet. Number two, we have discard. It causes the system to silently discard the packet without sending an ICMP message to the source address. That means if we use discard, the packet will be dropped, but no message will be sent back to the source of that traffic. Third one is Reject, which causes the system to discard the packet and send a message back to the source address. Let’s talk about the reject action.

The syntax is Reject space message type. If you do not specify a message type, a destination unreachable message is returned by default. If you specify TCP reset as the message type, TCP reset is returned only if the packet is a TCP packet. Otherwise the message that is returned is administratively prohibited. If you specify any other message type, that message type is returned. Let’s talk about action modifiers. We actually have a bunch of action modifiers, but on the screen right now I have some very important ones only. For example, we have Count, which helps you count the number of packets. We have log, it logs the packet header information.

We have policer. It uses a policer to rate limit traffic. We are going to discuss about policers very soon. And then we have Syslog, which logs the packet to the system log file. Well, that’s it for this lecture. I know it has been a power pack lecture. A lot of things, a lot of items to remember. The next one is going to be even more interesting, where we’ll dive into the Juno’s device and take a look at how we can configure and apply the Firewall filters. We’ll see them live in action. I’m excited to see you there. I’d like to thank you for watching and I’ll catch you in the the next video. Thank you.