Junos tips – apply-groups and apply-path

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;
            }
        }
    }
}