and the Alcatel-Lucent logo are registered trademarks of Alcatel-Lucent. Xylan®,
®
, OmniStack®, and Alcatel-Lucent OmniVista® are registered trademarks of Alcatel-Lucent.
OmniAccess™, Omni Switch/Router™, PolicyView™, RouterView™, SwitchManager™, VoiceView™,
WebView™, X-Cell™, X-Vision™, and the Xylan logo are trademarks of Alcatel-Lucent.
This OmniSwitch product contains components which may be covered by one or more of the following
U.S. Patents:
This OmniSwitch 6800/6850/9000 Advanced Routing Configuration Guide describes how to set up and
monitor advanced routing protocols for operation in a live network environment. The routing protocols
described in this manual are purchased as an add-on package to the base switch software.
Supported Platforms
This information in this guide applies to the following products:
• OmniSwitch 6800 Series (with Kadvrout.img file installed)
• OmniSwitch 6850 Series (with Kadvrout.img file installed)
Note. This OmniSwitch CLI Reference Guide covers Release 6.3.1, which is supported on the OmniSwitch
6800 Series, OmniSwitch 6850 Series, and OmniSwitch 9000 Series switches. OmniSwitch 6600 Family,
OmniSwitch 7700/7800, and OmniSwitch 8800 switches use Release 5.x. Please refer to the 5.x user
guides for those switches.
Unsupported Platforms
The information in this guide does not apply to the following products:
• OmniSwitch (original version with no numeric model name)
The audience for this user guide is network administrators and IT support personnel who need to configure, maintain, and monitor switches and routers in a live network. However, anyone wishing to gain
knowledge on how advanced routing software features are implemented in the OmniSwitch 6800 Series,
OmniSwitch 6850 Series, and OmniSwitch 9000 Series switches will benefit from the material in this
configuration guide.
When Should I Read this Manual?
Read this guide as soon as you are ready to integrate your OmniSwitch into your network and you are
ready to set up advanced routing protocols. You should already be familiar with the basics of managing a
single OmniSwitch as described in the OmniSwitch 6800/6850/9000 Switch Management Guide.
The topics and procedures in this manual assume an understanding of the OmniSwitch directory structure
and basic switch administration commands and procedures. This manual will help you set up your
switches to route on the network using routing protocols, such as OSPF.
What is in this Manual?
This configuration guide includes information about configuring the following features:
The configuration procedures in this manual use Command Line Interface (CLI) commands in all examples. CLI commands are text-based commands used to manage the switch through serial (console port)
connections or via Telnet sessions. Procedures for other switch management methods, such as web-based
(WebView or OmniVista) or SNMP, are outside the scope of this guide.
For information on WebView and SNMP switch management methods consult the OmniSwitch 6800/6850/9000 Switch Management Guide. Information on using WebView and OmniVista can be found in the
context-sensitive on-line help available with those network management applications.
This guide provides overview material on software features, how-to procedures, and application examples
that will enable you to begin configuring your OmniSwitch. It is not intended as a comprehensive reference to all CLI commands available in the OmniSwitch. For such a reference to all OmniSwitch CLI
commands, consult the OmniSwitch CLI Reference Guide.
Chapters in this guide are broken down by software feature. The titles of each chapter include protocol or
feature names (e.g., OSPF, PIM-SM) with which most network professionals will be familiar.
Each software feature chapter includes sections that will satisfy the information requirements of casual
readers, rushed readers, serious detail-oriented readers, advanced users, and beginning users.
Quick Information. Most chapters include a specifications table that lists RFCs and IEEE specifications
supported by the software feature. In addition, this table includes other pertinent information such as minimum and maximum values and sub-feature support. Most chapters also include a defaults table that lists
the default values for important parameters along with the CLI command used to configure the parameter.
Many chapters include a Quick Steps section, which is a procedure covering the basic steps required to get
a software feature up and running.
In-Depth Information. All chapters include overview sections on the software feature as well as on
selected topics of that software feature. Topical sections may often lead into procedure sections that
describe how to configure the feature just described. Serious readers and advanced users will also find the
many application examples, located near the end of chapters, helpful. Application examples include
diagrams of real networks and then provide solutions using the CLI to configure a particular feature, or
more than one feature, within the illustrated network.
Documentation Roadmap
The OmniSwitch user documentation suite was designed to supply you with information at several critical
junctures of the configuration process. The following section outlines a roadmap of the manuals that will
help you at each stage of the configuration process. Under each stage, we point you to the manual or
manuals that will be most helpful to you.
Stage 1: Using the Switch for the First Time
Pertinent Documentation: Getting Started Guide
Release Notes
A hard-copy Getting Started Guide is included with your switch; this guide provides all the information
you need to get your switch up and running the first time. It provides information on unpacking the switch,
rack mounting the switch, installing NI modules, unlocking access control, setting the switch’s IP address,
and setting up a password. It also includes succinct overview information on fundamental aspects of the
switch, such as hardware LEDs, the software directory structure, CLI conventions, and web-based
management.
At this time you should also familiarize yourself with the Release Notes that accompanied your switch.
This document includes important information on feature limitations that are not included in other user
guides.
Stage 2: Gaining Familiarity with Basic Switch Functions
Pertinent Documentation: Hardware Users Guide
Switch Management Guide
Once you have your switch up and running, you will want to begin investigating basic aspects of its hardware and software. Information about switch hardware is provided in the Hardware Users Guide. This
guide provide specifications, illustrations, and descriptions of all hardware components, such as chassis,
power supplies, Chassis Management Modules (CMMs), Network Interface (NI) modules, and cooling
fans. It also includes steps for common procedures, such as removing and installing switch components.
The Switch Management Guide is the primary users guide for the basic software features on a single
switch. This guide contains information on the switch directory structure, basic file and directory utilities,
switch access security, SNMP, and web-based management. It is recommended that you read this guide
before connecting your switch to the network.
When you are ready to connect your switch to the network, you will need to learn how the OmniSwitch
implements fundamental software features, such as 802.1Q, VLANs, Spanning Tree, and network routing
protocols. The Network Configuration Guide contains overview information, procedures, and examples on
how standard networking technologies are configured in the OmniSwitch.
The Advanced Routing Configuration Guide includes configuration information for networks using
advanced routing technologies (OSPF and BGP) and multicast routing protocols (DVMRP and PIM-SM).
Anytime
The OmniSwitch CLI Reference Guide contains comprehensive information on all CLI commands
supported by the switch. This guide includes syntax, default, usage, example, related CLI command, and
CLI-to-MIB variable mapping information for all CLI commands supported by the switch. This guide can
be consulted anytime during the configuration process to find detailed and specific information on each
CLI command.
The following are the titles and descriptions of all the related OmniSwitch 6800/6850/9000 user manuals:
• OmniSwitch 6800 Series Getting Started Guide
Describes the hardware and software procedures for getting an OmniSwitch 6800 Series switch up and
running. Also provides information on fundamental aspects of OmniSwitch software and stacking
architecture.
• OmniSwitch 6850 Series Getting Started Guide
Describes the hardware and software procedures for getting an OmniSwitch 6850 Series switch up and
running. Also provides information on fundamental aspects of OmniSwitch software and stacking
architecture.
• OmniSwitch 6800 Series Hardware Users Guide
Detailed technical specifications and procedures for the OmniSwitch 6800 Series chassis and components. Also includes comprehensive information on assembling and managing stacked configurations.
• OmniSwitch 6850 Series Hardware User Guide
Complete technical specifications and procedures for all OmniSwitch 6850 Series chassis, power
supplies, and fans. Also includes comprehensive information on assembling and managing stacked
configurations.
• OmniSwitch 9000 Series Getting Started Guide
Describes the hardware and software procedures for getting an OmniSwitch 9000 Series up and
running. Also provides information on fundamental aspects of OmniSwitch software architecture.
• OmniSwitch 9000 Series Hardware Users Guide
Complete technical specifications and procedures for all OmniSwitch 9000 Series chassis, power
supplies, fans, and Network Interface (NI) modules.
• OmniSwitch CLI Reference Guide
Complete reference to all CLI commands supported on the OmniSwitch 6800, 6850, and 9000.
Includes syntax definitions, default values, examples, usage guidelines and CLI-to-MIB variable
mappings.
Includes procedures for readying an individual switch for integration into a network. Topics include
the software directory architecture, image rollback protections, authenticated switch access, managing
switch files, system configuration, using SNMP, and using web management software (WebView).
Includes network configuration procedures and descriptive information on all the major software
features and protocols included in the base software package. Chapters cover Layer 2 information
(Ethernet and VLAN configuration), Layer 3 information (routing protocols, such as RIP), security
options (authenticated VLANs), Quality of Service (QoS), and link aggregation.
Includes network configuration procedures and descriptive information on all the software features and
protocols included in the advanced routing software package. Chapters cover multicast routing
(DVMRP and PIM-SM), and OSPF.
• OmniSwitch Transceivers Guide
Includes information on Small Form Factor Pluggable (SFPs) and 10 Gbps Small Form Factor Pluggables (XFPs) transceivers.
• Technical Tips, Field Notices
Includes information published by Alcatel-Lucent’s Customer Support group.
• Release Notes
Includes critical Open Problem Reports, feature exceptions, and other important information on the
features supported in the current release and any limitations to their support.
All user guides are included on the User Manual CD that accompanied your switch. This CD also includes
user guides for other Alcatel-Lucent data enterprise products. In addition, it contains a stand-alone version
of the on-line help system that is embedded in the OmniVista network management application.
Besides the OmniVista documentation, all documentation on the User Manual CD is in
requires the Adobe Acrobat Reader program for viewing. Acrobat Reader freeware is available at
www.adobe.com.
Note. In order to take advantage of the documentation CD’s global search feature, it is recommended that
you select the option for searching PDF files before downloading Acrobat Reader freeware.
To verify that you are using Acrobat Reader with the global search option, look for the following button in
the toolbar:
Note. When printing pages from the documentation PDFs, de-select Fit to Page if it is selected in your
print dialog. Otherwise pages may print with slightly smaller margins.
PDF format and
Technical Support
An Alcatel-Lucent service agreement brings your company the assurance of 7x24 no-excuses technical
support. You’ll also receive regular software updates to maintain and maximize your Alcatel-Lucent product’s features and functionality and on-site hardware replacement through our global network of highly
qualified service delivery partners. Additionally, with 24-hour-a-day access to Alcatel-Lucent’s Service
and Support web page, you’ll be able to view and update any case (open or closed) that you have reported
to Alcatel-Lucent’s technical support, open a new case or access helpful release notes, technical bulletins,
and manuals. For more information on Alcatel-Lucent’s Service Programs, see our web page at
service.esd.alcatel-lucent.com, call us at 1-800-995-2696, or email us at support@ind.alcatel.com.
Open Shortest Path First routing (OSPF) is a shortest path first (SPF), or link state, protocol. OSPF is an
interior gateway protocol (IGP) that distributes routing information between routers in a single Autonomous System (AS). OSPF chooses the least-cost path as the best path. OSPF is suitable for complex
networks with large numbers of routers since it provides faster convergence where multiple flows to a
single destination can be forwarded on one or more interfaces simultaneously.
In This Chapter
This chapter describes the basic components of OSPF and how to configure them through the Command
Line Interface (CLI). CLI commands are used in the configuration examples; for more details about the
syntax of commands, see the OmniSwitch CLI Reference Guide.
Configuration procedures described in this chapter include:
• Loading and enabling OSPF (see page 1-16).
• Creating OSPF areas (see page 1-17).
• Creating OSPF interfaces (see page 1-20).
• Creating virtual links (see page 1-22).
• Configuring redistribution using route maps (see page 1-23).
For information on creating and managing VLANs, see “Configuring VLANs” in the OmniSwitch 6800/
6850/9000 Network Configuration Guide.
RFCs Supported1370—Applicability Statement for OSPF
1850—OSPF Version 2 Management Information
Base
2328—OSPF Version 2
2370—The OSPF Opaque LSA Option
3101—The OSPF Not-So-Stubby Area (NSSA)
Option
3623—Graceful OSPF Restart
Maximum number of Areas (per router)32
Maximum number of Interfaces (per router) 3200
Maximum number of Interfaces (per area)100
Maximum number of Link State Database
entries (per router)
Maximum number of adjacencies (per
router)
Maximum number of adjacencies (per area) 128
Maximum number of ECMP gateways (per
destination)
Maximum number of neighbors (per router) 64
Maximum number of routes (per router)96K (Depending on the number of interfaces/
The followings steps are designed to show the user the necessary set of commands for setting up a router
to use OSPF:
1 Create a VLAN using the vlan command. For example:
-> vlan 5
-> vlan 5 enable
2 Assign a router IP address and subnet mask to the VLAN using the ip interface command. For exam-
ple:
-> ip interface vlan-5 vlan 5 address 120.1.4.1 mask 255.0.0.0
3 Assign a port to the created VLANs using the vlan command. For example:
-> vlan 5 port default 2/1
Note. The port will be statically assigned to the VLAN, as a VLAN must have a physical port assigned to
it in order for the router port to function. However, the router could be set up in such a way that mobile
ports are dynamically assigned to VLANs using VLAN rules. See the chapter titled “Defining VLAN
Rules” in the OmniSwitch 6800/6850/9000 Network Configuration Guide.
4 Assign a router ID to the router using the ip router router-id command. For example:
-> ip router router-id 1.1.1.1
5 Load and enable OSPF using the ip load ospf and the ip ospf status commands. For example:
-> ip load ospf
-> ip ospf status enable
6 Create a backbone to connect this router to others, and an area for the router’s traffic, using the ip ospf
area command. (Backbones are always labeled area 0.0.0.0.) For example:
7 Create an OSPF interface for each VLAN created in Step 1, using the ip ospf interface command. The
OSPF interface should use the same interface name used for the VLAN router IP created in Step 2. For
example:
-> ip ospf interface vlan-5
Note. The interface name cannot have spaces.
8 Assign the OSPF interface to the area and the backbone using the ip ospf interface area command.
For example:
-> ip ospf interface vlan-5 area 0.0.0.0
9 Enable the OSPF interfaces using the ip ospf interface status command. For example:
-> ip ospf interface vlan-5 status enable
10 You can now display the router OSPF settings by using the show ip ospf command. The output gener-
ated is similar to the following:
-> show ip ospf
Router Id = 1.1.1.1,
OSPF Version Number = 2,
Admin Status = Enabled,
Area Border Router? = Yes,
AS Border Router Status = Disabled,
Route Redistribution Status = Disabled,
Route Tag = 0,
SPF Hold Time (in seconds) = 10,
SPF Delay Time (in seconds) = 5,
MTU Checking = Disabled,
# of Routes = 0,
# of AS-External LSAs = 0,
# of self-originated LSAs = 0,
# of LSAs received = 0,
External LSDB Limit = -1,
Exit Overflow Interval = 0,
# of SPF calculations done = 1,
# of Incr SPF calculations done = 0,
# of Init State Nbrs = 0,
# of 2-Way State Nbrs = 0,
# of Exchange State Nbrs = 0,
# of Full State Nbrs = 0,
# of attached areas = 2,
# of Active areas = 2,
# of Transit areas = 0,
# of attached NSSAs = 0
11 You can display OSPF area settings using the show ip ospf area command. For example:
-> show ip ospf area 0.0.0.0
Area Identifier = 0.0.0.0,
Admin Status = Enabled,
Operational Status = Up,
Area Type = normal,
Area Summary = Enabled,
Time since last SPF Run = 00h:08m:37s,
# of Area Border Routers known = 1,
# of AS Border Routers known = 0,
# of LSAs in area = 1,
# of SPF Calculations done = 1,
# of Incremental SPF Calculations done = 0,
# of Neighbors in Init State = 0,
# of Neighbors in 2-Way State = 0,
# of Neighbors in Exchange State = 0,
# of Neighbors in Full State = 0,
# of Interfaces attached = 1
Area ID
As set in Step 6
12 You can display OSPF interface settings using the show ip ospf interface command. For example:
-> show ip ospf interface vlan-5
Interface IP Name = vlan-3
VLAN Id = 5,
Interface IP Address = 120.1.4.1,
Interface IP Mask = 255.0.0.0,
Admin Status = Enabled,
Operational Status = Down,
OSPF Interface State = Down,
Interface Type = Broadcast,
Area Id = 0.0.0.0,
Designated Router IP Address = 0.0.0.0,
Designated Router RouterId = 0.0.0.0,
Backup Designated Router IP Address = 0.0.0.0,
Backup Designated Router RouterId = 0.0.0.0,
MTU (bytes) = 1500,
Metric Cost = 1,
Priority = 1,
Hello Interval (seconds) = 10,
Transit Delay (seconds) = 1,
Retrans Interval (seconds) = 5,
Dead Interval (seconds) = 40,
Poll Interval (seconds) = 120,
Link Type = Broadcast,
Authentication Type = simple,
Authentication Key = Set,
# of Events = 0,
# of Init State Neighbors = 0,
# of 2-Way State Neighbors = 0,
# of Exchange State Neighbors = 0,
# of Full State Neighbors = 0
Open Shortest Path First routing (OSPF) is a shortest path first (SPF), or link-state, protocol. OSPF is an
interior gateway protocol (IGP) that distributes routing information between routers in a Single Autonomous System (AS). OSPF chooses the least-cost path as the best path.
Each participating router distributes its local state (i.e., the router’s usable interfaces, local networks, and
reachable neighbors) throughout the AS by flooding. In a link-state protocol, each router maintains a database describing the entire topology. This database is built from the collected link state advertisements of
all routers. Each multi-access network that has at least two attached routers has a designated router and a
backup designated router. The designated router floods a link state advertisement for the multi-access
network.
When a router starts, it uses the OSPF Hello Protocol to discover neighbors. The router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the
router dynamically detects its neighboring routers by sending Hello packets to a multicast address. On
non-broadcast and point-to-multipoint networks, some configuration information is necessary in order to
configure neighbors. On all networks (broadcast or non-broadcast), the Hello Protocol also elects a designated router for the network.
Hello. Please respond...
Are you a neighbor...
My link state is...
Hello. Please respond...
Are you a neighbor...
My link state is...
OSPF Hello Protocol
The router will attempt to form full adjacencies with all of its newly acquired neighbors. Only some pairs,
however, will be successful in forming full adjacencies. Topological databases are synchronized between
pairs of fully adjacent routers.
Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and
received only on adjacencies. In particular, distribution of topological database updates proceeds along
adjacencies.
Link state is also advertised when a router’s state changes. A router’s adjacencies are reflected in the
contents of its link state advertisements. This relationship between adjacencies and link state allows the
protocol to detect downed routers in a timely fashion.
Link state advertisements are flooded throughout the AS. The flooding algorithm ensures that all routers
have exactly the same topological database. This database consists of the collection of link state advertisements received from each router belonging to the area. From this database each router calculates a shortest-path tree, with itself as root. This shortest-path tree in turn yields a routing table for the protocol.
OSPF allows collections of contiguous networks and hosts to be grouped together as an area. Each area
runs a separate copy of the basic link-state routing algorithm (usually called SPF). This means that each
area has its own topological database, as explained in the previous section.
Inter-Area Routing
Intra-Area
Routing
Router 1
Link State
Messages
Router 2
Area 1
Backbone
Area 2
Intra-Area
Routing
Router 3
Link State
Messages
Router 4
OSPF Intra-Area and Inter-Area Routing
An area’s topology is visible only to the members of the area. Conversely, routers internal to a given area
know nothing of the detailed topology external to the area. This isolation of knowledge enables the protocol to reduce routing traffic by concentrating on small areas of an AS, as compared to treating the entire
AS as a single link-state domain.
Areas cause routers to maintain a separate topological database for each area to which they are connected.
(Routers connected to multiple areas are called area border routers). Two routers belonging to the same
area have identical area topological databases.
Different areas communicate with each other through a backbone. The backbone consists of routers with
contacts between multiple areas. A backbone must be contiguous (i.e., it must be linked to all areas).
The backbone is responsible for distributing routing information between areas. The backbone itself has all
of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas.
All routers in an area must agree on that area’s parameters. Since a separate copy of the link-state algorithm is run in each area, most configuration parameters are defined on a per-router basis. All routers
belonging to an area must agree on that area’s configuration. Misconfiguration will keep neighbors from
forming adjacencies between themselves, and OSPF will not function.
When an AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories:
• Internal routers. A router with all directly connected networks belonging to the same area. These
routers run a single copy of the SPF algorithm.
• Area border routers. A router that attaches to multiple areas. Area border routers run multiple copies
of the SPF algorithm, one copy for each attached area. Area border routers condense the topological
information of their attached areas for flooding to other areas.
• Backbone routers. A router that has an interface to the backbone. This includes all routers that inter-
face to more than one area (i.e., area border routers). However, backbone routers do not have to be area
border routers. Routers with all interfaces connected to the backbone are considered to be internal routers.
• AS boundary routers. A router that exchanges routing information with routers belonging to other
Autonomous Systems. Such a router has AS external routes that are advertised throughout the Autonomous System. The path to each AS boundary router is known by every router in the AS. This classification is completely independent of the previous classifications (i.e., internal, area border, and
backbone routers). AS boundary routers may be internal or area border routers, and may or may not
participate in the backbone.
Virtual Links
It is possible to define areas in such a way that the backbone is no longer contiguous. (This is not an ideal
OSPF configuration, and maximum effort should be made to avoid this situation.) In this case the system
administrator must restore backbone connectivity by configuring virtual links.
Virtual links can be configured between any two backbone routers that have a connection to a common
non-backbone area. The protocol treats two routers joined by a virtual link as if they were connected by an
unnumbered point-to-point network. The routing protocol traffic that flows along the virtual link uses
intra-area routing only, and the physical connection between the two routers is not managed by the
network administrator (i.e., there is no dedicated connection between the routers as there is with the OSPF
backbone).
Router B
Backbone
Backbone
Router A
Area 1
Virtual Link
OSPF Routers Connected with a Virtual Link
In the above diagram, Router A and Router B are connected via a virtual link in Area 1, which is known as
a transit area. See “Creating Virtual Links” on page 1-22 for more information.
OSPF allows certain areas to be configured as stub areas. A stub area is an area with routers that have no
AS external Link State Advertisements (LSAs).
In order to take advantage of the OSPF stub area support, default routing must be used in the stub area.
This is accomplished by configuring only one of the stub area’s border routers to advertise a default route
into the stub area. The default routes will match any destination that is not explicitly reachable by an intraarea or inter-area path (i.e., AS external destinations).
Backbone
Backbone
Area 1
(stub)
Area 2
Area 3
(stub)
OSPF Stub Area
Area 1 and Area 3 could be configured as stub areas. Stub areas are configured using the OSPF ip ospf area
command, described in “Creating an Area” on page 1-17. For more overview information on areas, see “OSPF
Areas” on page 1-8.
The OSPF protocol ensures that all routers belonging to an area agree on whether the area has been configured as a stub. This guarantees that no confusion will arise in the flooding of AS external advertisements.
Two restrictions on the use of stub areas are:
• Virtual links cannot be configured through stub areas.
• AS boundary routers cannot be placed internal to stub areas.
NSSA, or not-so-stubby area, is an extension to the base OSPF specification and is defined in RFC 1587.
An NSSA is similar to a stub area in many ways: AS-external LSAs are not flooded into an NSSA and
virtual links are not allowed in an NSSA. The primary difference is that selected external routing information can be imported into an NSSA and then redistributed into the rest of the OSPF routing domain. These
routes are imported into the NSSA using a new LSA type: Type-7 LSA. Type-7 LSAs are flooded within
the NSSA and are translated at the NSSA boundary into AS-external LSAs so as to convey the external
routing information to other areas.
NSSAs enable routers with limited resources to participate in OSPF routing while also allowing the import
of a selected number of external routes into the area. For example, an area which connects to a small
external routing domain running RIP may be configured as an NSSA. This will allow the import of RIP
routes into this area and the rest of the OSPF routing domain and at the same time, prevent the flooding of
other external routing information (learned, for example, through RIP) into this area.
All routers in an NSSA must have their OSPF area defined as an NSSA. To configure otherwise will
ensure that the router will be unsuccessful in establishing an adjacent in the OSPF domain.
Totally Stubby Areas
In Totally Stubby Areas the ABR advertises a default route to the routers in the totally stubby area but
does not advertise any inter-area or external LSAs. As a result, routers in a totally stubby area know only
the routes for destination networks in the stub area and have a default route for any other destination
outside the stub.
Note. Virtual links cannot be configured through totally stubby areas.
The router memory is saved when using stub area networks by filtering Type 4 and 5 LSAs. This concept
has been extended with Totally Stubby Areas by filtering Type 3 LSAs (Network Summary LSA) in addition to Type 4 and 5 with the exception of one single Type 3 LSA used to advertise a default route within
the area.
The following is an example of a simple totally stubby configuration with Router B being an ABR
between the backbone area 0 and the stub area 1. Router A is in area 1.1.1.1, totally stubby area:
OSPF Area 0
192.168.50.0/24
192.168.12.1
Router ARouter B
OSPF Area 1
Totally Stubby
192.168.12.2
Totally Stubby Area Example
Note. See “Configuring a Totally Stubby Area” on page 1-19 for information on configuring Totally
Using information from its continuously updated databases, OSPF calculates the shortest path to a given
destination. Shortest path is determined from metric values at each hop along a path. At times, two or more
paths to the same destination will have the same metric cost.
In the network illustration below, there are two paths from Source router A to Destination router B. One
path traverses two hops at routers X and Y and the second path traverses two hops at M and N. If the total
cost through X and Y to B is the same as the cost via M and N to B, then these two paths have equal cost.
In this version of OSPF both paths will be stored and used to transmit data.
XY
A-> X-> Y-> B = A-> M-> N-> B
Source (A)Destination (B)
MN
Multiple Equal Cost Paths
Delivery of packets along equal paths is based on flows rather than a round-robin scheme. Equal cost is
determined based on standard routing metrics. However, other variables, such as line speed, are not
considered. So it is possible for OSPF to decide two paths have an equal cost even though one may contain
faster links than another.
Non Broadcast OSPF Routing
OSPF can operate in two modes on non-broadcast networks: NBMA and point-to-multipoint. The interface type for the corresponding network segment should be set to non-broadcast or point-to-multipoint,
respectively.
For non-broadcast networks neighbors should be statically configured. For NBMA neighbors the eligibility option must be enabled for the neighboring router to participate in Designated Router (DR) election.
For the correct working of an OSPF NBMA network, a fully meshed network is mandatory. Also, the
neighbor eligibility configuration for a router on every other router should match the routers interface
priority configuration.
See “Configuring Static Neighbors” on page 1-31 for more information and setting up static neighbors.