In terms of functionality, Junos is great operating system :P, everyone knows it. During JNCIE study I remembered several tips that I want to share. Maybe someone will find it useful.
Apply-group and apply-path in Junos are similar functionalities for slightly different use. The concept behind them is to apply some bulk, repeatable (but not always) configuration to the particular configuration hierarchy. The result is that some configurational elements inherit specific options from the configuration group.
Apply-groups
The common use of apply-group is to add some specific configurational options for IGP protocol like OSPF for example. Another frequent application is to enable mpls, ldp or specific CoS settings for all core facing interfaces. In that way, each time you will have to enable next core interface the whole block of additional configuration will be added to it automatically.
OSPF example
Each of the specified interface type will be P2P interface in OSPF:
groups { ospf-p2p { protocols { ospf { area <*> { interface <xe-*> { interface-type p2p; } interface <ge-*> { interface-type p2p; } interface <et-*> { interface-type p2p; } interface <irb.*> { interface-type p2p; } } } } } }
Verification:
tomek@MX480-RE1> show configuration protocols ospf | display inheritance area 0.0.0.1 { interface xe-2/0/1.0 { ## ## 'p2p' was inherited from group 'ospf-p2p' ## interface-type p2p; } interface ge-0/0/2.0 { ## ## 'p2p' was inherited from group 'ospf-p2p' ## interface-type p2p; } } tomek@MX480-RE1> show ospf interface Interface State Area DR ID BDR ID Nbrs et-0/2/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 irb.100 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 ge-0/0/6.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Another example is to have some specific configuration for each Routing Engine in dual RE router: The same type of configuration is usually used in SRX HA Clusters.
groups { re0 { system { host-name MX480-RE0; time-zone Europe/Warsaw; dump-on-panic; } interfaces { fxp0 { description OOB_INTERFACE; unit 0 { family inet { address 192.168.1.1/24 { master-only; } address 192.168.1.2/24; } } } } } re1 { system { host-name MX480-RE1; time-zone Europe/Warsaw; dump-on-panic; } interfaces { fxp0 { description OOB_INTERFACE; unit 0 { family inet { address 192.168.1.1/24 { master-only; } address 192.168.1.3/24; } } } } } }
Both of this examples are simply applied by configuring them in global context.
tomek@MX480-RE1> show configuration | display set | match apply set apply-groups re0 set apply-groups re1 set apply-groups ospf-p2p
Apply-path
Let’s say you have protected your router from unauthorised access by applying a firewall filter to the loopback interface. Beside the administrative access restrictions this filter has a term that allows to establish a bgp session from each configured peer. Every time a new bgp peer is added to the configuration, you have to add this peer prefix to that firewall filter.
But fear not, there is a really simple solution for that.
By configuring apply-path in prefix-list you can automatically add new peer to the firewall filter.
tomek@R1> show configuration protocols bgp group IBGP { type internal; bfd-liveness-detection { minimum-interval 300; } neighbor 2.2.2.2 { local-address 1.1.1.1; } } tomek@R1> show configuration firewall family inet filter protect-re term bgp from { source-prefix-list { bgp-peer; } protocol tcp; port bgp; } then accept;
When you display inherited configuration of this prefix-list
tomek@R1> show configuration policy-options prefix-list bgp-peer | display inheritance ## ## apply-path was expanded to: ## 2.2.2.2/32; ## apply-path "protocols bgp group <*> neighbor <*>";
You will notice that our IBGP peer address is automatically added to the filter.
The same thing can be achieved when we want to allow ospf communication on all directly connected interfaces.
tomek@R1> show configuration firewall family inet filter protect-re term allow-ospf-networks from { prefix-list { ospf-nets; } protocol ospf; } then accept; tomek@R1> show configuration policy-options prefix-list ospf-nets | display inheritance ## ## apply-path was expanded to: ## 10.1.13.0/24; ## 10.1.12.0/24; ## 10.1.1.0/24; ## 1.1.1.1/32; ## apply-path "interfaces <*> unit <*> family inet address <*>";
Final NOTE that is good to remember. The apply-group can be applied at different configuration levels. For example you can apply a VRRP group as shown below at the top of the configuration hierarchy (global context) or under interface logical unit – the result will be the same.
tomek@R2# show groups VRRP-PRIMARY { interfaces { <ge-*> { unit <*> { family inet { address 192.168.1.253/24 { vrrp-group 1 { virtual-address 192.168.1.254; priority 254; accept-data; } } } } } } }
tomek@R2# show interfaces ge-0/0/0 unit 0;
tomek@R2# show | display set | match apply-group set apply-groups VRRP-PRIMARY
[edit] tomek@R2# show interfaces ge-0/0/0 | display inheritance unit 0 { ## ## 'inet' was inherited from group 'VRRP-PRIMARY' ## family inet { ## ## '192.168.1.253/24' was inherited from group 'VRRP-PRIMARY' ## address 192.168.1.253/24 { ## ## '1' was inherited from group 'VRRP-PRIMARY' ## vrrp-group 1 { ## ## '192.168.1.254' was inherited from group 'VRRP-PRIMARY' ## virtual-address 192.168.1.254; ## ## '254' was inherited from group 'VRRP-PRIMARY' ## priority 254; ## ## 'accept-data' was inherited from group 'VRRP-PRIMARY' ## accept-data; } } } }
tomek@R2# delete apply-groups tomek@R2# set interfaces ge-0/0/0 unit 0 apply-groups VRRP-PRIMARY [edit] tomek@R2# commit commit complete
[edit] tomek@R2# show interfaces ge-0/0/0 unit 0 { apply-groups VRRP-PRIMARY; } [edit] tomek@R2# show | display set | match apply-group set interfaces ge-0/0/0 unit 0 apply-groups VRRP-PRIMARY
[edit] tomek@R2# show interfaces ge-0/0/0 | display inheritance unit 0 { ## ## 'inet' was inherited from group 'VRRP-PRIMARY' ## family inet { ## ## '192.168.1.253/24' was inherited from group 'VRRP-PRIMARY' ## address 192.168.1.253/24 { ## ## '1' was inherited from group 'VRRP-PRIMARY' ## vrrp-group 1 { ## ## '192.168.1.254' was inherited from group 'VRRP-PRIMARY' ## virtual-address 192.168.1.254; ## ## '254' was inherited from group 'VRRP-PRIMARY' ## priority 254; ## ## 'accept-data' was inherited from group 'VRRP-PRIMARY' ## accept-data; } } } }