In this post, we’re going to look at Juniper prefix-lists. What they are, how to configure them, and how they behave.
You may also like to read about route filters, which provide some additional matching options.
What Is A Prefix List
A prefix list is exactly what it sounds like, a list of prefixes or routes.
The prefix list can then be referred to in either routing policy or firewall filters, instead of repeatedly specifying the same list of prefixes over and over again in different policies or filters.
It is then easier to update the configuration once in the prefix list, rather than having to find everywhere in the policies we refer to the same set of routes.
How To Configure A Prefix List In Junos
The two common methods are to either type it out or use an apply-path statement to have it built dynamically.
Here is an example of doing it manually.
set policy-options prefix-list pl-block-172-16 172.16.0.0/22
root@vMX-1> show configuration policy-options
prefix-list pl-block-172-16 {
172.16.0.0/22;
}In this case, we’ve only specified one prefix.
To build a prefix list based on the configuration, we use the apply-path command. This is useful for creating prefix lists of routing neighbors.
set policy-options prefix-list pl-bgp-peers apply-path "protocols bgp group <*> neighbor <*>"
root@vMX-1> show configuration policy-options prefix-list pl-bgp-peers
apply-path "protocols bgp group <*> neighbor <*>";To see what the end prefix-list will look like, we need to use the display inheritance command.
root@vMX-1> show configuration policy-options prefix-list pl-bgp-peers | display inheritance
##
## apply-path was expanded to:
## 10.100.1.2/32;
##
apply-path "protocols bgp group <*> neighbor <*>";The above apply-path matches on any neighbor, in any group, configured under protocols bgp.
When additional neighbors are configured, the prefix-list will be updated.
[edit]
root@vMX-1# show | compare
[edit protocols bgp]
group test-group { ... }
+ group new-group {
+ peer-as 65005;
+ neighbor 10.1.2.3;
+ }
[edit]
root@vMX-1# ...fix-list pl-bgp-peers | display inheritance
##
## apply-path was expanded to:
## 10.100.1.2/32;
## 10.1.2.3/32;
##
apply-path "protocols bgp group <*> neighbor <*>";
[edit]
root@vMX-1#How Do Prefix Lists Behave
How prefix-lists behave depends on how they are used in the configuration.
Under policy-statements they can be matched as either prefix-list or prefix-list-filter. The prefix-list method acts like an exact match, whereas the prefix-list-filter can be an exact, longer, or orlonger style match.
Under firewall filters prefix-lists are matched as a source-prefix-list This behaves like an orlonger match and the filter will apply to any address covered by the prefix list.
This is shown in the following examples, based on this test setup.
The vMX-1 router has a bgp peering to vMX-2 and has been configured to advertise 10.200.0.0/24, with 10.200.0.1/32 configured on its loopback interface. A prefix list called pl-block-172-16 with a single entry of 172.16.0.0/22 has been created.
The vMX-2 router has been configured with static routes for 172.16.0.0/22 and the four /24s it contains, and 172.20.0.0/22 and the four /24s it contains. The first address of each subnet has been configured as a /32 under the loopback interface so we can source pings from within those address ranges.
Without any import policy applied to the BGP neighbor, the vMX-1 route table looks as follows:
lab@vMX-1> show route table inet.0
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.1.0/24 *[Direct/0] 01:06:51
> via ge-0/0/1.0
10.100.1.1/32 *[Local/0] 01:06:51
Local via ge-0/0/1.0
10.200.0.0/24 *[Static/5] 01:07:36
Reject
10.200.0.1/32 *[Direct/0] 01:07:35
> via lo0.0
172.16.0.0/22 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.0.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.1.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.2.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.3.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.0.0/22 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.0.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.1.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.2.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.3.0/24 *[BGP/170] 00:53:53, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
192.168.0.1/32 *[Direct/0] 01:09:55
> via lo0.0Example 1 – Import Policy Using prefix-list
The following policy was created on vMX-1 and applied as an import filter on the bgp neighbor.
lab@vMX-1# show policy-options policy-statement reject-via-prefix-list
term block-routes {
from {
prefix-list pl-block-172-16;
}
then reject;
}
term default {
then accept;
}If we now look at the route table, we can see that only the 172.16.0.0/22 prefix was blocked and is no longer present in the routing table. The prefix list is being treated as an exact match.
lab@vMX-1> show route table inet.0
inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.1.0/24 *[Direct/0] 01:12:16
> via ge-0/0/1.0
10.100.1.1/32 *[Local/0] 01:12:16
Local via ge-0/0/1.0
10.200.0.0/24 *[Static/5] 01:13:01
Reject
10.200.0.1/32 *[Direct/0] 01:13:00
> via lo0.0
172.16.0.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.1.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.2.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.16.3.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.0.0/22 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.0.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.1.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.2.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.3.0/24 *[BGP/170] 00:59:18, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
192.168.0.1/32 *[Direct/0] 01:15:20
> via lo0.0Example 2 – Import Policy Using prefix-filter-list
If we change the match from prefix-list to prefix-list-filter we can specify whether the match should be exact, longer, or orlonger. The policy-statement was updated as follows:
[edit]
lab@vMX-1# show policy-options policy-statement reject-via-prefix-list
term block-routes {
from {
prefix-list-filter pl-block-172-16 orlonger;
}
then reject;
}
term default {
then accept;
}We can see the route table no longer has any routes from the 172.16.0.0/22 space.
lab@vMX-1> show route table inet.0
inet.0: 15 destinations, 15 routes (10 active, 0 holddown, 5 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.1.0/24 *[Direct/0] 01:17:49
> via ge-0/0/1.0
10.100.1.1/32 *[Local/0] 01:17:49
Local via ge-0/0/1.0
10.200.0.0/24 *[Static/5] 01:18:34
Reject
10.200.0.1/32 *[Direct/0] 01:18:33
> via lo0.0
172.20.0.0/22 *[BGP/170] 01:04:51, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.0.0/24 *[BGP/170] 01:04:51, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.1.0/24 *[BGP/170] 01:04:51, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.2.0/24 *[BGP/170] 01:04:51, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
172.20.3.0/24 *[BGP/170] 01:04:51, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.100.1.2 via ge-0/0/1.0
192.168.0.1/32 *[Direct/0] 01:20:53
> via lo0.0Example 3 – Firewall Filter Using source-prefix-list
After the policy tests above, the import policy was removed from the BGP neighbor, so vMX-1 can now see all 172.16.0.0/22 and longer routes.
From vMX-2, we can ping from a number of the 172.16.0.0/22 and 172.20.0.0/22 networks.
lab@vMX-2> ping count 2 10.200.0.1 source 172.16.0.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=86.540 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=3.974 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.974/45.257/86.540/41.283 ms
lab@vMX-2> ping count 2 10.200.0.1 source 172.16.1.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=4.403 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=3.027 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.027/3.715/4.403/0.688 ms
lab@vMX-2> ping count 2 10.200.0.1 source 172.16.2.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=4.159 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=3.109 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.109/3.634/4.159/0.525 ms
lab@vMX-2> ping count 2 10.200.0.1 source 172.20.0.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=39.167 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=3.694 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.694/21.431/39.167/17.736 ms
lab@vMX-2> ping count 2 10.200.0.1 source 172.20.1.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=3.371 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=3.563 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.371/3.467/3.563/0.096 msThe following firewall filter was applied as an input filter on the interface facing vMX-2.
lab@vMX-1# show firewall
family inet {
filter ff-block-172-16 {
term block-172-16 {
from {
source-prefix-list {
pl-block-172-16;
}
}
then {
count blocked-172-16;
log;
discard;
}
}
term default {
then accept;
}
}
}From vMX-2, we repeat the pings and get the following results.
lab@vMX-2> ping count 2 10.200.0.1 source 172.16.0.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
lab@vMX-2> ping count 2 10.200.0.1 source 172.16.1.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
lab@vMX-2> ping count 2 10.200.0.1 source 172.16.2.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
lab@vMX-2> ping count 2 10.200.0.1 source 172.20.0.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=4.091 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=3.590 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.590/3.841/4.091/0.250 ms
lab@vMX-2> ping count 2 10.200.0.1 source 172.20.1.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
64 bytes from 10.200.0.1: icmp_seq=0 ttl=64 time=18.873 ms
64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=5.027 ms
--- 10.200.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.027/11.950/18.873/6.923 msAnd on vMX-1, we can see the filter working from the firewall log and counters.
lab@vMX-1> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
10:09:16 pfe D ge-0/0/1.0 ICMP 172.16.0.1 10.200.0.1
10:09:15 pfe D ge-0/0/1.0 ICMP 172.16.0.1 10.200.0.1
10:08:56 pfe D ge-0/0/1.0 ICMP 172.16.2.1 10.200.0.1
10:08:55 pfe D ge-0/0/1.0 ICMP 172.16.2.1 10.200.0.1
10:08:39 pfe D ge-0/0/1.0 ICMP 172.16.1.1 10.200.0.1
10:08:38 pfe D ge-0/0/1.0 ICMP 172.16.1.1 10.200.0.1
10:08:25 pfe D ge-0/0/1.0 ICMP 172.16.0.1 10.200.0.1
10:08:23 pfe D ge-0/0/1.0 ICMP 172.16.0.1 10.200.0.1
lab@vMX-1> show firewall filter ff-block-172-16
Filter: ff-block-172-16
Counters:
Name Bytes Packets
blocked-172-16 672 8