The BGP next-hop address tracking feature is enabled by default when a supporting Cisco software image is installed. BGP next-hop address tracking is event driven. BGP prefixes are automatically tracked as peering sessions are established. Next-hop changes are rapidly reported to the BGP routing process as they are updated in the RIB. This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the RIB. When a best-path calculation is run in between BGP scanner cycles, only next-hop changes are tracked and processed.

BGP monitors the next hop of installed routes to verify next-hop reachability and to select, install, and validate the BGP best path. By default, the BGP scanner is used to poll the RIB for this information every 60 seconds. During the 60 second time period between scan cycles, Interior Gateway Protocol (IGP) instability or other network failures can cause black holes and routing loops to temporarily form.

In Cisco IOS Release 12.4(4)T, 12.2(33)SRB, and later releases, BGP selective next-hop route filtering was implemented as part of the BGP Selective Address Tracking feature to support BGP next-hop address tracking. Selective next-hop route filtering uses a route map to selectively define routes to help resolve the BGP next hop.

The ability to use a route map with the bgp nexthopcommand allows the configuration of the length of a prefix that applies to the BGP Next_Hop attribute. The route map is used during the BGP bestpath calculation and is applied to the route in the routing table that covers the next-hop attribute for BGP prefixes. If the next-hop route fails the route map evaluation, the next-hop route is marked as unreachable. This command is per address family, so different route maps can be applied for next-hop routes in different address families.

Note	Only match ip address and match source-protocol commands are supported in the route map. No set commands or other match commands are supported.

The Next_Hop attribute identifies the next-hop IP address to be used as the BGP next hop to the destination. The router makes a recursive lookup to find the BGP next hop in the routing table. In external BGP (eBGP), the next hop is the IP address of the peer that sent the update. Internal BGP (iBGP) sets the next-hop address to the IP address of the peer that advertised the prefix for routes that originate internally. When any routes to iBGP that are learned from eBGP are advertised, the Next_Hop attribute is unchanged.

A BGP next-hop IP address must be reachable in order for the router to use a BGP route. Reachability information is usually provided by the IGP, and changes in the IGP can influence the forwarding of the next-hop address over a network backbone.

Cisco NSF is supported by the BGP, EIGRP, OSPF, and IS-IS protocols for routing and by Cisco Express Forwarding (CEF) for forwarding. Of the routing protocols, BGP, EIGRP, OSPF, and IS-IS have been enhanced with NSF-capability and awareness, which means that routers running these protocols can detect a switchover and take the necessary actions to continue forwarding network traffic and to recover route information from the peer devices.

In this document, a networking device is said to be NSF-aware if it is running NSF-compatible software. A device is said to be NSF-capable if it has been configured to support NSF; therefore, it would rebuild routing information from NSF-aware or NSF-capable neighbors.

Each protocol depends on CEF to continue forwarding packets during switchover while the routing protocols rebuild the Routing Information Base (RIB) tables. Once the routing protocols have converged, CEF updates the FIB table and removes stale route entries. CEF then updates the line cards with the new FIB information.

Note	Currently, EIGRP supports only NSF awareness.

A key element of NSF is packet forwarding. In a Cisco networking device, packet forwarding is provided by CEF. CEF maintains the FIB and uses the FIB information that was current at the time of the switchover to continue forwarding packets during a switchover. This feature reduces traffic interruption during the switchover.

During normal NSF operation, CEF on the active RP synchronizes its current FIB and adjacency databases with the FIB and adjacency databases on the standby RP. Upon switchover of the active RP, the standby RP initially has FIB and adjacency databases that are mirror images of those that were current on the active RP. For platforms with intelligent line cards, the line cards will maintain the current forwarding information over a switchover; for platforms with forwarding engines, CEF will keep the forwarding engine on the standby RP current with changes that are sent to it by CEF on the active RP. In this way, the line cards or forwarding engines will be able to continue forwarding after a switchover as soon as the interfaces and a data path are available.

As the routing protocols start to repopulate the RIB on a prefix-by-prefix basis, the updates in turn cause prefix-by-prefix updates for CEF, which it uses to update the FIB and adjacency databases. Existing and new entries will receive the new version ("epoch") number, indicating that they have been refreshed. The forwarding information is updated on the line cards or forwarding engine during convergence. The RP signals when the RIB has converged. The software removes all FIB and adjacency entries that have an epoch older than the current switchover epoch. The FIB now represents the newest routing protocol forwarding information

The routing protocols run only on the active RP, and they receive routing updates from their neighbor routers. Routing protocols do not run on the standby RP. Following a switchover, the routing protocols request that the NSF-aware neighbor devices send state information to help rebuild the routing tables.

Note	For NSF operation, the routing protocols depend on CEF to continue forwarding packets while the routing protocols rebuild the routing information.

When an NSF-capable router begins a BGP session with a BGP peer, it sends an OPEN message to the peer. Included in the message is a declaration that the NSF-capable or NSF-aware router has "graceful restart capability." Graceful restart is the mechanism by which BGP routing peers avoid a routing flap following a switchover. If the BGP peer has received this capability, it is aware that the device sending the message is NSF-capable. Both the NSF-capable router and its BGP peer(s) (NSF-aware peers) need to exchange the graceful restart capability in their OPEN messages, at the time of session establishment. If both the peers do not exchange the graceful restart capability, the session will not be graceful restart capable.

If the BGP session is lost during the RP switchover, the NSF-aware BGP peer marks all the routes associated with the NSF-capable router as stale; however, it continues to use these routes to make forwarding decisions for a set period of time. This functionality means that no packets are lost while the newly active RP is waiting for convergence of the routing information with the BGP peers.

After an RP switchover occurs, the NSF-capable router reestablishes the session with the BGP peer. In establishing the new session, it sends a new graceful restart message that identifies the NSF-capable router as having restarted.

At this point, the routing information is exchanged between the two BGP peers. Once this exchange is complete, the NSF-capable device uses the routing information to update the RIB and the FIB with the new forwarding information. The NSF-aware device uses the network information to remove stale routes from its BGP table. Following that, the BGP protocol is fully converged.

If a BGP peer does not support the graceful restart capability, it will ignore the graceful restart capability in an OPEN message but will establish a BGP session with the NSF-capable device. This functionality will allow interoperability with non-NSF-aware BGP peers (and without NSF functionality), but the BGP session with non-NSF-aware BGP peers will not be graceful restart capable.

BGP support for NSF requires that neighbor routers are NSF-aware or NSF-capable. NSF awareness in BGP is also enabled by the graceful restart mechanism. A router that is NSF-aware functions like a router that is NSF-capable with one exception: an NSF-aware router is incapable of performing an SSO operation. However, a router that is NSF-aware is capable of maintaining a peering relationship with a NSF-capable neighbor during a NSF SSO operation, as well as holding routes for this neighbor during the SSO operation.

The BGP Nonstop Forwarding Awareness feature provides an NSF-aware router with the capability to detect a neighbor that is undergoing an SSO operation, maintain the peering session with this neighbor, retain known routes, and continue to forward packets for these routes. The deployment of BGP NSF awareness can minimize the affects of route-processor (RP) failure conditions and improve the overall network stability by reducing the amount of resources that are normally required for reestablishing peering with a failed router.

NSF awareness for BGP is not enabled by default. The bgp graceful-restart command is used to globally enable NSF awareness on a router that is running BGP. NSF-aware operations are also transparent to the network operator and BGP peers that do not support NSF capabilities.

Note	NSF awareness is enabled automatically in supported software images for Interior Gateway Protocols, such as EIGRP, IS-IS, and OSPF. In BGP, global NSF awareness is not enabled automatically and must be started by issuing the bgp graceful-restart command in router configuration mode.

In Cisco IOS Releases 12.2(33)SRC, 12.2(33)SB (on platforms including the Cisco 10000 series routers), 15.0(1)M, and later releases, the ability to enable or disable BGP graceful restart for every individual BGP neighbor was introduced. Three new methods of configuring BGP graceful restart for BGP peers, in addition to the existing global BGP graceful restart configuration, are now available. Graceful restart can be enabled or disabled for a BGP peer or a BGP peer group using the neighbor ha-mode graceful-restart command, or a BGP peer can inherit a graceful restart configuration from a BGP peer-session template using the ha-mode graceful-restartcommand.

Although BGP graceful restart is disabled by default, the existing global command enables graceful restart for all BGP neighbors regardless of their capabilities. The ability to enable or disable BGP graceful restart for individual BGP neighbors provides a greater level of control for a network administrator.

When the BGP graceful restart capability is configured for an individual neighbor, each method of configuring graceful restart has the same priority, and the last configuration instance is applied to the neighbor. For example, if global graceful restart is enabled for all BGP neighbors but an individual neighbor is subsequently configured as a member of a peer group for which the graceful restart is disabled, graceful restart is disabled for that neighbor.

The configuration of the restart and stale-path timers is available only with the global bgp graceful-restart command, but the default values are set when the neighbor ha-mode graceful-restartor ha-mode graceful-restart commands are configured. The default values are optimal for most network deployments, and these values should be adjusted only by an experienced network operator.

Peer session templates are used to group and apply the configuration of general BGP session commands to groups of neighbors that share session configuration elements. General session commands that are common for neighbors that are configured in different address families can be configured within the same peer session template. Peer session templates are created and configured in peer session configuration mode. Only general session commands can be configured in a peer session template.

General session commands can be configured once in a peer session template and then applied to many neighbors through the direct application of a peer session template or through indirect inheritance from a peer session template. The configuration of peer session templates simplifies the configuration of general session commands that are commonly applied to all neighbors within an autonomous system.

Peer session templates support direct and indirect inheritance. A BGP neighbor can be configured with only one peer session template at a time, and that peer session template can contain only one indirectly inherited peer session template. A BGP neighbor can directly inherit only one session template and can indirectly inherit up to seven additional peer session templates.

Peer session templates support inheritance. A directly applied peer session template can directly or indirectly inherit configurations from up to seven peer session templates. So, a total of eight peer session templates can be applied to a neighbor or neighbor group.

Peer session templates support only general session commands. BGP policy configuration commands that are configured only for a specific address family or NLRI configuration mode are configured with peer policy templates.

For more details about BGP peer session templates, see the "Configuring a Basic BGP Network" module.

To use a BGP peer session template to enable or disable BGP graceful restart, see the section "Enabling and Disabling BGP Graceful Restart Using BGP Peer Session Templates".

A new configuration hierarchy, named scope, has been introduced into the BGP protocol. To implement MTR 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. BGP commands configured under the scope hierarchy are configured for a single network (globally), or on a per-VRF basis, and are referred to as scoped commands. The scope hierarchy can contain one or more address families.

The BGP CLI has been modified to provide backwards compatibility for pre-MTR BGP configuration and to provide a hierarchical implementation of MTR. Router configuration mode is backwards compatible with the pre-address family and pre-MTR configuration CLI. Global commands that affect all networks are configured in this configuration mode. For address-family and topology configuration, general session commands and peer templates can be configured to be used in the address-family or topology configuration modes.

After any global commands are configured, the scope is defined either globally or for a specific VRF. Address family configuration mode is entered by configuring the address-family command in router scope configuration mode or router configuration mode. Unicast is the default address family if no subaddress family (SAFI) is specified. MTR supports only the IPv4 address family with a SAFI of unicast or multicast. Entering address family configuration mode from router configuration mode configures BGP to use pre-MTR-based CLI. This configuration mode is backwards compatible with pre-existing address family configurations. Entering address family configuration mode from router scope configuration mode configures the router to use the hierarchical CLI that supports MTR. Address family configuration parameters that are not specific to a topology are entered in this address family configuration mode.

BGP topology configuration mode is entered by configuring the topology(BGP) command in address family configuration mode. Up to 32 topologies (including the base topology) can be configured on a router. The topology ID is configured by entering the bgp tid command. All address family and subaddress family configuration parameters for the topology are configured here.

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

The following shows the hierarchy levels that are used when configuring BGP for MTR implementation:

router bgp <
autonomous-system-number
>
 ! global commands

 scope {global | vrf <
vrf-name
>}
  ! scoped commands

  address-family {<
afi
>} [<
safi
>]
   ! address family specific commands

   topology {<
topology-name
> | base}
    ! topology specific commands

MTR is configured under BGP on a per-session basis. The base unicast and multicast topologies are carried in the global (default) session. A separate session is created for each class-specific topology that is configured under a BGP routing process. Each session is identified by its topology ID. BGP performs a best-path calculation individually for each class-specific topology. A separate RIB and FIB are maintained for each session.

Depending on the design and policy requirements for your network, you may need to install routes from a class-specific topology on one router in a class-specific topology on a neighboring router. Topology translation functionality using BGP provides support for this operation. Topology translation is BGP neighbor-session based. The neighbor translate-topology command is configured using the IP address and topology ID from the neighbor.

The topology ID identifies the class-specific topology of the neighbor. The routes in the class-specific topology of the neighbor are installed in the local class-specific RIB. BGP performs a best-path calculation on all installed routes and installs these routes into the local class-specific RIB. If a duplicate route is translated, BGP will select and install only one instance of the route per standard BGP best-path calculation behavior.

Topology import functionality using BGP is similar to topology translation. The difference is that routes are moved between class-specific topologies on the same router using BGP. This function is configured by entering the import topology command. The name of the class-specific topology or base topology is specified when entering this command. Best-path calculations are run on the imported routes before they are installed into the topology RIB. This command also includes a route-map keyword to allow you to filter routes that are moved between class-specific topologies.

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    address-family ipv4 [[mdt | multicast | tunnel | unicast [vrf vrf-name] | vrf vrf-name] | vpnv4 [unicast] | vpnv6 [unicast]]

5.    no bgp nexthop trigger enable

6.    end

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    address-family ipv4 [[mdt | multicast | tunnel | unicast [vrf vrf-name] | vrf vrf-name] | vpnv4 [unicast]]

5.    bgp nexthop trigger delay delay-timer

6.    end

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    address-family ipv4 [unicast | multicast| vrf vrf-name]

5.    bgp nexthop route-map map-name

6.    exit

7.    exit

8.    ip prefix-list list-name [seq seq-value] {deny network / length | permit network / length}[ge ge-value] [le le-value]

9.    route-map map-name [permit| deny][sequence-number]

10.    match ip address prefix-list prefix-list-name [prefix-list-name...]

11.    exit

12.    route-map map-name [permit| deny][sequence-number]

13.    end

14.    show ip bgp [network] [network-mask]

BGP table version is 7, local router ID is 172.17.1.99
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*  10.1.1.0/24      192.168.1.2              0             0 40000 i
*  10.2.2.0/24      192.168.3.2              0             0 50000 i
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
*> 172.17.1.0/24    0.0.0.0                  0         32768 

Perform this task to enable BGP NSF awareness globally for all BGP neighbors. BGP NSF awareness is part of the graceful restart mechanism and BGP NSF awareness is enabled by issuing the bgp graceful-restart command in router configuration mode. BGP NSF awareness allows NSF-aware routers to support NSF-capable routers during an SSO operation. NSF-awareness is not enabled by default and should be configured on all neighbors that participate in BGP NSF.

Note	The configuration of the restart and stale-path timers is not required to enable the BGP graceful restart capability. The default values are optimal for most network deployments, and these values should be adjusted only by an experienced network operator.

Note	Configuring both BFD and BGP graceful restart for NSF on a router running BGP may result in suboptimal routing. For more details, see "BFD for BGP".

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    bgp graceful-restart [restart-time seconds] [stalepath-time seconds]

5.    end

• Troubleshooting Tips
  
• What to Do Next
  

Perform this task to adjust the BGP graceful restart timers. There are two BGP graceful restart timers that can be configured. The optional restart-time keyword and seconds argument determine how long peer routers will wait to delete stale routes before a BGP open message is received. The default value is 120 seconds. The optional stalepath-time keyword and seconds argument determine how long a router will wait before deleting stale routes after an end of record (EOR) message is received from the restarting router. The default value is 360 seconds.

Note	The configuration of the restart and stale-path timers is not required to enable the BGP graceful restart capability. The default values are optimal for most network deployments, and these values should be adjusted only by an experienced network operator.

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    bgp graceful-restart [restart-timeseconds]

5.    bgp graceful-restart [stalepath-time seconds]

6.    Router(config-router)# end

• What to Do Next
  

Perform this task to enable and disable BGP graceful restart for BGP neighbors using peer session templates. In this task, a BGP peer session template is created, and BGP graceful restart is enabled. A second peer session template is created, and this template is configured to disable BGP graceful restart.

In this example, the configuration is performed at Router B in the figure below and two external BGP neighbors--at Router A and Router E in the figure below--are identified. The first BGP peer at Router A is configured to inherit the first peer session template that enables BGP graceful restart, whereas the second BGP peer at Router E inherits the second template that disables BGP graceful restart. Using the optional show ip bgp neighbors command, the status of the BGP graceful restart capability is verified for each BGP neighbor configured in this task.

Figure 1

Network Topology Showing BGP Neighbors

The restart and stale-path timers can be modified only using the global bgp graceful-restart command as shown in the Configuring BGP NSF Awareness Timers. The restart and stale-path timers are set to the default values when BGP graceful restart is enabled for BGP neighbors using peer session templates.

Before You Begin

This task requires a Cisco IOS Release 12.2(33)SRC, or 12.2(33)SB.

Note	A BGP peer cannot inherit from a peer policy or session template and be configured as a peer group member at the same. BGP templates and BGP peer groups are mutually exclusive.

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    template peer-session session-template-name

5.    ha-mode graceful-restart [disable]

6.    exit-peer-session

7.    template peer-session session-template-name

8.    ha-mode graceful-restart [disable]

9.    exit-peer-session

10.    bgp log-neighbor-changes

11.    neighbor ip-address remote-as autonomous-system-number

12.    neighbor ip-address inherit peer-session session-template-number

13.    neighbor ip-address remote-as autonomous-system-number

14.    neighbor ip-address inherit peer-session session-template-number

15.    end

16.    show ip bgp template peer-session [session-template-number]

17.    show ip bgp neighbors [ip-address [received-routes | routes | advertised-routes | paths [regexp] | dampened-routes | flap-statistics| received prefix-filter| policy[detail]]]

Router# show ip bgp neighbors 192.168.1.2
BGP neighbor is 192.168.1.2,  remote AS 40000, external link
 Inherits from template S1 for session parameters
  BGP version 4, remote router ID 192.168.1.2
  BGP state = Established, up for 00:02:11
  Last read 00:00:23, last write 00:00:27, hold time is 180, keepalive intervals
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast: advertised and received
    Graceful Restart Capability: advertised
    Multisession Capability: advertised and received
!
Address tracking is enabled, the RIB does have a route to 192.168.1.2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is enabled, restart-time 120 seconds, stalepath-time 360 secs
Connection state is ESTAB, I/O status: 1, unread input bytes: 0 

Router# show ip bgp neighbors 192.168.3.2
BGP neighbor is 192.168.3.2,  remote AS 50000, external link
 Inherits from template S2 for session parameters
  BGP version 4, remote router ID 192.168.3.2
  BGP state = Established, up for 00:01:41
  Last read 00:00:45, last write 00:00:45, hold time is 180, keepalive intervals
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast: advertised and received
!
Address tracking is enabled, the RIB does have a route to 192.168.3.2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0 

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    address-family ipv4 [unicast | multicast| vrf vrf-name]

5.    neighbor ip-address remote-as autonomous-system-number

6.    neighbor ip-address activate

7.    neighbor ip-address ha-mode graceful-restart [disable]

8.    end

9.    show ip bgp neighbors [ip-address [received-routes | routes | advertised-routes | paths [regexp] | dampened-routes | flap-statistics| received prefix-filter| policy[detail]]]

Router# show ip bgp neighbors 172.21.1.2
BGP neighbor is 172.21.1.2,  remote AS 45000, internal link
  BGP version 4, remote router ID 172.22.1.1
  BGP state = Established, up for 00:01:01
  Last read 00:00:02, last write 00:00:07, hold time is 180, keepalive intervals
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast: advertised and received
    Graceful Restart Capability: advertised
    Multisession Capability: advertised and received
!
  Address tracking is enabled, the RIB does have a route to 172.21.1.2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is enabled, restart-time 120 seconds, stalepath-time 360 secs
Connection state is ESTAB, I/O status: 1, unread input bytes: 0 

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    address-family ipv4 [unicast | multicast| vrf vrf-name]

5.    neighbor peer-group-name peer-group

6.    neighbor peer-group-name remote-as autonomous-system-number

7.    neighbor peer-group-name ha-mode graceful-restart [disable]

8.    neighbor ip-address peer-group peer-group-name

9.    end

10.    show ip bgp neighbors [ip-address [received-routes | routes | advertised-routes | paths [regexp] | dampened-routes | flap-statistics| received prefix-filter| policy[detail]]]

Router# show ip bgp neighbors 172.16.1.2
BGP neighbor is 172.16.1.2,  remote AS 45000, internal link
 Member of peer-group PG1 for session parameters
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Idle
  Neighbor sessions:
    0 active, is multisession capable
!
Address tracking is enabled, the RIB does have a route to 172.16.1.2
  Connections established 0; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled

1.    enable

2.    show running-config [options]

3.    show ip bgp neighbors [ip-address [received-routes | routes | advertised-routes | paths [regexp] | dampened-routes | flap-statistics| received prefix-filter| policy[detail]]]

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv4 [unicast | multicast| vrf vrf-name]

5.    bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]

6.    end

1.    enable

2.    show ip bgp flap-statistics [regexp regexp | filter-list access-list | ip-address mask [longer-prefix]]

3.    clear ip bgp flap-statistics [neighbor-address [ipv4-mask]] [regexp regexp | filter-list extcom-number]

4.    show ip bgp dampened-paths

5.    clear ip bgp [ipv4 {multicast | unicast} | ipv6{multicast | unicast} | vpnv4 unicast] dampening [neighbor-address] [ipv4-mask]

• Cisco Express Forwarding (CEF) and IP routing must be enabled on all participating routers.
• BGP must be configured on the routers before BFD is deployed. You should implement fast convergence for the routing protocol that you are using. See the IP routing documentation for your version of Cisco IOS software for information on configuring fast convergence.

• For the current Cisco implementation of BFD support for BGP in Cisco IOS Releases 12.0(31)S, 12.4(4)T, 12.2(33)SRA, 12.2(33)SXH, and 12.2(33)SB, BFD is supported only for IPv4 networks, and only asynchronous mode is supported. In asynchronous mode, either BFD peer can initiate a BFD session.
• BFD works only for directly-connected neighbors. BFD neighbors must be no more than one IP hop away. Multihop configurations are not supported.
• Configuring both BFD and BGP graceful restart for NSF on a router running BGP may result in suboptimal routing. For more details, see the BFD for BGP.

1.    enable

2.    configure terminal

3.    interface type number

4.    bfd interval milliseconds min_rx milliseconds multiplier interval-multiplier

5.    end

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    neighbor ip-address fall-over bfd

5.    end

6.    show bfd neighbors [details]

7.    show ip bgp neighbors [ip-address [received-routes | routes | advertised-routes | paths [regexp] | dampened-routes | flap-statistics| received prefix-filter| policy[detail]]]

1.    enable

2.    show bfd neighbors [details]

3.    debug bfd [event | packet | ipc-error | ipc-event | oir-error | oir-event]

• What to Do Next
  

Perform this task to activate an MTR topology inside an address family using BGP. This task is configured on Router B in the figure below and must also be configured on Router D and Router E. In this task, a scope hierarchy is configured to apply globally and a neighbor is configured under router scope configuration mode. Under the IPv4 unicast address family, an MTR topology that applies to video traffic is activated for the specified neighbor. There is no interface configuration mode for BGP topologies.

Figure 2

BGP Network Diagram

The BGP CLI has been modified to provide backwards compatibility for pre-MTR BGP configuration and to provide a hierarchical implementation of MTR. A new configuration hierarchy, named scope, has been introduced into the BGP protocol. To implement MTR 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 following shows the hierarchy levels that are used when configuring BGP for MTR implementation:

router bgp <
autonomous-system-number
>
 ! global commands

 scope {global | vrf <
vrf-name
>}
  ! scoped commands

  address-family {<
afi
>} [<
safi
>]
   ! address family specific commands

   topology {<
topology-name
> | base}
    ! topology specific commands

Before using BGP to support MTR, you should be familiar with all the concepts documented in the BGP Support for MTR.

Before You Begin

• You must be running a Cisco IOS Release 12.2(33)SRB, or later release, on any routers configured for MTR.
• A global MTR topology configuration has been configured and activated.
• IP routing and CEF are enabled.

Note

Redistribution within a topology is permitted. Redistribution from one topology to another is not permitted. This restriction is designed to prevent routing loops. You can use topology translation or topology import functionality to move routes from one topology to another. Only the IPv4 address family (multicast and unicast) is supported. Only a single multicast topology can be configured, and only the base topology can be specified if a multicast topology is created.

1.    enable

2.    configure terminal

3.    router bgp autonomous-system-number

4.    scope {global | vrf vrf-name}

5.    neighbor {ip-address| peer-group-name} remote-as autonomous-system-number

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

7.    address-family ipv4 [mdt | multicast | unicast]

8.    topology {base| topology-name}

9.    bgp tid number

10.    neighbor ip-address activate

11.    neighbor {ip-address| peer-group-name} translate-topology number

12.    end

13.    clear ip bgp topology {* | topology-name} {as-number | dampening [network-address [network-mask]] | flap-statistics [network-address [network-mask]] | peer-group peer-group-name | table-map | update-group [number | ip-address]} [in [prefix-filter] | out| soft [in [prefix-filter] | out]]

14.    show ip bgp topology {* | topology} summary

Router# show ip bgp topology VIDEO summary
BGP router identifier 192.168.3.1, local AS number 45000
BGP table version is 1, main routing table version 1
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.1.2      4 45000     289     289        1    0    0 04:48:44        0
192.168.3.2     4 50000       3       3        1    0    0 00:00:27        0

• What to Do Next
  

Before You Begin

• You must be running a Cisco IOS Release 12.2(33)SRB, or later release, on any routers configured for MTR.
• A global topology configuration has been configured and activated.
• IP routing and CEF are enabled.

Note

Redistribution within a topology is permitted. Redistribution from one topology to another is not permitted. This restriction is designed to prevent routing loops from occurring. You can use topology translation or topology import functionality to move routes from one topology to another. Only the IPv4 address family (multicast and unicast) is supported. Only a single multicast topology can be configured, and only the base topology can be specified if a multicast topology is created.

1.    enable

2.    configure terminal

3.    ip prefix-list list-name [seq seq-value] {deny network / length| permit network / length} [ge ge-value] [le le-value]

4.    route-map map-name [permit | deny] [sequence-number]

5.    match ip address {access-list-number [access-list-number... | access-list-name...] | access-list-name [access-list-number...| access-list-name] | prefix-list prefix-list-name [prefix-list-name...]}

6.    exit

7.    router bgp autonomous-system-number

8.    scope {global | vrf vrf-name}

9.    address-family ipv4 [mdt | multicast | unicast]

10.    topology {base| topology-name}

11.    import topology {base| topology-name}[route-map map-name]

12.    end