We're going to look at the policy language that is used in different vendors. So for Cisco, for policy control, if you want a complicated way to do this, you have what we call route maps, and a route map is like a program for iOS. It has line numbers much as old programming languages used to have, and each line with its line number is a separate condition or action. And a concept is basically if you match something then do a particular expression, and then exit. Else if you match something else, then do this other expression and then exit, and then it continues on and on and on and on. The route map "continue" keyword allows you to apply more than one condition and actions inside one roadmap. It would be an expression that allows you to jump to the next line number and continue to do what is contained in both expressions. Now for Juniper, they have a policy framework which generally is used for both routing policy hours as well as firewall filtering. Now just like Cisco route maps. You have three main components: You have much conditions that select whatever you want to match. Then you have actions which are performed if the criteria match. Now these match conditions and actions are contained in terms. A time is an actual line of statement that contains those match conditions and the actions. Unlike iOS they are not numbered and the term does not define a default action, since it does not contain a permit or deny keyword as part of its statement. So, let's look at some sample route maps. Now we have a couple of rules. For example, lines can have multiple set statements and if that happens, all the state statements are implemented by that particular line. Say, route-map SAMPLE permit 10. And you have set community 300:1 and set local-reference 120. So anything that passes through this particular route map statement, is going to have both the community set as well as the local preference. In this case, nothing is matched. So everything that is advertised will be match by this statement. Alternatively you can have multiple match statements, like match community 1, match IP address prefix-list and then you give it a name and in this case all these conditions must match, for the local-preference to be set to 300. Some match statements can have multiple commands. In this case, at least one of the commands must match and the slide shows you an example. So route map sample permit 10, your matching ip address prefix-list MY-LIST OTHER-LIST. What this means is match everything inside the prefix-list, MY-LIST, or match everything that is inside a prefix-list OTHER-LIST. And if something is inside one of these prefix lists, sets the community to 300:10 . If you have a route map with just a match statement and no set statement, then any prefixes that is matching will go through and the rest are dropped. In this example we have route-map SAMPLE permit 10, and then match ip address prefix-list MY-LIST. So for this statement, the action that's going to be done is the permit, which is up here at the top. If you had route-map SAMPLE deny 10, and then the action that would be done would be to deny everything that matches this prefix list. As we've mentioned before, if you have a line with only a set statement, all the prefixes will be matched and whatever you say in the set statement will be done. Any following lines are ignored. So in this example, route-map SAMPLE permit 10, with set local- preference 120, and then route-map SAMPLE permit 20 set community 300:5. The second route map statement will never ever ever be reached because everything will have the local-preference set and then it will exit the whole route map. Aligned with a match and set statement and not following lines, will have the default rule applied, which means everything which doesn't match what has been set will be dropped. So in this example, anything which doesn't match the prefix-list, MY-LIST is going to be denied. So, let's look at what this implies. If you omit the third line in this example it means that prefixes that do not match LIST ONE or LIST-TWO are going to be dropped, because the route maps have an implicit deny all. in this case, you want to match things in LIST-ONE, set 120. Match things in LIST-TWO, set up reference of 80, and then everything else will go through the default 100. if you don't have the third line, then it will not only not set the local preference, but it will actually drop the prefix. And this is an example of how you would actually apply this to the BGP session. Now to do AS-PATH filtering, we already showed you how to use a filter list, but in some cases besides just filtering the list, maybe you want to set a local preference as well. This slide shows you how to do it. So instead of applying a filter list, you apply a route-map in the inbound direction, and then you say permit 10 and then you match an as-path of 1, which will match the as-path access-list 1, and then you set a local preference to 80. Then, if you match as-path 2, you set the local preference to 200. This is an example of how you'd use this particular concepts to do prepend. You have a route-map SETPATH permit 10, and it's applied in the outbound direction towards a neighbor. It does not have a match statement, so it's going to match everything. And then you have set as-path prepend, and then the AS numbers that you want to prepend. If you do this, make sure you use your own AS number when prepending, otherwise you can mess with the BGP loop detection and some AS ends will be dropped because you are prepending the wrong Autonomous System Number. The slides that talk about communities, show you how to match communities, and this slide also gives you an example of how you'd match a community and then set a local preference. For community lists, because you can have more than one entry inside a community list, you have to remember that if you have a prefix that belongs to 150: 3 and 200:5, then it will set the local preference to 50. Otherwise if it belongs to only 88:6, you're going to set the local preference to 200. If there's not a condition than anything which doesn't match any of these conditions is going to be dropped. When you have multiple values in the same community list statement is a logical AND between them. If you have multiple values in separate community- list statement, a logical or condition is between each statement. For example, if you have IP community list 1, as shown in the example, Permit 150:3 200:5, then both these communities must exist. If you have ip community-list 1 permit 150:3, and then ip community-list 1 permit 200:5, then either of these could match and this is an example configuration that shows using this. We've mentioned a continue keyword and this is a way you could do some bit of set statements if it matches a condition and then other bit of statements that match other conditions. And this slide shows you how to do it. So the continue 30 will skip the permit 20 line and jump down to line 30 where you have a match for group 3, where you're sending a prepend of 100 100. So permit 20 is only run for lists prefixes which do not match group 1, and they match group 2. In this case you are setting the community no export. For Juniper policy languages, you have it configured in other policy options. And this is an example of how you do a route filter and you'd say: policy-options, you have a policy statement, you give it a name, and then you have different terms. So term some prefixes, and then inside the term, you specify which prefixes you want to match. So you have a from keyword and then different route filters. As mentioned in the previous video, you can have an action on a particular route filter. So you serve route filter 0.0.0.0./0 exact reject, and this will reject the default route. It will not continue processing these terms. Then you have route filter 192.0.0.0/8 upto 24; and route filter 193.0.0.0/8 prefix-length- range 12 20, and you don't have an action on these two route filters. So if something matches either one of these two route filters, it's going to go to that then close, and apply the preference of 200, and then tool accept. Then you have a term default-deny which has a then, reject. Remember that for Juniper the default policy is dependent on the routing protocol. So for BGP, the default policy is to announce everything that is inside BGP. This slide shows you how you would actually do an AS regex configuration. So for example, you have Autonomous System Number 1800 who's your neighbor or further down the line and you want to match everything that they originate. So you'd have as-path, you give it a name, and then you put a regex, which is .* 1800. Then you have a policy statement, which is any name and then you have a term filter-ases, and then you have from as-path and then you put the same name in red as we've seen as you had up there that you named. And then you can set up preference to 10. Now to apply to a BGP session you have protocols BGP and then you can say export, and then the outer policy out to export that named policy, and this will apply to everything every BGP session. Now Juniper BGP requires that each neighbor is inside a group. So you have a group for upstreams and this could be type external, and you have an export and import statement. The export statement all-upstreams-out, will override the global export outer policy out in red. Then you have a neighbour 172.16.2.2 with an import policy import-example. This will overwrite the green import incoming-upstreams policy. Next you have a neighbor without a particular policy applied and this means that they shall use the import policy for the group and export policy for the group, since those both will override the outer BGP policy.