RIP Commands 2

RIP Commands
Use the commands in this chapter to configure and monitor Routing Information Protocol (RIP). For RIP configuration information and examples, refer to the "Configuring RIP" chapter of the Network Protocols Configuration Guide, Part 1.
auto-summary (RIP)
To restore the default behavior of automatic summarization of subnet routes into network-level routes, use the auto-summary command in router configuration mode. To disable this function and transmit subprefix routing information across classful network boundaries, use the no form of this command. auto-summary no auto-summary
Syntax Description
This command has no arguments or keywords.
Defaults
Enabled (the software summarizes subprefixes to the classful network boundary when crossing classful network boundaries).
Command Modes
Router configuration
Command History
Release 10.0 Modification This command was introduced.
Usage Guidelines
Route summarization reduces the amount of routing information in the routing tables. RIP Version 1 always uses automatic summarization. If you are using RIP Version 2, you can turn off automatic summarization by specifying no auto-summary. Disable automatic summarization if you must perform routing between disconnected subnets. When automatic summarization is off, subnets are advertised.
Examples
In the following example, network numbers are not summarized automatically:
router rip version 2 no auto-summary
default-information originate
To generate a default route into RIP, use the default-information originate command in router configuration mode. To disable this feature, use the no form of this command. default-information originate [route-map mapname] no default-information originate
Syntax Description
route-map mapname
(Optional) Routing process will generate the default route if the route map is satisfied.
Defaults
This command is disabled by default.
Command Modes
Command History
Usage Guidelines
The route map referenced in the default-information originate command cannot use an extended access list; it can use a standard access list.
Examples
The following example originates a default route (0.0.0.0/0) over a certain interface when 172.68.0.0/16 is present. This is called "conditional default origination."
router rip version 2 network 172.68.16.0 default-information originate route-map condition ! route-map condition permit 10 match ip address 10 set interface s1/0 ! access-list 10 permit 172.68.16.0 0.0.0.255 !
default-metric (RIP)
To set default metric values for RIP, use this form of the default-metric command in router configuration mode. To return to the default state, use the no form of this command. default-metric number no default-metric [number]
Syntax Description
number
Default metric value.
Defaults
Built-in, automatic metric translations, as appropriate for each routing protocol. The metric of redistributed connected and static routes is set to 0.
Command Modes
Command History
Usage Guidelines
The default-metric command is used in conjunction with the redistribute router configuration command to cause the current routing protocol to use the same metric value for all redistributed routes. A default metric helps solve the problem of redistributing routes with incompatible metrics. Whenever metrics do not convert, using a default metric provides a reasonable substitute and enables the redistribution to proceed.
Note When enabled, the default-metric command applies a metric value of 0 to redistributed connected routes. The default-metric command does not override metric values that are applied with the redistribute command.
Examples
The following example shows a router in autonomous system 109 using both the RIP and the OSPF routing protocols. The example advertises OSPF-derived routes using the RIP protocol and assigns the OSPF-derived routes a RIP metric of 10.
router rip default-metric 10 redistribute ospf 109
Related Commands
Command Description
redistribute Redistributes routes from one routing domain into another routing domain.
flash-update-threshold
To suppress regularly scheduled flash updates, use the flash-update-threshold command in router configuration mode. To return to the default state, use the no form of this command. flash-update-threshold seconds no flash-update-threshold
Syntax Description
seconds The time interval in seconds for which the suppression of flash updates can be configured.
Defaults
Command Modes
Command History
Usage Guidelines
This command suppresses flash updates when the arrival of a regularly scheduled update matches the number of seconds that is configured with the seconds argument. The range of seconds that can be configure is from 0 to 30 seconds. If the number of seconds matches the number of seconds or is less than the number seconds that is configured with the seconds argument, the flash update is suppressed. If the numbers seconds until the flash update arrives exceeds the number of seconds that is configured with the seconds argument, the flash update is not suppressed. The regular scheduled interval for flash updates and the configuration of the suppression of flash updates can be verified with the show ip protocol command.
Examples
The following example configures a router to suppress a regularly scheduled flash update if the update is due in 10 seconds or less:
router rip flash-update-threshold 10
Related Commands
Command show ip protocols Description Displays the parameters and current state of the active routing protocol process.
input-queue
To adjust the depth of 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 version of this command. input-queue depth no input-queue [depth]
Syntax Description
depth Numerical value associated with the depth of the RIP input queue. The larger the numerical value, the larger the depth of the queue. The range is 0 to 1024.
Defaults
50
Command Modes
Command History
Usage Guidelines
Consider using the input-queue command if you have a high-end router 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.
Examples
The following example sets the depth of the RIP input queue to 100:
input-queue 100
Related Commands
Command output-delay
Description Changes interpacket delay for RIP updates sent.
ip rip authentication key-chain

To enable authentication for RIP Version 2 packets and to specify the set of keys that can be used on an interface, use the ip rip authentication key-chain command in interface configuration mode. Use the no form of this command to prevent authentication. ip rip authentication key-chain name-of-chain no ip rip authentication key-chain [name-of-chain]
Syntax Description
name-ofchain
Enables authentication and specifies the group of keys that are valid.
Defaults
No authentication is provided for RIP packets.
Command Modes
Interface configuration
Command History
Usage Guidelines
If no key chain is configured with the key-chain command, no authentication is performed on the interface (not even the default authentication).
Examples
The following example configures the interface to accept and send any key belonging to the key chain named trees:
ip rip authentication key-chain trees
Related Commands
Command Description key chain Enables authentication for routing protocols by identifying a group of authentication keys.
ip rip authentication mode

To specify the type of authentication used in RIP Version 2 packets, use the ip rip authentication mode command in interface configuration mode. Use the no form of this command to restore clear text authentication. ip rip authentication mode {text | md5} no ip rip authentication mode
Syntax Description
text md5
Clears text authentication. Keyed MD5 authentication.
Defaults
Clear text authentication is provided for RIP packets.
Command Modes
Command History
Usage Guidelines
RIP Version 1 does not support authentication.
Examples
The following example configures the interface to use MD5 authentication:
ip rip authentication mode md5
Related Commands
Command Description inputqueue key chain Enables authentication for RIP Version 2 packets and specifies the set of keys that can be used on an interface. Enables authentication for routing protocols by identifying a group of authentication keys.
ip rip receive version

To specify a RIP version to receive on an interface basis, use the ip rip receive version command in interface configuration mode. Use the no form of this command to follow the global version rules. ip rip receive version [1] [2] no ip rip receive version
Syntax Description
1 (Optional) Accepts only RIP Version 1 packets on the interface. 2 (Optional) Accepts only RIP Version 2 packets on the interface.
Defaults
Command Modes
Command History
Usage Guidelines
Use this command to override the default behavior of RIP as specified by the version command. This command applies only to the interface being configured. You can configure the interface to accept both RIP versions.
Examples
The following example configures the interface to receive both RIP Version 1 and Version 2 packets:
ip rip receive version 1 2
The following example configures the interface to receive only RIP Version 1 packets:
ip rip receive version 1
Related Commands
Command ip rip send version version input-queue Description Specifies a RIP version to send on an interface basis.
Specifies a RIP vesrion used globally by the router. Enables authentication for RIP Version 2 packets and specifies the set of keys that can be used on an interface. Enables authentication for routing protocols by identifying a group of authentication keys.
key chain
ip rip send version
To specify a RIP version to send on an interface basis, use the ip rip send version command in interface configuration mode. Use the no form of this command to follow the global version rules. ip rip send version [1] [2] no ip rip send version
Syntax Description
1 (Optional) Sends only RIP Version 1 packets out the interface. 2 (Optional) Sends only RIP Version 2 packets out the interface.
Defaults
The software behaves according to the router version command.
Command Modes
Command History
Usage Guidelines
Use this command to override the default behavior of RIP as specified by the router version command. This command applies only to the interface being configured. The following example configures the interface to send both RIP Version 1 and Version 2 packets out the interface:
ip rip send version 1 2
The following example configures the interface to send only RIP Version 2 packets out the interface:
ip rip send version 2
Related Commands
Command ip rip receive version version Description Specifies a RIP version to receive on an interface basis. Specifies a RIP vesrion used globally by the router.
ip split-horizon (RIP)
To enable the split horizon mechanism, use the ip split-horizon command in interface configuration mode. To disable the split horizon mechanism, use the no form of this command. ip split-horizon no ip split-horizon
Syntax Description
Defaults
Default behavior varies with media type.
Command Modes
Command History
Usage Guidelines
For all interfaces except those for which either Frame Relay or SMDS encapsulation is enabled, the default condition for this command is ip split-horizon; in other words, the split horizon feature is active. If the interface configuration includes either the
encapsulation frame-relay or encapsulation smds commands, then the default is for split horizon to be disabled. Split horizon is not disabled by default for interfaces using any of the X.25 encapsulations.
Note For networks that include links over X.25 PSNs, the neighbor router configuration command can be used to defeat the split horizon feature. You can as an alternative explicitly specify the no ip split-horizon command in your configuration. However, if you do so you must similarly disable split horizon for all routers in any relevant multicast groups on that network.
Note If split horizon has been disabled on an interface and you want to enable it, use the ip split-horizon command to restore the split horizon mechanism.
Note In general, changing the state of the default for the ip split-horizon command is not recommended, unless you are certain that your application requires a change in order to properly advertise routes. If split horizon is disabled on a serial interface (and that interface is attached to a packet-switched network), you must disable split horizon for all routers and access servers in any relevant multicast groups on that network.
The following simple example disables split horizon on a serial link. The serial link is connected to an X.25 network:
interface serial 0 encapsulation x25 no ip split-horizon
Related Commands
Command neighbor (RIP) Description Defines a neighboring router with which to exchange routing information.
neighbor (RIP)
To define a neighboring router with which to exchange routing information, use this form of the neighbor command in router configuration mode. To remove an entry, use the no form of this command.
neighbor ip-address no neighbor ip-address
Syntax Description
ipaddress
IP address of a peer router with which routing information will be exchanged.
Defaults
No neighboring routers are defined.
Command Modes
Command History
Usage Guidelines
This command permits the point-to-point (nonbroadcast) exchange of routing information. When it is used in combination with the passive-interface router configuration command, routing information can be exchanged between a subset of routers and access servers on a LAN. Multiple neighbor commands can be used to specify additional neighbors or peers.
Examples
In the following example, RIP updates are sent to all interfaces on network 10.108.0.0 except interface Ethernet 1. However, in this case a neighbor router configuration command is included. This command permits the sending of routing updates to specific neighbors. One copy of the routing update is generated per neighbor.
router rip network 10.108.0.0 passive-interface ethernet 1 neighbor 10.108.20.4
Related Commands
Command Description
passive-interface Disables sending routing updates on an interface.
network (RIP)
To specify a list of networks for the Routing Information Protocol (RIP) routing process, use this form of the network command in router configuration mode. To remove an entry, use the no form of this command. network network-number no network network-number
Syntax Description
networknumber
IP address of the network of directly connected networks.
Defaults
No networks are specified.
Command Modes
Command History
Usage Guidelines
The network number specified must not contain any subnet information. There is no limit to the number of network commands you can use on the router. RIP routing updates will be sent and received only through interfaces on this network.
RIP sends updates to the interfaces in the specified networks. Also, if an interface's network is not specified, it will not be advertised in any RIP update.
Examples
The following example defines RIP as the routing protocol to be used on all interfaces connected to networks 10.99.0.0 and 192.168.7.0:
router rip network 10.99.0.0 network 192.168.7.0
Related Commands
Command Description router rip Configures the Routing Information Protocol (RIP) process.
offset-list
To add an offset to incoming and outgoing metrics to routes learned via RIP, use the offset-list command in router configuration mode. To remove an offset list, use the no form of this command. offset-list {access-list-number | name} {in | out} offset [type number] no offset-list {access-list-number | name} {in | out} offset [type number]
Syntax Description
access-list- Standard access list number or name to be applied. number | Access list number 0 indicates all access lists. If offset is name 0, no action is taken. For IGRP, the offset is added to the delay component only. in out offset Applies the access list to incoming metrics. Applies the access list to outgoing metrics. Positive offset to be applied to metrics for networks matching the access list. If the offset is 0, no action is taken.
type
(Optional) Interface type to which the offset-list is applied. (Optional) Interface number to which the offset-list is applied.
number
Defaults
Command Modes
Command History
Release 10.0 10.3 11.2 Modification This command was introduced. The type and number arguments were added. The name argument was added.
Usage Guidelines
The offset value is added to the routing metric. An offset-list with an interface type and interface number is considered extended and takes precedence over an offset-list that is not extended. Therefore, if an entry passes the extended offset-list and the normal offset-list, the extended offset-list's offset is added to the metric.
Examples
In the following example, the router applies an offset of 10 to the router's delay component only to access list 21:
offset-list 21 out 10
In the following example, the router applies an offset of 10 to routes learned from Ethernet interface 0:
offset-list 21 in 10 ethernet 0
output-delay
To change the interpacket delay for RIP updates sent, use the output-delay command in router configuration mode. To remove the delay, use the no form of this command. output-delay delay no output-delay [delay]
Syntax Description
delay Delay, in milliseconds, between packets in a multiple-packet RIP update. The range is 8 to 50 milliseconds. The default is no delay.
Defaults
0 milliseconds
Command Modes
Command History
Usage Guidelines
Consider using this command if you have a high-end router 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.
Examples
The following example sets the interpacket delay to 10 milliseconds:
output-delay 10
router rip
To configure the Routing Information Protocol (RIP) routing process, use the router rip command in global configuration mode. To turn off the RIP routing process, use the no form of this command. router rip no router rip
Syntax Description
Defaults
No RIP routing process is defined.
Command Modes
Global configuration
Command History
Examples
The following example shows how to begin the RIP routing process:
router rip
Related Commands
Command network (RIP) Description Specifies a list of networks for the Routing Information Protocol (RIP) process.
timers basic
To adjust 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. Interval of time (in seconds) after which a route is declared invalid. The interval should be at least three times the value of update time. The interval is measured from the last update received for the route. The route becomes invalid when there is an absence of updates during the invalid time that refresh the route. The route is marked inaccessible and advertised as unreachable. However, the route still forwards packets until the flush interval expires. The default is 180 seconds.
invalid
holddown Interval (in seconds) during which routing information regarding better paths is suppressed. The interval should be at least three times the value of update time. 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 continues to forward packets until an update is received with a better metric or until the holddown time expires. When the 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 is measured from the last update received for the route. The interval should be longer than the larger of the invalid and holddown values. If the interval is less than the sum of the update and holddown values, 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 is 30 seconds invalid is 180 seconds holddown is 180 seconds flush is 240 seconds
Command Modes
Command History
Usage Guidelines
The basic timing parameters for RIP are adjustable. Since RIP 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 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.
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; however, this is not a big 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.
validate-update-source
To have the Cisco IOS software validate the source IP address of incoming routing updates for RIP and IGRP routing protocols, use the validate-update-source command in router configuration mode. To disable this function, use the no form of this command. validate-update-source no validate-update-source
Syntax Description
Defaults
The behavior of this command is enabled by default.
Command Modes
Command History
Usage Guidelines
This command is applicable only to RIP and IGRP. The software ensures that the source IP address of incoming routing updates is on the same IP network as one of the addresses defined for the receiving interface. Disabling split horizon on the incoming interface will also cause the system to perform this validation check. For unnumbered IP interfaces (interfaces configured as ip unnumbered), no checking is performed.
Examples
The following example configures a router not to perform validation checks on the source IP address of incoming RIP updates:
router rip network 10.105.0.0 no validate-update-source
version
To specify a RIP version used globally by the router, use the version command in router configuration mode. Use the no form of this command to restore the default value. version {1 | 2} no version
Syntax Description
1 2
Specifies RIP Version 1. Specifies RIP Version 2.
Defaults
The software receives RIP Version 1 and Version 2 packets, but sends only Version 1 packets.
Command Modes
Command History
Usage Guidelines
To specify RIP versions used on an interface basis, use the ip rip receive version and ip rip send version commands.
Examples
The following example enables the software to send and receive RIP Version 2 packets:
version 2
Related Commands
Command ip rip receive version ip rip send version show ip protocols
Description Specifies a RIP version to receive on an interface basis. Specifies a RIP version to send on an interface basis. Displays the parameters and current state of the active routing protocol process..
Configuring OSPF
This chapter describes how to configure OSPF. For a complete description of the OSPF commands in this chapter, refer to the "OSPF Commands" chapter of the Network Protocols Command Reference, Part 1. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. Open shortest path first (OSPF) is an IGP developed by the OSPF working group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet authentication and uses IP multicast when sending/receiving packets. We support RFC 1253, Open Shortest Path First (OSPF) MIB, August 1991. The OSPF MIB defines an IP routing protocol that provides management information related to OSPF and is supported by Cisco routers. For protocol-independent features that include OSPF, see the chapter "Configuring IP Routing Protocol-Independent Features" in this document.
Cisco's OSPF Implementation

Cisco's implementation conforms to the OSPF Version 2 specifications detailed in the Internet RFC 1583. The list that follows outlines key features supported in Cisco's OSPF implementation:
Stub areasDefinition of stub areas is supported.
Route redistributionRoutes learned via any IP routing protocol can be redistributed into any other IP routing protocol. At the intradomain level, this means that OSPF can import routes learned via IGRP, RIP, and IS-IS. OSPF routes can also be exported into IGRP, RIP, and IS-IS. At the interdomain level, OSPF can import routes learned via EGP and BGP. OSPF routes can be exported into EGP and BGP. AuthenticationPlain text and MD5 authentication among neighboring routers within an area is supported. Routing interface parametersConfigurable parameters supported include interface output cost, retransmission interval, interface transmit delay, router priority, router "dead" and hello intervals, and authentication key. Virtual linksVirtual links are supported. NSSA areasRFC 1587. OSPF over demand circuitRFC 1793.
OSPF Configuration Task List

OSPF typically requires coordination among many internal routers, area border routers (routers connected to multiple areas), and autonomous system boundary routers. At a minimum, OSPF-based routers or access servers can be configured with all default parameter values, no authentication, and interfaces assigned to areas. If you intend to customize your environment, you must ensure coordinated configurations of all routers. To configure OSPF, complete the tasks in the following sections. Enabling OSPF is mandatory; the other tasks are optional, but might be required for your application. Enable OSPF Configure OSPF Interface Parameters Configure OSPF over Different Physical Networks Configure OSPF Area Parameters Configure OSPF Not So Stubby Area (NSSA) Configure Route Summarization between OSPF Areas Configure Route Summarization when Redistributing Routes into OSPF Create Virtual Links Generate a Default Route
Configure Lookup of DNS Names Force the Router ID Choice with a Loopback Interface Control Default Metrics Change the OSPF Administrative Distances Configure OSPF on Simplex Ethernet Interfaces Configure Route Calculation Timers Configure OSPF over On Demand Circuits Log Neighbors Going Up or Down Change the LSA Group Pacing Block OSPF LSA Flooding Ignore MOSPF LSA Packets Monitor and Maintain OSPF
In addition, you can specify route redistribution; see the task "Redistribute Routing Information" in the chapter "Configuring IP Routing Protocol-Independent Features" for information on how to configure route redistribution.
Enable OSPF
As with other routing protocols, enabling OSPF requires that you create an OSPF routing process, specify the range of IP addresses to be associated with the routing process, and assign area IDs to be associated with that range of IP addresses. Use the following commands, starting in global configuration mode: Step 1 Command router ospf process-id Purpose Enable OSPF routing, which places you in router configuration mode. Define an interface on which OSPF runs and define the area ID for that interface.
network address wildcard-mask area area-id
Configure OSPF Interface Parameters
Our OSPF implementation allows you to alter certain interface-specific OSPF parameters, as needed. You are not required to alter any of these parameters, but some interface parameters must be consistent across all routers in an attached network. Those parameters are controlled by the ip ospf hello-interval, ip ospf dead-interval, and ip ospf authentication-key commands. Therefore, be sure that if you do configure any of these parameters, the configurations for all routers on your network have compatible values. In interface configuration mode, use any of the following commands to specify interface parameters as needed for your network: Command ip ospf cost cost Purpose Explicitly specify the cost of sending a packet on an OSPF interface. Specify the number of seconds between link state advertisement retransmissions for adjacencies belonging to an OSPF interface.
ip ospf retransmitinterval seconds
ip ospf transmit-delay Set the estimated number of seconds it takes seconds to transmit a link state update packet on an OSPF interface. ip ospf priority number ip ospf hello-interval seconds Set priority to help determine the OSPF designated router for a network. Specify the length of time between the hello packets that the Cisco IOS software sends on an OSPF interface. Set the number of seconds that a device's hello packets must not have been seen before its neighbors declare the OSPF router down.
ip ospf dead-interval seconds
ip ospf authentication- Assign a password to be used by neighboring key key OSPF routers on a network segment that is using OSPF's simple password authentication. ip ospf messagedigest-key keyid md5 key ip ospf authentication Enable OSPF MD5 authentication.
Specifies the authentication type for an
[message-digest | null]
interface.
Configure OSPF over Different Physical Networks

OSPF classifies different media into the following three types of networks by default: Broadcast networks (Ethernet, Token Ring, FDDI) Nonbroadcast multiaccess networks (SMDS, Frame Relay, X.25) Point-to-point networks (HDLC, PPP)
You can configure your network as either a broadcast or a nonbroadcast multiaccess network. X.25 and Frame Relay provide an optional broadcast capability that can be configured in the map to allow OSPF to run as a broadcast network. See the x25 map and framerelay map command descriptions in the Wide-Area Networking Command Reference for more detail.
Configure Your OSPF Network Type

You have the choice of configuring your OSPF network type as either broadcast or nonbroadcast multiaccess, regardless of the default media type. Using this feature, you can configure broadcast networks as nonbroadcast multiaccess networks when, for example, you have routers in your network that do not support multicast addressing. You also can configure nonbroadcast multiaccess networks (such as X.25, Frame Relay, and SMDS) as broadcast networks. This feature saves you from having to configure neighbors, as described in the section "Configure OSPF for Nonbroadcast Networks." Configuring nonbroadcast, multiaccess networks as either broadcast or nonbroadcast assumes that there are virtual circuits from every router to every router or fully meshed network. This is not true for some cases, for example, because of cost constraints, or when you have only a partially meshed network. In these cases, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers not directly connected will go through the router that has virtual circuits to both routers. Note that it is not necessary to configure neighbors when using this feature. An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface having one or more neighbors. It creates multiple host routes. An OSPF point-tomultipoint network has the following benefits compared to nonbroadcast multiaccess and point-to-point networks: Point-to-multipoint is easier to configure because it requires no configuration of neighbor commands, it consumes only one IP subnet, and it requires no designated router election.
It costs less because it does not require a fully meshed topology.
It is more reliable because it maintains connectivity in the event of virtual circuit failure. To configure your OSPF network type, use the following command in interface configuration mode: Command ip ospf network {broadcast | nonbroadcast | {point-to-multipoint [nonbroadcast] }} Purpose Configure the OSPF network type for a specified interface.
See the "OSPF Point-to-Multipoint Example" section at the end of this chapter for an example of an OSPF point-to-multipoint network.
Configure Point-to-Multipoint, Broadcast Networks

On point-to-multipoint, broadcast networks, there is no need to specify neighbors. However, you can specify neighbors with the neighbor command, in which case you should specify a cost to that neighbor. Before this feature, some OSPF point-to-multipoint protocol traffic was treated as multicast traffic. Therefore, the neighbor command was not needed for point-tomultipoint interfaces because multicast took care of the traffic. Hellos, updates and acknowledgments were sent using multicast. In particular, multicast hellos discovered all neighbors dynamically. On any point-to-multipoint interface (broadcast or not), the Cisco IOS software assumed the cost to each neighbor was equal. The cost was configured with the ip ospf cost command. In reality, the bandwidth to each neighbor is different, so the cost should be different. With this feature, you can configure a separate cost to each neighbor. This feature applies to point-to-multipoint interfaces only. To treat an interface as point-to-multipoint broadcast and assign a cost to each neighbor, use the following commands beginning in interface configuration mode: Step 1 Command Purpose
ip ospf network Configure an interface as point-to-multipoint point-tofor broadcast media. multipoint exit Enter global configuration mode.
router ospf process-id neighbor ipaddress cost number
Configure an OSPF routing process and enter router configuration mode. Specify a neighbor and assign a cost to the neighbor.
Repeat Step 4 for each neighbor if you want to specify a cost. Otherwise, neighbors will assume the cost of the interface, based on the ip ospf cost command.
Configure OSPF for Nonbroadcast Networks

Because there might be many routers attached to an OSPF network, a designated router is selected for the network. It is necessary to use special configuration parameters in the designated router selection if broadcast capability is not configured. These parameters need only be configured in those devices that are themselves eligible to become the designated router or backup designated router (in other words, routers with a nonzero router priority value). To configure routers that interconnect to nonbroadcast networks, use the following command in router configuration mode: Command neighbor ip-address [priority number] [poll-interval seconds] Purpose Configure a router interconnecting to nonbroadcast networks.
You can specify the following neighbor parameters, as required: Priority for a neighboring router Nonbroadcast poll interval Interface through which the neighbor is reachable
On point-to-multipoint, nonbroadcast networks, you now use the neighbor command to identify neighbors. Assigning a cost to a neighbor is optional. Prior to Release 12.0, some customers were using point-to-multipoint on nonbroadcast media (such as classic IP over ATM), so their routers could not dynamically discover
their neighbors. This feature allows the neighbor command to be used on point-tomultipoint interfaces. On any point-to-multipoint interface (broadcast or not), the Cisco IOS software assumed the cost to each neighbor was equal. The cost was configured with the ip ospf cost command. In reality, the bandwidth to each neighbor is different, so the cost should be different. With this feature, you can configure a separate cost to each neighbor. This feature applies to point-to-multipoint interfaces only. To treat the interface as point-to-multipoint when the media does not support broadcast, use the following commands beginning in interface configuration mode: Step 1 Command Purpose
ip ospf network point-to- Configure an interface as point-tomultipoint non-broadcast multipoint for nonbroadcast media. exit router ospf process-id Enter global configuration mode. Configure an OSPF routing process and enter router configuration mode. Specify an OSPF neighbor and optionally assign a cost to the neighbor. Repeat Step 4 for each neighbor.
2 3
neighbor ip-address [cost number]
Configure OSPF Area Parameters

Our OSPF software allows you to configure several area parameters. These area parameters, shown in the following table, include authentication, defining stub areas, and assigning specific costs to the default summary route. Authentication allows password-based protection against unauthorized access to an area. Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the area border router, into the stub area for destinations outside the autonomous system. To take advantage of the OSPF stub area support, default routing must be used in the stub area. To further reduce the number of link state advertisements sent into a stub area, you can configure no-summary on the ABR to prevent it from sending summary link advertisement (link state advertisements Type 3) into the stub area.
In router configuration mode, specify any of the following area parameters as needed for your network: Command Purpose
area area-id authentication Enable authentication for an OSPF area. area area-id authentication Enable MD5 authentication for an OSPF message-digest area. area area-id stub [nosummary] area area-id default-cost cost Define an area to be a stub area.
Assign a specific cost to the default summary route used for the stub area.
Configure OSPF Not So Stubby Area (NSSA)

NSSA area is similar to OSPF stub area. NSSA does not flood Type 5 external link state advertisements (LSAs) from the core into the area, but it has the ability of importing AS external routes in a limited fashion within the area. NSSA allows importing of Type 7 AS external routes within NSSA area by redistribution. These Type 7 LSAs are translated into Type 5 LSAs by NSSA ABR which are flooded throughout the whole routing domain. Summarization and filtering are supported during the translation. Use NSSA to simplify administration if you are an Internet service provider (ISP), or a network administrator that must connect a central site using OSPF to a remote site that is using a different routing protocol. Prior to NSSA, the connection between the corporate site border router and the remote router could not be run as OSPF stub area because routes for the remote site cannot be redistributed into stub area. A simple protocol like RIP is usually run and handle the redistribution. This meant maintaining two routing protocols. With NSSA, you can extend OSPF to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA. In router configuration mode, use the following command to specify area parameters as needed to configure OSPF NSSA: Command area area-id nssa [no-redistribution] [defaultPurpose Define an area to be
information-originate]
NSSA.
In router configuration mode on the ABR, use the following command to control summarization and filtering of Type 7 LSA into Type 5 LSA: Command Purpose
summary address prefix mask (Optional) Control the summarization [not advertise] [tag tag] and filtering during the translation.
Implementation Considerations
Evaluate the following considerations before implementing this feature: You can set a Type 7 default route that can be used to reach external destinations. When configured, the router generates a Type 7 default into the NSSA by the NSSA ABR. Every router within the same area must agree that the area is NSSA; otherwise, the routers will not be able to communicate with each other. If possible, avoid using explicit redistribution on NSSA ABR because confusion may result over which packets are being translated by which router.
Configure Route Summarization between OSPF Areas

Route summarization is the consolidation of advertised addresses. This feature causes a single summary route to be advertised to other areas by an ABR. In OSPF, an ABR will advertise networks in one area into another area. If the network numbers in an area are assigned in a way such that they are contiguous, you can configure the ABR to advertise a summary route that covers all the individual networks within the area that fall into the specified range. To specify an address range, use the following command in router configuration mode: Command Purpose
area area-id range address mask Specify an address range for which a [advertise | not-advertise] single route will be advertised.
Configure Route Summarization when Redistributing Routes into OSPF

When redistributing routes from other protocols into OSPF (as described in the chapter "Configuring IP Routing Protocol-Independent Features"), each route is advertised individually in an external link state advertisement (LSA). However, you can configure the Cisco IOS software to advertise a single route for all the redistributed routes that are covered by a specified network address and mask. Doing so helps decrease the size of the OSPF link state database. To have the software advertise one summary route for all redistributed routes covered by a network address and mask, use the following command in router configuration mode: Command summary-address address mask Purpose Specify an address and mask that covers redistributed routes, so only one summary route is advertised.
Create Virtual Links

In OSPF, all areas must be connected to a backbone area. If there is a break in backbone continuity, or the backbone is purposefully partitioned, you can establish a virtual link. The two end points of a virtual link are Area Border Routers. The virtual link must be configured in both routers. The configuration information in each router consists of the other virtual endpoint (the other ABR), and the nonbackbone area that the two routers have in common (called the transit area). Note that virtual links cannot be configured through stub areas. To establish a virtual link, use the following command in router configuration mode: Command area area-id virtual-link router-id [authentication [message-digest | null ]] [hello-interval seconds] [retransmit-interval seconds] [transmit-delay seconds] [dead-interval seconds] [[authentication-key key] | [message-digest-key keyid md5 key]] Purpose Establish a virtual link.
To display information about virtual links, use the show ip ospf virtual-links EXEC command. To display the router ID of an OSPF router, use the show ip ospf EXEC command.
Generate a Default Route

You can force an autonomous system boundary router to generate a default route into an OSPF routing domain. Whenever you specifically configure redistribution of routes into an OSPF routing domain, the router automatically becomes an autonomous system boundary router. However, an autonomous system boundary router does not, by default, generate a default route into the OSPF routing domain. To force the autonomous system boundary router to generate a default route, use the following command in router configuration mode: Command default-information originate [always] [metric metric-value] [metric-type type-value] [routemap map-name] Purpose Force the autonomous system boundary router to generate a default route into the OSPF routing domain.
See the discussion of redistribution of routes in the "Configuring IP Routing ProtocolIndependent Features" chapter.
Configure Lookup of DNS Names

You can configure OSPF to look up Domain Naming System (DNS) names for use in all OSPF show command displays. This feature makes it easier to identify a router, because it is displayed by name rather than by its router ID or neighbor ID. To configure DNS name lookup, use the following command in global configuration mode: Command ip ospf name-lookup Purpose Configure DNS name lookup.
Force the Router ID Choice with a Loopback Interface

OSPF uses the largest IP address configured on the interfaces as its router ID. If the interface associated with this IP address is ever brought down, or if the address is removed, the OSPF process must recalculate a new router ID and resend all its routing information out its interfaces. If a loopback interface is configured with an IP address, the Cisco IOS software will use this IP address as its router ID, even if other interfaces have larger IP addresses. Since loopback interfaces never go down, greater stability in the routing table is achieved.
OSPF automatically prefers a loopback interface over any other kind, and it chooses the highest IP address among all loopback interfaces. If no loopback interfaces are present, the highest IP address in the router is chosen. You cannot tell OSPF to use any particular interface. To configure an IP address on a loopback interface, use the following commands, starting in global configuration mode: Step 1 Command interface loopback 0 ip address address mask Purpose Create a loopback interface, which places you in interface configuration mode. Assign an IP address to this interface.
Control Default Metrics

In Cisco IOS Release 10.3 and later, by default, OSPF calculates the OSPF metric for an interface according to the bandwidth of the interface. For example, a 64K link gets a metric of 1562, while a T1 link gets a metric of 64. The OSPF metric is calculated as ref-bw divided by bandwidth, with ref-bw equal to 108 by default, and bandwidth determined by the bandwidth command. The calculation gives FDDI a metric of 1. If you have multiple links with high bandwidth, you might want to specify a larger number to differentiate the cost on those links. To do so, use the following command in router configuration mode: Command ospf auto-cost reference-bandwidth ref-bw Purpose Differentiate high bandwidth links.
Change the OSPF Administrative Distances

An administrative distance is a rating of the trustworthiness of a routing information source, such as an individual router or a group of routers. Numerically, an administrative distance is an integer between 0 and 255. In general, the higher the value, the lower the trust rating. An administrative distance of 255 means the routing information source cannot be trusted at all and should be ignored. OSPF uses three different administrative distances: intra-area, inter-area, and external. Routes within an area are intra-area; routes to another area are inter-area; and routes
from another routing domain learned via redistribution are external. The default distance for each type of route is 110. To change any of the OSPF distance values, use the following command in router configuration mode: Command distance ospf {[intra-area dist1] [inter-area dist2] [external dist3]} Purpose Change the OSPF distance values.
For an example of changing administrative distance, see the section "Changing OSPF Administrative Distance" at the end of this chapter.
Configure OSPF on Simplex Ethernet Interfaces

Because simplex interfaces between two devices on an Ethernet represent only one network segment, for OSPF you must configure the transmitting interface to be a passive interface. This prevents OSPF from sending hello packets for the transmitting interface. Both devices are able to see each other via the hello packet generated for the receiving interface. To configure OSPF on simplex Ethernet interfaces, use the following command in router configuration mode: Command Purpose
passive-interface type Suppress the sending of hello packets through number the specified interface.
Configure Route Calculation Timers

You can configure the delay time between when OSPF receives a topology change and when it starts a shortest path first (SPF) calculation. You can also configure the hold time between two consecutive SPF calculations. To do this, use the following command in router configuration mode: Command Purpose
timers spf spf-delay spf-holdtime Configure route calculation timers.
Configure OSPF over On Demand Circuits

The OSPF on demand circuit is an enhancement to the OSPF protocol that allows efficient operation over on demand circuits like ISDN, X.25 SVCs and dial-up lines. This feature supports RFC 1793, Extending OSPF to Support Demand Circuits. Prior to this feature, OSPF periodic hello and link state advertisements (LSAs) updates would be exchanged between routers that connected the on demand link, even when no changes occurred in the hello or LSA information. With this feature, periodic hellos are suppressed and the periodic refreshes of LSAs are not flooded over the demand circuit. These packets bring up the link only when they are exchanged for the first time, or when a change occurs in the information they contain. This operation allows the underlying datalink layer to be closed when the network topology is stable. This feature is useful when you want to connect telecommuters or branch offices to an OSPF backbone at a central site. In this case, OSPF for on demand circuits allows the benefits of OSPF over the entire domain, without excess connection costs. Periodic refreshes of hello updates, LSA updates, and other protocol overhead are prevented from enabling the on demand circuit when there is no "real" data to transmit. Overhead protocols such as hellos and LSAs are transferred over the on demand circuit only upon initial setup and when they reflect a change in the topology. This means that critical changes to the topology that require new SPF calculations are transmitted in order to maintain network topology integrity. Periodic refreshes that do not include changes, however, are not transmitted across the link. To configure OSPF for on demand circuits, use the following commands, beginning in global configuration mode: Step 1 2 3 Command router ospf process-id interface type number ip ospf demandcircuit Purpose Enable OSPF operation. Enter interface configuration mode. Configure OSPF on an on demand circuit.
If the router is part of a point-to-point topology, then only one end of the demand circuit must be configured with this command. However, all routers must have this feature loaded. If the router is part of a point-to-multipoint topology, only the multipoint end must be configured with this command.
For an example of OSPF over an on-demand circuit, see the section "OSPF over OnDemand Routing Example" at the end of this chapter.
Implementation Considerations
Evaluate the following considerations before implementing this feature: Because LSAs that include topology changes are flooded over an on demand circuit, it is advised to put demand circuits within OSPF stub areas, or within NSSAs to isolate the demand circuits from as many topology changes as possible. To take advantage of the on demand circuit functionality within a stub area or NSSA, every router in the area must have this feature loaded. If this feature is deployed within a regular area, all other regular areas must also support this feature before the demand circuit functionality can take effect. This is because type 5 external LSAs are flooded throughout all areas. You do not want to do on a broadcast-based network topology because the overhead protocols (such as hellos and LSAs) cannot be successfully suppressed, which means the link will remain up. Configuring the router for an OSPF on-demand circuit with an asynchronous interface is not a supported configuration. The supported configuration is to use dialer interfaces on both ends of the circuit. For more information, refer to the following TAC URL: /en/US/tech/tk365/technologies_tech_note09186a008009481b.shtml#reason5
Log Neighbors Going Up or Down

To configure the router to send a syslog message when an OSPF neighbor goes up or down, use the following command in router configuration mode: Command ospf log-adjacencychanges Purpose Send syslog message when an OSPF neighbor goes up or down.
Configure this command if you want to know about OSPF neighbors going up or down without turning on the debugging command debug ip ospf adjacency. The ospf logadjacency-changes command provides a higher level view of such changes with less output.
Change the LSA Group Pacing
The OSPF LSA group pacing feature allows the router to group together OSPF link state advertisements (LSAs) and pace the refreshing, checksumming, and aging functions. The group pacing results in more efficient use of the router. The router groups together OSPF LSAs and paces the refreshing, checksumming, and aging functions so that sudden hits on CPU usage and network resources are avoided. This feature is most beneficial to large OSPF networks. OSPF LSA group pacing is enabled by default. For typical customers, the default group pacing interval for refreshing, checksumming, and aging is appropriate and you need not configure this feature.
Original LSA Behavior

Each OSPF LSA has an age, which indicates whether the LSA is still valid. Once the LSA reaches the maximum age (one hour), it is discarded. During the aging process, the originating router sends a refresh packet every 30 minutes to refresh the LSA. Refresh packets are sent to keep the LSA from expiring, whether there has been a change in the network topology or not. Checksumming is performed on all LSAs every 10 minutes. The router keeps track of LSAs it generates and LSAs it receives from other routers. The router refreshes LSAs it generated; it ages the LSAs it received from other routers. Prior to the LSA group pacing feature, the Cisco IOS software would perform refreshing on a single timer, and checksumming and aging on another timer. In the case of refreshing, for example, the software would scan the whole database every 30 minutes, refreshing every LSA the router generated, no matter how old it was. illustrates all the LSAs being refreshed at once. This process wasted CPU resources because only a small portion of the database needed to be refreshed. A large OSPF database (several thousand LSAs) could have thousands of LSAs with different ages. Refreshing on a single timer resulted in the age of all LSAs becoming synchronized, which resulted in much CPU processing at once. Furthermore, a huge number of LSAs could cause a sudden increase of network traffic, consuming a large amount of network resources in a short period of time. Figure 21 OSPF LSAs on a Single Timer without Group Pacing
Solution
This problem is solved by each LSA having its own timer. Again using the example of refreshing, each LSA gets refreshed when it is 30 minutes old, independent of other LSAs. So CPU is used only when necessary. However, LSAs being refreshed at frequent, random intervals would require many packets for the few refreshed LSAs the router must send out. That would be inefficient use of bandwidth.
Therefore, the router delays the LSA refresh function for an interval of time instead of performing it when the individual timers are reached. The accumulated LSAs constitute a group, which is then refreshed and sent out in one packet or more. Thus, the refresh packets are paced, as are the checksumming and aging. The pacing interval is configurable; it defaults to 4 minutes, which is randomized to further avoid synchronization. illustrates the case of refresh packets. The first timeline illustrates individual LSA timers; the second timeline illustrates individual LSA timers with group pacing. Figure 22 OSPF LSAs on Individual Timers with Group Pacing
The group pacing interval is inversely proportional to the number of LSAs the router is refreshing, checksumming, and aging. For example, if you have approximately 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. The default value of pacing between LSA groups is 240 seconds (4 minutes). The range is 10 seconds to 1800 seconds (half an hour). To change the LSA group pacing interval, use the following command in router configuration mode: Command Purpose
timers lsa-group-pacing seconds Change the group pacing of LSAs.
For an example, see the section "LSA Group Pacing Example" at the end of this chapter.
Block OSPF LSA Flooding

By default, OSPF floods new LSAs over all interfaces in the same area, except the interface on which the LSA arrives. Some redundancy is desirable, because it ensures
robust flooding. However, too much redundancy can waste bandwidth and might destabilize the network due to excessive link and CPU usage in certain topologies. An example would be a fully meshed topology. You can block OSPF flooding of LSAs two ways, depending on the type of networks: On broadcast, nonbroadcast, and point-to-point networks, you can block flooding over specified OSPF interfaces. On point-to-multipoint networks, you can block flooding to a specified neighbor.
On broadcast, nonbroadcast, and point-to-point networks, to prevent flooding of OSPF LSAs, use the following command in interface configuration mode: Command Purpose
ospf database-filter all Block the flooding of OSPF LSA packets to out the interface.
On point-to-multipoint networks, to prevent flooding of OSPF LSAs, use the following command in router configuration mode: Command neighbor ip-address database-filter all out Purpose Block the flooding of OSPF LSA packets to the specified neighbor.
For an example of blocking LSA flooding, see the section "Block LSA Flooding Example" at the end of this chapter.
Ignore MOSPF LSA Packets

Cisco routers do not support LSA Type 6 (MOSPF), 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. To do so, use the following command in router configuration mode: Command ospf ignore lsa mospf Purpose Prevent the router from generating syslog messages when it receives MOSPF LSA packets.
For an example of suppressing MOSPF LSA packets, see the section "Ignore MOSPF LSA Packets Example" at the end of this chapter.
Monitor and Maintain OSPF

You can display specific statistics such as the contents of IP routing tables, caches, and databases. Information provided can be used to determine resource utilization and solve network problems. You can also display information about node reachability and discover the routing path your device's packets are taking through the network. To display various routing statistics, use the following commands in EXEC mode: Command show ip ospf [process-id] show ip ospf [process-id area-id] database show ip ospf [process-id area-id] database [router] [link-state-id] show ip ospf [process-id area-id] database [router] [self-originate] show ip ospf [process-id area-id] database [router] [adv-router [ip-address]] show ip ospf [process-id area-id] database [network] [link-state-id] show ip ospf [process-id area-id] database [summary] [link-state-id] show ip ospf [process-id area-id] database [asbrsummary] [link-state-id] show ip ospf [process-id] database [external] [linkstate-id] show ip ospf [process-id Purpose Display general information about OSPF routing processes. Display lists of information related to the OSPF database.
area-id] database [databasesummary] show ip ospf border-routers Display the internal OSPF routing table entries to Area Border Router (ABR) and Autonomous System Boundary Router (ASBR). show ip ospf interface [interface-name] show ip ospf neighbor [interface-name] [neighborid] detail show ip ospf request-list [nbr] [intf] [intf-nbr] show ip ospf retransmission-list [nbr] [intf] [intf-nbr] show ip ospf virtual-links Display OSPF-related interface information. Display OSPF-neighbor information on a per-interface basis.
Display a list of all LSAs requested by a router. Display a list of all LSAs waiting to be retransmitted.
Display OSPF-related virtual links information.
OSPF Configuration Examples

The following sections provide OSPF configuration examples: OSPF Point-to-Multipoint Example OSPF Point-to-Multipoint, Broadcast Example OSPF Point-to-Multipoint, Nonbroadcast Example Variable-Length Subnet Masks Example OSPF Routing and Route Redistribution Examples Route Map Examples Changing OSPF Administrative Distance
OSPF over On-Demand Routing Example LSA Group Pacing Example Block LSA Flooding Example Ignore MOSPF LSA Packets Example
OSPF Point-to-Multipoint Example

In , Mollie uses DLCI 201 to communicate with Neon, DLCI 202 to Jelly, and DLCI 203 to Platty. Neon uses DLCI 101 to communicate with Mollie and DLCI 102 to communicate with Platty. Platty communicates with Neon (DLCI 401) and Mollie (DLCI 402). Jelly communicates with Mollie (DLCI 301). Figure 23 OSPF Point-to-Multipoint Example
Mollie's Configuration
hostname mollie ! interface serial 1 ip address 10.0.0.2 255.0.0.0 ip ospf network point-to-multipoint encapsulation frame-relay frame-relay map ip 10.0.0.1 201 broadcast frame-relay map ip 10.0.0.3 202 broadcast frame-relay map ip 10.0.0.4 203 broadcast ! router ospf 1 network 10.0.0.0 0.0.0.255 area 0
Neon's Configuration
hostname neon ! interface serial 0 ip address 10.0.0.1 255.0.0.0 ip ospf network point-to-multipoint encapsulation frame-relay frame-relay map ip 10.0.0.2 101 broadcast frame-relay map ip 10.0.0.4 102 broadcast !
router ospf 1 network 10.0.0.0 0.0.0.255 area 0
Platty's Configuration
hostname platty ! interface serial 3 ip address 10.0.0.4 255.0.0.0 ip ospf network point-to-multipoint encapsulation frame-relay clock rate 1000000 frame-relay map ip 10.0.0.1 401 broadcast frame-relay map ip 10.0.0.2 402 broadcast ! router ospf 1 network 10.0.0.0 0.0.0.255 area 0
Jelly's Configuration
hostname jelly ! interface serial 2 ip address 10.0.0.3 255.0.0.0 ip ospf network point-to-multipoint encapsulation frame-relay clock rate 2000000 frame-relay map ip 10.0.0.2 301 broadcast ! router ospf 1 network 10.0.0.0 0.0.0.255 area 0
OSPF Point-to-Multipoint, Broadcast Example

The following example illustrates a point-to-multipoint network with broadcast:
interface Serial0 ip address 10.0.1.1 255.255.255.0 encapsulation frame-relay ip ospf cost 100 ip ospf network point-to-multipoint frame-relay map ip 10.0.1.3 202 broadcast frame-relay map ip 10.0.1.4 203 broadcast frame-relay map ip 10.0.1.5 204 broadcast frame-relay local-dlci 200 ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 neighbor 10.0.1.5 cost 5 neighbor 10.0.1.4 cost 10
The following example shows the configuration of the neighbor at 10.0.1.3:

interface serial 0 ip address 10.0.1.3 255.255.255.0 ip ospf network point-to-multipoint encapsulation frame-relay
frame-relay local-dlci 301 frame-relay map ip 10.0.1.1 300 broadcast no shut ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0
The output shown for neighbors in the first configuration above looks like this:
Router# show ip ospf neighbor Neighbor ID Pri State Interface 4.1.1.1 1 FULL/ Serial0 3.1.1.1 1 FULL/ Serial0 2.1.1.1 1 FULL/ Serial0 Dead Time 00:01:50 00:01:47 00:01:45 Address 10.0.1.5 10.0.1.4 10.0.1.3
The route information in the first configuration above looks like this:
Router# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR Gateway of last resort is not set C 1.0.0.0/8 is directly connected, Loopback0 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks O 10.0.1.3/32 [110/100] via 10.0.1.3, 00:39:08, Serial0 C 10.0.1.0/24 is directly connected, Serial0 O 10.0.1.5/32 [110/5] via 10.0.1.5, 00:39:08, Serial0 O 10.0.1.4/32 [110/10] via 10.0.1.4, 00:39:08, Serial0
OSPF Point-to-Multipoint, Nonbroadcast Example

The following example illustrates a point-to-multipoint network with nonbroadcast:
interface Serial0 ip address 10.0.1.1 255.255.255.0 ip ospf network point-to-multipoint non-broadcast encapsulation frame-relay no keepalive frame-relay local-dlci 200 frame-relay map ip 10.0.1.3 202 frame-relay map ip 10.0.1.4 203 frame-relay map ip 10.0.1.5 204 no shut ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 neighbor 10.0.1.3 cost 5 neighbor 10.0.1.4 cost 10
neighbor 10.0.1.5 cost 15
The following example is the configuration for the router on the other side:
interface Serial9/2 ip address 10.0.1.3 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast no ip mroute-cache no keepalive no fair-queue frame-relay local-dlci 301 frame-relay map ip 10.0.1.1 300 no shut ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0
The output shown for neighbors in the first configuration above looks like this:
Router# show ip ospf neighbor Neighbor ID Pri State Interface 4.1.1.1 1 FULL/ Serial0 3.1.1.1 1 FULL/ Serial0 2.1.1.1 1 FULL/ Serial0 Dead Time 00:01:52 00:01:52 00:01:52 Address 10.0.1.5 10.0.1.4 10.0.1.3
Variable-Length Subnet Masks Example

OSPF, static routes, and IS-IS support variable-length subnet masks (VLSMs). With VLSMs, you can use different masks for the same network number on different interfaces, which allows you to conserve IP addresses and more efficiently use available address space. In the following example, a 30-bit subnet mask is used, leaving two bits of address space reserved for serial line host addresses. There is sufficient host address space for two host endpoints on a point-to-point serial link.
interface ethernet 0 ip address 131.107.1.1 255.255.255.0 ! 8 bits of host address space reserved for ethernets interface serial 0 ip address 131.107.254.1 255.255.255.252 ! 2 bits of address space reserved for serial lines ! Router is configured for OSPF and assigned AS 107 router ospf 107 ! Specifies network directly connected to the router network 131.107.0.0 0.0.255.255 area 0.0.0.0
OSPF Routing and Route Redistribution Examples

OSPF typically requires coordination among many internal routers, area border routers, and autonomous system boundary routers. At a minimum, OSPF-based routers can be configured with all default parameter values, with no authentication, and with interfaces assigned to areas. Three examples follow: The first is a simple configuration illustrating basic OSPF commands.
The second example illustrates a configuration for an internal router, ABR, and ASBRs within a single, arbitrarily assigned, OSPF autonomous system. The third example illustrates a more complex configuration and the application of various tools available for controlling OSPF-based routing environments.
Basic OSPF Configuration Example

The following example illustrates a simple OSPF configuration that enables OSPF routing process 9000, attaches Ethernet 0 to area 0.0.0.0, and redistributes RIP into OSPF, and OSPF into RIP:
interface ethernet 0 ip address 130.93.1.1 255.255.255.0 ip ospf cost 1 ! interface ethernet 1 ip address 130.94.1.1 255.255.255.0 ! router ospf 9000 network 130.93.0.0 0.0.255.255 area 0.0.0.0 redistribute rip metric 1 subnets ! router rip network 130.94.0.0 redistribute ospf 9000 default-metric 1
Basic OSPF Configuration Example for Internal Router, ABR, and ASBRs
The following example illustrates the assignment of four area IDs to four IP address ranges. In the example, OSPF routing process 109 is initialized, and four OSPF areas are defined: 10.9.50.0, 2, 3, and 0. Areas 10.9.50.0, 2, and 3 mask specific address ranges, while Area 0 enables OSPF for all other networks.
router ospf 109 network 131.108.20.0 0.0.0.255 area 10.9.50.0 network 131.108.0.0 0.0.255.255 area 2 network 131.109.10.0 0.0.0.255 area 3 network 0.0.0.0 255.255.255.255 area 0 !
! Interface Ethernet0 is in area 10.9.50.0: interface ethernet 0 ip address 131.108.20.5 255.255.255.0 ! ! Interface Ethernet1 is in area 2: interface ethernet 1 ip address 131.108.1.5 255.255.255.0 ! ! Interface Ethernet2 is in area 2: interface ethernet 2 ip address 131.108.2.5 255.255.255.0 ! ! Interface Ethernet3 is in area 3: interface ethernet 3 ip address 131.109.10.5 255.255.255.0 ! ! Interface Ethernet4 is in area 0: interface ethernet 4 ip address 131.109.1.1 255.255.255.0 ! ! Interface Ethernet5 is in area 0: interface ethernet 5 ip address 10.1.0.1 255.255.0.0
Each network area router configuration command is evaluated sequentially, so the order of these commands in the configuration is important. The Cisco IOS software sequentially evaluates the address/wildcard-mask pair for each interface. See the "OSPF Commands" chapter of the Network Protocols Command Reference, Part 1 for more information. Consider the first network area command. Area ID 10.9.50.0 is configured for the interface on which subnet 131.108.20.0 is located. Assume that a match is determined for interface Ethernet 0. Interface Ethernet 0 is attached to Area 10.9.50.0 only. The second network area command is evaluated next. For Area 2, the same process is then applied to all interfaces (except interface Ethernet 0). Assume that a match is determined for interface Ethernet 1. OSPF is then enabled for that interface and Ethernet 1 is attached to Area 2. This process of attaching interfaces to OSPF areas continues for all network area commands. Note that the last network area command in this example is a special case. With this command, all available interfaces (not explicitly attached to another area) are attached to Area 0.
Complex Internal Router, ABR, and ASBRs Example

The following example outlines a configuration for several routers within a single OSPF autonomous system. provides a general network map that illustrates this example configuration. Figure 24 Sample OSPF Autonomous System Network Map
In this configuration, five routers are configured with OSPF: Router A and Router B are both internal routers within Area 1.
Router C is an OSPF area border router. Note that for Router C, Area 1 is assigned to E3 and Area 0 is assigned to S0. Router D is an internal router in Area 0 (backbone area). In this case, both network router configuration commands specify the same area (Area 0, or the backbone area). Router E is an OSPF autonomous system boundary router. Note that BGP routes are redistributed into OSPF and that these routes are advertised by OSPF.
Note It is not necessary to include definitions of all areas in an OSPF autonomous system in the configuration of all routers in the autonomous system. You must only define the directly connected areas. In the example that follows, routes in Area 0 are learned by the routers in Area 1 (Router A and Router B) when the area border router (Router C) injects summary link state advertisements (LSAs) into Area 1.
The OSPF domain in BGP autonomous system 109 is connected to the outside world via the BGP link to the external peer at IP address 11.0.0.6.
Router AInternal Router

interface ethernet 1 ip address 131.108.1.1 255.255.255.0 router ospf 1 network 131.108.0.0 0.0.255.255 area 1
Router BInternal Router

interface ethernet 2 ip address 131.108.1.2 255.255.255.0 router ospf 202 network 131.108.0.0 0.0.255.255 area 1
Router CABR
interface ethernet 3 ip address 131.108.1.3 255.255.255.0 interface serial 0 ip address 131.108.2.3 255.255.255.0 router ospf 999 network 131.108.1.0 0.0.0.255 area 1 network 131.108.2.0 0.0.0.255 area 0
Router DInternal Router

interface ethernet 4 ip address 10.0.0.4 255.0.0.0 interface serial 1 ip address 131.108.2.4 255.255.255.0 router ospf 50 network 131.108.2.0 0.0.0.255 area 0 network 10.0.0.0 0.255.255.255 area 0
Router EASBR
interface ethernet 5 ip address 10.0.0.5 255.0.0.0
interface serial 2 ip address 11.0.0.5 255.0.0.0 router ospf 65001 network 10.0.0.0 0.255.255.255 area 0 redistribute bgp 109 metric 1 metric-type 1 router bgp 109 network 131.108.0.0 network 10.0.0.0 neighbor 11.0.0.6 remote-as 110
Complex OSPF Configuration for ABR Examples

The following example configuration accomplishes several tasks in setting up an ABR. These tasks can be split into two general categories: Basic OSPF configuration Route redistribution
The specific tasks outlined in this configuration are detailed briefly in the following descriptions. illustrates the network address ranges and area assignments for the interfaces. Figure 25 Interface and Area Specifications for OSPF Example Configuration
The basic configuration tasks in this example are as follows: Configure address ranges for Ethernet 0 through Ethernet 3 interfaces. Enable OSPF on each interface. Set up an OSPF authentication password for each area and network.
Assign link state metrics and other OSPF interface configuration options.
Create a stub area with area id 36.0.0.0. (Note that the authentication and stub options of the area router configuration command are specified with separate area command entries, but can be merged into a single area command.) Specify the backbone area (Area 0).
Configuration tasks associated with redistribution are as follows: Redistribute IGRP and RIP into OSPF with various options set (including metrictype, metric, tag, and subnet). Redistribute IGRP and OSPF into RIP.
The following is an example OSPF configuration:

interface ethernet 0 ip address 192.42.110.201 255.255.255.0 ip ospf authentication-key abcdefgh ip ospf cost 10 ! interface ethernet 1 ip address 131.119.251.201 255.255.255.0 ip ospf authentication-key ijklmnop ip ospf cost 20 ip ospf retransmit-interval 10 ip ospf transmit-delay 2 ip ospf priority 4 ! interface ethernet 2 ip address 131.119.254.201 255.255.255.0 ip ospf authentication-key abcdefgh ip ospf cost 10 ! interface ethernet 3 ip address 36.56.0.201 255.255.0.0 ip ospf authentication-key ijklmnop ip ospf cost 20 ip ospf dead-interval 80
OSPF is on network 131.119.0.0:

router ospf 201 network 36.0.0.0 0.255.255.255 area 36.0.0.0 network 192.42.110.0 0.0.0.255 area 192.42.110.0 network 131.119.0.0 0.0.255.255 area 0 area 0 authentication area 36.0.0.0 stub area 36.0.0.0 authentication area 36.0.0.0 default-cost 20 area 192.42.110.0 authentication area 36.0.0.0 range 36.0.0.0 255.0.0.0 area 192.42.110.0 range 192.42.110.0 255.255.255.0 area 0 range 131.119.251.0 255.255.255.0 area 0 range 131.119.254.0 255.255.255.0
redistribute igrp 200 metric-type 2 metric 1 tag 200 subnets redistribute rip metric-type 2 metric 1 tag 200
IGRP autonomous system 200 is on 131.119.0.0:

router igrp 200 network 131.119.0.0 ! ! RIP for 192.42.110 ! router rip network 192.42.110.0 redistribute igrp 200 metric 1 redistribute ospf 201 metric 1
Route Map Examples

The examples in this section illustrate the use of redistribution, with and without route maps. Examples from both the IP and CLNS routing protocols are given. The following example redistributes all OSPF routes into IGRP:
router igrp 109 redistribute ospf 110
The following example redistributes RIP routes with a hop count equal to 1 into OSPF. These routes will be redistributed into OSPF as external link state advertisements with a metric of 5, metric type of Type 1, and a tag equal to 1.
router ospf 109 redistribute rip route-map rip-to-ospf ! route-map rip-to-ospf permit match metric 1 set metric 5 set metric-type type1 set tag 1
The following example redistributes OSPF learned routes with tag 7 as a RIP metric of 15:
router rip redistribute ospf 109 route-map 5 ! route-map 5 permit match tag 7 set metric 15
The following example redistributes OSPF intra-area and interarea routes with next-hop routers on serial interface 0 into BGP with an INTER_AS metric of 5:
router bgp 109 redistribute ospf 109 route-map 10 ! route-map 10 permit match route-type internal match interface serial 0 set metric 5
The following example redistributes two types of routes into the integrated IS-IS routing table (supporting both IP and CLNS). The first are OSPF external IP routes with tag 5; these are inserted into Level 2 IS-IS LSPs with a metric of 5. The second are ISOIGRP derived CLNS prefix routes that match CLNS access list 2000. These will be redistributed into IS-IS as Level 2 LSPs with a metric of 30.
router isis redistribute ospf 109 route-map 2 redistribute iso-igrp nsfnet route-map 3 ! route-map 2 permit match route-type external match tag 5 set metric 5 set level level-2 ! route-map 3 permit match address 2000 set metric 30
With the following configuration, OSPF external routes with tags 1, 2, 3, and 5 are redistributed into RIP with metrics of 1, 1, 5, and 5, respectively. The OSPF routes with a tag of 4 are not redistributed.
router rip redistribute ospf 109 route-map 1 ! route-map 1 permit match tag 1 2 set metric 1 ! route-map 1 permit match tag 3 set metric 5 ! route-map 1 deny match tag 4 ! route map 1 permit match tag 5 set metric 5
The following configuration sets the condition that if there is an OSPF route to network 140.222.0.0, generate the default network 0.0.0.0 into RIP with a metric of 1:
router rip redistribute ospf 109 route-map default
! route-map default permit match ip address 1 set metric 1 ! access-list 1 permit 140.222.0.0 0.0.255.255 access-list 2 permit 0.0.0.0 0.0.0.0
In the following configuration, a RIP learned route for network 160.89.0.0 and an ISOIGRP learned route with prefix 49.0001.0002 will be redistributed into an IS-IS Level 2 LSP with a metric of 5:
router isis redistribute rip route-map 1 redistribute iso-igrp remote route-map 1 ! route-map 1 permit match ip address 1 match clns address 2 set metric 5 set level level-2 ! access-list 1 permit 160.89.0.0 0.0.255.255 clns filter-set 2 permit 49.0001.0002...
The following configuration example illustrates how a route map is referenced by the default-information router configuration command. This is called conditional default origination. OSPF will originate the default route (network 0.0.0.0) with a Type 2 metric of 5 if 140.222.0.0, with network 0.0.0.0 in the routing table. Extended accesslists cannot be used in a route map for conditional default origination.
Note Only routes external to the OSPF process can be used for tracking, such as nonOSPF routes or OSPF routes from a separate OSPF process.
route-map ospf-default permit match ip address 1 set metric 5 set metric-type type-2 ! access-list 1 140.222.0.0 0.0.255.255 ! router ospf 109 default-information originate route-map ospf-default
Changing OSPF Administrative Distance

The following example changes the external distance to 200, making it less trustworthy. illustrates the example. Figure 26
OSPF Administrative Distance
Router A
router ospf 1 redistribute ospf 2 subnet distance ospf external 200 ! router ospf 2 redistribute ospf 1 subnet distance ospf external 200
Router B
router ospf 1 redistribute ospf 2 subnet distance ospf external 200 ! router ospf 2 redistribute ospf 1 subnet distance ospf external 200
OSPF over On-Demand Routing Example

The following configuration allows OSPF over an on-demand circuit, as shown in . Note that the on-demand circuit is defined on one side only (BRI 0 on RouterA). It is not required to be configured on both sides. Figure 27 OSPF over On-Demand Circuit
Router A
username RouterB password 7 060C1A2F47 isdn switch-type basic-5ess ip routing ! interface TokenRing0 ip address 140.10.20.7 255.255.255.0 no shut ! interface BRI0 no cdp enable description connected PBX 1485 ip address 140.10.10.7 255.255.255.0 encapsulation ppp ip ospf demand-circuit dialer map ip 140.10.10.6 name RouterB broadcast 61484 dialer-group 1 ppp authentication chap no shut ! router ospf 100 network 140.10.10.0 0.0.0.255 area 0 network 140.10.20.0 0.0.0.255 area 0 ! dialer-list 1 protocol ip permit
Router B
username RouterA password 7 04511E0804 isdn switch-type basic-5ess ip routing ! interface Ethernet0 ip address 140.10.60.6 255.255.255.0 no shut ! interface BRI0 no cdp enable description connected PBX 1484 ip address 140.10.10.6 255.255.255.0 encapsulation ppp dialer map ip 140.10.10.7 name RouterA broadcast 61485 dialer-group 1 ppp authentication chap no shut ! router ospf 100 network 140.10.10.0 0.0.0.255 area 0 network 140.10.60.0 0.0.0.255 area 0 ! dialer-list 1 protocol ip permit
LSA Group Pacing Example
The following example changes the OSPF pacing between LSA groups to 60 seconds:
router ospf timers lsa-group-pacing 60
Block LSA Flooding Example

The following example prevents flooding of OSPF LSAs to broadcast, nonbroadcast, or point-to-point networks reachable through Ethernet interface 0:
interface ethernet 0 ospf database-filter all out
The following example prevents flooding of OSPF LSAs to point-to-multipoint networks to the neighbor at IP address 1.2.3.4:
router ospf 109 neighbor 1.2.3.4 database-filter all out
Ignore MOSPF LSA Packets Example

The following example configures the router to suppress the sending of syslog messages when it receives MOSPF packets:
router ospf 109 ospf ignore lsa mospf
http://www.lab.dit.upm.es/~labrst/config/manuales-cisco/
Configuring DHCP
This chapter describes how to configure Dynamic Host Configuration Protocol (DHCP). For a complete description of the DHCP commands listed in this chapter, refer to the "DHCP Commands" chapter of the Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services publication. To locate documentation of other commands that appear in this chapter, use the command reference master index, or search online. As explained in RFC 2131, Dynamic Host Configuration Protocol, DHCP provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP Server to a host and a mechanism for allocating network addresses to hosts. DHCP is built on a client/server model, where designated DHCP Server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. By default, Cisco routers running Cisco IOS software include DHCP server and relay agent software. DHCP supports three mechanisms for IP address allocation: Automatic allocationDHCP assigns a permanent IP address to a client.
Dynamic allocationDHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). Manual allocationThe network administrator assigns an IP address to a client and DHCP is used simply to convey the assigned address to the client. The format of DHCP messages is based on the format of Bootstrap Protocol (BOOTP) messages, which ensures support for BOOTP relay agent functionality and interoperability between BOOTP clients and DHCP Servers. BOOTP relay agents eliminate the need for deploying a DHCP Server on each physical network segment. BOOTP is explained in RFC 951, Bootstrap Protocol (BOOTP), and RFC 1542, Clarifications and Extensions for the Bootstrap Protocol. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Supported Platforms" section in the "Using Cisco IOS Software" chapter in this book.
DHCP Server Overview

The Cisco IOS DHCP Server feature is a full DHCP Server implementation that assigns and manages IP addresses from specified address pools within the router to DHCP clients. If the Cisco IOS DHCP Server cannot satisfy a DHCP request from its own database, it can forward the request to one or more secondary DHCP Servers defined by the network administrator. Figure 14 shows the basic steps that occur when a DHCP client requests an IP address from a DHCP Server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS DHCP Server. A DHCP Server offers configuration parameters (such as an IP address, a MAC address, a domain name, and a lease for the IP address) to the client in a DHCPOFFER unicast message. Figure 14 DHCP Request for an IP Address from a DHCP Server
Note A DHCP client may receive offers from multiple DHCP Servers and can accept any one of the offers; however, the client usually accepts the first offer it receives. Additionally, the offer from the DHCP Server is not a guarantee that the IP address will be allocated to the client; however, the server usually reserves the address until the client has had a chance to formally request the address.
The client returns a formal request for the offered IP address to the DHCP Server in a DHCPREQUEST broadcast message. The DHCP Server confirms that the IP address has been allocated to the client by returning a DHCPACK unicast message to the client.
Note The formal request for the offered IP address (the DHCPREQUEST message) that is sent by the client is broadcast so that all other DHCP Servers that received the DHCPDISCOVER broadcast message from the client can reclaim the IP addresses that they offered to the client. If the configuration parameters sent to the client in the DHCPOFFER unicast message by the DHCP Server are invalid (a misconfiguration error exists), the client returns a DHCPDECLINE broadcast message to the DHCP Server. The DHCP Server will send to the client a DHCPNAK denial broadcast message, which means the offered configuration parameters have not been assigned, if an error has occurred during the negotiation of the parameters or the client has been slow in responding to the DHCPOFFER message (the DHCP Server assigned the parameters to another client) of the DHCP Server.
DHCP defines a process by which the DHCP Server knows the IP subnet in which the DHCP client resides, and it can assign an IP address from a pool of valid IP addresses in that subnet. The DHCP Server identifies which DHCP address pool to use to service a client request as follows: If the client is not directly connected (the giaddr field of the DHCPDISCOVER broadcast message is non-zero), the DHCP Server matches the DHCPDISCOVER with a DHCP pool that has the subnet that contains the IP address in the giaddr field. If the client is directly connected (the giaddr field is zero), the DHCP Server matches the DHCPDISCOVER with DHCP pool(s) that contain the subnet(s) configured on the receiving interface. If the interface has secondary IP addresses, the subnets associated with the secondary IP addresses are examined for possible allocation only after the subnet associated with the primary IP address (on the interface) is exhausted. The Cisco IOS DHCP Server feature offers the following benefits: Reduced Internet access costs
Using automatic IP address assignment at each remote site substantially reduces Internet access costs. Static IP addresses are considerably more expensive to purchase than are automatically allocated IP addresses. Reduced client configuration tasks and costs
Because DHCP is easy to configure, it minimizes operational overhead and costs associated with device configuration tasks and eases deployment by nontechnical users. Centralized management
Because the DHCP Server maintains configurations for several subnets, an administrator only needs to update a single, central server when configuration parameters change. Before you configure the Cisco IOS DHCP Server feature, complete the following tasks: Identify an external File Transport Protocol (FTP), Trivial File Transfer Protocol (TFTP), or remote copy protocol (rcp) server that you will use to store the DHCP bindings database. Identify the IP addresses that you will enable the DHCP Server to assign, and the IP addresses that you will exclude. Identify DHCP options for devices where necessary, including the following: Default boot image name Default routers Domain Name System (DNS) servers NetBIOS name server Decide on a NetBIOS node type (b, p, m, or h). Decide on a DNS domain name.
DHCP Client Overview

The Cisco IOS DHCP client now enables you to obtain an IP address from a DHCP Server dynamically using the DHCP protocol as specified in RFC 2131. In Cisco IOS Release 12.2, only Ethernet interfaces are supported; work is in progress to support all interface types. The Cisco IOS DHCP client offers the following benefits: Reduces time to configure and deploy Reduces the number of configuration errors Enables customers to centrally control the IP address assigned to a Cisco IOS router
DHCP Relay Agent Overview
A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used to forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP datagrams are switched between networks somewhat transparently. Relay agents receive DHCP messages and then generate a new DHCP message to send out on another interface. The Cisco IOS DHCP relay agent supports the use of unnumbered interfaces. The DHCP relay agent automatically adds a static host route specifying the unnumbered interface as the outbound interface.
DHCP Configuration Task List

The DHCP Server database is organized as a tree. The root of the tree is the address pool for natural networks, branches are subnetwork address pools, and leaves are manual bindings to clients. Subnetworks inherit network parameters and clients inherit subnetwork parameters. Therefore, common parameters, for example the domain name, should be configured at the highest (network or subnetwork) level of the tree.
Note Inherited parameters can be overridden. For example, if a parameter is defined in both the natural network and a subnetwork, the definition of the subnetwork is used. Address leases are not inherited. If a lease is not specified for an IP address, by default, the DHCP Server assigns a one-day lease for the address.
To configure the Cisco IOS DHCP Server feature, perform the tasks described in the following sections. First configure a database agent or disable conflict logging, then specify IP addresses that the DHCP Server should not assign (excluded addresses) and should assign (a pool of available IP addresses) to requesting clients. The tasks in the first three sections are required. The tasks in the remaining sections are optional. Enabling the Cisco IOS DHCP Server and Relay Agent Features (Optional)
Configuring a DHCP Database Agent or Disabling DHCP Conflict Logging (Required) Excluding IP Addresses (Required) Configuring a DHCP Address Pool (Required) Configuring Manual Bindings (Optional) Configuring a DHCP Server Boot File (Optional) Configuring the Number of Ping Packets (Optional)
Configuring the Timeout Value for Ping Packets (Optional) Enabling the Cisco IOS DHCP Client on Ethernet Interfaces (Optional) Configuring DHCP Server Options Import and Autoconfiguration (Optional)
Configuring the Relay Agent Information Option in BOOTREPLY Messages (Optional) Configuring a Relay Agent Information Reforwarding Policy (Optional) Enabling the DHCP Smart-Relay Feature (Optional)
Enabling the Cisco IOS DHCP Server and Relay Agent Features
By default, the Cisco IOS DHCP server and relay agent features are enabled on your router. To reenable these features if they are disabled, use the following command in global configuration mode: Command Router(config)# service dhcp Purpose Enables the Cisco IOS DHCP server and relay features on your router. Use the no form of this command to disable the Cisco IOS DHCP server and relay features.
Configuring a DHCP Database Agent or Disabling DHCP Conflict Logging

A DHCP database agent is any hostfor example, an FTP, TFTP, or rcp serverthat stores the DHCP bindings database. You can configure multiple DHCP database agents and you can configure the interval between database updates and transfers for each agent. To configure a database agent and database agent parameters, use the following command in global configuration mode: Command Router(config)# ip dhcp database url [timeout seconds | write-delay seconds] Purpose Configures the database agent and the interval between database updates and database transfers.
If you choose not to configure a DHCP database agent, disable the recording of DHCP address conflicts on the DHCP Server. To disable DHCP address conflict logging, use the following command in global configuration mode:
Command
Purpose
Router(config)# no ip dhcp conflict Disables DHCP address conflict logging logging.
Excluding IP Addresses
The DHCP Server assumes that all IP addresses in a DHCP address pool subnet are available for assigning to DHCP clients. You must specify the IP address that the DHCP Server should not assign to clients. To do so, use the following command in global configuration mode: Command Router(config)# ip dhcp excluded-address low-address [high-address] Purpose Specifies the IP addresses that the DHCP Server should not assign to DHCP clients.
Configuring a DHCP Address Pool

You can configure a DHCP address pool with a name that is a symbolic string (such as "engineering") or an integer (such as 0). Configuring a DHCP address pool also places you in DHCP pool configuration modeidentified by the (dhcp-config)# prompt from which you can configure pool parameters (for example, the IP subnet number and default router list). To configure a DHCP address pool, complete the required tasks in the following sections.
Configuring the DHCP Address Pool Name and Entering DHCP Pool Configuration Mode
To configure the DHCP address pool name and enter DHCP pool configuration mode, use the following command in global configuration mode: Command Router(config)# ip dhcp pool name Purpose Creates a name for the DHCP Server address pool and places you in DHCP pool configuration mode (identified by the dhcpconfig# prompt).
Configuring the DHCP Address Pool Subnet and Mask
To configure a subnet and mask for the newly created DHCP address pool, which contains the range of available IP addresses that the DHCP Server may assign to clients, use the following command in DHCP pool configuration mode: Command Purpose Specifies the subnet network number and mask of the DHCP address pool.
Router(dhcp-config)# network networknumber [mask | /prefix- The prefix length specifies the number of bits length] that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/).
Note You can not configure manual bindings within the same pool that is configured with the network command. To configure manual bindings, see the "Configuring Manual Bindings" section.
Configuring the Domain Name for the Client

The domain name for a DHCP client places the client in the general grouping of networks that make up the domain. To configure a domain name string for the client, use the following command in DHCP pool configuration mode: Command Purpose
Router(dhcp-config)# domain-name Specifies the domain name for domain the client.
Configuring the IP Domain Name System Servers for the Client

DHCP clients query DNS IP servers when they need to correlate host names to IP addresses. To configure the DNS IP servers that are available to a DHCP client, use the following command in DHCP pool configuration mode: Command Router(dhcp-config)# dns-server address [address2 ... address8] Purpose Specifies the IP address of a DNS server that is available to a DHCP client. One IP address is required; however, you can specify up to eight IP addresses in one command line.
Configuring the NetBIOS Windows Internet Naming Service Servers for the Client
Windows Internet Naming Service (WINS) is a name resolution service that Microsoft DHCP clients use to correlate host names to IP addresses within a general grouping of networks. To configure the NetBIOS WINS servers that are available to a Microsoft DHCP client, use the following command in DHCP pool configuration mode: Command Router(dhcp-config)# netbios-name-server address [address2 ... address8] Purpose Specifies the NetBIOS WINS server that is available to a Microsoft DHCP client. One address is required; however, you can specify up to eight addresses in one command line.
Configuring the NetBIOS Node Type for the Client

The NetBIOS node type for Microsoft DHCP clients can be one of four settings: broadcast, peer-to-peer, mixed, or hybrid. To configure the NetBIOS node type for a Microsoft DHCP, use the following command in DHCP pool configuration mode: Command Purpose
Router(dhcp-config)# netbios- Specifies the NetBIOS node type for a node-type type Microsoft DHCP client.
Configuring the Default Router for the Client

After a DHCP client has booted, the client begins sending packets to its default router. The IP address of the default router should be on the same subnet as the client. To specify a default router for a DHCP client, use the following command in DHCP pool configuration mode: Command Router(dhcp-config)# default-router address [address2 ... address8] Purpose Specifies the IP address of the default router for a DHCP client. One IP address is required; however, you can specify up to eight addresses in one command line.
Configuring the Address Lease Time
By default, each IP address assigned by a DHCP Server comes with a one-day lease, which is the amount of time that the address is valid. To change the lease value for an IP address, use the following command in DHCP pool configuration mode: Command Router(dhcp-config)# lease {days [hours][minutes] | infinite} Purpose Specifies the duration of the lease. The default is a one-day lease. Use the show ip dhcp binding to display the lease expiration time and date of the IP address of the host.
Configuring Manual Bindings

An address binding is a mapping between the IP address and MAC address of a client. The IP address of a client can be assigned manually by an administrator or assigned automatically from a pool by a DHCP server. Manual bindings are IP addresses that have been manually mapped to the MAC addresses of hosts that are found in the DHCP database. Manual bindings are stored in NVRAM on the DHCP server. Manual bindings are just special address pools. There is no limit on the number of manual bindings, but you can only configure one manual binding per host pool. Automatic bindings are IP addresses that have been automatically mapped to the MAC addresses of hosts that are found in the DHCP database. Automatic bindings are stored on a remote host called a database agent. The bindings are saved as text records for easy maintenance. All DHCP clients send a client identifier (DHCP option 61) in the DHCP packet. To configure manual bindings, you must enter the client-identifier DHCP pool configuration command with the appropriate hexadecimal values identifying the DHCP client. To configure a manual binding, first create a host pool, then specify the IP address of the client and client identifier or hardware address. To configure manual bindings, use the following commands beginning in global configuration mode: Command Step 1 Router(config)# ip dhcp pool name Purpose Creates a name for the a DHCP Server address pool and places you in DHCP pool configuration modeidentified by the (dhcp-config)# prompt.
Step 2 Router(dhcpconfig)# host address [mask | /prefix-length]
Specifies the IP address and subnet mask of the client. The prefix length specifies the number of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/). Specifies the unique identifier for DHCP clients. This command is used for DHCP requests. DHCP clients require client identifiers. The unique identification of the client is specified in dotted hexadecimal notation, for example, 01b7.0813.8811.66, where 01 represents the Ethernet media type. See "Troubleshooting Tips" below for information on how to determine the client identifier of the DHCP client.
Router(dhcpStep 3 config)# clientidentifier uniqueidentifier
Router(dhcp(Optional) Specifies a hardware address Step 4 config)# hardware- for the client. This command is used for address hardware- BOOTP requests. address type The type value: Indicates the protocol of the hardware platform. Strings and values are acceptable. The string options are: ethernet ieee802 The value options are: 1 10Mb Ethernet 6 IEEE 802
If no type is specified, the default protocol is Ethernet. Step 5 Router(dhcpconfig)# client(Optional) Specifies the name of the client using any standard ASCII
name name
character. The client name should not include the domain name. For example, the name mars should not be specified as mars.cisco.com.
Troubleshooting Tips
You can determine the client identifier by using the debug ip dhcp server packet command. In the following example, the client is identified by the value 0b07.1134.a029.
Router# debug ip dhcp server packet DHCPD:DHCPDISCOVER received from client 0b07.1134.a029 through relay 10.1.0.253. DHCPD:assigned IP address 10.1.0.3 to client 0b07.1134.a029. . . .
Configuring a DHCP Server Boot File

The boot file is used to store the boot image for the client. The boot image is generally the operating system the client uses to load. To specify a boot file for the DHCP client, use the following command in DHCP pool configuration mode: Command Router(dhcp-config)# bootfile filename Purpose Specifies the name of the file that is used as a boot image.
Configuring the Number of Ping Packets

By default, the DHCP Server pings a pool address twice before assigning a particular address to a requesting client. If the ping is unanswered, the DHCP Server assumes (with a high probability) that the address is not in use and assigns the address to the requesting client. To change the number of ping packets the DHCP Server should send to the pool address before assigning the address, use the following command in global configuration mode: Command Router(config)# ip dhcp ping packets number Purpose Specifies the number of ping packets the DHCP Server sends to a pool address before assigning the address to a requesting client. The default is two packets. Setting the count argument to a value of 0 turns off DHCP Server ping operation
completely.
Configuring the Timeout Value for Ping Packets

By default, the DHCP Server waits 500 milliseconds before timing out a ping packet. To change the amount of time the server waits, use the following command in global configuration mode: Command Purpose
Router(config)# ip dhcp Specifies the amount of time the DHCP ping timeout Server must wait before timing out a ping milliseconds packet. The default is 500 milliseconds.
Enabling the Cisco IOS DHCP Client on Ethernet Interfaces

To acquire an IP address via DHCP on an Ethernet interface, use the following command in interface configuration mode: Command Purpose
Router(config-if)# ip address dhcp Specifies that the Ethernet [client-id interface name] [hostname interface acquires an IP host-name] address through DHCP.
Configuring DHCP Server Options Import and Autoconfiguration

The Cisco IOS DHCP server can dynamically configure options such as the DNS and WINS addresses to respond to DHCP requests from local clients behind the customer premises equipment (CPE). Previously, network administrators needed to manually configure the Cisco IOS DHCP server on each device enabled with this feature. The Cisco IOS DHCP server was enhanced to allow configuration information to be updated automatically. Network administrators can configure one or more centralized DHCP servers to update specific DHCP options within the DHCP pools. The remote servers can request or "import" these option parameters from the centralized servers. See the section "DHCP Server Options Import and Autoconfiguration Example" later in this chapter for a configuration example. To configure the central router to update specific DHCP options within the DHCP pools, use the following commands beginning in global configuration mode:
Command Step 1 Router(config)# ip dhcp pool name
Purpose Creates a name for the a DHCP Server address pool and places you in DHCP pool configuration modeidentified by the (dhcp-config)# prompt.
Specifies the subnet network number Step 2 Router(dhcp-config)# and mask of the DHCP address pool. network networknumber [mask | The prefix length specifies the number /prefix-length] of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/). Step 3 Router(dhcp-config)# Specifies the IP address of a DNS dns-server address server that is available to a DHCP [address2 ... address8] client. One IP address is required; however, you can specify up to eight IP addresses in one command line. To configure the remote router to import DHCP options into the DHCP server database, use the following commands beginning in global configuration mode: Command Purpose
Step 1 Router(config)# ip dhcp pool Creates a name for the a name DHCP Server address pool and places you in DHCP pool configuration mode identified by the (dhcpconfig)# prompt. Specifies the subnet network Step 2 Router(dhcp-config)# network number and mask of the DHCP address pool. network-number [mask | /prefix-length] The prefix length specifies the number of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/).
Step 3 Router(dhcp-config)# import all
Import DHCP option parameters into the DHCP server database. Exits DHCP pool configuration mode.
Step 4 Router(dhcp-config)# exit
Step 5 Router(config)# interface type Configures an interface and number enters interface configuration mode. Step 6 Router(config-if)# ip address Specifies that the interface dhcp [client-id interface acquires an IP address name] [hostname host-name] through DHCP.
Configuring the Relay Agent Information Option in BOOTREPLY Messages

To configure the DHCP Server to validate the relay agent information option in forwarded BOOTREPLY messages, use the following command in global configuration mode: Command Purpose
Router(config)# ip dhcp Configures the DHCP Server to check that relay information check the relay agent information option in forwarded BOOTREPLY messages is valid.
Configuring a Relay Agent Information Reforwarding Policy

To configure a relay agent information reforwarding policy on the DHCP Server (what the DHCP Server should do if a forwarded message already contains relay information), use the following command in global configuration mode: Command Purpose
Router(config)# ip dhcp relay Determines the relay information information policy {drop | keep reforwarding policy in a cable |replace} modem termination system.
Enabling the DHCP Smart-Relay Feature
By default, the DHCP smart-relay feature is disabled. To enable the smart-relay functionality, use the following command in global configuration mode: Command Router(config)# ip dhcp smart-relay Purpose Allows the DHCP relay agent to switch the gateway address (giaddr field of a DHCP packet) to secondary addresses when there is no DHCPOFFER message from a DHCP Server.
Monitoring and Maintaining the DHCP Server

To clear DHCP Server variables, use the following commands in privileged EXEC mode, as needed: Command Router# clear ip dhcp binding {address | *} Purpose Deletes an automatic address binding from the DHCP database. Specifying the address argument clears the automatic binding for a specific (client) IP address, whereas specifying an asterisk (*) clears all automatic bindings. Clears an address conflict from the DHCP database. Specifying the address argument clears the conflict for a specific IP address, whereas specifying an asterisk (*) clears conflicts for all addresses. Resets all DHCP Server counters to 0.
Router# clear ip dhcp conflict {address | *}
Router# clear ip dhcp server statistics Router# clear ip route [vrf vrfname] dhcp [ipaddress]
Removes routes from the routing table added by the Cisco IOS DHCP Server and Relay Agent for the DHCP clients on unnumbered interfaces.
To enable DHCP Server debugging, use the following command in privileged EXEC mode: Command Purpose
Router# debug ip dhcp server {events | Enables debugging on the packets | linkage} DHCP Server.
To display DHCP Server information, use the following commands in EXEC mode, as needed: Command Router# show ip dhcp binding [address] Purpose Displays a list of all bindings created on a specific DHCP Server. Use the show ip dhcp binding to display the lease expiration time and date of the IP address of the host and the number. You can also use this command to display the IP addresses that have already been assigned. Displays a list of all address conflicts recorded by a specific DHCP Server. Displays recent activity on the DHCP database. Router# show ip dhcp database [url] Router# show ip dhcp server statistics Router# show ip dhcp import Note Use this command in privileged EXEC mode. Displays count information about server statistics and messages sent and received.
Router# show ip dhcp conflict [address]
Displays the option parameters that were imported into the DHCP Server database. Imported option parameters are not part of the router configuration and are not saved in NVRAM. Displays the routes added to the routing table by the Cisco IOS DHCP Server and Relay Agent.
Router# show ip route [vrf vrfname] dhcp [ipaddress]
Configuration Examples
This section provides the following configuration examples:
DHCP Database Agent Configuration Example DHCP Address Pool Configuration Example Manual Bindings Configuration Example Cisco IOS DHCP Client Example DHCP Server Options Import and Autoconfiguration Example
DHCP Database Agent Configuration Example

The following example stores bindings on host 172.16.4.253. The file transfer protocol is FTP. The server should wait 2 minutes (120 seconds) before writing database changes.
ip dhcp database ftp://user:password@172.16.4.253/router-dhcp writedelay 120
DHCP Address Pool Configuration Example

In the following example, three DHCP address pools are created: one in network 172.16.0.0, one in subnetwork 172.16.1.0, and one in subnetwork 172.16.2.0. Attributes from network 172.16.0.0such as the domain name, DNS server, NetBIOS name server, and NetBIOS node typeare inherited in subnetworks 172.16.1.0 and 172.16.2.0. In each pool, clients are granted 30-day leases and all addresses in each subnetwork, except the excluded addresses, are available to the DHCP Server for assigning to clients. Table 5 lists the IP addresses for the devices in three DHCP address pools.
Table 5 DHCP Address Pool Configuration Example Pool 0 (Network 172.16.0.0) Device Default routers DNS Server Pool 1 (Subnetwork Pool 2 (Subnetwork 172.16.1.0) 172.16.2.0) 172.16.1.100 172.16.1.102 172.16.2.102 172.16.1.103 NetBIOS name 172.16.2.103 server 172.16.2.100
IP Address Device IP Address Device IP Address Default Default routers 172.16.1.101 routers 172.16.2.101
NetBIOS h-node node type
ip dhcp database ftp://user:password@172.16.4.253/router-dhcp writedelay 120 ip dhcp excluded-address 172.16.1.100 172.16.1.103 ip dhcp excluded-address 172.16.2.100 172.16.2.103 ! ip dhcp pool 0 network 172.16.0.0 /16 domain-name cisco.com dns-server 172.16.1.102 172.16.2.102 netbios-name-server 172.16.1.103 172.16.2.103 netbios-node-type h-node ! ip dhcp pool 1 network 172.16.1.0 /24 default-router 172.16.1.100 172.16.1.101 lease 30 ! ip dhcp pool 2 network 172.16.2.0 /24 default-router 172.16.2.100 172.16.2.101 lease 30
Manual Bindings Configuration Example

The following example creates a manual binding for a client named Mars.cisco.com. The MAC address of the client is 02c7.f800.0422 and the IP address of the client is 172.16.2.254.
ip dhcp pool Mars host 172.16.2.254 hardware-address 02c7.f800.0422 ieee802 client-name Mars
Because attributes are inherited, the previous configuration is equivalent to the following:
ip dhcp pool Mars host 172.16.2.254 mask 255.255.255.0 hardware-address 02c7.f800.0422 ieee802 client-name Mars default-router 172.16.2.100 172.16.2.101 domain-name cisco.com dns-server 172.16.1.102 172.16.2.102 netbios-name-server 172.16.1.103 172.16.2.103 netbios-node-type h-node
Cisco IOS DHCP Client Example

Figure 15 shows a simple network diagram of a DHCP client on an Ethernet LAN.
Figure 15 Topology Showing DHCP Client with Ethernet Interface
On the DHCP Server, the configuration is as follows:

ip dhcp pool 1 network 10.1.1.0 255.255.255.0 lease 1 6
On the DHCP client, the configuration is as follows on interface E2:

interface Ethernet2 ip address dhcp
This configuration allows the DHCP client to aquire an IP address from the DHCP Server through an Ethernet interface.
DHCP Server Options Import and Autoconfiguration Example

The following example shows a remote and central server configured to support DHCP options import and autoconfiguration. The central server is configured to automatically update DHCP options, such as DNS and WINs addresses, within the DHCP pools. In response to a DHCP request from a local client behind CPE equipment, the remote server can request or "import" these option parameters from the centralized server. See Figure 16 for a diagram of the network topology. Figure 16 DHCP Example Network Topology
Central Router
!do not assign this range to DHCP clients ip dhcp-excluded address 10.0.0.1 10.0.0.5
! ip dhcp pool central ! Specifies network number and mask for DHCP clients network 10.0.0.0 255.255.255.0 ! Specifes the domain name for the client domain-name central ! Specifies DNS server that will respond to DHCP clients when they need to correlate host ! name to ip address dns-server 10.0.0.2 !Specifies the NETBIOS WINS server netbios-name-server 10.0.0.2 ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 duplex auto speed auto
Remote Router
! ip dhcp pool client ! Imports DHCP options parameters into DHCP server database import all network 20.0.0.0 255.255.255.0 ! interface FastEthernet0/0 ip address dhcp duplex auto speed auto

RIP Commands 2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RIP Commands 2

Uploaded by

Copyright:

Available Formats

RIP Commands

Default metric value.

Description Changes interpacket delay for RIP updates sent.

ip rip authentication key-chain

ip rip authentication mode

Clears text authentication. Keyed MD5 authentication.

ip rip receive version

ip rip send version

neighbor ip-address no neighbor ip-address

IP address of a peer router with which routing information will be exchanged.

passive-interface Disables sending routing updates on an interface.

IP address of the network of directly connected networks.

timers basic update invalid holddown flush no timers basic

Specifies RIP Version 1. Specifies RIP Version 2.

Command ip rip receive version ip rip send version show ip protocols

Cisco's OSPF Implementation

Stub areasDefinition of stub areas is supported.

OSPF Configuration Task List

network address wildcard-mask area area-id

Configure OSPF Interface Parameters

ip ospf retransmitinterval seconds

ip ospf dead-interval seconds

Specifies the authentication type for an

Configure OSPF over Different Physical Networks

Configure Your OSPF Network Type

It costs less because it does not require a fully meshed topology.

Configure Point-to-Multipoint, Broadcast Networks

router ospf process-id neighbor ipaddress cost number

Configure OSPF for Nonbroadcast Networks

neighbor ip-address [cost number]

Configure OSPF Area Parameters

Configure OSPF Not So Stubby Area (NSSA)

Configure Route Summarization between OSPF Areas

Configure Route Summarization when Redistributing Routes into OSPF

Create Virtual Links

Generate a Default Route

Configure Lookup of DNS Names

Force the Router ID Choice with a Loopback Interface

Control Default Metrics

Change the OSPF Administrative Distances

Configure OSPF on Simplex Ethernet Interfaces

Configure Route Calculation Timers

timers spf spf-delay spf-holdtime Configure route calculation timers.

Configure OSPF over On Demand Circuits

Log Neighbors Going Up or Down

Change the LSA Group Pacing

Original LSA Behavior

timers lsa-group-pacing seconds Change the group pacing of LSAs.

Block OSPF LSA Flooding

Ignore MOSPF LSA Packets

Monitor and Maintain OSPF

Display OSPF-related virtual links information.

OSPF Configuration Examples

OSPF Point-to-Multipoint Example

router ospf 1 network 10.0.0.0 0.0.0.255 area 0

OSPF Point-to-Multipoint, Broadcast Example

The following example shows the configuration of the neighbor at 10.0.1.3:

OSPF Point-to-Multipoint, Nonbroadcast Example

neighbor 10.0.1.5 cost 15

Variable-Length Subnet Masks Example

OSPF Routing and Route Redistribution Examples

Basic OSPF Configuration Example

Complex Internal Router, ABR, and ASBRs Example