Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring a Policy Subroutine

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

On Device R1, a policy called main is configured.

This main policy calls a subroutine called subroutine.

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.

Figure 1: BGP Topology for Policy Subroutine

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section Step-by-Step Procedure 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.

Step-by-Step Procedure

1. Configure the device interfaces.
   [edit interfaces]user@R1# set fe-1/2/0 unit 0 description to_R2user@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_R3user@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_R4user@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
2. Configure the internal BGP (IBGP) connections to Device R2 and Device R3.
   [edit protocols bgp group int]user@R1# set type internaluser@R1# set local-address 192.168.0.1user@R1# set neighbor 192.168.0.2user@R1# set neighbor 192.168.0.3
3. Configure the EBGP connection to Device R4.
   [edit protocols bgp group to_64511]user@R1# set type externaluser@R1# set export mainuser@R1# set neighbor 10.1.0.6 peer-as 64511
4. 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.0user@R1# set interface fe-1/2/2.0user@R1# set interface lo0.0 passive
5. Configure the policy main.
   [edit policy-options policy-statement main term subroutine-as-a-match]user@R1# set from policy subroutineuser@R1# set then accept
   [edit policy-options policy-statement main term nothing-else]user@R1# set then reject
6. Configure the policy subroutine.
   [edit policy-options policy-statement subroutine term get-routes]user@R1# set from protocol staticuser@R1# set then accept
   [edit policy-options policy-statement subroutine term nothing-else]user@R1# set then reject
7. 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 discarduser@R1# set route 172.16.1.32/28 discarduser@R1# set route 172.16.1.48/28 discarduser@R1# set route 172.16.1.64/28 discard
8. Configure the autonomous system (AS) number and router ID.
   [edit routing-options]user@R1# set router-id 192.168.0.1user@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.

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

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
                      Discard

Meaning

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

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

1. On Device R1, deactivate the final term in the policy main.
   [edit policy-options policy-statement main]user@R1# deactivate term nothing-elseuser@R1# commit
2. 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.

3. On Device R1, reactivate the final term in the policy main, and deactivate the final term in the policy subroutine.
   [edit policy-options policy-statement main]user@R1# activate term nothing-else
   [edit policy-options policy-statement subroutine]user@R1# deactivate term nothing-elseuser@R1# commit
4. 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 policy subroutine.

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.