Routing Protocol Configuration

Table Of Contents

Routing Protocol Configuration

Routing Information Protocol

RIP Configuration Task List

Enhanced Interior Gateway Routing Protocol

Enabling EIGRP

Logging EIGRP Neighbor Adjacency Changes

Configuring the Percentage of Link Bandwidth Used

Adjusting the EIGRP Metric Weights

Applying Offsets to Routing Metrics

Disabling Route Summarization

Configuring Summary Aggregate Addresses

Configuring EIGRP Protocol-Independent Parameters

Configuring EIGRP Stub Routing

Monitoring and Maintaining EIGRP

EIGRP Stub Routing

Open Shortest Path First

Enabling OSPF

Configuring OSPF Interface Parameters

Configuring OSPF over Different Physical Networks

Configuring OSPF Area Parameters

Configuring OSPF NSSA

Configuring Route Summarization Between OSPF Areas

Configuring Route Summarization When Redistributing Routes into OSPF

Creating Virtual Links

Generating a Default Route

Configuring Lookup of DNS Names

Forcing the Router ID Choice with a Loopback Interface

Controlling Default Metrics

Changing the OSPF Administrative Distances

Configuring OSPF on Simplex Ethernet Interfaces

Configuring Route Calculation Timers

Logging Neighbors Going Up or Down

Changing the LSA Group Pacing

Blocking OSPF LSA Flooding

Reducing LSA Flooding

Ignoring MOSPF LSA Packets

Displaying OSPF Update Packet Pacing

Monitoring and Maintaining OSPF

OSPF Configuration Examples

Routing Protocol Configuration


This chapter describes routing protocols as they apply to the mobile router. This chapter describes:

Routing Information Protocol

Enhanced Interior Gateway Routing Protocol

Open Shortest Path First

Routing Information Protocol

This section describes how to configure Routing Information Protocol (RIP). For a complete description of the RIP commands that appear in this section, refer to the "RIP Commands" chapter of the Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols. To locate documentation of other commands that appear in this section, use the command reference master index, or search online.

RIP is a commonly used interior gateway protocol created for use in small, homogeneous networks. It is a classical distance-vector routing protocol. RIP is documented in RFC 1058.

RIP uses broadcast User Datagram Protocol (UDP) data packets to exchange routing information. Cisco IOS software sends routing information updates every 30 seconds, which is termed advertising. If a router does not receive an update from another router for 180 seconds or more, it marks the routes served by the nonupdating router as being unusable. If there is still no update after 240 seconds, the router removes all routing table entries for the nonupdating router.

The metric that RIP uses to rate the value of different routes is hop count. The hop count is the number of routers that can be traversed in a route. A directly connected network has a metric of zero; an unreachable network has a metric of 16. This small range of metrics makes RIP an unsuitable routing protocol for large networks.

A router that is running RIP can receive a default network via an update from another router that is running RIP, or the router can source (generate) the default network itself with RIP. In both cases, the default network is advertised through RIP to other RIP neighbors.

Cisco IOS software will source the default network with RIP if one of the following conditions is met:

The ip default-network command is configured.

The default-information originate command is configured.

The default route is learned through another routing protocol or static route and redistributed into RIP.

RIP sends updates to the interfaces in the specified networks. If the network of an interface network is not specified, it will not be advertised in any RIP update.

The Cisco implementation of RIP Version 2 supports plain text and Message Digest 5 (MD5) authentication, route summarization, classless interdomain routing (CIDR), and variable-length subnet masks (VLSMs).

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.

RIP Configuration Task List

To configure RIP, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Enabling RIP (Required)

Allowing Unicast Updates for RIP (Required)

Applying Offsets to Routing Metrics (Optional)

Adjusting Timers (Optional)

Specifying a RIP Version (Optional)

Enabling RIP Authentication (Optional)

Configuring Route Summarization on an Interface (Optional)

Verifying IP Route Summarization (Optional)

Disabling Automatic Route Summarization (Optional)

Disabling the Validation of Source IP Addresses (Optional)

Enabling or Disabling Split Horizon (Optional)

Configuring Interpacket Delay (Optional)

Connecting RIP to a WAN (Optional)

Enabling RIP

To enable RIP, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1

Router(config)# router rip

Enable a RIP routing process, which places you in router configuration mode.

Step 2

Router(config-router)# network ip-address

Associate a network with a RIP routing process.

Allowing Unicast Updates for RIP

Because RIP is normally a broadcast protocol, in order for RIP routing updates to reach nonbroadcast networks, you must configure the Cisco IOS software to permit this exchange of routing information. To do so, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# neighbor ip-address

Defines a neighboring router with which to exchange routing information.


To control the set of interfaces with which you want to exchange routing updates, you can disable the sending of routing updates on specified interfaces by configuring the passive-interface router configuration command.

Applying Offsets to Routing Metrics

An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned by using RIP. Optionally, you can limit the offset list with either an access list or an interface. To increase the value of routing metrics, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# offset-list [access-list-number | access-list-name] {in | out} offset [interface-type interface-number]

Apply an offset to the routing metrics.


Adjusting Timers

Routing protocols use several timers that determine such variables as the frequency of routing updates, the length of time before a route becomes invalid, and other parameters. You can adjust these timers to tune routing protocol performance to better suit your internetwork needs. You can make the following timer adjustments:

The rate (time in seconds between updates) at which routing updates are sent

The interval of time (in seconds) after which a route is declared invalid

The interval (in seconds) during which routing information regarding better paths is suppressed

The amount of time (in seconds) that must pass before a route is removed from the routing table

The amount of time for which routing updates will be postponed

It also is possible to tune the IP routing support in the software to enable faster convergence of the various IP routing algorithms, and, hence, quicker fallback to redundant routers. The total effect is to minimize disruptions to end users of the network in situations where quick recovery is essential.

To adjust the timers, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# timers basic update invalid holddown flush [sleeptime]

Adjusts routing protocol timers.


Specifying a RIP Version

The Cisco implementation of RIP Version 2 supports authentication, key management, route summarization, CIDR, and VLSMs.

By default, the software receives RIP Version 1 and Version 2 packets, but sends only Version 1 packets. You can configure the software to receive and send only Version 1 packets. Alternatively, you can configure the software to receive and send only Version 2 packets. To configure the software to send and receive packets from only one version, use the following command in router configuration mode:

Command
Task

Router(config-router)# version {1 | 2}

Configure the software to receive and send only RIP Version 1 or only RIP Version 2 packets.


The preceding task controls the default behavior of RIP. You can override that behavior by configuring a particular interface to behave differently. To control which RIP version an interface sends, use the following commands in interface configuration mode, as needed:

:

Command
Purpose

Router(config-if)# ip rip send version 1

Configure an interface to send only RIP Version 1 packets.

Router(config-if)# ip rip send version 2

Configure an interface to send only RIP Version 2 packets.

Router(config-if)# ip rip send version 1 2

Configure an interface to send RIP Version 1 and Version 2 packets.


Similarly, to control how packets received from an interface are processed, use the following commands in interface configuration mode, as needed:

Command
Purpose

Router(config-if)# ip rip receive version 1

Configure an interface to accept only RIP Version 1 packets.

Router(config-if)# ip rip receive version 2

Configure an interface to accept only RIP Version 2 packets.

Router(config-if)# ip rip receive version 1 2

Configure an interface to accept either RIP Version 1 or 2 packets.


Enabling RIP Authentication

RIP Version 1 does not support authentication. If you are sending and receiving RIP Version 2 packets, you can enable RIP authentication on an interface.

The key chain determines the set of keys that can be used on the interface. If a key chain is not configured, no authentication is performed on that interface, not even the default authentication.

We support two modes of authentication on an interface for which RIP authentication is enabled: plain text authentication and MD5 authentication. The default authentication in every RIP Version 2 packet is plain text authentication.


Note Do not use plain text authentication in RIP packets for security purposes, because the unencrypted authentication key is sent in every RIP Version 2 packet. Use plain text authentication when security is not an issue, for example, to ensure that misconfigured hosts do not participate in routing.


To configure RIP authentication, use the following commands in interface configuration mode:

 
Command
Purpose

Step 1

Router(config-if)# ip rip authentication key-chain name-of-chain

Enable RIP authentication.

Step 2

Router(config-if)# ip rip authentication mode {text | md5}

Configure the interface to use MD5 digest authentication (or let it default to plain text authentication).

RIP Route Summarization

Summarizing routes in RIP Version 2 improves scalability and efficiency in large networks. Summarizing IP addresses means that there is no entry for child routes (routes that are created for any combination of the individual IP addresses contained within a summary address) in the RIP routing table, reducing the size of the table and allowing the router to handle more routes.

Summary IP address functions more efficiently than multiple individually advertised IP routes for the following reasons:

The summarized routes in the RIP database are processed first.

Any associated child routes that are included in a summarized route are skipped as RIP looks through the routing database, reducing the processing time required.

Cisco routers can summarize routes in two ways:

Automatically, by summarizing subprefixes to the classful network boundary when crossing classful network boundaries (automatic summary).


Note You need not configure anything for automatic summary to be enabled. To disable automatic summary, use the Router (config-router)# no auto-summary router configuration command.


As specifically configured, advertising a summarized local IP address pool on the specified interface (on a network access server) so that the address pool can be provided to dialup clients.

Automatic summary addressing always summarizes to the classful address boundary, while the ip summary-address router configuration command summarizes addresses on a specified interface. If automatic summary addressing is enabled, automatic summarization is the default behavior for interfaces on the router not associated with dial-in clients (the "backbone"), with or without the ip summary-address rip interface command present.

For example, if a local IP address pool of 10.1.1.1 to 10.1.1.254 is configured on the network access server, you could configure the ip summary-address rip 10.1.1.0 255.255.255.0 command on the network access server port that provides addresses to dialup clients to cause the router to advertise 10.1.1.0/24 routes to dialup clients. Because a summary route is advertised, advertisement of the /32 host routes (installed when the dialup client connects) is suppressed so that the router does not advertise these routes to the network access server interface.

Automatic summary will override the configured summary address feature on a given interface except when both of the following conditions are true:

The configured interface summary address and the IP address of the configured interface share the same major network (the classful, nonsubnetted portion of the IP address).

Split horizon is not enabled on the interface.


Note If split horizon is enabled, neither an automatic summary address nor the interface summary address is advertised.


In the following example configuration, the major network is 10.0.0.0. The 10 in the address defines a Class A address space, allowing space for 0.x.x.x unique hosts where x defines unique bit positions in the addresses for these hosts. The summary of the major net defines the prefix as implied by the class (A, B, or C) of the address, without any network mask. The summary address 10.2.0.0 overrides the automatic summary address of 10.0.0.0, 10.2.0.0 is advertised out interface E1, and 10.0.0.0 is not advertised.

interface Ethernet1
ip address 10.1.1.1 255.255.255.0
ip summary-address rip 10.2.0.0 255.255.0.0
no ip split-horizon

router rip
network 10.0.0.0

When RIP determines that a summary address is required in the RIP database, a summary entry is created in the RIP routing database. As long as there are child routes for a summary address, the address remains in the routing database. When the last child route is removed, the summary entry also is removed from the database. This method of handling database entries reduces the number of entries in the database because each child route is not listed in an entry, and the aggregate entry itself is removed when there are no longer any valid child routes for it.

RIP Version 2 route summarization requires that the lowest metric of the "best route" of an aggregated entry, or the lowest metric of all current child routes, be advertised. The best metric for aggregated summarized routes is calculated at route initialization or when there are metric modifications of specific routes at advertisement time, and not at the time the aggregated routes are advertised.

Restrictions to RIP Route Summarization

Supernet advertisement (advertising any network prefix less than its classful major network) is not allowed in RIP route summarization, other than advertising a supernet learned in the routing tables. Supernets learned on any interface that is subject to configuration are still learned. For example, the following summarization is invalid:

interface E1
.
ip summary-address rip 10.0.0.0 252.0.0.0 (invalid supernet summarization)

Each route summarization on an interface must have a unique major net, even if the subnet mask is unique. For example, the following is not permitted:

interface Ethernet1
.
.
ip summary-address rip 10.1.0.0 255.255.0.0
ip summary-address rip 10.2.0.0 255.255.0.0 (or different mask)

Configuring Route Summarization on an Interface

The ip summary-address rip router configuration command causes the router to summarize a given set of routes learned via RIP Version 2 or redistributed into RIP Version 2. Host routes are especially applicable for summarization. To configure IP summary addressing, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1

Router(config)# rip

Enable RIP routing.

Step 2

Router(config)# interface FastEthernet0/0

Enter interface configuration mode for the 10/100 Fast Ethernet port.

Step 3

Router(config-if)# ip summary-address rip ip_address ip_network_mask

Specify the IP address and network mask that identifies the routes to be summarized.

See the " Route Summarization Examples" section for examples of using split horizon.

Verifying IP Route Summarization

You can verify which routes are summarized for an interface using the show ip protocols EXEC command. The following example shows potential summarizations and the associated interface summary address and network mask for 10/100 Fast Ethernet interface:

router# show ip protocols
 Routing Protocol is "rip"
   Sending updates every 30 seconds, next due in 8 seconds
   Invalid after 180 seconds, hold down 180, flushed after 240
   Outgoing update filter list for all interfaces is 
   Incoming update filter list for all interfaces is 
   Redistributing: rip
   Default version control: send version 2, receive version 2
     Interface               Send  Recv  Triggered RIP  Key-chain
     FastEthernet2        2      2
   Automatic network summarization is not in effect
   Address Summarization:
     10.11.0.0/16 for FastEthernet2

You can check summary address entries in the RIP database. These entries will appear in the database only if relevant child routes are being summarized. When the last child route for a summary address becomes invalid, the summary address is also removed from the routing table. The following example shows a summary address entry for route 10.11.0.0/16, with three child routes active:

router# show ip rip database
 10.0.0.0/8    auto-summary
 10.11.11.0/24    directly connected, FastEthernet
 10.1.0.0/8    auto-summary
 10.11.0.0/16    int-summary
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 10.11.10.0/24    directly connected, Ethernet3

Disabling Automatic Route Summarization

RIP Version 2 supports automatic route summarization by default. The software summarizes subprefixes to the classful network boundary when crossing classful network boundaries.

If you have disconnected subnets, disable automatic route summarization to advertise the subnets. When route summarization is disabled, the software sends subnet and host routing information across classful network boundaries.

To disable automatic summarization, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# no auto-summary

Disables automatic summarization.


Disabling the Validation of Source IP Addresses

By default, the software validates the source IP address of incoming RIP routing updates. If that source address is not valid, the software discards the routing update.

You might want to disable this feature if you have a router that is "off network" and you want to receive its updates. However, disabling this feature is not recommended under normal circumstances. To disable the default function that validates the source IP addresses of incoming routing updates, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# no validate-update-source

Disables the validation of the source IP address of incoming RIP routing updates.


Enabling or Disabling Split Horizon

Normally, routers that are connected to broadcast-type IP networks and that use distance-vector routing protocols employ the split horizon mechanism to reduce the possibility of routing loops. Split horizon blocks information about routes from being advertised by a router out of any interface from which that information originated. This behavior usually optimizes communications among multiple routers, particularly when links are broken. However, with nonbroadcast networks (such as Frame Relay and Switched Multimegabit Digital System [SMDS]), situations can arise for which this behavior is less than ideal. For these situations, you might want to disable split horizon with RIP.

If an interface is configured with secondary IP addresses and split horizon is enabled, updates might not be sourced by every secondary address. One routing update is sourced per network number unless split horizon is disabled.

To enable or disable split horizon, use the following commands in interface configuration mode, as needed:

Command
Tasks

Router(config-if)# ip split-horizon

Enable split horizon.

Router(config-if)# no ip split-horizon

Disable split horizon.


Split horizon for Frame Relay and SMDS encapsulation is disabled by default. Split horizon is not disabled by default for interfaces using any of the X.25 encapsulations. For all other encapsulations, split horizon is enabled by default.

See the " Split Horizon Examples" section for examples of using split horizon.


Note In general, changing the state of the default is not recommended unless you are certain that your application requires making a change in order to advertise routes properly. Remember that 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 in any relevant multicast groups on that network.


Configuring Interpacket Delay

By default, the software adds no delay between packets in a multiple-packet RIP update being sent. If you have a high-end router sending to a low-speed router, you might want to add such interpacket delay to RIP updates, in the range of 8 to 50 milliseconds. To do so, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# output-delay delay

Adds interpacket delay for RIP updates sent.


Connecting RIP to a WAN

Routers are used on connection-oriented networks to allow potential connectivity to many remote destinations. Circuits on the WAN are established on demand and are relinquished when the traffic subsides. Depending on the application, the connection between any two sites for user data could be short and relatively infrequent.

There are two problems using RIP to connect to a WAN:

Periodic broadcasting by RIP generally prevents WAN circuits from being closed.

Even on fixed, point-to-point links, the overhead of periodic RIP transmissions could seriously interrupt normal data transfer because of the quantity of information that passes through the line every 30 seconds.

To overcome these limitations, triggered extensions to RIP cause RIP to send information on the WAN only when there has been an update to the routing database. Periodic update packets are suppressed over the interface on which this feature is enabled. RIP routing traffic is reduced on point-to-point, serial interfaces. Therefore, you can save money on an on-demand circuit for which you are charged for usage. Triggered extensions to RIP partially support RFC 2091, Triggered Extensions to RIP to Support Demand Circuits.

To enable triggered extensions to RIP, use the following commands in global configuration mode:

Command
Purpose

Router(config)# interface serial controller-number

Enters serial interface configuration mode.

Router(config-if)# ip rip triggered

Enables triggered extensions to RIP.


To display the contents of the RIP private database, use the following command in EXEC mode:

Command
Purpose

Router# show ip rip database [prefix mask]

Displays the contents of the RIP private database.


RIP Configuration Examples

The following sections provide RIP configuration examples:

IP Route Summarization Examples

RIP Split Horizon Examples

Route Summarization Examples

A correct example and an incorrect configuration example of route summarization are provided.

Example 1: Correct Configuration

The following example shows how the ip summary-address rip router configuration command works with automatic summary addressing in RIP. In the example, the major network is 10.0.0.0. The summary address 10.2.0.0 overrides the automatic summary address of 10.0.0.0, so that 10.2.0.0 is advertised out 10/100 Fast Ethernet interface and 10.0.0.0 is not advertised.


Note If split horizon is enabled, neither automatic summary nor interface summary addresses (those configured with the ip summary-address rip command) are advertised.


Router# router rip
Router(config)# router interface fastethernet0/0
Router(config-if)# ip address 10.1.1.1 255.255.255.0
Router(config-if)# ip summary-address rip 10.2.0.0 255.255.0.0
Router(config-if)# no ip split-horizon

Router# router rip
Router(config)# network 10.0.0.0

Router(config)# neighbor 172.16.2.2 peer-group mygroup

Example 2: Incorrect Configuration

The following example shows an illegal use of the ip summary-address rip command, because both addresses to be summarized have the same major network. Each route summarization on an interface must have a unique major network, whether or not the addresses have unique address masks.

Router(config)# interface fastethernet0/0
.
Router(config-if)# ip summary-address rip 10.1.0.0 255.255.0.0
Rotuer(config-if)# ip summary-address rip 10.2.0.0 255.255.255.0

Split Horizon Examples

Two examples of configuring split horizon are provided.

Example 1:

The following configuration shows a simple example of disabling split horizon on a serial link. In this example, the serial link is connected to an X.25 network.

interface serial 0
encapsulation x25
no ip split-horizon

Example 2:

Figure 13-1 illustrates a typical situation in which the no ip split-horizon interface configuration command would be useful. This figure depicts two IP subnets that are both accessible via a serial interface on Router C (connected to Frame Relay network). In this example, the serial interface on Router C accommodates one of the subnets via the assignment of a secondary IP address.

The Ethernet interfaces for Router A, Router B, and Router C (connected to IP networks 10.13.50.0, 10.155.120.0, and 10.20.40.0, respectively), all have split horizon enabled by default, while the serial interfaces connected to networks 192.125.1.0 and 192.108.1.0 all have split horizon disabled by default. The partial interface configuration specifications for each router that follow Figure 13-1 illustrate that the ip split-horizon interface configuration command is not explicitly configured under normal conditions for any of the interfaces.

Figure 13-1 Disabled Split Horizon Example for Frame Relay Network

In this example, split horizon must be disabled on Router C in order for network 192.125.1.0 to be advertised into network 192.108.0.0, and vice versa. These subnets overlap at Router C, interface 0. If split horizon were enabled on serial interface 0, it would not advertise a route back into the Frame Relay network for either of these networks.

The configurations for routers A, B, and C follow.

Router A Configuration

interface ethernet 1
 ip address 10.13.50.1
!
interface serial 1
 ip address 192.125.1.2
 encapsulation frame-relay
 no ip split-horizon

Router B Configuration

interface ethernet 2
 ip address 10.155.120.1
!
interface serial 2
 ip address 192.108.1.2
 encapsulation frame-relay 
 no ip split-horizon

Router C Configuration

interface ethernet 0
 ip address 10.20.40.1
!
interface serial 1/0
 ip address 192.124.1.1
 ip address 192.108.1.1 secondary
 encapsulation frame-relay 

Enhanced Interior Gateway Routing Protocol

Enhanced Interior Gateway Routing Protocol (EIGRP) is an enhanced version of the IGRP developed by Cisco. EIGRP uses the same distance vector algorithm and distance information as IGRP. However, the convergence properties and the operating efficiency of EIGRP have improved substantially over IGRP.

To configure EIGRP, perform the tasks described in the following sections:

Enabling EIGRP (Required)

Logging EIGRP Neighbor Adjacency Changes (Optional)

Configuring the Percentage of Link Bandwidth Used (Optional)

Adjusting the EIGRP Metric Weights (Optional)

Applying Offsets to Routing Metrics (Optional)

Disabling Route Summarization (Optional)

Configuring Summary Aggregate Addresses (Optional)

Configuring EIGRP Protocol-Independent Parameters (Optional)

Monitoring and Maintaining EIGRP(Optional)

Configuring EIGRP Stub Routing (Optional)

The convergence technology is based on research conducted at SRI International and employs an algorithm referred to as the Diffusing Update Algorithm (DUAL). This algorithm guarantees loop-free operation at every instant throughout a route computation and allows all devices involved in a topology change to synchronize at the same time. Routers that are not affected by topology changes are not involved in recomputations. The convergence time with DUAL rivals that of any other existing routing protocol.

EIGRP provides the following features:

Automatic redistribution—IGRP routes can be automatically redistributed into EIGRP, and EIGRP routes can be automatically redistributed into IGRP. If desired, you can turn off redistribution. You can also completely turn off EIGRP and IGRP on the router or on individual interfaces.

Increased network width—With Routing Information Protocol (RIP), the largest possible width of your network is 15 hops. When EIGRP is enabled, the largest possible width is 224 hops. Because the EIGRP metric is large enough to support thousands of hops, the only barrier to expanding the network is the transport layer hop counter. Cisco works around this problem by incrementing the transport control field only when an IP packet has traversed 15 routers and the next hop to the destination was learned by way of EIGRP. When a RIP route is being used as the next hop to the destination, the transport control field is incriminated as usual.

Fast convergence—The DUAL algorithm allows routing information to converge as quickly as any currently available routing protocol.

Partial updates—EIGRP sends incremental updates when the state of a destination changes, instead of sending the entire contents of the routing table. This feature minimizes the bandwidth required for EIGRP packets.

Less CPU usage than IGRP—This occurs because full update packets need not be processed each time they are received.

Neighbor discovery mechanism—This is a simple hello mechanism used to learn about neighboring routers. It is protocol-independent.

Variable-length subnet masks (VLSMs).

Arbitrary route summarization.

Scaling—EIGRP scales to large networks.


Note Redistribution between EIGRP and IGRP differs from normal redistribution in that the metrics of IGRP routes are compared with the metrics of external EIGRP routes. The rules of normal administrative distances are not followed, and routes with the lowest metric are selected.


EIGRP has the following four basic components:

Neighbor discovery of neighbor recovery

Reliable transport protocol

DUAL finite state machine

Protocol-dependent modules

Neighbor discovery of neighbor recovery is the process that routers use to dynamically learn of other routers on their directly attached networks. Routers must also discover when their neighbors become unreachable or inoperative. Neighbor discovery of neighbor recovery is achieved with low overhead by periodically sending small hello packets. As long as hello packets are received, the IOS software can determine that a neighbor is alive and functioning. Once this status is determined, the neighboring routers can exchange routing information.

The reliable transport protocol is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Some EIGRP packets must be sent reliably and others need not be. For efficiency, reliability is provided only when necessary. For example, on a multiaccess network that has multicast capabilities (such as Ethernet) it is not necessary to send hello packets reliably to all neighbors individually. Therefore, EIGRP sends a single multicast hello with an indication in the packet informing the receivers that the packet need not be acknowledged. Other types of packets (such as updates) require acknowledgment, which is indicated in the packet. The reliable transport has a provision to send multicast packets quickly when unacknowledged packets are pending. This provision helps to ensure that convergence time remains low in the presence of varying speed links.

The DUAL finite state machine embodies the decision process for all route computations. It tracks all routes advertised by all neighbors. DUAL uses the distance information (known as a metric) to select efficient, loop-free paths. DUAL selects routes to be inserted into a routing table based on feasible successors. A successor is a neighboring router used for packet forwarding that has a least-cost path to a destination that is guaranteed not to be part of a routing loop. When there are no feasible successors but there are neighbors advertising the destination, a recomputation must occur. This is the process whereby a new successor is determined. The amount of time required to recompute the route affects the convergence time. Recomputation is processor-intensive; it is advantageous to avoid unneeded recomputation. When a topology change occurs, DUAL will test for feasible successors. If there are feasible successors, it will use any it finds in order to avoid unnecessary recomputation.

The protocol-dependent modules are responsible for network layer protocol-specific tasks. An example is the EIGRP module, which is responsible for sending and receiving EIGRP packets that are encapsulated in IP. It is also responsible for parsing EIGRP packets and informing DUAL of the new information received. EIGRP asks DUAL to make routing decisions, but the results are stored in the IP routing table. Also, EIGRP is responsible for redistributing routes learned by other IP routing protocols.

For a complete description of the EIGRP commands listed in this section, refer to the "Enhanced IGRP Commands" chapter of the Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols publication. To locate documentation of other commands that appear in this section, use the command reference master index, or search online.

Enabling EIGRP

To create an EIGRP routing process, use the following commands beginning in global configuration mode:

Command
Purpose

Router(config)# router eigrp autonomous-system

Enables an EIGRP routing process in global configuration mode.

Router(config-router)# network network-number

Associates networks with an EIGRP routing process in router configuration mode.


EIGRP sends updates to the interfaces in the specified networks. If you do not specify the network of an interface, the interface will not be advertised in any EIGRP update.

Logging EIGRP Neighbor Adjacency Changes

You can enable the logging of neighbor adjacency changes to monitor the stability of the routing system and to help you detect problems. By default, adjacency changes are not logged. To enable such logging, use the following command in global configuration mode:

Command
Purpose

Router(config)# eigrp log-neighbor-changes

Enables logging of EIGRP neighbor adjacency changes.


Configuring the Percentage of Link Bandwidth Used

By default, EIGRP packets consume a maximum of 50 percent of the link bandwidth, as configured with the bandwidth interface configuration command. You might want to change that value if a different level of link utilization is required or if the configured bandwidth does not match the actual link bandwidth (it may have been configured to influence route metric calculations).

To configure the percentage of bandwidth that may be used by EIGRP on an interface, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# ip bandwidth-percent eigrp percent

Configures the percentage of bandwidth that might be used by EIGRP on an interface.


Adjusting the EIGRP Metric Weights

You can adjust the default behavior of EIGRP routing and metric computations. For example, this adjustment allows you to tune system behavior to allow for satellite transmission. Although EIGRP metric defaults have been carefully selected to provide excellent operation in most networks, you can adjust the EIGRP metric. Adjusting EIGRP metric weights can dramatically affect network performance, so be careful if you adjust them.

To adjust the EIGRP metric weights, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# metric weights tos k1 k2 k3 k4 k5

Adjusts the EIGRP metric.



Note Because of the complexity of this task, it is not recommended unless it is done with guidance from an experienced network designer.


By default, the EIGRP composite metric is a 32-bit quantity that is a sum of the segment delays and the lowest segment bandwidth (scaled and inverted) for a given route. For a network of homogeneous media, this metric reduces to a hop count. For a network of mixed media (FDDI, Ethernet, and serial lines running from 9600 bits per second to T1 rates), the route with the lowest metric reflects the most desirable path to a destination.

Applying Offsets to Routing Metrics

An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned via EIGRP. An offset list provides a local mechanism for increasing the value of routing metrics. Optionally, you can limit the offset list with either an access list or an interface. To increase the value of routing metrics, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# offset-list [access-list-number | access-list-name] {in | out} offset [interface-type interface-number]

Applies an offset to routing metrics.


Disabling Route Summarization

You can configure EIGRP to perform automatic summarization of subnet routes into network-level routes. For example, you can configure subnet 131.108.1.0 to be advertised as 131.108.0.0 over interfaces that have subnets of 192.31.7.0 configured. Automatic summarization is performed when there are two or more network commands configured for the EIGRP process. By default, this feature is enabled.

To disable automatic summarization, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# no auto-summary

Disables automatic summarization.


Route summarization works in conjunction with the ip summary-address eigrp interface configuration command, in which additional summarization can be performed. If automatic summarization is in effect, there usually is no need to configure network level summaries using the ip summary-address eigrp command.

Configuring Summary Aggregate Addresses

You can configure a summary aggregate address for a specified interface. If any more specific routes are in the routing table, EIGRP will advertise the summary address out the interface with a metric equal to the minimum of all more specific routes.

To configure a summary aggregate address, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# ip summary-address eigrp autonomous-system-number ip-address mask

Configure a summary aggregate address.


Configuring EIGRP Protocol-Independent Parameters

EIGRP works with AppleTalk, IP, and IPX. To configure EIGRP, perform one or more of the tasks in the following sections:

Adjusting the Interval Between Hello Packets and the Hold Time

Disabling Split Horizon

Adjusting the Interval Between Hello Packets and the Hold Time

You can adjust the interval between hello packets and the hold time.

Routing devices periodically send hello packets to each other to dynamically learn of other routers on their directly attached networks. This information is used to discover neighbors and to learn when neighbors become unreachable or inoperative.

By default, hello packets are sent every 5 seconds. The exception is on low-speed, nonbroadcast multiaccess (NBMA) media, where the default hello interval is 60 seconds. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command. The default hello interval remains 5 seconds for high-speed NBMA networks. Note that for the purposes of EIGRP, Frame Relay and Switched Multimegabit Data Service (SMDS) networks may or may not be considered to be NBMA. These networks are considered NBMA if the interface has not been configured to use physical multicasting; otherwise they are not considered NBMA.

You can configure the hold time on a specified interface for a particular EIGRP routing process designated by the autonomous system number. The hold time is advertised in hello packets and indicates to neighbors the length of time they should consider the sender valid. The default hold time is three times the hello interval, or 15 seconds. For slow-speed NBMA networks, the default hold time is 180 seconds.

To change the interval between hello packets, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# ip hello-interval eigrp autonomous-system-number seconds

Configures the hello interval for an EIGRP routing process.


On very congested and large networks, the default hold time might not be sufficient time for all routers to receive hello packets from their neighbors. In this case, you may want to increase the hold time.

To change the hold time, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# ip hold-time eigrp autonomous-system-number seconds

Configures the hold time for an EIGRP routing process.



Note Do not adjust the hold time without advising your technical support personnel.


Disabling Split Horizon

Split horizon controls the sending of EIGRP update and query packets. When split horizon is enabled on an interface, update and query packets are not sent for destinations for which this interface is the next hop. Controlling update and query packets in this manner reduces the possibility of routing loops.

By default, split horizon is enabled on all interfaces.

Split horizon blocks route information from being advertised by a router out of any interface from which that information originated. This behavior usually optimizes communications among multiple routing devices, particularly when links are broken. However, with nonbroadcast networks (such as Frame Relay and SMDS), situations can arise for which this behavior is less than ideal. For these situations, including networks in which you have EIGRP configured, you may want to disable split horizon.

To disable split horizon, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# no ip split-horizon eigrp autonomous-system-number

Disables split horizon.


Configuring EIGRP Stub Routing

The EIGRP Stub Routing feature improves network stability, reduces resource utilization, and simplifies stub router configuration.

Stub routing is commonly used in a hub-and-spoke network topology. In a hub-and-spoke network, one or more end (stub) networks are connected to a remote router (the spoke) that is connected to one or more distribution routers (the hub). The remote router is adjacent only to one or more distribution routers. The only route for IP traffic to follow into the remote router is through a distribution router.

This type of configuration is commonly used in WAN topologies where the distribution router is directly connected to a WAN. The distribution router can be connected to many more remote routers. Often, the distribution router will be connected to 100 or more remote routers. In a hub-and-spoke topology, the remote router must forward all nonlocal traffic to a distribution router, so it becomes unnecessary for the remote router to hold a complete routing table. Generally, the distribution router need not send anything more than a default route to the remote router.

When using the EIGRP Stub Routing feature, you need to configure the distribution and remote routers to use EIGRP, and to configure only the remote router as a stub. Only specified routes are propagated from the remote (stub) router. The hub router responds to all queries for summaries, connected routes, redistributed static routes, external routes, and internal routes with the message "inaccessible." A router that is configured as a stub will send a special peer information packet to all neighboring routers to report its status as a stub router.

Any neighbor that receives a packet informing it of the stub status will not query the stub router for any routes, and a router that has a stub peer will not query that peer. The stub router will depend on the distribution router to send the proper updates to all peers.

Figure 13-2 shows a simple hub-and-spoke configuration.

Figure 13-2 Simple Hub-and-Spoke Network

The stub routing feature by itself does not prevent routes from being advertised to the remote router. In the example in Figure 13-2, the remote router can access the corporate network and the Internet through the distribution router only. Having a full route table on the remote router, in this example, would serve no functional purpose because the path to the corporate network and the Internet would always be through the distribution router. The larger route table would only reduce the amount of memory required by the remote router. Bandwidth and memory can be conserved by summarizing and filtering routes in the distribution router. The remote router need not receive routes that have been learned from other networks because the remote router must send all nonlocal traffic, regardless of destination, to the distribution router. If a true stub network is desired, the distribution router should be configured to send only a default route to the remote router. The EIGRP Stub Routing feature does not automatically enable summarization on the distribution router. In most cases, the network administrator will need to configure summarization on the distribution routers.


Note When configuring the distribution router to send only a default route to the remote router, you must use the ip classless command on the remote router. By default, the ip classless command is enabled in all Cisco IOS images that support the EIGRP Stub Routing feature.


Without the stub feature, even after the routes that are sent from the distribution router to the remote router have been filtered or summarized, a problem might occur. If a route is lost somewhere in the corporate network, EIGRP could send a query to the distribution router, which in turn will send a query to the remote router even if routes are being summarized. If there is a problem communicating over the WAN link between the distribution router and the remote router, an EIGRP stuck in active (SIA) condition could occur and cause instability elsewhere in the network. The EIGRP Stub Routing feature allows a network administrator to prevent queries from being sent to the remote router.

Dual-Homed Remote Topology

In addition to a simple hub-and-spoke network where a remote router is connected to a single distribution router, the remote router can be dual-homed to two or more distribution routers. This configuration adds redundancy and introduces unique issues, and the stub feature helps to address some of these issues.

A dual-homed remote router will have two or more distribution (hub) routers. However, the principles of stub routing are the same as they are with a hub-and-spoke topology. Figure 13-3 shows a common dual-homed remote topology with one remote router, but 100 or more routers could be connected on the same interfaces on distribution router 1 and distribution router 2. The remote router will use the best route to reach its destination. If distribution router 1 experiences a failure, the remote router can still use distribution router 2 to reach the corporate network.

Figure 13-3 Simple Dual-Homed Remote Topology

Figure 13-3 shows a simple dual-homed remote with one remote router and two distribution routers. Both distribution routers maintain routes to the corporate network and stub network 10.1.1.0/24.

Dual-homed routing can introduce instability into an EIGRP network. In Figure 13-4, distribution router 1 is directly connected to network 10.3.1.0/24. If summarization or filtering is applied on distribution router 1, the router will advertise network 10.3.1.0/24 to all of its directly connected EIGRP neighbors (distribution router 2 and the remote router).

Figure 13-4 Dual-Homed Remote Topology With Distribution Router 1 Connected to Two Networks

Figure 13-4 shows a simple dual-homed remote router where distribution router 1 is connected to both network 10.3.1.0/24 and network 10.2.1.0/24.

If the 10.2.1.0/24 link between distribution router 1 and distribution router 2 has failed, the lowest cost path to network 10.3.1.0/24 from distribution router 2 is through the remote router (see Figure 13-5). This route is not desirable because the traffic that was previously traveling across the corporate network 10.2.1.0/24 would now be sent across a much lower bandwidth connection. The over utilization of the lower bandwidth WAN connection can cause a number of problems that might affect the entire corporate network. The use of the lower bandwidth route that passes through the remote router might cause WAN EIGRP distribution routers to be dropped. Serial lines on distribution and remote routers could also be dropped, and EIGRP SIA errors on the distribution and core routers could occur.

Figure 13-5 Dual-Homed Remote Topology with a Failed Route to a Distribution Router

It is not desirable for traffic from distribution router 2 to travel through any remote router in order to reach network 10.3.1.0/24. If the links are sized to handle the load, it would be acceptable to use one of the backup routes. However, most networks of this type have remote routers located at remote offices with relatively slow links. This problem can be prevented if proper summarization is configured on the distribution router and remote router.

It is typically undesirable for traffic from a distribution router to use a remote router as a transit path. A typical connection from a distribution router to a remote router would have much less bandwidth than a connection at the network core. Attempting to use a remote router with a limited bandwidth connection as a transit path would generally produce excessive congestion to the remote router. The EIGRP Stub Routing feature can prevent this problem by preventing the remote router from advertising core routes back to distribution routers. Routes learned by the remote router from distribution router 1 will not be advertised to distribution router 2. Since the remote router will not advertise core routes to distribution router 2, the distribution router will not use the remote router as a transit for traffic destined for the network core.

The EIGRP Stub Routing feature can help to provide greater network stability. In the event of network instability, this feature prevents EIGRP queries from being sent over limited bandwidth links to nontransit routers. Instead, distribution routers to which the stub router is connected answer the query on behalf of the stub router. This feature greatly reduces the chance of further network instability due to congested or problematic WAN links. The EIGRP Stub Routing feature also simplifies the configuration and maintenance of hub-and-spoke networks. When stub routing is enabled in dual-homed remote configurations, it is no longer necessary to configure filtering on remote routers to prevent those remote routers from appearing as transit paths to the hub routers.


Caution EIGRP Stub Routing should only be used on stub routers. A stub router is defined as a router connected to the network core or distribution layer through which core transit traffic should not flow. A stub router should not have any EIGRP neighbors other than distribution routers. Ignoring this restriction will cause undesirable behavior.

Monitoring and Maintaining EIGRP

To delete neighbors from the neighbor table, use the following command in EXEC mode:

Command
Purpose

Router# clear ip eigrp neighbors [ip-address | interface-type]

Deletes neighbors from the neighbor table.


To display various routing statistics, use the following commands in EXEC mode, as needed:

Command
Purpose

Router# show ip eigrp interfaces [interface-type | interface-number] [as-number]

Displays information about interfaces configured for EIGRP.

Router# show ip eigrp neighbors [interface-type | as-number | static]

Displays the EIGRP discovered neighbors.

Router# show ip eigrp topology [as-number | [[ip-address] mask]]

Displays the EIGRP topology table for a given process.

Router# show ip eigrp traffic [as-number]

Displays the number of packets sent and received for all or a specified EIGRP process.


To enable EIGRP Stub Routing packet debugging, use the following command in privileged EXEC mode:

Command
Purpose

Router# debug eigrp packet stub

Displays debug information about the stub status of peer routers.


EIGRP Stub Routing

To configure EIGRP Stub Routing, perform the tasks described in the following sections. The tasks in the first section are required; the task in the last section is optional.

Configuring EIGRP Stub Routing (Required)

Verifying EIGRP Stub Routing (Optional)

Configuring EIGRP Stub Routing

To configure a remote or spoke router for EIGRP stub routing, use the following commands beginning in router configuration mode:

 
Command
Purpose

Step 1

router(config)# router eigrp 1

Configures a remote or distribution router to run an EIGRP process.

Step 2

router(config-router)# network network-number

Specifies the network address of the EIGRP distribution router.

Step 3

router(config-router)# eigrp stub [receive-only | connected | static | summary]

Configures a remote router as an EIGRP stub router.

Verifying EIGRP Stub Routing

To verify that a remote router has been configured as a stub router with EIGRP, use the show ip eigrp neighbor detail command from the distribution router in privileged EXEC mode. The last line of the output will show the stub status of the remote or spoke router. The following example shows output is from the show ip eigrp neighbor detail command:

router# show ip eigrp neighbor detail
IP-EIGRP neighbors for process 1  
H   Address                 Interface   Hold Uptime   SRTT   RTO  Q  Seq Type
                                (sec)      (ms)        Cnt Num
0   10.1.1.2           Se3/1    11 00:00:59   1  4500  0   7
   Version 12.1/1.2, Retrans: 2, Retries: 0
   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes

Stub Routing Example

A router that is configured as a stub with the eigrp stub command shares connected and summary routing information with all neighbor routers by default. Four optional keywords can be used with the eigrp stub command to modify this behavior:

receive-only

connected

static

summary

This section provides configuration examples for all forms of the eigrp stub command. The eigrp stub command can be modified with several options, and these options can be used in any combination except for the receive-only keyword. The receive-only keyword will restrict the router from sharing any of its routes with any other router in that EIGRP autonomous system, and the receive-only keyword will not permit any other option to be specified because it prevents any type of route from being sent.

The three other optional keywords (connected, static, and summary) can be used in any combination but cannot be used with the receive-only keyword. If any of these three keywords is used individually with the eigrp stub command, connected and summary routes will not be sent automatically.

The connected keyword will permit the EIGRP Stub Routing feature to send connected routes. If the connected routes are not covered by a network statement, it may be necessary to redistribute connected routes with the redistribute connected command under the EIGRP process. This option is enabled by default.

The static keyword will permit the EIGRP Stub Routing feature to send static routes. Without this option, EIGRP will not send any static routes, including internal static routes that normally would be automatically redistributed. It will still be necessary to redistribute static routes with the redistribute static command.

The summary keyword will permit the EIGRP Stub Routing feature to send summary routes. Summary routes can be created manually with the summary address command or automatically at a major network border router with the auto-summary command enabled. This option is enabled by default.

In the following example, the eigrp stub command is used to configure the router as a stub that advertises connected and summary routes:

router eigrp 1
network 10.0.0.0
eigrp stub

In the following example, the eigrp stub connected static command is used to configure the router as a stub that advertises connected and static routes (sending summary routes will not be permitted):

router eigrp 1
network 10.0.0.0
eigrp stub connected static

In the following example, the eigrp stub receive-only command is used to configure the router as a stub, and connected, summary, or static routes will not be sent:

router eigrp 1
network 10.0.0.0 eigrp 
stub receive-only

Open Shortest Path First

This section describes how to configure Open Shortest Path First (OSPF). For a complete description of the OSPF commands in this section, refer to the "OSPF Commands" chapter of the Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols publication. To locate documentation of other commands that appear in this section, use the command reference master index, or search online.

To configure OSPF, perform the tasks described in the following sections. The tasks in the first section are required; the tasks in the remaining sections are optional, but might be required for your application.

Enabling OSPF (Required)

Configuring OSPF Interface Parameters (Optional)

Configuring OSPF over Different Physical Networks (Optional)

Configuring OSPF Area Parameters (Optional)

Configuring OSPF NSSA (Optional)

Configuring Route Summarization Between OSPF Areas (Optional)

Configuring Route Summarization When Redistributing Routes into OSPF (Optional)

Creating Virtual Links (Optional)

Generating a Default Route (Optional)

Configuring Lookup of DNS Names (Optional)

Forcing the Router ID Choice with a Loopback Interface (Optional)

Controlling Default Metrics (Optional)

Changing the OSPF Administrative Distances (Optional)

Configuring OSPF on Simplex Ethernet Interfaces (Optional)

Configuring Route Calculation Timers (Optional)

Logging Neighbors Going Up or Down (Optional)

Changing the LSA Group Pacing (Optional)

Blocking OSPF LSA Flooding (Optional)

Reducing LSA Flooding (Optional)

Ignoring MOSPF LSA Packets (Optional)

Displaying OSPF Update Packet Pacing (Optional)

Monitoring and Maintaining OSPF (Optional)

OSPF Configuration Examples (Optional)

OSPF typically requires coordination among many internal routers: Area Border Routers (ABRs), which are routers connected to multiple areas, and Autonomous System Boundary Routers (ASBRs). 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 on all routers.

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.

Enabling 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. To do so, use the following commands beginning in global configuration mode:

 
Command
Task

Step 1

Router(config)# router ospf process-id

Enable OSPF routing, which places you in router configuration mode.

Step 2

Router(config-router)# network ip-address wildcard-mask area area-id

Define an interface on which OSPF runs and define the area ID for that interface.

Configuring 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 interface configuration commands. Therefore, be sure that if you do configure any of these parameters, the configurations for all routers on your network have compatible values.

To specify interface parameters for your network, use the following commands in interface configuration mode, as needed:

Command
Purpose

Router(config-if)# ip ospf cost cost

Explicitly specifies the cost of sending a packet on an OSPF interface.

Router(config-if)# ip ospf retransmit-interval seconds

Specifies the number of seconds between link-state advertisement (LSA) retransmissions for adjacencies belonging to an OSPF interface.

Router(config-if)# ip ospf transmit-delay seconds

Sets the estimated number of seconds required to send a link-state update packet on an OSPF interface.

Router(config-if)# ip ospf priority number-value

Sets priority to help determine the OSPF designated router for a network.

Router(config-if)# ip ospf hello-interval seconds

Specifies the length of time between the hello packets that the Cisco  IOS software sends on an OSPF interface.

Router(config-if)# ip ospf dead-interval seconds

Sets the number of seconds that a device must wait before it declares a neighbor OSPF router down because it has not received a hello packet.

Router(config-if)# ip ospf authentication-key key

Assigns a password to be used by neighboring OSPF routers on a network segment that is using the OSPF simple password authentication.

Router(config-if)# ip ospf message-digest-key key-id md5 key

Enables OSPF MD5 authentication. The values for the key-id and key arguments must match values specified for other neighbors on a network segment.

Router(config-if)# ip ospf authentication [message-digest | null]

Specifies the authentication type for an interface.


Configuring OSPF over Different Physical Networks

OSPF classifies media into the following three types of networks by default:

Broadcast networks (Ethernet, Token Ring, and FDDI)

Nonbroadcast multiaccess (NBMA) networks (Switched Multimegabit Data Service [SMDS], Frame Relay, and X.25)

Point-to-point networks (High-Level Data Link Control [HDLC], PPP)

You can configure your network as either a broadcast or an NBMA 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. Refer to the x25 map and frame-relay map command descriptions in the Cisco IOS Wide-Area Networking Command Reference publication for more detail.

Configuring Your OSPF Network Type

You have the choice of configuring your OSPF network type as either broadcast or NBMA, regardless of the default media type. Using this feature, you can configure broadcast networks as NBMA networks when, for example, you have routers in your network that do not support multicast addressing. You also can configure NBMA networks (such as X.25, Frame Relay, and SMDS) as broadcast networks. This feature saves you from needing to configure neighbors, as described in the "Configuring OSPF for Nonbroadcast Networks" section.

Configuring NBMA, multiaccess networks as either broadcast or nonbroadcast assumes that there are virtual circuits (VCs) 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 VCs to both routers. Note that you need not 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-to-multipoint network has the following benefits compared to NBMA 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 VC failure.

To configure your OSPF network type, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# ip ospf network {broadcast | non-broadcast | {point-to-multipoint [non-broadcast]}}

Configures the OSPF network type for a specified interface.


See the "OSPF Point-to-Multipoint Example" section for an example of an OSPF point-to-multipoint network.

Configuring 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 the point-to-multipoint keyword was added to the ip ospf network interface configuration command, some OSPF point-to-multipoint protocol traffic was treated as multicast traffic. Therefore, the neighbor command was not needed for point-to-multipoint interfaces because multicast took care of the traffic. Hello, update, and acknowledgment messages were sent using multicast. In particular, multicast hello messages discovered all neighbors dynamically.

On any point-to-multipoint interface (broadcast or not), the Cisco IOS software assumed that the cost to each neighbor was equal. The cost was configured with the ip ospf cost interface confutation command. In reality, the bandwidth to each neighbor is different, so the cost should differ. 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:

 
Command
Purpose

Step 1

Router(config-if)# ip ospf network point-to-multipoint

Configures an interface as point-to-multipoint for broadcast media.

Step 2

Router(config-if)# exit

Enters global configuration mode.

Step 3

Router(config)# router ospf process-id

Configures an OSPF routing process and enters router configuration mode.

Step 4

Router(config-router)# neighbor ip-address cost number

Specifies a neighbor and assigns a cost to the neighbor. Repeat this step 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 interface configuration command.

Configuring OSPF for Nonbroadcast Networks

Because many routers might be attached to an OSPF network, a designated router is selected for the network. Special configuration parameters are needed 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
Purpose

Router(config-router)# neighbor ip-address [priority number] [poll-interval seconds]

Configures a router interconnecting to nonbroadcast networks.


You can specify the following neighbor parameters, as required:

Priority for a neighboring router

Nonbroadcast poll interval

On point-to-multipoint, nonbroadcast networks, you now use the neighbor router configuration command to identify neighbors. Assigning a cost to a neighbor is optional.

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 interface configuration command. In reality, the bandwidth to each neighbor is different, so the cost should differ. 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:

 
Command
Purpose

Step 1

Router(config-if)# ip ospf network point-to-multipoint non-broadcast

Configures an interface as point-to-multipoint for nonbroadcast media.

Step 2

Router(config-if)# exit

Enters global configuration mode.

Step 3

Router(config)# router ospf process-id

Configures an OSPF routing process and enters router configuration mode.

Step 4

Router(config-router)# neighbor ip-address [cost number]

Specifies a neighbor and assign a cost to the neighbor. Repeat this step 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 interface configuration command.

Configuring OSPF Area Parameters

Our OSPF software allows you to configure several area parameters. These area parameters, shown in the following task 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 ABR, 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 LSAs sent into a stub area, you can configure the no-summary keyword of the area stub router configuration command on the ABR to prevent it from sending summary link advertisement (LSAs type 3) into the stub area.

To specify an area parameter for your network, use the following commands in router configuration mode as needed:

Command
Purpose

Router(config-router)# area area-id authentication

Enables authentication for an OSPF area.

Router(config-router)# area area-id authentication message-digest

Enables MD5 authentication for an OSPF area.

Router(config-router)# area area-id stub [no-summary]

Defines an area to be a stub area.

Router(config-router)# area area-id default-cost cost

Assigns a specific cost to the default summary route used for the stub area.


Configuring OSPF NSSA

The OSPF implementation of NSSA is similar to OSPF stub area. NSSA does not flood type 5 external LSAs from the core into the area, but it can import autonomous system external routes in a limited fashion within the area.

NSSA allows importing of type 7 autonomous system external routes within NSSA area by redistribution. These type 7 LSAs are translated into type 5 LSAs by NSSA ABRs, 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 could not be redistributed into stub area, and two routing protocols needed to be maintained. A simple protocol like RIP was usually run and handled the redistribution. 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.

To specify area parameters as needed to configure OSPF NSSA, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# area area-id nssa [no-redistribution] [default-information-originate]

Defines an area to be NSSA.


To control summarization and filtering of type 7 LSAs into type 5 LSAs, use the following command in router configuration mode on the ABR:

Command
Purpose

Router(config-router)# summary address prefix mask [not advertise] [tag tag]

Controls the summarization and filtering during the translation.


Implementation Considerations

Evaluate the following considerations before you implement 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 or 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.

Configuring 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

Router(config-router)# area area-id range ip-address mask [advertise | not-advertise]

Specifies an address range for which a single route will be advertised.


Configuring Route Summarization When Redistributing Routes into OSPF

When routes from other protocols are redistributed into OSPF, each route is advertised individually in an external 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
Purpose

Router(config-router)# summary-address ip-address mask prefix mask [not-advertise][tag tag]

Specifies an address and mask that covers redistributed routes, so only one summary route is advertised. Use the optional not-advertise keyword to filter out a set of routes.


Creating 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 endpoints of a virtual link are ABRs. 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
Purpose

Router(config-router)# 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 key-id md5 key]]

Establishes 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.

Generating a Default Route

You can force an ASBR 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 ASBR. However, an ASBR does not, by default, generate a default route into the OSPF routing domain.

To force the ASBR to generate a default route, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# default-information originate [always] [metric metric-value] [metric-type type-value] [route-map map-name]

Forces the autonomous system boundary router to generate a default route into the OSPF routing domain.


Configuring Lookup of DNS Names

You can configure OSPF to look up Domain Naming System (DNS) names for use in all OSPF show EXEC command displays. This feature makes it easier to identify a router, because the router 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
Purpose

Router(config)# ip ospf name-lookup

Configures DNS name lookup.


Forcing 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. Because 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 beginning in global configuration mode:

 
Command
Purpose

Step 1

Router(config)# interface loopback 0

Creates a loopback interface, which places the router in interface configuration mode.

Step 2

Router(config-if)# ip address ip-address mask

Assign an IP address to this interface.

Controlling Default Metrics

By default OSPF calculates the OSPF metric for an interface according to the bandwidth of the interface. For example, a 64 Kbps link gets a metric of 1562, while a T1 link gets a metric of 64.

The OSPF metric is calculated as the ref-bw value divided by the bandwidth value, with the ref-bw value equal to 108 by default, and the bandwidth value determined by the bandwidth interface configuration 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
Purpose

Router(config-router)# auto-cost reference-bandwidth ref-bw

Differentiates high bandwidth links.


Changing 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 from 0 to 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, interarea, and external. Routes within an area are intra-area; routes to another area are interarea; 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
Purpose

Router(config-router)# distance ospf {[intra-area dist1] [inter-area dist2] [external dist3]}

Change the OSPF distance values.


For an example of changing administrative distance, see the "Changing OSPF Administrative Distance Example" section.

Configuring 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 sending interface to be a passive interface. This configuration prevents OSPF from sending hello packets for the sending 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

Router(config-router)# passive-interface interface-type interface-number

Suppresses the sending of hello packets through the specified interface.


Configuring 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 so, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# timers spf spf-delay spf-holdtime

Configures route calculation timers.


Logging Neighbors Going Up or Down

By default, the system sends a syslog message when an OSPF neighbor goes up or down. If you turned off this feature and want to restore it, use the following command in router configuration mode:

Command
Task

Router(config-router)# log-adj-changes [detail]

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 debug ip ospf adjacency EXEC command. The log-adj-changes router configuration command provides a higher level view of the peer relationship with less output. Configure log-adj-changes detail if you want to see messages for each state change.

Changing the LSA Group Pacing

The OSPF LSA group pacing feature allows the router to group OSPF LSAs and pace the refreshing, checksumming, and aging functions. The group pacing results in more efficient use of the router.

The router groups OSPF LSAs and paces the refreshing, checksumming, and aging functions so that sudden increases in 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 (1 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. Figure 13-6 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 large 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 13-6 OSPF LSAs on a Single Timer Without Group Pacing

LSA Group Pacing With Multiple Timers

This problem is solved by configuring each LSA to have its own timer. To again use the example of refreshing, each LSA gets refreshed when it is 30 minutes old, independent of other LSAs. So the 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, which 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.

Figure 13-7 illustrates the case of refresh packets. The first time line illustrates individual LSA timers; the second time line illustrates individual LSA timers with group pacing.

Figure 13-7 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 from 10 seconds to 1800 seconds (30 minutes). To change the LSA group pacing interval, use the following command in router configuration mode:

Command
Purpose

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

Changes the group pacing of LSAs.


For an example, see the "LSA Group Pacing Example" section.

Blocking 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

Router(config-if)# ospf database-filter all out

Blocks the flooding of OSPF LSA packets to the interface.


On point-to-multipoint networks, to prevent flooding of OSPF LSAs, use the following command in router configuration mode:

Command
Purpose

Router(config-router)# neighbor ip-address database-filter all out

Blocks the flooding of OSPF LSA packets to the specified neighbor.


For an example of blocking LSA flooding, see the " Block LSA Flooding Example" section.

Reducing LSA Flooding

The explosive growth of the Internet has placed the focus on the scalability of IGPs such as OSPF. By design, OSPF requires LSAs to be refreshed as they expire after 3600 seconds. Some implementations have tried to improve the flooding by reducing the frequency to refresh from 30 minutes to about 50 minutes. This solution reduces the amount of refresh traffic but requires at least one refresh before the LSA expires. The OSPF flooding reduction solution works by reducing unnecessary refreshing and flooding of already known and unchanged information. To achieve this reduction, the LSAs are now flooded with the higher bit set. The LSAs are now set as "do not age."

To reduce unnecessary refreshing and flooding of LSAs on your network, use the following command in interface configuration mode:

Command
Purpose

Router(config-if)# ip ospf flood-reduction

Suppresses the unnecessary flooding of LSAs in stable topologies.


Ignoring MOSPF LSA Packets

Cisco routers do not support LSA type 6 Multicast OSPF (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
Purpose

Router(config-router)# ignore lsa mospf

Prevents the router from generating syslog messages when it receives MOSPF LSA packets.


For an example of suppressing MOSPF LSA packets, see the " Ignore MOSPF LSA Packets Example" section.

Displaying OSPF Update Packet Pacing

The former OSPF implementation for sending update packets needed to be more efficient. Some update packets were getting lost in cases where the link was slow, a neighbor could not receive the updates quickly enough, or the router was out of buffer space. For example, packets might be dropped if either of the following topologies existed:

A fast router was connected to a slower router over a point-to-point link.

During flooding, several neighbors sent updates to a single router at the same time.

OSPF update packets are now automatically paced so they are not sent less than 33 milliseconds apart. Pacing is also added between resends to increase efficiency and minimize lost retransmissions. Also, you can display the LSAs waiting to be sent out an interface. The benefit of the pacing is that OSPF update and retransmission packets are sent more efficiently.

There are no configuration tasks for this feature; it occurs automatically.

To observe OSPF packet pacing by displaying a list of LSAs waiting to be flooded over a specified interface, use the following command in EXEC mode:

Command
Purpose

Router# show ip ospf flood-list interface-type interface-number

Displays a list of LSAs waiting to be flooded over an interface.


Monitoring and Maintaining 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 that your device packets are taking through the network.

To display various routing statistics, use the following commands in EXEC mode, as needed:

Command
Purpose

Router# show ip ospf [process-id]

Displays general information about OSPF routing processes.

Router# show ip ospf border-routers

Displays the internal OSPF routing table entries to the ABR and ASBR.

Router# show ip ospf [process-id [area-id]] database


Router# show ip ospf [process-id [area-id]] database [database-summary]


Router# show ip ospf [process-id [area-id]] database [router] [self-originate]


Router# show ip ospf [process-id [area-id]] database [router] [adv-router [ip-address]]


Router# show ip ospf [process-id [area-id]] database [router] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [network] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [summary] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [asbr-summary] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [external] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [nssa-external] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [opaque-link] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [opaque-area] [link-state-id]


Router# show ip ospf [process-id [area-id]] database [opaque-as] [link-state-id]

Displays lists of information related to the OSPF database.

Router# show ip ospf flood-list interface interface-type

Displays a list of LSAs waiting to be flooded over an interface (to observe OSPF packet pacing).

Router# show ip ospf interface [interface-type interface-number]

Displays OSPF-related interface information.

Router# show ip ospf neighbor [interface-name] [neighbor-id] detail

Displays OSPF neighbor information on a per-interface basis.

Router# show ip ospf request-list [neighbor] [interface] [interface-neighbor]

Displays a list of all LSAs requested by a router.

Router# show ip ospf retransmission-list [neighbor] [interface] [interface-neighbor]

Displays a list of all LSAs waiting to be resent.

Router# show ip ospf [process-id]summary-address

Displays a list of all summary address redistribution information configured under an OSPF process.

Router# show ip ospf virtual-links

Displays OSPF-related virtual links information.


To restart an OSPF process, use the following command in EXEC mode:

Command
Purpose

Router# clear ip ospf [pid] {process | redistribution | counters [neighbor [neighbor-interface] [neighbor-id]]}

Clears redistribution based on the OSPF routing process ID. If the pid option is not specified, all OSPF processes are cleared.


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 Example

LSA Group Pacing Example

Block LSA Flooding Example

Ignore MOSPF LSA Packets Example

OSPF Point-to-Multipoint Example

In Figure 13-8, the router named Mollie uses data-link connection identifier (DLCI) 201 to communicate with the router named Neon, DLCI 202 to the router named Jelly, and DLCI 203 to the router named 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 13-8 OSPF Point-to-Multipoint Example

Mollie 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 Configuration

hostname neon
!
interface serial 1/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 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 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 Serial1/0
 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 1/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 is as follows:

Router# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
4.1.1.1           1   FULL/  -        00:01:50    10.0.1.5        Serial1/0
3.1.1.1           1   FULL/  -        00:01:47    10.0.1.4        Serial1/0
2.1.1.1           1   FULL/  -        00:01:45    10.0.1.3        Serial1/0

The route information in the first configuration is as follows:

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, Serial1/0
C       10.0.1.0/24 is directly connected, Serial1/0
O       10.0.1.5/32 [110/5] via 10.0.1.5, 00:39:08, Serial1/0
O       10.0.1.4/32 [110/10] via 10.0.1.4, 00:39:08, Serial1/0

OSPF Point-to-Multipoint, Nonbroadcast Example

The following example illustrates a point-to-multipoint network with nonbroadcast:

interface Serial1/0
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 Serial1/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 is as follows:  

Router# show ip ospf neighbor
Neighbor   ID     Pri   State     Dead Time   Address         Interface
4.1.1.1          1       FULL/  -             00:01:52      10.0.1.5         Serial1/0
3.1.1.1          1       FULL/  -             00:01:52      10.0.1.4         Serial1/0
2.1.1.1          1       FULL/  -             00:01:52     10.0.1.3         Serial1/0

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 ethernet

interface serial 1/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, ABRs, and ASBRs. At a minimum, OSPF-based routers can be configured with all default parameter values, with no authentication, and with interfaces assigned to areas.

Three types of 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 Examples

The following example illustrates a simple OSPF configuration that enables OSPF routing process 9000, attaches Ethernet interface 0 to area 0.0.0.0, and redistributes RIP into OSPF, and OSPF into RIP:

interface ethernet 0
 ip address 10.93.1.1 255.255.255.0
 ip ospf cost 1
!
interface ethernet 1
 ip address 10.94.1.1 255.255.255.0
!
router ospf 9000
 network 10.93.0.0 0.0.255.255 area 0.0.0.0
 redistribute rip metric 1 subnets
!
router rip
 network 10.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, and 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 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 Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols publication 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 Ethernet interface 0. Ethernet interface 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 Ethernet interface 0). Assume that a match is determined for interface Ethernet 1. OSPF is then enabled for that interface and Ethernet interface 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. Figure 13-9 provides a general network map that illustrates this example configuration.

Figure 13-9 Sample OSPF Autonomous System Network Map

In this configuration, five routers are configured in OSPF autonomous system 109:

Router A and Router B are both internal routers within area 1.

Router C is an OSPF ABR. 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 ASBR. Note that BGP routes are redistributed into OSPF and that these routes are advertised by OSPF. Further that the Cisco 3200 Series router does not support BGP.


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 ABR (Router C) injects summary LSAs into area 1.


Autonomous system 109 is connected to the outside world via the BGP link to the external peer at IP address 11.0.0.6. Example configurations follow.

Following is the sample configuration for the general network map shown in Figure 13-9.

Router A Configuration—Internal Router

interface ethernet 1
 ip address 131.108.1.1 255.255.255.0

router ospf 109
 network 131.108.0.0 0.0.255.255 area 1

Router B Configuration—Internal Router

interface ethernet 2
 ip address 131.108.1.2 255.255.255.0

router ospf 109
 network 131.108.0.0 0.0.255.255 area 1

Router C Configuration—ABR

interface ethernet 3
 ip address 131.108.1.3 255.255.255.0

interface serial 1/0
 ip address 131.108.2.3 255.255.255.0

router ospf 109
 network 131.108.1.0 0.0.0.255 area 1
 network 131.108.2.0 0.0.0.255 area 0

Router D Configuration—Internal 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 109
 network 131.108.2.0 0.0.0.255 area 0
 network 10.0.0.0 0.255.255.255 area 0

Router E Configuration—ASBR

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 109
 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. Figure 13-10 illustrates the network address ranges and area assignments for the interfaces.

Figure 13-10 Interface and Area Specifications for OSPF Example Configuration

The basic configuration tasks in this example are as follows:

Configure address ranges for Ethernet interface 0 through Ethernet interface 3.

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 RIP into OSPF with various options set (including metric-type, metric, tag, and subnet).

Redistribute OSPF into RIP.

The following is an example OSPF configuration:

interface ethernet 0/0
 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

In the following configuration 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 rip metric-type 2 metric 1 tag 200

Route Map Examples

The examples in this section illustrate the use of redistribution, with and without route maps. Examples from both the IP and Connectionless Network Service (CLNS) routing protocols are given.

The following example redistributes RIP routes with a hop count equal to 1 into OSPF. These routes will be redistributed into OSPF as external LSAs with a metric of 5, a 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 1/0
 set metric 5

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 example illustrates how a route map is referenced by the default-information router configuration command. This type of reference 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 is in the routing table.

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 Example

The following configuration changes the external distance to 200, making it less trustworthy. Figure 13-11 illustrates the example.

Figure 13-11 OSPF Administrative Distance

Router A Configuration

router ospf 1
 redistribute ospf 2 subnet
 distance ospf external 200
!
router ospf 2
 redistribute ospf 1 subnet
 distance ospf external 200

Router B Configuration

router ospf 1
 redistribute ospf 2 subnet
 distance ospf external 200
!
router ospf 2
 redistribute ospf 1 subnet
 distance ospf external 200

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
 ignore lsa mospf