> 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/2-redistribution-troubleshooting.md).
# 2) Redistribution Troubleshooting
### Pre-Work
Load the config called **policy.tshoot1.cfg** using the **load\_config\_on\_nodes.py** script.
```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename policy.tshoot1.cfg
```
### Lab
R2 is learning 3.3.3.3/32 via BGP. R2 is redistributing BGP into OSPF, but it isn't working.
Explain the problem and fix it so that R1 sees an OSPF route for 3.3.3.3/32.
### Answer
Expand to reveal
```
set policy-options policy-statement BGP_TO_OSPF then accept
```
### Explanation
Expand to reveal
In Junos, each protocol has a default import and export policy. In OSPF, the default export policy is to reject everything. This makes sense, as you don't want to automatically redistribute routes from other sources into OSPF. The problem here is that with no terminating action defined on the policy, the default policy is taking effect, and denying the route.
\
You might wonder how this default-deny export policy works for OSPF routes that are "advertised" to other neighbors. In a link-state protocol such as OSPF and ISIS, "advertising" is not quite the right term. All routers must have a synced link state database. So by default, Junos will synchronize the database, but this is a separate mechanism from the process of taking routes from the routing table and redistributing them into OSPF. For further information about the default policies for the various routing protocols, see the link in the *Further Reading* section at the bottom.
\
When we look at the current config on R2, it may look correct at first glance. The policy is defined and applied under OSPF. You may wonder if it is OK that there is no term, and the answer is yes, it is. If there is just a single term on your policy, you can omit the `term` from the policy.
```
admin@R2> show configuration policy-options
policy-statement BGP_TO_OSPF {
from protocol bgp;
}
admin@R2> show configuration protocols ospf export
export BGP_TO_OSPF;
```
\
The problem is that a terminating action has not been defined. (There is no `then` statement). By default, the route policy will continue processing, and actually go into the default OSPF export policy, which rejects all routes. You can think of this as the policies being chained, and the last policy in the chain is always the default policy.
\
In routing policies, there are two possible terminating actions: `accept` and `reject`. When a route evaluation hits a term with one of these actions, the processing stops and the route is accepted or rejected. If neither of these terminating actions are present on the term, then processing continues on, eventually moving into the default policy for that protocol. Therefore, we need to add a `then accept` statement to the policy in this lab:
```
admin@R2> show configuration policy-options
policy-statement BGP_TO_OSPF {
from protocol bgp;
then accept;
}
```
\
R1 should now have the route via OSPF:
```
admin@R1> show ospf database external
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 15 0x22 0x108a 36
```
### Further Reading