-
Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols, Release 12.3 T
-
IP Routing Protocol Commands: T Through V
-
Introduction
-
IP Routing Protocol Commands: A
-
IP Routing Protocol Commands: B
-
IP Routing Protocols Commands: C through H
-
IP Routing Protocols Commands: ignore lsa mospf through ip ospf transmit-delay
-
IP Routing Protocol Commands: ip policy route-map through is-type
-
IP Routing Protocols Commands: K through M
-
IP Routing Protocols Commands: N
-
IP Routing Protocols Commands: O through R
-
IP Routing Protocols Commands: send-lifetime through set-overload-bit
-
IP Routing Protocols Commands: show bgp nsap through show ip bgp update-group
-
IP Routing Protocols Commands: show ip cache policy through show ip local policy
-
IP Routing Protocol Commands: show ip ospf through synchronization
-
Table Of Contents
ip authentication key-chain eigrp
ip ospf database-filter all out
ignore lsa mospf
To suppress the sending of syslog messages when the router receives link-state advertisement (LSA) Type 6 Multicast OSPF (MOSPF) packets, which are unsupported, use the ignore lsa mospf command in router configuration mode. To restore the sending of syslog messages, use the no form of this command.
ignore lsa mospf
no ignore lsa mospf
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default. Each MOSPF packet causes the router to send a syslog message.
Command Modes
Router configuration
Command History
Usage Guidelines
Cisco routers do not support LSA Type 6 MOSPF packets, and they generate syslog messages if they receive such packets. If the router is receiving many MOSPF packets, you might want to configure the router to ignore the packets and thus prevent a large number of syslog messages.
Examples
The following example configures the router to suppress the sending of syslog messages when it receives MOSPF packets:
router ospf 109ignore lsa mospfimport ipv4
To configure an import map to import IPv4 prefixes from the global routing table to a VRF table, use the import ipv4 command in VRF configuration submode. To remove the import map, use the no form of this command.
import ipv4 unicast | multicast [prefix-limit] route-map
no import ipv4 unicast | multicast [prefix-limit] route-map
Syntax Description
Defaults
No default behavior or values
Command Modes
VRF configuration submode
Command History
Usage Guidelines
IP prefixes that are defined for import are processed through a match clause in a route map. The prefixes that pass through the route map are imported into the VRF. A maximum of 5 VRFs per router can be configured to import IPv4 prefixes from the global routing table. 1000 prefixes per VRF are imported by default. You can manually configure from 1 to 2147483647 prefixes for each VRF. We recommend that you use caution if you manually configure the prefix import limit. Configuring the router to import too many prefixes can interrupt normal router operation. Only IPv4 unicast and multicast prefixes can be imported to a VRF with this feature. IPv4 prefixes imported into a VRF using this feature cannot be imported into a VPNv4 VRF.
No MPLS or Route Target Configuration is Required
No MPLS or route target (import/export) configuration is required.
Import Behavior
Import actions are triggered when a new routing update is received or when routes are withdrawn. During the initial BGP update period, the import action is postponed to allow BGP to convergence more quickly. Once BGP converges, incremental BGP updates are evaluated immediately and qualified prefixes are imported as they are received.
Examples
The following example, beginning in global configuration mode, imports all unicast prefixes from the 10.24.240.0/22 subnet into the VRF named GREEN. An IP prefix list is used to define the imported IPv4 prefixes. The route map is attached to the Ethernet 0 interface. Unicast RPF verification for VRF GREEN is enabled.
ip prefix-list COLORADO permit 10.24.240.0/22!ip vrf GREENrd 100:10import ipv4 unicast 1000 map UNICASTexitroute-map UNICAST permit 10match ip address prefix-list COLORADOexitinterface Ethernet 0ip policy route-map UNICASTip verify unicast vrf GREEN permitendRelated Commands
inherit peer-policy
To configure a peer policy template to inherit the configuration from another peer policy template, use the inherit peer-policy command in policy-template configuration mode. To remove an inherit statement from a peer policy template, use the no form of this command.
inherit peer-policy policy-template sequence-number
no inherit peer-policy policy-template sequence-number
Syntax Description
Defaults
No default behavior or values
Command Modes
Policy-template configuration
Command History
Usage Guidelines
The inherit peer-policy command is used to configure a peer policy template to inherit the configuration of another peer policy template. Peer policy templates support inheritance and a peer can directly and indirectly inherit up to seven 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. However, peer policy templates do not fall through. Every sequence is evaluated. If a BGP policy command is reapplied with a different value, it will overwrite any previous value from a lower sequence number.
Note
A Border Gateway Protocol (BGP) routing process cannot be configured to be a member of a peer group and to use peer templates for group configurations. You must use one method or the other. We recommend peer templates because they provide improved performance and scalability.
Examples
In the following example, a peer policy template named CUSTOMER-A is created. 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-ARouter(config-router-ptmp)# route-map SET-COMMUNITY inRouter(config-router-ptmp)# filter-list 20 inRouter(config-router-ptmp)# inherit peer-policy PRIMARY-IN 20Router(config-router-ptmp)# inherit peer-policy GLOBAL 10Router(config-router-ptmp)# exit-peer-policyRouter(config-router)#Related Commands
inherit peer-session
To configure a peer session template to inherit the configuration from another peer session template, use the inherit peer-session command in session-template configuration mode. To remove an inherit statement from a peer session template, use the no form of this command.
inherit peer-session template-name
no inherit peer-session template-name
Syntax Description
Defaults
No default behavior or values
Command Modes
Session-template configuration
Command History
Usage Guidelines
The inherit peer-session command is used to configure a peer session template to inherit the configuration of another peer session template. 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 indirectly inherited session template can also contain an indirectly inherited template. So, a peer can directly inherit only one peer session template and indirectly inherit up to seven additional indirectly inherited peer session templates, allowing you to apply up to a maximum of eight inherited peer session configurations.
Note
Indirectly inherited peer session templates are evaluated first, and the directly applied (locally configured) peer session template is evaluated last. 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. In other words, an overlapping statement from a local configuration will override the statement from the inherited configuration.
Examples
In the following example, a peer session template named CORE1 is created. This example inherits the configuration of the peer session template named INTERNAL-BGP.
Router(config-router)# template peer-session CORE1Router(config-router-stmp)# description CORE-123Router(config-router-stmp)# update-source loopback 1Router(config-router-stmp)# inherit peer-session INTERNAL-BGPRouter(config-router-stmp)# exit-peer-sessionRouter(config-router)#Related Commands
input-queue
The input-queue command defines the number of received, but not yet processed RIP update packets contained in the Routing Information Protocol (RIP) input queue. Use the input-queue command in router configuration mode. To remove the configured depth and restore the default depth, use the no form of this command.
input-queue depth
no input-queue
Syntax Description
Defaults
A depth of 50.
Command Modes
Router configuration
Command History
11.0
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
Consider using the input-queue command if you have a high-end router that is sending at high speed to a low-speed router that might not be able to receive at the high speed. Configuring this command will help prevent the routing table from losing information.
Another way to prevent the routing table from losing information is to use the output-delay command to change the interpacket delay for RIP updates.
Examples
The following example sets the depth of the RIP input queue to 100:
router ripinput-queue 100Related Commands
ip as-path access-list
To configure an autonomous system path filter using a regular expression, use the ip as-path access-list command in global configuration mode. To delete the autonomous system path filter and remove it from the running configuration file, use the no form of this command.
ip as-path access-list acl-number permit | deny regexp
no ip as-path access-list acl-number
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Command History
Usage Guidelines
The ip as-path access-list command is configure an autonomous system path filter. You can apply autonomous system path filters to both inbound and outbound BGP paths. Each filter is defined by the regular expression. If the regular expression matches the representation of the autonomous system path of the route as an ASCII string, then the permit or deny condition applies. The autonomous system path should not contain the local autonomous system number.
Examples
In the following example, an autonomous system path access list (number 500) is defined to configure the router to not advertise any path through or from autonomous system 65535 to the 10.20.2.2 neighbor:
Router(config)# ip as-path access-list 500 deny _65535_Router(config)# ip as-path access-list 500 deny ^65535$Router(config)# !Router(config)# router bgp 50000Router(config-router)# neighbor 192.168.1.1 remote-as 65535Router(config-router)# neighbor 10.20.2.2 remote-as 40000Router(config-router)# neighbor 10.20.2.2 filter-list 1 outRouter(config-router)# endIn the following example, the router is configured to deny all updates with private autonomous system paths:
Router(config)# ip as-path access-list 1 deny (_64[6-9][0-9][0-9]_|_65[0-9][0-9][0-9]_)Router(config)# ip as-path access-list 1 permit .*Related Commands
ip authentication key-chain eigrp
To enable authentication of Enhanced Interior Gateway Routing Protocol (EIGRP) packets, use the ip authentication key-chain eigrp command in interface configuration mode. To disable such authentication, use the no form of this command.
ip authentication key-chain eigrp as-number key-chain
no ip authentication key-chain eigrp as-number key-chain
Syntax Description
as-number
Autonomous system number to which the authentication applies.
key-chain
Name of the authentication key chain.
Defaults
No authentication is provided for EIGRP packets.
Command Modes
Interface configuration
Command History
Examples
The following example applies authentication to autonomous system 2 and identifies a key chain named SPORTS:
ip authentication key-chain eigrp 2 SPORTSRelated Commands
ip authentication mode eigrp
To specify the type of authentication used in Enhanced Interior Gateway Routing Protocol (EIGRP) packets, use the ip authentication mode eigrp command in interface configuration mode. To disable that type of authentication, use the no form of this command.
ip authentication mode eigrp as-number md5
no ip authentication mode eigrp as-number md5
Syntax Description
Defaults
No authentication is provided for EIGRP packets.
Command Modes
Interface configuration
Command History
Usage Guidelines
Configure authentication to prevent unapproved sources from introducing unauthorized or false routing messages. When authentication is configured, an MD5 keyed digest is added to each EIGRP packet in the specified autonomous system.
Examples
The following example configures the interface to use MD5 authentication in EIGRP packets in autonomous system 10:
ip authentication mode eigrp 10 md5Related Commands
ip bandwidth-percent eigrp
To configure the percentage of bandwidth that may be used by Enhanced Interior Gateway Routing Protocol (EIGRP) on an interface, use the ip bandwidth-percent eigrp command in interface configuration mode. To restore the default value, use the no form of this command.
ip bandwidth-percent eigrp as-number percent
no ip bandwidth-percent eigrp as-number percent
Syntax Description
Defaults
50 percent
Command Modes
Interface configuration
Command History
Usage Guidelines
EIGRP will use up to 50 percent of the bandwidth of a link, as defined by the bandwidth interface configuration command. This command may be used if some other fraction of the bandwidth is desired. Note that values greater than 100 percent may be configured. The configuration option may be useful if the bandwidth is set artificially low for other reasons.
Examples
The following example allows EIGRP to use up to 75 percent (42 kbps) of a 56-kbps serial link in autonomous system 209:
interface serial 0bandwidth 56ip bandwidth-percent eigrp 209 75Related Commands
ip bgp fast-external-fallover
To configure per-interface fast external fallover, use the ip bgp fast-external-fallover command in interface configuration mode. To remove a per-interface fast external fallover configuration, use the no form of this command.
ip bgp fast-external-fallover [permit | deny]
no ip bgp fast-external-fallover [permit | deny]
Syntax Description
permit
Allows per-interface fast external fallover.
deny
Prevents per-interface fast external fallover.
Defaults
Global fast external fallover is enabled by default in Cisco IOS software.
Command Modes
Interface configuration
Command History
12.0ST
This command was introduced.
12.1
This command was integrated into Cisco IOS Release 12.1.
Usage Guidelines
The ip bgp fast-external-fallover command is used to configure per-interface fast external fallover, overriding the global configuration. Entering the permit keyword enables fast external fallover. Entering the deny keyword disables fast external fallover. Entering the no form of this command, returns the router to the global configuration.
Examples
The following example enables per-interface fast-external-fallover on interface Ethernet 0/0:
Router(config)# interface ethernet 0/0Router(config-if)# ip bgp fast-external-fallover permitRelated Commands
ip bgp-community new-format
To configure BGP to display communities in the format AA:NN (autonomous system:community number/4-byte number), use the ip bgp-community new-format command in global configuration mode. To configure BGP to display communities as a 32-bit number, use the no form of this command.
ip bgp-community new-format
no ip bgp-community new-format
Syntax Description
This command has no argument or keywords.
Defaults
BGP communities (also when entered in the AA:NN format) are displayed as a 32-bit numbers if this command is not enabled or if the no form is entered.
Command Modes
Global configuration
Command History
Usage Guidelines
The ip bgp-community new-format command is used to configure the local router to display BGP communities in the AA:NN format to conform with RFC-1997. This command only affects the format in which BGP communities are displayed; it does not affect the community or community exchange. However, expanded IP community lists that match locally configured regular expressions may need to be updated to match on the AA:NN format instead of the 32-bit number.
RFC 1997, BGP Communities Attribute, specifies that a BGP community is made up of two parts that are each 2 bytes long. The first part is the autonomous system number and the second part is a 2-byte number defined by the network operator.
Examples
In the following example, a router that uses the 32-bit number community format is upgraded to use the AA:NN format:
Router(config)# ip bgp-community new-formatThe following sample output shows how BGP community numbers are displayed when the ip bgp-community new-format command is enabled:
Router# show ip bgp 10.0.0.0BGP routing table entry for 10.0.0.0/8, version 4Paths: (2 available, best #2, table Default-IP-Routing-Table)Advertised to non peer-group peers:10.0.33.353510.0.33.35 from 10.0.33.35 (192.168.3.3)Origin incomplete, metric 10, localpref 100, valid, externalCommunity: 1:1Local0.0.0.0 from 0.0.0.0 (10.0.33.34)Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, bestRelated Commands
ip community-list
To create or configure a Border Gateway Protocol (BGP) community list and to control access to it, use the ip community-list command in global configuration command. To delete the community list, use the no form of this command.
ip community-list {standard | standard list-name {deny | permit} [community-number] [AA:NN] [internet] [local-AS] [no-advertise] [no-export]} | {expanded | expanded list-name {deny | permit} regexp}
no ip community-list standard | expanded | {expanded | standard} list-name
Syntax Description
Defaults
BGP community exchange is not enabled by default. It is enabled on a per-neighbor basis with the neighbor send-community command.
The Internet community is applied to all routes or prefixes by default, until any other community value is configured with this command or the set community command.
Once a permit value has been configured to match a given set of communities, the community list defaults to an implicit deny for all other community values.
Community values entered in the new format (AA:NN) are converted to 32-bit numbers if the ip bgp-community new-format command is not enabled on the local router.
Defaults
Global configuration
Command History
Usage Guidelines
The ip community-list command is used to configure BGP community filtering. BGP community values are configured as a 32-bit number (old format) or as a 4-byte number (new format). The new community format is enabled when the ip bgp-community new-format command is entered in global configuration mode. The new community format consists of a 4-byte value. The first two bytes represent the autonomous system number, and the trailing two bytes represent a user-defined network number. Named and numbered community lists are supported. BGP community attribute exchange between BGP peers is enabled when the neighbor send-community command is configured for the specified neighbor. The BGP community attribute is defined in RFC-1997 and RFC-1998.
Standard Community Lists
Standard community lists are used to configure well-known communities and specific community numbers. A maximum of 16 communities can be configured in a standard community list. If you attempt to configure more than 16 communities, the trailing communities that exceed the limit are not processed or saved to the running configuration file.
Expanded Community Lists
Expanded community lists are used to filter communities using a regular expression. Regular expressions are used to configure patterns to match community attributes. The order for matching using the * or + character is longest construct first. Nested constructs are matched from the outside in. Concatenated constructs are matched beginning at the left side. If a regular expression can match two different parts of an input string, it will match the earliest part first. For more information about configuring regular expressions, see the Regular Expressions appendix of the Cisco IOS Terminal Services Configuration Guide.
Community List Processing
When multiple values are configured in the same community list statement, a logical AND condition is created. All community values must match to satisfy an AND condition. When multiple values are configured in separate community list statements, a logical OR condition is created. The first list that matches a condition is processed.
Examples
In the following example, a standard community list is configured that permits routes that from network 10 in autonomous system 50000:
Router(config)# ip community-list 1 permit 50000:10In the following example, a standard community list is configured that permits only routes from peers in the same autonomous system or from subautonomous system peers in the same confederation:
Router(config)# ip community-list 1 permit no-exportIn the following example, a standard community list is configured to deny routes that carry communities from network 40 in autonomous system 65534 and from network 60 in autonomous system 65412. This example shows a logical AND condition; all community values must match in order for the list to be processed.
Router(config)# ip community-list 2 deny 65534:40 65412:60In the following example, a named standard community list is configured that permits all routes within the local autonomous system or permits routes from network 20 in autonomous system 40000. This example shows a logical OR condition; the first match is processed.
Router(config)# ip community-list standard RED permit local-ASRouter(config)# ip community-list standard RED permit 40000:20In the following example, an expanded community list is configured that will deny routes that carry communities from any private autonomous system:
Router(config)# ip community-list 500 deny _64[6-9][0-9][0-9]_|_65[0-9][0-9][0-9]_In the following example, a named expanded community list configured that denies routes from network 1 through 99 in autonomous system 50000:
Router(config)# ip community-list expanded BLUE deny 50000:[0-9][0-9]_Related Commands
ip default-network
To select a network as a candidate route for computing the gateway of last resort, use the ip default-network command in global configuration mode. To remove a route, use the no form of this command.
ip default-network network-number
no ip default-network network-number
Syntax Description
Defaults
If the router has a directly connected interface onto the specified network, the dynamic routing protocols running on that router will generate (or source) a default route. For Router Information Protocol (RIP), this is flagged as the pseudonetwork 0.0.0.0; for Interior Gateway Routing Protocol (IGRP), it is the network itself, flagged as an exterior route.
Command Modes
Global configuration
Command History
Usage Guidelines
The Cisco IOS software uses both administrative distance and metric information to determine the default route. Multiple ip default-network commands can be given. All candidate default routes, both static (that is, flagged by the ip default-network command) and dynamic, appear in the routing table preceded by an asterisk.
If the IP routing table indicates that the specified network number is subnetted and a nonzero subnet number is specified, then the system will automatically configure a static summary route. This static summary route is configured instead of a default network. The effect of the static summary route is to cause traffic destined for subnets that are not explicitly listed in the IP routing table to be routed using the specified subnet.
Examples
The following example defines a static route to network 10.0.0.0 as the static default route:
ip route 10.0.0.0 255.0.0.0 10.108.3.4ip default-network 10.0.0.0If the following command was issued on a router not connected to network 10.140.0.0, the software might choose the path to that network as a default route when the network appeared in the routing table:
ip default-network 10.140.0.0Related Commands
ip dvmrp metric
To configure the metric associated with a set of destinations for Distance Vector Multicast Routing Protocol (DVMRP) reports, use the ip dvmrp metric command in interface configuration mode. To disable this function, use the no form of this command.
ip dvmrp metric metric [route-map map-name] [mbgp] [mobile] [list access-list-number] [protocol process-id] | dvmrp]
no ip dvmrp metric metric [route-map map-name] [mbgp] [mobile] [list access-list-number] [protocol process-id] | dvmrp]
Syntax Description
Defaults
No metric value is preconfigured. Only directly connected subnets and networks are advertised to neighboring DVMRP routers.
Command Modes
Interface configuration
Command History
10.2
This command was introduced.
11.1
The route-map keyword was added.
11.1(20)CC
This mbgp keyword was added.
12.0(7)T
This mbgp keyword was added.
Usage Guidelines
When Protocol Independent Multicast (PIM) is configured on an interface and DVMRP neighbors are discovered, the Cisco IOS software sends DVMRP report messages for directly connected networks. The ip dvmrp metric command enables DVMRP report messages for multicast destinations that match the access list. Usually, the metric for these routes is 1. Under certain circumstances, you might want to tailor the metric used for various unicast routes. This command lets you configure the metric associated with a set of destinations for report messages sent out this interface.
You can use the access-list-number argument in conjunction with the protocol and process-id arguments to selectively list the destinations learned from a given routing protocol.
To display DVMRP activity, use the debug ip dvmrp command.
Examples
The following example connects a PIM cloud to a DVMRP cloud. Access list 1 permits the sending of DVMRP reports to the DVMRP routers advertising all sources in the 172.16.35.0 network with a metric of 1. Access list 2 permits all other destinations, but the metric of 0 means that no DVMRP reports are sent for these destinations.
access-list 1 permit 172.16.35.0 0.0.0.255access-list 1 deny 0.0.0.0 255.255.255.255access-list 2 permit 0.0.0.0 255.255.255.255interface tunnel 0ip dvmrp metric 1 list 1ip dvmrp metric 0 list 2The following example redistributes IPv4 multicast routes into DVMRP neighbors with a metric of 1:
interface tunnel 0ip dvmrp metric 1 mbgpRelated Commands
debug ip dvmrp
Displays information on DVMRP packets received and sent.
ip dvmrp accept-filter
Configures an acceptance filter for incoming DVMRP reports.
ip extcommunity-list
To create an extended community list to configure Virtual Private Network (VPN) route filtering, use the ip extcommunity-list command in global configuration mode. To delete the extended community list, use the no form of this command.
Global Configuration Mode CLI
ip extcommunity-list expanded-list | expanded list-name {permit | deny} [regular-expression] | standard-list | standard list-name {permit | deny} [rt value] [soo value]
no ip extcommunity-list expanded-list | expanded list-name | standard-list | standard list-name
To enter IP Extended community-list configuration mode to create or configure an extended community-list, use the ip extcommunity-list command in global configuration mode. To delete the entire extended community list, use the no form of this command. To delete a single entry, use the no form in IP Extended community-list configuration mode.
ip extcommunity-list expanded-list | expanded list-name | standard-list | standard list-name
no ip extcommunity-list expanded-list | expanded list-name | standard-list | standard list-name
Expanded IP Extended Community-List Configuration Mode CLI
[sequence-number] deny [regular-expression] | exit | permit [regular-expression] | resequence [starting-sequence] [sequence-increment]
default {sequence-number | deny [regular-expression] | exit | permit [regular-expression] | resequence [starting-sequence] [sequence-increment]}
no {sequence-number | deny [regular-expression] | permit [regular-expression] | resequence [starting-sequence] [sequence-increment]}
Standard IP Extended Community-List Configuration Mode CLI
[sequence-number] deny [rt value] [soo value] | exit | permit [rt value] [soo value] | resequence [starting-sequence] [sequence-increment]
default {sequence-number | deny [rt value] [soo value] | exit | permit [rt value] [soo value] | resequence [starting-sequence] [sequence-increment]}
no {sequence-number | deny [rt value | soo value] | permit [rt value] [soo value] | resequence [starting-sequence] [sequence-increment]}
Syntax Description
Defaults
Extended community exchange is not enabled by default. It is enabled on a per-neighbor basis with the neighbor send-community command.
Once a permit value has been configured to match a given set of extended communities, the extended community list defaults to an implicit deny for all other values.
Extended community list entries start with the number 10 and increment by ten for each subsequent entry when no sequence number is specified, when default behavior is configured, and when an extended community list is resequenced without specifying the first entry number or the increment range for subsequent entries.
Command Modes
Global configuration
IP Extended community-list configurationCommand History
Usage Guidelines
The ip extcommunity-list command is used to configure named or numbered extended community lists. Extended community attributes are used to filter routes for VPN routing and forwarding instances (VRFs) and Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). All of the standard rules of access lists apply to the configuration of extended community lists. The route target (RT) and site of origin (SOO) extended community attributes are supported by the standard range of extended community lists. Regular expressions are supported in expanded extended community lists. For information about configuring regular expressions, see the Regular Expressions appendix of the Cisco IOS Terminal Services Configuration Guide.
Route Target Extended Community Attribute
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.
Site of Origin Extended Community Attribute
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 site of origin extended community attribute, regardless if 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 should not be configured for stub sites or sites that are not multihomed.
IP Extended Community-List Configuration Mode
Named and numbered extended community lists can be configured in IP Extended community-list configuration mode. To enter IP Extended community-list configuration mode, enter the ip extcommunity-list command with either the expanded or standard keyword followed by the extended community list name. This configuration mode supports all of the functions that are available in global configuration mode. In addition, you can perform the following operations:
•
•
•
Extended Community List Processing
When multiple values are configured in the same extended community list statement, a logical AND condition is created. All extended community values must match to satisfy an AND condition. When multiple values are configured in separate extended community list statements, a logical OR condition is created. The first list that matches a condition is processed.
Examples
Standard Extended Community-List Configuration Example
In the following example, an extended community list is configured that permits routes from route target 64512:10 and site of origin 65400:20 and denies routes from route target 65424:30 and site of origin 64524:40. List 1 shows a logical OR condition; the first match is processed. List 2 shows a logical AND condition; all community values must match in order for list 2 to be processed.
Router(config)# ip extcommunity-list 1 permit rt 64512:10Router(config)# ip extcommunity-list 1 permit soo 65400:20Router(config)# ip extcommunity-list 2 deny rt 65424:30 soo 64524:40Expanded Extended Community-List Configuration Example
In the following example, an expanded extended community list is configured to deny advertisements from any path through or from autonomous system 65534 from being advertised to the 192.168.1.2 neighbor:
Router(config)# ip extcommunity-list 500 deny _65412_Router(config)# router bgp 50000Router(config-router)# address-family vpnv4Router(config-router-af)# neighbor 172.16.1.1 remote-as 65412Router(config-router-af)# neighbor 172.16.1.1 neighbor send-community extendedRouter(config-router-af)# neighbor 192.168.1.2 remote-as 65534Router(config-router-af)# neighbor 192.168.1.2 neighbor send-community extendedRouter(config-router-af)# endNamed Extended Community-List Configuration Example
In the following example, a named extended community list is configured that will permit routes only from route target 65505:50. All other routes are implicitly denied.
Router(config)# ip extcommunity-list standard NAMED_LIST permit rt 65505:50IP Extended Community-List Configuration Mode Example
In the following example, an expanded named extended community list is configured in IP Extended community-list configuration mode. A list entry is created with a sequence number 10 that will permit a route target or route origin pattern that matches any network number extended community from autonomous system 65412.
Router(config)# ip extcommunity-list REDRouter(config-extcom-list)# 10 permit 65412:[0-9][0-9][0-9][0-9][0-9]_Router(config-extcom-list)# exitExtended Community-List Resequencing Example
In the following example, the first list entry is resequenced to the number 50 and each subsequent entry is configured to increment by 100:
Router(config)# ip extcommunity-list BLUERouter(config-extcom-list)# resequence 50 100Router(config-extcom-list)# exitRelated Commands
ip fast-convergence
To reduce packet loss when the metric of a path is changed, or to fast-flood Intermediate System-to-Intermediate System (IS-IS) link-state packets (LSPs), use the ip fast-convergence command in router configuration mode. To disable packet loss reduction or fast-flooding, use the no version of this command.
ip fast-convergence
no ip fast-convergence
Note
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default.
Command Modes
Router configuration
Command History
Usage Guidelines
To reduce packet loss when the metric of a path is changed, use the ip fast-convergence command. Entering the ip fast-convergence command is especially helpful when Multiprotocol Label Switching (MPLS) traffic engineering with Fast Reroute (FFR) is deployed.
If you are running Cisco IOS Release 12.2(11)T or a later release, you can enter the ip fast-convergence command to configure the router to flood the first five LSPs that invoke SPF before running SPF. When you speed up the LSP flooding process, you improve overall network convergence time. We recommend that you enable the fast-flooding of LSPs before the router runs the SPF computation, in order to achieve a faster convergence time.
Examples
In the following example, the ip fast-convergence command is entered to configure the router to flood the first five LSPs that invoke SPF, before the SPF computation is started. When the show running-configuration command is entered, the output confirms that fast-flooding has been enabled on the router.
Router> enableRouter# configure terminalRouter(config)# router isisRouter(config-router)# ip fast-convergenceRouter(config-router)# endRouter# show running-configurationfast-floodRelated Commands
ip hello-interval eigrp
To configure the hello interval for the Enhanced Interior Gateway Routing Protocol (EIGRP) routing process designated by an autonomous system number, use the ip hello-interval eigrp command in interface configuration mode. To restore the default value, use the no form of this command.
ip hello-interval eigrp as-number seconds
no ip hello-interval eigrp as-number seconds
Syntax Description
as-number
Autonomous system number.
seconds
Hello interval (in seconds). The range is from 1 to 65535.
Defaults
For low-speed, nonbroadcast multiaccess (NBMA) networks: 60 seconds
For all other networks: 5 seconds
Command Modes
Interface configuration
Command History
Usage Guidelines
The default of 60 seconds applies only to low-speed, NBMA media. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command. Note that for the purposes of EIGRP, Frame Relay and Switched Multimegabit Data Service (SMDS) networks may be considered to be NBMA. These networks are considered NBMA if the interface has not been configured to use physical multicasting; otherwise, they are considered not to be NBMA.
Examples
The following example sets the hello interval for Ethernet interface 0 to 10 seconds:
interface ethernet 0ip hello-interval eigrp 109 10Related Commands
ip hold-time eigrp
To configure the hold time for a particular Enhanced Interior Gateway Routing Protocol (EIGRP) routing process designated by the autonomous system number, use the ip hold-time eigrp command in interface configuration mode. To restore the default value, use the no form of this command.
ip hold-time eigrp as-number seconds
no ip hold-time eigrp as-number seconds
Syntax Description
Defaults
For low-speed, nonbroadcast multiaccess (NBMA) networks: 180 seconds
For all other networks: 15 seconds
Command Modes
Interface configuration
Command History
Usage Guidelines
On very congested and large networks, the default hold time might not be sufficient time for all routers and access servers to receive hello packets from their neighbors. In this case, you may want to increase the hold time.
We recommend that the hold time be at least three times the hello interval. If a router does not receive a hello packet within the specified hold time, routes through this router are considered unavailable.
Increasing the hold time delays route convergence across the network.
The default of 180 seconds hold time and 60 seconds hello interval apply only to low-speed, NBMA media. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command.
Examples
The following example sets the hold time for Ethernet interface 0 to 40 seconds:
interface ethernet 0ip hold-time eigrp 109 40Related Commands
ip local policy route-map
To identify a route map to use for local policy routing, use the ip local policy route-map command in global configuration mode. To disable local policy routing, use the no form of this command.
ip local policy route-map map-tag
no ip local policy route-map map-tag
Syntax Description
map-tag
Name of the route map to use for local policy routing. The name must match a map-tag value specified by a route-map command.
Defaults
Packets that are generated by the router are not policy routed.
Command Modes
Global configuration
Command History
Usage Guidelines
Packets that are generated by the router are not normally policy routed. However, you can use this command to policy route such packets. You might enable local policy routing if you want packets originated at the router to take a route other than the obvious shortest path.
The ip local policy route-map command identifies a route map to use for local policy routing. 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 packets should be policy routed. The set commands specify the set actions—the particular policy routing actions to perform if the criteria enforced by the match commands are met. The no ip local policy route-map command deletes the reference to the route map and disables local policy routing.
Examples
The following example sends packets with a destination IP address matching that allowed by extended access list 131 to the router at IP address 172.130.3.20:
ip local policy route-map xyz!route-map xyzmatch ip address 131set ip next-hop 172.130.3.20Related Commands
ip multicast cache-headers
To allocate a circular buffer to store IP multicast packet headers that the router receives, use the ip multicast cache-headers command in global configuration mode. To remove the buffer, use the no form of this command.
ip multicast [vrf vrf-name] cache-headers [rtp]
no ip multicast [vrf vrf-name] cache-headers
Syntax Description
Defaults
The command is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
You can store IP multicast packet headers in a cache and then display them to determine the following information:
•
•
•
•
•
•
•
Note
Use the show ip mpacket command to display the buffer.
Examples
The following example allocates a buffer to store IP multicast packet headers:
ip multicast cache-headers
Related Commands
ip next-hop-self eigrp
To instruct EIGRP that the IP next hop is itself, use the ip next-hop-self eigrp command in interface configuration mode. To instruct EIGRP to use the received next hop rather than itself, use the no form of this command.
ip next-hop-self eigrp autonomous-system-number
no ip next-hop-self eigrp autonomous-system-number
Syntax Description
Defaults
EIGRP always sets the IP next-hop value to be itself.
Command Modes
Interface configuration
Command History
Usage Guidelines
EIGRP will, by default, set the IP next-hop value to be itself for routes that it is advertising, even when advertising those routes back out the same interface where it learned them. To change this default, you must use the no ip next-hop-self eigrp interface configuration command to instruct EIGRP to use the received next hop value when advertising these routes. Some exceptions to this guideline follow:
•
•
Examples
The following example changes the default IP next hop value and instructs EIGRP to use the received next hop value:
interface serial 0no ip next-hop-self eigrp 101ip ospf area
To enable OSPFv2 on an interface, use the ip ospf area command in interface configuration mode. To disable OSPFv2 on the interface, use the no form of this command.
ip ospf process-id area area-id [secondaries none]
no ip ospf process-id area [secondaries none]
Syntax Description
Defaults
If the secondaries keyword is entered in the no form of this command, the secondary IP addresses will be advertised. If the secondaries keyword is not present, OSPFv2 will be disabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
OSPF is enabled on an interface when the network address for the interface matches the range of addresses that is specified by the network area command that is entered in router configuration mode. For Cisco IOS releases 12.0(29)S, 12.3(11)T and 12.2(1)SB, you can enable OSPFv2 explicitly on an interface with the ip ospf area command that is entered in interface configuration mode. This capability simplifies the configuration of unnumbered interfaces with different areas.
The ip ospf area command that is entered in interface configuration mode will take supersede the effects of the network area command. Therefore, an interface that is configured with the ip ospf area command in interface configuration mode will not be affected by the network area command.
Note
Examples
The following example enables OSPFv2 on Ethernet interface 0/0/2 and prevents secondary IP addresses from being advertised:
Router(config)# interface Ethernet0/0/2Router(config-if)# ip ospf 10 area 0 secondaries noneRelated Commands
ip ospf authentication
To specify the authentication type for an interface, use the ip ospf authentication command in interface configuration mode. To remove the authentication type for an interface, use the no form of this command.
ip ospf authentication [message-digest | null]
no ip ospf authentication
Syntax Description
Defaults
The area default is no authentication (null authentication).
Command Modes
Interface configuration
Command History
Usage Guidelines
Before using the ip ospf authentication command, configure a password for the interface using the ip ospf authentication-key command. If you use the ip ospf authentication message-digest command, configure the message-digest key for the interface with the ip ospf message-digest-key command.
For backward compatibility, authentication type for an area is still supported. If the authentication type is not specified for an interface, the authentication type for the area will be used (the area default is null authentication).
Examples
The following example enables message-digest authentication:
ip ospf authentication message-digestRelated Commands
ip ospf authentication-key
To assign a password to be used by neighboring routers that are using the OSPF simple password authentication, use the ip ospf authentication-key command in interface configuration mode. To remove a previously assigned OSPF password, use the no form of this command.
ip ospf authentication-key password
no ip ospf authentication-key
Syntax Description
password
Any continuous string of characters that can be entered from the keyboard up to 8 bytes in length.
Defaults
No password is specified.
Command Modes
Interface configuration
Command History
Usage Guidelines
The password created by this command is used as a "key" that is inserted directly into the OSPF header when the Cisco IOS software originates routing protocol packets. A separate password can be assigned to each network on a per-interface basis. All neighboring routers on the same network must have the same password to be able to exchange OSPF information.
Note
Examples
The following example enables the authentication key with the string yourpass:
ip ospf authentication-key yourpassRelated Commands
area authentication
Enables authentication for an OSPF area.
ip ospf authentication
Specifies authentication type for an interface.
ip ospf cost
To explicitly specify the cost of sending a packet on an interface, use the ip ospf cost command in interface configuration mode. To reset the path cost to the default value, use the no form of this command.
ip ospf cost interface-cost
no ip ospf cost interface-cost
Syntax Description
interface-cost
Unsigned integer value expressed as the link-state metric. It can be a value in the range from 1 to 65535.
Defaults
No default cost is predefined.
Command Modes
Interface configuration
Command History
Usage Guidelines
You can set the metric manually using this command, if you need to change the default. Using the bandwidth command changes the link cost as long as this command is not used.
The link-state metric is advertised as the link cost in the router link advertisement. We do not support type of service (ToS), so you can assign only one cost per interface.
In general, the path cost is calculated using the following formula:
108 / bandwidth
Using this formula, the default path costs were calculated as noted in the following list. If these values do not suit your network, you can use your own method of calculating path costs.
•
•
•
•
•
•
•
•
•
•
•
Examples
The following example sets the interface cost value to 65:
ip ospf cost 65ip ospf database-filter all out
To filter outgoing link-state advertisements (LSAs) to an OSPF interface, use the ip ospf database-filter all out command in interface configuration mode. To restore the forwarding of LSAs to the interface, use the no form of this command.
ip ospf database-filter all out
no ip ospf database-filter all out
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default. All outgoing LSAs are flooded to the interface.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command performs the same function that the neighbor database-filter command performs on a neighbor basis.
Examples
The following example prevents flooding of OSPF LSAs to broadcast, nonbroadcast, or point-to-point networks reachable through Ethernet interface 0:
interface ethernet 0ip ospf database-filter all outRelated Commands
ip ospf dead-interval
To set the interval during which at least one hello packet must be received from a neighbor before the router declares that neighbor down, use the ip ospf dead-interval command in interface configuration mode. To restore the default value, use the no form of this command.
ip ospf dead-interval {seconds | minimal hello-multiplier multiplier}
no ip ospf dead-interval
Syntax Description
Defaults
seconds: Four times the interval set by the ip ospf hello-interval command.
Command Modes
Interface configuration
Command History
10.0
This command was introduced.
12.0(23)S
The minimal keyword, hello-multiplier keyword and multiplier argument were added to allow OSPF Support for Fast Hello Packets.
Usage Guidelines
The dead interval is advertised in OSPF hello packets. This value must be the same for all networking devices on a specific network.
Specifying a smaller dead interval (seconds) will give faster detection of a neighbor being down and improve convergence, but might cause more routing instability.
OSPF Support for Fast Hello Packets
By specifying the minimal and hello-multiplier keywords with a multiplier argument, you are enabling OSPF fast hello packets. The minimal keyword sets the dead interval to 1 second, and the hello-multiplier value sets the number of hello packets sent during that 1 second, thus providing subsecond or "fast" hello packets.
When fast hello packets are configured on the interface, the hello interval advertised in the hello packets that are sent out this interface is set to 0. The hello interval in the hello packets received over this interface is ignored.
The dead interval must be consistent on a segment, whether it is set to 1 second (for fast hello packets) or set to any other value. The hello multiplier need not be the same for the entire segment as long as at least one hello packet is sent within the dead interval.
Use the show ip ospf interface command to verify the dead interval and fast hello interval.
Examples
The following example sets the OSPF dead interval to 20 seconds:
interface ethernet 1ip ospf dead-interval 20The following example configures OSPF fast hello packets; the dead interval is 1 second and there are 5 hello packets sent every second:
interface ethernet 1ip ospf dead-interval minimal hello-multiplier 5Related Commands
ip ospf hello-interval
Interval between hello packets that the Cisco IOS software sends on the interface.
show ip ospf interface
Displays OSPF-related information.
ip ospf demand-circuit
To configure OSPF to treat the interface as an OSPF demand circuit, use the ip ospf demand-circuit command in interface configuration mode. To remove the demand circuit designation from the interface, use the no form of this command.
ip ospf demand-circuit
no ip ospf demand-circuit
Syntax Description
This command has no arguments or keywords.
Defaults
The circuit is not a demand circuit.
Command Modes
Interface configuration
Command History
Usage Guidelines
On point-to-point interfaces, only one end of the demand circuit must be configured with this command. Periodic hello messages are suppressed and periodic refreshes of link-state advertisements (LSAs) do not flood the demand circuit. This command allows the underlying data link layer to be closed when the topology is stable. In point-to-multipoint topology, only the multipoint end must configured with this command.
Examples
The following example sets the configuration for an ISDN on-demand circuit:
router ospf 1network 10.0.3.0 255.255.255.0 area 0interface BRI0ip ospf demand-circuitip ospf flood-reduction
To suppress the unnecessary flooding of link-state advertisements (LSAs) in stable topologies, use the ip ospf flood-reduction command in interface configuration mode. To disable this feature, use the no form of this command.
ip ospf flood-reduction
no ip ospf flood-reduction
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default.
Command Modes
Interface configuration
Command History
Usage Guidelines
All routers supporting the OSPF demand circuit are compatible and can interact with routers supporting flooding reduction.
Examples
The following example reduces the flooding of unnecessary LSAs on serial interface 0:
interface serial 0ip ospf flood-reductionRelated Commands
show ip ospf interface
Displays OSPF-related interface information.
show ip ospf neighbor
Displays OSPF-neighbor information on a per-interface basis.
ip ospf hello-interval
To specify the interval between hello packets that the Cisco IOS software sends on the interface, use the ip ospf hello-interval command in interface configuration mode. To return to the default time, use the no form of this command.
ip ospf hello-interval seconds
no ip ospf hello-interval
Syntax Description
seconds
Specifies the interval (in seconds). The value must be the same for all nodes on a specific network. The range is from 1 to 65535.
Defaults
10 seconds (Ethernet)
30 seconds (nonbroadcast)
Command Modes
Interface configuration
Command History
Usage Guidelines
This value is advertised in the hello packets. The smaller the hello interval, the faster topological changes will be detected, but more routing traffic will ensue. This value must be the same for all routers and access servers on a specific network.
Examples
The following example sets the interval between hello packets to 15 seconds:
interface ethernet 1ip ospf hello-interval 15Related Commands
ip ospf dead-interval
Sets the time period for which hello packets must not have been seen before neighbors declare the router down.
ip ospf lls
To enable Link-Local Signaling (LLS) on an interface, regardless of the router-level LLS setting, use the ip ospf lls command in interface configuration mode. To reconfigure the router-level LLS setting on the specific interface, use the default or no version of this command.
ip ospf lls [disable]
{no | default} ip ospf lls [disable]
Syntax Description
Defaults
LLS is enabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
By default, each Open Shortest Path First (OSPF) interface inherits the LLS setting from the router level. The ip ospf lls interface-level command takes precedence over the capability lls router-level command. For example, if you have entered the no capability lls command to disable LLS at the router level, you can use the ip ospf lls command to selectively enable LLS for specific interfaces, in order to allow the router to enable OSPF nonstop forwarding (NSF) awareness only for these specified interfaces.
To unconfigure the interface LLS setting, enter either the default ip ospf lls command or the no ip ospf lls command to restore the default LLS setting for the interface that has been configured at the router level. For example, if the capability lls command is enabled (by default) at the router level, you can use either the default ip ospf lls command or the no ip ospf lls command to disable LLS on specific interfaces, for instance, to interoperate on network segments where there are routers that do not properly handle LLS.
Note
Examples
In following example, LLS is disabled on Ethernet interface 2/0:
Router(config)# interface Ethernet2/0Router(config-if)# ip address 10.1.145.2 255.255.0.0Router(config-if)# no ip directed-broadcastRouter(config-if)# ip ospf message-digest-key 1 md5 testingRouter(config-if)# ip ospf lls disableRelated Commands
ip ospf message-digest-key
To enable OSPF Message Digest 5 (MD5) authentication, use the ip ospf message-digest-key command in interface configuration mode. To remove an old MD5 key, use the no form of this command.
ip ospf message-digest-key key-id encryption-type md5 key
no ip ospf message-digest-key key-id
Syntax Description
Defaults
OSPF MD5 authentication is disabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
Usually, one key per interface is used to generate authentication information when sending packets and to authenticate incoming packets. The same key identifier on the neighbor router must have the same key value.
The process of changing keys is as follows. Suppose the current configuration is as follows:
interface ethernet 1ip ospf message-digest-key 100 md5 OLDYou change the configuration to the following:
interface ethernet 1ip ospf message-digest-key 101 md5 NEWThe system assumes its neighbors do not have the new key yet, so it begins a rollover process. It sends multiple copies of the same packet, each authenticated by different keys. In this example, the system sends out two copies of the same packet—the first one authenticated by key 100 and the second one authenticated by key 101.
Rollover allows neighboring routers to continue communication while the network administrator is updating them with the new key. Rollover stops once the local system finds that all its neighbors know the new key. The system detects that a neighbor has the new key when it receives packets from the neighbor authenticated by the new key.
After all neighbors have been updated with the new key, the old key should be removed. In this example, you would enter the following:
interface ethernet 1no ip ospf message-digest-key 100Then, only key 101 is used for authentication on Ethernet interface 1.
We recommend that you not keep more than one key per interface. Every time you add a new key, you should remove the old key to prevent the local system from continuing to communicate with a hostile system that knows the old key. Removing the old key also reduces overhead during rollover.
Note
Examples
The following example sets a new key 19 with the password 8ry4222:
interface ethernet 1ip ospf message-digest-key 10 md5 xvv560qleip ospf message-digest-key 19 md5 8ry4222Related Commands
ip ospf mtu-ignore
To disable OSPF MTU mismatch detection on receiving DBD packets, use the ip ospf mtu-ignore command in interface configuration mode. To reset to default, use the no form of this command.
ip ospf mtu-ignore
no ip ospf mtu-ignore
Syntax Description
This command has no keywords or arguments.
Defaults
OSPF MTU mismatch detection is enabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
OSPF checks whether neighbors are using the same MTU on a common interface. This check is performed when neighbors exchange Database Descriptor (DBD) packets. If the receiving MTU in the DBD packet is higher than the IP MTU configured on the incoming interface, OSPF adjacency will not be established.
Examples
The following example disables MTU mismatch detection on receiving DBD packets:
interface serial 0/0ip ospf mtu-ignoreip ospf name-lookup
To configure OSPF to look up Domain Name System (DNS) names for use in all OSPF show EXEC command displays, use the ip ospf name-lookup command in global configuration mode. To disable this function, use the no form of this command.
ip ospf name-lookup
no ip ospf name-lookup
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
This command makes it easier to identify a router because the router is displayed by name rather than by its router ID or neighbor ID.
Examples
The following example configures OSPF to look up DNS names for use in all OSPF show EXEC command displays:
ip ospf name-lookupip ospf network
To configure the OSPF network type to a type other than the default for a given medium, use the ip ospf network command in interface configuration mode. To return to the default value, use the no form of this command.
ip ospf network {broadcast | non-broadcast | {point-to-multipoint [non-broadcast] | point-to-point}}
no ip ospf network
Syntax Description
Defaults
Depends on the network type.
Command Modes
Interface configuration
Command History
10.0
This command was introduced.
10.3
The point-to-multipoint keyword was added.
11.3 AA
The non-broadcast keyword used with the point-to-multipoint keyword was added.
Usage Guidelines
Using this feature, you can configure broadcast networks as NBMA networks when, for example, routers in your network do not support multicast addressing. You can also configure nonbroadcast multiaccess networks (such as X.25, Frame Relay, and Switched Multimegabit Data Service (SMDS)) as broadcast networks. This feature saves you from needing to configure neighbors.
Configuring NBMA networks as either broadcast or nonbroadcast assumes that there are virtual circuits from every router to every router or fully meshed networks. However, there are other configurations where this assumption is not true. For example, a partially meshed network. In these cases, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers that are not directly connected will go through the router that has virtual circuits to both routers. You need not configure neighbors when using this feature.
If this command is issued on an interface that does not allow it, this command will be ignored.
OSPF has two features related to point-to-multipoint networks. One feature applies to broadcast networks; the other feature applies to nonbroadcast networks:
•
•
Examples
The following example sets your OSPF network as a broadcast network:
interface serial 0ip address 192.168.77.17 255.255.255.0ip ospf network broadcastencapsulation frame-relayThe following example illustrates a point-to-multipoint network with broadcast:
interface serial 0ip address 10.0.1.1 255.255.255.0encapsulation frame-relayip ospf cost 100ip ospf network point-to-multipointframe-relay map ip 10.0.1.3 202 broadcastframe-relay map ip 10.0.1.4 203 broadcastframe-relay map ip 10.0.1.5 204 broadcastframe-relay local-dlci 200!router ospf 1network 10.0.1.0 0.0.0.255 area 0neighbor 10.0.1.5 cost 5neighbor 10.0.1.4 cost 10Related Commands
ip ospf priority
To set the router priority, which helps determine the designated router for this network, use the ip ospf priority command in interface configuration mode. To return to the default value, use the no form of this command.
ip ospf priority number-value
no ip ospf priority number-value
Syntax Description
Defaults
Priority of 1
Command Modes
Interface configuration
Command History
Usage Guidelines
When two routers attached to a network both attempt to become the designated router, the one with the higher router priority takes precedence. If there is a tie, the router with the higher router ID takes precedence. A router with a router priority set to zero is ineligible to become the designated router or backup designated router. Router priority is configured only for interfaces to multiaccess networks (in other words, not to point-to-point networks).
This priority value is used when you configure OSPF for nonbroadcast networks using the neighbor router configuration command for OSPF.
Examples
The following example sets the router priority value to 4:
interface ethernet 0ip ospf priority 4Related Commands
ip ospf resync-timeout
To configure how long the router will wait before taking a neighbor adjacency down if the out-of-band resynchronization (oob-resync) has not taken place since the time a restart signal (OSPF Hello packet with RS-bit set) was received from the neighbor, use the ip ospf resync-timeout command in interface configuration mode. To restore the default value, use the no form of this command.
ip ospf resync-timeout seconds
no ip ospf resync-timeout
Syntax Description
Defaults
The default value is 40 seconds or the value set for the interface's OSPF dead interval, whichever is greater.
Command Modes
Interface configuration
Command History
Usage Guidelines
When an OSPF nonstop forwarding (NSF) router performs a route processor (RP) switchover, it notifies its neighbors, via a special Hello packet, of such action and requests that each neighbor help resynchronize the Link State Database.
When a neighbor (that is NSF-aware) receives the special Hello packet from the NSF-capable router, it starts a resync timeout timer and waits to synchronize its database with the NSF-capable router. If the NSF-capable router does not initiate the database resynchronization process before the resync-timeout timer expires, the NSF-aware neighbor will take down the adjacency with the NSF-capable router.
By default, the resync-timeout timer is set to 40 seconds or the dead interval of the interface, whichever is greater. (By default, the dead interval is 4 times the hello interval; the hello interval defaults to 10 seconds for Ethernet or 30 seconds for nonbroadcast.) The ip ospf resync-timeout command allows the resync-timeout to be changed and independent of the dead interval or default value.
Examples
This example sets the OSPF resync-timeout interval to 50 seconds:
interface GigabitEthernet 6/0/0ip ospf resync-timeout 50Related Commands
ip ospf retransmit-interval
To specify the time between link-state advertisement (LSA) retransmissions for adjacencies belonging to the interface, use the ip ospf retransmit-interval command in interface configuration mode. To return to the default value, use the no form of this command.
ip ospf retransmit-interval seconds
no ip ospf retransmit-interval
Syntax Description
Defaults
5 seconds
Command Modes
Interface configuration
Command History
Usage Guidelines
When a router sends an LSA to its neighbor, it keeps the LSA until it receives back the acknowledgment message. If the router receives no acknowledgment, it will resend the LSA.
The setting of this parameter should be conservative, or needless retransmission will result. The value should be larger for serial lines and virtual links.
Examples
The following example sets the retransmit interval value to 8 seconds:
interface ethernet 2ip ospf retransmit-interval 8ip ospf transmit-delay
To set the estimated time required to send a link-state update packet on the interface, use the ip ospf transmit-delay command in interface configuration mode. To return to the default value, use the no form of this command.
ip ospf transmit-delay seconds
no ip ospf transmit-delay
Syntax Description
seconds
Time (in seconds) required to send a link-state update. The range is from 1 to 65535 seconds. The default is 1 second.
Defaults
1 second
Command Modes
Interface configuration
Command History
Usage Guidelines
Link-state advertisements (LSAs) in the update packet must have their ages incremented by the amount specified in the seconds argument before transmission. The value assigned should take into account the transmission and propagation delays for the interface.
If the delay is not added before transmission over a link, the time in which the LSA propagates over the link is not considered. This setting has more significance on very low-speed links.
Examples
The following example sets the retransmit delay value to 3 seconds:
interface ethernet 0ip ospf transmit-delay 3
