Legal Notice

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS

DOCUMENT ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE
ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY
PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT
ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND
ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE
SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE
FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the
University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating
system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND

SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND
THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL,
CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST
PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE
THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco
WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We
Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS,
Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco,
the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems
Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch,
Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace,
MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX,
PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest
Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks
of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners.
The use of the word partner does not imply a partnership relationship between Cisco and any other
company.

Copyright © 2008 Cisco Systems, Inc. All rights reserved.

Cisco Systems Advanced Services

OSPF Best Practices

Version 2.0

Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
 Contents

Contents............................................................................................................................................ 2

Introduction ...................................................................................................................................... 5

Objective ...................................................................................................................................... 5
Scope ........................................................................................................................................... 5
Audience ...................................................................................................................................... 5

Contributions and Acknowledgements ......................................................................................... 6

Best Practice Summary Topics ...................................................................................................... 7

Summarization Techniques ............................................................................................................ 8

Best Practice Summary.............................................................................................................. 8

Best Practice Detail Explanation ............................................................................................... 8

Type 3 LSA filtering ....................................................................................................................... 14

Best Practice Summary............................................................................................................ 14

Best Practice Detail Explanation ............................................................................................. 14

External Routes.............................................................................................................................. 16

Best Practice Summary............................................................................................................ 16

Best Practice Detail Explanation ............................................................................................. 16

Use of Stub Areas .......................................................................................................................... 17

Best Practice Summary............................................................................................................ 18

Best Practice Detail Explanation ............................................................................................. 18

Redistribution Between Multiple Process ................................................................................... 21

Best Practice Summary............................................................................................................ 21

Best Practice Detail Explanation ............................................................................................. 21

Router ID ......................................................................................................................................... 23

Best Practice Summary............................................................................................................ 23

Best Practice Detail Explanation ............................................................................................. 23

December 18, 2007 OSPF Best Practices 2

 Process ID....................................................................................................................................... 25

Best Practice Summary............................................................................................................ 25

Authentication ................................................................................................................................ 26

Best Practice Summary............................................................................................................ 26

Best Practice Detail Explanation ............................................................................................. 26

OSPF Over Multi-Access Links..................................................................................................... 27

Best Practice Summary............................................................................................................ 27

OSPF Over WAN............................................................................................................................. 28

Non-Broadcast Multi-Access Mode..................................................................................................... 28

Broadcast Mode ................................................................................................................................... 28
Point-to-Point Mode............................................................................................................................. 29
Point-to-Multipoint Mode .................................................................................................................... 29
Best Practice Summary............................................................................................................ 29

OSPF and Full mesh ...................................................................................................................... 32

Best Practice Summary............................................................................................................ 32

Best Practice detail Explanations ........................................................................................... 32

OSPF over hub and spoke ............................................................................................................ 34

Best Practice Summary............................................................................................................ 34

Best Practice detail Explanations ........................................................................................... 34

IP Addressing ................................................................................................................................. 35

Best Practice Summary............................................................................................................ 35

OSPF Backbone Area .................................................................................................................... 36

Best Practice Summary............................................................................................................ 36

OSPF Cost....................................................................................................................................... 37

Best Practice Summary............................................................................................................ 37

Passive Interface............................................................................................................................ 38

Best Practice Summary............................................................................................................ 38

Load Balancing .............................................................................................................................. 39

Best Practice Summary............................................................................................................ 39

December 18, 2007 OSPF Best Practices 3

 OSPF Graceful Shutdown/Restart................................................................................................ 40

Best Practice Summary............................................................................................................ 40

Best Practice Detail Explanation ............................................................................................. 40

OSPF Through GRE Tunnels ........................................................................................................ 42

Best Practice Summary............................................................................................................ 42

Best Practice Detail Explanation ............................................................................................. 42
Connecting Remote Offices through Internet ...................................................................................... 42
Connecting ABRs Through GRE Tunnel For Intra-area Connectivity ................................................ 43

OSPF Flood Reduction .................................................................................................................. 46

Best Practice Summary............................................................................................................ 46

Best Practice Detail Explanation ............................................................................................. 46

December 18, 2007 OSPF Best Practices 4

 Introduction

Routing protocol design and implementation are generally mature fields, and a good amount of
documentation is available both within and external to Cisco on this topic. Our experience within the
Routing VT pointed to the fact that Cisco’s (especially Advanced Service’s) best practices for routing
protocols implementations are not being captured in one document.
In an effort to address this issue, the Routing VT worked as a team to capture routing protocols deployment
best practices, and provide a way to dynamically update and add to them. This document represents one
phase of this project, capturing best practices for deploying the Open Shortest Path First (OSPF) protocol.
Readers should be familiar with basic routing and experienced in configuring Cisco routers. No attempt is
made to explain and clarify low level functionality, although some examples are provided to help understand
the recommendation in question.
Throughout the document, best practices are given on each OSPF topic with an introduction on the features,
followed by Best Practices bullet points in a text box and then detailed explanations on the Best Practices.
For easy reference, Best Practices are in a box to clearly separate recommendations from explanations.
Disclaimer
This is version 2.0 which is the third released version. This version includes modifications to the previous
version’s (ver 1.0 and 1.5) content and a few new topics. The future versions of the document will contain
more extensive best practices.

Objective
The objective of this document is to:
• Provide comprehensive industry best practices for the Routing Protocols used on Cisco Routers.
• Provide a medium to track and continuously update the technology best practices to ensure the collective
technical experience of Advanced Services Routing VT is recorded, reviewed and updated. In other
words, provide a platform for converting AS expertise to Cisco Intellectual Property.

Scope
• Routing Best Practices for Design, Implementation, Optimization, Planning, Migration, Case Studies
New Features and Caveats

Audience
• This document is for NCEs in Advanced Services, Other Cisco Technical Teams and Cisco Partners and
Customers.
• Advanced Services Tools Team for automation of Best Practices Compliance

December 18, 2007 OSPF Best Practices 5

 Contributions and Acknowledgements

This document was intended to be a team effort. The following members contributed to the completion of
different versions of this document:
Version 1.0
Member Name Role
Senthil Palanisamy Project Lead and Contributor
John Samson, Yadhu Govindarajan, Jaswant Singh Contributors
Sina Mirtorabi Contributor and Reviewer

Sandeep Dhingra Initial idea, contribution and Direction

Version 1.5
Member Name Role
Senthil Palanisamy Project Lead and Contributor
Sina Mirtorabi, Shyan Wignarajah Reviewers

Version 2.0
Member Name Role
Faraz Shamim Project Lead , Contributor and Reviewer
Prashant Shukla Contributor
Senthil Palanisamy Reviewer

In addition to the names mentioned above, Cisco internal web pages, CCO web pages and various Cisco
internal news group archives have been referred, to gather information. Also many users of version 1.0 and
1.5 of this document provided valuable feedback and comments for improvement which are included in the
later versions.

December 18, 2007 OSPF Best Practices 6

 Best Practice Summary Topics

The following topics are covered in this version of the document:

• Summarization Techniques
• Type 3 LSA filtering
• External Routes
• Use of Stub and NSSA area
• Redistribution
• Mutual Redistribution at Single point
• Mutual Redistribution at more than one point:
• Router ID
• Process ID
• Authentication
• OSPF over multi-access link
• OSPF over WAN
• OSPF and Full mesh
• OSPF over Hub and spoke
• IP Addressing
• OSPF backbone area
• OSPF cost
• Passive interface
• Load balancing
• OSPF Graceful Shutdown/Restart
• OSPF Through GRE Tunnels
• OSPF Flood reduction
 Summarization Techniques

OSPF is a link state protocol; routers in an OSPF domain flood the status of each of their connected links state
throughout the domain, which is used by each router to build and maintain a link state database. The topology
of the network is derived from this link state database.
Routing (or flooding) domains are broken up in an OSPF network by dividing the network into areas, with
Area Border Routers (ABRs) providing the ability to route (forward traffic) between two flooding domains. In
order to provide consistent routing throughout an OSPF network, OSPF requires all areas to connect to a
central area, called the backbone, or Area 0. Topology summarization always occurs at a flooding domain
border (ABR), since all destinations are advertised by the ABR as if they are directly connected to the ABR.
Any information about the internal topology of the area is removed from the information transmitted between
areas.
OSPF forces hierarchy within the domain requiring every area connects to Area 0. If the addressing is carefully
allocated within areas attached to Area 0, they can be easily summarized at the ABRs. Address (reachability)
summarization plays a critical role in network scaling by reducing the OSPF database and routing table sizes
and isolating instability within an area.

Best Practice Summary

• Summarizing intra-area routes is recommended in most cases.
• If an area has multiple ABRs, then the summarization for the same range of routes should be
configured on all the ABRs in the area.
• Since summarization for the same range of addresses on multiple ABRs in some topologies
(typically hub and spoke topologies) can, in some situations, cause routing black holes it is
generally best to have at least one link between two ABRs summarizing the same address
space within the non-backbone area.
• Make sure that the ‘null 0’ route (discard route) is installed for the summarized address
ranges to avoid routing loops in some scenarios.
• It is preferable to set manually the cost of the summary route, or use a loopback interface in
the summarized IP address range to prevent the summary cost from changing due to network
changes within the area.
• Having more than one ABR for areas is recommended for redundancy.
• Keep the number of ABRs for an area reasonable (2 –4) in order to limit the number of
summary LSAs within the domain.
• If a normal OSPF Area needs to know only selective summary LSA from other Areas and
not all the summary LSAs, then configure LSA type 3 filtering at the ABRs.

Best Practice Detail Explanation

• If an area is connected through multiple ABRs to the backbone, the same range of addresses need to be
summarized from all the ABRs in an area. Otherwise, the ABRs that do not summarize routes will inject
more specific routes towards the backbone. This would lead to asymmetric routing and also the purpose of
summarization would be defeated. This situation not only applies to the non-backbone Areas, but also for

December 18, 2007 OSPF Best Practices 8

 the Area0 routes summarized towards the non-backbone Areas. Having said that, there may be situations
where it can be used for optimal routing with backup path. For example, consider the case where we have
two hub locations, and each one has specific services/servers within the hub, but they can also reach each
other over a high speed link between them. We might want to be able to direct the traffic specifically to the
right hub site for some services, but still have a default route (or summarized route) for reaching everything
in case the other link fails. This could apply in the other direction too, where we are summarizing from
non-backbone Areas towards the core of the network. The key point to be noted here is that we should be
aware of the effect of summarization when we have more than one ABR.
• By default OSPF installs a discard route (route to null0 with an administrative distance of 5) for the
‘summarized route’ whenever an ABR summarizes the more specific routes using “area...range” command.
This is the default behavior from Cisco IOS version 12.1.6 and onwards. Previous versions of Cisco IOS do
not install this ‘null 0’ or ‘discard route’ for the summary route. So, with older software versions (Before
12.1.6), this ‘discard route’ needs to be configured manually for each summary route. CSCdk72879.
Note: From Cisco IOS version 12.1.6 onwards, by default a ‘null 0‘or ‘discard route’ is installed whenever
routes are summarized at the ABR using “area…range” command. This behavior can be changed by
configuring no discard-route internal under OSPF configuration. Please note this behavior is only for
summarizing the OSPF internal routes using ‘area…range” command in pre-12.1.6 versions. Discard route is
always installed for summarizing ‘external routes’ at an ASBR in all versions of Cisco IOS.
In the network illustrated below, Router A is summarizing the specific routes in Area 10 towards the backbone
as a single summarized route 10.10.0.0/16. But, there is no ‘discard route’ or ‘null 0’ route installed for the
summary route 10.10.0.0/16 in its routing table. Router B generates a default-route and sends it to the rest of
the OSPF domain. Router A now has the default-route pointing towards Router B.

Figure 1 Example of Routing Loop Scenario without the Discard Route

December 18, 2007 OSPF Best Practices 9

 • Assume the 10.10.1.0/24 segment fails. If a packet arrives at Router B with a destination of 10.10.1.1,
Router B will forward the packet to Router A, because of the 10.10.0.0/16 summary route learned from
Router A.
When the packet reaches Router A, Router A doesn’t have a route to 10.l0.1.0/24 in its routing table, so it sends
the packet back to Router B following its default-route. Now the Router B sends the packet back to Router A,
because it receives the summary 10.10.0.0/16 from Router A and the process is repeated until the TTL value of
the packet is reduced to 0.
The discard route is critical to preventing this loop from occurring. If Router A had a discard route10.10.0.0/16
pointing to null 0 in the routing table, either by manual configuration or by the OSPF process, the loop could
have been avoided.
• It is common to have more than one ABR for redundancy and summarization configured for non-backbone
Areas and backbone Area. Generally the Area 0 will have multiple redundant paths with higher bandwidth
links. This may not be true for the non-backbone Areas. For example, if we take a hub and spoke topology,
where the small remote site offices are grouped on an OSPF non-backbone Area, the WAN link bandwidth
might be smaller compared to the backbone Area links. If address summarization is configured on all the
ABR routers, it is recommended to have a higher bandwidth transit link (within the non-backbone area)
between the ABRs to provide optimal path in case of certain failures. The following scenario best explains
one such a situation.
Consider a hub and spoke topology where the remote sites are dual homed to two ABRs (Hub Routers) for
redundancy, and the two ABRs are summarizing their intra-area routes towards the backbone. If one of the
ABRs loses connectivity to one of the remote sites in its area, its next best path to reach that specific remote
site is through a sub-optimal path as illustrated in the following figure.
In the figure, Router A and Router B are hub ABR routers connected to the Remote Site Routers Router C and
Router D in OSPF Area 1. Router A and Router B (ABRs) summarize the Area 1 address range 10.40.0.0/16
into Area 0. When one of the WAN links between Router A and Router C fails, Router A will install a route to
10.40.1.1 through Router D, which is learning the route through Router B. Thus, the traffic forwarded from
area 0 to Router A (to reach 10.40.1.1) will travel through Router D, Router B and then to Router C.

Figure 2 Sub-Optimal Routing without Intra-area Transit-Link between the ABRs

December 18, 2007 OSPF Best Practices 10

 The longer path may be undesirable in many situations. To avoid this issue, a transit link that belongs to Area 1
may be provided between the ABR routers Router A and Router B. This would result in an optimal path as
illustrated the following figure.
As illustrated in the following Figure, when the link between Router A and Router C fails, the next best path to
reach Router C from Router A is through Router B. The presence of a direct Area 1 transit link between both
ABRs (Router A and Router B) prevents traffic from taking the sub-optimal path through Router D as seen in
the previous scenario. ( In this example we assume that the OSPF Area 0 has enough redundant high
bandwidth links between ABRs and so there is no suboptimal path between ABRs in Area 0.)

December 18, 2007 OSPF Best Practices 11

 Figure 3 Optimal Routing with Intra-area Transit-link Between the ABRs

• By default, a summary route inherits the best metric (lowest cost) of the component routes of the summary.
This is in compliance with RFC 1583. This is the default behavior while summarizing the routes from one
Area into another. Giving no compatible rfc1583 command under OSPF would make the summarized
route to inherit the highest metric of the component routes covered by the summary. Irrespective of whether
the summary carries the highest metric or the lowest metric of the component routes, if that specific
component route changes, then the summary metric also changes. This might cause a routing change in the
Areas the summary is being advertised in to. To prevent this from happening, either the summary should
have a manually configured metric on the ABR, or a loopback interface with appropriate cost be configured
on the ABR so that the summary inherits the loopback interface’s cost. While summarizing routes with
multiple ABR, load balancing can also be achieved. If the network requirement is to loadbalance the traffic
while coming into specific area then this method is recommended. Figure 4 depicts such situation:

December 18, 2007 OSPF Best Practices 12

 Figure 4 Intelligent load balancing

Here one could summarize with the range 11.1/16 on both ABR1 and ABR2. The traffic could end up on any
ABR but with splitting the summary range into two blocks, 11.1.0/17 and 11.1.128/17, it will be able to load
balance the traffic and this way an intelligent form of loadbalancing can be achieved. On ABR1 11.1.0/17 is
configured with a cost of 30 and 11.1.128.0/17 is configured with a cost of 80. Similarly on ABR2, 11.1.0/17 is
configured with a cost of 80 and 11.1.128.0/17 is configured with a cost of 30. This means that whenever there
is a traffic destined to 11.1.0/17 range, it will always prefer ABR1 because of the cost of 30. For the range
11.1.128/17 , ABR2 will be preferred.

December 18, 2007 OSPF Best Practices 13

 Type 3 LSA filtering

There are some situations where an area can not be made stub or totally stub to reduce routes in an area. For
those situations LSA type 3 filtering can be used. LSA type 3 filtering will allow you to filter type 3 LSA
based on the prefix lists and only allow limited sets of routes into an area. Type 3 LSA filtering is a Cisco
proprietary feature and it can only be used if the ABR is a Cisco router.

Best Practice Summary

• If a normal OSPF Area needs to know only selective summary LSA from other Areas and not all
the summary LSAs, then configure LSA type 3 filtering at the ABRs.
• The Type -3 Filtering need to be configured on all the ABRs in an Area

Best Practice Detail Explanation

• Often there are situation where external routes needs to be injected into an area and area may not be
interested to know about every other area’s routes. Typically, to block other area routes, totally stub
area can be implemented but that will restrict the injections of any external LSA. To accommodate
this situation, an NSSA area can be defined but that will just make things complicated. Even with
NSSA, selective summary LSA from another Area can’t be injected into the NSSA Area. Either
NSSA permits all summary LSA from other areas or no summary route from other area ( in addition to
permitting the external routes in NSSA Area). So , in an Area where you need to permit external
LSAs and selelctive summary LSAs from other Areas we can use Type 3 LSA filtering and leak
selective type 3 routes that need to be known to the area.

December 18, 2007 OSPF Best Practices 14

 Figure 5 Type 3 LSA Filtering

Figure 5 shows how Type 3 LSA filtering works. It can be applied either inbound or outbound depending upon
the situation. In this example, area 0 is used with the filter-list but it can be applied with any other area as well.
The outbound filter means do not send any type 3 LSA into that area. The inbound filter means do not send
type 3 LSA outside that area into any other area. The advantage of this method is that you can always pick and
choose what prefix to deny or permit based on the access-list.

December 18, 2007 OSPF Best Practices 15

 External Routes

Routes redistributed into an OSPF process from any other routing protocol (including another OSPF process)
generate OSPF external routes that are propagated throughout the domain (except Stub and NSSA area) as
Type-5 LSAs. The router redistributing external prefix is called an ASBR (Autonomous System Border
Router).

Best Practice Summary

• Summarize externally learned routes at the redistribution point (ASBR) to reduce the external
LSAs where possible, since external LSAs are flooded throughout the OSPF domain.
• Avoid configuring redistribute connected under the OSPF routing process. Instead, use the
network statement under OSPF process and mark those interfaces as passive.
• If redistribution is required, limit it to as fewer routers as possible.

Best Practice Detail Explanation

• In a normal OSPF area, it is only possible to summarize redistributed routes at the ASBR where the
redistribution occurs. Summarizing these external routes at the redistribution point reduces the number of
Type-5 LSAs that need to be flooded throughout the domain. The metric of the summary is set to the lowest
metric within the component routes.
• If redistribution is required, then it is better to limit it to as fewer routers as possible. If there are many
ASBRs in an Area, then each will have a type 4 LSA generated at the ABR. These Type-4 LSAs are also
flooded throughout the OSPF domain.
• Redistributing connected networks into OSPF may be avoided unless otherwise it is the best suited
implementation for that network design. When redistributing connected networks, the router essentially
becomes an ASBR and generates Type-5 LSA for each of the connected networks, which is then flooded
throughout the OSPF domain except the stub areas.
This behavior is changed from the IOS version 12.1.3 and onwards. From 12.1.3 onwards if ‘redistribute
connected’ is configured under OSPF process AND if the interfaces are included in OSPF process then, only
LSA Type-1 or Type-2 are generated even though ‘redistribute connected’ is configured under OSPF process.
For more information, please refer to the following paper on CCO:
http://www.cisco.com/warp/public/104/redist-conn.html

December 18, 2007 OSPF Best Practices 16

 Use of Stub Areas

Before going into best practices of using the Stub Areas, the following table from the CCO gives an overview
of the type of OSPF Areas and restrictions on each Area.

Area Restriction
Normal None
Stub No Type 5 AS-external LSA allowed
Totally Stub No Type 3, 4 or 5 LSAs allowed except the default summary route
NSSA No Type 5 AS-external LSAs allowed, but Type 7 LSAs that convert to Type 5
at the NSSA ABR can traverse
NSSA Totally Stub No Type 3, 4 or 5 LSAs except the default summary route, but Type 7 LSAs
that convert to Type 5 at the NSSA ABR are allowed

For further understanding of each of the Areas, please refer to the following CCO URL:
http://www.cisco.com/en/US/partner/tech/tk365/technologies_tech_note09186a0080094a74.
shtml#typesofospfareas
• Stub Areas do not accept Type-5 LSAs but, all other LSAs are permitted. In other words routes belonging
to external autonomous systems (AS) are not permitted in the Stub Area but all other routes such as inter-
area and intra-area routes are allowed. In order to reach the outside networks, the routers in the stub area
use a default route which is injected into the area by the Area Border Router (ABR).
• Totally Stubby Areas accept only intra-area routes. No other types of routes are allowed in this Area.
• NSSA (Not So Stubby Area) allows the flexibility of having few external routes while maintaining the Stub
Area characteristics. This may be useful in certain situations where there is a necessity to redistribute some
external AS routes into an OSPF Stub Area but do not want to make this Area as a Normal Area. If the
Area is configured as an NSSA Area, the redistributed external routes in this NSSA Area become Type-7
LSAs which are flooded throughout the NSSA area. These Type-7 LSAs are converted into Type-5 LSAs
at the NSSA ABRs which then is flooded throughout the OSPF domain. Please note that the External LSAs
(Type-5) generated at other OSPF Areas are not permitted into the NSSA Area.
• NSSA-Totally Stub Area is similar to the Totally Stubby Area in characteristics with an addition of
permitting redistribution of External AS routes into the NSSA Totally Stub Area. As in the NSSA Area,
these external routes are Type 7 LSAs which are then converted to Type 5 at the NSSA ABRs and flooded
throughout the OSPF domain.

December 18, 2007 OSPF Best Practices 17

Best Practice Summary

Note: All the points here assume there is more than one ABR present in each Area.
• Use Stub Area where optimal routing to and from within the Area to the rest of the OSPF Areas is needed
but optimal routing to reach the external AS routes from within the Area is not an important consideration.
• Use Totally Stubby Area where optimal routing to and from devices within an area to the rest of the OSPF
domain or external AS routes is not an important consideration.
• Use NSSA Area if Stub Area characteristics are required, but also need to import External AS routes within
this Area.
• Use NSSA Totally Stub Area if Totally Stub Area characteristics are required but also need to import
External AS routes within this Area.
• Consider using an NSSA Area (NSSA or NSSA Totally Stub) if there are many ASBRs in an area
redistributing routes in a way that cannot be summarized at the ASBR (redistributing point) itself, but
combined redistributed external routes can be summarized at the NSSA ABR towards the backbone.
• Configure a loopback address as part of a NSSA Area in an ASBR. This will help avoiding sub-optimal
routing.

Best Practice Detail Explanation

• Stub or NSSA areas prevent type 5 LSAs to be flooded inside the area. This will reduce the resources for
keeping and processing external LSAs. Routers inside those areas need to rely on a default route to reach
external destinations outside of OSPF domain. This is not a problem when there is only one ABR
connecting the Stub or NSSA Area to the backbone. When there are more than one ABR present, it may
introduce sub-optimal routing to reach external destinations outside of OSPF domain since the routers
within the Stub or NSSA area has to rely on the default route to reach the external routes
• Note that a default route is originated automatically in a Stub area by the ABR(s) however in NSSA Area,
one needs to configure manually the origination of the default routes on ABR(s). If NSSA Totally Stub
Area is configured, then default is generated automatically.
• In an NSSA Area, the redistributed external routes become Type-7 LSAs which are flooded throughout the
NSSA area. The ABR between the NSSA Area and the backbone will generate a Type-5 LSA for each
received Type-7 from within the NSSA Area. The External Type-7 LSAs from different ASBRS in the
NSSA Area can be summarized by the translator ABR. Though there may be multiple ABRs present in the
NSSA Area, only one ABR will be elected to be the translator (the one having highest router ID).
• While type 3 LSAs that are originated by the ABRs and can be filtered between the areas, external LSAs
cannot be filtered, so they are flooded throughout the domain (except stub and NSSA areas). However if an
area is NSSA, an ABR can be configured to block the translation of type 7 external LSA into type 5 LSA.
This confines the propagation of external type 7 LSA within the NSSA areas.
• An ASBR in NSSA area will set the forwarding address when prefix are redistributed into OSPF. When an
ABR in NSSA Area translates the Type-7 LSAs into Type-5 LSAs, the same forwarding address is
maintained in the Type 5 LSAs also. The forwarding address is chosen from an interface part of NSSA area
at the ASBR. If a loopback address is available, the precedence is given to loopback while choosing a
forwarding address. When there is no summarization involved, this would ensure that the optimal path is

December 18, 2007 OSPF Best Practices 18

 always chosen to reach the ASBR in the NSSA Area. In absence of a loopback, the ASBR will be reached
through the transit interface that has the forwarding address which may not be the optimum path. Please
note that if the redistributed external AS routes are summarized at the NSSA ABRs, then the forwarding
address is set to 0.0.0.0 to the summarized Type 5 LSA.
The following example illustrates how the forwarding address selection affects the path selection. The scenario
explained here assumes that there is no summarization configured at the NSSA ABRs for both NSSA routes
and External routes from this Area.
The following diagram illustrates the behavior when there is no loopback configured in the NSSA ASBR while
redistributing the External AS routes. Router C which is an NSSA ASBR redistributed the RIP domain routes
10.66.66.0/24 into OSPF. Since there is no Loop Back configured on the Router C, the forwarding address for
the Type-7 LSAs is set to10.60.1.2 (s0). The same forwarding address is maintained while the Type-7 LSAs
are translated into Type 5 at the NSSA ABR. Now from Router E point of view, to reach 10.66.66.0/24 the
shorter path is through Router D and router A (cost=106). But actually to reach the RIP domain, the shorter
path from Router E is through the Router B (cost=74). Though there is a shorter path available, the longer path
is preferred due to the forwarding address set in the Type 7 LSA and corresponding Type 5 LSA.

Figure 6 Sub-Optimal Path to the ASBRs at NSSA Area Due to Default Forwarding Address
Selection

In the same scenario, if a loopback address is configured on the Router C and included in the OSPF Area 1,
then the ASBR sets the loopback’s address in the forwarding address. In the following figure, the NSSA ASBR
(Router C) redistributed the same RIP domain routes 10.66.66.0/24 into OSPF, but now with a loopback0
interface (10.55.1.1/32) configured and included in OSPF Area 1. Since there is a loopback interface
configured on the Router C, the forwarding address for the Type-7 LSAs is set to10.55.1.1 (L0). The same
forwarding address is maintained while the Type-7 LSAs are translated into Type 5 at the NSSA ABR. Now
from Router E point of view, to reach 10.66.66.0/24 the shorter path is through the Router B (cost=75).

December 18, 2007 OSPF Best Practices 19

 Figure 7 Optimal Path to the ASBRs in NSSA Area Due Change in Forwarding Address
(Loopback)

Please note that from 12.2.15T and 12.2.18S a new feature called “OSPF Forwarding Address Suppression in
Translated Type-5 LSAs” is introduced which causes a NSSA Area border router (ABR) to translate Type-7
LSAs to Type-5 LSAs, but use the address 0.0.0.0 for the forwarding address instead of that specified in the
Type-7 LSA. This feature causes routers at the backbone to forward the traffic to the translating NSSA ABRs.
Configuring this feature causes the router to be noncompliant with RFC 1587. For further information about
this feature please refer to the following CCO URL:
http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1839/products_feature_guide
09186a00801541c9.html

December 18, 2007 OSPF Best Practices 20

 Redistribution Between Multiple Process

Mutual redistribution between multiple routing processes (another routing protocol or another OSPF process)
should be done carefully as undesired behavior such as sub-optimal routing or flooding loops can occur.

Best Practice Summary

• Avoid mutual redistribution at multiple points

• Configure administrative distance in such a way that each prefix native to each protocol or process is
reached via the corresponding domain’s protocol or process.
• Control the prefixes (using distance or/and prefix-list / tag combination) in a way that the same
prefix is not advertised back to the originating domain.

Best Practice Detail Explanation

• Mutual redistribution at a single point does not give complexity and it is fairly straightforward. However,
whenever there is mutual redistribution between two routing domains at multiple points, one has to make
sure that prefixes native to each domain are reached though the corresponding domain and are not
advertised back to the same domain through another redistribution point. When redistributing the routes
from one protocol to another, the ‘administrative distance’ of the routing protocol is the deciding factor on
which protocol’s routes to be installed in the routing table.
• We will give an example of flooding loop when mutual redistribution is done at more than one point.
Consider two domains, one running OSPF and the other RIP. Mutual redistribution is performed at two
places.

December 18, 2007 OSPF Best Practices 21

 Figure 8 Mutual Redistribution

Router A and router B are configured for mutual redistribution between RIP and OSPF. Say router A and router
B receive a RIP route at exactly the same time, and each one generates an OSPF external LSA. Each router's
OSPF external overrides the RIP route in the other router due to the lower admin distance. Once the RIP route
is removed from the routing table, the redistribution is cancelled and the external LSAs are managed. This
eventually causes the RIP route to be installed and the cycle continues.
By configuring the external admin distance of OSPF route higher than RIP, we make sure that each domain’s
prefix is reached though the domain itself and this prevent the prefix to be advertised back to the same domain
For more extensive information on mutual redistribution refer to the following paper:

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml

December 18, 2007 OSPF Best Practices 22

 Router ID

OSPF identifies each router with a unique router ID. By default, Cisco IOS assigns the highest IP address of the
loopback interface(s) if available or the highest IP address of an active interface as the Router ID. Configuring
the command router-id <ip_address> under OSPF process changes this behavior. It is recommended to
configure the router ID deterministically using this command.

Best Practice Summary

• Configure a deterministic router ID for OSPF process, using router-id <ip address> command.
• Choose the router ID (IP address) from the same OSPF area address space the router belongs to.
This helps in route summarization, in case these router IDs need to be routed.
• If OSPF router ID needs to be routable, configure a loopback interface with the same IP address
and include it under the OSPF process.
• If applications like DLSW+, IPSec, etc., require optimal routing, configure separate loopback
interface(s) and use IP addresses from a different address space which is not summarized at the
ABRs. These addresses can be leaked as more specific routes to other areas for optimal path
selection.

Best Practice Detail Explanation

• Configuring Router ID ensures that the router ID would remain the same after a router reloads and even if
other loopback interface(s) with higher IP address is configured in future for other applications like IP
Multicast – Anycast RP setup where the same IP address is configured on multiple RP (Rendezvous Point)
routers.
• Configuring OSPF router ID using router-id <ip_address> commands does not make this router ID
address routable across the OSPF domain. It is used only for identification purpose by the OSPF internal
process. However, it is very common to include the router ID in the routing process for management
purposes, so that any router can be reached by telnet to the router ID IP address. This is useful in
troubleshooting process. If this is a requirement, then the recommendation is to configure the router ID IP
address under a loopback interface and include it in routing process using “network … area …” router
configuration command. This is in addition to configuring the same IP address as the OSPF router ID using
router-id <ip_address> command.
Even though any IP address can be used as a router ID, it is recommended to assign the router ID taken from
the address range assigned to the OSPF area to which the router belongs. This will allow summarizing router
ID IP address in the same range of the summary for the area. There are situations such as an ISP environment,
where the loopback addresses are often the specific next-hop we want to get to, and so it must be optimally
routed to. So, the loopback addresses should come from a different address space than the other POP links in
these situations. They should be /32 in length and not summarized.
• In most cases it is better to assign the loop back of an ABR into Area 0 so that if the connection to the
backbone fails, the router stays as an ABR and we don’t introduce SPF calculations in the non-backbone

December 18, 2007 OSPF Best Practices 23

 Areas. It should be noted that if a Stub or Totally Stubby Area is configured on an ABR, it generates the
default route to the Stub or Totally Stubby Areas. Because the loopback is in Area 0, if the transit links to
the backbone fails, then this ABR will still generate default route to the Stubby or Totally Stubby Areas
leading to black holing of some traffic till the connectivity to the backbone is restored. The work around is
to have enough redundancy for the backbone connectivity in these ABRs.
• Some applications or suit of protocols such as IPSec or DLSw+ might use loopback interfaces of the
routers to terminate the TCP/UDP sessions between the peers. For these applications, if we use the same
loopback interface that is used for OSPF router ID, which is summarized at the ABRs, then there is a
possibility of sub-optimal routing to these end-points (especially when multiple ABRs are summarizing the
same range of IP addresses). If the loopback IP addresses for these protocols are configured from a
different address space than the one summarized at the ABRs, these addresses can be sent as more specific
routes to the rest of the OSPF domain. This will help choose the optimal path between these peers.

December 18, 2007 OSPF Best Practices 24

 Process ID

The process ID is the identification of the OSPF process to which the interface belongs. The process ID is local
to the router, and two OSPF neighbouring routers can have different OSPF process IDs, unlike Enhanced
Interior Gateway Routing Protocol (EIGRP) where the routers need to be in the same Autonomous System
(AS). Cisco IOS can run multiple OSPF processes on the same router, and the process ID merely distinguishes
one process from the other.

Best Practice Summary

• Although OSPF process ID has local significance to the router, it is recommended to have the same
process ID for all the routers in the same OSPF domain. This improves configuration consistency and
eases automatic configuration tasks.

December 18, 2007 OSPF Best Practices 25

 Authentication

In general, most of the Enterprise customers do not run authentication within their OSPF domain. If security is
a concern, then it is recommended to configure Message Digest (MD5) authentication on the routers.
This mode of authentication provides more protection over simple text authentication. With support of key
rollover feature, transition to a new MD5 key will not disturb connectivity.
In the latest IOS versions, it is not necessary to configure authentication on an OSPF area level. Authentication
can be enabled between two routers sharing a common link.

Best Practice Summary

• If security is of primary concern, use MD5 authentication between the OSPF neighbors.

Best Practice Detail Explanation

• Though Authentication provides added security, it should be noted that there is overhead associated
with configuring authentication. While configuring authentication depending on the security policy
of the organization, users may consider configuring authentication only on untrusted portion of the
network..
• Area 0 authentication needs to be dealt separately specially in a case when virtual links are involved.
In case of a virtual-link, make sure that the authentication is enabled or disabled on the virtual-link
specifically. This must be done if an area authentication is enabled. Enabling the area authentication
enables authentication on every single interface that is part of area 0. The virtual link end point which
is on the router that is connected to area 0 will also have authentication enabled but the other end of
the virtual link which is connected to two areas will not have authentication enabled on the virtual
link. This will create problem even with virtual link formation. So to avoid any issues the
authentication fo area 0 must be enabled even though that router is not physically a part of area 0.

December 18, 2007 OSPF Best Practices 26

 OSPF Over Multi-Access Links

In a broadcast, multi-access network such as Ethernet, Fast Ethernet, Gigabit Ethernet etc., OSPF elects a
Designated Router (DR) and a Backup Designated Router (BDR) for each segment. The DR acts as the pseudo-
node for that segment and sends Network LSA (Type-2 LSA) with information pertaining to that segment. By
configuring the OSPF priority on an interface, you can influence DR/BDR election.
It is a good practice to distribute DR/BDR functionality deterministically so that one router does not end up
being the DR for many segments it is attached to.
In today’s campus environment, the distribution and core layers (and sometimes access layers also) use high
speed layer 3 switches which are connected through logically separate VLANs between the core and
distribution layers. With these designs there are only two OSPF neighbors in a broadcast segment. Instead of
leaving these interfaces as broadcast multi-access, these two neighbor’s interfaces can be configured as ‘point-
to-point’ thereby avoiding DR/BDR election completely. This will reduce the Type-2 LSAs in an OSPF area
(which reduce the number of node in SPF) and also allow the neighbor adjacency to be established slightly
faster as the routers need not go through the DR/BDR election in the adjacency process.

Best Practice Summary

• In a broadcast multi-access LAN segment, deterministically assign the DR and BDR to different routers
so that one router does not end up being the DR for many segments.
• If there are only two neighbors in a broadcast multi-access LAN segment (like Ethernet) and no
additional neighbors will be added, configure the two neighbor’s broadcast interfaces as ‘ospf point-to-
point’ network type.

December 18, 2007 OSPF Best Practices 27

 OSPF Over WAN

OSPF configuration on Non-Broadcast Multi-Access networks needs special consideration depending on the
layer 2 topology/protocol such as ATM or Frame Relay. Depending on the design requirements, OSPF network
type configuration can be chosen.
Following is a brief discussion on the “OSPF Network Type” options in NBMA type topologies. Next, there is
a summary of guidelines identified as benefits and risks that can help engineers make the right decision.
The NBMA interface can be configured as following OSPF network types:
• Non-Broadcast Multi-Access mode
• Broadcast Mode
• Point-to-Multipoint mode
• Point-to-point mode.

Non-Broadcast Multi-Access Mode

In general full mesh connectivity is expected for any to any communication. DR/BDR election is invoked in
interfaces configured as OSPF network type “NBMA”. If there are routers within the NBMA cloud that do not
have the full mesh connectivity, the OSPF priority need to be set to 0 on those router interfaces. This is to avoid
a router that doesn’t have full mesh connectivity becoming DR. In other words, any router that has the potential
to become a DR or BDR should have the full connectivity to the rest of the routers in the NBMA/WAN cloud.
All the routers in the NBMA should have connectivity to DR and BDR routers. It is important to note that in
case of a single PVC failure from a spoke router to the DR, this specific spoke router will lose connectivity to
the rest of the cloud. Though this specific spoke router has PVC to the BDR, the DR now do not have the
knowledge of this spoke router and hence, it will not announce this spoke router in the type 2 LSA that it will
generate to list the routers on the NBMA cloud. Since the NBMA cloud doesn’t have broadcast or multicast
capabilities, while configuring NBMA mode, the OSPF configuration should include the list of OSPF
neighbors on the routers that are eligible to become DR or BDR. In other words the neighbor configuration
should be included on all the routers that have OSPF priority other than 0. This will force the routers to use
unicast instead of multicast addresses for the protocol packets. The OSPF cost is configured per interface,
which by default is the same for all neighbors irrespective of the characteristics of individual PVCs that
connect to the neighbors.

Broadcast Mode
The overhead of manually configuring the OSPF neighbors on the NMBA/WAN network might increases
depending on the number of eligible neighbors. To avoid this overhead, it is possible to configure the NBMA
cloud as a ‘broadcast’ network by including ‘ip ospf network broadcast’ command. This command makes the
OSPF treat the NBMA/WAN network as a broadcast network and uses multicast addresses for the neighbor
discovery and other updates. As with the NBMA mode, the output cost is assigned per interface, which is used
for all neighbors. In Broadcast mode, full mesh connectivity is required for all the routers in the network as DR
and BDR election is achieved by broadcasting.

December 18, 2007 OSPF Best Practices 28

Point-to-Point Mode
In a point-to-point mode the adjacency is always formed with the neighbor. There is no DR/BDR election in a
point-to-point mode. OSPF sees the NBMA cloud as a set of point-to-point links. Unlike NBMA mode, this
mode requires multiple subnets for configuration as the links are considered a set of point-to-point links. This
configuration gives the flexibility to configure separate OSPF cost per neighbor (per point-to-point neighbor)
and also single PVC failure will not affect the connectivity of a router to the rest of the network (as long as the
router has point to point connectivity with any other router within the cloud). This mode doesn’t require full
mesh connectivity among the NMBA network routers. The downside is the router needs to maintain more
adjacencies in the point-to-point mode and also the database size increases, as there are more links to describe
the network. Depending on the topology, OSPF flooding may be sub-optimal with the point-to-point mode.

Point-to-Multipoint Mode
Point-to-Multipoint mode doesn’t require full mesh connectivity. The point-to-multipoint interface is
considered as a set of numbered point-to-point links in this mode. This mode also has all the benefits of the
point-to-point mode. There is no DR/ BDR election in this mode also. The connectivity is maintained in case of
single PVC failure (as long as the router has PVC to another router in the cloud). Routing between two routers
that are not directly connected will go through the router that has VCs to both routers. This mode supports
OSPF cost per neighbor and also has provision for emulating non-broadcast feature to support non-broadcast
media like ATM SVCs (Classical IP over ATM). This situation is not capable to handle OSPF multicast hellos,
so hellos are sent as unicast by configuring neighbor statements. The difference between this case and NBMA
case is that this case does not elect DR/BDR whereas in NMBA case the router has to elect a DR/BDR.
Another difference is that in NBMA case only one side is required to have neighbor statement but in this case
both sides require to have neighbor statement along with this unique network type to indicate the router not to
elect the DR/BDR but send unicast hellos to the configured neighbors. This feature is called OSPF point-to-
multipoint non-broadcast. The downside in this mode with or without non-broadcast option is every router in
the network sends type 3 link (stub network) which increases the number of host routes in the OSPF database.

Best Practice Summary

• Choosing the appropriate mode of NBMA/WAN network depends on various factors, like the
availability of full mesh / partial mesh, address space conservation, flexibility in per VC cost etc.
Hence it is difficult to give general recommendations. The following table lists the advantages and
disadvantages of each mode, which can help engineers to decide on the right configuration based on
the design constraints and requirements.

OSPF Network type Advantages Disadvantages

configuration

Does not require full mesh. Size of the routing table increases.
Ability to use unnumbered interfaces. Size of the OSPF database increases.
Point-to-Point Mode Robustness, flexibility, per link cost, Multiple IP subnets required.
resiliency.

December 18, 2007 OSPF Best Practices 29

OSPF Network type Advantages Disadvantages
configuration

Per PVC cost. Multiple adjacencies to maintain.

Fast convergence. Suboptimal Flooding.

Router Link LSA describes transit Requires Full mesh for any to any connectivity.
network.
Requires the configuration of each neighbour.
Only one IP subnet is required.
Non-Broadcast Mode Does not provide resilience in case of PVC
LSA updates and hellos are sent failure.
unicast.
Selection of DR and BDR.
Only two adjacencies are required for
Non-DR and Non-BDR routers. Cannot configure a separate cost for each
neighbour.
More optimal flooding.
PVC to DR is critical.
No need to configure each neighbour. Requires Full mesh for correct operation.
Router Link LSA describes transit LSA updates and hellos are sent multicast
network. which means that the update must be replicated
Broadcast Mode out of each PVC.
Only one IP subnet is required.
Does not provide resilience in case of PVC
Only two adjacencies are required for failure.
Non-DR or Non-BDR routers.
Cannot configure a separate cost for each
Flooding uses multicast addresses. neighbour.
More optimal flooding. PVC to DR is critical.
Does not require full mesh. Router Link LSA describes local interface as
stub plus each of the attached neighbours as p-
Ability to configure different cost for 2-p link.
each neighbour.
Point-to-Multipoint Mode Multiple host routes created.
Resilient in the event of PVC failure.
Size of the routing table increases.
Robustness, flexibility, resiliency.
Size of the OSPF database increases.
One IP subnet per NBMA cloud.
Multiple adjacencies to maintain.
Fast convergence.
Suboptimal flooding.

Point-to-Multipoint non- Does not require full mesh Requires the configuration of each neighbour
broadcast Mode
Ability to configure different cost for Router Link LSA describes local interface as
each neighbour stub plus each of the attached neighbours as p-
2-p link.
Resilient in the event of PVC failure
Multiple host routes created.
One IP subnet per NMBA cloud
Size of the routing table increases.
LSA Updates and hellos are sent
unicast Size of the OSPF database increases.

December 18, 2007 OSPF Best Practices 30

OSPF Network type Advantages Disadvantages
configuration

Multiple adjacencies to maintain.

Suboptimal flooding.

December 18, 2007 OSPF Best Practices 31

 OSPF and Full mesh

OSPF does not perform very well in a full mesh environment. The critical thing that can impact a network
significantly is the flooding behaviour over full mesh network. Flooding behaviour could become worse as the
number of nodes increase. You may require only 6 links to make a full mesh of 4 routers but to connect 6
routers it would take 15 links. The situation gets worse as you increase the number of routes.

Best Practice Summary

• If OSPF Full Mesh connectivity is required, it is recommended not to go over more than 6 to 8
routers
• If more Routers need to be connected in full mesh, a full mesh hierarchical design may be
considered for scalability

Best Practice detail Explanations

• The formula to determine the number of links to connect N number of nodes is defined as N(N-1)/2. This means
when a link goes down and N number of routers would flood N router LSAs all over the full mesh cloud over
N2 links which makes the time complexity very close to O(n3). Node down situation is even worse. Figure 9
shows a full mesh cloud showing how the flooding of information takes place:

December 18, 2007 OSPF Best Practices 32

 Figure 9 OSPF LSA flooding

The way flooding works is that it will propagate any new information over all the links. The receiving node
will propagate the info to all the other links except the link where the info came from. This process continue
until the new information reaches all nodea in a network,
Therefore it’s a best practice not to go over 6-8 nodes if a full mesh connectivity is required. This number of 6-
8 is excluding the other links that a router may be connected to so the number could be lower if each router in
6-8 full mesh already has hundreds of links of its own. If there are more routers that need to be a part of full
mesh then a full mesh hierarchy can be created which can scale much better than adding every node to the full
mesh cloud.
• OSPF database filter feature could also be use in a fully mesh situation to block flooding manually on few
selected interface but this process could get very tedious as it has to be done manually. You have to define a
mesh group and determine manually which interface should be blocked and which interface should flood the
info. This is why an easiest thing would be not to allow growth of your full mesh network. Whenever number of
routers increases, break the mesh into smaller mesh groups.

December 18, 2007 OSPF Best Practices 33

 OSPF over hub and spoke

OSPF protocol was not designed to handle hub and spoke networks. This is why we see OSPF do not scale
very well in a hub and spoke situation. The problem is with the link state nature of OSPF which requires it to
form and maintain neighbour relationship with every neighbour. A large number of hub and spoke could be a
disaster if not tuned properly.

Best Practice Summary

• When configuring OSPF for hub and spoke environment design the OSPF areas with smaller number of
routers.

Best Practice detail Explanations

• Hub and spoke networks are non-fully mesh networks with a high end router serving as hub and small low end
routers acting as spokes. The most common and preferred network type that should be used in hub and spoke is
point-to-multipoint. This network type significantly reduces the size of the router LSA in half and will help in
the flooding process. Its not very expensive to flood few small LSA over a link but its very costly to flood a
huge LSA. Please note that though point to multipoint configuration may be beneficial from OSPF perspective,
it may not be a desired configuration for other protocols / features customer may be running in their network.
Since this paper focuses on the OSPF, point to multipoint configuration is suggested here from OSPF
perspective. A holistic approach is recommended while designing OSPF with oter protocol / feature
requirements.
• In a hub a spoke, a spoke really does not need to know about other spokes. All it really cares about is how to
reach the hub router. For this purpose, try to configure the hub and spoke are as totally stub area and configure
small number of areas. Creating a large hub and spoke networks makes it impossible to filter spokes
information from each other and increase the size of the database for small spokes routers to handle. Also, a link
flap in one spoke will trigger SPF in every single router within an area including all spoke routers.
• In situations where a large OSPF Area can’t be divided into smaller areas, OSPF database filter feature can be
used at the hub routuer in such a way that one spoke’s LSAs are not sent to other spoke. This would require
configuring default route on spokes manually. Even though this requires lot of manual work, in critical
situations this may be used as a temporary work around till the OSPF Areas are split into smaller Areas.
Please note that a static default route configured at the spoke would rely on the WAN interface status to install
or remove the default route on the routing table. This might be a problem if the interface status is UP but not
the underlying WAN protocol. There are other ways to address the issue but they are not covered in this paper.

December 18, 2007 OSPF Best Practices 34

 IP Addressing

IP addressing has a lot to do with a network’s stability and scalability. Proper addressing facilitates easy route-
summarization that contributes to a more stable network. The IP addressing scheme along with route-
summarization affects the size of the routing table and thus convergence time. IP Addresses can be allocated in
many ways. The most recommended ways would be to allocate based on topology and geography or the
combination of both. This type of addressing allocation makes route-summarization easy and improves
stability. The blocks assigned should be on a bit boundary so they can be summarized at the ABRs.

Best Practice Summary

• Start off with a large address space.

• Assign large blocks to each OSPF area (anticipate the future needs).
• On Access Servers, assign contiguous blocks (from the area’s assigned block) for dial up connections
(/32 host addresses for each line).
• Allocate addresses based on topology/geography.

December 18, 2007 OSPF Best Practices 35

 OSPF Backbone Area

OSPF area 0 is the backbone of the OSPF domain. The primary focus in designing the OSPF backbone area is
to give the highest stability for this area. To achieve this, there are many things that can be considered.
Controlling the size of the area, installing high capacity routers, providing stable, multiple redundant links
between the core routers are some of the steps we can take to ensure the stability of the backbone area (Area 0).
Virtual link configuration is required only when the backbone area is discontinuous or when a non-backbone
area is not directly connected to the backbone area 0.
Virtual Links should generally be avoided in a network. In situations where it is used as the only work around,
summarization of internal backbone route if configured will be ignored for the transit area in which the virtual
link is configured.

Best Practice Summary

• Virtual link may be used if physical link cannot be available.

• If virtual link is used, make sure that the IOS code has the TransitCapability, CSCdi62634
• Provide redundant connections in the backbone area to prevent it from becoming discontiguous.
Single link failures should not result in area partitions.
• To achieve higher stability at the backbone area, one should have reliable, high bandwidth links,
faster CPU routers with sufficient memory.
• It is a good practice to configure a loopback as part of area 0, so that the ABR status remains
unchanged if the router looses its backbone connection. This will help the connected areas to
exchange traffic.

December 18, 2007 OSPF Best Practices 36

 OSPF Cost

OSPF cost of an interface is calculated automatically (unless the cost is set manually) based on OSPF auto-cost
reference bandwidth command and it is a function of the bandwidth of the interface. Configuring the “OSPF
auto-cost reference bandwidth” to the highest bandwidth in the network may not give needed granularity within
the network for the smaller bandwidth links. But considering the advantages, configuring OSPF reference
bandwidth to the highest denominator is recommended.
In general, the non-backbone areas with smaller bandwidth links need more granular OSPF costing. A hybrid
approach can be considered. Usually the backbone area is the one that houses the highest bandwidth links.
Other non-backbone areas may not have higher bandwidth links than that of the backbone area. In these
circumstances, reference bandwidth can be assigned with respect to the area and its highest bandwidth links.
Very careful study needs to be done regarding the future requirements and also the links types in the ABRs that
connect multiple areas. There are many pitfalls that might lead to sub-optimal routing due to wrong costing in
this scenario.

Best Practice Summary

• Configure the OSPF auto-cost reference bandwidth through out the OSPF domain to the highest
bandwidth link in the network.

December 18, 2007 OSPF Best Practices 37

 Passive Interface

The OSPF process does not need to send hellos on user VLANs/interfaces or ‘stub networks’ as there are no
neighbors on those interfaces. The stub network interfaces/VLANs can be included under OSPF but they may
be configured as passive-interface. Even if there are two routers available for redundancy using HSRP or
similar protocol, their interfaces can be configured as passive interface. If redundancy is required between these
two routers, a separate ‘transit link’ is recommended and OSPF can be enabled on this ‘transit link’.
Configuring passive interface default under OSPF routing process and specifically enabling the interfaces
using no passive interface <interface #> is recommended on the routers. This gives more control for
administering OSPF.

Best Practice Summary

• Configure passive interface default under OSPF routing process. And, enable specific interfaces
using no passive interface <interface#>.
• Configure passive interface for the user VLANS and stub-networks.

December 18, 2007 OSPF Best Practices 38

 Load Balancing

OSPF by default allows up to 4 equal cost paths to be installed in the routing table for load balancing purpose.
The default behavior can be changed to install up to 6 equal cost paths for load balancing (…in certain code in
12.0 it can be even 8). If there are more than 4 redundant paths the default value needs to be increased.
If there are multiple equal cost paths available through many interfaces to the same destination, only the first 4
routes are installed i.e. there might be 4 different next-hops from the same VLAN or interface even though
there are routes available through other VLANs/interfaces. In this case, even though we have 4 equal cost paths
across many interfaces, the packets go out of only one interface to many different next hops.
The traffic-share min across interfaces command installs the routes from many ‘different’ interfaces if there
are equal cost paths available through multiple interfaces.

Best Practice Summary

• If multiple equal cost paths are available to the same destination through multiple VLANs/interfaces,
configure traffic-share min across-interfaces command under OSPF routing process.
• In a switched environment with multiple VLANS on the same physical trunk, OSPF forms neighbor
relationship on many VLANS which may be unnecessary. There should be clear distinction between
transit networks and local networks. For OSPF to exchange routing information, it doesn’t have to
form neighbor relationship with all the VLANS on the trunk. Instead, a dedicated VLAN can be used
for OSPF neighbor relationship and transit network. These VLANS can also be designed to eliminate
spanning-tree convergence issues. Passive-interface can be used to limit the neighbor relations.

December 18, 2007 OSPF Best Practices 39

 OSPF Graceful Shutdown/Restart

During network maintenance, it may be necessary to reload an OSPF router with less disruption to the existing
network traffic. This is more important for the network core routers, as there may be hundreds flows actively
passing through the router that needs to be reloaded.

Best Practice Summary

• If an OSPF router needs to be reloaded in a production network, max-metric router-lsa command

may be used to move the transit traffic from this router to other redundant paths in the network, if
available. (Note: Configuration should not be saved. Please see details)
• On routers where IBGP is configured, max-metric router-lsa on-startup wait-for-bgp may be
configured.

Best Practice Detail Explanation

• When an OSPF router is shut down (by reload command), by default MAXAGE LSA is generated from the
router and sent to their neighbors. LSAs that are maxage seconds old (3600 seconds) are not used for
routing table calculation. Though this might seem like there is a built-in graceful shutdown available with
OSPF, giving exclusive max-metric router-lsa command comes in handy for giving enough time for the
traffic to switch over smoothly. Also, this gives the opportunity to verify whether all the transit traffic is
switched over.
• When an OSPF router needs to be taken down, or logically separated from the network (for maintenance
purpose) includes the max-metric router-lsa command under OSPF process. This will generate Router
LSA with maximum metric of 65535 for all the transit networks and send it to the routers in the same OSPF
domain. The routers within the OSPF domain run the SPF calculation and choose a new path if available,
bypassing the router that has the max-metric router-lsa configured. Please note that this command will not
make the router generate maximum metric for the stub networks (links that are directly hanging off of this
router such as user VLANs) as the only way to reach those networks is through this router.
• IMPORTANT NOTE: It is important that the router configuration with the “max-metric router-
lsa” command is NOT saved to the startup configuration. If the command is saved, the router will
keep generating the “max-metric” LSA even after the router is reloaded. When the router is reloaded,
it is recommended to verify if the router is advertising the configured metrics.
• If OSPF is used as IGP for the IBGP on a router, configuring max-metric router-lsa on-startup wait-for-
bgp command will help sending max-metric router-lsa till the IBGP is converged on that router. Generally,
IBGP peering comes up after the IGP is converged. Depending on the configuration, the time for all the
IBGP peers to come up might take little longer time. When the IGP is converged before all the IBGP peers
in the domain are converged, there may be possibilities for black-holing the traffic for a short time. This
can be avoided by configuring this command. This command advertises maximum metric until BGP is
converged or the default timer of 600 seconds is expired.
Further details on the configuration of the max-metric router-lsa can be found at the following URL:

December 18, 2007 OSPF Best Practices 40

 http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1839/products_feature_guide
09186a0080087c09.html#wp1024086

December 18, 2007 OSPF Best Practices 41

 OSPF Through GRE Tunnels

In many enterprise networks, there are situations when two or more OSPF routers need to be connected through
GRE tunnels. Though connectivity through the GRE tunnel instead of a direct physical link is not preferred
due to various reasons such as the packet overhead, larger MTU and fragmentation and router performance
issues etc., there are circumstances when GRE is the only viable alternative for the customers. Also, with the
some of the latest platforms where GRE packets are switched at the hardware level, more customers are
implementing GRE Tunnels as the solution to their connectivity needs. Please note that this section does not
address the advantages or disadvantages of using GRE Tunnels. Rather it attempts to guide the configuration
practices if GRE Tunnels are considered for implementation.

Best Practice Summary

• Consider GRE Tunnel only when direct physical connection is not feasible.
• When building GRE Tunnel and enabling OSPF on the Tunnel, the ‘Tunnel Destination’ should not
be learned through the Tunnel itself.
• When building GRE Tunnels for connecting the ABRs that summarize the non-backbone areas, the
Tunnel itself should be built through Area 0 though the GRE Tunnel interfaces belong to a non-
backbone area. (In other words, the GRE Tunnel source and destination loop back interfaces should
belong to OSPF Area 0 though the GRE tunnel interfaces belong to non-backbone Area).
• The OSPF Cost for the Tunnel need to be verified and adjusted for optimal path selection in failure
scenarios.

Best Practice Detail Explanation

There are many situations when the customers prefer to use the GRE tunnel for the connectivity. Two common
scenarios are as follows:
• Connecting Remote offices through Internet to the corporate OSPF network
• Connecting ABRs through GRE tunnel for intra-area connectivity

Connecting Remote Offices through Internet

• In some situations, connecting the remote offices to the corporate network through leased lines or ATM or
Frame Relay is not feasible. So, customers connect the remote site to the local ISP and use GRE and
IPSec Technologies for connecting the remote site to the corporate network and run OSPF through the
secured tunnel.
Further explanation and sample configuration can be found at the following CCO URL:
http://www.cisco.com/en/US/customer/tech/tk583/tk372/technologies_configuration_exampl
e09186a00800a43f6.shtml

December 18, 2007 OSPF Best Practices 42

 • The important point to note when creating the GRE tunnel is, the Tunnel Source should be a ‘connected’
interface and Tunnel Destination address should be reachable through the internet. The Tunnel Destination
should not be learned through the Tunnel itself even after building the Tunnel. If the Tunnel Destination is
learned through the Tunnel itself (and if it is more preferable route), then it might create recursive lookup
which would lead to flapping of the Tunnel. Either the Tunnel destinations are filtered through Tunnel, or
the Cost or Distance need to be changed in such a way that the Tunnel is less preferred to reach these
destinations.
For further understating on the recursive lookup and the resulting flap, please refer to the following Cisco
URL:
http://www.cisco.com/en/US/customer/tech/tk365/technologies_tech_note09186a008009469
0.shtml

Connecting ABRs Through GRE Tunnel For Intra-area Connectivity

• As discussed in the “Summarization” Best Practices section, when an OSPF domain has two or more ABRs
and if the non-backbone areas are summarized towards the backbone, then it is important to have an transit
link between the ABRs in the same non-backbone Area. The same diagram is used here for reference.
In the following figure, when the ABRs Router A and Router B are summarizing the Area-1 routes, if the
WAN link from Router C to Router A fails, the packet that needs to travel from Router A to the Router C,
takes the sub-optimal path as shown in the diagram. To avoid this scenario, we need to have a transit-link in
Area-1 between the two ABRs, Router A and Router B.
In some situations, it may not be feasible to implement a direct physical connection as an Intra-Area transit-link
between these two ABRs. So, customers prefer to implement GRE tunnel between these two ABRs for
providing transit-link for the Intra-Area traffic.

Figure 10 Sub-Optimal Routing Without Intra-Area Transit-Link Between the ABRs

By default, the OSPF cost of the GRE tunnel interface is 11111, which is high. So if we leave it to the default
values, probably the packet might still take the sub-optimal path as shown in the following diagram.

December 18, 2007 OSPF Best Practices 43

 Figure 11 Sub-Optimal Routing with Wrong OSPF Cost on GRE Tunnels

In the following diagram, if the GRE tunnel cost is changed to same as direct link cost, say GRE tunnel OSPF
cost = 64, then the packets would flow as expected. Please note that the GRE Tunnel cost of 64 is an example.
It is not a hard and fast rule to keep the Tunnel cost equal to the directly connected link cost. In case of link
failures as shown in the diagram, the cumulative cost to reach the remote destination through optimal path (in
our diagram, from Router A through GRE tunnel to Router B and then to Router C) should be less than the
cumulative cost of the sub-optimal path (From Router A to Router B to Router D and then to Router A). With
modified cost, the packet would traverse as shown in the following diagram.

Figure 12 Optimal Routing After the OSPF Cost Changed on GRE Tunnel

December 18, 2007 OSPF Best Practices 44

 The scenario explained above is an example showing the Tunnel Cost needs to be verified and adjusted to
make the network paths optimal in case of failure. It is not recommended that the GRE tunnel be the only
preferable path. Depending on bandwidth availability and topology, the GRE Tunnel path might be less
preferable. For example, in the above diagram, if the customer uses a physical link between the ABRs as a
primary Intra-Area link and uses GRE Tunnels as a backup Intra-Area link, in that case, the GRE Tunnel cost
should be adjusted to be slightly higher than the primary physical link. This would ensure the GRE Tunnel
doesn’t become the primary link in case of failures discussed above. GRE Tunnel would be used only if the
primary physical link between the ABRs also fails.
The following are the key considerations while creating the GRE tunnel and configuring OSPF:
• Separate GRE tunnels need to be created for each area in the ABR (except Area 0). The IP address of the
GRE Tunnel Interface should be placed in the specific OSPF area the GRE Tunnel belongs to.
• The Tunnel source and destination interfaces (such as loopbacks) must be configured in Area 0 and it
should be reachable from both Tunnel end point routers (typically ABRs) through Area 0. In other words,
the GRE Tunnel should come up through Area 0 and use Area 0 for forwarding and receiving the packets,
even though the GRE interface IP addresses are part of non-backbone area.
• Each GRE Tunnel interface must have unique source and destination interfaces (such as unique loopback
interfaces) tied to the GRE Tunnel interface. (This behavior has been changed from 12.3(9.13)T,
12.2(18)SXE, 12.2(27.7) onwards through CSCea16871. From these versions, multiple GRE tunnels can
use single loopback interface as tunnel source and destination by using unique Tunnel Key ID for each
GRE Tunnels). Prior to this version, if multiple GRE tunnels were configured to use the ‘same’ tunnel
source and destination addresses, only one GRE tunnel would be up.

December 18, 2007 OSPF Best Practices 45

 OSPF Flood Reduction

Flood reduction is a technique to limit the amount of flooding in OSPF network. With the help of this feature
OSPF do not age the LSAs over the link, hence will not refresh those LSA’s every 30 minutes.

Best Practice Summary

• OSPF Flood reduction can be enabled on any router as long as the feature is supported, no harm can
be done by this fature
• OSPF Flood reduction is used to minimize the LS aging process over a link so its usage is universal
• OSPF Flood reduction may not work properly if neighboring router do not support DC bit(RFC
1793)

Best Practice Detail Explanation

• This feature can be used in networks to reduce the amount of flooding. OSPF refreshes LSA every 30
minutes and flood this new refresh LSA everywhere. The idea of flood reduction was taken from RFC
1793written for OSPF demand circuit. In demand circuit capable interface, OSPF do not send any
hellos and will not do any LSA refresh every 30 minutes because the LSA age most significant bit is
set, indicating not to age this LSA. In flood reduction, OSPF will continue to send out hellos over an
interface where the flood reduction is configured but it will not age the LSAs over those links. Those
LSA will only be flooded again if there is any change in the LSA. Reduction in flooding makes
network more stable. The future version of flood reduction will have a finite number that could be
defined for the age but for now the only option is to refresh the LSA every 30 minutes or do not
refresh at all.

December 18, 2007 OSPF Best Practices 46

 Corporate Headquarters European Headquarters Americas Headquarters Asia Pacific Headquarters
Cisco Systems, Inc. Cisco Systems Europe Cisco Systems, Inc. Cisco Systems Australia, Pty., Ltd
170 West Tasman Drive 11 Rue Camille Desmoulins 170 West Tasman Drive Level 9, 80 Pacific Highway
San Jose, CA 95134-1706 92782 Issy-Les-Moulineaux San Jose, CA 95134-1706 P.O. Box 469
USA Cedex 9 USA North Sydney
www.cisco.com France www.cisco.com NSW 2060 Australia
Tel: 408 526-4000 www-europe.cisco.com Tel: 408 526-7660 www.cisco.com
800 553-NETS (6387) Tel: 33 1 58 04 60 00 Fax: 408 527-0883 Tel: +61 2 8448 7100
Fax: 408 526-4100 Fax: 33 1 58 04 61 00 Fax: +61 2 9957 4350

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the

Cisco Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China • Colombia • Costa Rica • Croatia • Czech Republic Denmark • Dubai, UAE Finland •
France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico
The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Singapore • Slovakia • Slovenia South
Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

December 18, 2007 OSPF Best Practices 47