ON THIS PAGE
Example: Configuring a Policy Subroutine
This example demonstrates the use of a policy subroutine in a routing policy match condition.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
On Device R1, a policy called main is configured.
user@R1# show policy-options
policy-statement main {
term subroutine-as-a-match {
from policy subroutine;
then accept;
}
term nothing-else {
then reject;
}
}
This main policy calls a subroutine called subroutine.
user@R1# show policy-options
policy-statement subroutine {
term get-routes {
from protocol static;
then accept;
}
term nothing-else {
then reject;
}
}
The router evaluates the logic of main in a defined
manner. The match criterion of from policy subroutine allows
the routing device to locate the subroutine. All terms of the subroutine
are evaluated, in order, following the normal policy processing rules.
In this example, all static routes in the routing table match the
subroutine with an action of accept. This returns a true result to
the original, or calling, policy which informs the device that a positive
match has occurred. The actions in the calling policy are executed
and the route is accepted. All other routes in the routing table do
not match the subroutine and return a false result to the calling
policy. The device evaluates the second term of main and
rejects the routes.
The actions in the subroutine do not actually accept or reject a specific route. The subroutine actions are only translated into a true or a false result. Actions that modify a route’s attributes, however, are applied to the route regardless of the outcome of the subroutine.
Device R1 in AS 64510 has multiple customer routes, some of
which are static routes configured locally, and some of which are
received from Device R2 and Device R3 through internal BGP (IBGP).
AS 64510 is connected to Device R4 in AS 64511. The policy main is applied as an export policy in Device R1’s BGP peering
session with Device R4. This causes Device R1 to send only its own
static routes to Device R4. Because of the policy main,
Device R1 does not send the routes received from its internal peers,
Device R2 and Device R3.
When you are working with policy subroutines, it is important
to remember that the default EBGP export policy is to advertise all
learned BGP routes to all EBGP peers. This default policy is in effect
in the main policy and also in the subroutine. Therefore, as shown
in this example, if you do not want the default EBGP export policy
to take effect, you must configure a then reject terminating
action as the final term in both the main policy and in the policy
subroutine. This example demonstrates what happens when the final then reject term is missing either from the main policy or
from the policy subroutine.
Topology
Figure 1 shows the sample network.
CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
The section #configuration318__policy-subroutine-st describes the steps on Device R1.
Configuration
CLI Quick Configuration
To quickly configure
this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match
your network configuration, and then copy and paste the commands into
the CLI at the [edit] hierarchy level.
Device R1
set interfaces fe-1/2/0 unit 0 description to_R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces fe-1/2/2 unit 0 description to_R3 set interfaces fe-1/2/2 unit 0 family inet address 10.0.0.5/30 set interfaces fe-1/2/3 unit 0 description to_R4 set interfaces fe-1/2/3 unit 0 family inet address 10.1.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.1 set protocols bgp group int neighbor 192.168.0.2 set protocols bgp group int neighbor 192.168.0.3 set protocols bgp group to_64511 type external set protocols bgp group to_64511 export main set protocols bgp group to_64511 neighbor 10.1.0.6 peer-as 64511 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement main term subroutine-as-a-match from policy subroutine set policy-options policy-statement main term subroutine-as-a-match then accept set policy-options policy-statement main term nothing-else then reject set policy-options policy-statement subroutine term get-routes from protocol static set policy-options policy-statement subroutine term get-routes then accept set policy-options policy-statement subroutine term nothing-else then reject set routing-options static route 172.16.1.16/28 discard set routing-options static route 172.16.1.32/28 discard set routing-options static route 172.16.1.48/28 discard set routing-options static route 172.16.1.64/28 discard set routing-options router-id 192.168.0.1 set routing-options autonomous-system 64510
Device R2
set interfaces fe-1/2/0 unit 0 description to_R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to_R3 set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int neighbor 192.168.0.1 export send-static set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.2.16/28 discard set routing-options static route 172.16.2.32/28 discard set routing-options static route 172.16.2.48/28 discard set routing-options static route 172.16.2.64/28 discard set routing-options router-id 192.168.0.2 set routing-options autonomous-system 64510
Device R3
set interfaces fe-1/2/1 unit 0 description to_R2 set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.2/30 set interfaces fe-1/2/2 unit 0 description to_R1 set interfaces fe-1/2/2 unit 0 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int neighbor 192.168.0.1 export send-static set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/2.6 set protocols ospf area 0.0.0.0 interface fe-1/2/0.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static from protocol static set policy-options policy-statement send-static then accept set routing-options static route 172.16.3.16/28 discard set routing-options static route 172.16.3.32/28 discard set routing-options static route 172.16.3.48/28 discard set routing-options static route 172.16.3.64/28 discard set routing-options router-id 192.168.0.3 set routing-options autonomous-system 64510
Device R4
set interfaces fe-1/2/3 unit 0 description to_R1 set interfaces fe-1/2/3 unit 0 family inet address 10.1.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.4/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 64510 set protocols bgp group ext neighbor 10.1.0.5 set routing-options autonomous-system 64511
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Use the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R1:
Configure the device interfaces.
[edit interfaces] user@R1# set fe-1/2/0 unit 0 description to_R2 user@R1# set fe-1/2/0 unit 0 family inet address 10.0.0.1/30 user@R1# set fe-1/2/2 unit 0 description to_R3 user@R1# set fe-1/2/2 unit 0 family inet address 10.0.0.5/30 user@R1# set fe-1/2/3 unit 0 description to_R4 user@R1# set fe-1/2/3 unit 0 family inet address 10.1.0.5/30 user@R1# set lo0 unit 0 family inet address 192.168.0.1/32
Configure the internal BGP (IBGP) connections to Device R2 and Device R3.
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 192.168.0.1 user@R1# set neighbor 192.168.0.2 user@R1# set neighbor 192.168.0.3
Configure the EBGP connection to Device R4.
[edit protocols bgp group to_64511] user@R1# set type external user@R1# set export main user@R1# set neighbor 10.1.0.6 peer-as 64511
Configure OSPF connections to Device R2 and Device R3.
[edit protocols ospf area 0.0.0.0] user@R1# set interface fe-1/2/0.0 user@R1# set interface fe-1/2/2.0 user@R1# set interface lo0.0 passive
Configure the policy
main.[edit policy-options policy-statement main term subroutine-as-a-match] user@R1# set from policy subroutine user@R1# set then accept [edit policy-options policy-statement main term nothing-else] user@R1# set then reject
Configure the policy
subroutine.[edit policy-options policy-statement subroutine term get-routes] user@R1# set from protocol static user@R1# set then accept [edit policy-options policy-statement subroutine term nothing-else] user@R1# set then reject
Configure the static route to the 172.16.5.0/24 network.
[edit routing-options static] user@R1# set route 172.16.1.16/28 discard user@R1# set route 172.16.1.32/28 discard user@R1# set route 172.16.1.48/28 discard user@R1# set route 172.16.1.64/28 discard
Configure the autonomous system (AS) number and router ID.
[edit routing-options] user@R1# set router-id 192.168.0.1 user@R1# set autonomous-system 64510
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@R1# show interfaces
fe-1/2/0 {
unit 0 {
description to_R2;
family inet {
address 10.0.0.1/30;
}
}
}
fe-1/2/2 {
unit 0 {
description to_R3;
family inet {
address 10.0.0.5/30;
}
}
}
fe-1/2/3 {
unit 0 {
description to_R4;
family inet {
address 10.1.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 192.168.0.1;
neighbor 192.168.0.2;
neighbor 192.168.0.3;
}
group to_64511 {
type external;
export main;
neighbor 10.1.0.6 {
peer-as 64511;
}
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/0.0;
interface fe-1/2/2.0;
interface lo0.0 {
passive;
}
}
}
user@R1# show policy-options
policy-statement main {
term subroutine-as-a-match {
from policy subroutine;
then accept;
}
term nothing-else {
then reject;
}
}
policy-statement subroutine {
term get-routes {
from protocol static;
then accept;
}
term nothing-else {
then reject;
}
}
user@R1# show routing-options
static {
route 172.6.1.16/28 discard;
route 172.6.1.32/28 discard;
route 172.6.1.48/28 discard;
route 172.6.1.64/28 discard;
}
router-id 192.168.0.1;
autonomous-system 64510;
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying the Routes on Device R1
- Verifying the Route Advertisement to Device R4
- Experimenting with the Default BGP Export Policy
Verifying the Routes on Device R1
Purpose
On Device R1, check the static routes in the routing table.
Action
user@R1> show route protocol static
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.16/28 *[Static/5] 1d 02:02:13
Discard
172.16.1.32/28 *[Static/5] 1d 02:02:13
Discard
172.16.1.48/28 *[Static/5] 1d 02:02:13
Discard
172.16.1.64/28 *[Static/5] 1d 02:02:13
DiscardMeaning
Device R1 has four static routes.
Verifying the Route Advertisement to Device R4
Purpose
On Device R1, make sure that the static routes are advertised to Device R4.
Action
user@R1> show route advertising-protocol bgp 10.1.0.6 inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.16/28 Self I * 172.16.1.32/28 Self I * 172.16.1.48/28 Self I * 172.16.1.64/28 Self I
Meaning
As expected, Device R1 only advertises its static routes to Device R4.
Experimenting with the Default BGP Export Policy
Purpose
See what can happen when you remove the final then reject term from the policy main or the policy subroutine.
Action
On Device R1, deactivate the final term in the policy
main.[edit policy-options policy-statement main] user@R1# deactivate term nothing-else user@R1# commit
On Device R1, check to see which routes are advertised to Device R4.
user@R1> show route advertising-protocol bgp 10.1.0.6 inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.16/28 Self I * 172.16.1.32/28 Self I * 172.16.1.48/28 Self I * 172.16.1.64/28 Self I * 172.16.2.16/28 Self I * 172.16.2.32/28 Self I * 172.16.2.48/28 Self I * 172.16.2.64/28 Self I * 172.16.3.16/28 Self I * 172.16.3.32/28 Self I * 172.16.3.48/28 Self I * 172.16.3.64/28 Self I
Now, all the BGP routes from Device R1 are sent to Device R4. This is because after the processing is returned to policy
main, the default BGP export policy takes effect.On Device R1, reactivate the final term in the policy
main, and deactivate the final term in the policysubroutine.[edit policy-options policy-statement main] user@R1# activate term nothing-else [edit policy-options policy-statement subroutine] user@R1# deactivate term nothing-else user@R1# commit
On Device R1, check to see which routes are advertised to Device R4.
user@R1> show route advertising-protocol bgp 10.1.0.6 inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.16/28 Self I * 172.16.1.32/28 Self I * 172.16.1.48/28 Self I * 172.16.1.64/28 Self I * 172.16.2.16/28 Self I * 172.16.2.32/28 Self I * 172.16.2.48/28 Self I * 172.16.2.64/28 Self I * 172.16.3.16/28 Self I * 172.16.3.32/28 Self I * 172.16.3.48/28 Self I * 172.16.3.64/28 Self I
Now, all the BGP routes from Device R1 are sent to Device R4. This is because before the processing is returned to policy
main, the default BGP export policy takes effect in the policysubroutine.
Meaning
To prevent the default BGP export policy from taking
effect, you must include a final then reject term in the
main policy and in all referenced subroutines.