Table Of Contents

table-map

template peer-policy

template peer-session

timers active-time

timers basic (ODR)

timers basic (RIP)

timers bgp

timers lsa arrival

timers nsf route-hold

timers pacing flood

timers pacing lsa-group

timers pacing retransmission

timers spf

timers throttle lsa all

timers throttle spf

traffic-share balanced

traffic-share min

validate-update-source

variance (EIGRP)

version

vrf (router configuration)

table-map

To modify metric and tag values when the IP routing table is updated with BGP learned routes, use the table-map command in address family or router configuration mode. To disable this function, use the no form of the command.

table-map map-name

no table-map map-name

Syntax Description

map-name

Route map name, from the route-map command.

Defaults

This command is disabled by default.

Command Modes

Address family configuration

Router configuration

Command History

Release	Modification
10.0	This command was introduced.
12.0(7)T	Address family configuration mode was added.

Usage Guidelines

This command adds the route map name defined by the route-map command to the IP routing table. This command is used to set the tag name and the route metric to implement redistribution.

You can use match clauses of route maps in the table-map command. IP access list, autonomous system paths, and next hop match clauses are supported.

Examples

In the following router configuration mode example, the Cisco IOS software is configured to automatically compute the tag value for the BGP learned routes and to update the IP routing table:

route-map tag

 match as path 10

 set automatic-tag

!

router bgp 100

 table-map tag

In the following address family configuration mode example, the Cisco IOS software is configured to automatically compute the tag value for the BGP learned routes and to update the IP routing table:

route-map tag

 match as path 10

 set automatic-tag

!

router bgp 100

address-family ipv4 unicast

 table-map tag

Related Commands

Command	Description
address-family ipv4 (BGP)	Places the router in address family configuration mode for configuring routing sessions such as BGP, RIP, or static routing sessions that use standard IP Version 4 address prefixes.
address-family vpnv4	Places the router in address family configuration mode for configuring routing sessions such as BGP, RIP, or static routing sessions that use standard VPN Version 4 address prefixes.
match as-path	Matches a BGP autonomous system path access list.
match ip address	Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, and performs policy routing on packets.
match ip next-hop	Redistributes any routes that have a next hop router address passed by one of the access lists specified.
route-map	Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing.

template peer-policy

To create a peer policy template and enter policy-template configuration mode, use the template peer-policy command in router configuration mode. To remove a peer policy template, use the no form of this command.

template peer-policy policy-template-name

no template peer-policy policy-template-name

Syntax Description

policy-template-name

Name or tag for the peer policy template.

Defaults

Removing a peer policy template by using the no form of this command removes all policy configurations inside of the template.

Command Modes

Address family configuration

Router configuration

Command History

Release	Modification
12.0(24)S	This command was introduced.
12.2(18)S	This command was integrated into Cisco IOS Release 12.2(18)S.
12.3(4)T	This command was integrated into Cisco IOS Release 12.3(4)T.

Usage Guidelines

Peer policy templates are used to group and apply the configuration of commands that are applied within specific address-families and NLRI configuration mode. Peer policy templates are created and configured in peer policy configuration mode. BGP policy commands that are configured for specific address-families or NLRI configuration modes are configured in a peer policy template. The following BGP policy commands are supported by peer policy templates:

•advertisement-interval

•allowas-in

•as-override

•capability

•default-originate

•distribute-list

•dmzlink-bw

•exit-peer-policy

•filter-list

•inherit peer-policy

•maximum-prefix

•next-hop-self

•next-hop-unchanged

•prefix-list

•remove-private-as

•route-map

•route-reflector-client

•send-community

•send-label

•soft-reconfiguration

•unsuppress-map

•weight

Peer policy templates are used to configure BGP policy commands that are configured for neighbors that belong to specific address-families and NLRI configuration modes. Like peer session templates, peer policy templates are configured once and then applied to many neighbors through the direct application of a peer policy template or through inheritance from peer policy templates. The configuration of peer policy templates simplifies the configuration of BGP policy commands that are applied to all neighbors within an autonomous system.

Peer policy templates support direct and indirect inheritance from up to eight peer policy templates. Inherited peer policy templates are configured with sequence numbers like route-maps. An inherited peer policy template, like a route-map, is evaluated starting with the inherit statement with the lowest sequence number and ending with the highest sequence number. However, there is a difference; a peer policy template will not fall through like a route-map. Every sequence is evaluated, and if a BGP policy command is reapplied with different value, it will overwrite any previous value from a lower sequence number.

Peer policy templates support only general policy commands. BGP policy configuration commands that are configured only for specific address families or NLRI configuration modes are configured with peer policy templates.

---

Note A BGP neighbor cannot be configured to work with both peer groups and peer templates. A BGP neighbor can be configured to belong only to a peer group or to inherit policies from only peer templates.

---

Examples

The following example creates a peer policy template named CUSTOMER-A. This peer policy template is configured to inherit the configuration from the peer policy templates named PRIMARY-IN and GLOBAL.

Router(config-router)# template peer-policy CUSTOMER-A

Router(config-router-ptmp)# route-map SET-COMMUNITY in

Router(config-router-ptmp)# filter-list 20 in 

Router(config-router-ptmp)# inherit peer-policy PRIMARY-IN 20

Router(config-router-ptmp)# inherit peer-policy GLOBAL 10

Router(config-router-ptmp)# exit-peer-policy

Router(config-router)#

Related Commands

Command	Description
advertisement-interval	Sets the minimum interval between the sending of BGP routing updates.
allowas-in	Configures PE routers to allow readvertisement of all prefixes containing duplicate autonomous system numbers.
as-override	Configures a PE router to override the ASN of a site with the ASN of a provider.
capability orf prefix-list	Configures outbound route filtering and advertises the capability to send and receive ORF updates to the neighbor routers.
default-originate	Originates a default route to the local router.
distribute-list	Distributes BGP neighbor information as specified in an access list.
dmzlink-bw	Advertises the bandwidth of links that are used to exit an autonomous system.
exit peer-policy	Exits policy-template configuration mode and enters router configuration mode.
filter-list	Sets up a BGP filter.
inherit peer-policy	Configures a peer policy template to inherit the configuration from another peer policy template.
maximum-prefix	Controls how many prefixes can be received from a neighbor.
neighbor inherit peer-policy	Configures a router to send a peer policy template to a neighbor so that the neighbor can inherit the configuration.
neighbor send-label	Enables a BGP router to send MPLS labels with BGP routes to a neighboring BGP router.
next-hop-self	Disables next-hop processing of BGP updates on the router.
next-hop-unchanged	Propagates the next- hop unchanged for iBGP paths to this router.
prefix-list	Specifies a prefix list, a CLNS filter set, or a CLNS filter expression to be used to filter BGP advertisements.
remove-private-as	Removes the private autonomous system number from outbound routing updates.
route-map	Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing.
route-reflector-client	Configures the router as a BGP route reflector and configures the specified neighbor as its client.
send-community	Specifies that the BGP community attribute should be sent to the specified neighbor.
show ip bgp template peer-policy	Displays locally configured peer policy templates.
show ip bgp template peer-session	Displays locally configured peer session templates.
soft-reconfiguration	Configures the Cisco IOS software to start storing updates.
template peer-session	Creates a peer session template and enters session-template configuration mode.
unsuppress-map	Selectively unsuppresses surpressed routes.
weight	Assigns a weight to a neighbor connection.

template peer-session

To create a peer session template and enter session-template configuration mode, use the template peer-session command in router configuration mode. To remove a peer session template, use the no form of this command.

template peer-session session-template-name

no template peer-session session-template-name

Syntax Description

template-name

Name or tag for the peer session template.

Defaults

Removing a peer session template by using the no form of this command removes all session command configurations inside of the template.

Command Modes

Address family configuration

Router configuration

Command History

Release	Modification
12.0(24)S	This command was introduced.
12.2(18)S	This command was integrated into Cisco IOS Release 12.2(18)S.
12.3(4)T	This command was integrated into Cisco IOS Release 12.3(4)T.

Usage Guidelines

Peer session templates are used to group and apply the configuration of general session commands to groups of neighbors that share common 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. The following general session commands are supported by peer session templates:

•description

•disable-connected-check

•ebgp-multihop

•exit peer-session

•inherit peer-session

•local-as

•password

•remote-as

•shutdown

•timers

•translate-update

•update-source

•version

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 simplify 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 peer 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. However, each inherited session template can also contain one indirectly inherited peer session template. So, only one directly applied peer session template and up to seven additional indirectly inherited peer session templates can be applied, allowing you to apply up to a maximum of eight peer session configurations to a neighbor: the configuration from the directly inherited peer session template and the configurations from up to seven indirectly inherited peer session templates. Inherited peer session templates are evaluated first, and the directly applied template will be evaluated and applied last. So, if a general session command is reapplied with a different value, the subsequent value will have priority and overwrite the previous value that was configured in the indirectly inherited template.

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

---

Note A BGP neighbor cannot be configured to work with both peer groups and peer templates. A BGP neighbor can be configured only to belong to a peer group or to inherit policies from peer templates.

---

Examples

The following example creates a peer session template named CORE1. This example inherits the configuration of the peer session template named INTERNAL-BGP.

Router(config-router)# template peer-session CORE1

Router(config-router-stmp)# description CORE-123

Router(config-router-stmp)# update-source loopback 1

Router(config-router-stmp)# inherit peer-session INTERNAL-BGP

Router(config-router-stmp)# exit-peer-session 

Router(config-router)#

Related Commands

Command	Description
description	Configures a description to be displayed by the local or a peer router.
disable-connected-check	Disables connection verification for eBGP peers no more than one hop away when the eBGP peer is configured with a loopback interface.
ebgp-multihop	Accepts or initiates BGP connections to external peers residing on networks that are not directly connected.
exit peer-session	Exits session-template configuration mode and enters router configuration mode.
inherit peer-session	Configures a peer session template to inherit the configuration from another peer session template.
local-as	Allows the customization of the autonomous system number for eBGP peer groupings.
neighbor inherit peer-session	Configures a router to send a peer session template to a neighbor so that the neighbor can inherit the configuration.
neighbor translate-update	Upgrades a router running BGP in the NLRI format to support multiprotocol BGP.
password	Enables MD5 authentication on a TCP connection between two BGP peers.
remote-as	Adds an entry to the BGP or multiprotocol BGP neighbor table.
show ip bgp template peer-policy	Displays locally configured peer policy templates.
show ip bgp template peer-session	Displays locally configured peer session templates.
shutdown	Disables a neighbor or peer group.
template peer-session	Creates a peer policy template and enters policy-template configuration mode.
timers bgp	Adjusts BGP network timers.
update-source	Specifies that the Cisco IOS software allow internal BGP sessions to use any operational interface for TCP connections.
version	Configures the Cisco IOS software to accept only a particular BGP version.

timers active-time

To adjust routing wait time, use the timers active-time command in router configuration mode. To disable this function, use the no form of the command.

timers active-time [time-limit | disabled]

no timers active-time

Syntax Description

time-limit	Enhanced Interior Gateway Routing Protocol (EIGRP) active-time limit (in minutes). The time range is from 1to 4294967295 minutes.
disabled	Disables the timers and permits the routing wait time to remain active indefinitely.

Defaults

This command is disabled by default.

Command Modes

Router configuration

Command History

Release	Modification
10.0	This command was introduced.

Usage Guidelines

In EIGRP, there are timers that control the time the router waits (after sending a query) before declaring the route to be in the stuck in active (SIA) state.

Examples

In the following example, the routing wait time is 200 minutes on the specified route:

router eigrp 5

 timers active-time 200

In the following example, the routing wait time is indefinite on the specified route:

router eigrp 5

 timers active-time disabled

Related Commands

Command	Description
show ip eigrp topology	Displays the EIGRP topology table.

timers basic (ODR)

To adjust On-Demand Routing (ODR) network timers, use the timers basic command in router configuration mode. To restore default ODR timer values, use the no form of this command.

timers basic update invalid holddown flush [sleeptime]

no timers basic

Syntax Description

update	Rate (in seconds) at which updates are sent. This is the fundamental timing parameter of the ODR routing protocol.
invalid	Interval of time (in seconds) after which a route is declared invalid; it should be at least three times the value of the update argument. A route becomes invalid when there is an absence of updates that refresh the route. The route then enters holddown. The route is marked inaccessible and advertised as unreachable. However, the route is still used for forwarding packets.
holddown	Interval (in seconds) during which routing information regarding better paths is suppressed. It should be at least three times the value of the update argument. A route enters into a holddown state when an update packet is received that indicates the route is unreachable. The route is marked inaccessible and advertised as unreachable. However, the route is still used for forwarding packets. When holddown expires, routes advertised by other sources are accepted and the route is no longer inaccessible.
flush	Amount of time (in seconds) that must pass before the route is removed from the routing table; the interval specified must be at least the sum of the invalid and holddown arguments. If it is less than this sum, the proper holddown interval cannot elapse, which results in a new route being accepted before the holddown interval expires.
sleeptime	(Optional) Interval (in milliseconds) for postponing routing updates in the event of a flash update. The sleeptime value should be less than the update time. If the sleeptime is greater than the update time, routing tables will become unsynchronized.

Defaults

ODR uses the following default values if this command is not configured or if the no form of this command is entered:

update: 90 seconds
invalid: 270 seconds
holddown: 280 seconds
flush: 630 seconds
sleeptime: 0 milliseconds

Command Modes

Router configuration

Command History

Release	Modification
10.0	This command was introduced.

Usage Guidelines

The basic timing parameters for ODR are adjustable. Because this routing protocol is executing a distributed, asynchronous routing algorithm, it is important that these timers be the same for all routers and access servers in the network.

---

Note The current and default timer values are displayed in the output of the show ip protocols EXEC command. The relationships of the various timers should be preserved as described in the syntax description table.

---

Examples

In the following example, updates are configured to be broadcast every 5 seconds. If a reply is not received from a peer within 15 seconds, the route is declared unusable. Further information the dead peer is suppressed for an additional 15 seconds. At the end of the suppression period, the route is flushed from the routing table.

Router(config)# router odr 

Router(config-router)# timers basic 5  15  15  30 

Router(config-router)# end 

---

Note When configuring a short update period, you run the risk of congesting slow-speed serial lines; however, this is less of a concern on high-speed links, such as Fast Ethernet, Gigabit Ethernet, and T1-rate serial links. Also, if you have many routes in your updates, you can cause the routers to spend an excessive amount of time processing updates.

---

Related Commands

Command	Description
cdp timer	Specifies how often the Cisco IOS software sends CDP updates,
router odr	Configures an ODR process on a Cisco router.

timers basic (RIP)

To adjust Routing Information Protocol (RIP) network timers, use the timers basic command in router configuration mode. To restore the default timers, use the no form of this command.

timers basic update invalid holddown flush

no timers basic

Syntax Description

update	Rate (in seconds) at which updates are sent. This is the fundamental timing parameter of the routing protocol. The default is 30 seconds.
invalid	Interval of time (in seconds) after which a route is declared invalid; it should be at least three times the value of the update argument. A route becomes invalid when there is an absence of updates that refresh the route. The route then enters into a holddown state. The route is marked inaccessible and advertised as unreachable. However, the route is still used for forwarding packets. The default is 180 seconds.
holddown	Interval (in seconds) during which routing information regarding better paths is suppressed. It should be at least three times the value of the update argument. A route enters into a holddown state when an update packet is received that indicates the route is unreachable. The route is marked inaccessible and advertised as unreachable. However, the route is still used for forwarding packets. When holddown expires, routes advertised by other sources are accepted and the route is no longer inaccessible. The default is 180 seconds.
flush	Amount of time (in seconds) that must pass before the route is removed from the routing table; the interval specified should be greater than the value of the invalid argument. If it is less than this sum, the proper holddown interval cannot elapse, which results in a new route being accepted before the holddown interval expires. The default is 240 seconds.

Defaults

update: 30 seconds
invalid: 180 seconds
holddown: 180 seconds
flush: 240 seconds

Command Modes

Router configuration

Command History

Release	Modification
10.0	This command was introduced.

Usage Guidelines

The basic timing parameters for RIP are adjustable. Because RIP is executing a distributed, asynchronous routing algorithm, these timers must be the same for all routers and access servers in the network.

---

Note The current and default timer values can be seen by inspecting the output of the show ip protocols EXEC command. The relationships of the various timers should be preserved as described previously.

---

Examples

The following example sets updates to be broadcast every 5 seconds. If a router is not heard from in 15 seconds, the route is declared unusable. Further information is suppressed for an additional 15 seconds. At the end of the suppression period, the route is flushed from the routing table.

router rip

 timers basic 5  15  15  30 

---

Note By setting a short update period, you run the risk of congesting slow-speed serial lines. A short update period can be a concern on faster-speed Ethernets and T1-rate serial lines. Also, if you have many routes in your updates, you can cause the routers to spend an excessive amount of time processing updates.

---

timers bgp

To adjust BGP network timers, use the timers bgp command in router configuration mode. To reset the BGP timing defaults, use the no form of this command.

timers bgp keepalive holdtime

no timers bgp

Syntax Description

keepalive	Frequency (in seconds) with which the Cisco IOS software sends keepalive messages to its peer. The default is 60 seconds. The range is from 0 to 65535.
holdtime	Interval (in seconds) after not receiving a keepalive message that the software declares a peer dead. The default is 180 seconds. The range is from 0 to 65535.

Defaults

keepalive: 60 seconds

holdtime: 180 seconds

Command Modes

Router configuration

Command History

Release	Modification
10.0	This command was introduced.

Examples

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

timers bgp 70 210

Related Commands

Command	Description
clear ip bgp peer-group	Removes all the members of a BGP peer group.
router bgp	Configures the BGP routing process.
show ip bgp	Displays entries in the BGP routing table.

timers lsa arrival

To set the minimum interval at which the software accepts the same link-state advertisement (LSA) from OSPF neighbors, use the timers lsa arrival command in router configuration mode. To restore the default value, use the no form of this command.

timers lsa arrival milliseconds

no timers lsa arrival

Syntax Description

milliseconds

Minimum delay in milliseconds that must pass between acceptance of the same LSA arriving from neighbors. The range is 0 to 600,000 milliseconds. The default is 1000 milliseconds.

Defaults

1000 milliseconds

Command Modes

Router configuration

Command History

Release	Modification
12.0(25)S	This command was introduced.

Usage Guidelines

The timers lsa arrival command controls the minimum interval for accepting the same LSA. The "same LSA" is defined as an LSA instance that contains the same LSA ID number, LSA type, and advertising router ID. If an instance of the same LSA arrives sooner than the interval that is set, the LSA is dropped.

We suggest you keep the milliseconds value of the timers lsa arrival command less than or equal to the neighbors' hold-interval value of the timers throttle lsa all command.

Examples

The following example sets the minimum interval for accepting the same LSA at 2000 milliseconds:

router ospf 1

 log-adjacency-changes

 timers throttle lsa all 200 10000 45000

 timers lsa arrival 2000

 network 10.10.4.0 0.0.0.255 area 24

 network 10.10.24.0 0.0.0.255 area 24

Related Commands

Command	Description
show ip ospf timers rate-limit	Displays all of the LSAs in the rate limit queue.
timers throttle lsa all	Sets rate-limiting values for LSAs being generated.

timers nsf route-hold

To set the route-hold timer to determine how long an NSF-aware router that is running Enhanced Interior Gateway Routing Protocol (EIGRP) will hold routes for an inactive peer, use the timers nsf route-hold command in router configuration mode. To return the route-hold timer to the default value, use the no form of this command.

timers nsf route-hold seconds

no timers nsf route-hold

Syntax Description

seconds

The time, in seconds, that EIGRP will hold routes for an inactive peer. The configurable time range is from 20 to 300 seconds.

Defaults

EIGRP NSF awareness is enabled by default. The default value for the route-hold timer is 240 seconds.

Command Modes

Router configuration

Command History

Release	Modification
12.2(15)T	This command was introduced.

Usage Guidelines

The route-hold timer sets the maximum period of time that the NSF-aware router will hold known routes for an NSF-capable neighbor during a switchover operation or a well-known failure condition. The route-hold timer is configurable so that you can tune network performance and avoid undesired effects, such as "black holing" routes if the switchover operation takes too much time. When this timer expires, the NSF-aware router scans the topology table and discards any stale routes, allowing EIGRP peers to find alternate routes instead of waiting during a long switchover operation.

Examples

The following configuration example sets the route-hold timer value for an NSF-aware router. In the example, the route-hold timer is set to 2 minutes:

Router(config-router)# timers nsf route-hold 120

Related Commands

Command	Description
debug eigrp nsf	Displays EIGRP NSF-specific events in the console of a router.
debug ip eigrp notifications	Displays EIGRP events and notifications in the console of the router.
show ip eigrp neighbors	Displays the neighbors discovered by IP EIGRP.
show ip protocols	Displays the parameters and current state of the active routing protocol process.

timers pacing flood

To configure link-state advertisement (LSA) flood packet pacing, use the timers pacing flood command in router configuration mode. To restore the default flood packet pacing value, use the no form of this command.

timers pacing flood milliseconds

no timers pacing flood

Syntax Description

milliseconds

Time (in milliseconds) at which LSAs in the flooding queue are paced in between updates. The configurable range is from 5 milliseconds to 100 milliseconds. The default value is 33 milliseconds.

Defaults

33 milliseconds

Command Modes

Router configuration

Command History

Release	Modification
12.2(4)T	This command was introduced.

Usage Guidelines

Configuring Open Shortest Path First (OSPF) flood pacing timers allows you to control interpacket spacing between consecutive link-state update packets in the OSPF transmission queue. This command allows you to control the rate at which LSA updates occur so that high CPU or buffer utilization that can occur when an area is flooded with a very large number of LSAs can be reduced.

The default settings for OSPF packet pacing timers are suitable for the majority of OSPF deployments. Do not change the packet pacing timers unless all other options to meet OSPF packet flooding requirements have been exhausted. Specifically, network operators should prefer summarization, stub area usage, queue tuning, and buffer tuning before changing the default flood timers. Furthermore, there are no guidelines for changing timer values; each OSPF deployment is unique and should be considered on a case-by-case basis. The network operator assumes risks associated with changing the default flood timer values.

Examples

The following example configures LSA flood packet-pacing updates to occur in 55-millisecond intervals for OSPF routing process 1:

Router(config)# router ospf 1

Router(config-router)# timers pacing flood 55

Related Commands

Command	Description
show ip ospf	Displays general information about OSPF routing processes.
timers pacing lsa-group	Changes the interval at which OSPF LSAs are collected into a group and refreshed, checksummed, or aged.
timers pacing retransmission	Configures LSA retransmission packet pacing.

timers pacing lsa-group

To change the interval at which Open Shortest Path First (OSPF) link-state advertisements (LSAs) are collected into a group and refreshed, checksummed, or aged, use the timers pacing lsa-group command in router configuration mode. To restore the default value, use the no form of this command.

timers pacing lsa-group seconds

no timers pacing lsa-group

Syntax Description

seconds

Number of seconds in the interval at which LSAs are grouped and refreshed, checksummed, or aged. The range is from 10 to 1800 seconds. The default value is 240 seconds.

Defaults

The default interval for this command is 240 seconds. OSPF LSA group pacing is enabled by default.

Command Modes

Router configuration

Command History

Release	Modification
11.3 AA	This command was introduced.
12.2(4)T	The syntax of this command was changed from timers lsa-group-pacing to timers pacing lsa-group.

Usage Guidelines

This command allows you to control the rate at which LSA updates occur so that high CPU or buffer utilization that can occur when an area is flooded with a very large number of LSAs can be reduced. The default settings for OSPF packet pacing timers are suitable for the majority of OSPF deployments. Do not change the packet pacing timers unless all other options to meet OSPF packet flooding requirements have been exhausted. Specifically, network operators should prefer summarization, stub area usage, queue tuning, and buffer tuning before changing the default flooding timers. Furthermore, there are no guidelines for changing timer values; each OSPF deployment is unique and should be considered on a case-by-case basis. The network operator assumes the risks associated with changing the default timer values.

Cisco IOS software groups the periodic refresh of LSAs to improve the LSA packing density for the refreshes in large topologies. The group timer controls the interval used for group refreshment of LSAs; however, this timer does not change the frequency that individual LSAs are refreshed (the default refresh rate is every 30 minutes).

The duration of the LSA group pacing is inversely proportional to the number of LSAs the router is handling. For example, if you have about 10,000 LSAs, decreasing the pacing interval would benefit you. If you have a very small database (40 to 100 LSAs), increasing the pacing interval to 10 to 20 minutes might benefit you slightly.

Examples

The following example configures OSPF group packet-pacing updates between LSA groups to occur in 60-second intervals for OSPF routing process 1:

Router(config)# router ospf 1

Router(config-router)# timers pacing lsa-group 60

Related Commands

Command	Description
show ip ospf	Displays general information about OSPF routing processes.
timers pacing flood	Configures LSA flood packet pacing.
timers pacing retransmission	Configures LSA retransmission packet pacing.

timers pacing retransmission

To configure link-state advertisement (LSA) retransmission packet pacing, use the timers pacing retransmission command in router configuration mode. To restore the default retransmission packet pacing value, use the no form of this command.

timers pacing retransmission milliseconds

no timers pacing retransmission

Syntax Description

milliseconds

The time (in milliseconds) at which LSAs in the retransmission queue are paced. The configurable range is from 5 milliseconds to 200 milliseconds. The default value is 66 milliseconds.

Defaults

66 milliseconds

Command Modes

Router configuration

Command History

Release	Modification
12.2(4)T	This command was introduced.

Usage Guidelines

Configuring OSPF retransmission pacing timers allow you to control interpacket spacing between consecutive link-state update packets in the OSPF retransmission queue. This command allows you to control the rate at which LSA updates occur so that high CPU or buffer utilization that can occur when an area is flooded with a very large number of LSAs can be reduced. The default settings for OSPF packet retransmission pacing timers are suitable for the majority of OSPF deployments. Do not change the packet retransmission pacing timers unless all other options to meet OSPF packet flooding requirements have been exhausted. Specifically, network operators should prefer summarization, stub area usage, queue tuning, and buffer tuning before changing the default flooding timers. Furthermore, there are no guidelines for changing timer values; each OSPF deployment is unique and should be considered on a case-by-case basis. The network operator assumes risks associated with changing the default packet retransmission pacing timer values.

Examples

The following example configures LSA flood pacing updates to occur in 55-millisecond intervals for OSPF routing process 1:

Router(config)# router ospf 1

Router(config-router)# timers pacing retransmission 55

Related Commands

Command	Description
show ip ospf	Displays general information about OSPF routing processes.
timers pacing flood	Configures LSA flood packet pacing.
timers pacing lsa-group	Changes the interval at which OSPF LSAs are collected into a group and refreshed, checksummed, or aged.

timers spf

The timers spf command is replaced by the timers throttle spf command. Refer to the timers throttle spf command reference page for instructions on using the new command.

timers throttle lsa all

To set rate-limiting values for OSPF link-state advertisement (LSA) generation, use the timers throttle lsa all command in router configuration mode. To restore the default values, use the no form of this command.

timers throttle lsa all start-interval hold-interval max-interval

no timers throttle lsa all

Syntax Description

start-interval	Minimum delay in milliseconds for the generation of LSAs. The first instance of LSA is always generated immediately upon a local OSPF topology change. The generation of the next LSA is not before the start interval. The range is 0 to 600,000 milliseconds. The default is 0 milliseconds, which means no delay; the LSA is sent immediately.
hold-interval	Incremental time in milliseconds. This value is used to calculate the subsequent rate limiting times for LSA generation. The range is 1 to 600,000 milliseconds. The default value is 5000 milliseconds.
max-interval	Maximum wait time in milliseconds between generation of the same LSA. The range is 1 to 600,000 milliseconds. The default value is 5000 milliseconds.

Defaults

start-interval: 0 milliseconds
hold-interval: 5000 milliseconds
max-interval: 5000 milliseconds

Command Modes

Router configuration

Command History

Release	Modification
12.0(25)S	This command was introduced.

Usage Guidelines

The "same LSA" is defined as an LSA instance that contains the same LSA ID number, LSA type, and advertising router ID. We suggest you keep the milliseconds value of the timers lsa arrival command less than or equal to the hold-interval value of the timers throttle lsa all command.

Examples

This example customizes OSPF LSA throttling so that the start interval is 200 milliseconds, the hold interval is 10,000 milliseconds, and the maximum interval is 45,000 milliseconds. The minimum interval between instances of receiving the same LSA is 2000 milliseconds.

router ospf 1

 log-adjacency-changes

 timers throttle lsa all 200 10000 45000

 timers lsa arrival 2000

 network 10.10.4.0 0.0.0.255 area 24

 network 10.10.24.0 0.0.0.255 area 24

Related Commands

Command	Description
show ip ospf	Displays information about OSPF routing processes.
timers lsa arrival	Sets the minimum interval at which the software accepts the same LSA from OSPF neighbors.

timers throttle spf

To turn on OSPF SPF throttling, use the timers throttle spf command in router configuration mode. To turn off SPF throttling, use the no form of this command.

timers throttle spf spf-start spf-hold spf-max-wait

no timers throttle spf spf-start spf-hold spf-max-wait

Syntax Description

spf-start	Indicates the initial SPF schedule delay in milliseconds. Value range is 1 to 600000 milliseconds.
spf-hold	Indicates the minimum hold time between two consecutive SPF calculations. Value range is 1 to 600000 milliseconds.
spf-maximum	Indicates the maximum wait time between two consecutive SPF calculations. Value range is 1 to 600000 milliseconds.

Defaults

SPF throttling is not set.

Command Modes

Router configuration

Command History

Release	Modification
12.2(14)S	This command was introduced.

Usage Guidelines

The timers throttle spf command replaces the timers spf-interval command.

The first wait interval between SPF calculations is the amount of time in milliseconds specified by the spf-start argument. Each consecutive wait interval is two times the current hold level in milliseconds until the wait time reaches the maximum time in milliseconds as specified by the spf-maximum argument. Subsequent wait times remain at the maximum until the values are reset or an LSA is received between SPF calculations.

Examples

The following example shows a router configured with the start, hold, and maximum interval values for the timers throttle spf command set at 5, 1,000, and 90,000 milliseconds, respectively.

router ospf 1

 router-id 10.10.10.2

 log-adjacency-changes

 timers throttle spf 5 1000 90000 

 redistribute static subnets

 network 10.21.21.0 0.0.0.255 area 0

 network 10.22.22.0 0.0.0.255 area 00

traffic-share balanced

To control how traffic is distributed among routes when there are multiple routes for the same destination network that have different costs, use the traffic-share balanced command in router configuration mode. To disable this function, use the no form of the command.

traffic-share balanced

no traffic-share balanced

Syntax Description

This command has no arguments or keywords.

Defaults

Traffic is distributed proportionately to the ratios of the metrics.

Command Modes

Router configuration

Command History

Release	Modification
10.0	This command was introduced.

Usage Guidelines

This command applies to only Enhanced Interior Gateway Routing Protocol (EIGRP). With the default setting, routes that have higher metrics represent less-preferable routes and get less traffic.

Examples

In the following example, traffic is balanced across multiple routes:

router eigrp 5

 traffic-share balanced

 variance 1 

Related Commands

Command	Description
variance (EIGRP)	Controls load balancing in an EIGRP network.

traffic-share min

To configure traffic to use minimum cost routes, when there are multiple routes that have different cost routes to the same destination network, use the traffic-share min across-interfaces command in router configuration mode. To disable this function, use the no form of this command.

traffic-share min {across-interfaces}

no traffic-share min {across-interfaces}

Syntax Description

This command has no arguments or keywords.

Defaults

Traffic is configured to use minimum cost paths.

Command Modes

Router configuration

Command History

Release	Modification
10.0	This command was introduced.
11.0(3)	This command became protocol independent when the across-interfaces