> 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/11-bgp-inbound-filtering.md).
# 11) BGP Inbound Filtering
### Pre-Work
Load the config called **policy.ospf.into.bgp.cfg** using the **load\_config\_on\_nodes.py** script.
```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename policy.ospf.into.bgp.cfg
```
### Lab
All routing (static routes, OSPFv2, and BGP) is already setup. OSPF is currently redistributed into BGP on R2.
Configure R3 so that route advertisements within RFC1918 (10/8, 172.16/12, 192.168/16) are filtered from being received from R2. You must use a prefix-list.
### Answer
Expand to reveal
```
set policy-options prefix-list RFC1918 10.0.0.0/8
set policy-options prefix-list RFC1918 172.16.0.0/12
set policy-options prefix-list RFC1918 192.168.0.0/16
edit policy-options policy-statement R2_INBOUND
set term REJECT_RFC1918 from prefix-list-filter RFC1918 orlonger
set term REJECT_RFC1918 then reject
set term ACCEPT_ALL then accept
top
set protocols bgp group EBGP neighbor 10.2.3.2 import R2_INBOUND
```
### Explanation
Expand to reveal
We have already seen how prefix-list-filters work from the previous lab. Instead, this lab demostrates how to use per-peer inbound BGP route policies. You apply the route policy to the peer with an import statement:
```
set protocols bgp group EBGP neighbor 10.2.3.2 import R2_INBOUND
```
\
Note that it is also acceptable to apply import/export route policies at the BGP group level. This allows you to apply route policies to all peers within the group with a single configuration statement.
```
set protocols bgp group EBGP import R2_INBOUND
```
\
On R3 we can use the following command to see received routes after the inbound route policy is applied. Notice that it tells us that there are 3 hidden routes in the RIB.
```
admin@R3> show route receive-protocol bgp 10.2.3.2
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 10.2.3.2 1 65000 I
```
\
Using the `all` keyword, we can see the hidden routes as well. This shows us which routes were received from 10.2.3.2 but rejected.
```
admin@R3> show route receive-protocol bgp 10.2.3.2 all
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 10.2.3.2 1 65000 I
10.0.0.0/16 10.2.3.2 0 65000 I
10.0.1.0/24 10.2.3.2 0 65000 I
10.2.0.0/16 10.2.3.2 0 65000 I
```
\
To specifically view hidden/rejected routes only, we can use the `hidden` keyword:
```
admin@R3> show route receive-protocol bgp 10.2.3.2 hidden
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
Prefix Nexthop MED Lclpref AS path
10.0.0.0/16 10.2.3.2 0 65000 I
10.0.1.0/24 10.2.3.2 0 65000 I
10.2.0.0/16 10.2.3.2 0 65000 I
```
\
Using the `detail` keyword, we can get information about the BGP attributes on these prefixes, as well as the reason these prefixes are hidden:
```
admin@R3> show route receive-protocol bgp 10.2.3.2 hidden detail
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
10.0.0.0/16 (1 entry, 0 announced)
Nexthop: 10.2.3.2
MED: 0
AS path: 65000 I
Hidden reason: Rejected by import policy
10.0.1.0/24 (1 entry, 0 announced)
Nexthop: 10.2.3.2
MED: 0
AS path: 65000 I
Hidden reason: Rejected by import policy
10.2.0.0/16 (1 entry, 0 announced)
Nexthop: 10.2.3.2
MED: 0
AS path: 65000 I
Hidden reason: Rejected by import policy
```
\
We can also use the `hidden` keyword on the route table in general:
```
admin@R3> show route protocol bgp hidden
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/16 [BGP ] 00:04:37, MED 0, localpref 100
AS path: 65000 I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/0.0
10.0.1.0/24 [BGP ] 00:04:37, MED 0, localpref 100
AS path: 65000 I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/0.0
10.2.0.0/16 [BGP ] 00:04:37, MED 0, localpref 100
AS path: 65000 I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/0.0
```
#### Further Details on "show route receive-protocol bgp"
It was mentioned above that the command show route receive-protocol bgp shows routes after being passed through the import policy. This is not entirely correct. It is true that routes that are rejected by the import policy are not shown, however modifications to accepted routes are not shown with this command.
\
As an example, we can add this action to set local preference to 120 on accepted routes:
```
set policy-options policy-statement R2_INBOUND term ACCEPT_ALL then local-preference 120
```
\
Using `show route receive-protocol bgp 10.2.3.2` we can see that the LP value has not changed on the one accepted route:
```
admin@R3> show route receive-protocol bgp 10.2.3.2
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 10.2.3.2 1 65000 I
```
\
We can only see the modifications to accepted routes using the standard `show route`:
```
admin@R3> show route protocol bgp
inet.0: 7 destinations, 7 routes (4 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:02:16, MED 1, localpref 120
AS path: 65000 I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/0.0
```
### Further Reading