[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring BGP Routing Policy

Routing policy determines how the system 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 system. You can use one or more of the following mechanisms to configure routing policy: Access lists Prefix trees

Community lists Route maps Prefix lists

The remainder of this section provides detailed information on using these features with BGP. Before proceeding, please see ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 1, Configuring Routing Policy, 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 matchclauses. The match-and-set route maps consist of the route maps configured with any of the commands listed in Table 1-8.

Table 1-8 Commands that create match-and-set route maps

aggregate-address attribute-map redistribute route-map bgp dampening route-map neighbor route-map in neighbor route-map out table-map vrf import-map vrf export-map

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

Table 1-9 Clauses supported in BGP match-and-set route maps

match as-path match community match distance set as-path prepend set comm-list delete set community

match extcommunity set dampening match ip address match ip next-hop match level match metric match metric-type match route-type match tag set extcommunity set ip next-hop set local-preference set metric set metric-type set origin set tag set weight

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

Table 1-10 Commands that create match-only route maps

aggregate advertise-map aggregate support-map

BGP does not support the clauses listed in Table 1-11. However, see the section later in this chapter, Applying Table Maps, for exceptions for route maps applied via the table-map command.

Table 1-11 Clauses not supported in BGP route maps

set automatic-tag set level set distance set route-type

match as-path
Use to match an AS-path access list. The implemented weight is based on the first matched AS path. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match as-path pathlist5 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match community
Use to match a community list. Supported for inbound and outbound route maps. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match community comm5 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match distance
Use to match any routes that have the specified administrative distance. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match distance 25 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match extcommunity
Use to match an extended community list in a route map. You can specify one or more extended community list names in a match clause. If you specify more than one extended community list, the lists are logical ORed. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match extcommunity topeka10 Use the no version to remove the match clause from a route map or a specified value from the match clause.

match ip address
Use to match any route that has a destination network number that is permitted by an access list, a prefix list, or a prefix tree, or performs policy routing on packets. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match ip address prefix-tree boston

 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match ip next-hop
Use to match any routes that have a next-hop router address passed by the specified access list, prefix list, or prefix tree. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match ip next-hop 5 192.54.24.1 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match level
Use to match routes for the specified type. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match level-1 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match metric
Use to match a route for the specified metric value. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match metric 10 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match metric-type
Use to match a route for the specified metric type. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match metric-type external Use the no version to delete the match clause from a route map.

match route-type
Use to match a route for the specified route type.

Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match route-type level-1 Use the no version to delete the match clause from a route map or a specified value from the match clause.

match tag
Use to match the tag value of the destination routing protocol. Example

host1(config)#route-map 1 host1(config-route-map)#match tag 25 Use the no version to delete the match clause from a route map or a specified value from the match clause.

neighbor route-map
Use to apply a route map to incoming or outgoing routes. If you specify an outbound route map, BGP advertises only routes that match at least one section of the route map. A clause with multiple values matches a route having any of the values; that is, the multiple values are logical ORed. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to remove the route map.

route-map
Use to define the conditions for redistributing routes from one routing protocol into another, and for filtering or modifying updates sent to or received from peers.

 Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteriathe conditions under which redistribution is allowed for the current route map. The set commands specify the set actionsthe redistribution actions to perform if the criteria enforced by the match commands are set. Use route maps when you wish to have detailed control over how routes are redistributed between routing processes. The destination routing protocol is the one you specify with the router command. The source routing protocol is the one you specify with the redistribute command. A clause with multiple values matches a route having any of the values; that is, the multiple values are logical ORed. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. Use the no version to delete the route map.

set as-path prepend

Use to modify an AS path for BGP routes by prepending one or more AS numbers or a list of AS numbers to the path list. The only global BGP metric available to influence the best-path selection is the AS-path length. By varying the length of the AS path, a BGP speaker can influence the best-path selection by a peer farther away. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set as-path prepend list list10 Use the no version to delete the set clause from a route map.

set comm-list delete

Use to remove communities specified by the community list from the community attribute of routes matching the route map. You can use this command to delete communities only if the community list was created with a single community per list entry as shown in the following sample configuration for router Test: host1(config)#ip community-list 1 permit 231:10 host1(config)#ip community-list 1 permit 231:20 host1(config)#router bgp 45 host1(config-router)#neighbor 10.6.2.5 remote-as 5 host1(config-router)#neighbor 10.6.2.5 route-map indelete in host1(config-router)#route-map indelete permit 10 host1(config-route-map)#set comm-list 1 delete Router Test receives the same route from 10.6.2.5 and applies the indelete route map. BGP compares each list entry with the community attribute. A match is found for the list entry 231:10, and this community is deleted from the community attribute. Similarly, a match is found for the list entry of 231:20, and this community is deleted from the community attribute.

Use the no version to delete the set clause from a route map.

set community
Use to set the community attribute in BGP updates. You can specify a community list number in the range 1-4294967295, or in the new community format of AA:NN, or one of the following well-known communities: local-as - prevents advertisement outside the local AS no-advertise - prevents advertisement to any peer no-export - prevents advertisement beyond the BGP confederation boundary

Alternatively, you can use the list keyword to specify the name of a community list that you previously created with the ip community-list command. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set community no-advertise Use the none keyword to remove the community attribute from a route. Use the no version to delete the set clause from a route map.

set dampening
Use to enable BGP route flap dampening only on routes that pass the match clauses of, and are redistributed by, a particular route map. BGP creates a dampening parameter block for each unique set of dampening parameterssuch as suppress threshold and reuse thresholdused 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. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set dampening 5 1000 1500 45 15 Use the no version to delete the set clause from a route map.

set extcommunity
Use to set the extended community attributes in a route map for BGP updates. You can specify a site-of-origin (soo) extended community and a route target (rt) extended community at the same time in a set clause without overwriting the other. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set extcommunity rt 10.10.10.2:325 Use the no version to delete the set clause from a route map.

set ip next-hop

Use to set the next hop attribute of a route that matches a route map. You can specify an IP address or an interface as the next hop. Use the peer-address keyword to have the following effect: On outbound route maps, disables the next hop calculation by setting the next hop to the IP address of the BGP speaker On inbound route maps, overrides any third-party next-hop configuration by setting the next hop to the IP address of the peer

Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set ip next-hop 192.56.32.1 Use the no version to delete the set clause from a route map.

set local-preference
Use to specify a preference value for the AS path. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set local-preference 200 Use the no version to delete the set clause from a route map.

set metric
Use to set the metric valuefor BGP, the MEDfor a route. To establish an absolute metric, do not enter a plus or minus sign before the metric value. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric 10 To establish a relative metric, specify a plus or minus sign immediately preceding the metric value. The value is added to or subtracted from the metric of any routes matching the route map. The relative metric value can range from 0 to 4294967295. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric -25 You cannot use both an absolute metric and a relative metric within the same route map sequence. Setting either metric overrides any previously configured value. Use the no version to delete the set clause from a route map.

set metric-type

 Use to set the metric type for a route. For BGP, affects all types of route maps. If the route map contains both a set metric-type and a set metric clause, the set metric clause takes precedence. Specifying the internal metric type in a BGP outbound route map, BGP sets the MED of the advertised routes to the IGP cost of the next hop of the advertised route. If the cost of the next hop changes, BGP is not forced to readvertise the route. For BGP, you can specify the following: external - reverts to the normal BGP rules for propagating the MED; this is the BGP default internal - sets the MED of a received route that is being propagated to an external peer equal to the IGP cost of the indirect next-hop Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric-type internal Use the no version to delete the set clause from a route map.

set origin
Use to set the BGP origin of the advertised route. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set origin egp Use the no version to delete the set clause from a route map.

set tag
Use to set the tag value of the destination routing protocol. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set tag 23 Use the no version to delete the set clause from a route map.

set weight
Use to specify the BGP weight for the routing table. The weights assigned with the set weight command in a route map override the weights assigned using the neighbor weight and neighbor filter-list weight commands. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set weight 200

Use the no version to delete the set clause from a route map.

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. You can use only the set clauses listed in Table 1-12 in these route maps.

Table 1-12 Set clauses supported in route maps applied via the table-map command
set distance set metric-type set ip next-hop set route-type set level set metric set tag

set distance
Use to set the administrative distance attribute on routes being installed into the routing table that match the route map. Distance is used to establish preference between routes to the same prefix to identify the best route to that prefix. Setting distance in any other circumstance has no effect. Example host1(config-route-map)#set distance 5 Use the no version to delete the set clause from a route map.

set level
Use to specify where to import routes when all of a route map's match criteria are met. Example host1(config-route-map)#set level level-2 Use the no version to delete the set clause from a route map.

set route-type
Use to set the routes of the specified type. Example

host1(config-route-map)#set route-type internal Use the no version to delete the set clause from a route map.

table-map
Use to apply a policy to BGP routes about to be added to the IP routing table. The route map can include any of the clauses listed in Table 1-12. The new route map is applied to all routes that are subsequently placed in the IP routing table. To apply the new table map to routes that are already present in the IP routing table, you must refresh the IP routing table with the clear ip routes * command or the clear ip bgp * command (this command will bounce the BGP sessions). Example host1(config-router)#table-map distmet1 host1(config-router)#exit host1(config)#exit host1#clear ip routes * Use the no version to halt application of the route 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.1 2 10.63.42.23/32 Bgp 10.45.2.31 33/44 ATM5/1.1 4

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: Define an access list with the access list command and apply the list to routes received from or passed to a neighbor with the neighbor distribute-list command. Define a prefix list with the ip prefix-list command and apply the list to routes received from or passed to a neighbor with the neighbor prefix-list command. Define a prefix tree with the ip prefix-tree command and apply the list to routes received from or passed to a neighbor with the neighbor prefix-tree command. 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 ip access-list and show config 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 1-15.

Figure 1-15 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 1-16. 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 1-16 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
Use to define an IP access list to permit or deny routes based on the prefix. Each access list is a set of permit or deny conditions for routes based on matching a route's prefix. Use the neighbor distribute-list command to apply the access list to routes received from or forwarded to a neighbor. Use the log keyword to log an Info event in the ipAccessList log whenever an access-list rule is matched. Use the no version to delete an IP access list or the specified entry in the access list.

clear access-list
Use to clear IP access list counters.r Each access list has a counter for its entries. Example

host1#clear access-list reject1 There is no no version.

neighbor distribute-list
Use to filter routes to selected prefixes as specified in an access list. Using distribute lists is one of three ways to filter BGP advertisements. The other ways are as follows: Use AS-path filters with the ip as-path access-list and the neighbor filterlist commands. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy Use filters with route maps with the route-map and the neighbor routemap commands. New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.

Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to disassociate the access list from a neighbor.

neighbor prefix-list
Use to assign an inbound or outbound prefix list. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy Example host1(config-router)#neighbor 192.168.1.158 prefix-list seoul19 in New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to remove the prefix list.

neighbor prefix-tree
Use to assign an inbound or outbound prefix tree. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy Example host1(config-router)#neighbor 192.168.1.158 prefix-tree newyork out

 New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to remove the 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 charactersoften referred to as metacharactersto 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 Using Regular Expressions in ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 1, Configuring Routing Policy. 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 1-17.

Figure 1-17 Filtering with AS-path access lists Suppose you want router London to behave in the following way: Accept routes originated in AS 621 only if they pass directly to router London Accept routes originated in AS 11 only if they pass directly to router London Forward routes from AS 282 to AS 435 only if they pass through either AS 621 or AS 11, but not both AS 621 and AS 11 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 host1(config-router)#neighbor 10.2.9.2 host1(config-router)#neighbor 10.2.8.2 host1(config-router)#neighbor 10.2.8.2 host1(config-router)#neighbor 10.2.7.2 host1(config-router)#neighbor 10.2.7.2 host1(config-router)#exit host1(config)#ip as-path access-list 1 host1(config)#ip as-path access-list 1 host1(config)#ip as-path access-list 2 host1(config)#ip as-path access-list 2 host1(config)#ip as-path access-list 3 host1(config)#ip as-path access-list 3 host1(config)#ip as-path access-list 3

remote-as 621 filter-list 1 in remote-as 11 filter-list 2 in remote-as 435 filter-list 3 out deny ^621_11$ permit .* deny ^11_621$ permit .* deny ^11_621_282 deny ^621_11_282 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 1-18: host1(config)#router bgp 293 host1(config-router)#neighbor 10.5.5.2 host1(config-router)#neighbor 10.5.5.2 host1(config-router)#neighbor 10.2.2.4 host1(config-router)#exit host1(config)#ip as-path access-list 1

remote-as 32 filter-list 1 in remote-as 17 deny ^32$

Figure 1-18 Assigning a filter list Access list 1 denies routes that originate in AS 32and 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 elsesuch as in AS 837, AS 17, or AS 451are permitted, because their AS-path attributes do not begin with 32.

ip as-path access-list
Use to define an AS-path access list to permit or deny routes based on the AS path. Each access list is a set of permit or deny conditions for routes based on matching a route's AS path with a regular expression. If the regular expression matches the representation of the AS path of the route as an ASCII string, then the permit or deny condition applies. The AS path does not contain the local AS number. Use the neighbor filter-list command to apply the AS-path access list. You can apply access list filters to inbound and outbound BGP routes. You can assign weights to routes matching the AS-path access list.

 Use the no version to remove a single access list entry if permit or deny and a path-expression are specified. Otherwise, the entire access list is removed.

neighbor filter-list
Use to assign an AS-path access list to matching inbound or outbound routes with the in or out keywords. You can specify an optional weight value with the weight keyword to assign a relative importance to incoming routes matching the AS-path access list. The name of the access list is a string of up to 32 characters. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to disassociate the access list from a neighbor.

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 1-19, 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 1-19 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 via router Boston to those learned via 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 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 host1(config)#ip as-path access-list dog1 permit 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 alpha in

_32$ _837$

.*

BGP applies route map alpha to all routes learned via 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 837that 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:

 Router Chicago prefers routes learned via router Boston (weight 150) over routes learned via router NY (weight 50), except that Router Chicago prefers routes learned via router NY that originate in AS 837 or AS 32 (weight 175 as a result of route map alpha) over the same routes learned via router Boston (weight 150). Refer to the commands and guidelines beginning on p 1-53 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 1-13 describes how a BGP speaker handles a route based on the setting of its community attribute.

Table 1-13 Action based on well-known community membership

If the well-known community is... no-export no-advertise local-as (also known as noexport-subconfed) internet The BGP speaker... Does not advertise the route to any EBGP peers (does not advertise the route beyond the local AS) Does not advertise the route to any peers, IBGP or EBGP Advertises the route only to peers within the local confederation 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 could 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 1-20. The following sample configurations illustrate some of the capabilities of using the community attribute.

Figure 1-20 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 via 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
Use to specify that communities must be displayed in AA:NN format, where AA is a number that identifies the autonomous system and NN is a number that identifies the community within the autonomous system. Use the no version to restore the default display.

neighbor send-community
Use to specify that a community attribute should be sent to a BGP neighbor. You can specify that only standard communities, only extended communities, or both be sent. When you create a neighbor in a VPNv4 address family, that neighbor automatically gets a neighbor send-community both command; this command subsequently appears in a show configurationdisplay because it is not the default. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member. Example host1(config-router)#neighbor send-community westcoast extended New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.

To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to send only standard communities to a BGP neighbor. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.

set community
Use to set the community attribute in BGP updates. You can specify a community list number in the range 1-4294967295, or in the new community format of AA:NN, or one of the following well-known communities: local-as - prevents advertisement outside the local AS no-advertise - prevents advertisement to any peer no-export - prevents advertisement beyond the BGP confederation boundary

Alternatively, you can use the list keyword to specify the name of a community list that you previously created with the ip community-list command. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set community no-advertise Use the none keyword to remove the community attribute from a route. Use the no version to delete the set clause from a route map.

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 1-21.

Figure 1-21 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
Creates a standard or a regular expression community list for BGP and controls access to it. A route can belong to any number of communities, so a community list can have many entries comprising many communities. You can specify one or more community values when you create a community list. A clause in a route map that includes a list having more than one value only matches a route having all of the values; that is, the multiple values are logical ANDed. Example host1(config)#ip community-list 1 permit 100:2 100:3 100:4 host1(config)#route-map marengo permit 10 host1(config-route-map)#match community 1 A route matches this community list only if it belongs to at least all three communities in community list 1: Communities 100:2, 100:3, and 100:4. Use the no version to remove a single community list entry if permit or deny and a path-expression are specified. Otherwise, the entire community list is removed. The system 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-05.txt (November 2002 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
Use to create an extended community list for BGP and control access to it. A route can belong to any number of communities, so an extended community list can have many entries comprising many communities. You can specify one or more community values when you create an extended community list. A clause in a route map that includes a list having more than one value only matches a route having all of the values; that is, the multiple values are logical ANDed. Example host1(config)#ip extcommunity-list boston1 permit 100:2 100:3 100:4 host1(config)#route-map marengo permit 10 host1(config-route-map)#match extcommunity boston1

A route matches this community list only if it belongs to at least all three communities in extended community list boston1: Communities 100:2, 100:3, and 100:4. Use the no version to remove a single extended community list entry if permit or deny and a path-expression are specified. Otherwise, the entire community list is removed.

Resetting a BGP Connection

When a routing policy changes, use the clear ip bgp command 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 clear ip bgp 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.

clear ip bgp
Use to clear the current BGP connection or to activate a new policy without clearing the BGP session. You can specify the IP address of a BGP neighbor, the name of a BGP peer group, or an address family to be cleared. Use the asterisk (*) to clear all BGP connections. If you do not use the soft in or soft out options, the clear is known as a hard clear and clears the current BGP connection. Use the soft in option to reapply inbound policy to all received routes without clearing the BGP session. Use the soft in prefix-list option to push an ORF to the peer and reapply inbound policy to all received routes without clearing the BGP session. Use the soft out option to reapply outbound policy and resend routes without clearing the BGP session. This command takes effect immediately. There is no no version.

Changing Polices 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 system 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 sessionsand causing network disruptionsby issuing the clear ip bgp soft in command.

neighbor soft-reconfiguration inbound

Use to initiate the storage of copies of routes received from the specified IP address or from all members of the specified peer group. Use with the clear ip bgp soft in command to reapply inbound policies to stored routes without clearing the BGP sessions. Example host1(config)#router bgp 37 host1(config-router)#neighbor 192.168.1.1 remote-as 42 host1(config-router)#neighbor 192.168.1.1 soft-reconfiguration inbound If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. If the route-refresh capability was negotiated with the peer, BGP immediately sends a route-refresh message to the peer to populate the Adj-RIBs-In table. If the route-refresh capability was not negotiated with the peer, BGP automatically bounces the session. The Adj-RIBs-In table is repopulated when routes are received from the peer after the session comes back up. Use the no version to disable storage of the route copies. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.

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 system 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 system 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 system. 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 soft prefix-filter

Use to push an ORF to the peer and reapply inbound policy to all received routes without clearing the BGP session.

 You can specify the IP address of a BGP neighbor, the name of a BGP peer group, or an address family to be cleared. Use the asterisk (*) to clear all BGP connections. If the ORF capability is not configured or received on the peer, then the prefixfilter keyword is ignored and the system performs a normal inbound soft reconfiguration. This command takes effect immediately. There is no no version.

neighbor capability
Use to negotiate the exchange of inbound route filters and their installation as ORFs by specifying the orf keyword, an ORF type, and the direction of the capability. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. You cannot configure the receive direction for the orf capability for a peer that is a member of a peer group or for a peer. Example host1(config-router)#neighbor 192.168.1.158 capability orf prefix-list both When issued with the orf keyword, this command takes effect immediately and automatically bounces the BGP session. Use the no version to prevent advertisement of the capability.

neighbor maximum-orf-entries
Use to set the maximum number of ORF entries of any one type that will be accepted from the specified neighbor. Example host1(config-router)#neighbor 192.168.1.158 maximum-orf-entries 125000 Use the no version to restore the default value of no limits.

neighbor prefix-list
Use to assign an inbound or outbound prefix list. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy Example host1(config-router)#neighbor 192.168.1.158 prefix-list seoul19 in

 New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to remove the 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 system stores a penalty value with each route. Each time the route flaps, the system increases the penalty by 1000. If the penalty for a route reaches a configured suppress value, the system suppresses the route. That is, the system 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 system once again advertises the route. You can specify a max-suppress-time for route suppression; once this interval passes, the system once again advertises the route. BGP creates a dampening parameter block for each unique set of dampening parameterssuch as suppress threshold and reuse thresholdused 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 system 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

 Use to enable BGP route flap dampening on all BGP routes or routes matching a specified route map. You can specify a complete set of values that determine how routes are dampened. If you choose to do so, you must specify the entire set: half-life - when this period expires, the penalty assigned to a route is decreased by half reuse - when the penalty for a flapping route falls below this limit, the route is unsuppressed (added back to the BGP table and used for forwarding) suppress - when a route's penalty exceeds this limit, the route is suppressed max-suppress-time - when the period a route has been suppressed exceeds this limit, the route becomes unsuppressed If you specify the preceding set of dampening values, you can optionally specify a half-life-unreachable period to apply to unreachable routes. If you do not specify this value, the same half-life period is used for both reachable and unreachable routes. Dampening applies only to routes learned via EBGP. The new dampening parameters are applied in future flaps. Changing the dampening parameters does not affect the Figure of Merit that has been calculated for routes using the old dampening parameters. To reset the Figure-of-Merit for all routes, you must issue the clear ip bgp dampening command. Use the no version to disable route flap dampening.

clear ip bgp dampening

Use to clear route flap dampening information and unsuppress the suppressed routes. You can use the flap-statistics keyword as an alternative to the dampening keyword. Both achieve the same results. Examples To clear dampening information for all routes in all address families in all VRFs: host1#clear ip bgp dampening To clear dampening information for all routes in VRF dogwood: host1#clear ip bgp vrf dogwood dampening To clear dampening information for all non-VRF routes in the IPv4 unicast address family: host1#clear ip bgp ipv4 unicast dampening To clear dampening information for a specific route: host1#clear ip bgp dampening 192.168.5.0 255.255.255.0 To clear dampening information for the most specific route matching an address: host1#clear ip bgp dampening 192.168.5.0

This command takes effect immediately. There is no no version.

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
Use to unsuppress routes that have been suppressed by a set dampening clause in a route map. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member. Routes previously suppressed by a route map that are unsuppressed by this command are not automatically advertised; you must use the clear ip bgp command to perform a hard clear or outbound soft clear. Example host1(config-router)#neighbor berlin5 unsuppress-map inmap3 Use the no version to restore the default values.

set dampening
Use to enable BGP route flap dampening only on routes that pass the match clauses of, and are redistributed by, a particular route map. BGP creates a dampening parameter block for each unique set of dampening parameterssuch as suppress threshold and reuse thresholdused 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. Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set dampening 5 1000 1500 45 15 Use the no version to delete the set clause from a route map.

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 command test the outcome of a BGP policy. The command output displays the routes that would be advertised or accepted if the specified policy were implemented. BGP routes must be present in the forwarding table for this command to work properly. If you run the policy test on incoming routes, soft reconfiguration (via the neighbor soft reconfiguration in command) must be in effect.

Note: The output of the test ip bgp neighbor command is always speculative. It does not reflect the current state of the system.

test ip bgp neighbor

Use to test the effect of BGP policies on a router without implementing the policy. You can apply the test to routes advertised to peers or received from peers. You can test the following kinds of policies: distribute lists, filter lists, prefix lists, prefix trees, or route maps. If you do not specify a policy, then the test uses whatever policies are currently in effect on the system.

Note: If you test the current policies, the results might vary for routes learned before the current policies were activated if you did not clear the forwarding table when the policies changed.

The address-family identifier for the route is the same as is used for identifying the neighbor. If you do not specify a route, the test is performed for all routes associated with the address-family identifier. If you completely specify a route with IP address, mask, and route distinguisher, the command displays detailed route information. Otherwise only summary information is shown. Use the fields option to select particular fields of interest. Specifying only an address and mask without a route distinguisher causes all routes sharing the address and mask to be considered. Specifying only an address causes a best match to be performed for the route.

 If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. You can set a weight value for inbound routes filtered with a filter list. Example host1#test ip bgp neighbor 10.12.54.21 advertised-routes distribute-list boston5 fields all

[Contents] [Prev] [Next] [Index] [Report an Error]

Selecting the Best Path

BGP selects only one route to a destination as the best path. When multiple routes to a given destination exist, BGP must determine which of these routes is the best. BGP puts the best path in its routing table and advertises that path to its BGP neighbors. If only one route exists to a particular destination, BGP installs that route. If multiple routes exist for a destination, BGP uses tie-breaking rules to decide which one of the routes to install in the BGP routing table.

The BGP Path Decision Algorithm

BGP determines the best path to each destination for a BGP speaker by comparing path attributes according to the following selection sequence:

1. 1. 1.

Select a path with a reachable next hop. Select the path with the highest weight. If path weights are the same, select the path with the highest local preference value. 1. Prefer locally originated routes (network routes, redistributed routes, or aggregated routes) over received routes. 1. Select the route with the shortest AS-path length. 1. If all paths have the same AS-path length, select the path based on origin: IGP is preferred over EGP; EGP is preferred over Incomplete. 1. If the origins are the same, select the path with lowest MED value. 1. If the paths have the same MED values, select the path learned via EBGP over one learned via IBGP. 1. Select the route with the lowest IGP cost to the next hop. 6460. Select the route received from the peer with the lowest BGP router ID. The following sections discuss the attributes evaluated in the path decision process. Examples show how you might configure these attributes to influence routing decisions.

Configuring Next-Hop Processing

Routes sent by BGP speakers include the next-hop attribute. The next hop is the IP address of a node on the network that is closer to the advertised prefix. Systems that have traffic destined for the advertised

prefix send the traffic to the next hop. The next hop can be the address of the BGP speaker sending the update or of a third-party node. The third-party node does not have to be a BGP speaker. The next-hop attributes conform to the following rules: The next hop for EBGP sessions is the IP address of the peer that advertised the route. The next hop for IBGP sessions is one of the following: If the route originated inside the AS, the next hop is the IP address of the peer that advertised the route. If the route originated outside the ASthat is, it was injected into the AS via an EBGP sessionthe next hop is the IP address of the external BGP speaker that advertised the route. For routes advertised on multiaccess mediasuch as Frame Relay, ATM, or Ethernetthe next hop is the IP address of the originating router's interface that is connected to the medium.

Next Hops
If you use the neighbor remote-as command to configure the BGP neighbors, the next hop is passed according to the rules provided above when networks are advertised. Consider the network configuration shown inFigure 1-22. Router Jackson advertises 192.168.22.0/23 internally to router Memphis with a next hop of 10.2.2.1. Router Jackson advertises the same network externally to router Topeka with a next hop of 10.1.13.1.

Figure 1-22 Configuring next-hop processing Router Memphis advertises 172.24.160/19 with a next hop of 10.2.2.2 to router Jackson. Router Jackson advertises this same network externally to router Topeka with a next hop of 10.1.13.1. Router Topeka advertises network 192.168.32.0/19 with a next hop of 10.1.13.2 to router Jackson. Because this network originates outside AS 604, router Jackson then internally advertises this network (192.168.32.0/19) to router Memphis with the same next hop, 10.1.13.2 (the IP address of the external BGP speaker that advertised the route).

When router Memphis has traffic destined for 192.168.32.0/19, it must be able to reach the next hop via an IGP, because it has no direct connection to 10.1.13.2. Otherwise, router Memphis will drop packets destined for 192.168.32.0/19 because the next-hop address is not accessible. Router Memphis does a lookup in its IP routing table to determine how to reach 10.1.13.2: Destination Next Hop

10.1.13.0/24 10.2.2.1

The next hop is reachable via router Jackson, and the traffic can be forwarded. The following commands configure the routers as shown in Figure 1-22: To configure router Jackson: host1(config)#router bgp 604 host1(config-router)#neighbor 10.1.13.2 remote-as 25 host1(config-router)#neighbor 10.2.2.2 remote-as 604 host1(config-router)#network 192.168.22.0 mask 255.255.254.0 To configure router Memphis: host2(config)#router bgp 604 host2(config-router)#neighbor 10.2.2.1 remote-as 604 host2(config-router)#network 172.24.160.0 mask 255.255.224.0 To configure router Topeka: host3(config)#router bgp 25 host3(config-router)#neighbor 10.1.13.1 remote-as 604 host3(config-router)#network 172.31.64.0 mask 255.255.192.0 Additional configuration is required for routers Biloxi, Memphis, and Jackson; the details depend on the IGP running in AS 604.

neighbor remote-as
Use to add an entry to the BGP neighbor table. Specifying a neighbor with an AS number that matches the AS number specified in the router bgp command identifies the neighbor as internal to the local AS. Otherwise, the neighbor is considered external. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. This command takes effect immediately. Use the no version to remove an entry from the table.

Next-Hop-Self

In some circumstances, using a third-party next hop causes routing problems. These configurations typically involve nonbroadcast multiaccess (NBMA) media.To better understand this situation, first consider a broadcast multiaccess (BMA) media network, as shown in Figure 1-23.

Figure 1-23 Next-hop behavior for broadcast multiaccess media. Routers Toledo, Madrid, and Barcelona are all on the same Ethernet network, which has a prefix of 10.19.7.0/24. When router Toledo advertises prefix 192.168.22.0/23 to router Madrid, it sets the next-hop attribute to 10.19.7.5. Before router Madrid advertises this prefix to router Barcelona, it sees that its own IP address, 10.19.7.7, is on the same subnet as the next hop for the advertised prefix. If router Barcelona can reach router Madrid, then it should be able to reach router Toledo. Router Madrid therefore advertises 192.168.22.0/23 to router Barcelona with a next-hop attribute of 10.19.7.5. Now consider Figure 1-24, which shows the same routers on a Frame RelayNBMAnetwork.

Figure 1-24 Next-hop behavior for nonbroadcast multiaccess media. Routers Toledo and Madrid are EBGP peers, as are routers Madrid and Barcelona. When router Toledo advertises prefix 192.168.22.0/23 to router Madrid, router Madrid makes the same comparison as in the BMA example, and leaves the next-hop attribute intact when it advertises the prefix to router Barcelona. However, router Barcelona will not be able to forward traffic to 192.168.22.0/23, because it does not have a direct PVC connection to router Toledo and cannot reach the next hop of 10.19.7.5. You can use the neighbor next-hop-self command to correct this routing problem. If you use this command to configure router Madrid, the third-party next hop advertised by router Toledo is not advertised to router Barcelona. Instead, router Madrid advertises 192.168.22.0/23 with the next-hop attribute set to its own IP address, 10.19.7.7. Router Barcelona now forwards traffic destined for 192.168.22.0/23 to the next hop, 10.19.7.7. router Madrid then passes the traffic along to router Toledo. To disable third-party next-hop processing, configure router Madrid as follows:

host1(config)#router bgp 319 host1(config-router)#neighbor 10.19.7.8 remote-as 211 host1(config-router)#neighbor 10.19.7.8 next-hop-self

neighbor next-hop-self
Use to prevent third-party next hops from being used on NBMA media such as Frame Relay. This command is useful in nonmeshed networks such as Frame Relay or where BGP neighbors may not have direct access to the same IP subnet. Forces the BGP speaker to report itself as the next hop for an advertised route it learned from a neighbor. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group. New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to disable this feature (and therefore enable next-hop processing of BGP updates). Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.

Assigning a Weight to a Route

You can assign a weight to a route when more than one route exists to the same destination. A weight indicates a preference for that particular route over the other routes to that destination. The higher the assigned weight, the more preferred the route. By default, the route weight is 32768 for paths originated by the router, and 0 for other paths. In the configuration shown in Figure 1-25, routers Boston and NY both learn about network 192.68.5.0/24 from AS 200. Routers Boston and NY both propagate the route to router LA. Router LA now has two routes for reaching 192.68.5.0/24 and must decide the appropriate route. If you prefer that router LA direct traffic through router Boston, you can configure router LA so that the weight of routes coming from router Boston are highermore preferredthan the routes coming from router NY. Router LA subsequently prefers routes received from router Boston and therefore uses router Boston as the next hop to reach network 192.68.5.0/24.

Figure 1-25 Assigning a weight to a neighbor connection You can use any of the following three ways to set the weights in routes coming in from router Boston: The neighbor weight command The set weight command in route maps An AS-path access list

Using the neighbor weight Command

The following commands assign a weight of 1000 to all routes router LA receives from AS 100 and assign a weight of 500 to all routes router LA receives from AS 300: host1(config)#router bgp 400 host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor

10.5.5.1 remote-as 100 10.5.5.1 weight 1000 10.72.4.2 remote-as 300 10.72.4.2 weight 500

Router LA sends traffic through router Boston in preference to router NY.

Using a Route Map

A route map instance is a set of conditions with an assigned number. The number after the permit keyword designates an instance of a route map. For example, instance 10 of route map 10 begins with the following: host1(config)#route-map 10 permit 10 In the following commands to configure router LA, instance 10 of route map 10 assigns a weight of 1000 to any routes from AS 100. Instance 20 assigns a weight of 500 to routes from any other AS. host1(config)#router bgp 400 host1(config-router)#neighbor 10.5.5.1 remote-as 100

host1(config-router)#neighbor 10.5.5.1 route-map 10 in host1(config-router)#neighbor 10.72.4.2 remote-as 300 host1(config-router)#neighbor 10.72.4.2 route-map 20 in host1(config-router)#exit host1(config)#route-map 10 host1(config-route-map)#set weight 1000 host1(config-route-map)#route-map 20 host1(config-route-map)#set weight 500 See ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 1, Configuring Routing Policy for more information on using route maps.

Using an AS-Path Access List

The following commands assign weights to routes filtered by AS-path access lists on router LA: host1(config)#router bgp 400 host1(config-router)#neighbor 10.5.5.1 remote-as 100 host1(config-router)#neighbor 10.5.5.1 filter-list 1 weight 1000 host1(config-router)#neighbor 10.72.4.2 remote-as 300 host1(config-router)#neighbor 10.72.4.2 filter-list 2 weight 500 host1(config-router)#exit host1(config)#ip as-path access-list 1 permit ^100_ host1(config)#ip as-path access-list 2 permit ^300_ Access list 1 permits any route whose AS-path attribute begins with 100 (specified by ^). This permits routes that pass through router Boston, whether they originate in AS 100 (AS path = 100) or AS 200 (AS path = 100 200) or AS 300 (AS path = 100 200 300). Access list 2 permits any route whose AS-path attribute begins with 300. This permits routes that pass through router NY, whether they originate in AS 300 (AS path = 300) or AS 200 (AS path = 300 200) or AS 100 (AS path = 300 200 100). The neighbor filter-list commands assign a weight attribute of 1000 to routes passing through router Boston and a weight attribute of 500 to routes passing through router NY. Regardless of the origin of the route, routes learned through router Boston are preferred.

ip as-path access-list
Use to define a BGP access list; use the neighbor filter-list command to apply a specific access list. You can apply access list filters on inbound or outbound BGP routes, or both. You can permit or deny access for a route matching the condition(s) specified by the regular expression. If the regular expression matches the representation of the AS path of the route as an ASCII string, then the permit or deny condition applies. The AS path allows substring matching. For example, the regular expression 20 matches AS path = 20 and AS path = 100 200 300, because 20 is a substring of each path. To disable substring matching and constrain matching to only the specified attribute string, place the underscore (_) metacharacter on both sides of the string, for example _20_. The AS path does not contain the local AS number.

 Use the no version to remove a single access list entry if permit or deny and a path-expression are specified. Otherwise, the entire access list is removed.

neighbor filter-list
Applies an AS-path access list to advertisements inbound from or outbound to the specified neighbor, or assigns a weight to incoming routes that match the AS-path access list. You can specify an optional weight value with the weight keyword to assign a relative importance to incoming routes matching the AS-path access list. The name of the access list is a string of up to 32 characters. You can apply the filter to incoming or outgoing advertisements with the in or out keywords. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to remove the filter list.

neighbor weight
Use to assign a weight to a neighbor connection. All routes learned from this neighbor will have the assigned weight initially. The route with the highest weight will be chosen as the preferred route when multiple routes are available to a particular network. The weights assigned with the set weight commands in a route map override the weights assigned with the neighbor weight and neighbor filter-list commands. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.

Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to remove the weight assignment.

See Access Lists (p 1-62) for more information on using access lists.

Configuring the Local-Pref Attribute

The local-pref attribute specifies the preferred path among multiple paths to the same destination. The preferred path is the one with the higher preference value. Local preference is used only within an AS, to select an exit point. To configure the local preference of a BGP path, you can do one of the following: Use the bgp default local-preference command to set the local-preference attribute. Use a route map to set the local-pref attribute.

Using the bgp default local-preference Command

In Figure 1-26, AS 873 receives updates for network 192.168.5.0/24 from AS 32 and AS 17.

Figure 1-26 Configuring the local-preference attribute The following commands configure router LA: host1(config-router)#router bgp 873

host1(config-router)#neighbor 10.72.4.2 remote-as 32 host1(config-router)#neighbor 10.2.2.4 remote-as 873 host1(config-router)#bgp default local-preference 125 The following commands configure router SanJose: host2(config-router)#router bgp 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#bgp default local-preference 200 Router LA sets the local preference for all updates from AS 32 to 125. Router SanJose sets the local preference for all updates from AS 17 to 200. Because router LA and router SanJose exchange local preference information within AS 873, they both recognize that routes to network 192.168.5.0/24 in AS 293 have a higher local preference when they come to AS 873 from AS 17 than when they come from AS 32. As a result, both router LA and router SanJose prefer to reach this network via router Boston in AS 17.

bgp default local-preference

Use to change the default local preference value. Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix. To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session. Use the no version to restore the default value, 100.

Using a Route Map to Set the Local Preference

When you use a route map to set the local preference you have more flexibility in selecting routes for which you can set a local preference based on many criteria, including AS. In the previous section, all updates received by router SanJose were set to a local preference of 200. Using a route map, you can specifically assign a local preference for routes from AS 17 that pass through AS 293. The following commands configure router SanJose. host2(config-router)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#neighbor 10.5.5.1 route-map 10 in host2(config-router)#exit host2(config)#ip as-path access-list 1 permit ^17 293$ host2(config)#route-map 10 permit 10 host2(config-route-map)#match as-path 1 host2(config-route-map)#set local-preference 200 host2(config-route-map)#exit

host2(config)#route-map 10 permit 20 Router SanJose sets the local-pref attributes to 200 for routes originating in AS 293 and passing last through AS 17. All other routes are accepted (as defined in instance 20 of the route map 10), but their local preference remains at the default value of 100, indicating a less-preferred path.

Understanding the Origin Attribute

BGP uses the origin attribute to describe how a route was learned at the originthe point where the route was injected into BGP. The origin of the route can be one of three values: IGP - indicates that the route was learned via an IGP and, therefore, is internal to the originating AS. All routes advertised via the network command have an origin of IGP. EGP - indicates that the route was learned via an EGP. Incomplete - indicates that the origin of the route is unknownthat is, learned from something other than IGP or EGP. All routes advertised via the redistribute commandsuch as static routeshave an origin of Incomplete. An origin of Incomplete occurs when a route is redistributed into BGP.

Figure 1-27 The origin attribute Consider the sample topology shown in Figure 1-27. Because routers Albany and Boston are not directly connected, they learn the path to each other via an IGP (not illustrated). The following commands configure router Boston: host1(config)#ip route 172.31.125.100 255.255.255.252 host1(config)#router bgp 100 host1(config-router)#neighbor 10.2.25.1 remote-as 100 host1(config-router)#neighbor 10.4.4.1 remote-as 100 host1(config-router)#neighbor 10.3.3.1 remote-as 300 host1(config-router)#network 172.19.0.0 host1(config-router)#redistribute static

The following commands configure router NY: host2(config)#router bgp 100 host2(config-router)#neighbor 10.4.4.1 remote-as 100 host2(config-router)#neighbor 10.2.25.2 remote-as 100 host2(config-router)#network 172.28.8.0 mask 255.255.248.0 The following commands configure router Albany: host3(config)#router bgp 100 host3(config-router)#neighbor 10.4.4.2 remote-as 100 host3(config-router)#neighbor 10.2.25.2 remote-as 100 host3(config-router)#network 192.168.33.0 mask 255.255.255.0 The following commands configure router LA: host4(config)#router bgp 300 host4(config-router)#neighbor 10.3.3.2 remote-as 100 host4(config-router)#network 192.168.204.0 mask 255.255.252.0 host4(config-router)#redistribute isis Consider how route 172.21.10.0/23 is passed along to the routers in Figure 1-27: 1. IS-IS injects route 172.21.10.0/23 from router Chicago into BGP on router LA. BGP sets the origin attribute to Incomplete (because it is a redistributed route) to indicate how BGP originally became aware of the route. 1. Router Boston learns about route 172.21.10.0/23 via EBGP from router LA. 1. Router NY learns about route 172.21.10.0/23 via IBGP from router Boston. The value of the origin attribute for a given route remains the same, regardless of where you examine it. Table 1-14 shows this for all the routes known to routers NY and LA.

Table 1-14 Origin and AS-path for routes viewed on different routers
Route Router Origin IGP IGP IGP IGP AS Path 300 300 300 empty 192.168.204.0/22 Albany 192.168.204.0/22 Boston 192.168.204.0/22 NY 192.168.204.0/22 LA 172.21.10.0/23 172.21.10.0/23 172.21.10.0/23 172.21.10.0/23 Albany Boston NY LA

Incomplete 300 Incomplete 300 Incomplete 300 Incomplete empty

172.28.8.0/21 172.28.8.0/21 172.28.8.0/21 172.28.8.0/21 172.31.125.100 172.31.125.100 172.31.125.100 172.31.125.100 172.19.0.0/16 172.19.0.0/16 172.19.0.0/16 172.19.0.0/16 192.168.330/24 192.168.330/24 192.168.330/24 192.168.330/24

Albany Boston NY LA Albany Boston NY LA Albany Boston NY LA Albany Boston NY LA

IGP IGP IGP IGP

empty empty empty 100

Incomplete empty Incomplete empty Incomplete empty Incomplete 100 IGP IGP IGP IGP IGP IGP IGP IGP empty empty empty 100 empty empty empty 100

As a matter of routing policy, you can specify an origin for a route with a set origin clause in a redistribution route map. Changing the origin enables you to influence which of several routes for the same destination prefix is selected as the best route. In practice, changing the origin is rarely done.

Understanding the AS-path Attribute

The AS-path attribute is a list of the ASs through which a route has passed. Whenever a route enters an AS, BGP prepends the AS number to the AS-path attribute. This feature enables network operators to track routes, but it also enables the detection and prevention of routing loops. Consider the following sequence of events for the systems shown in Figure 1-28: 1. Route 172.21.10.0/23 is injected into BGP via router London in AS 47. 1. Suppose router London advertises that route to router Paris in AS 621. As received by router Paris, the AS-path attribute for route 172.21.10.0/23 is 47. 1. Router Paris advertises the route to router Berlin in AS 11. As received by router Berlin, the AS-path attribute for route 172.21.10.0/23 is 621 47. 1. Router Berlin advertises the route to router London in AS 47. As received by router London, the AS-path attribute for route 172.21.10.0/23 is 11 621 47.

Figure 1-28 AS-path attributes A routing loop would exist if router London accepts the route from router Berlin. Router London can choose not to accept the route from router Berlin because it recognizes from the AS-path attribute (11 621 47) that the route originated in its own AS 47. As a matter of routing policy, you can prepend additional AS numbers to the AS-path attribute for a route with a set as-path prepend clause in an outbound route map. Changing the AS path enables you to influence which of several routes for the same destination prefix is selected as the best route.

Configuring a Local AS
You can change the local AS of a BGP peer or peer group within the current address family with the neighbor local-as command. By using different local AS numbers for different peers, you can avoid or postpone AS renumbering in the event the ASs are merged.

neighbor local-as
Use to assign a local AS to the given BGP peer or peer group. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. This command takes effect immediately and automatically bounces the BGP session. Use the no version for an individual peer to restore the value set for the peer group, if present, or set globally for BGP with the router bgp command. Use the no version for a peer group to restore the value set globally for BGP. The following example commands change the local AS number for peer 104.4.2 from the global local AS of 100 to 32: host1(config)#router bgp 100 host1(config-router)#address-family ipv4 unicast vrf boston host1(config-router)#neighbor 10.4.4.2 remote-as 645 host1(config-router)#neighbor 10.4.4.2 local-as 32

Configuring the MED Attribute

If two ASs connect to each other in more than one place, one link or path might be a better choice to reach a particular prefix within or behind one of the ASs. The MED value is a metric expressing a degree of preference for a particular path. Lower MED values are preferred. Whereas the Local Preference attribute is used only within an AS (to select an exit point), the MED attribute is exchanged between ASs. A router in one AS sends the MED to tell a router in another AS which path the second router should use to reach particular destinations. If you are the administrator of the second AS, you must therefore trust that the router in the first AS is providing information that is truly beneficial to your AS. You configure the MED on the sending router by using the set metric command in an outbound route map. Unless configured otherwise, a receiving router compares MED attributes only for paths from external neighbors that are members of the same AS. If you want MED attributes from neighbors in different ASs to be compared, you must issue the bgp always-compare-med command. In Figure 1-29, router London in AS 303 can reach 192.168.33.0/24 in AS 73 through router Paris or through router Nice to router Paris.

Figure 1-29 Configuring the MED The following commands configure router London: host1(config)#router bgp 303 host1(config-router)#neighbor 10.4.4.2 remote-as 73 host1(config-router)#neighbor 10.3.3.2 remote-as 73 host1(config-router)#neighbor 10.5.5.2 remote-as 4 host1(config-router)#network 122.28.8.0 mask 255.255.248.0 The following commands configure router Paris: host2(config)#router bgp 73 host2(config-router)#neighbor 10.4.4.1 remote-as 303 host2(config-router)#neighbor 10.4.4.1 route-map 10 out host2(config-router)#neighbor 10.2.25.1 remote-as 73

host2(config-router)#neighbor 10.6.6.1 remote-as 4 host2(config-router)#neighbor 10.6.6.1 route-map 10 out host2(config-router)#network 192.168.33.0 mask 255.255.255.0 host2(config-router)#exit host2(config)#route-map 10 permit 10 host2(config-route-map)#set metric 50 The following commands configure router Nice: host3(config)#router bgp 73 host3(config-router)#neighbor 10.3.3.1 remote-as 303 host3(config-router)#neighbor 10.3.3.1 route-map 10 out host3(config-router)#neighbor 10.2.25.2 remote-as 73 host3(config-router)#network 172.19.0.0 host3(config-router)#exit host3(config)#route-map 10 permit 10 host3(config-route-map)#set metric 100 The following commands configure router Dublin: host4(config)#router bgp 4 host4(config-router)#neighbor 10.5.5.1 remote-as 303 host4(config-router)#neighbor 10.5.5.1 route-map 10 out host4(config-router)#neighbor 10.6.6.2 remote-as 73 host4(config-router)#network 172.14.27.0 mask 255.255.255.0 host4(config-router)#exit host4(config)#route-map 10 permit 10 host4(config-route-map)#set metric 25 Router London receives updates regarding route 192.168.33.0/24 from both router Nice and router Paris. Router London compares the MED values received from the two routers: Router Nice advertises a MED of 100 for the route, whereas router Paris advertises a MED of 50. On this basis, router London prefers the path through router Paris. Because BGP by default compares only MED attributes of routes coming from the same AS, router London can compare only the MED attributes for route 192.168.33.0/24 that it received from routers Paris and Nice. It cannot compare the MED received from router Dublin, because router Dublin is in a different AS than routers Paris and Nice. However, you can use the bgp always-compare-med command to configure router London to consider the MED attribute from router Dublin as follows: host1(config)#router bgp 303 host1(config-router)#neighbor 10.4.4.2 remote-as 73 host1(config-router)#neighbor 10.3.3.2 remote-as 73 host1(config-router)#neighbor 10.5.5.2 remote-as 4 host1(config-router)#network 122.28.8.0 mask 255.255.248.0 host1(config-router)#bgp always-compare-med Router Dublin advertises a MED of 25 for route 192.168.33.0/24, which is lowermore preferredthan the MED advertised by router Paris or router Nice. However, the AS path for the route through router Dublin is longer than that through router Paris. The AS path is the same length for router Paris and router

Nice, but the MED advertised by router Paris is lower than that advertised by router Nice. Consequently, router London prefers the path through router Paris. Suppose, however that router Dublin was not configured to set the MED for route 192.168.33.0/24 in its outbound route map 10. Would router London receive a MED of 50 passed along by router Paris through router Dublin? No, because the MED attribute is nontransitive. Router Dublin does not transmit any MED that it receives. A MED is only of value to a direct peer.

bgp always-compare-med
Use to enable the comparison of the MED for paths from neighbors in different ASs. Unless you specify the bgp always-compare-med command, the router compares MED attributes only for paths from external neighbors that are in the same AS. The BGP path decision algorithm selects a lower MED value over a higher one. Unlike local preferences, the MED attribute is exchanged between ASs, but does not leave the AS. The value is used for decision making within the AS only. When BGP propagates a route received from outside the AS to another AS, it removes the MED. Example host1(config-router)#bgp always-compare-med Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix. To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session. Use the no version to disable the feature.

set metric
Use to set the metric valuefor BGP, the MEDfor a route. Sets an absolute metric. You cannot use both an absolute metric and a relative metric within the same route map sequence. Setting either metric overrides any previously configured value. Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric 10 Use the no version to delete the set clause from a route map.

Missing MED Values

By default, a route that arrives with no MED value is treated as if it had a MED of 0, the most preferred value. You can use the bgp bestpath missing-as-worst command to specify that a route with any MED value is always preferred to a route that is missing the MED value.

bgp bestpath missing-as-worst

Use to set a missing MED value to infinity, the least preferred value. After issuing this command, a route missing the MED is always preferred less than any route that has a MED configured. Example host1(config-router)#bgp bestpath missing-as-worst Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix. To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session. Use the no version to restore the default condition, where a missing MED value is set to 0, the most preferred value.

Comparing MED Values Within a Confederation

A BGP speaker within a confederation of sub-ASs might need to compare routes to determine the best path to a destination. By default, BGP does not use the MED value when comparing routes originated in different sub-ASs within the confederation to which the BGP speaker belongs. (Within the confederation, routes learned from different sub-ASs are considered to have originated in different places.) You can use the bgp bestpath med confed command to force the consideration of MED values within a confederation.

bgp bestpath med confed

Use to specify that BGP consider the MED when comparing routes originated in different sub-ASs within the confederation to which the BGP speaker belongs. This command does not affect the comparison of routes that are originated in other ASs and does not affect the comparison of routes that are originated in other confederations. Example host1(config-router)#bgp bestpath med confed Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix. To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session.

Use to the no version to restore the default, where the MED is not considered.

Example
Suppose a BGP speaker has three routes to prefix 10.10.0.0/16: Route 1 is originated by sub-AS 1 inside the confederation. Route 2 is originated by sub-AS 2 inside the confederation. Route 3 is originated by AS 3 outside the confederation.

BGP compares these routes to each other to determine the best path to the prefix. If you have issued the bgp bestpath med confed command, BGP considers the MED when comparing Route 1 with Route 2. However, BGP does not consider the MED when comparing Route 3 with either Route 1 or Route 2, because Route 3 originates outside the confederation.

Capability Negotiation
The system accepts connections from peers that perform capability negotiation. Capabilities are negotiated using the open messages that are exchanged when the session is established. The system supports the following capabilities: Cisco-proprietary route refresh - capability code 128 Cooperative route filtering- capability code 3 Dynamic capability renegotiation - capability code 66 Four-octet AS numbers - capability code 65 Multiprotocol extensions - capability code 1 address family IPv4 unicast - AFI 1 SAFI 1 address family IPv4 multicast - AFI 1 SAFI 2 address family IPv4 unicast and multicast - AFI 1 SAFI 3 address family VPN-IPv4 unicast - AFI 1 SAFI 128 Route refresh - capability code 2

The system advertises these capabilitiesexcept for the cooperative route filtering capabilityby default. You can prevent the advertisement of specific capabilities with the no neighbor capability command. You can also use this command to prevent all capability negotiation with the specified peer.

Cooperative Route Filtering

The cooperative route filtering capabilityalso referred to as outbound route filtering (ORF)enables a BGP speaker to send an inbound route filter to a peer and have the peer install it as an outbound filter on the remote end of the session. You must specify both the type of inbound filter (ORF type) and the direction of ORF capability. The system currently supports prefix-lists as the inbound filter sent by the BGP speaker. The inbound filter sent by the BGP speaker can be a prefix list or a Cisco proprietary prefix list.The BGP speaker must indicate whether it will send inbound filters to peers, accept inbound filters from peers, or both. The system supports both standard and Cisco-proprietary orf messages.

Dynamic Capability Negotiation

If both peers acknowledge support of dynamic capability negotiation, then at any subsequent point after the session is established, either peer can send a capabilities message to the other indicating a desire to negotiate another capability or to remove a previously negotiated capability.

Four-Octet AS Numbers
BGP speakers that support four-octet AS and sub-AS numbers are sometimes referred to as "new" speakers. The four-octet AS numbers are employed by the AS-path and aggregator attributes. "Old" speakers are those that do not support the four-octet numbers. Two new transitional optional attributes, new-as-path and new-aggregator, are used to carry the four-octet numbers across the old speakers. A new speaker communicating with an old speaker will send the new attributes with the four-octet numbers for locally-originated and propagated routes. The old speaker propagates the new attributes for received routes. The new speaker also sends the AS-path and aggregator attributes with two-octet numbers; any AS number greater than 65535 is replaced with a reserved AS number, 23456.

Route Refresh
If the system detects that a peer supports both Cisco-proprietary and standard route refresh messages, it will prefer to use the standard route refresh messages.

neighbor capability
Use to control the advertisement of BGP capabilities to peers. Capability negotiation and advertisement of all capabilities is enabled by default. You can specify the dynamic-capability-negotiation, four-octet-asnumbers, orf, route-refresh, and route-refresh-cisco capabilities. The graceful restart capability is controlled by specific graceful-restart commands. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. You cannot configure the receive direction for the orf capability for a peer that is a member of a peer group or for a peer. Example host1(config-router)#neighbor 10.6.2.5 capability orf prefix-list both If you issue the route-refresh or route-refresh-cisco keywords, takes effect immediately. If dynamic capability negotiation was negotiated for the session, a capability message is sent to inform the peer of the new capability configuration. If dynamic capability negotiation was not negotiated for the session, the session is bounced automatically. If you issue the dynamic-capability-negotiation, four-octet-as-numbers, or negotiation keywords, takes effect immediately and bounces the session. If you issue the orf keyword, takes effect immediately and automatically bounces the BGP session. Use the no version to prevent advertisement of the specified capability or use the negotiation keyword with the no version to prevent all capability negotiation with the specified peer.

[Contents] [Prev] [Next] [Index] [Report an Error]

Interactions Between BGP and IGPs

Interactions between BGP and an internal gateway protocol are more likely to occur in an enterprise system than in a service provider system. You can also encounter interactions when configuring small test systems. The main interaction factors are the following: Synchronization between BGP and IGPs Administrative distances for routes learned from various sources

Synchronizing BGP with IGPs

In Figure 1-30, AS 100 provides transit service but does not run BGP on all of the routers in the AS. In this situation, you must redistribute BGP into the IGP so that the non-BGP routersfor example, router Albanylearn how to forward traffic to customer prefixes. If BGP converges faster than the IGP, a prefix might be advertised to other ASs before that prefix can be forwarded. For example, suppose router LA advertises a route to router Boston using EBGP, and router Boston propagates that route to router NY using IBGP. If router NY propagates the route to router Chicago before the IGP within AS 100 has convergedthat is, before router Albany learns the routethen router Chicago might start sending traffic for that route before router Albany can forward that traffic.

Figure 1-30 Synchronization Synchronization solves this problem by preventing a BGP speaker from advertising a route over an EBGP session until all routers within the speaker's AS have learned about the route. If the AS contains routers connected via an IGP, the BGP speaker cannot propagate a BGP route that it learned from a peer until an IGP route to the prefix has been installed in the BGP speaker's IP routing table. The BGP speaker advertises the BGP route externally even if the IGP route is better than the BGP route. In contrast, if

synchronization is disabled, a BGP speaker propagates a BGP route learned from a peer only if it is the best route to the prefix in the IP routing table. Synchronization is enabled by default. However, you must configure redistribution of external routes into the IGP, or the routing tables will not receive the IGP routes.

Note: When you create an address family for a VRF, synchronization is automatically disabled for that address family.

If synchronization is enabled and if redistribution is configured for the networks in Figure 1-30, router NY checks its IGP routing table for a route to 192.56.0.0/16 when it learns about the prefix from the IBGP session with router Boston. If the route is not present, the prefix is not reachable through router Albany, so router NY does not advertise it as available. Router NY keeps checking its IGP routing table; if the route appears, router NY knows that it can pass traffic to the prefix and advertises the route via EBGP to router Chicago. In practice, service providers rarely redistribute BGP into an IGP because existing IGPs cannot handle the full Internet routing table (about 100,00 routes). Instead, all routers in an AS typically run BGP; in these cases it is advisable to turn synchronization off everywhere.

Disabling Synchronization
Because the routes learned via EBGP are extensive, redistributing those routes into your IGP consumes processor and memory resources. You can disable synchronization if your AS does not pass traffic from one AS to another or if all the transit routers in your AS run BGP. Figure 1-31 shows the same configuration as in the previous example, except that all the routers in AS 100 now run IBGP. As a result, all the routers receive updates learned by the area border routers from external BGP speakers. If synchronization is disabled, a BGP speaker propagates a BGP route learned from a peer only if it is the best route to the prefix in the IP routing table. However, the speaker does advertise the routes that it originates.

Figure 1-31 Disabling synchronization The following commands show how to configure routers Boston, NY, and Chicago (shown in Figure 1-31) with synchronization disabled for routers NY and Boston. The no synchronization command enables router NY to put the route to 192.56.0.0/16 in its IP routing table and advertise it to router Chicago without learning about 192.56.00/16 via router Albany. The command also enables router Boston to put the route to 192.30.0.0/16 in its IP routing table and advertise it to router Chicago without learning about 192.30.00/16 via router Albany. To configure router Boston: host1((config)#router bgp 100 host1(config-router)#neighbor 2.2.2.2 remote-as 100 host1(config-router)#neighbor 4.4.4.1 remote-as 100 host1(config-router)#neighbor 1.1.1.2 remote-as 300 host1(config-router)#no synchronization To configure router NY: host2(config)#router bgp 100 host2(config-router)#neighbor 3.3.3.2 remote-as 200 host2(config-router)#neighbor 2.2.2.1 remote-as 100 host2(config-router)#neighbor 4.4.4.3 remote-as 100 host2(config-router)#no synchronization To configure router Albany: host3(config)#router bgp 100 host3(config-router)#neighbor 4.4.4.4 remote-as 100 host3(config-router)#neighbor 4.4.4.2 remote-as 100 host3(config-router)#no synchronization To configure router Chicago: host4(config)#router bgp 200 host4(config-router)#neighbor 3.3.3.1 remote-as 100 To configure router LA: host5(config)#router bgp 300 host5(config-router)#neighbor 1.1.1.1 remote-as 100 host5(config-router)#network 192.56.0.0

synchronization
Use to enable and disable synchronization between BGP and an IGP. Synchronization is enabled by default. However, creating an address family for a VRF automatically disables synchronization for that address family. This command takes effect immediately.

 Use the no version to advertise a route without waiting for the IGP to learn a route to the prefix.

Setting the Administrative Distance for a Route

The administrative distance is an integer ranging from 0-255 that is associated with each route known to a router. The distance represents how reliable the source of the route is considered to be. A lower value is preferred over a higher value. An administrative distance of 255 indicates no confidence in the source; routes with this distance are not installed in the routing table. As shown in Table 1-15, default distances are provided for each type of source from which a route can be learned.

Table 1-15 Default administrative distances for route sources

Route Source Default Distance Connected interface 0 Static route External BGP OSPF IS-IS RIP Internal BGP Unknown 1 20 110 115 120 200 255

If the IP routing table contains several routes to the same prefixfor example, an OSPF route and an IBGP routethe route with the lowest administrative distance is used for forwarding. By default, BGP propagates received BGP routes to EBGP routes only if the BGP route is used for forwarding trafficthat is, if it is the route with the lowest administrative distance in the IP forwarding table. However, you can modify this behavior by using the bgp advertise-inactive command. See Advertising Inactive Routes (p 1-49) for more information. You can use the distance bgp command to configure the administrative distance associated with routes. If you choose to set an administrative distance, you must specify a value for all three of the following types of routes: external - administrative distance for BGP external routes. External routes are routes for which the best path is learned from a BGP peer external to the AS. Acceptable values are from 1 to 255. The default value is 20. internal - administrative distance for BGP internal routes. Internal routes are those routes that are learned from a BGP peer within the same AS. Acceptable values are from 1 to 255. The default value is 200. local - administrative distance for BGP local routes. Local routes are those routes locally originated by BGP. BGP can locally originate routes if you issue

the network command, if you configure redistribution into BGP, or via a non-AS-set aggregate route. Acceptable values are from 1 to 255. The default value is 200.

Caution: Changing the administrative distance of BGP internal routes is considered dangerous and is not recommended. One problem that can arise is the accumulation of routing table inconsistencies, which can break routing.

You can use the distance bgp command to configure these preferences. The following commands leave the internal distance at 200, set the external distance to 150, and set the local distance to 80: host1(config)#router bgp 100 host1(config-router)#network 172.28.0.0 host1(config-router)#neighbor 156.128.5.5 remote-as 310 host1(config-router)#neighbor 142.132.1.1 remote-as 50 host1(config-router)#distance bgp 150 200 80

distance bgp
Use to set the administrative distance for all BGP routes. You must specify the following: external-distance - administrative distance for routes external to the AS in the range 1-255. The default is 20. internal-distance - administrative distance for routes internal to the AS in the range 1-255. The default is 200. local-distance - administrative distance for local routes in the range 1-255. The default is 200. The default value is 20 for external routes, 200 for internal route, and 200 for local routes. The new distance is applied to all routes that are subsequently placed in the IP routing table. To apply the new distance to routes that are already present in the IP routing table, you must use the clear ip routes * command to reinstall BGP routes in the IP routing table. Use the no version to return the distances to their default values, 20, 200, and 200.

Example 1
Routes learned from other sources can be preferred to routes learned via BGP. Consider the network structure shown in Figure 1-32.

Figure 1-32 Administrative distances Suppose router KC originates 172.17.24.0/21 and advertises the route to router Chicago via EBGP. Both router KC and router Chicago are directly connected to the network represented by 172.17.24.0/21. If you issue the show ip route command on router Chicago, the BGP route does not appear. Instead, only the connected route is displayed. Both routes are in the IP routing table, but the show ip route command displays only the best route. (Use the show ip route all command to display all best routes; in this case the BGP route and the connected route.) Connected routes have a default distance of 0. Routes learned via EBGP have a default value of 20. The connected route is a better route than the EBGP route and appears in the command display. In practice, if two BGP peers are connected to the same network, both peers should originate the route.

Example 2
Consider the network structure shown in Figure 1-33. Router Chicago originates prefix 192.168.11.0/24 and advertises it via EBGP to router Albany. Router Albany advertises the route to router Boston via IBGP.

Figure 1-33 Administrative distance and synchronization

Router Albany also redistributes the route into the internal gateway protocol, RIP, which informs router NY of the route. Router NY propagates the route to router Boston via RIP, from which it is injected into BGP. In this example, both router Albany and router Boston have synchronization turned on. When synchronization is on, BGP propagates a received route to EBGP peers, even if the IP forwarding table contains a non-BGP route with a better administrative distance than the BGP route. This example demonstrates why synchronization is needed. Router Boston does not advertise the route externally to router Philly. At first, this is because router Boston has not yet heard about the prefix from router NY, and therefore the IGP route does not appear in router Boston's IP routing table. BGP routes are not propagated until a route to the prefix via any IGP appears in the IP routing table. In other words, routers connected via an IGP must have a route to the prefix before a BGP speaker can advertise the route it learned from a peer. When the RIP route appears on router Boston, the router has both an IBGP route and a RIP route to the same prefix. Even though the RIP route has a better administrative distance, the IBGP route is propagated to router Philly because synchronization is turned on.

Configuring Backdoor Routes

In certain network topologies, a BGP speaker might learn routes to the same prefix from an external BGP peer and via an IGP protocol. Consider the network structure shown in Figure 1-34. A company has established an OSPF link between routers NY and Boston. This private link between the two routers is known as a backdoor link. Router NY learns two routes to prefix 172.19.0.0/16; one via OSPF from router Boston, and one via EBGP from router LA through router SanDiego. As was shown in Table 1-15, EBGP routes have an administrative distance of 20 and are preferred over IGP routes, which have much higher administrative distances. In this example, the longer path via EBGP is preferred over the OSPF backdoor path with its distance of 110.

Figure 1-34 Backdoor route You can modify this behavior by issuing the network backdoor command on router NY: host1(config)#router bgp 300

host1(config-router)#neighbor 10.4.4.1 remote-as 400 host1(config-router)#network 172.19.0.0 backdoor Unlike the typical network command, network backdoor does not cause the BGP speaker to advertise the specified prefix. Instead, it sets the administrative distance for the EBGP path to that prefix to the same value as a route learned via IBGP. That is, the EBGP administrative distance is changed from the highly preferred value of 20 to the highly unpreferred value of 200. In Figure 1-34, this change in value results in the backdoor OSPF being more preferred as a way to reach prefix 172.19.0.0/16.

network backdoor
Use to cause a backdoor IGP route to be preferred over an EBGP route to the same prefix by setting the administrative distance of the EBGP route to that of an IBGP route, 200. Issuing this command does not cause the BGP speaker to advertise the specified route. Example host1(config-router)#network 10.53.42.0 backdoor This command takes effect immediately. Use the no version to restore the default distance to the EBGP route, 20.

Setting the Maximum Number of Equal-Cost Multipaths

You can use the maximum-paths command to specify the number of equal-cost paths to the same destination that BGP can submit to the IP routing table. If you set the value to 1, the system installs the single best route in the IP routing table. If you set the value greater than 1, the system installs that number of parallel routes.

maximum-paths
Use to set the maximum number of equal cost multipaths. Specify a value in the range 1-6; the default value is 1. The maximum number applies only to routes learned from external peers unless you use the ibgp keyword, in which case the maximum number applies only to routes received from internal peers. This command takes effect immediately; it does not bounce the session. You can specify the maximum number of equal-cost multipaths in the context of the virtual router, an IPv4 unicast address family, or a VRF specified in the context of an IPv4 unicast address family. This command does not support VPNv4 address families. Example 1 host1(config-router)#maximum-paths 3 Example 2

host1:vr1(config-router-af)#maximum-paths ibgp 5

Use the no version to restore the default value, 1.

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring BGP Peer Groups

You will often want to apply the same policies to most or all of the peers of a particular BGP speaker. Update policies are usually defined by route maps, filter lists, and distribution lists. You can reduce the configuration effort by defining a peer group made up of these peers. A peer group is defined relative to a particular BGP speaker. Figure 1-35 shows two peer groups, eastcoast and leftcoast. Each of these peer groups is defined for router Chicago, the hub router. Routers Boston, NY, and Miami have no knowledge of being members of Router Chicago's eastcoast peer group. Similarly, routers SanFran, LA, and SanDiego have no knowledge of being members of router Chicago's leftcoast peer group. The following commands configure the eastcoast peer group on router Chicago: host1(config)#router bgp 23 host1(config)#route-map wtset permit 10 host1(config-route-map)#set weight 25 host1(config-route-map)#exit host1(config-router)#neighbor eastcoast peer-group host1(config-router)#neighbor eastcoast route-map wtset in host1(config-router)#neighbor 10.6.6.2 remote-as 12 host1(config-router)#neighbor 10.6.6.2 peer-group eastcoast host1(config-router)#neighbor 10.7.3.2 remote-as 12 host1(config-router)#neighbor 10.7.3.2 peer-group eastcoast host1(config-router)#neighbor 10.4.4.2 remote-as 12 host1(config-router)#neighbor 10.4.4.2 peer-group eastcoast The following commands configure the leftcoast peer group on router Chicago: host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor leftcoast peer-group 10.3.3.2 remote-as 78 10.3.3.2 peer-group leftcoast 10.3.2.2 remote-as 2143 10.3.2.2 peer-group leftcoast 10.3.1.2 remote-as 136 10.3.1.2 peer-group leftcoast

Figure 1-35 BGP peer groups

neighbor peer-group
Two versions of this command exist. Use to create a BGP peer group or to configure a BGP neighbor to be a member of a peer group. To create a BGP peer group, specify a peerGroupName for the new peer group. Use the no version to remove a peer group. To assign members to a peer group, specify an ip-address and a peerGroupName of a BGP neighbor that belongs to this group. This command takes effect immediately. Use the no version to remove a neighbor from a peer group. For information on the inheritance of configuration values by peer groups and peers, see Inheritance of Configuration Values earlier in this chapter. [Contents] [Prev] [Next] [Index] [Report an Error]
Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

Managing a Large-Scale AS
BGP requires that IBGP peers be fully meshed, creating significant routing overhead as the number of peers increases. The number of IBGP sessions increases rapidly with the number of routers:

For example, if an AS has 9 BGP peers,

BGP provides two alternative configuration strategies to reduce the number of fully meshed peers. You can either: Configure confederations. Configure route reflectors.

Both of these strategies are complex and can create their own problems. Neither strategy is typically used unless the mesh of IBGP peers approaches 100 sessions per peer.

Configuring a Confederation
IBGP requires that BGP speakers within an AS be fully meshed. You can reduce the IBGP mesh inside an AS by subdividing the AS into a confederation of sub-ASs. Each sub-AS must be fully meshed internally, but the sub-ASs do not have to be fully meshed with each other. Confederations are most useful when the number of IBGP speakers within an AS increases to the point that each router has about 100 peering sessions. Figure 1-36 shows a simpler system. AS 29 consists of 10 fully meshed IBGP peers (for clarity, only the BGP sessions are shown). Border router Salem has an EBGP session with a neighbor in AS 325. Border router Boston has an EBGP session with a neighbor in AS 413.

Figure 1-36 A fully meshed autonomous system Figure 1-37 illustrates how you can create three sub-ASs within AS 29 to greatly reduce the number of peering sessions. According to common practice, use a number from the private range of AS numbers from 64512 to 65535to identify each sub-AS. AS 29 is now a confederation of three sub-ASs: AS 64720, AS 64721, and AS 64722. Each sub-AS consists of fully meshed IBGP peers. A slightly modified version of EBGP runs between the sub-ASs: It acts like IBGP within an AS because the local-pref, MED, and next-hop attributes are preserved across the sub-AS boundaries. To the external neighbors, AS 29 appears the same as it ever was.

Figure 1-37 A confederation of sub-autonomous systems The following commands partially configure router Salem: host1(config)#router bgp 64720 host1(config-router)#bgp confederation identifier 29 host1(config-router)#bgp confederation peers 64721 64722 host1(config-router)#neighbor 10.2.25.4 remote-as 64720 host1(config-router)#neighbor 10.2.25.8 remote-as 64721 host1(config-router)#neighbor 10.2.25.2 remote-as 325 The bgp confederation identifier command establishes router Salem as a member of Confederation 29. The bgp confederation peers command specifies that sub-AS 64721 and sub-AS 64722 are members of the same confederation as the sub-AS that includes router Salem. The neighbor remoteas commands specify the IBGP connection with a neighbor in sub-AS 64720 and the EBGP connections with neighbors in sub-AS 64721 and outside the confederation in AS 325. Similarly, the following commands partially configure router Harvard: host2(config)#router bgp 64721 host2(config-router)#bgp confederation identifier 29 host2(config-router)#bgp confederation peers 64720 64722 host2(config-router)#neighbor 10.2.25.7 remote-as 64720 From router Newport's perspective, router Salem is simply a member of AS 29:

host3(config)#router bgp 325 host3(config-router)#neighbor 10.2.25.6 remote-as 29 From router Mason's perspective, router Boston is simply a member of AS 29: host4(config)#router bgp 413 host4(config-router)#neighbor 10.3.3.2 remote-as 29

bgp confederation identifier

Use to establish a router as a member of the specified BGP confederation. To systems outside the confederation, the confederation appears as an autonomous system with an AS number the same as the confederation identifier. The new confederation identifier is used in open messages and in the AS path in update messages that are sent after you issue the command. To force sessions that are already up to use the new confederation identifier, you must use the clear ip bgp command to perform a hard clear. Use the no version to remove the sub-AS from the confederation.

bgp confederation peers

Enables EBGP sessions with routers in the peer sub-ASs; the EBGP sessions preserve local-pref, MED, and next-hop attributes. You can specify one or more individual sub-AS numbers, or you can issue the filter-list keyword and an AS-path access list (which is based on regular expressions) to specify a list of sub-AS numbers. If the remote AS of a peer appears in the specified list of sub-ASs or is identified by the filter list, then the peer is considered to be in the same confederation. This command takes effect immediately and bounces only those sessions whose peer type changed as a result of issuing the command. Use the no version to remove individually specified sub-ASs, all sub-ASs specified by the filter list, or all sub-ASs from the confederation.

ip bgp-confed-as-set new-format
Use to specify that AS-confed-sets are displayed enclosed within square brackets rather than parentheses, and that the AS paths in the set are delimited by commas rather than spaces. Example host1(config)#ip bgp-confed-as-set new-format Use the no version to restore the default display within parentheses and with space-delimited ASs.

Configuring Route Reflectors

Router reflection is an alternative to confederations as a strategy to reduce IBGP meshing. BGP specifies that a BGP speaker cannot advertise routes to an IBGP neighbor if the speaker learned the route from a

different IBGP neighbor. A route reflector is a BGP speaker that advertises routes learned from each of its IBGP neighbors to its other IBGP neighbors; routes are reflected among IBGP routers that are not meshed. The route reflector's neighbors are called route reflector clients. The clients are neighbors only to the route reflector, not to each other. Each route reflector client depends on the route reflector to advertise its routes within the AS; each client also depends on the route reflector to pass routes to the client. A route reflector and its clients are collectively referred to as a cluster. Clients peer only with a route reflector and do not peer outside their cluster. Route reflectors peer with clients and other route reflectors within the cluster; outside the cluster they peer with other reflectors and other routers that are neither clients nor reflectors. Route reflectors and nonclient routers must be fully meshed. Clients and nonclients have no knowledge of route reflection; they operate as standard BGP peers and require no configuration. You simply configure the route reflectors. Route reflectors advertise routes learned from: A nonclient peer only to clients A client peer to all nonclient peers and to all client peers except for the originator of the route An EBGP peer to all nonclient peers and all client peers Figure 1-38 illustrates a simple route reflection setup. Configured as a route reflector, Router Harvard reflects routes among its clients within Cluster 23: Routers Plymouth, Westford, and Acton. These route reflector clients see router Harvard and each other simply as IBGP neighbors. Router Newport in AS 325 and router Mason in AS 413 see router Harvard simply as an EBGP neighbor in AS 29.

Figure 1-38 Simple route reflection

Route Reflection and Redundancy

Reliability and redundancy are important issues when using route reflection because the members of a cluster are not fully meshed. For example, if router Harvard in Figure 1-38 goes down, all of its clients are isolated from networks outside the cluster. Having one or more redundant route reflectors in a cluster protects against such an occurrence. However, you cannot rely on logical redundancy alone. Consider the cluster shown in Figure 1-39. The operator has attempted to provide redundancy in Cluster 9 by configuring two route reflectors, router Acton and router Westford. Unfortunately, router Harvard is physically isolated if its link to router Acton goes down, or if router Acton itself goes down. Similarly, router Plymouth is isolated if any problems develop with router Westford.

Figure 1-39 Route reflection: logical redundancy In Figure 1-40, the operator has added physical redundancy to the cluster configuration. Now, loss of either one of the route reflectors does not isolate the reflector clients.

Figure 1-40 Route reflection: physical and logical redundancy

Route Reflection and Looping

BGP prevents looping between ASs by evaluating the AS-path attribute to determine a route's origin. Border routers reject routes they receive from external neighbors if the AS path indicates that the route originated within the border router's AS. Route reflection creates the possibility of looping within an AS. Routes that originate within a cluster might be forwarded back to the cluster. Because this happens within a given AS, the AS-path attribute is of no use in detecting a loop.

Route reflectors add an originator ID to each route that identifies the originator of the route within the local AS by its router ID. If a router receives a route having the originator ID set to its own router ID, it rejects the route. You can also use a cluster list to prevent looping. Each cluster has an identifying number, the cluster ID. For clusters with a single route reflector, the cluster ID is the router ID of the route reflector; otherwise you configure the cluster ID. The cluster list records the cluster ID of each cluster traversed by a route. When a route reflector passes a route from a client to a nonclient router outside the cluster, the reflector appends the cluster ID to the list. When a route reflector receives a route from a nonclient, it rejects the route if the list contains the local cluster ID. What about routes that a client forwards out of the cluster? No cluster ID is needed, because clients can forward routes only to EBGP peers, that is, to peers outside the AS. Looping between ASs is prevented by the AS-path list. The following commands configure the route reflectors for the network topology shown in Figure 1-41. You would configure the other routers, whether nonclients or route reflector clients, as usual for IBGP and EBGP peers. To configure router Salem as a route reflector: host1(config)#router bgp 29 host1(config-router)#neighbor host1(config-router)#neighbor route-reflector-client host1(config-router)#neighbor host1(config-router)#neighbor route-reflector-client host1(config-router)#neighbor host1(config-router)#neighbor host1(config-router)#neighbor

10.2.5.5 remote-as 29 10.2.5.5 10.2.5.6 remote-as 29 10.2.5.6 10.2.5.7 remote-as 29 10.2.5.8 remote-as 29 10.2.25.5 remote-as 325

You do not configure a cluster ID, because router Salem is the only route reflector in this cluster.

Figure 1-41 BGP route reflection To configure router Concord as a route reflector: host2(config)#router bgp 29 host2(config-router)#neighbor host2(config-router)#neighbor route-reflector-client host2(config-router)#neighbor host2(config-router)#neighbor route-reflector-client host2(config-router)#neighbor

10.7.1.3 remote-as 29 10.7.1.3 10.7.1.4 remote-as 29 10.7.1.4 10.7.6.2 remote-as 29

You do not configure a cluster ID, because router Concord is the only route reflector in this cluster. To configure router Acton as a route reflector: host3(config)#router bgp 29 host3(config)#bgp cluster-id 23 host3(config-router)#neighbor 10.3.1.1 remote-as 29 host3(config-router)#neighbor 10.3.1.1 route-reflector-client host3(config-router)#neighbor 10.1.2.3 remote-as 29 host3(config-router)#neighbor 10.1.2.3 route-reflector-client

host3(config-router)#neighbor 10.3.3.4 remote-as 29 host3(config-router)#neighbor 10.2.5.1 remote-as 29 You must configure a cluster ID, because router Acton and router Harvard are both route reflectors in this cluster. To configure router Harvard as a route reflector: host4(config)#router bgp 29 host4(config)#bgp cluster-id 23 host4(config-router)#neighbor 10.3.1.2 host4(config-router)#neighbor 10.3.1.2 route-reflector-client host4(config-router)#neighbor 10.1.2.1 host4(config-router)#neighbor 10.1.2.1 route-reflector-client host4(config-router)#neighbor 10.3.3.2 host4(config-router)#neighbor 10.2.5.2

remote-as 29

remote-as 29

remote-as 29 remote-as 29

You must configure a cluster ID, because router Harvard and router Acton are both route reflectors in this cluster.

bgp client-to-client reflection

Use to reenable the reflector to reflect routes among all clients. Client-to-client reflection is enabled by default. If the route reflector's clients are fully meshed, you can disable reflection because it is not necessary. If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group. Example host1(config-router)#no bgp client-to-client reflection Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP RIB, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear. Use the no version to disable route reflection; use only if the route reflector's clients are fully meshed.

bgp cluster-id
Use to configure a cluster ID on the route reflectors if the BGP cluster has more than one route reflector. For clusters with a single reflector, the cluster ID is the reflector's router ID and does not have to be configured. You specify a cluster ID number or an IP address of a router acting as a route reflector. The new cluster ID is used in update messages sent after you issue the command. To force BGP to resend all routes with the new cluster ID, you must use the clear ip bgp command to perform a hard clear or a soft clear. Use the no version to cause BGP to use the router ID as the cluster ID.

neighbor route-reflector-client
Use to configure the local router as the route reflector and the specified neighbor as one of its clients. The reflector and its clients constitute a cluster. BGP neighbors that are not specified as clients are nonclients. Route reflectors pass routes among the client routers. Route reflection eliminates the need for all IBPG peers to be fully-meshed. The members of a cluster do not have to be fully meshed, but BGP speakers outside the cluster must be fully meshed. If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group. If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member. Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP RIB, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear. Use the no version to indicate that the neighbor is no longer a client. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration. [Contents] [Prev] [Next] [Index] [Report an Error]
Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring BGP Multicasting

The BGP multiprotocol extensions (MP-BGP) enable BGP to carry IP multicast routes used by the Protocol Independent Multicast (PIM) to build data distribution trees (see ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 3, Configuring IP Multicasting for information on PIM). You can configure a multicast routing topology different from your unicast topology to achieve greater control over network resources. This application of MP-BGP is often referred to as multicast BGP (MBGP). The BGP multiprotocol extensions specify that BGP can exchange information within different types of address families: Unicast IPv4 - When you enable BGP, the system employs unicast IPv4 addresses by default. You must specify an address family other than unicast IPv4 for the new features. Multicast IPv4 - If you specify the multicast IPv4 address family, you can configure the system to exchange routes to multicast sources (as opposed to routes to unicast destinations). VPN-IPv4 - If you specify the VPN-IPv4 address family, sometimes referred to as VPNv4, you can configure the system to provide IPv4 VPN services via an MPLS backbone. As discussed in Understanding BGP Command Scope (p 1-15), BGP configuration commands fall into five categories. If you specify the multicast address family, from within the Address Family Configuration mode you can issue the commands listed in Table 1-4 to configure parameters that affect the multicast

address family globally. You can issue the commands listed in Table 1-6 to configure a peer or peer group that you have activated in the multicast address family without affecting those configuration parameters for any other address family within which the peer or peer group is activated. If you issue any of the commands listed in Table 1-5 from within the default IPv4 unicast address family to configure a peer or peer group, you can apply those configuration values to the same entity in the multicast address family by activating the peer or peer group in the multicast address family.

Example
To add a peer to the multicast routing table, first add the peer to the unicast routing table, and then copy it to the multicast routing table. host1(config)#router bgp 22 host1(config-router)#neighbor 192.168.55.122 remote-as 33 host1(config-router)#address-family ipv4 multicast host1(config-router-af)neighbor 192.168.55.122 activate

address-family
Use to configure the router to exchange IPv4 addresses in unicast, multicast, or VPN mode. The default setting is to exchange IPv4 addresses in unicast mode from the default router. Examples host1:vr1(config-router)#address-family ipv4 multicast host1:vr1(config-router)#address-family vpnv4 host1:vr1(config-router)#address-family ipv4 unicast vrf vr2 This command takes effect immediately. Use the no version to disable the exchange of a type of prefix.

exit-address-family
Use to exit Address Family Configuration mode and access Router Configuration mode. Example host1:vr1(config-router-af)#exit-address-family There is no no version.

neighbor activate
Use to specify a peer with which routes of the current address family are exchanged. A peer can be activated in more than one address family. By default, a peer is activated only for the IPv4 unicast address family. The peer must be created in unicast IPv4 or VPN IPv4 before you can activate it in another address family.

 If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. The address families that are actively exchanged over a BGP session are negotiated when the session is established. Example host1:vr1(config-router-af)#neighbor 192.168.1.158 activate This command takes effect immediately. If dynamic capability negotiation was not negotiated with the peer, the session is automatically bounced so that the exchanged address families can be renegotiated in the open messages when the session comes back up. If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued. If a neighbor is activated, BGP also sends the full contents of the BGP RIB of the newly activated address family. Use the no version to indicate that routes of the current address family should not be exchanged with the peer.

Monitoring BGP Multicast Services

To display values from the BGP multicast routing table, use the show BGP commands with the ipv4 multicast keyword. For more information about displaying BGP parameters, see Monitoring BGP in this chapter. [Contents] [Prev] [Next] [Index] [Report an Error]
Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

Using BGP Routes for Other Protocols

You can use the ip route-type command to specify whether BGP IPv4 unicast routes are available only for other unicast routing protocols or for both unicast and multicast routing protocols to perform RPF checks. Routes available for unicast routing protocols appear in the unicast view of the routing table, whereas routes available for multicast routing protocols appear in the multicast view of the routing table. Typically you use MP-BGP to learn the RPF routes for multicast protocols, especially if the topology for multicast networks differs from that for unicast networks. However, you might use this command if you do not want to run multicast MP-BGP, or if you are running BGP between CE routers in a given BGP/MPLS VPN (the current specification does not provide a way to transmit multicast MP-BGP routes across a BGP/MPLS VPN core).

ip route-type
Use to specify whether BGP routes are available for other unicast protocols or both unicast and multicast protocols.

 You cannot specify that BGP routes are available only for multicast protocols. Use the show ip routes command to view the routes available for unicast protocols. Use the show ip rpf-routes command to view the routes available for multicast protocols. It does not display routes available only to unicast protocols. By default, BGP IPv4 unicast routes are available only for other unicast routing protocols. Example 1 host1(config)#router bgp 100 host1(config-router)#ip route-type both Example 2

host1(config)#router bgp 100 host1(config-router)#address-family ipv4 unicast vrf v1 host1(config-router-af)#ip route-type both Use the no version to restore the default value, unicast.

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring BGP VPN Services

To configure a system to provide BGP VPN services, you must perform some tasks once per PE and some tasks for each VRF on the PE.

VRF Configuration Tasks

To configure a VRF to provide BGP VPN services: 1. Create the VRF.

host1(config)#virtual-router vr1 host1:vr1(config)#ip vrf vrfA 1. Assign a route distinguisher to the VRF.

host1:vr1(config-vrf)#rd 100:100 1. Set the route-target import and route-target export lists for the VRF.

host1:vr1(config-vrf)#route-target import 100:1 host1:vr1(config-vrf)#route-target export 100:1 1. (Optional) Set import and export maps for the VRF.

host1:vr1(config-vrf)#import map Another-route-map host1:vr1(config-vrf)#export map A-route-map host1:vr1(config-vrf)#exit 1. Assign interfaces for PE-to-CE links to the VRF from inside or outside the VRF context: host1:vr1(config)#interface gigabitEthernet 1/0 host1:vr1(config-if)#ip vrf forwarding vrfA host1:vr1(config-if)#ip address 10.16.2.77 255.255.255.0 host1:vr1(config-if)#exit or host1:vr1(config)#virtual-router :vrfA host1:vr1:vrfA(config)#interface gigabitEthernet 1/0 1. Use either of the following methods to establish how the VRF learns routes to customer sites:

 Create static routes to the customer site in the VRF by one of the following methods: host1(config)#virtual-router vr1 host1:vr1(config)#ip vrf vpnA host1:vr1(config-vrf)#ip route vrf vrfA 10.3.0.0 255.255.0.0 10.1.1.1 host1:vr1(config-vrf)#ip route vrf vrfA 10.12.0.0 255.255.0.0 10.1.1.1 or host1(config)#virtual-router vr1:vrfA host1:vr1:vrfA(config)#ip route 10.3.0.0 255.255.0.0 10.1.1.1 host1:vr1:vrfA(config)#ip route 10.12.0.0 255.255.0.0 10.1.1.1 Configure an IGP on the VRF to learn routes from the CE.

See Configuring IGPs on the VRF later in this chapter for examples. Configure a PE-to-CE EBGP session.

See Configuring PE-to-CE BGP Sessions later in this chapter for information on configuring EBGP. 1. (Optional) Configure the system to generate a label for each different FEC pointed to by a BGP route in the VPN. host1:vr1(config-vrf)#ip mpls forwarding-mode label-switched 1. (Optional) Configure the system to create a VPN interface for each received stacked label, enabling collection of statistics on a per-label basis. host1:vr1(config-vrf)#ip mpls vpn-interface per-label

PE Configuration Tasks
To configure a PE to provide BGP VPN services: 1. Configure PE-to-PE LSPs.

See Chapter 2, Configuring MPLS, for information on configuring LSPs. 1. Enable BGP routing.

host1:vr1(config)#router bgp 100 1. (Optional) Disable automatic route-target filtering.

host1:vr1(config-router)#no bgp default route-target filter 1. Configure PE-to-PE BGP sessions. a. Create the PE-to-PE session. host1:vr1(config)#router bgp 100 host1:vr1(config-router)#neighbor 192.168.1.158 remote-as 100 a. Create the VPN-IPv4 address family. host1:vr1(config-router)#address-family vpnv4 a. Activate the PE-to-PE session in the VPN-IPV4 address family. host1:vr1(config-router-af)#neighbor 192.168.1.158 activate host1:vr1(config-router-af)#exit-address-family 1. Configure PE-to-CE BGP sessions. a. Enable and configure BGP: host1:vr1(config)#router bgp 100 See Chapter 1, Configuring BGP Routing, for more information on configuring BGP. a. Specify the IPv4 unicast address family for each VRF: host1:vr1(config-router)#address-family ipv4 unicast vrf vrfA a. Configure the method of route advertisement by doing one of the following: Use neighbor commands to specify peers to which BGP advertises the routes: host1:vr1(config-router)#neighbor 10.12.13.0 remote-as 200 Use network commands or the redistribute static command to make BGP advertise static routes to customers. host1:vr1(config-router)#network 10.3.0.0 mask 255.255.0.0 host1:vr1(config-router)#redistribute static Use redistribute commands to make BGP advertise IGP routes to customers. host1:vr1(config-router)#redistribute ospf 1. (Optional) Configure an AS override.

See Using a Single ASN for all CE Sites later in this chapter for examples.

1. (Optional) Force the BGP speaker to accept routes that have the speaker's AS number in its AS path. host1:vr1(config-router)#bgp enforce-first-as

Creating a VRF
Access the desired virtual router context; then create the VRF(s) for that VR. host1(config)#virtual-router vr1 host1:vr1(config)#ip vrf vrfA

ip vrf
Use to create a VRF or access VRF Configuration mode to configure a VRF. You must specify a route distinguisher after you create a VRF. Otherwise, the VRF will not operate. Example host1:vr1(config)#ip vrf vrfA Use the no version to remove a VRF.

Specifying a Route Distinguisher

The route distinguisher enables you to establish unique VPN-IPv4 addresses to accommodate the possibility that more than one VPN might use the same IP address from their private address spaces.

rd
Use to specify a route distinguisher to a VRF. You can specify either an AS number or an IP address as the first part of the route distinguisher. Specify some unique integer as the second part. You must specify a route distinguisher for a VRF. Otherwise, the VRF will not operate. Once you have configured the route distinguisher, you can change it only by removing and recreating the VRF. Example host1:vr1(config-vrf)#rd 100:100 There is no no version.

Defining Route Targets for VRFs

BGP uses an extended-community attribute, the route target, to filter appropriate VPN routes into the correct VRFs. You configure the export list on the VRF to specify export route targets. When BGP advertises a route from this VRF's forwarding table, it associates the list of export route targets with the route and includes this attribute in the update message that advertises the route.

You also configure a route-target import list on each VRF to specify import route targets. When a PE receives a route, BGP compares the route target list associated with the route (and carried in the update message) with the import list associated with each VRF configured in the PE. For VPN-IPv4 routes received from another PE, if any route target in the export list matches a route target in a VRF's import list, then the route is installed in that VRF's forwarding table. Although it is possible to create very sophisticated route distribution schemes, the most common configuration is to do the following: Allocate one route-target extended-community value per VPN. Define the route-target import list and a route-target export list to include only the route-target extended-community values for the VPN(s) to which the VRF belongs: host1:vr1(config-vrf)#route-target export 777:100 host1:vr1(config-vrf)#route-target import 777:100 If the import and export lists are identical, you can use the both keyword to define the lists simultaneously: host1:vr1(config-vrf)#route-target both 777:105 A route-target export list can be modified on the sending PE by an export map or outbound routing policy. It can be modified on the receiving PE by an import map or inbound routing policy.

route-target
Use to createor add tolists of VPN extended communities for a VRF that determine whether a route is imported into a VRF. An export list defines a route-target extended community; routes having any route target in their export list that matches a route target in a VRF's import list are installed in the VRF's forwarding table. An import list defines a route-target extended community; only routes that have at least one matching route target in their associated export list can be installed into the VRF's forwarding table. If the import and export lists are identical, use the both keyword to define both lists simultaneously. You can add only one route target to a list at a time. Example host1:vr1(config-vrf)#route-target export 100:1 host1:vr1(config-vrf)#route-target import 100:1 Use the no version to remove a route target from the import list, the export list, or both lists.

Example: Fully Meshed VPNs

In a fully meshed VPN, each site in the VPN can reach every other site in the VPN. Figure 3-10 illustrates a situation with two fully meshed VPNs, VPN A and VPN B. VPN A includes Customer Sites 1, 3, and 5 through VRFs A, C, and E. VPN B includes Customer Sites 2, 4, and 6 through VRFs B, D, and F.

Figure 3-10 Fully meshed VPNs BGP sessions exist between PE 1 and PE 2, PE 2 and PE 3, and PE 3 and PE 1. The MPLS paths through the service provider core are omitted for clarity. To configure route targets for this fully meshed scenario, you specify the same route target for the import list and export list on all VRFs in VPN A. The VRFs in VPN B use a different route target, but it is the same for the import list and export list for all. Route-target configuration on PE 1: host1(config)#virtual-router newyork host1:newyork(config)#ip vrf vrfA host1:newyork(config-vrf)#route-target both 777:1 host1:newyork(config-vrf)#exit host1:newyork(config)#ip vrf vrfB host1:newyork(config-vrf)#route-target both 777:2 Route-target configuration on PE 2: host2(config)#virtual-router boston host2:boston(config)#ip vrf vrfC host2:boston(config-vrf)#route-target both 777:1 host2:boston(config-vrf)#exit host2:boston(config)#ip vrf vrfD host2:boston(config-vrf)#route-target both 777:2

Route-target configuration on PE 3: host3(config)#ip vrf vrfE host3(config-vrf)#route-target both 777:1 host3(config-vrf)#exit host3(config)#ip vrf vrfF host3(config-vrf)#route-target both 777:2

Example: Hub-and- Spoke VPN

In one type of a hub-and-spoke design, only the hub site can reach every other site in the VPN. All other sitesspokescan reach only the hub site. (More complex hub-and-spoke designs are possible, but require additional configuration besides route targets to achieve.) In Figure 3-11, Customer Site 1 is the hub site for VPN A. As such it can reach both spokes, Customer Sites 2 and 3 through VRF A. Customer Site 2 can reach only the hub, customer 1, through VRF C. Customer Site 3 can reach only the hub, customer 1, through VRF E. BGP sessions exist between PE 1 and PE 2 and between PE 1 and PE 3. In most situations, BGP itself would be fully meshed, but that level of complexity is not necessary for this example. The MPLS paths through the service provider core are omitted for clarity. To configure route targets for this hub and spoke, you specify different import and export route targets on the hub VRF. On the spoke VRFs, you switch these route targets. Route-target configuration on PE 1: host1(config)#virtual-router newyork host1:newyork(config)#ip vrf vrfA host1:newyork(config-vrf)#route-target export 777:25 host1:newyork(config-vrf)#route-target import 777:50

Figure 3-11 Hub-and-spoke VPN Route-target configuration on PE 2: host2(config)#virtual-router boston host2:boston(config)#ip vrf vrfC host2:boston(config-vrf)#route-target export 777:50 host2:boston(config-vrf)#route-target import 777:25 Route-target configuration on PE 3: host3(config)#ip vrf vrfE host3(config-vrf)#route-target export 777:50 host3(config-vrf)#route-target import 777:25 This configuration ensures that when VRF E on PE 3 receives an update message from PE 1, BGP installs the advertised route only if it has a route target of 25. Routes from PE 2 have a route target of 50, and cannot be installed. Similarly, when VRF C on PE 2 receives an update message from PE 1, BGP installs the advertised route only if it has a route target of 25. Routes from PE 3 have a route target of 50, and cannot be installed. When PE 1 receives updates from either PE 2 or PE 3, the routes have a route target of 50, match VRF A's import list, and are installed in VRF A's forwarding table.

Setting Import and Export Maps for a VRF

The combination of the export route target of VRF A and the route-target import list of VRF B determines whether routes from VRF A are distributed to VRF B.

You can associate import maps and export maps with VRFs to provide finer-grained control of route distribution: Export maps - You can use an export map to change the attributes of a route when it is exported from a VRF. Export maps do not filter routes. Import maps - You can use an import map to change the attributes of a route when it is imported to a VRF. You can also use an import map to filter routes. If you associate an import map with a VRF, that VRF then accepts only received routes that pass the import map (and match the import route target list). For information on creating a route map to be used as an import or export map, see Chapter 1, Configuring BGP Routing. The following example shows how to apply the route map A-route-map to the VRF vpnAconfigured on the virtual router boston. host1(config)#virtual router boston host1:boston(config)#ip vrf vpnA host1:boston(config-vrf)#import map A-route-map

export map
Use to apply an export route map to a VRF. Example

host1:boston(config-vrf)#export map A-route-map Use the no version to remove the route map from the VRF.

import map
Use to apply an import route map to a VRF. Example

host1:boston(config-vrf)#import map Another-route-map Use the no version to remove the route map from the VRF.

Assigning an Interface to a VRF

You must assign an interface or subinterface to a VRF so that when the system receives a packet at this interface, it routes the packet using the VRF's forwarding table rather the global forwarding table. You can assign the interface from outside the context of the VRF or inside the context of the VRF. To assign an interface to a VRF from outside the VRF context: 1. 1. Select the interface. Specify the VRF to associate with the interface.

host1:vr1(config)#interface gigabitEthernet 1/0 host1:vr1(config-if)#ip vrf forwarding vrfA

1. Assign an IP address to the interface because forwarding the interface from the VR to the VRF removes the existing IP configuration from the interface. host1:vr1(config-if)#ip address 10.16.2.77 255.255.255.0 To assign an interface to a VRF from inside the VRF context: 1. 1. Select the interface. Enter the VRF context.

host1:vr1(config)#virtual-router :vrfA 1. Associate the interface.

host1:vr1:vrfA(config)#interface gigabitEthernet 1/0 In this case, you do not have to reassign an IP address to the interface because you did not use the ip vrf forwarding command.

ip vrf forwarding
Use to assign a VRF to an interface or subinterface by forwarding the interface from the VR to the VRF. Forwarding the interface removes the IP configuration from the interface. You must reassign an IP address to the interface after you issue this command. Example host1:foo(config)#ip vrf forwarding vrfA host1:foo(config)#ip address 10.12.4.5 255.255.255.0 Use the no version to remove the interface assignment.

Adding Static Routes to a VRF

Consider the network structure shown in Figure 3-12. If no routing protocolBGP or any other IGPis running between the PE and the CE, you must use the ip route vrf command to add a static route in the customer's VRF for each prefix in that customer's site. Each of these static routes should point to the link connecting the PE to the CE. Typically, you redistribute these static routes in the VRF's address family in BGP or use network commands to make those prefixes reachable from other CEs in the same VPN.

Figure 3-12 Configuring static routes In Figure 3-12, PE 2 has external BGP connections to CE 3 and CE 4. PE 1 has an EBGP connection to CE 2. However, no BGP (or IGP) connection exists between PE 1 and CE 1. The following example shows how to configure static routes on VRF A for both prefixes in CE 1. host1(config)#virtual-router pe1 host1:pe1(config)#ip vrf vpnA host1:pe1(config-vrf)#ip route vrf vrfA 10.3.0.0 255.255.0.0 10.1.1.1 host1:pe1(config-vrf)#ip route vrf vrfA 10.12.0.0 255.255.0.0 10.1.1.1

ip route vrf
Use to add a static route to a VRF. Example

host1:pe1(config-router-af)#ip route vrf vrfA 10.0.0.0 255.0.0.0 192.168.1.1 Use the no version to remove a static route from a VRF.

Configuring IGPs on the VRF

If you do not configure static routes on the VRF for each prefix in the associated customer site, then you must configure an IGP on the VRF so that the VRF can learn routes from customer sites.

Configuring the IGP in the VRF Context

After creating a VRF, you can access it as if it were a virtual router for the purpose of configuring the IGP. If you are in the context of the virtual router that has the VRF, you access the VRF as follows: host1(config)#virtual-router :vrfa host1:default:vrfa(config)# If you are not in the context of the virtual router that has the VRF, you access the VRF as follows: host1(config)#virtual-router boston:vrfa host1:boston:vrfa(config)# The following sample commands illustrate one way to configure OSPF; you can configure RIP and IS-IS similarly: host1(config)#ip vrf vrfa host1(config-vrf)#rd 100:5 host1(config-vrf)#route-target both 100:5 host1(config-vrf)#exit host1(config)#virtual-router :vrfa host1:default:vrfa(config)#router ospf 100 host1:default:vrfa(config-router)#redistribute bgp At this point you proceed with the IGP configuration for the VRF.

Configuring the IGP outside the VRF Context

The RIP and OSPF protocols also enable you to specify a VRF and configure the protocol without actually entering the VRF context. For example, for OSPF you could issue the following command and then complete OSPF configuration tasks for VRF A: host1(config)#router ospf 100 vrf vrfa For RIP, you create the RIP process, specify the address family for the VRF, and specify redistribution of BGP routes for VRF A: host1(config)#router rip 100 host1(config-router)#address-family ipv4 vrf vrfa host1(config-router-af)#redistribute bgp At this point you proceed with RIP configuration for the VRF. See the appropriate chapter for information on configuring the desired IGP: ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 6, Configuring RIP ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 7, Configuring OSPF ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 8, Configuring IS-IS

 ERX Routing Protocols Configuration Guide, Vol. 2, Chapter 1, Configuring BGP Routing

virtual-router
Use to access a VRF to configure it with an IGP to learn routes from a CE. To access the VRF from its VR context (in this example, the default VR):

host1(config)#virtual-router :vrfsouthie host1:default:southie(config)# To access the VRF from the context of a different VR:

host1(config)#virtual-router boston:southie host1:boston:southie(config)# Issuing a no version of this command (no virtual-router :vrfName or no virtualrouter vrName:vrfName) that specifies an existing VRF only displays the error message: "Cannot delete a VRF with this command"; you must use the no ip vrf command to remove a VRF.

Disabling Automatic Route-Target Filtering

When BGP receives a VPN-IPv4 route from another PE, BGP stores that route in its local-RIB only if at least one VRF imports a route target of that route. If there is no VRF that imports any of the route targets of the route, BGP discards the route; this feature is called automatic route-target filtering. The intention is that BGP only keeps track of routes for directly connected VPNs, and discards all other VPN-IPv4 routes to conserve memory. If a new VPN is connected to the system (that is, if the import route-target list of a VRF changes), BGP automatically sends a route-refresh message to obtain the routes that it previously discarded. You can use the no bgp default route-target filter command to disable automatic route-target filtering globally for all VRFs. However, automatic route-target filtering is always disabled on route reflectors that have at least one route-reflector client. You cannot enable automatic route-target filtering for such route reflectors.

bgp default route-target filter

Use to control automatic route-target filtering. Route-target filtering is enabled by default; use the no version to disable automatic filtering. Example host1:vrf1(config-router)#no bgp default route-target filter Takes effect immediately. If route target filtering is turned on, immediately removes routes that should be filtered. If route target filtering is turned off, BGP automatically sends out a route-refresh message over every VPNv4 unicast session (for which the route refresh capability was negotiated)

to get previously filtered routes. If the route refresh capability was not negotiated over the session, BGP bounces the session. Use the no version to disable automatic route-target filtering.

Creating Labels Per FEC

By default, the system minimizes the number of stacked labels to be managed by generating a single label for all BGP routes advertised by a given VRF; this is a per-VRF label. Upon receiving traffic for a per-VRF label, the system performs a label pop and a route lookup to forward the traffic to the next hop. You can use the ip mpls forwarding-mode label-switched command to configure the system to generate a label for each different FEC that a BGP route points to in the VPN; this is a per-FEC label. Issuing this command enables you to avoid a route lookup for traffic destined for CEs, because in this mode traffic is label switched to the corresponding next hop over that interface; a route lookup is not performed. For the following types of routes, the system always generates a per-VRF label and forwards traffic after a route lookup (rather than label switching the traffic without a route lookup) regardless of the status of this command: Local connected interfaces redistributed into BGP, regardless of the interface type. BGP redistributed routes that point to Ethernet interfaces with a null next-hop address; that is, when the next-hop address is the local address on the Ethernet interface. BGP redistributed routes that point to loopback interfaces. The following commands configure a system where BGP is running in VRF pe11 and static and connected routes are redistributed into the VRF: host1(config)#ip vrf pe11 host1(config-vrf)#ip mpls forwarding-mode label-switched host1(config-vrf)#ip route vrf pe11 10.3.4.5 255.255.255.255 fastEthernet 0/1 host1(config-vrf)#ip route vrf pe11 10.1.1.1 255.255.255.255 loopback 1 host1(config-vrf)#exit host1(config)#router bgp 100 host1(config-router)#address-family ipv4 unicast vrf pe11 host1(config-router-af)#exit host1(config-router)#no auto-summary host1(config-router)#no synchronization host1(config-router)#redistribute static host1(config-router)#redistribute connected For each connected route that is redistributed into the VRF and advertised across the BGP/MPLS VPN, the system assigns a per-VRF label rather than a per-FEC label. The static route 10.3.4.5/32 points to an Ethernet interface where the next-hop address is the local address on that interface. BGP therefore advertises this static route with a per-VRF label. The static route 10.1.1.1/32 points to loopback interface 1. BGP therefore advertise this static route with a per-VRF label.

ip mpls forwarding-mode label-switched

Use to generate a label for each different FEC pointed to by a BGP route. For some types of routes, issuing this command has no effect on the labels created; they are always per-VRF labels. Example host1:vr1(config-vrf)#ip mpls forwarding-mode label-switched Use the no version to restore the default, generating a single label for all BGP routes sent from a given VRF.

Allocating VPN Interfaces per Label

If you want to observe statistics on a per-label basis, you can use the ip mpls vpn-interface perlabel command to configure the system to allocate a VPN interface for each received stacked label. Doing so will reduce the number of supported egress FECs to the order of thousands.

Note: If you want to run IP multicasting over MPLS tunnels in a VRF, you must issue the ip mpls vpn-interface per-label command. IP multicasting over MPLS tunnels in a VRF is not supported in the default mode whereby MPLS allocates VPN interfaces per next hop.

You can use the show ip route command to observe the received stacked label associated with received BGP routes. In the following example, several routes have been received in VRF pe11: host1:pe1:pe11#show ip route 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 L- MPLS label, V- VRF Prefix/Length Type ------------------ -------------------------10.21.21.0/24 Bgp mpls:vpnIngress-33] 10.22.22.0/24 Bgp mpls:vpnIngress-33] 10.99.99.21/32 Bgp mpls:vpnIngress-33] Next Hop Dist/Met ------------- ----------2.2.2.2[L:21] 2.2.2.2[L:21] 2.2.2.2[L:26] 200/0 200/0 200/0 Intf ip dyn-0[ tun ip dyn-0[ tun ip dyn-0[ tun

All three routes were received from the same endpoint, indicated by the common BGP indirect next hop, 2.2.2.2. The received stacked label for each route is presented in the Next Hop column as

[L: labelNumber]. Routes 10.21.21.0/24 and 10.22.22.0/24 have the same label, 21. Route 10.99.99.21/32 has a different label, 26. In the default mode, a single VPN interface is created for each next hop. That is, a single dynamic IP interface is created on top of the variable interface created by MPLS. All three routes, even though they have different received stacked labels, point to the same dynamic IP interface created for the next hop, ip dyn-0[ tun mpls:vpnIngress-33]. Alternatively, if you issue the ip mpls vpn-interface per-label command in the same network to create per-label interfaces, the output would look as follows: host1:pe1:pe11#show ip route 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 L- MPLS label, V- VRF Prefix/Length Type ------------------ -------------------------10.21.21.0/24 Bgp mpls:vpnIngress-33] 10.22.22.0/24 Bgp mpls:vpnIngress-33] 10.99.99.21/32 Bgp mpls:vpnIngress-36] Next Hop Dist/Met ------------- ----------2.2.2.2[L:21] 2.2.2.2[L:21] 2.2.2.2[L:26] 200/0 200/0 200/0 Intf ip dyn-0[ tun ip dyn-0[ tun ip dyn-0[ tun

Routes 10.21.21.0/24 and 10.22.22.0/24 have the same received stacked label, 21, and point to the same dynamic IP interface created for that label, ip dyn-0[ tun mpls:vpnIngress-33]. Route 10.99.99.21/32 has a different label, 26, so a different dynamic IP interface is created for it, ip dyn-0[ tun mpls:vpnIngress-36].

ip mpls vpn-interface per-label

Use to create a VPN interface for each received stacked label in a BGP/MPLS VPN. Enables collection of statistics on a per-label basis. Example host1:vr1(config-vrf)#ip mpls vpn-interface per-label Use the no version to restore the default, creating a VPN interface for each nexthop PE.

Configuring PE-to-PE LSPs

See Chapter 2, Configuring MPLS, for information on configuring LSPs.

Enabling BGP Routing

You must enable the BGP routing process on the system serving as the PE router.

router bgp
Use to enable the BGP routing protocol and to specify the local ASthe AS to which this BGP speaker belongs. All subsequent BGP configuration commands are placed within the context of this router and AS; you can have only a single BGP instance per virtual router. Specify only one BGP AS per virtual router. Example host1:vr1(config)#router bgp 100 This command takes effect immediately. Use the no version to remove the BGP process.

Enabling VPN Address Exchange

To limit the exchange of routes to those from within the VPN-IPv4 address family, and to set other desired BGP parameters: 1. Specify that the router should exchange addresses within a VPN by choosing the VPN-IPv4 address family. 1. Specify individual neighbors or peer groups that will exchange routes only from within the current (VPN-IPv4) address family. 1. Configure BGP parameters for VPN services. See Chapter 1, Configuring BGP Routing, for information on configuring BGP sessions. The section Understanding BGP Command Scope in that chapter has tables that list BGP commands according to their scope. From Address Family Configuration mode, you can issue the commands in Table 1-4 and Table 1-6. 1. Exit Address Family Configuration mode.

address-family
Use to configure the router to exchange IPv4 addresses in VPN mode. The default setting is to exchange IPv4 addresses in unicast mode from the default router. Example host1:vr1(config-router)#address-family vpnv4 This command takes effect immediately. Use the no version to disable the exchange of a type of prefix.

exit-address-family

 Use to exit Address Family Configuration mode and access Router Configuration mode. Example host1:vr1(config-router-af)#exit-address-family There is no no version.

neighbor activate
Use to specify neighbors that will exchange routes from within the current address family. Example host1:vr1(config-router-af)#neighbor 192.168.1.158 activate Takes effect immediately. If dynamic capability negotiation was not negotiated with the peer, the session is automatically bounced so that the exchanged address families can be renegotiated in the open messages when the session comes back up. If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued. If a neighbor is activated, BGP also sends the full contents of the BGP RIB of the newly activated address family. Use the no version to indicate that routes of the current address family should not be exchanged with the peer. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.

Configuring PE-to-CE BGP Sessions

If you have established a BGP session between a PE and a particular CE, you can configure BGP sessions with all the other customer sites within the VPN so that they can learn the routes to the particular CE. Configuring the PE-to-CE external BGP session is a bit different from the usual external BGP session. You must configure the session in the context of the IPV4 unicast address family of the VRF. Consider the topology shown in Figure 3-13.

Figure 3-13 PE-to-CE session You configure the characteristics of VRF A, the global BGP attributes, the address family for the session, and BGP attributes relevant to the VRF or address family. host1(config)#ip vrf vrfa host1(config-vrf)#rd 777:5 host1(config-vrf)#route-target both 777:5 host1(config-vrf)#exit host1(config)#interface gigabitEthernet 1/0 host1(config-if)#ip vrf forwarding vrfA host1(config-if)#ip address 10.1.10.1 255.255.255.0 host1(config-if)#exit host1(config)#router bgp 777 (Configure global BGP attributes) host1(config-router)#address-family ipv4 unicast vrf vrfA host1(config-router-af)#neighbor 10.1.10.2 remote-as 73 (Configure BGP attributes relevant to the VRF or the address family) See Chapter 1, Configuring BGP Routing, for more information on configuring BGP.

Advertising Static Routes to Customers

If you established static routes on a PE for each prefix in a particular customer site, you can configure BGP on the PE to advertise these static routes to customer sites within the VPN via network commands. host1:vr1(config-router)#network 10.3.0.0 host1:vr1(config-router)#network 10.12.0.0 In this example, both networks end on a classful boundary, eliminating the need to configure a network mask. Alternatively, you can use the redistribute command to advertise the static routes as follows:

host1:vr1(config-router)#redistribute static See Chapter 1, Configuring BGP Routing, for more information on advertising static routes.

Advertising IGP Routes to Customers

If the PE learns routes from a CE via an IGP, you can configure BGP to advertise these IGP routes to all customer sites within the VPN via redistribute commands. For example, if the PE learns the routes via OSPF, you can issue the following command to inject these routes into BGP for advertisement: host1:vr1(config-router)#redistribute ospf See Chapter 1, Configuring BGP Routing, for more information on advertising IGP routes.

Disabling the Default Address Family

PEs can exchange routes in the IPv4 address family, VPNv4 address family, or both. Issuing the neighbor remote-as command automatically activates the IPv4 unicast address family, meaning that the PE exchanges routes in the IPv4 unicast address family with that peer.

Example 1
The following commands illustrate how you could configure the exchange of routes in both the IPv4 unicast and the VPNv4 unicast address families for a BGP peer: host1:vr1(config)#router bgp 777 host1:vr1(config-router)#neighbor 10.26.5.10 remote-as 100 host1:vr1(config-router)#address-family vpnv4 unicast host1:vr1(config-router-af)#neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family The neighbor remote-as command activated the IPv4 unicast address family for the peer. The addressfamily command entered the context of the VPNv4 unicast family and the neighbor activate command activated the address family for the peer.

Example 2
The following commands illustrate one way you could disable the exchange of routes in the IPv4 unicast address family and enable the exchange of routes in the VPNv4 unicast address family: host1:vr1(config)#router bgp 777 host1:vr1(config-router)#neighbor 10.26.5.10 remote-as 100 host1:vr1(config-router)#address-family ipv4 unicast host1:vr1(config-router-af)#no neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family host1:vr1(config-router)#address-family vpnv4 unicast host1:vr1(config-router-af)#neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family

In this case, the no neighbor activate command specifically disables the IPv4 unicast address family for that peer alone; no other peers are affected. The VPNv4 unicast address family is activated for the peer as in Example 1.

Example 3
The following commands illustrate another way you could disable the exchange of routes in the IPv4 unicast address family and enable the exchange of routes in the VPNv4 unicast address family: host1:vr1(config)#router bgp 777 host1:vr1(config-router)#no bgp default ipv4-unicast host1:vr1(config-router)#neighbor 10.26.5.10 remote-as 100 host1:vr1(config-router)#address-family vpnv4 unicast host1:vr1(config-router-af)#neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family In this case, the no bgp default ipv4-unicast command prevents the automatic enabling of the IPv4 unicast address family for all peers subsequently configured with the neighbor remote-as command. Previously configured peers are not affected. The VPNv4 unicast address family is activated for the peer as in Examples 1 and 2.

Using a Single ASN for all CE Sites

If you want to use the same AS number for all of your CE sites, you can substitute a PE's autonomous system number for that of a neighbor by specifying the neighbor's IP address in the neighbor asoverridecommand. If you fail to do this, the CE recognizes its AS in the AS path of received routes and believes it has discovered a routing loop; the routes will be rejected.

Example
In the following example, the router's AS number of 777 overrides the neighboring router's AS number of 100. host1:vr1(config)#router bgp 777 host1:vr1(config-router)#neighbor 172.16.20.10 remote-as 100 host1:vr1(config-router)#neighbor 172.16.20.10 update-source loopback0 host1:vr1(config-router)#address-family ipv4 vrf vpn1 host1:vr1(config-router-af)#neighbor 172.25.14.12 remote-as 100 host1:vr1(config-router-af)#neighbor 172.25.14.12 as-override

neighbor as-override
Use to enable the use of the same AS number for all CE sites by substituting the current router's AS number in routing tables for that of the neighboring router. If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group. Example

host1:vr1(config-router)#neighbor 192.168.255.255 as-override Example

host1(config-router)#neighbor 192.168.1.158 as-override New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session. Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to halt the substitution of the AS numbers. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.

Advertising Prefixes with Duplicate AS Numbers

When a BGP speaker receives a route that has the speaker's AS number in its AS path, the speaker declares that route to be a loop and discards it. However, in some circumstances, as in the implementation of a hub-and-spoke VPN topology, this is not the desired behavior. You want the BGP speaker (hub) to accept such routes. You can use the neighbor allowas-in command to specify the number of times that a route's AS path can contain the BGP speaker's AS number.

neighbor allowas-in
Use to enable the acceptance of all routes whose AS path contains the BGP speaker's AS number up to the specified number of times. If the AS path of a route contains the speaker's AS number more than the specified number of times, the route is considered to be a loop and is discarded. Example host1(config-router)#bgp allowas-in New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command. To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.

Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. 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. 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. Use the no version to prevent the acceptance of these routes, resulting in the BGP speaker's discarding the routes.

Controlling Route Importation

You can control how many routes a PE can add to a particular VRF's forwarding table by specifying a maximum limit and a warning threshold. When the router attempts to add a route, it checks the limit you configure against a route count it maintains for routes already in the VRF's forwarding table. With a warning threshold configured, the following behavior takes place when the PE attempts to add a route: When adding the route causes the route count to exceed the warning threshold for the first time, the system adds the route and generates a warning-thresholdexceeded log entry. As long as the route count stays above the warning threshold, adding more routes does not generate more warning-threshold-exceeded log entries. If the route count fluctuates below and above the warning threshold due to route deletions and additions, an interval of five minutes since the last warning-thresholdexceeded log entry must pass before another warning-threshold-exceeded log entry can be generated. This behavior prevents the system log from being flooded with log entries. With a limit configured, the following behavior takes place when the PE attempts to add a route: When adding the route causes the route count to exceed the limit for the first time, the system rejects the route and generates a limit-exceeded log entry. As long as the route count stays at the limit, further attempts to add routes fail, but do not generate any more limit-exceeded log entries. If the route count fluctuates below and up to the limit due to route deletions and additions, no further limit-exceeded log entries are generated until a five minute interval has passed since the last limit-exceeded log entry. This behavior prevents the system log from being flooded with log entries. When you issue the command, the system immediately reevaluates the current number of routes against the new limit. If the current number of routes is greater than the maximum allowed, the system might remove dynamically learned routes in order to enforce the new limit.

maximum routes
Use to prevent a PE router from importing too many routes from attached CE routers into a particular VRF. When the router attempts to add a route that exceeds the warningThreshold, the system generates a warning-threshold log entry and adds the route. An interval of five

minutes must pass before another warning-threshold-exceeded message can be generated. When the router attempts to add a route that exceeds the limit, the system generates a limit-exceeded warning and rejects the route. An interval of five minutes must pass before another limit-exceeded message can be generated. Messages are logged to ipRouteTable at severity error. The interval timers for the limit and the warning threshold are independent. You can use the warning-only keyword to specify that the system add the route and generate a warning-threshold-exceeded log entry (instead of a limit-exceeded log entry) when the limit is exceeded. Issuing the command causes the system to evaluate the current route count and determine whether to generate new messages; any existing warning threshold or limit timers are reset to zero. Example host1(config-vrf)#maximum routes 80 65 Use the no version to remove the limit and warning threshold.

Deleting Routes for a VRF

You can delete one or all IP routes assigned to a VRF or all VRFs.

clear ip routes
Use to clear routes from the routing table of one or all VRFs. If you do not specify a VRF, routes are removed from all VRFs. You can specify either that a single route or all dynamic routes are to be removed. Example host1:vr1#clear ip routes vrf vr3 * This command takes effect immediately. There is no no version.

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

OSPF and BGP/MPLS VPNs

Before reading this section, you should be thoroughly familiar with OSPF. For detailed information on that protocol, see ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 7, Configuring OSPF.

You can use BGP/MPLS VPNs to connect OSPF domains without creating OSPF adjacencies between the domains. The BGP/MPLS VPN backbone acts as either an OSPF backbone (area 0) or an OSPF area above the backbone. In this topology, OSPF is the routing protocol between the CE and the PE. This OSPF link can be configured in area 0 or any other OSPF area. However, if the customer site has any connections to area 0, then at least one OSPF router configured on a CE must have an area 0 link to a PE site. In this case, the BGP/MPLS VPN acts as if it is in an area above the OSPF backbone area. When the PE-CE link is in a nonbackbone area, the BGP/MPLS VPN acts as an OSPF backbone. In either case, the OSPF router configured as a PE in the BGP/MPLS VPN is always treated as an area border router (ABR) and functions as an area 0 router so that it can distribute interarea routes to the CE. The BGP/MPLS VPN distributes both interarea and intra-area routes between PEs as inter-area, type 3 summary routes.

Distributing OSPF routes from CE to PE

You configure OSPF in the VRF associated with the VPN and associate the interface connected to the CE with the VRF. OSPF routes can then propagate from a CE to a PE when an OSPF adjacency has formed between the two routers. OSPF adds routes to the VRF's forwarding table at the PE side with routes learned from the CE.

Distributing routes Between PEs

The OSPF routes in the VRF forwarding table are OSPF IPv4 routes, but BGP/MPLS VPNs distribute VPN-IPv4 routes via MP-BGP. You must configure the VRF to redistribute the OSPF routes into MP-BGP. MP-BGP converts each imported OSPF route to a VPN-IPv4 route, applies export policy to the route, and then propagates the route to a remote PE site via the MPLS/VPN backbone. At the destination PE, MPBGP places each route in the appropriate VRF forwarding table based on the import policy for each VRF and the route target associated with the route.

Preserving OSPF Routing Information Across the MPLS/VPN Backbone

MP-BGP attaches two new extended community attributes to the routes redistributed from OSPF: OSPF domain identifier extended community attribute OSPF route type extended community attribute

MP-BGP uses these attributes and the MED to preserve OSPF routing information across the BGP/MPLS VPN backbone.

OSPF Domain Identifier Attribute

The OSPF domain identifier attribute uniquely identifies the OSPF domain from which a route was redistributed into MP-BGP. You must configure an OSPF domain ID for the VRFs on the PE with the domain-id command. All VRFs that belong to a given OSPF domain must be configured with the same domain ID. If not configured, the domain ID defaults to zero. If you configure a value of zero, MP-BGP does not attach an OSPF domain identifier attribute.

If the OSPF domain ID for the destination PE differs from the originating PE, MP-BGP redistributes the route into OSPF as an OSPF type 5 external route.

OSPF Route Type Attribute

The route type attribute carries the OSPF area ID and LSA type: Type of route 1 - intra-area route 2 - intra-area route 3 - interarea summary route Origin of route Type 1 LSA Type 2 LSA Type 3 LSA

5 - external route (area ID = 0) Type 5 LSA 7 - external route (area ID = 0) Type 7 LSA

MP-BGP uses the route type conveyed by this extended community attribute to determine the best OSPF route when it installs the routes in the VRF forwarding table on the destination PE.

Distributing OSPF Routes from PE to CE

At the remote PE site, MP-BGP converts the OSPF routes to BGP VPN-IPv4 routes and sends them across the BGP/MPLS VPN backbone. At the destination PE, MP-BGP must redistribute the BGP VPNIPv4 routes back into OSPF IPv4 routes. The PE OSPF router becomes the originator of the routes, which are either type 5 external routes or type 3 internal routes. The PE can announce the OSPF routes to the appropriate CE router via its directly connected PE-CE OSPF link. If the route has a route type of inter or intra, it is redistributed as a type 3 summary interarea route and the destination PE router generates a type 3 LSA for it. A route is redistributed as an external route if the route: Originates in an OSPF domain that is different from that of the destination PE router. Has a route type of 5 or 7, both of which indicate an external route. In the first case, the PE advertises the route as an external type 2 route. In the second case, the PE advertises the route as an external type 2 route if the least-significant bit is set in the option byte in the route type extended community attribute; otherwise the PE advertises the route as external type 1 route.

Preventing Routing Loops

PE routes ignore OSPF routes received from a CE if the routes are advertised by: A type 3 LSA with the most-significant bit set in the LSA options field.

 A type 5 LSA that has a tag value equal to the VPN route tag associated with the OSPF VRF on that PE. When the destination PE router originates a type 3 LSA learned from BGP to a CE, the PE sets the mostsignificant bit in the LSA options field to identify the LSA as being generated from a PE. This prevents the LSA from being passed back to the BGP/MPLS VPN through a different PE. When the destination PE router originates a type 5 LSA learned from BGP to a CE, the PE replaces the external route tag in the LSA with the VPN route tag. You configure the VPN route tag for the OPSF VRF on the PE with the domain-tag command. The value of a VPN route tag must be unique within an OSPF domain, so that the same external route is not propagated back to the BGP/MPLS VPN backbone through another PE-CE link.

Configuration Tasks
At a minimum, perform the following tasks on each PE to configure them for OSPF. For other OSPF configuration tasks, see ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 7, Configuring OSPF. 1. Create the VRF.

host1(config)#ip vrf ospf2 Proceed with new VRF creation? [confirm] host1(config-vrf)#rd 100:85 host1(config-vrf)#exit 1. Start OSPF on the VRF, either from the parent VR or directly from the VRF.

From the parent VR: host1(config)#router ospf 5 vrf ospf2 From the VRF: host1(config)#virtual-router :ospf2 host1:default:ospf2(config)#router ospf 5 The command prompts in the remaining steps reflect using the latter method for starting OSPF. 1. Configure the OSPF domain ID.

host1:default:ospf2(config-router)#domain-id 45 1. Configure the VPN route tag.

host1:default:ospf2(config-router)#domain-tag 1200 1. Redistribute routes learned from other PEs back into OSPF.

host1:default:ospf2(config-router)#redistribute bgp

1.

Create an address family in BGP.

host1:default(config)#router bgp 100 host1:default(config-router)#address-family ipv4 unicast vrf ospf2 1. Redistribute OSPF routes into BGP.

host1:default(config-router)#redistribute ospf

domain-id
Use to set the OSPF domain ID for an OSPF VRF on a PE router; the default value is zero. Use the same domain ID for all OSPF VRFs in a given OSPF domain. When the value is zero, MP-BGP does not attach an OSPF domain identifier attribute when it converts an OSPF route to an MP-BGP route to cross the BGP/MPLS VPN. Example host1:default:ospf2(config-router)#domain-id 45 Use the no version to restore the default value.

domain-tag
Use to set the VPN route tag for an OSPF VRF on a PE router. The default value is a 32-bit number based on the AS number of the BGP/MPLS VPN backbone, with the first 16 bits set to 1110 0000 0000 0000, followed by the 16 bits representing the AS number. Example host1:default:ospf2(config-router)#domain-tag 1200 Use the no version to restore the default value.

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback

[Contents] [Prev] [Next] [Index] [Report an Error]

Monitoring BGP/MPLS VPNs

To view BGP/MPLS VPN settings, you can issue the following show commands as well as any of the show ip bgp commands described in Chapter 1, Configuring BGP Routing. Refer to Chapter 2, Configuring MPLS, for information on show commands to monitor MPLS settings. Use the debug ip mbgp command to get information on problems with BGP or the network.

debug ip mbgp
Use to display information on MP-BGP logs for inbound or outbound events, or both. Example host1#debug ip mbgp There is no no version, but you can use the undebug ip mbgp command to disable display of information previously enabled with the debug ip mbgp command.

show ip bgp next-hops

Use to display information about BGP next hops. Specify all VRFs or a particular VRF, and all indirect next hops or a particular indirect next hop. Field descriptions Indirect next-hop - BGP next-hop attribute as received in the BGP update message MPLS stacked label - MPLS label as received in the MP-Reach-NLRI attribute in the BGP update message; shown only for VPN routes Reachable - indicates whether or not the indirect next-hop is reachable. For nonVPN routes, the indirect next-hop is reachable if it is resolved by a route in the IP forwarding table. For VPN routes, the indirect next-hop is reachable if an MPLS base tunnel to the indirect next-hop exists and MPLS successfully created a stacked tunnel on top of that base tunnel using the MPLS stacked label. Direct next-hop - interface and next-hop IP address which resolve the indirect next-hop Reference count - number of routes using this next-hop Example

host1:pe1#show ip bgp vpnv4 vrf pe11 next-hops Indirect next-hop 2.2.2.2 MPLS stacked label 19 Reachable Direct next-hop tun mpls:vpnInL19-18 Reference count is 1

Indirect next-hop 11.11.11.2 Reachable (metric 1) Direct next-hop atm2/0.11 (11.11.11.2) Reference count is 1

show ip interface vrf

Use to display information about the interfaces associated with the specified VRF. Field descriptions

 interface - interface type and interface specifier interface status - status of the interface line protocol - status of the line protocol Link up/down trap - status of SNMP link up/down traps on the interface Internet address - IP address of the interface Operational MTU - actual MTU for the interface Administrative MTU - configured MTU for the interface Operational speed - actual speed Administrative speed - configured speed Discontinuity Time - value of sysUpTime the last time the integrity of the interface statistics was compromised Router advertisement - whether routes are advertised; enabled or disabled Administrative debounce-time - whether the up/down state of the interface will be debounced or damped if a link periodically fails and immediately comes back; the time delay (configured in Interface Configuration mode) that an interface must remain in a new state before the routing protocols react to the state change Operational debounce-time - whether the up/down state of the interface will debounced or "damped" if a link periodically fails and immediately comes back; the time delay that an interface must remain in a new state before the routing protocols react to the state change; the time delay (configured in Interface Configuration mode or Global Configuration mode) that an interface must remain in a new state before the routing protocols react to the state change Access routing - when enabled, an access route is installed to the host on the other end of the interface Multipath mode - algorithm used for ECMP, DA/SA hashing or round-robin In Received Packets, Bytes - total packets and bytes received on an IP interface Unicast - unicast packets and bytes received on an IP interface Multicast - multicast packets and bytes received on an IP interface In Policed Packets - packets discarded on a receive IP interface because of token bucket limiting In Error Packets - packets discarded on a receive IP interface because of IP header errors In Invalid Source Address Packets - packets discarded on a receive IP interface because of invalid IP source address (sa-validate enabled) Out Forwarded Packets, Bytes - packets and bytes forwarded out an IP interface Unicast - unicast packets and bytes forwarded out an IP interface Multicast - multicast packets and bytes forwarded out an IP interface Out Scheduler Drops Committed Packets - committed packets dropped because of out queue threshold limit Out Scheduler Drops Conformed Packets - conformed packets dropped because of out queue threshold limit Out Scheduler Drops Exceeded Packets - exceeded packets dropped because of out queue threshold limit Out Policed Packets - packets discarded on a forwarding IP interface because of token bucket limiting Example

host1#show ip interface vrf vpn1 null0 is up, line protocol is up Network Protocols: IP Internet address is 255.255.255.255/255.255.255.255 Broadcast address is 255.255.255.255 Operational MTU = 1500 Administrative MTU = 0 Operational speed = 100000000 Administrative speed = 0 Discontinuity Time = 0 Router advertisement = disabled Administrative debounce-time = disabled Operational debounce-time = disabled Access routing = disabled Multipath mode = hashed atm4/0.77 is up, line protocol is up Network Protocols: IP Internet address is 7.8.7.7/255.255.255.0 Broadcast address is 255.255.255.255 Operational MTU = 9180 Administrative MTU = 0 Operational speed = 155520000 Administrative speed = 0 Discontinuity Time = 0 Router advertisement = disabled Administrative debounce-time = disabled Operational debounce-time = disabled Access routing = disabled Multipath mode = hashed In Received Packets 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Packets 0, Bytes 0 In Policed Packets 0, Bytes 0 In Error Packets 0 In Invalid Source Address Packets 0 Out Forwarded Packets 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Packets 0, Bytes 0 Out Scheduler Drops Committed Packets 0, Bytes 0 Out Scheduler Drops Conformed Packets 0, Bytes 0 Out Scheduler Drops Exceeded Packets 0, Bytes 0 Out Policed Packets 0, Bytes 0 host1#show ip interface vrf vpn1 brief Interface IP-Address Status Protocol Description null0 255.255.255.255 up up atm4/0.77 7.8.7.7 up up

show ip protocols
Use to display information about the routing protocols associated with the VRF. You must specify the name of the VRF for which the protocols are displayed; otherwise, the command displays all protocols configured on the system Field descriptions

For BGP: Redistributing - protocol to which BGP is redistributing routes Default local preference - local preference value IGP synchronization - status of IGP synchronization: enabled, disabled Always compare MED - status of multiexit discrimination: enabled, disabled Router flap damping - status of route dampening: enabled, disabled Administrative Distance - external, internal, and local administrative distances Neighbor Address - the IP address of the BGP neighbor Neighbor Incoming/Outgoing update distribute list - number of the access list for outgoing routes Neighbor Incoming/Outgoing update prefix list - number of the prefix list for incoming or outgoing routes Neighbor Incoming/Outgoing update prefix tree - number of the prefix tree for incoming or outgoing routes Neighbor Incoming/Outgoing update filter list - number of filter list for incoming routes Routing for Networks - the network for which BGP is currently injecting routes

For IS-IS: System Id - 6-byte value of the system IS-Type - routing type of the router: Level 1, Level 2 Distance - administrative distance for IS-IS learned routes Address Summarization - aggregate addresses defined in the routing table for multiple groups of addresses at a given level or routes learned from other routing protocols Routing for Networks - network for which IS-IS is currently injecting routes

For OSPF: Router ID - OSPF process ID for the router Distance - administrative distance for OSPF learned routes Redistributing - protocol to which OSPF is redistributing routes Address Summarization - aggregate addresses defined in the routing table for multiple groups of addresses at a given level or routes learned form other routing protocols Routing for Networks - network for which OSPF is currently injecting routes

For RIP: Router Administrative State - RIP protocol state. Enable means it is allowed to send and receive updates. Disable means that it may be configured but it is not allowed to run yet. System Version - RIP versions allowed for sending and receiving RIP updates. The system version is currently set to RIP1, which sends RIP version 1 but will receive version 1 or 2. If the version is set to RIP2, the system will send and receive version 2 only. The default is configured for RIP1. Update interval - current setting of the update timer (in seconds) Invalid after - current setting of the invalid timer (in seconds) hold down time - current setting of the hold down timer (in seconds) flushed interval - current setting of the flush timer (in seconds)

 Filter applied to outgoing route update - access list applied to outgoing RIP route updates Filter applied to incoming route update - access list applied to incoming RIP route updates Global route map - route map that specifies all RIP interfaces on the system Distance - value added to RIP routes added to the IP routing table. The default is 120. Interface - interface type on which RIP protocol is running Redistributing - protocol to which RIP is redistributing routes Routing for Networks - network for which RIP is currently injecting routes Example

host1:pe1#show ip protocols vrf pe13 Routing Protocol is "ospf 1" with Router ID 13.13.13.1 Distance is 110 Redistributing: bgp Address Summarization: None Routing for Networks: 13.13.13.0/255.255.255.0 area 0.0.0.0

show ip route vrf

Use to display the routing table of the specified VRF. Field descriptions Protocol/Route type codes - type of route Prefix/Length - network prefix for route in VRF routing table Type - protocol of route Next Hop - IP address of the next hop to reach route Dist/Met - administrative distance and metric applied to route Intf - outgoing interface to reach route Example

host1#show ip route vrf vpn2 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 --------------45.5.5.5/32 56.5.5.0/24 Type ------Connect Connect Next Hop ---------45.5.5.5 56.5.5.5 Dist/Met -------0/1 0/1 Intf -----------fastEthernet3/0 atm4/0.21

show ip vrf

 Use to display brief information about the VRFs in this virtual router: the route target of each VRF and the interfaces attached to each VRF. Specify the VRF name to display the brief information only about that VRF. You must be within the context of the virtual router to which the VRF belongs. Field descriptions VRF Name - name of each VRF Default RD - default route distinguisher for the VRF Interfaces - interfaces configured for the VRF Examples:

host1#show ip vrf VRF Name Default RD vpn1 1:1 vpn2 1:3

Interfaces null0 atm4/0.77 null0 fastEthernet3/0 atm4/0.21 Interfaces null0 atm4/0.77

host1#show ip vrf vpn1 VRF Name Default RD vpn1 1:1

show ip vrf detail

Use to display detailed information about the VRFs in this virtual router. Specify the VRF name to display the brief information only about that VRF. You must be within the context of the virtual router to which the VRF belongs. Field descriptions VRF - name of the VRF Default RD - default route distinguisher for the VRF VRF IP Router ID - IP address that uniquely identifies the router Default TTL - time to live value in the IP header Reassemble Timeout - value to time out reassembled packets Interface Configured - interface configured for the VRF Import VPN Route Target Extended Communities - list of VPNs from which the VRF accepts routing information Export VPN Route Target Extended Communities - list of VPNs to which the VRF sends update messages Import Route-map - route map associated with the VRF that filters routes received by the VRF Export Route-map - route map associated with the VRF that filters routes forwarded by the VRF Example

host1#show ip vrf detail VRF vpn1; Default RD 1:1 VRF IP Router ID 10.1.1.1

Default TTL: 127 Reassemble Timeout: 30 Interface Configured: null0 atm4/0.77 Import VPN Route Target Extended Communities: 1:2 Export VPN Route Target Extended Communities: 1:1 1:2 Import Route-map : map2 Export Route-map : map1 VRF vpn2; Default RD 1:3 Interface Configured: null0 fastEthernet3/0 atm4/0.21 Import VPN Route Target Extended Communities: 3:3 10.4.3.0:1 Export VPN Route Target Extended Communities: 10.4.3.0:1 Import Route-map : map2 No Export Route-map

show ip vrf interfaces

Use to display summary information about all interfaces associated with all VRFs configured in a virtual router. Use the detail keyword to display detailed information about the interfaces. Field descriptions Interface - interface type and interface specifier IP-Address - IP address of the interface Status - status of the interface Protocol - status of the line protocol VRF - name of the VRF with which the interface is associated interface status - status of the interface line protocol - status of the line protocol Link up/down trap - status of SNMP link up/down traps on the interface Internet address - IP address of the interface IP Statistics Rcvd: local destination - frames with this router as their destination hdr errors - number of packets containing header errors addr errors - number of packets containing addressing errors unkn proto - number of packets received containing unknown protocols discards - number of discarded packets IP Statistics Frags: reasm ok - number of reassembled packets reasm req - number of requests for reassembly reasm fails - number of reassembly failures frag ok - number of packets fragmented successfully frag creates - number of frames requiring fragmentation

 frag fails - number of packets unsuccessfully fragmented IP Statistics Sent: generated - number of packets generated no routes - number of packets that could not be routed discards - number of packets that could not be routed that were discarded ICMP Statistics Rcvd: errors - number of error packets received dst unreach - number of packets received with destination unreachable time exceed - number of packets received with time-to-live exceeded param probs - number of packets received with parameter errors src quench - number of source quench packets received redirect - number of receive packet redirects echo req - number of echo request (PING) packets echo rpy - number of echo replies received timestamp req - number of requests for a timestamp timestamp rpy - number of replies to timestamp requests addr mask req - number of address mask requests addr mask rpy - number of address mask replies ICMP Statistics Sent: errors - number of error packets sent dst unreach - number of packets sent with destination unreachable time excd - number of packets sent with time-to-live exceeded param probs - number of packets sent with parameter errors src quench - number of source quench packets sent redirect - number of send packet redirects timestamp req - number of requests for a timestamp timestamp rpy - number of replies to timestamp requests addr mask req - number of address mask requests addr mask rpy - number of address mask replies In Received Packets, Bytes - total packets and bytes received on an IP interface Unicast - unicast packets and bytes received on an IP interface Multicast - multicast packets and bytes received on an IP interface In Forwarded Packets, Bytes - packets and bytes forwarded into an output IP interface In Total Dropped Packets, Bytes - total packets and bytes discarded on a receive IP interface In Policed Packets - packets discarded on a receive IP interface because of token bucket limiting In Invalid Source Address Packets - packets discarded on a receive IP interface because of invalid IP source address (sa-validate enabled) In Error Packets - packets discarded on a receive IP interface because of IP header errors

 In Discarded Packets - packets discarded on the ingress interface because of a configuration problem rather than a problem with the packet itself In Fabric Dropped Packets - packets discarded on a receive IP interface because of internal fabric congestion Out Forwarded Packets, Bytes - packets and bytes forwarded out an IP interface Unicast - unicast packets and bytes forwarded out an IP interface Multicast - multicast packets and bytes forwarded out an IP interface Out Requested Packets, Bytes - packets and bytes requested to be forwarded out an IP interface Out Total Dropped Packets, Bytes - total packets and bytes dropped by an IP interface on output Out Scheduler Drops Committed Packets, Bytes - committed packets and bytes dropped because of out queue threshold limit Out Scheduler Drops Conformed Packets, Bytes - conformed packets and bytes dropped because of out queue threshold limit Out Scheduler Drops Exceeded Packets, Bytes - exceeded packets and bytes dropped because of out queue threshold limit Out Policed Packets - packets discarded on the egress interface because of token bucket limiting Out Discarded Packets - packets discarded on the egress interface because of a configuration problem rather than a problem with the packet itself Out Fabric Dropped Packets - packets dropped because of internal fabric congestion Example

host1:PE1#show ip vrf interfaces Interface IP-Address Status Protocol null0 255.255.255.255/32 up up atm4/0.134 4.4.4.2/24 up up null0 255.255.255.255/32 up up ip0 6.6.6.8/24 up up null0 255.255.255.255/32 up up loopback1 7.7.7.2/24 up up host1:PE1#show ip vrf interfaces detail null0 is up, line protocol is up VRF: pe11 Link up/down trap is disabled Internet address is 255.255.255.255/255.255.255.255 IP statistics: Rcvd: 0 local destination 0 hdr errors, 0 addr errors 0 unkn proto, 0 discards Frags: 0 reasm ok, 0 reasm req, 0 reasm fails 0 frag ok, 0 frag creates, 0 frag fails Sent: 0 generated, 0 no routes, 0 discards ICMP statistics: Rcvd: 0 errors, 0 dst unreach, 0 time exceed

VRF pe11 pe11 pe12 pe12 pe13 pe13

Sent:

0 0 0 0 0 0 0 0

param probs, 0 src quench, 0 redirect, echo req, 0 echo rpy timestmp req, 0 timestmp rpy addr mask req, 0 addr mask rpy errors, 0 dst unreach, 0 time excd param probs, 0 src qnch, 0 redirect timestamp req, 0 timestamp rpy addr mask req, 0 addr mask rpy

atm4/0.134 is up, line protocol is up VRF: pe11 Link up/down trap is disabled Internet address is 4.4.4.2/255.255.255.0 IP statistics: Rcvd: 0 local destination 0 hdr errors, 0 addr errors 0 unkn proto, 0 discards Frags: 0 reasm ok, 0 reasm req, 0 reasm fails 0 frag ok, 0 frag creates, 0 frag fails Sent: 0 generated, 0 no routes, 0 discards ICMP statistics: Rcvd: 0 errors, 0 dst unreach, 0 time exceed 0 param probs, 0 src quench, 0 redirect, 0 echo req, 0 echo rpy 0 timestmp req, 0 timestmp rpy 0 addr mask req, 0 addr mask rpy Sent: 0 errors, 0 dst unreach, 0 time excd 0 param probs, 0 src qnch, 0 redirect 0 timestamp req, 0 timestamp rpy 0 addr mask req, 0 addr mask rpy In Received Packets 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Packets 0, Bytes 0 In Forwarded Packets 0, Bytes 0 In Total Dropped Packets 0, Bytes 0 In Policed Packets 0 In Invalid Source Address Packets 0 In Error Packets 0 In Discarded Packets 0 In Fabric Dropped Packets 0 Out Forwarded Packets 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Packets 0, Bytes 0 Out Requested Packets 0, Bytes 0 Out Total Dropped Packets 0, Bytes 0 Out Scheduler Drops Committed Packets 0, Bytes 0 Out Scheduler Drops Conformed Packets 0, Bytes 0 Out Scheduler Drops Exceeded Packets 0, Bytes 0 Out Policed Packets 0

Out Discarded Packets 0 Out Fabric Dropped Packets 0

show mpls tunnels

Use to display status and configuration for all tunnels or for a specific tunnel in the current router context. A result of Incomplete Configuration in the display indicates either no tunnel endpoint or no label distribution protocol. Field descriptions State - status of tunnel, up or down Out Label - in the default case for a BGP/MPLS VPN, this will be Variable Interface, which indicates that a packet exiting the interface is going through a variable interface and that one of the labels listed further in the display will be prepended to the packet Mpls Statistics pkts - number of packets sent across tunnel hcpkts - number of high-capacity (64-bit) packets sent across tunnel octets - number of octets sent across tunnel hcoctets - number of high-capacity (64-bit) octets sent across tunnel errors - number of packets that are dropped for some reason before being sent discardPkts - number of packets that are discarded due to lack of buffer space before being sent Labels - list of labels associated with the variable interface; one will be selected to be prepended to packets before being sent across tunnel Examples

The output varies between the default behaviorwhen the system creates a VPN interface per next-hop PEand the behavior resulting when you issue the ip mpls vpn-interface perlabel commandwhen the system creates a VPN interface for each received stacked label. VPN interface per next-hop PE: host12#show mpls tunnels LSP vpnIngress-21 to 3.3.3.3 State: Up Out label is Variable Interface 102 pkts, 0 hcPkts, 13464 octets 0 hcOctets, 0 errors, 0 discardPkts Labels: 16 17 18 19 VPN interface per received stacked label: host12#show mpls tunnels

LSP vpnInL16-21 to 3.3.3.3 State: Up Out label is 16 on Label 33 102 pkts, 0 hcPkts, 13464 octets 0 hcOctets, 0 errors, 0 discardPkts LSP vpnInL17-21 to 3.3.3.3 State: Up Out label is 17 on Label 33 102 pkts, 0 hcPkts, 13464 octets 0 hcOctets, 0 errors, 0 discardPkts LSP vpnInL18-21 to 3.3.3.3 State: Up Out label is 18 on Label 33 102 pkts, 0 hcPkts, 13464 octets 0 hcOctets, 0 errors, 0 discardPkts LSP vpnInL19-21 to 3.3.3.3 State: Up Out label is 19 on Label 33 102 pkts, 0 hcPkts, 13464 octets 0 hcOctets, 0 errors, 0 discardPkts

undebug ip mbgp
Use to disable the display of information on MP-BGP logs that was previously enabled with the debug ip mbgp command. Example host1#undebug ip mbgp There is no no version.

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright 1998-2005, Juniper Networks, Inc. All Rights Reserved. Trademark Notice. Privacy. home | contact us | search | feedback