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 access5  host3(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 Web site 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

						Copyright© 1999-2012 Juniper Networks, Inc. 
							All rights reserved.