Configuring BGP Routing Policy

Routing policy determines how the router handles the routes it receives from and sends to BGP peers or other routing protocols. In many cases, routing policy consists of filtering routes, accepting certain routes, accepting and modifying other routes, and rejecting some routes. You can think of routing policy as a way to control the flow of routes into and out of the router.

You can use one or more of the following mechanisms to configure routing policy:

The remainder of this section provides detailed information about using these features with BGP. Before proceeding, please see JunosE IP Services Configuration Guide, for a thorough background on how these features work in general.

Types of BGP Route Maps

A route map consists of match clauses and set clauses. Match clauses, which consist of a match command, specify the attribute values that determine whether a route matches the route map. Set clauses, which consist of a set command, modify the specified attributes of routes that pass all match clauses in the route map.

BGP route maps can be applied to inbound routes, outbound routes, and redistributed routes. BGP route maps are of two types, those that support both match and set clauses, and those that support only match clauses.

The match-and-set route maps consist of the route maps configured with any of the commands listed in Table 14.

Table 14: Commands That Create Match-and-Set Route Maps

aggregate-address attribute-map

global import map

bgp dampening route-map

neighbor route-map in

export map

neighbor route-map out

import map

redistribute route-map

global export map

table-map

BGP supports the clauses listed in Table 15 for match-and-set route maps.

Table 15: Clauses Supported in BGP Match-and-Set Route Maps

match as-path

set as-path prepend

match community

set comm-list delete

match distance

set community

match extcommunity

set dampening

match ip address

set extcommunity

match ip next-hop

set ip next-hop

match level

set local-preference

match metric

set metric

match metric-type

set metric-type

match route-type

set origin

match tag

set tag

 

set weight

The match-only route maps consist of the route maps configured with any of the commands listed in Table 16. You can use any of the match clauses listed in Table 15 in these route maps. Set clauses have no effect in these route maps.

Table 16: Commands That Create Match-Only Route Maps

aggregate advertise-map

aggregate support-map

BGP does not support the clauses listed in Table 17. However, see Applying Table Maps for exceptions for route maps applied with the table-map command.

Table 17: Clauses Not Supported in BGP Route Maps

set automatic-tag

set level

set distance

set route-type

match as-path

match community

match distance

match extcommunity

match ip address

match ip next-hop

match level

match metric

match metric-type

match route-type

match tag

neighbor route-map

route-map

set as-path prepend

set comm-list delete

set community

set dampening

set extcommunity

set ip next-hop

set local-preference

set metric

set metric-type

set origin

set tag

set weight

Applying Table Maps

You can use the table-map command on a per-address-family basis to apply a route map to modify IP attributes of BGP routes that are about to be added to the IP routing table. In these route maps, you can use only the set clauses in Table 18.

Table 18: Set Clauses Supported in Route Maps Applied with the Table-Map Command

set distance

set metric-type

set level

set route-type

set metric

set tag

set distance

set level

set route-type

table-map

For example, suppose you want to change the distance and metric attributes to particular values for routes advertised by a members of a particular community. The show ip route bgp command indicates that the routes currently in the table have a variety of values for these attributes:

host1#show ip route bgp 
Protocol/Route type codes:
  I1- ISIS level 1, I2- ISIS level2,
  I- route type intra, IA- route type inter, E- route type external,
  i- metric type internal, e- metric type external,
  O- OSPF, E1- external type 1, E2- external type2,
  N1- NSSA external type1, N2- NSSA external type2
  Prefix/Length     Type      Next Hop        Dist/Met        Intf        
------------------ ------- --------------- -------------- ------------
10.100.3.3/32        Bgp     10.12.12.1       20/0           ATM5/1.12         
10.63.42.23/32      Bgp     10.45.2.31       12/5          ATM5/1.14 

The following commands demonstrate how you can apply the policy to change these values:

host1(config)#route-map distmet1 permit 5 host1(config-route-map)#match community boston42 host1(config-route-map)#set distance 33 host1(config-route-map)#set metric 44 host1(config-route-map)#exit host1(config)#router bgp 100 host1(config-router)#table-map distmet1 host1(config-router)#exit host1(config)#exit host1#clear ip routes *

The show ip route bgp command reveals the new values:

host1#show ip route bgp 
Protocol/Route type codes:
  I1- ISIS level 1, I2- ISIS level2,
  I- route type intra, IA- route type inter, E- route type external,
  i- metric type internal, e- metric type external,
  O- OSPF, E1- external type 1, E2- external type2,
  N1- NSSA external type1, N2- NSSA external type2
  Prefix/Length     Type      Next Hop        Dist/Met        Intf        
------------------ ------- --------------- -------------- ------------
10.100.3.3/32        Bgp     10.12.12.1       33/44           ATM5/1.12         
10.63.42.23/32      Bgp     10.45.2.31      33/44          ATM5/1.14 

Access Lists

An access list is a sequential collection of permit and deny conditions that you can use to filter inbound or outbound routes. You can use different kinds of access lists to filter routes based on either the prefix or the AS path.

Filtering Prefixes

To filter routes based on the prefix, you can do any of the following:

The router compares each route’s prefix against the conditions in the list or tree one by one. If the first match is for a permit condition, the route is accepted or passed. If the first match is for a deny condition, the route is rejected or blocked. The order of conditions is critical because testing stops with the first match. If no conditions match, the router rejects or blocks the address; that is, the last action of any list is an implicit deny condition for all routes. The implicit rule is displayed by show access-list and show configuration commands.

You cannot selectively place conditions in or remove conditions from an access list, prefix, list, or prefix tree. You can insert a new condition only at the end of a list or tree.

Consider the network structure in Figure 21.

Figure 21: Filtering with Access Lists

Filtering with Access Lists

The following commands configure router Boston to apply access list reject1 to routes inbound from router SanJose. Access list reject1 rejects routes matching 172.24.160.0/19.

host3(config)#router bgp 17 host3(config-router)#neighbor 10.5.5.4 remote-as 873 host3(config-router)#neighbor 10.5.5.4 distribute-list reject1 in host3(config-router)#exit host3(config)#access-list reject1 permit 172.24.48.0 0.0.255 host3(config)#access-list reject1 deny 172.24.160.0 0.0.255 host3(config)#access-list reject1 permit 172.24.24.0 0.0.255

Consider the network shown in Figure 22. Router NY originates network 10.16.22.0/23 and advertises it to router LA. Suppose you do not want router LA to advertise that network to router Boston. You can apply an access list to updates from router LA to router Boston that prevents router LA from propagating updates for network 10.16.22.0/23.

Figure 22: Filtering Routes with an Access List

Filtering Routes with an Access List

The following commands configure router LA:

host2(config)#router bgp 400 host2(config-router)#network 172.24.160.0 mask 255.255.224.0 host2(config-router)#neighbor 10.72.4.2 remote-as 300 host2(config-router)#neighbor 10.5.5.1 remote-as 100 host2(config-router)#neighbor 10.5.5.1 distribute-list 1 out host2(config-router)#exit host2(config)#access-list 1 deny 10.16.22.0 0.254.255.255

access-list

clear access-list

neighbor distribute-list

neighbor prefix-list

neighbor prefix-tree

Filtering AS Paths with a Filter List

You can use a filter list to filter incoming and outgoing routes based on the value of the AS-path attribute. Whenever a BGP route passes through an AS, BGP prepends its AS number to the AS-path attribute. The AS-path attribute is the list of ASs that a route has passed through to reach a destination.

To filter routes based on the AS-path, define the access list with the ip as-path access-list command, and apply the list to routes received from or passed to a neighbor with the neighbor filter-list command. AS-path access lists use regular expressions to describe the AS path to be matched. A regular expression uses special characters—often referred to as metacharacters—to define a pattern that is compared with an input string. For a full discussion of regular expressions, with examples on how to use them, see JunosE IP Services Configuration Guide.

The router compares each route’s AS path against the conditions in the access list one by one. If the first match is for a permit condition, the route is accepted or passed. If the first match is for a deny condition, the route is rejected or blocked. The order of conditions is critical because testing stops with the first match. If no conditions match, the router rejects or blocks the route; that is, the last action of any list is an implicit deny condition for all routes.

You cannot selectively place conditions in or remove conditions from an AS-path access list. You can insert a new condition only at the end of an AS-path access list.

Example 1

Consider the network structure in Figure 23.

Figure 23: Filtering with AS-Path Access Lists

Filtering with AS-Path Access Lists

Suppose you want router London to behave in the following way:

The following commands configure router London to apply filters based on the AS path to routes received from router Berlin and router Paris and to routes forwarded to router Madrid.

host1(config)#router bgp 47 host1(config-router)#neighbor 10.2.9.2 remote-as 621 host1(config-router)#neighbor 10.2.9.2 filter-list 1 in host1(config-router)#neighbor 10.2.8.2 remote-as 11 host1(config-router)#neighbor 10.2.8.2 filter-list 2 in host1(config-router)#neighbor 10.2.7.2 remote-as 435 host1(config-router)#neighbor 10.2.7.2 filter-list 3 out host1(config-router)#exit host1(config)#ip as-path access-list 1 deny ^621_11$ host1(config)#ip as-path access-list 1 permit .* host1(config)#ip as-path access-list 2 deny ^11_621$ host1(config)#ip as-path access-list 2 permit .* host1(config)#ip as-path access-list 3 deny ^11_621_282 host1(config)#ip as-path access-list 3 deny ^621_11_282 host1(config)#ip as-path access-list 3 permit .*

AS-path access list 1 is applied to routes that router London receives from router Paris. Router London rejects routes with the AS path (621 11).

AS-path access list 2 is applied to routes that router London receives from router Berlin. Router London rejects routes with the AS path (11 621) or (621 282 11).

Router London accepts routes with the AS path (11 282), (621 282), (621 11 282), or (11 621 282). However, it applies AS-path access list 3 to routes it forwards to router Madrid, and filters out routes with the AS path (621 11 282) or (11 621 282).

Example 2

Consider the following commands used to configure router Chicago in Figure 24:

host1(config)#router bgp 293 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.5.5.2 filter-list 1 in host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#exit host1(config)#ip as-path access-list 1 deny ^32$

Figure 24: Assigning a Filter List

Assigning a Filter List

Access list 1 denies routes that originate in AS 32—and therefore routes originated by router NY—because the AS-path attribute for these routes begins with (and indeed consists only of) the value 32.

Routes originating anywhere else—such as in AS 837, AS 17, or AS 451—are permitted, because their AS-path attributes do not begin with 32.

ip as-path access-list

neighbor filter-list

Filtering AS Paths with a Route Map

You can use a route map instead of the neighbor filter-list command to apply access lists for filtering routes. In Figure 25, suppose router Chicago is configured as follows:

host1(config)#router bgp 293 host1(config-router)#network 192.168.5.0 mask 255.255.255.0 host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 weight 150 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.5.5.2 weight 50

Figure 25: Route Map Filtering

Route Map Filtering

Routes learned from router Boston have a weight of 150, whereas those learned from router NY have a weight of 50. Router Chicago therefore prefers all routes learned from router Boston to those learned from router NY. Based on this configuration, router Chicago prefers routes to prefixes originating in AS 837 or originating in AS 32 that pass through router Boston over routes to those same prefixes that pass through router NY.

This is a longer path than you might desire. You can avoid this result by configuring a route map to modify the weight of certain routes learned by router Chicago:

host1(config-router)#neighbor 10.5.5.2 route-map alpha in host1(config-router)#exit host1(config)#route-map alpha permit 10 host1(config-route-map)#match as-path dog1 host1(config-route-map)#set weight 175 host1(config-route-map)#exit host1(config)#ip as-path access-list dog1 permit _32$ host1(config)#ip as-path access-list dog1 permit _837$ host1(config)#route-map alpha permit 20 host1(config-route-map)#match as-path dog2 host1(config-route-map)#exit host1(config)#ip as-path access-list dog2 permit .*

BGP applies route map alpha to all routes learned from 10.5.5.2 (router NY). Instance 10 of route map alpha matches routes with access list dog1. This access list permits any route whose AS-path attribute ends in 32 or 837—that is, routes that originate in AS 32 or AS 837. It sets their weight to 175, overriding the neighbor weight (50) set for updates received from 10.5.5.2. Then, instance 20 of route map alpha permits all other routes with no modification.

The result of this improved configuration is the following:

Refer to the commands and guidelines in the section Types of BGP Route Maps for more information about configuring route maps.

Configuring the Community Attribute

A community is a logical group of prefixes that share some common attribute. Community members can be on different networks and in different autonomous systems. BGP allows you to define the community to which a prefix belongs. A prefix can belong to more than one community. The community attribute lists the communities to which a prefix belongs.

You can use communities to simplify routing policies by configuring which routing information a BGP speaker will accept, prefer, or distribute to other neighbors according to community membership. When a route is learned, advertised, or redistributed, a BGP speaker can set, append, or modify the community of a route. When routes are aggregated, the resulting BGP update contains a community attribute that contains all communities from all of the aggregated routes (if the aggregate is an AS-set aggregate).

Several well-known communities have been predefined. Table 19 describes how a BGP speaker handles a route based on the setting of its community attribute.

Table 19: Action Based on Well-Known Community Membership

Well-Known Community

BGP Speaker Action

no-export

Does not advertise the route to any EBGP peers (does not advertise the route beyond the local AS)

no-advertise

Does not advertise the route to any peers, IBGP or EBGP

local-as (also known as no-export-subconfed)

Advertises the route only to peers within the local confederation

internet

Advertises this route to the Internet community; by default, all prefixes are members of the Internet community

In addition to the well-known communities, you can define local-use communities, also known as private communities or general communities. These communities serve as a convenient way to categorize groups of routes to facilitate the use of routing policies. The community attribute consists of four octets, but it is common practice to designate communities in the AA:NN format. The autonomous system number (AA) comprises the higher two octets, and the community number (NN) comprises the lower two octets. Both are expressed as decimal numbers. For example, if a prefix in AS 23 belongs to community 411, the attribute can be expressed as 23:411. Use the ip bgp-community new-format command to specify that the show commands display communities in this format.

Use the set community command in route maps to configure the community attributes. By default, the community attribute is not sent to BGP peers. To send the community attribute to a neighbor, use the neighbor send-community command.

Consider the network structure shown in Figure 26. The following sample configurations illustrate some of the capabilities of using the community attribute.

Figure 26: Communities

Communities

The following commands configure router NY to apply route map setcomm to routes going out to 10.72.4.3. If the community attribute of such a route matches instance 10 of the route map, router NY sets the community attribute to 31:15. All locally originated routes will match this instance of the route map.

host1(config)#router bgp 31 host1(config-router)#network 10.16.22.0 mask 255.255.254.0 host1(config-router)#neighbor 10.72.4.3 remote-as 425 host1(config-router)#neighbor 10.72.4.3 send-community host1(config-router)#neighbor 10.72.4.3 route-map setcomm out host1(config-router)#exit host1(config)#ip as-path access-list 1 permit ^$ host1(config)#route-map setcomm permit 10 host1(config-route-map)#match as-path 1 host1(config-route-map)#set community 31:15

The following commands configure router LA to apply route map matchcomm to routes coming in from 10.72.4.2. If the community attribute of such a route matches instance 10 of the route map, router LA sets the weight of the route to 25.

host2(config)#router bgp 425 host2(config-router)#network 172.24.160 mask 255.255.224.0 host2(config-router)#neighbor 10.72.4.2 remote-as 31 host2(config-router)#neighbor 10.72.4.2 send-community host2(config-router)#neighbor 10.72.4.2 route-map matchcomm in host2(config-router)#neighbor 10.5.5.1 remote-as 122 host2(config-router)#neighbor 10.5.5.1 send-community host2(config-router)#exit host2(config)#ip community-list 1 permit 31:15 host2(config)#route-map matchcomm permit 10 host2(config-route-map)#match community 1 host2(config-route-map)#set weight 25

The following commands configure router Boston to apply route map 5 to routes going out to 10.5.5.4. If the destination IP address of such a route matches instance 10 of the route map, router Boston sets the community attribute of the route to no-export.

host3(config)#router bgp 122 host3(config-router)#network 192.168.144.0 mask 255.255.240.0 host3(config-router)#neighbor 10.5.5.4 remote-as 425 host3(config-router)#neighbor 10.5.5.4 send-community host3(config-router)#neighbor 10.5.5.4 route-map 5 out host3(config-router)#exit host3(config)#route-map 5 permit 10 host3(config-route-map)#match ip address access5host3(config-route-map)#set community no-export host3(config-route-map)#exit host3(config)#access-list access5 permit 10.16.22.112

Suppose router Boston forwards a route destined for 10.16.22.112 through router LA. Route map 5 matches and sets the community attribute to no-export. As a consequence router LA does not export the route to router NY; the route does not reach its destination.

ip bgp-community new-format

neighbor send-community

set community

Community Lists

A community list is a sequential collection of permit and deny conditions. Each condition describes the community number to be matched. If you issued the ip bgp-community new-format command, the community number is in AA:NN format; otherwise it is in decimal format.

The router tests the community attribute of a route against the conditions in a community list one by one. The first match determines whether the router accepts (the route is permitted) or rejects (the route is denied) a route having the specified community. Because the router stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the router rejects the route.

Consider the network structure shown in Figure 27.

Figure 27: Community Lists

Community Lists

Suppose you want router Albany to set metrics for routes that it forwards to router Boston based on the communities to which the routes belong. You can create community lists and filter the routes with a route map that matches on the community list. The following commands demonstrate how to configure router Albany:

host1(config)#router bgp 293 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.2.2.1 remote-as 451 host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 route-map commtrc out host1(config-router)#exit host1(config)#route-map commtrc permit 1 host1(config-route-map)#match community 1 host1(config-route-map)#set metric 20 host1(config-route-map)#exit host1(config)#route-map commtrc permit 2 host1(config-route-map)#match community 2 host1(config-route-map)#set metric 75 host1(config-route-map)#exit host1(config)#route-map commtrc permit 3 host1(config-route-map)#match community 3 host1(config-route-map)#set metric 85 host1(config-route-map)#exit host1(config)#ip community-list 1 permit 25 host1(config)#ip community-list 2 permit 62 host1(config)#ip community-list 3 permit internet

Community list 1 comprises routes with a community of 25; their metric is set to 20. Community list 2 comprises routes with a community of 62; their metric is set to 75. Community 3 catches all remaining routes by matching the internet community; their metric is set to 85.

ip community-list

The router supports the new BGP extended community attribute. This attribute enables the definition of a new type of IP extended community and extended community list unrelated to the community list that uses regular expressions. BGP speakers can use the new extended community attribute to control routes similarly to the way it uses the community attribute. The extended community attribute is currently defined in the Internet draft, BGP Extended Communities Attribute—draft-ietf-idr-bgp-ext-communities-07.txt (February 2004 expiration).

Note: IETF drafts are valid for only 6 months from the date of issuance. They must be considered as works in progress. Please refer to the IETF Website at http://www.ietf.org for the latest drafts.

ip extcommunity-list

Resetting a BGP Connection

When a routing policy changes, use the clear ip bgp and clear bgp ipv6 commands to clear the current BGP session and implement the new policy.

Clearing a BGP session can create a major disruption in the network operation; this is known as a hard clear. For this reason, you can use the soft in and soft out options of the command (a soft clear) to activate policies without disrupting the BGP session.

The soft in option reapplies inbound policy to received routes; the soft out option resends routes to a neighbor after reapplying outbound policy. The soft in prefix-list option causes BGP to push any prefix list outbound route filters (ORFs) to the peer and then reapply inbound policy to received routes.

Note: Resetting the BGP connection is slightly different when you change outbound policies for peer groups for which you have enabled Adj-RIBs-Out. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group.

clear bgp ipv6

clear ip bgp

Changing Policies Without Disruption

Changing policies can cause major network disruptions when you bring down sessions to reapply the modified policies. You can use either of the methods in this section to minimize network disruptions.

Soft Reconfiguration

You can use soft reconfiguration to enable the nondisruptive reapplication of inbound policies. Issuing the command causes the router to store copies of the routes received from the specified peer or from all members of the specified peer group. The route copies are stored unmodified, before application of inbound policies.

If you then change your inbound policies, you can apply them to the stored routes without clearing your BGP sessions—and causing network disruptions—by issuing the clear ip bgp soft in command.

neighbor soft-reconfiguration inbound

Route-Refresh Capability

The route-refresh capability provides a lower-cost alternative to soft reconfiguration as a means to change policies without major disruptions. The router advertises the route-refresh capability when it establishes a BGP session with a peer to indicate that it is capable of exchanging BGP route-refresh messages. If inbound soft reconfiguration is disabled (the default) and you issue the clear ip bgp soft in command, the router sends route-refresh messages to its peers that have advertised this capability. The messages contain a request for the peer to resend its routes to the router. The new inbound policy is then applied to the routes as they are received.

Our implementation conforms to RFC 2918—Route Refresh Capability for BGP-4 (September 2000), but it also supports nonstandard implementations.

Cooperative Route Filtering

If a BGP speaker negotiates the cooperative route filtering capability with a peer, then the speaker can transfer inbound route filters to the peer. The peer then installs the filter as an outbound route filter (ORF) on the remote end. The ORF is applied by the peer after application of its configured outbound policies. This cooperative filtering has the advantage of both reducing the amount of processing required for inbound BGP updates and reducing the amount of BGP control traffic generated by BGP updates.

clear ip bgp

neighbor capability

neighbor maximum-orf-entries

neighbor prefix-list

Configuring Route Flap Dampening

Route flap dampening is a mechanism for minimizing instability caused by route flapping. Route flapping occurs when a link is having a problem and is constantly going up and down. Every time the link goes down, the upstream peer withdraws the routes from all its neighbors. When the link comes back up again, the peer advertises those routes globally. When the link problem appears again, the peer withdraws the routes again. This process continues until the underlying problem is fixed.

The router stores a penalty value with each route. Each time the route flaps, the router increases the penalty by 1000. If the penalty for a route reaches a configured suppress value, the router suppresses the route. That is, the router does not include the route as a forwarding entry and does not advertise the route to BGP peers.

The penalty decrements by 50 percent for each half-life interval that passes. The half-life interval resets when the route flaps and the penalty increments. The route remains suppressed until the penalty falls below the configured reuse threshold, at which point the router once again advertises the route. You can specify a max-suppress-time for route suppression; after this interval passes, the router once again advertises the route.

BGP creates a dampening parameter block for each unique set of dampening parameters—such as suppress threshold and reuse threshold—used by BGP. For example, if you have a route map that sets the dampening parameters to one set of values for some routes and to another set of values for the remaining routes, BGP uses and stores two dampening parameter blocks, one for each set.

Global Route Flap Dampening

Use the bgp dampening command if you want to enable route flap dampening with the same values on all BGP routes, or on all routes matching the specified route map. If you specify a route map, the router dampens only routes that are permitted by the route map. For example:

host1(config-router)#bgp dampening 8 600 2500 30 route-map 1

bgp dampening

clear bgp ipv6 dampening

clear ip bgp dampening

Policy-Based Route Flap Dampening

You can use policy-based route flap dampening to apply different dampening criteria to different routes. Establish one or more match clauses for an instance of a route map. Then use the set dampening command to specify the dampening values that apply to routes that pass all the match clauses for that route map. Consider the following example:

host1(config)#route-map 21 permit 5 host1(config-route-map)#match as-path 1 host1(config-route-map)#set dampening 5 1000 1500 45 15 host1(config-route-map)#exit host1(config)#ip as-path access-list 1 permit ^300_

Access list 1 permits routes that originate in AS 300. Instance 5 of route map 21 permits routes that match access list 1 and applies the set of dampening criteria to only those routes; in this case, routes that originate in AS 300.

You can restore the advertisement of routes suppressed as a result of policy-based route flap dampening by issuing the neighbor unsuppress-map command. You can unsuppress routes from a specified neighbor or peer group. You must specify a route map; only those routes that match the route map are unsuppressed.

neighbor unsuppress-map

set dampening

Policy Testing

You can analyze and check your BGP routing policies on your network before you implement the policies. Use the test ip bgp neighbor and test bgp ipv6 neighbor commands to test the outcome of a BGP policy. The commands output displays the routes that are advertised or accepted if the specified policy is implemented.

Note: You can use the standard redirect operators to redirect the test output to network or local files. See the section JunosE System Basics Configuration Guide.

BGP routes must be present in the forwarding table for these commands to work properly. If you run the policy test on incoming routes, soft reconfiguration (configured with the neighbor soft reconfiguration in command) must be in effect.

Note: The output of these commands is always speculative. It does not reflect the current state of the router.

test bgp ipv6 neighbor

test ip bgp neighbor