Undoubtedly, one of the coolest features in JUNOS is the apply-path statement. Using apply-path, an operator can configure a prefix-list which comprises IP prefixes linked to a defined path within JUNOS. This facilitates tasks like configuring firewall filters to allow traffic from configured BGP neighbors, making them highly dynamic.
For example, suppose we have the following configuration:
system { ntp { server 192.168.70.10; server 192.168.72.10; } } protocols { bgp { group ibgp { type internal; neighbor 192.168.50.100; neighbor 192.168.50.101; neighbor 192.168.50.102; neighbor 192.168.50.103; neighbor 192.168.50.104; neighbor 192.168.50.105; } } }
Let’s assume we want to restrict BGP and NTP traffic to only those peers with whom we wish to peer with. Without the use of apply-paths, we’d have to configure a prefix-list or add individual source-address statements comprising all of the above addresses and add that to our firewall filter configuration, as in the following:
policy-options { prefix-list bgp-peers { 192.168.50.100/32; 192.168.50.101/32; 192.168.50.102/32; 192.168.50.103/32; 192.168.50.104/32; 192.168.50.105/32; } prefix-list ntp { 192.168.70.10/32; 192.168.72.10/32; } } firewall { filter re-protect { term bgp { from { prefix-list { bgp-peers; } protocol tcp; port bgp; } then accept; } term ntp { from { prefix-list { ntp; } protocol udp; port ntp; } then accept; } } }
As you can see, that’s a lot of redundant typing especially considering we’ve already configured these under their respective configuration stanzas within JUNOS. The above example might not seem like a lot, but if you’re looking at an ISP edge router it wouldn’t be uncommon to see several hundred such BGP neighbor statements. Now multiply that across all of your devices in your network and you will quickly see that prefix-list maintenance can quickly become cumbersome.
Enter the apply-path statement. The idea behind the apply-path statement was to create a method whereby prefix-lists could be created dynamically by simply referencing other portions of the configuration, thus eliminating most of the effort required to maintain a prefix list. The path consists of elements separated by spaces. Each element matches a specific keyword or identifier within the configuration, and you can use wildcards to match more than one identifier. Wildcards must be enclosed in angle brackets, for example, <*>.
As an example, let us take a look at how the above prefix-list definition could be simplified:
policy-options { prefix-list bgp-peers { apply-path "protocols bgp group <*> neighbor <*>"; } prefix-list ntp { apply-path "system ntp server <*>"; } }
With the above we’ve eliminated 8 lines of code and replaced it with 2. The apply-path statement is telling the prefix-list to be generated dynamically by looking at the “protocols bgp group <*> neighbor <*>” and “system ntp server <*>” portions of the configuration.
Although this has simplified the configuration greatly, it comes at the expense of being able to easily identify which addresses are part of a prefix-list. In order to properly determine if the apply-path statement is working correctly and also to identify those addresses which are part of the prefix list, we can use the “show | display inheritence” command, as in the following:
root@jncie-lab# show | display inheritance prefix-list bgp-peers { ## ## apply-path was expanded to: ## 192.168.50.100/32; ## 192.168.50.101/32; ## 192.168.50.102/32; ## 192.168.50.103/32; ## 192.168.50.104/32; ## 192.168.50.105/32; ## apply-path "protocols bgp group <*> neighbor <*>"; } prefix-list ntp { ## ## apply-path was expanded to: ## 192.168.70.10; ## 192.168.72.10; ## apply-path "system ntp server <*>"; }
In closing, the use of apply-paths in an operational network assists in hardening a network, and can dramatically reduce the operational overhead of maintaining prefix-lists. In addition, it also helps to eliminate configuration errors in which the address added to the prefix list don’t match that configured in respective portions within the JUNOS configuration.
Super writing Stefan
regards
Mehdi Raza
I find this especially helpful in configuring snmp access. I hate the idea of populating both the snmp clients lists and a prefix-list for controlling snmp packets to the RE. This is a beautiful technique to auto-populate the prefix-list with the addresses you are already maintaining in snmp.
Thanks,
Mark Borchers
Is there a way to use apply-path from within a logical-system? For example is it possible to create a policy-statement titled “bgp-peers” inside a logical-system titled “internet” that only references BGP peers belonging to that LS? Using the string in your example above only pulls peers from the global LS into the prefix-list. Feeding it a string that includes “logical-system internet” prepended receives an immediate “invalid path element” error at the CLI.
What I’d like to do is configure loopback firewalls at each LS on our MXes (MXen?) as well as a “global” filter that would allow the policy to cascade and provide some admin groups more direct access to their management/control plane. If the apply-path option doesn’t work its not a big deal; just seems like a handy tool if there’s a way to make it work.
Thanks!
Awesome, very clear and easy to understand. I just learned about this option, google’d and there you are. Thanks.
Hi!
Lets say i have two prefix-list list
prefix-list prefix-a {
192.168.0.0/22;
}
prefix-list prefix-b {
172.16.0.0/22;
}
How can we inherit prefix-list within a prefix-list? I’m trying to aggregate all the prefix-list into one
prefix-list aggregate-prefixes {
apply-path “policy-options prefix-list prefix- “;
}