Cisco IOS IP Routing: BGP Command Reference

neighbor timers

To set the timers for a specific BGP peer or peer group, use the neighbor timers command in address family or router configuration mode. To clear the timers for a specific BGP peer or peer group, use the no form of this command.

neighbor [ip-address | peer-group-name] timers keepalive holdtime [min-holdtime]

no neighbor [ip-address | peer-group-name] timers

Syntax Description

Defaults

keepalive: 60 seconds
holdtime: 180 seconds

Command Modes

Address family configuration (config-router-af)
Router configuration (config-router)

Command History

Usage Guidelines

The timers configured for a specific neighbor or peer group override the timers configured for all BGP neighbors using the timers bgp command.

When configuring the holdtime argument for a value of less than twenty seconds, the following warning is displayed:

% Warning: A hold time of less than 20 seconds increases the chances of peer flapping

If the minimum acceptable hold-time interval is greater than the specified hold-time, a notification is displayed:

% Minimum acceptable hold time should be less than or equal to the configured hold time 

Note When the minimum acceptable hold-time is configured on a BGP router, a remote BGP peer session is established only if the remote peer is advertising a hold-time that is equal to, or greater than, the minimum acceptable hold-time interval. If the minimum acceptable hold-time interval is greater than the configured hold-time, the next time the remote session tries to establish, it will fail and the local router will send a notification stating "unacceptable hold time."

Examples

The following example changes the keepalive timer to 70 seconds and the hold-time timer to 210 seconds for the BGP peer 192.168.47.0:

router bgp 109 
 neighbor 192.168.47.0 timers 70 210

The following example changes the keepalive timer to 70 seconds, the hold-time timer to 130 seconds, and the minimum hold-time interval to 100 seconds for the BGP peer 192.168.1.2:

router bgp 45000

 neighbor 192.168.1.2 timers 70 130 100

neighbor transport

To enable a TCP transport session option for a Border Gateway Protocol (BGP) session, use the neighbor transport command in router or address family configuration mode. To disable a TCP transport session option for a BGP session, use the no form of this command.

neighbor {ip-address | peer-group-name} transport {connection-mode {active | passive} | path-mtu-discovery [disable] | multi-session | single-session}

no neighbor {ip-address | peer-group-name} transport {connection-mode | path-mtu-discovery | multi-session | single-session}

Syntax Description

Command Default

If this command is not configured, TCP path MTU discovery is enabled by default, but no other TCP transport session options are enabled.

Command Modes

Router configuration (config-router)
Address family configuration (config-router-af)

Command History

Usage Guidelines

This command is used to specify various transport options. An active or passive transport connection can be specified for a BGP session. TCP transport path MTU discovery can be enabled to allow a BGP session to take advantage of larger MTU links. Use the show ip bgp neighbors command to determine whether TCP path MTU discovery is enabled.

In Cisco IOS Release 12.2(33)SRB and later releases, options can be specified for the transport of address family traffic using a single TCP session or to enable a separate TCP session for each address family. Multiple TCP sessions are used to support Multi-Topology Routing (MTR), and the single session option is available for backwards compatibility for non-MTR configurations and for scalability purposes.

In Cisco IOS Release 12.2(33)SRB and later releases, the ability to disable TCP path MTU discovery, for a single neighbor or for an inheriting peer or peer group, was added. If you use the disable keyword to disable discovery, discovery is also disabled on any peer or peer group that inherits the template in which you disabled discovery.

The following example shows how to configure the TCP transport connection to be active for a single internal BGP (iBGP) neighbor:

router bgp 45000

 neighbor 172.16.1.2 remote-as 45000

 neighbor 172.16.1.2 activate

 neighbor 172.16.1.2 transport connection-mode active

 end

The following example shows how to configure the TCP transport connection to be passive for a single external BGP (eBGP) neighbor:

router bgp 45000

 neighbor 192.168.1.2 remote-as 40000

 neighbor 192.168.1.2 activate

 neighbor 192.168.1.2 transport connection-mode passive

 end

The following example shows how to disable TCP path MTU discovery for a single BGP neighbor:

router bgp 45000

 neighbor 172.16.1.2 remote-as 45000

 neighbor 172.16.1.2 activate

 no neighbor 172.16.1.2 transport path-mtu-discovery

 end

The following example shows how to reenable TCP path MTU discovery for a single BGP neighbor, if TCP path MTU discovery is disabled:

router bgp 45000

 neighbor 172.16.1.2 remote-as 45000

 neighbor 172.16.1.2 activate

 neighbor 172.16.1.2 transport path-mtu-discovery

 end

The following example shows how to enable a separate TCP session for each address family for an MTR topology configuration:

router bgp 45000

 scope global

  neighbor 172.16.1.2 remote-as 45000

  neighbor 172.16.1.2 transport multi-session

  address-family ipv4

   topology VIDEO 

   bgp tid 100

   neighbor 172.16.1.2 activate

   end

The following example shows how to disable TCP path MTU discovery and verify that it is disabled:

router bgp 100

 bgp log-neighbor-changes

 timers bgp 0 0

 redistribute static

 neighbor 10.4.4.4 remote-as 100

 neighbor 10.4.4.4 update-source Loopback 0

!end

Router# show ip bgp neighbors 10.4.4.4 | include path

    Used as bestpath:             n/a          0

    Used as multipath:            n/a          0

  Transport(tcp) path-mtu-discovery is enabled 

Option Flags: nagle, path mtu capable

Router#

Router# configure terminal

Router(config)# router bgp 100

Router(config-router)# neighbors 10.4.4.4 transport path-mtu-discovery disable 

Router(config-router)# end

Router# show ip bgp neighbor 10.4.4.4 | include path

    Used as bestpath:             n/a          0

    Used as multipath:            n/a          0

  Transport(tcp) path-mtu-discovery is disabled 

Related Commands

neighbor ttl-security

To secure a Border Gateway Protocol (BGP) peering session and to configure the maximum number of hops that separate two external BGP (eBGP) peers, use the neighbor ttl-security command in address-family or router configuration mode. To disable this feature, use the no form of this command.

neighbor neighbor-address ttl-security hops hop-count

no neighbor neighbor-address ttl-security hops hop-count

Syntax Description

Defaults

No default behavior or values

Command Modes

Address-family configuration
Router configuration

Command History

Usage Guidelines

The neighbor ttl-security command provides a lightweight security mechanism to protect BGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to disable the network by flooding the network with IP packets that contain forged source and destination IP addresses in the packet headers.

This feature leverages designed behavior of IP packets by accepting only IP packets with a TTL count that is equal to or greater than the locally configured value. Accurately forging the TTL count in an IP packet is generally considered to be impossible. Accurately forging a packet to match the TTL count from a trusted peer is not possible without internal access to the source or destination network.

This feature should be configured on each participating router. It secures the BGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router. When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. This feature has no effect on the BGP peering session, and the peering session can still expire if keepalive packets are not received. If the TTL value in a received packet is less than the locally configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. This is designed behavior; a response to a forged packet is not necessary.

To maximize the effectiveness of this feature, the hop-count value should be strictly configured to match the number of hops between the local and external network. However, you should also take path variation into account when configuring this feature for a multihop peering session.

The following restrictions apply to the configuration of this command:

•This feature is not supported for internal BGP (iBGP) peers or iBGP peer groups.

•The neighbor ttl-security command cannot be configured for a peer that is already configured with the neighbor ebgp-multihop command. The configuration of these commands is mutually exclusive, and only one of these commands is needed to enable a multihop eBGP peering session. An error message will be displayed in the console if you attempt to configure both commands for the same peering session.

•The effectiveness of this feature is reduced in large-diameter multihop peerings. In the event of a CPU utilization-based attack against a BGP router that is configured for large-diameter peering, you may still need to shut down the affected peering sessions to handle the attack.

•This feature is not effective against attacks from a peer that has been compromised inside of your network. This restriction also includes peers that are on the network segment between the source and destination network.

Examples

The following example sets the hop count to 2 for a directly connected neighbor. Because the hop-count argument is set to 2, BGP will accept only IP packets with a TTL count in the header that is equal to or greater than 253. If a packet is received with any other TTL value in the IP packet header, the packet will be silently discarded.

neighbor 10.0.0.1 ttl-security hops 2

Related Commands

neighbor unsuppress-map

To selectively advertise routes previously suppressed by the aggregate-address command, use the neighbor unsuppress-map command in address family or router configuration mode. To restore the system to the default condition, use the no form of this command.

neighbor {ip-address | peer-group-name} unsuppress-map route-map-name

no neighbor {ip-address | peer-group-name} unsuppress-map route-map-name

Syntax Description

Command Default

No routes are unsuppressed.

Command Modes

Address family configuration
Router configuration

Command History

Usage Guidelines

Use of the neighbor unsuppress-map command allows specified suppressed routes to be advertised.

Examples

The following BGP router configuration shows that routes specified by a route map named map1 are suppressed:

access-list 3 deny 172.16.16.6

access-list 3 permit any

route-map map1 permit 10

match ip address 3

!

router bgp 65000 

network 172.16.0.0

neighbor 192.168.1.2 remote-as 40000

aggregate-address 172.0.0.0 255.0.0.0 suppress-map map1

neighbor 192.168.1.2 unsuppress-map map1

neighbor 192.168.1.2 activate

The following example shows the routes specified by internal-map being unsuppressed for neighbor 172.16.16.6:

router bgp 100

address-family ipv4 multicast

 network 172.16.0.0

 neighbor 172.16.16.6 unsuppress-map internal-map

Related Commands

neighbor update-source

To have the Cisco IOS software allow Border Gateway Protocol (BGP) sessions to use any operational interface for TCP connections, use the neighbor update-source command in router configuration mode. To restore the interface assignment to the closest interface, which is called the best local address, use the no form of this command.

neighbor {ip-address | ipv6-address[%] | peer-group-name} update-source interface-type interface-number

no neighbor {ip-address | ipv6-address[%] | peer-group-name} update-source interface-type interface-number

Syntax Description

Command Default

Best local address

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

This command can work in conjunction with the loopback interface feature described in the "Interface Configuration Overview" chapter of the Cisco IOS Interface and Hardware Component Configuration Guide.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.

The neighbor update-source command must be used to enable IPv6 link-local peering for internal or external BGP sessions.

The % keyword is used whenever link-local IPv6 addresses are used outside the context of their interfaces and for these link-local IPv6 addresses you must specify the interface they are on. The syntax becomes <IPv6 local-link address>%<interface name>, for example, FE80::1%Ethernet1/0. Note that the interface type and number must not contain any spaces, and be used in full-length form because name shortening is not supported in this situation. The % keyword and subsequent interface syntax is not used for non-link-local IPv6 addresses.

Examples

The following example sources BGP TCP connections for the specified neighbor with the IP address of the loopback interface rather than the best local address:

router bgp 65000

 network 172.16.0.0

 neighbor 172.16.2.3 remote-as 110

 neighbor 172.16.2.3 update-source Loopback0

The following example sources IPv6 BGP TCP connections for the specified neighbor in autonomous system 65000 with the global IPv6 address of loopback interface 0 and the specified neighbor in autonomous system 65400 with the link-local IPv6 address of Fast Ethernet interface 0/0. Note that the link-local IPv6 address of FE80::2 is on Ethernet interface 1/0.

router bgp 65000

 neighbor 3ffe::3 remote-as 65000 

 neighbor 3ffe::3 update-source Loopback0 

 neighbor fe80::2%Ethernet1/0 remote-as 65400 

 neighbor fe80::2%Ethernet1/0 update-source FastEthernet 0/0 

 address-family ipv6 

  neighbor 3ffe::3 activate 

  neighbor fe80::2%Ethernet1/0 activate 

  exit-address-family 

Related Commands

neighbor version

To configure the Cisco IOS software to accept only a particular BGP version, use the neighbor version command in router configuration mode. To use the default version level of a neighbor, use the no form of this command.

neighbor {ip-address | peer-group-name} version number

no neighbor {ip-address | peer-group-name} version number

Syntax Description

Defaults

BGP Version 4

Command Modes

Router configuration

Command History

Usage Guidelines

Entering this command disables dynamic version negotiation.

Note The Cisco implementation of BGP in Cisco IOS Release 12.0(5)T or earlier releases supports BGP Versions 2, 3, and 4, with dynamic negotiation down to Version 2 if a neighbor does not accept BGP Version 4 (the default version).

The Cisco implementation of BGP in Cisco IOS Release 12.0(6)T or later releases supports BGP Version 4 only and does not support dynamic negotiation down to Version 2.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.

Examples

The following example locks down to Version 4 of the BGP protocol:

router bgp 109 
 neighbor 172.16.27.2 version 4

Related Commands

neighbor weight

To assign a weight to a neighbor connection, use the neighbor weight command in address family or router configuration mode. To remove a weight assignment, use the no form of this command.

neighbor {ip-address | peer-group-name} weight number

no neighbor {ip-address | peer-group-name} weight number

Syntax Description

Defaults

Routes learned through another BGP peer have a default weight of 0 and routes sourced by the local router have a default weight of 32768.

Command Modes

Address family
Router configuration

Command History

Usage Guidelines

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 route-map command override the weights assigned using the neighbor weight command.

Note For weight changes to take effect, use of the clear ip bgp peer-group * command may be necessary.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.

Examples

The following router configuration mode example sets the weight of all routes learned via 172.16.12.1 to 50:

router bgp 109 
 neighbor 172.16.12.1 weight 50

The following address family configuration mode example sets the weight of all routes learned via 172.16.12.1 to 50:

router bgp 109

address-family ipv4 multicast 
 neighbor 172.16.12.1 weight 50

Related Commands

network (BGP and multiprotocol BGP)

To specify the networks to be advertised by the Border Gateway Protocol (BGP) and multiprotocol BGP routing processes, use the network command in address family or router configuration mode. To remove an entry from the routing table, use the no form of this command.

network {network-number [mask network-mask] | nsap-prefix} [route-map map-tag]

no network {network-number [mask network-mask] | nsap-prefix} [route-map map-tag]

Syntax Description

Command Default

No networks are specified.

Command Modes

Address family configuration
Router configuration

Command History

Usage Guidelines

BGP and multiprotocol BGP networks can be learned from connected routes, from dynamic routing, and from static route sources.

The maximum number of network commands you can use is determined by the resources of the router, such as the configured NVRAM or RAM.

Examples

The following example sets up network 10.108.0.0 to be included in the BGP updates:

router bgp 65100

 network 10.108.0.0

The following example sets up network 10.108.0.0 to be included in the multiprotocol BGP updates:

router bgp 64800

address family ipv4 multicast

 network 10.108.0.0

The following example advertises NSAP prefix 49.6001 in the multiprotocol BGP updates:

router bgp 64500

 address-family nsap

  network 49.6001

Related Commands

network backdoor

To specify a backdoor route to a BGP-learned prefix that provides better information about the network, use the network backdoor command in address family or router configuration mode. To remove an address from the list, use the no form of this command.

network ip-address backdoor

no network ip-address backdoor

Syntax Description

Defaults

No network is marked as having a back door.

Command Modes

Address family configuration
Router configuration

Command History

Usage Guidelines

A backdoor network is assigned an administrative distance of 200. The objective is to make Interior Gateway Protocol (IGP) learned routes preferred. A backdoor network is treated as a local network, except that it is not advertised. A network that is marked as a back door is not sourced by the local router, but should be learned from external neighbors. The BGP best path selection algorithm does not change when a network is configured as a back door.

Examples

The following address family configuration example configures network 10.108.0.0 as a local network and network 192.168.7.0 as a backdoor network:

router bgp 109

address-family ipv4 multicast

 network 10.108.0.0

 network 192.168.7.0 backdoor

The following router configuration example configures network 10.108.0.0 as a local network and network 192.168.7.0 as a backdoor network:

router bgp 109

 network 10.108.0.0

 network 192.168.7.0 backdoor

Related Commands

prefix-length-size

To specify the length (in bytes) of the prefix length field of prefixes being advertised to neighbors, use the prefix-length-size command in L2VPN VPLS address-family configuration mode. To restore the default value, use the no form of this command.

prefix-length-size {1|2}

no prefix-length-size

Syntax Description

Command Default

1 byte

Command Modes

L2VPN VPLS address-family configuration (config-router-af)

Command History

Usage Guidelines

You might need to configure this command for interoperability with Juniper's JunOS. If the neighbor is a Juniper JunOS router, change the prefix length size to 2 bytes.

The size of the prefix length field is either 1 or 2 bits or bytes, depending on the address family of the prefix, as follows:

Examples

The following example configures the prefix length size to 2 bytes for L2VPN VPLS prefixes advertised to neighbors:

router bgp 1600

 address-family l2vpn vpls

 prefix-length-size 2

 neighbor 100.16.11.10 activate

 exit-address-family

Related Commands

redistribute (BGP to ISO IS-IS)

To redistribute routes from a Border Gateway Protocol (BGP) autonomous system into an International Organization for Standardization (ISO) Intermediate System-to-Intermediate System (IS-IS) routing process, use the redistribute command in router configuration mode. To remove the redistribute command from the configuration file and restore the system to its default condition where the software does not redistribute routes, use the no form of this command.

redistribute protocol autonomous-system-number [route-type] [route-map map-tag]

no redistribute protocol autonomous-system-number [route-type] [route-map map-tag]

Syntax Description

Command Default

Route redistribution is disabled.

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

The clns keyword must be specified to redistribute NSAP prefix routes from BGP into an ISO IS-IS routing process. This version of the redistribute command is used only under router configuration mode for IS-IS processes.

In redistribution from IGP (for example, ISIS, OSPF, RIP, or EIGRP) to BGP, the support for changing the autonomous system numbers of BGP from one to another is removed.

Examples

The following example configures NSAP prefix routes from BGP autonomous system 64500 to be redistributed into the IS-IS routing process called osi-proc-17:

router isis osi-proc-17

 redistribute bgp 64500 clns

In the following example the autonomous system BGP is modified from 200 to 300, this is not supported.

Router#config terminal

Router(config-if)#router eigrp 101

Router(config-router)#redistribute bgp 200

Router(config-router)#redistribute bgp 300

Cannot configure or redistribute to BGP AS 300

Please do "no router bgp 200" first

Remove support for autonomous system number 200 before configuring number 300.

Router(config)#no router bgp 200

Router(config-router)#redistribute bgp 300

Related Commands

redistribute (IP)

To redistribute routes from one routing domain into another routing domain, use the redistribute command in the appropriate configuration mode. To disable redistribution, use the no form of this command.

redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [autonomous-system-number] [metric {metric-value | transparent}] [metric-type type-value]
[match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets] [nssa-only]

no redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [autonomous-system-number] [metric {metric-value | transparent}] [metric-type type-value]
[match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets] [nssa-only]

Syntax Description

Command Default

Route redistribution is disabled.

Command Modes

Router configuration (config-router)
Address family configuration (config-af)
Address family topology configuration (config-router-af-topology)

Command History

Usage Guidelines

Changing or disabling any keyword will not affect the state of other keywords.

A router receiving a link-state protocol with an internal metric will consider the cost of the route from itself to the redistributing router plus the advertised cost to reach the destination. An external metric only considers the advertised metric to reach the destination.

Routes learned from IP routing protocols can be redistributed at Level 1 into an attached area or at Level 2. The level-1-2 keyword allows both Level 1 and Level 2 routes in a single command.

Redistributed routing information must be filtered by the distribute-list out router configuration command. This guideline ensures that only those routes intended by the administrator are passed along to the receiving routing protocol.

Whenever you use the redistribute or the default-information router configuration commands to redistribute routes into an OSPF routing domain, the router automatically becomes an ASBR. However, an ASBR does not, by default, generate a default route into the OSPF routing domain.

When routes are redistributed into OSPF from protocols other than OSPF or BGP, and no metric has been specified with the metric-type keyword and type-value argument, OSPF will use 20 as the default metric. When routes are redistributed into OSPF from BGP, OSPF will use 1 as the default metric. When routes are redistributed from one OSPF process to another OSPF process, Autonomous system (AS) external and not-so-stubby-area (NSSA) routes will use 20 as the default metric. When intra-area and inter-area routes are redistributed between OSPF processes, the internal OSPF metric from the redistribution source process is advertised as the external metric in the redistribution destination process. (This is the only case in which the routing table metric will be preserved when routes are redistributed into OSPF.)

When routes are redistributed into OSPF, only routes that are not subnetted are redistributed if the subnets keyword is not specified.

On a router internal to an NSSA area, the nssa-only keyword causes the originated type-7 NSSA LSAs to have their propagate (P) bit set to zero, which prevents area border routers from translating these LSAs into type-5 external LSAs. On an area border router that is connected to a NSSA and normal areas, the nssa-only keyword causes the routes to be redistributed only into the NSSA areas.

Routes configured with the connected keyword affected by this redistribute command are the routes not specified by the network router configuration command.

You cannot use the default-metric command to affect the metric used to advertise connected routes.

Note The metric value specified in the redistribute command supersedes the metric value specified using the default-metric command.

Default redistribution of IGPs or EGP into BGP is not allowed unless the default-information originate router configuration command is specified.

Using the no Form of the redistribute Command

Removing options that you have configured for the redistribute command requires careful use of the no form of the redistribute command to ensure that you obtain the result that you are expecting. See the "Examples" section for more information.

Release 12.2(33)SRB

If you plan to configure the Multi-Topology Routing (MTR) feature, you need to enter the redistribute command in router address family topology configuration mode in order for this OSPF router configuration command to become topology-aware.

4-Byte Autonomous System Number Support

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain—65538 for example—as the default regular expression match and output display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC 5396. To change the default regular expression match and output display of 4-byte autonomous system numbers to asdot format, use the bgp asnotation dot command.

In Cisco IOS Release 12.0(32)S12, 12.4(24)T, and Cisco IOS XE Release 2.3, the Cisco implementation of 4-byte autonomous system numbers uses asdot—1.2, for example—as the only configuration format, regular expression match, and output display, with no asplain support.

Examples

The following example shows how OSPF routes are redistributed into a BGP domain:

Router(config)# router bgp 109

Router(config-router)# redistribute ospf

The following example causes EIGRP routes to be redistributed into an OSPF domain:

Router(config)# router ospf 110

Router(config-router)# redistribute eigrp

The following example causes the specified EIGRP process routes to be redistributed into an OSPF domain. The EIGRP-derived metric will be remapped to 100 and RIP routes to 200.

Router(config)# router ospf 109

Router(config-router)# redistribute eigrp 108 metric 100 subnets

Router(config-router)# redistribute rip metric 200 subnets

The following example configures BGP routes to be redistributed into IS-IS. The link-state cost is specified as 5, and the metric type will be set to external, indicating that it has lower priority than internal metrics.

Router(config)# router isis

Router(config-router)# redistribute bgp 120 metric 5 metric-type external

In the following example, network 172.16.0.0 will appear as an external link-state advertisement (LSA) in OSPF 1 with a cost of 100 (the cost is preserved):

Router(config)# interface ethernet 0

Router(config-if)# ip address 172.16.0.1 255.0.0.0

Router(config)# ip ospf cost 100

Router(config)# interface ethernet 1

Router(config-if)# ip address 10.0.0.1 255.0.0.0

!

Router(config)# router ospf 1

Router(config-router)# network 10.0.0.0 0.255.255.255 area 0

Router(config-router)# redistribute ospf 2 subnet

Router(config)# router ospf 2

Router(config-router)# network 172.16.0.0 0.255.255.255 area 0

The following example shows how BGP routes are redistributed into OSPF and assigned the local 4-byte autonomous system number in asplain format. This example requires Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, or a later release.

Router(config)# router ospf 2

Router(config-router)# redistribute bgp 65538

The following example removes the connected metric 1000 subnets options from the redistribute connected metric 1000 subnets command and leaves the redistribute connected command in the configuration:

Router(config-router)# no redistribute connected metric 1000 subnets

The following example removes the metric 1000 options from the redistribute connected metric 1000 subnets command and leaves the redistribute connected subnets command in the configuration:

Router(config-router)# no redistribute connected metric 1000

The following example removes the subnets options from the redistribute connected metric 1000 subnets command and leaves the redistribute connected metric 1000 command in the configuration:

Router(config-router)# no redistribute connected subnets

The following example removes the redistribute connected command, and any of the options that were configured for the redistribute connected command, from the configuration:

Router(config-router)# no redistribute connected

The following example shows how EIGRP routes are redistributed into an EIGRP process in a named EIGRP configuration:

Router(config)# router eigrp virtual-name

Router(config-router)# address-family ipv4 autonomous-system 1

Router(config-router-af)# topology base

Router(config-router-af-topology)# redistribute eigrp 6473 metric 1 1 1 1 1

Related Commands

redistribute (ISO IS-IS to BGP)

To redistribute routes from an International Organization for Standardization (ISO) Intermediate System-to-Intermediate System (IS-IS) routing process into a Border Gateway Protocol (BGP) autonomous system, use the redistribute command in address family or router configuration mode. To remove the redistribute command from the configuration file and restore the system to its default condition where the software does not redistribute routes, use the no form of this command.

redistribute protocol [process-id] [route-type] [route-map [map-tag]]

no redistribute protocol [process-id] [route-type] [route-map [map-tag]]

Syntax Description

Command Default

Route redistribution is disabled.

route-type: ip
route-map map-tag: If the route-map argument is not entered, all routes are redistributed; if no
     map-tag value is entered, no routes are imported.

Command Modes

Address family configuration (Cisco IOS 12.3(8)T and later releases)
Router configuration (T-releases after Cisco IOS 12.3(8)T)

Command History

Usage Guidelines

The clns keyword must be specified to redistribute NSAP prefix routes from an ISO IS-IS routing process into BGP. Beginning with Cisco IOS Release 12.3(8)T, this version of the redistribute command is entered only in address family configuration mode for BGP processes.

Examples

Cisco IOS Releases Prior to Release 12.3(8)T

The following example configures CLNS NSAP routes from the IS-IS routing process called osi-proc-6 to be redistributed into BGP:

Router(config)# router bgp 64352

Router(config-router)# redistribute isis osi-proc-6 clns

Cisco IOS Releases 12.3(8)T and Later Releases

The following example configures CLNS NSAP routes from the IS-IS routing process called osi-proc-15 to be redistributed into BGP:

Router(config)# router bgp 404

Router(config-router)# address-family nsap

Router(config-router-af)# redistribute isis osi-proc-15 clns

Related Commands

redistribute dvmrp

To configure redistribution of Distance Vector Multicast Routing Protocol (DVMRP) routes into multiprotocol BGP, use the redistribute dvmrp command in address family or router configuration mode. To stop such redistribution, use the no form of this command.

redistribute dvmrp [route-map map-name]

no redistribute dvmrp [route-map map-name]

Syntax Description

Defaults

DVMRP routes are not redistributed into multiprotocol BGP.

Command Modes

Address family configuration
Router configuration

Command History

Usage Guidelines

Use this command if you have a subset of DVMRP routes in an autonomous system that you want to take the multiprotocol BGP path. Define a route map to further specify which DVMRP routes get redistributed.

Examples

The following router configuration mode example redistributes DVMRP routes to BGP peers that match access list 1:

router bgp 109

 redistribute dvmrp route-map dvmrp-into-mbgp

route-map dvmrp-into-mbgp

 match ip address 1

The following address family configuration mode example redistributes DVMRP routes to multiprotocol BGP peers that match access list 1:

router bgp 109

address-family ipv4 multicast

 redistribute dvmrp route-map dvmrp-into-mbgp

route-map dvmrp-into-mbgp

 match ip address 1

router bgp

To configure the Border Gateway Protocol (BGP) routing process, use the router bgp command in global configuration mode. To remove a BGP routing process, use the no form of this command.

router bgp autonomous-system-number

no router bgp autonomous-system-number

Syntax Description

Command Default

No BGP routing process is enabled by default.

Command Modes

Global configuration (config)

Command History

Usage Guidelines

This command allows you to set up a distributed routing core that automatically guarantees the loop-free exchange of routing information between autonomous systems.

Prior to January 2009, BGP autonomous system numbers that were allocated to companies were 2-octet numbers in the range from 1 to 65535 as described in RFC 4271, A Border Gateway Protocol 4 (BGP-4). Due to increased demand for autonomous system numbers, the Internet Assigned Number Authority (IANA) will start in January 2009 to allocate four-octet autonomous system numbers in the range from 65536 to 4294967295. RFC 5396, Textual Representation of Autonomous System (AS) Numbers, documents three methods of representing autonomous system numbers. Cisco has implemented the following two methods:

•Asplain—Decimal value notation where both 2-byte and 4-byte autonomous system numbers are represented by their decimal value. For example, 65526 is a 2-byte autonomous system number and 234567 is a 4-byte autonomous system number.

•Asdot—Autonomous system dot notation where 2-byte autonomous system numbers are represented by their decimal value and 4-byte autonomous system numbers are represented by a dot notation. For example, 65526 is a 2-byte autonomous system number and 1.169031 is a 4-byte autonomous system number (this is dot notation for the 234567 decimal number).

For details about the third method of representing autonomous system numbers, see RFC 5396.

Note In Cisco IOS releases that include 4-byte ASN support, command accounting and command authorization that include a 4-byte ASN number are sent in the asplain notation irrespective of the format that is used on the command-line interface.

Asdot Only Autonomous System Number Formatting

In Cisco IOS Release 12.0(32)S12, 12.4(24)T, Cisco IOS XE Release 2.3, and later releases, the 4-octet (4-byte) autonomous system numbers are entered and displayed only in asdot notation, for example, 1.10 or 45000.64000. When using regular expressions to match 4-byte autonomous system numbers the asdot format includes a period which is a special character in regular expressions. A backslash must be entered before the period for example, 1\.14, to ensure the regular expression match does not fail. Table 6 shows the format in which 2-byte and 4-byte autonomous system numbers are configured, matched in regular expressions, and displayed in show command output in Cisco IOS images where only asdot formatting is available.

Asplain as Default Autonomous System Number Formatting

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain as the default display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain and asdot format. In addition, the default format for matching 4-byte autonomous system numbers in regular expressions is asplain, so you must ensure that any regular expressions to match 4-byte autonomous system numbers are written in the asplain format. If you want to change the default show command output to display 4-byte autonomous system numbers in the asdot format, use the bgp asnotation dot command under router configuration mode. When the asdot format is enabled as the default, any regular expressions to match 4-byte autonomous system numbers must be written using the asdot format, or the regular expression match will fail. Table 7 and Table 8 show that although you can configure 4-byte autonomous system numbers in either asplain or asdot format, only one format is used to display show command output and control 4-byte autonomous system number matching for regular expressions, and the default is asplain format. To display 4-byte autonomous system numbers in show command output and to control matching for regular expressions in the asdot format, you must configure the bgp asnotation dot command. After enabling the bgp asnotation dot command, a hard reset must be initiated for all BGP sessions by entering the clear ip bgp * command.

Note If you are upgrading to an image that supports 4-byte autonomous system numbers, you can still use 2-byte autonomous system numbers. The show command output and regular expression match are not changed and remain in asplain (decimal value) format for 2-byte autonomous system numbers regardless of the format configured for 4-byte autonomous system numbers.

Reserved and Private Autonomous System Numbers

In Cisco IOS Release 12.0(32)S12, 12.0(32)SY8, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, 12.4(24)T, Cisco IOS XE Release 2.3 and later releases, the Cisco implementation of BGP supports RFC 4893. RFC 4893 was developed to allow BGP to support a gradual transition from 2-byte autonomous system numbers to 4-byte autonomous system numbers. A new reserved (private) autonomous system number, 23456, was created by RFC 4893 and this number cannot be configured as an autonomous system number in the Cisco IOS CLI.

RFC 5398, Autonomous System (AS) Number Reservation for Documentation Use, describes new reserved autonomous system numbers for documentation purposes. Use of the reserved numbers allow configuration examples to be accurately documented and avoids conflict with production networks if these configurations are literally copied. The reserved numbers are documented in the IANA autonomous system number registry. Reserved 2-byte autonomous system numbers are in the contiguous block, 64496 to 64511 and reserved 4-byte autonomous system numbers are from 65536 to 65551 inclusive.

Private 2-byte autonomous system numbers are still valid in the range from 64512 to 65534 with 65535 being reserved for special use. Private autonomous system numbers can be used for internal routing domains but must be translated for traffic that is routed out to the Internet. BGP should not be configured to advertise private autonomous system numbers to external networks. Cisco IOS software does not remove private autonomous system numbers from routing updates by default. We recommend that ISPs filter private autonomous system numbers.

Note Autonomous system number assignment for public and private networks is governed by the IANA. For information about autonomous-system numbers, including reserved number assignment, or to apply to register an autonomous system number, see the following URL: http://www.iana.org/.

Examples

The following example configures a BGP process for autonomous system 45000 and configures two external BGP neighbors in different autonomous systems using 2-byte autonomous system numbers:

router bgp 45000

 neighbor 192.168.1.2 remote-as 40000

 neighbor 192.168.3.2 remote-as 50000

 neighbor 192.168.3.2 description finance

 !

 address-family ipv4

  neighbor 192.168.1.2 activate

  neighbor 192.168.3.2 activate

  no auto-summary

  no synchronization

  network 172.17.1.0 mask 255.255.255.0

  exit-address-family

The following example configures a BGP process for autonomous system 65538 and configures two external BGP neighbors in different autonomous systems using 4-byte autonomous system numbers in asplain notation. This example is supported i n Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases.

router bgp 65538

 neighbor 192.168.1.2 remote-as 65536

 neighbor 192.168.3.2 remote-as 65550

 neighbor 192.168.3.2 description finance

 !

 address-family ipv4

  neighbor 192.168.1.2 activate

  neighbor 192.168.3.2 activate

  no auto-summary

  no synchronization

  network 172.17.1.0 mask 255.255.255.0

  exit-address-family

The following example configures a BGP process for autonomous system 1.2 and configures two external BGP neighbors in different autonomous systems using 4-byte autonomous system numbers in asdot notation. This example is supported in Cisco IOS Release 12.0(32)SY8, 12.0(32)S12, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, 12.4(24)T, and Cisco IOS XE Release 2.3, and later releases.

router bgp 1.2

 neighbor 192.168.1.2 remote-as 1.0

 neighbor 192.168.3.2 remote-as 1.14

 neighbor 192.168.3.2 description finance

 !

 address-family ipv4

  neighbor 192.168.1.2 activate

  neighbor 192.168.3.2 activate

  no auto-summary

  no synchronization

  network 172.17.1.0 mask 255.255.255.0

  exit-address-family

Related Commands

route-server-context

To create a route-server context in order to provide flexible policy handling for a BGP route server, use the route-server-context command in router configuration mode. To remove the route server context, use the no form of this command.

route-server-context context-name

no route-server-context context-name

Syntax Description

Command Default

No route server context exists.

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

Flexible (customized) policy support for a BGP route server is made possible with the use of the route-server-context command. The route-server-context command creates a context, which represents the virtual table used to store prefixes and paths that require special handling due to individualized policy configurations.

The context is referenced by the BGP neighbors assigned to use that context (in the neighbor route-server-client command). Thus, multiple neighbors sharing the same policy can share the same route server context.

In order to configure flexible policy handling, create a route server context, which includes an import map. The import map references a standard route map.

Examples

In the following example, the local router is a BGP route server. Its neighbors at 10.10.10.12 and 10.10.10.13 are its route server clients. A route server context named ONLY_AS27_CONTEXT is created and applied to the neighbor at 10.10.10.13. The context uses an import map that references a route map named only_AS27_routemap. The route map matches routes permitted by access list 27. Access list 27 permits routes that have 27 in the autonomous system path.

router bgp 65000

   route-server-context ONLY_AS27_CONTEXT

      address-family ipv4 unicast

         import-map only_AS27_routemap

      exit-address-family

   exit-route-server-context

   !

   neighbor 10.10.10.12 remote-as 12

   neighbor 10.10.10.12 description Peer12

   neighbor 10.10.10.13 remote-as 13

   neighbor 10.10.10.13 description Peer13

   neighbor 10.10.10.21 remote-as 21

   neighbor 10.10.10.27 remote-as 27

   !

   address-family ipv4

      neighbor 10.10.10.12 activate

      neighbor 10.10.10.12 route-server-client

      neighbor 10.10.10.13 activate

      neighbor 10.10.10.13 route-server-client context ONLY_AS27_CONTEXT

      neighbor 10.10.10.21 activate

      neighbor 10.10.10.27 activate

   exit-address-family

!

ip as-path access-list 27 permit 27

!

route-map only_AS27_routemap permit 10

   match as-path 27

!

Related Commands

scope

To define the scope for a Border Gateway Protocol (BGP) routing session and to enter router scope configuration mode, use the scope command in router configuration mode. To remove the scope configuration, use the no form of this command.

scope {global | vrf vrf-name}

no scope {global | vrf vrf-name}

Syntax Description

Command Default

No scope is defined for a BGP routing session.

Command Modes

Router configuration

Command History

Usage Guidelines

A new configuration hierarchy, named scope, has been introduced into the BGP protocol. To implement Multi-Topology Routing (MTR) support for BGP, the scope hierarchy is required, but the scope hierarchy is not limited to MTR use. The scope hierarchy introduces some new configuration modes such as router scope configuration mode. Router scope configuration mode is entered by configuring the scope command in router configuration mode, and a collection of routing tables is created when this command is entered. The scope is configured to isolate routing calculation for a single network (globally) or on a per-VRF basis, and BGP commands configured in routing scope configuration mode are referred to as scoped commands. The scope hierarchy can contain one or more address families.

The BGP command-line interface (CLI) has been modified to provide backwards compatibility for pre-MTR BGP configuration and to provide a hierarchal implementation of MTR. From router scope configuration mode, MTR is configured first by entering the address-family command to enter the desired address family and then by entering the topology command to define the topology

Note Configuring a scope for a BGP routing process removes CLI support for pre-MTR-based configuration.

Examples

The following example defines a global scope that includes both unicast and multicast topology configurations. Another scope is specifically defined only for the VRF named DATA.

Router(config)# router bgp 45000 

Router(config-router)# scope global

Router(config-router-scope)# bgp default ipv4-unicast

Router(config-router-scope)# neighbor 172.16.1.2 remote-as 45000 

Router(config-router-scope)# neighbor 192.168.3.2 remote-as 50000 

Router(config-router-scope)# address-family ipv4 unicast 

Router(config-router-scope-af)# topology VOICE 

Router(config-router-scope-af)# bgp tid 100 

Router(config-router-scope-af)# neighbor 172.16.1.2 activate 

Router(config-router-scope-af)# exit 

Router(config-router-scope)# address-family ipv4 multicast 

Router(config-router-scope-af)# topology base 

Router(config-router-scope-af-topo)# neighbor 192.168.3.2 activate 

Router(config-router-scope-af-topo)# exit 

Router(config-router-scope-af)# exit 

Router(config-router-scope)# exit 

Router(config-router)# scope vrf DATA 

Router(config-router-scope)# neighbor 192.168.1.2 remote-as 40000 

Router(config-router-scope)# address-family ipv4 

Router(config-router-scope-af)# neighbor 192.168.1.2 activate 

Router(config-router-scope-af)# end

Related Commands

set as-path

To modify an autonomous system path for BGP routes, use the set as-path command in route-map configuration mode. To not modify the autonomous system path, use the no form of this command.

set as-path {tag | prepend as-path-string}

no set as-path {tag | prepend as-path-string}

Syntax Description

Command Default

An autonomous system path is not modified.

Command Modes

Route-map configuration (config-route-map)

Command History

Usage Guidelines

The only global BGP metric available to influence the best path selection is the autonomous system path length. By varying the length of the autonomous system path, a BGP speaker can influence the best path selection by a peer further away.

By allowing you to convert the tag into an autonomous system path, the set as-path tag variation of this command modifies the autonomous system length. The set as-path prepend variation allows you to "prepend" an arbitrary autonomous system path string to BGP routes. Usually the local autonomous system number is prepended multiple times, increasing the autonomous system path length.

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain—65538 for example—as the default regular expression match and output display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC 5396. To change the default regular expression match and output display of 4-byte autonomous system numbers to asdot format, use the bgp asnotation dot command followed by the clear ip bgp * command to perform a hard reset of all current BGP sessions.

In Cisco IOS Release 12.0(32)S12, 12.4(24)T, and Cisco IOS XE Release 2.3, the Cisco implementation of 4-byte autonomous system numbers uses asdot—1.2 for example—as the only configuration format, regular expression match, and output display, with no asplain support.

Examples

The following example converts the tag of a redistributed route into an autonomous system path:

route-map set-as-path-from-tag

 set as-path tag

!

router bgp 100

 redistribute ospf 109 route-map set-as-path-from-tag

The following example prepends 100 100 100 to all the routes that are advertised to 10.108.1.1:

route-map set-as-path

 match as-path 1

 set as-path prepend 100 100 100

!

router bgp 100

 neighbor 10.108.1.1 route-map set-as-path out

The following example prepends 65538, 65538, and 65538 to all the routes that are advertised to 192.168.1.2. This example requires Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, or a later release.

route-map set-as-path

 match as-path 1.1

 set as-path prepend 65538 65538 65538

 exit

router bgp 65538

 neighbor 192.168.1.2 route-map set-as-path out

Related Commands

set comm-list delete

To remove communities from the community attribute of an inbound or outbound update, use the set comm-list delete command in route-map configuration mode. To remove a previous set comm-list delete command, use the no form of this command.

set comm-list {community-list-number | community-list-name} delete

no set comm-list {community-list-number | community-list-name} delete

Syntax Description

Command Default

No communities are removed.

Command Modes

Route-map configuration

Command History

Usage Guidelines

This set route-map configuration command removes communities from the community attribute of an inbound or outbound update using a route map to filter and determine the communities to be deleted. Depending upon whether the route map is applied to the inbound or outbound update for a neighbor, each community that passes the route map permit clause and matches the given community list will be removed from the community attribute being received from or sent to the Border Gateway Protocol (BGP) neighbor.

Each entry of a standard community list should list only one community when used with the set comm-list delete command. For example, in order to be able to delete communities 10:10 and 10:20, you must use the following format to create the entries:

ip community-list 500 permit 10:10 
ip community-list 500 permit 10:20

The following format for a community list entry, while acceptable otherwise, does not work with the set comm-list delete command:

config ip community-list 500 permit 10:10 10:20

When both the set community community-number and set comm-list delete commands are configured in the same sequence of a route map attribute, the deletion operation (set comm-list delete) is performed before the set operation (set community community-number).

Examples

In the following example, the communities 100:10 and 100:20 (if present) will be deleted from updates received from 172.16.233.33. Also, except for 100:50, all communities beginning with 100: will be deleted from updates sent to 172.16.233.33.

router bgp 100 
 neighbor 172.16.233.33 remote-as 120 
 neighbor 172.16.233.33 route-map ROUTEMAPIN in 
 neighbor 172.16.233.33 route-map ROUTEMAPOUT out 
! 
ip community-list 500 permit 100:10 
ip community-list 500 permit 100:20 
! 
ip community-list 120 deny   100:50 
ip community-list 120 permit 100:.* 
! 
route-map ROUTEMAPIN permit 10 
 set comm-list 500 delete 
! 
route-map ROUTEMAPOUT permit 10 
 set comm-list 120 delete

Related Commands

set community

To set the BGP communities attribute, use the set community route map configuration command. To delete the entry, use the no form of this command.

set community {community-number [additive] [well-known-community] | none}

no set community

Syntax Description

Command Default

No BGP communities attributes exist.

Command Modes

Route-map configuration

Command History

Usage Guidelines

You must have a match clause (even if it points to a "permit everything" list) if you want to set tags.

Use the route-map global configuration command, and the match and set route map configuration commands, to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.

The set route map configuration commands specify the redistribution set actions to be performed when all of the match criteria of a route map are met. When all match criteria are met, all set actions are performed.

Examples

In the following example, routes that pass the autonomous system path access list 1 have the community set to 109. Routes that pass the autonomous system path access list 2 have the community set to no-export (these routes will not be advertised to any external BGP [eBGP] peers).

route-map set_community 10 permit

 match as-path 1

 set community 109

route-map set_community 20 permit

 match as-path 2

 set community no-export

In the following similar example, routes that pass the autonomous system path access list 1 have the community set to 109. Routes that pass the autonomous system path access list 2 have the community set to local-as (the router will not advertise this route to peers outside the local autonomous system.

route-map set_community 10 permit

 match as-path 1

 set community 109

route-map set_community 20 permit

 match as-path 2

 set community local-as

Related Commands

set dampening

To set the BGP route dampening factors, use the set dampening route map configuration command. To disable this function, use the no form of this command.

set dampening half-life reuse suppress max-suppress-time

no set dampening

Syntax Description

Defaults

This command is disabled by default.

Command Modes

Route-map configuration

Command History

Usage Guidelines

Use the route-map global configuration command, and the match and set route-map configuration commands, to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.

When a BGP peer is reset, the route is withdrawn and the flap statistics cleared. In this instance, the withdrawal does not incur a penalty even though route flap dampening is enabled.

Examples

The following example sets the half life to 30 minutes, the reuse value to 1500, the suppress value to 10000; and the maximum suppress time to 120 minutes:

route-map tag

 match as path 10

 set dampening 30 1500 10000 120

!

router bgp 100

 neighbor 172.16.233.52 route-map tag in

Related Commands

set extcommunity

To set Border Gateway Protocol (BGP) extended community attributes, use the set extcommunity command in route-map configuration mode. To delete the entry, use the no form of this command.

set extcommunity {rt [extended-community-value] [additive] | soo [extended-community-value]}

no set extcommunity

Syntax Description

Command Default

Specifying new route targets with the rt keyword replaces existing route targets by default, unless the additive keyword is used. The use of the additive keyword adds the new route target to the existing route target list but does not replace any existing route targets.

Command Modes

Route-map configuration (config-route-map)

Command History

Usage Guidelines

Extended community attributes are used to configure, filter, and identify routes for virtual routing and forwarding instances (VRFs) and Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs).

The set extcommunity command is used to configure set clauses that use extended community attributes in route maps. All of the standard rules of match and set clauses apply to the configuration of extended community attributes.

The route target (RT) extended community attribute is configured with the rt keyword. This attribute is used to identify a set of sites and VRFs that may receive routes that are tagged with the configured route target. Configuring the route target extended attribute with a route allows that route to be placed in the per-site forwarding tables that are used for routing traffic that is received from corresponding sites.

The site of origin (SOO) extended community attribute is configured with the soo keyword. This attribute uniquely identifies the site from which the Provider Edge (PE) router learned the route. All routes learned from a particular site must be assigned the same SOO extended community attribute, whether a site is connected to a single PE router or multiple PE routers. Configuring this attribute prevents routing loops from occurring when a site is multihomed. The SOO extended community attribute is configured on the interface and is propagated into BGP through redistribution. The SOO can be applied to routes that are learned from VRFs. The SOO should not be configured for stub sites or sites that are not multihomed.

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain—65538 for example—as the default regular expression match and output display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC 5396. To change the default regular expression match and output display of 4-byte autonomous system numbers to asdot format, use the bgp asnotation dot command followed by the clear ip bgp * command to perform a hard reset of all current BGP sessions.

In Cisco IOS Release 12.0(32)S12, 12.4(24)T, and Cisco IOS XE Release 2.3, the Cisco implementation of 4-byte autonomous system numbers uses asdot—1.2 for example—as the only configuration format, regular expression match, and output display, with no asplain support.

Examples

The following example sets the route target to extended community attribute 100:2 for routes that are permitted by the route map:

Router(config)# access-list 2 permit 192.168.78.0 255.255.255.0

Router(config)# route-map MAP_NAME permit 10

Router(config-route-map)# match ip-address 2

Router(config-route-map)# set extcommunity rt 100:2

The following example sets the route target to extended community attribute 100:3 for routes that are permitted by the route map. The use of the additive keyword adds route target 100:3 to the existing route target list but does not replace any existing route targets.

Router(config)# access-list 3 permit 192.168.79.0 255.255.255.0

Router(config)# route-map MAP_NAME permit 10

Router(config-route-map)# match ip-address 3

Router(config-route-map)# set extcommunity rt 100:3 additive

Note Configuring route targets with the set extcommunity command will replace existing route targets, unless the additive keyword is used.

The following example sets the site of origin to extended community attribute 100:4 for routes that are permitted by the route map:

Router(config)# access-list 4 permit 192.168.80.0 255.255.255.0

Router(config)# route-map MAP_NAME permit 10

Router(config-route-map)# match ip-address 4

Router(config-route-map)# set extcommunity soo 100:4

In IPv6, the following example sets the SoO to extended community attribute 100:28 for routes that are permitted by the route map:

(config)# router bgp 100

(config-router)# address-family ipv6 vrf red

(config-router-af)# neighbor 8008::72a route-map setsoo in

(config-router-af)# exit

(config-router)# route-map setsoo permit 10

(config-router)# set extcommnunity soo 100:28

The following example available in Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, shows how to create a VRF with a route-target that uses a 4-byte autonomous system number, 65537 in asplain format, and how to set the route-target to extended community value 65537:100 for routes that are permitted by the route map.

Router(config)# ip vrf vpn_red

Router(config-vrf)# rd 64500:100

Router(config-vrf)# route-target both 65537:100

Router(config-vrf)# exit

Router(config)# route-map rt_map permit 10

Router(config-route-map)# set extcommunity rt 65537:100

Router(config-route-map)# end

The following example available in Cisco IOS Release 12.0(32)SY8, 12.0(32)S12, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, 12.4(24)T, Cisco IOS XE Release 2.3, and later releases, shows how to create a VRF with a route-target that uses a 4-byte autonomous system number, 1.1 in asdot format, and how to set the SoO to extended community attribute 1.1:100 for routes that are permitted by the route map.

Router(config)# ip vrf vpn_red

Router(config-vrf)# rd 64500:100

Router(config-vrf)# route-target both 1.1:100

Router(config-vrf)# exit

Router(config)# route-map soo_map permit 10

Router(config-route-map)# set extcommunity soo 1.1:100

Router(config-route-map)# end

Related Commands

set extcommunity cost

To create a set clause to apply the cost community attribute to routes that pass through a route map, use the set extcommunity cost command in route-map configuration mode. To delete the cost community set clause, use the no form of this command.

set extcommunity cost [igp | pre-bestpath] community-id cost-value

no set extcommunity cost [igp] community-id cost-value

Syntax Description

Command Default

The default cost value is applied to routes that are not configured with the cost community attribute when cost community filtering is enabled. The default cost-value is half of the maximum value (4294967295) or 2147483647.

Command Modes

Route-map configuration

Command History

Usage Guidelines

The cost community attribute is applied to internal routes by configuring the set extcommunity cost command in a route map. The cost community set clause is configured with a cost community ID number (0-255) and a cost community number value (0-4294967295). The path with the lowest cost community number is preferred. In the case where two paths have been configured with the same cost community value, the path selection process will then prefer the path with the lower community ID.

The BGP Cost Community feature can be configured only within the same autonomous-system or confederation. The cost community is a non-transitive extended community. The cost community is passed to internal BGP (iBGP) and confederation peers only and is not passed to external BGP (eBGP) peers. The cost community allows you to customize the local preference and best path selection process for specific paths. The cost extended community attribute is propagated to iBGP peers when extended community exchange is enabled with the neighbor send-community command.

The following commands can be used to apply the route map with the cost community set clause:

•aggregate-address

•neighbor default-originate route-map {in | out}

•neighbor route-map

•network route-map

•redistribute route-map

Multiple cost community set clauses may be configured with the set extcommunity cost command in a single route map block or sequence. However, each set clause must be configured with a different ID value for each point of insertion (POI).

Aggregate routes and multipaths are supported by the BGP Cost Community feature. The cost community attribute can be applied to either type of route. The cost community attribute is passed to the aggregate or multipath route from component routes that carry the cost community attribute. Only unique IDs are passed, and only the highest cost of any individual component route will be applied to the aggregate on a per-ID basis. If multiple component routes contain the same ID, the highest configured cost is applied to the route. If one or more component routes does not carry the cost community attribute or if the component routes are configured with different IDs, then the default value (2147483647) will be advertised for the aggregate or multipath route.

Note The BGP cost community attribute must be supported on all routers in an autonomous system or confederation before cost community filtering is configured. The cost community should be applied consistently throughout the local autonomous system or confederation to avoid potential routing loops.

Support for EIGRP MPLS VPN Back Door Links

The "pre-bestpath" point of insertion (POI) has been introduced in the BGP Cost Community feature to support mixed EIGRP VPN network topologies that contain VPN and backdoor links. This POI is applied automatically to EIGRP routes that are redistributed into BGP. The "pre-best path" POI carries the EIGRP route type and metric. This POI influences the best path calculation process by influencing BGP to consider this POI before any other comparison step. No configuration is required. This feature is enabled automatically for EIGRP VPN sites when a supporting is installed to a PE, CE, or back door router.

Examples

The following example configuration shows the configuration of the set extcommunity cost command. The following example applies the cost community ID of 1 and cost community value of 100 to routes that are permitted by the route map. This configuration will cause the best path selection process to prefer this route over other equal cost paths that were not permitted by this route map sequence.

Router(config)# router bgp 50000

Router(config-router)# neighbor 10.0.0.1 remote-as 50000

Router(config-router)# neighbor 10.0.0.1 update-source Loopback 0

Router(config-router)# address-family ipv4

Router(config-router-af)# neighbor 10.0.0.1 activate

Router(config-router-af)# neighbor 10.0.0.1 route-map COST1 in 

Router(config-router-af)# neighbor 10.0.0.1 send-community both 

Router(config-router-af)# exit 

Router(config)# route-map COST1 permit 10

Router(config-route-map)# match ip-address 1

Router(config-route-map)# set extcommunity cost 1 100

Related Commands

set ip next-hop (BGP)

To indicate where to output packets that pass a match clause of a route map for policy routing, use the set ip next-hop command in route-map configuration mode. To delete an entry, use the no form of this command.

set ip next-hop ip-address [... ip-address] [peer-address]

no set ip next-hop ip-address [... ip-address] [peer-address]

Syntax Description

Defaults

This command is disabled by default.

Command Modes

Route-map configuration

Command History

Usage Guidelines

An ellipsis (...) in the command syntax indicates that your command input can include multiple values for the ip-address argument.

Use the ip policy route-map interface configuration command, the route-map global configuration command, and the match and set route-map configuration commands to define the conditions for policy routing packets. The ip policy route-map command identifies a route map by name. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which policy routing occurs. The set commands specify the set actions—the particular routing actions to perform if the criteria enforced by the match commands are met.

If the first next hop specified with the set ip next-hop command is down, the optionally specified IP addresses are tried in turn.

When the set ip next-hop command is used with the peer-address keyword in an inbound route map of a BGP peer, the next hop of the received matching routes will be set to be the neighbor peering address, overriding any third-party next hops. So the same route map can be applied to multiple BGP peers to override third-party next hops.

When the set ip next-hop command is used with the peer-address keyword in an outbound route map of a BGP peer, the next hop of the advertised matching routes will be set to be the peering address of the local router, thus disabling the next hop calculation. The set ip next-hop command has finer granularity than the (per-neighbor) neighbor next-hop-self command, because you can set the next hop for some routes, but not others. The neighbor next-hop-self command sets the next hop for all routes sent to that neighbor.

The set clauses can be used in conjunction with one another. They are evaluated in the following order:

1. set ip next-hop

2. set interface

3. set ip default next-hop

4. set default interface

Note To avoid a common configuration error for reflected routes, do not use the set ip next-hop command in a route map to be applied to BGP route reflector clients.

Examples

In the following example, three routers are on the same FDDI LAN (with IP addresses 10.1.1.1, 10.1.1.2, and 10.1.1.3). Each is in a different autonomous system. The set ip next-hop peer-address command specifies that traffic from the router (10.1.1.3) in remote autonomous system 300 for the router (10.1.1.1) in remote autonomous system 100 that matches the route map is passed through the router bgp 200, rather than sent directly to the router (10.1.1.1) in autonomous system 100 over their mutual connection to the LAN.

router bgp 200

neighbor 10.1.1.3 remote-as 300

neighbor 10.1.1.3 route-map set-peer-address out

neighbor 10.1.1.1 remote-as 100

route-map set-peer-address permit 10

set ip next-hop peer-address

Related Commands

set metric (BGP-OSPF-RIP)

To set the metric value for a routing protocol, use the set metric command in route-map configuration mode. To return to the default metric value, use the no form of this command.

set metric metric-value

no set metric metric-value

Syntax Description

Defaults

The dynamically learned metric value.

Command Modes

Route-map configuration

Command History

Usage Guidelines

We recommend that you consult your Cisco technical support representative before changing the default value.

Use the route-map global configuration command, and the match and set route-map configuration commands, to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.

The set route-map configuration commands specify the redistribution set actions to be performed when all the match criteria of a route map are met. When all match criteria are met, all set actions are performed.

Examples

The following example sets the metric value for the routing protocol to 100:

route-map set-metric

 set metric 100

Related Commands

set metric-type internal

To set the Multi Exit Discriminator (MED) value on prefixes advertised to external BGP (eBGP) neighbors to match the Interior Gateway Protocol (IGP) metric of the next hop, use the set metric-type internal command in route-map configuration mode. To return to the default, use the no form of this command.

set metric-type internal

no set metric-type internal

Syntax Description

This command has no arguments or keywords.

Defaults

This command is disabled by default.

Command Modes

Route-map configuration

Command History

Usage Guidelines

This command will cause BGP to advertise a MED value that corresponds to the IGP metric associated with the next hop of the route. This command applies to generated, internal BGP (iBGP)-, and eBGP-derived routes.

If this command is used, multiple BGP speakers in a common autonomous system can advertise different MED values for a particular prefix. Also, note that if the IGP metric changes, BGP will readvertise the route every 10 minutes.

Use the route-map global configuration command and the match and set route-map configuration commands to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.

The set route-map configuration commands specify the redistribution set actions to be performed when all of the match criteria of the route map are met. When all match criteria are met, all set actions are performed.

Note This command is not supported for redistributing routes into Border Gateway Protocol (BGP).

Examples

In the following example, the MED value for all the advertised routes to neighbor 172.16.2.3 is set to the corresponding IGP metric of the next hop:

router bgp 109

 network 172.16.0.0

 neighbor 172.16.2.3 remote-as 200

 neighbor 172.16.2.3 route-map setMED out

!

route-map setMED permit 10

 match as-path 1

 set metric-type internal

!

 ip as-path access-list 1 permit .*

Related Commands

set origin (BGP)

To set the BGP origin code, use the set origin command in route-map configuration mode. To delete an entry, use the no form of this command.

set origin {igp | egp autonomous-system-number | incomplete}

no set origin {igp | egp autonomous-system-number | incomplete}

Syntax Description

Command Default

The origin of the route is based on the path information of the route in the main IP routing table.

Command Modes

Route-map configuration (config-route-map)

Command History

Usage Guidelines

You must have a match clause (even if it points to a "permit everything" list) if you want to set the origin of a route. Use this command to set a specific origin when a route is redistributed into BGP. When routes are redistributed, the origin is usually recorded as incomplete, identified with a ? in the BGP table.

Use the route-map global configuration command, and the match and set route-map configuration commands, to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.

The set route-map configuration commands specify the redistribution set actions to be performed when all of the match criteria of a route map are met. When all match criteria are met, all set actions are performed.

Examples

The following example sets the origin of routes that pass the route map to IGP:

route-map set_origin

 match as-path 10

 set origin igp

Related Commands

set traffic-index

To indicate how to classify packets that pass a match clause of a route map for Border Gateway Protocol (BGP) policy accounting, use the set traffic-index command in route-map configuration mode. To delete an entry, use the no form of this command.

set traffic-index bucket-number

no set traffic-index bucket-number

Syntax Description

Command Default

Routing traffic is not classified.

Command Modes

Route-map configuration

Command History