> For the complete documentation index, see [llms.txt](https://jncia-workbook.gitbook.io/workbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jncia-workbook.gitbook.io/workbook/junos-routing-policy/12-multiple-policies.md).
# 12) Multiple Policies
### Pre-Work
Load the config called **multiple.policies.cfg** using the **load\_config\_on\_nodes.py** script.
```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename multiple.policies.cfg
```
### Lab
R2 is currently redistributing static routes into OSPF:
```
[edit]
admin@R2# show policy-options
policy-statement STATIC_TO_OSPF {
from protocol static;
then accept;
}
[edit]
admin@R2# show protocols ospf export
export STATIC_TO_OSPF;
```
We now want to redistribute BGP into OSPF as well. However, it wouldn't make sense to match BGP routes in a route-policy named `STATIC_TO_OSPF`. Also, we don't want to rename the existing policy. Find a good solution.
### Answer
Expand to reveal
We can add a second policy and chain it together with the existing policy:
```
set policy-options policy-statement BGP_TO_OSPF from protocol bgp
set policy-options policy-statement BGP_TO_OSPF then accept
set protocols ospf export [ STATIC_TO_OSPF BGP_TO_OSPF ]
```
### Explanation
Expand to reveal
Junos allows us the flexibility of applying multiple route policies in a chain. This is something that isn't available in other vendors such as Cisco. The policy evaluation works as you might expect. It is as if all policies are stitched together into one large policy, where the policies are stitched in the order they are configured. Whenever the route matches a policy term that has a terminating action (`accept` or `reject`), evaluation stops (unless there is a continuing action in that term such as `next term` or `next policy`).
\
To solve this lab, we create a simple policy that matches BGP routes, and add this to the OSPF export statement. The brackets indicate a list of objects, where the objects are separated by a space.
```
set policy-options policy-statement BGP_TO_OSPF from protocol bgp
set policy-options policy-statement BGP_TO_OSPF then accept
set protocols ospf export [ STATIC_TO_OSPF BGP_TO_OSPF ]
```
\
You could also add the new policy as an `export` statement without any brackets, and the new export policy will automatically be added as a list:
```
[edit]
admin@R2# show protocols ospf export
export STATIC_TO_OSPF;
[edit]
admin@R2# set policy-options policy-statement BGP_TO_OSPF from protocol bgp
[edit]
admin@R2# set policy-options policy-statement BGP_TO_OSPF then accept
[edit]
admin@R2#
[edit]
admin@R2# set protocols ospf export BGP_TO_OSPF <----------------
[edit]
admin@R2# show | compare
[edit policy-options]
+ policy-statement BGP_TO_OSPF {
+ from protocol bgp;
+ then accept;
+ }
[edit protocols ospf]
- export STATIC_TO_OSPF;
+ export [ STATIC_TO_OSPF BGP_TO_OSPF ]; <-----------------
```
\
First, routes in the RIB are evaluated against the `STATIC_TO_OSPF` policy. This matches and accepts static routes, and everything besides a static route continues to be evaluated against the `BGP_TO_OSPF` policy. This matches and accepts BGP routes, and everything else continues to be evaluated against the default export policy for OSPF. The default export policy rejects all routes.
\
We can confirm that R2 is redistributing both static and BGP routes into OSPF now:
```
admin@R2> show ospf database external advertising-router self
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *3.3.3.3 10.0.0.2 0x80000001 7 0x22 0x108a 36
Extern *10.20.0.0 10.0.0.2 0x80000001 26 0x22 0x2761 36
Extern *10.20.1.0 10.0.0.2 0x80000001 26 0x22 0x1c6b 36
```
### Further Reading