Ospf Ixia Tests

White Paper
Open Shortest Path First (OSPF)

Conformance and Performance
Testing
26601 Agoura Road, Calabasas, CA 91302 | Tel: 818.871.1800 | Fax: 818.871.1805 | www.ixiacom.com
OSPF Conformance and Performance Testing Copyright Ixia, 2004 3
Contents
Abstract .....................................................................................................................................5
Introduction ..............................................................................................................................5
What is OSPF? ..........................................................................................................................6
OSPF operation ..................................................................................................................6
OSPF network types ..........................................................................................................8
OSPF topology ....................................................................................................................8
Summarization ............................................................................................................... 10
OSPF and IPv6 ................................................................................................................ 11
OSPF Challenges ................................................................................................................... 11
Scalability ........................................................................................................................ 11
Quick convergence ......................................................................................................... 11
Load balancing ............................................................................................................... 12
Security ........................................................................................................................... 12
Interoperability ................................................................................................................ 12
Why Test for OSPF? ............................................................................................................... 12
Test Solution Requirements ................................................................................................. 13
Optimized hardware platform ........................................................................................ 13
Emulation flexibility ........................................................................................................ 13
High scalability ................................................................................................................ 13
Integrated control and data plane testing .................................................................... 13
Test automation ............................................................................................................. 13
Ixias Approach to OSPF Testing ........................................................................................... 14
OSPF conformance testing ............................................................................................ 14
OSPF scalability and performance testing .................................................................... 14
Conclusion ............................................................................................................................. 15
Appendix: Sample OSPF Test Plans ..................................................................................... 16
1. OSPF Conformance Test ........................................................................................... 16
2. OSPF Scalability Test ................................................................................................. 19
3. OSPF Route Convergence Test ................................................................................. 21
4. OSPF Equal Cost Path Verification Test .................................................................... 23
Glossary ................................................................................................................................. 25
Acknowledgements ............................................................................................................... 26
4 Copyright Ixia, 2004 OSPF Conformance and Performance Testing
Open Shortest Path First (OSPF) Conformance and Performance Testing
Abstract The Open Shortest Path First (OSPF)
routing protocol has been gaining support
as the most popular choice for Interior
Gateway Protocol (IGP) used in IP
networks. The development of OSPF began
in 1987 by the Internet Engineering Task
Force (IETF) to address problems related to
the ongoing growth of the Internet. The
Routing Information Protocol (RIP) the
most popular routing protocol at the time
was unable to keep pace with the
increasing size of IP networks. The amount
of bandwidth consumed by RIP updates
was increasing, and route convergence
times were becoming unacceptable.
This white paper provides an overview of
OSPF basics: how it is defined and how it
operates. It also introduces appropriate
test methodologies to help ensure
successful OSPF development and
deployment for network equipment
manufacturers and network operators.
Introduction OSPF is considered an open-standards
protocol, as defined in RFC 1131 (OSPFv1)
standardized in 1989, and RFC 2328
(OSPFv2) standardized in 1991. All
vendors have since based their
implementations of OSPF on RFC 2328.
OSPF is now the most widely deployed IGP
protocol for internal networks.
OSPF is a dynamic protocol that performs
real-time calculations and reacts to
topological changes within a network. Its
efficiency comes from a rich set of
features and extensions that continue to
be added to the protocol. Extensions such
as traffic engineering and VPN
participation are expanding OSPFs
functionality and making it the most logical
IGP choice for todays networks. In
addition, OSPF has been augmented to
support IPv6 networks as defined in RFC
2740 (OSPFv3) in 1999.
OSPF offers a number of key benefits:
Cost-based routing metrics. Unlike RIP,
OSPF supports descriptive metrics to
indicate the bandwidth and capability of
each individual network link. This gives
administrators great flexibility in
engineering networks.
Multi-path routing. OSPF is able to
support multiple paths to a given
destination, giving routers a choice in
deciding how to balance data
forwarding over multiple paths. This
increases the capability to implement
load balancing and redundancy.
Hierarchical routing. OSPF supports the
concept of distinct areas and multi-
level routing, which provides the
scalability to accommodate systems
with thousands of routers.
Dijkstra Shortest Path First algorithm.
This fundamental capability of OSPF
allows it to calculate a cost to every
destination in the network.
High level of security. OSPF supports
authentication mechanisms to validate
router participation in the network.
Traffic engineering. OSPF can represent
and describe traffic-engineered
networks with deep granularity.
Fast Reroute. OSPF-TE (Traffic
Engineering) can work with the
Resource Reservation Protocol (RSVP)
to support 50ms failover times for
route path changes.
What is OSPF?
OSPF was designed with the specific goal
of efficiently handling routing tasks within
an enterprise network; this requires quick
convergence, minimum routing control
traffic, and better security. OSPF is a link-
state protocol: the concept of OSPF routing
is based on creating, maintaining, and
distributing a link-state database, which
describes a collection of routers and their
operational interfaces, how they are
interconnected, and the cost to use the
interfaces. (Cost is a metric used to
describe the relative efficiency of various
routes to a destination.) Each router in the
routing domain is responsible for the
creation of its local piece of topology via
link-state advertisements (LSAs). LSAs
contain information describing routers,
networks, reachable routes, route prefixes,
and metrics. The LSAs are then reliably
distributed to all other routers in a process
called flooding, which allows OSPF routers
to synchronize their topology databases.
Most of the OSPF operations are dedicated
to keeping the link-state database
synchronized among OSPF routers. As long
as every OSPF router has an identical link-
state database, every router can calculate
the shortest paths to the advertised
destination, using Dijkstras Shortest Path
First algorithm.
OSPF operation
OSPF routers typically go through the
following stages to maintain the operation
of an entire network:
Neighbor discovery
Database synchronization
Route calculations
Neighbor discovery. OSPF forms adjacencies
between neighboring routers operating in
the same area. OSPF neighboring routers
configured for broadcast or non-broadcast
networks use the Hello protocol to discover
each other and elect a Designated Router
(DR) and a Backup Designated Router
(BDR) for the area. Hello protocol packets
are sent periodically to establish and
maintain neighbor relationships between
OSPF neighbors. OSPF goes through
several stages when discovering a
neighbor: Down, Init, and 2-way (see Figure
1).
The DR is the elected router with the
highest priority on a broadcast network.
Only one DR is elected in a broadcast
network segment, and all routers on the
segment need to form adjacencies only
with the DR and BDR. The Designated
Router concept minimizes the number of
adjacencies that must be formed in a
broadcast network and the amount of
routing information that must be
disseminated to adjacencies. The BDR is
an elected device ready to minimize down
time if the DR fails. In that event, the BDR
assumes DR responsibility, and a second
BDR is elected. All routers on the segment
will then form adjacencies with the new
BDR.
The Hello protocol is used by OSPF to verify
the eligibility of potential OSPF neighbors,
and to confirm the correct area ID, timer
values, and OSPF priority. The Hello
protocol also maintains adjacencies after
neighbors are up by multicasting Hello
packets every 10 seconds.
Database synchronization. Once the DR and
BDR are elected and the OSPF neighbors
decide to form adjacencies, the state
transits from 2-way to ExStart (Exchange
Start) (see Figure 1). The neighboring
routers in ExStart state will decide which
router should be the master, as well as the
initial sequence number to be used by
subsequent Database Description (DBD)
packets. Adjacencies are forming in this
state, which then transits to the Exchange
state. In the Exchange state, the router
sends Database Description packets to
describe its database to neighbors. Link
State Requests may be sent to request
new LSAs from neighbors.
After databases are learned among
neighbors, Exchange state transits to one
of two states:
Loading state, if there are still entries
in the Link State Request list; or
to Full state, when the Link State
Request list is empty.
Routers request more recent LSAs by
sending Link State Requests to
neighboring routers that are in Loading
state. When there are no new LSAs to be
exchanged among neighbors, the router
transits to Full State.
If a topological change occurs in the
network, (due to changes in link status or
routes), an immediate update is sent from
that neighbor, alerting other OSPF-
speaking routers to the change. Only the
route prefix that is affected by the change
is modified, and only that LSA is sent with
the updated change. Each router then
updates its database with the change, and
network convergence occurs. OSPF also
has a built-in safety net to prevent
corrupted databases or unrecoverable
adjacencies. Each OSPF router will refresh
its own LSAs, then flood to the network
every 30 minutes.
Route calculations. After the databases are
learned and adjacencies transit to Full
state, each router calculates a path to
every destination route, using the SPF
algorithm. When these calculations are
done and the optimal route path to each
destination is determined, routes are
placed in the forwarding table. Route
calculations are usually based on interface
reachability and the cost metric.
Figure 1. OSPF adjacency process.
Down
Init
2-way
ExStart
Exchange
Loading
No Hello packets received, remains in Down.
Send Hello packets;
transit to Init.
Hello packets received from neighbor with
their own router ID contained;
transit to 2-way.
Designated Router (DR) and
Backup Designated Router (BDR) elected;
transit to Exstart.
Negotiate master/slave router and sequence
number of Database Description packets.
Database description packet exchanges.
LSAs are requested and sent.
Transit to either Loading or Full State after
completing database description.
Newly learned routes are asked for;
current database is being processed.
more LSA
exchanges
required
LSA list
empty
The router is synchronized with the neightbor
and route calculations begin.
Neighbor Discovery Hello Protocol
Database Synchronization
Route Calculations
Full State
The cost metric is either derived from
interface characteristics or manually
configured by an administrator. Unlike RIP,
which bases its forwarding decision on the
hop count, the cost metric for OSPF uses a
simple equation to determine the metric
automatically. The metric is then
appended to a route before it is advertised
to its peers. The more links the route
passes through in the network, the higher
the cost will be.
Link-state protocols like OSPF base their
metrics on links. OSPF makes decisions
about reaching networks by consolidating
and adding the cost of each link to the
destination as the route is learned and
forwarded throughout the network. Every
possible path to a destination route is
calculated and given a metric. The path
with the lowest metric is the preferred
path. This process is also known as
Dijkstras algorithm the Shortest Path
First tree calculation. OSPF calculates
metrics by applying the formula 10
8
/
bandwidth (bits/sec) when it creates the
cost for a given link. This metric is not
bound to this formula but can be
manipulated by the administrator based
on the networks needs.
OSPF network types
OSPF was designed to run over various
types of networks, including: point-to-point
networks such as Packet over SONET;
broadcast networks, such as Ethernet; and
non-broadcast networks, such as ATM or
Frame Relay. There are two types of non-
broadcast networks: Non-Broadcast Multi-
Access (NBMA) networks and point-to-
multipoint networks. NBMA networks
simulate OSPF operation on broadcast
networks where a DR and BDR are elected.
NBMA is the most efficient way to run
OSPF over non-broadcast networks in
terms of database size and the amount of
routing traffic; however, it requires all
routers to have direct links to each other.
For networks like PVC-only Frame Relay,
the manual configuration to support any-
to-any connection between routers can
create too much administrative overhead.
In this case, it is better to use point-to-
multipoint configuration. Point-to-
multipoint networks allow all routers to
communicate over the non-broadcast
network as if they were point-to-point links.
The DR and BDR are not elected in point-
to-multipoint networks, and an LSA is not
required to describe the network.
OSPF topology
OSPF introduces a routing domain, the
area: an OSPF area contains different
types of routers, with various network
types. This section describes various types
of areas and routers used in OSPF
networks, and the different LSAs
exchanged between routers.
Areas. The concept of area is what gives
OSPF its true scalability and strength in the
network. Each OSPF-speaking router must
be part of an area. The one mandatory
element of OSPF design is the backbone
area. This area must be present to connect
multiple areas. Backbone areas are also
known as Area 0, where internal routers
reside.
Stub areas. Stub areas (see Figure 2) have
no external connections or exits for OSPF,
and were designed to contain routers with
limited resources (router memory in
particular). In stub areas, the link-state
database is kept as small as possible. AS-
external LSAs are not flooded into stub
areas. OSPF groups a set of routers with a
single entry to other areas, and offers the
feature of classifying this area as a stub
area, primarily to summarize and segment
the network routing tables. Different types
of stub areas serve different purposes in
passing and accepting routes.
Not So Stubby Areas (NSSAs). Not So Stubby
Areas (NSSAs) are basically an extension
of stub areas, with the same restrictions;
however, NSSAs can directly import some
external routes for distribution into the rest
of the OSPF network, without accepting
other AS-external LSAs.
Area Border Router and Autonomous System
Boundary Router. The Area Border Router
(ABR) and Autonomous System Boundary
Router (ASBR) bridge other OSPF areas to
the backbone and provide redistribution
points from other protocols (see Figure 2).
ABRs allow other areas of OSPF to be
connected to the backbone area and share
route information. Border routers
participate in multiple areas and
simultaneously advertise prefixes into the
OSPF backbone as summary LSAs. Routes
are shared and summarized by OSPF into
the backbone area, saving resources and
memory consumption in calculating the
SPF. The ABR must have at least one
connection to the backbone area.
The ASBR borders the backbone area and
bridges non-OSPF routing domains to the
OSPF autonomous system areas. The
ASBR is similar to the ABR but has multiple
interfaces connected to OSPF and other
routing protocols. Usually these external
routes are manually brought into the ASBR
by redistribution and are summarized into
OSPF as AS-external LSAs. The OSPF
backbone area then floods the update
throughout the network and other areas
directly connected.
Figure 2. OSPF with multiple areas.
Router LSAs. Router LSAs are Type 1 LSAs.
Each router in an area initiates a router
LSA, which describes the state and cost of
the routers links (interfaces) to the area.
All of the routers links to the area must be
described in a single router LSA.
Network LSAs. Network LSAs are Type 2
LSAs. For each broadcast and NBMA
network in the area, a network LSA is
created, which supports two or more
routers. The network LSA is originated by
the networks DR. The LSA describes all
routers attached to the network, including
the DR.
Summary LSAs. Summary LSAs are Type 3
and 4 LSAs, originated by area border
routers. Summary LSAs describe inter-area
destinations:
When the destination is an IP network,
Type 3 summary LSAs are used. In this
case, the Link State ID field is an IP
network number.
When the destination is an AS
boundary router, a Type 4 summary
LSA is used. The Link State ID field is
the AS boundary routers OSPF Router
ID. Otherwise, Type 3 and 4 summary
LSA formats are identical.
AS-External LSAs. AS-external LSAs are Type
5 LSAs originated by AS boundary routers.
They describe destinations outside the AS.
Summarization
Summarization is another key component
of the OPSF feature set. Summarization
can be accomplished in OSPF at ABR and
ASBR boundaries advertised in
summarized LSAs.
Figure 3. OSPF summarization.
Summarization of routes is usually found
when hierarchical addressing is in place.
The addresses must be in contiguous
order for protocols like OSPF to take full
advantage of summarization. This ability
allows OSPF to run fewer CPU cycles and
reduce usage of memory and router
resources. If the OSPF router can store a
single route, and still be able to reach 100
different subnets from the one
advertisement, summarization has saved
one hundred different entries to the
database, and the memory to store them.
CPU cycles are also spared when the SPF
performs lookups to destinations by basing
its calculations on one entry rather than
100. Figure 3 shows a summarization
topology and how it would look in a
network diagram.
OSPF and IPv6
OSPF has been adapted to support IPv6 in
RFC 2740 (OSPFv3). All fundamental
mechanisms of OSPF remain unchanged,
such as flooding, areas, DR election, SPF
route calculation, etc. However, some
changes are needed to accommodate IPv6:
All addressing semantics were removed
from OSPF packet and LSA headers.
New LSAs have been created to carry
new IPv6 addresses and prefixes.
OSPFv3 now runs on a per-link basis,
instead of on a per-IP-subnet basis.
The flooding scope for LSAs has been
generalized.
Authentication has been removed from
the OSPF protocol itself, which relies
instead on IPv6s Authentication
Header and Encapsulating Security
Payload.
OSPF Challenges
OSPF faces several key challenges in
supporting todays networks:
Scalability
Quick convergence
Load balancing
Security
Interoperability
Scalability
An enterprise routing protocol like OSPF
must be able to scale up to meet the
demands of todays corporate networks,
which comprise thousands of routers,
supporting a wide variety of network
topologies and an ever growing number of
end-user applications. The OSPF protocol
needs to be flexible enough to support
many network types, such as point-to-
point, broadcast, and point-to-multipoint. A
multi-area architecture is necessary for
OSPF networks to scale up to support a
large number of destinations efficiently.
Route summarization and efficient
database synchronization can also
dramatically reduce the amount of
bandwidth consumed by the routing
protocol.
Quick convergence
Network instability can greatly impair
service quality and reduce productivity.
The ultimate goal in designing an
enterprise network is to reduce down time
and lost packets during the transition
caused by defective equipment or
congested links. Convergence time
depends on how quickly the routing
protocol can learn the new topology and
recalculate the routing tables throughout
entire network. Depending on the size of
the network, convergence times could
range from tens of seconds to minutes.
Load balancing
Dependability and reliability are essential
to support mission-critical applications in
todays enterprise networks. Multiple
paths to destinations can greatly increase
the dependability of networks and also
avoid congestion, by load-balancing across
multiple routes. OSPF must be able to
assign the same cost to multiple paths
with its link-state routing. Network
engineers need to build a network with
options to propagate packets via several
routes.
Security
As networks grow in size and geographic
coverage, concerns for security grow with
them. Enterprise networks need a
methodology to authenticate network
elements that have been added to the
network through unattended or manual
reconfiguration. OSPF needs to provide
secure authentication processes, such as
clear text (password) or message digest
authentication (MD5). OSPFv3 for IPv6 has
further enhanced security by encrypting
the IP layer with IPSec, as part of IPv6s
definition.
Interoperability
OSPF is a standards-based routing
protocol; however, different equipment
manufacturers may have different
interpretations of standards and
implementation. Unless these differences
can be understood and reconciled, the
enterprise network operator will be unable
to successfully integrate networks with
elements from multiple vendors. It is
critical for equipment manufacturers to
design products based on the published
standards; compliance with standards is
essential for network operators to ensure
interoperability among all network
elements.
Why Test for OSPF?
Network managers and equipment
manufacturers need to verify how well
devices supporting OSPF meet industry
standards and operational specifications.
Compliance with accepted standards can
dramatically increase the level of
interoperability among different vendors
implementations, an increasingly
important consideration for todays
complex, heterogeneous networks. Testing
protocol conformance is also especially
important for equipment developers,
because thorough testing throughout the
design cycle can avoid costly rework after
the product is released to market.
OSPF is designed to scale to the level
required for supporting large enterprise
networks. Network managers must
understand the scalability limitations and
performance bottlenecks of each network
element before deployment. Once the
network is operational, it is equally critical
to verify overall performance and service
quality. For example, convergence time is a
good indication of OSPF network
performance. The ability to support load
balancing also needs careful planning and
verification.
Test Solution
Requirements
OSPF test tools must be able to perform a
wide variety of functions to adequately test
and validate OSPF devices and networks.
For conformance testing, the test solution
must be able to fully exercise the control
plane of the device or system under test.
For performance and scalability testing,
the test solution must be able to emulate a
wide variety of topologies and hierarchies
at the control plane level and scale up for
large capacity testing. The solution must
also be able to drive wire-speed traffic
through the system at the data plane level
to fully stress the device being tested.
Optimized hardware platform
While simple router emulation can be run
on PCs or workstations, an optimized test
system is needed to provide complete
testing capabilities and high levels of
scalability. For example, to emulate a large
network, a network interface on a test tool
must support hundreds or even thousands
of IP interfaces and MAC addresses a
requirement that standard off-the-shelf
hardware cannot meet. Purpose-built test
hardware is necessary to provide the
flexibility and scalability needed to test
OSPF systems adequately.
Emulation flexibility
OSPF test tools must be able to emulate a
complete list of Router LSAs, Network
LSAs, Summary LSAs, AS-external LSAs,
and a variety of topologies, such as point-
to-point, broadcast, point-to-multipoint,
Non-Broadcast-Multi-Access (NBMA), Stub
Areas, and Not-So-Stubby Areas (NSSA).
Test tools need to provide an easy-to-use
interface that allows users to quickly
create a complex topology of networks and
routers behind each test port. Flexibility in
topology and LSA generation allows users
to test scenarios such as route
convergence and equal path load
balancing without using a large number of
real routers.
High scalability
To properly stress the routing domain of
OSPF networks, a test tool needs to scale
up in multiple dimensions, including the
numbers of OSPF adjacencies, emulated
routers, injected LSAs, and emulated
areas. These capabilities verify the
operation of a device in large scale
networks and enable corner-case
scenarios to be tested.
Integrated control and data plane testing
Another significant requirement for the
test tool is the ability to integrate control
and data plane testing. This capability
requires test tools to emulate large and
complex topologies and networks, and
then target data traffic over the advertised
topology with an integrated traffic
generator. The traffic is used to determine
device and network performance, and to
verify the proper operation of the control
plane. Automated data plane traffic
generation tied to the control plane
emulation is necessary to eliminate the
need to manually configure traffic to all
destination networks.
Test automation
OSPF test tools must be automated for
repetitive tasks and regression testing. An
industry-standard automation scripting
language like Tcl (Tool Command
Language) is a must-have feature for test
tools. Different test scenarios can be
written as self-contained, automated tests
to capture key metrics like route
convergence time and route capacity. This
flexibility greatly extends the testers ability
to measure the functionality and
performance of OSPF devices and
networks.
Ixias Approach to
OSPF Testing
OSPF conformance testing
Ixia has addressed the challenges of
protocol conformance testing by
developing IxANVL (Ixia Automated
Network Validation Library), the industry
standard conformance test suite. For
protocol conformance testing, IxANVL
supports over 30 protocols overall, and the
OSPF conformance test suite contains over
500 test cases to validate OSPF-capable
routers and devices. IxANVL provides
positive as well as negative test cases
against the RFCs that specify these
standards. Negative tests help validate
device response to killer packets.
IxANVL performs its tests as a dialog: it
sends packets to the router being tested,
receives the packets sent in response, and
then analyzes the response to determine
the next action to take. This allows IxANVL
to test complicated situations or reactions
much more intelligently and flexibly than
achievable by simple packet generation
and capture devices.
IxANVL can run on standalone
workstations or via Ixias optimized test
platforms. IxANVL can be completely
automated using a scripting interface, and
IxANVL source code is also available to
users for customization, allowing a great
degree of testing flexibility.
OSPF scalability and performance testing
The general methodology employed by Ixia
for testing the scalability and performance
of OSPF routers involves first surrounding
the device or system under test (DUT/SUT)
with Ixia hardware test interfaces. The Ixia
system then emulates everything else
needed to test the device, including
emulated OSPF routers, multiple areas,
various LSA types, and inter-area and
external routes. In this way, large and
complex topologies can be simulated to
test the DUT/SUT in realistic system
environments, with a minimum of hardware
requirements. For example, in Figure 4,
four Ixia test interfaces are connected to
the SUT with numerous areas and LSA
types being emulated per interface.
Figure 4. OSPF scalability test.
Ixia has developed two primary
applications for OSPF performance and
functional testing, IxExplorer and
IxScriptMate, each with a distinct testing
focus.
IxExplorer. IxExplorer provides a high level
of flexibility and functionality in protocol
emulation, traffic generation, and analysis.
IxExplorer is the primary controlling
application for Ixias purpose-built
hardware test platform, allowing detailed
configuration of protocols and analysis of
test results.
Within IxExplorer, both OSPFv2 and
OSPFv3 routing protocol emulation is
supported. Large topologies can be quickly
generated using router LSAs by defining an
m x n grid of emulated routers. IxExplorer
controls the protocols operation on Ixias
test hardware architecture, which supports
a CPU running Linux on each test port. This
dedicated emulation environment allows
hundreds of routers to be emulated on
each network interface. Hundreds of
thousands of routes and LSAs can be
advertised from each interface, and line
rate traffic can be generated over the
established connections.
IxScriptMate. IxScriptMate provides a
framework for running automated test
scenarios. Numerous test suites have
been developed within the IxScriptMate
environment to test OSPF route capacity
and OSPF convergence. IxScriptMate
simplifies the configuration process by
defining a configuration for the test and
showing the relevant parameters for user
input. Tests then run automatically and
display the results to the user.
Conclusion
OSPF is a scalable routing solution for the
ever growing IP networks of today. Its
complex and descriptive topology
advertisement and the concept of
hierarchical routing areas satisfy the
demands of the most diversified network
designs. Quick convergence and the
robustness of link-state database
exchanges are the key features of OSPF
networks. Also important is OSPFs
improved design for network security. With
all the enhanced features and capabilities
of OSPF networks, a proper test
methodology is essential to help network
equipment manufacturers and network
planners in several critical areas:
Conformance to standards, to ensure
interoperability in a complex, multi-
vendor environment.
Network scalability, to understand
network limitations.
Performance characterization, to avoid
bottlenecks.
The appendix of this paper provides
sample test plans to better demonstrate a
successful OSPF testing methodology.
Appendix: Sample
OSPF Test Plans
The test plans presented here include
several examples showing how Ixias
solution addresses the challenges of OSPF
testing:
1. OSPF Conformance Test
2. OSPF Scalability Test
3. OSPF Route Convergence Test
4. OSPF Equal Cost Path Verification
Test
.
1. OSPF Conformance Test
Objective. Verify the Device Under Tests
(DUTs) compliance with the following
capabilities defined in various OSPF RFCs:
OSPFv2 RFC 1583, RFC 2328
OSPF Opaque LSA RFC 2370
OSPF NSSA RFC 1587
OSPF Database Overflow RFC 1765
OSPFv3 (OSPF for IPv6) RFC 2740
Setup. A minimum of two network
connections are required from the test tool
to the DUT one for request packets and
one for response packets. Ixias IxANVL
conformance test solution is run from a
Linux workstation connected either directly
to the DUT, or via Ixia test hardware (see
Figure 5). IxANVL emulates various OSPF
topologies, depending on the configuration
of each test case.
Input parameters. Two sets of parameters
are required prior to running conformance
tests: one for test tool configuration and
one for DUT configuration. The test tool
configuration describes the interface and
protocol configuration of the tester, while
the DUT configuration describes the OSPF
features of the DUT using Expect scripts
(see Table 1).
Figure 5. OSPF Conformance Test setup.
Table 1.OSPF Conformance Test input parameters.
Parameters Description
Test Tool
Configuration
Tester Test IP Addresses, DUT IP Address, OSPF protocol
parameters (Hello interval, router priority, authentication, etc.)
DUT Configuration OSPF features (TOS Routing, Database Exchange Timeout,
Routing Table Update Timeout, etc.), via Expect scripts.
DUT
OR
Linux
workstation
Linux
workstation
DUT
IXIA
Methodology. For OSPF conformance
testing, a number of test cases are run
against the DUT based on the direct
interpretation of various OSPF RFCs.
1. Enter parameters to describe both
the Conformance Tester and DUT
configuration.
2. Select all or a set of test cases to run
(see Figure 6).
3. Run the conformance tests from the
user interface, or in a batch mode via
command scripts, reconfiguring the
DUT as required between test cases
to match the test setup.
Figure 6. OSPF Conformance Test case selection.
Results. Number of tests passed/failed,
including reasons for failed cases (See
Figure 7). IxANVL also keeps the history of
each pass or fail test case in the Test
Journal.
Figure 7. OSPF Conformance Test results.
2. OSPF Scalability Test
Objective. Determines the number of
injected routes, adjacencies, LSAs or
networks that an OSPF DUT can sustain at
a single time. This scalability test is
designed to help network and test
engineers to:
Evaluate devices to be purchased or
used in the network.
Test capacity and understand network
limitations before actual deployment
of new network elements and services.
Setup. The test requires a minimum of two
tester ports one to transmit traffic and
one to receive. The transmit direction of
traffic is unidirectional. Test port 2 is used
to advertise the OSPF network topology
and routes, while test port 1 sends traffic
to verify the advertised topology. Figure 8
shows the test configuration. During the
test, tester port 2 gradually increases the
number of advertised routes or size of
topology until the maximum sustainable
capacity can be determined. Ixias
IxExplorer or IxScriptMate application can
be used to configure, control, and execute
this test. IxScriptMate provides automated
test scripts showing comprehensive test
results of frame loss percentage based on
the ability to forward under maximum
route capacity, while IxExplorer allows
users to manually configure the size and
types of emulated topologies until the DUT
is no longer able to sustain the load.
Figure 8. OSPF Scalability Test topology.
Input parameters
Table 2. OSPF Scalability Test input parameters.
Parameter Description
Emulated LSAs Different types of LSAs
Emulated Areas Different types of areas, including the backbone area
Advertised routes The number of destinations in an OSPF network
Advertised Networks The number of networks emulated by the test port
Emulated Adjacencies The number of neighboring routers emulated by the test
port
The number of ports The number of ports emulating OSPF topology
Methodology
1. Test port 2 advertises the initial
OSPF topology based on the
configured number of emulated
adjacencies, advertised networks,
and advertised routes.
2. Test port 1 sends traffic verifying the
advertised topology.
3. Test port 2 verifies the received
packets.
4. Test port 2 increases the size of
advertised topology by a predefined
amount of routes, LSAs, adjacencies,
or networks.
5. Repeat steps 2 through step 4 until
port 2 receives no packets or packet
loss is above the Tolerance level.
Results. IxScriptMate has an automated
test for measuring the maximum route
capacity of a DUT. The comprehensive test
results will show the maximum number of
routes learned by the DUT. Figure 9 shows
an example results page. The results are
broken down per frame size and show the
resulting numbers for Max Routes Verified,
Total Loss Percentage, and Tolerance. The
Max Routes Verified value shows the
maximum number of routes that could be
sustained at that particular traffic rate and
frame size. This test can also be executed
manually, but automation with
IxScriptMate helps to simplify and speed
the testing process.
Figure 9. OSPF Scalability Test results.
3. OSPF Route Convergence Test
Objective. Verifies the ability of a router to
switch between preferred and less-
preferred routes when the preferred routes
are withdrawn and re-advertised. The test
calculates convergence by taking an
average convergence latency of multiple
topological changes.
Setup. This test uses three test ports one
to transmit and two to receive (see Figure
10). Both receive ports emulate OSPF
networks. The transmit direction of traffic
is unidirectional. The DUT must have three
ports utilized with two enabled for OSPF. All
three ports should be configured for IP and
have unique subnets in which to
communicate with the tester ports. Ixias
IxScriptMate application can be used to
configure, control, and execute this test.
Figure 10. OSPF Route Convergence Test topology.
Input parameters
Table 3. OSPF Route Convergence Test input parameters.
Max Rate The rate at which frames are transmitted. This is a percentage
of the maximum theoretical frame rate.
Number of Routes The number of prefixes to generate at the start of the test.
Advertised Delay Per
Route
The maximum time, in seconds, to allow the router to absorb
each route. This time is multiplied by the number of routes to
calculate the Max Wait Time.
Max Wait Time The amount of time the test will wait for the entire topology to
stabilize.
Methodology. This methodology can be
executed manually or by script. The key to
determining an accurate convergence time
is understanding the DUT capabilities and
properly manipulating the test parameters.
1. Test ports 1 and 2 advertise the
same OSPF topology and routes with
different metrics. The path via port 1
is used as the preferred route, while
the path via port 2 is used as the
alternate route.
2. After the Max Wait Time, the Tx port
sends traffic to target all advertised
routes. The DUT should route the
traffic via the preferred routes to test
port 1.
3. Routes are withdrawn from test port
1 (the preferred path). Traffic should
reroute to arrive at test port 2 (the
alternate path).
4. Measure the timestamp, T1, of the
last packet targeting a specific route
delivered on the preferred path.
Measure the timestamp, T2, of the
first packet targeting the same route
arriving via the alternate path.
5. Calculate the convergence time for
one specific route (T2 T1).
6. Repeat step 4 and 5 to obtain
convergence time for all withdrawn
routes. Calculate average
convergence for all routes.
Results. The test results provide an
average convergence time for all routes.
Figure 11 displays example results for the
automated OSPF convergence test in
IxScriptMate. In addition to convergence
time, this test also indicates the amount of
lost packets caused by the convergence.
Figure 11. OSPF Route Convergence Test results.
convergence delay
4. OSPF Equal Cost Path Verification Test
Objective. This test confirms OSPF load
balancing features, given four equal cost
paths to the same destination.
Setup. This test requires a minimum of
three ports one to transmit and two to
receive and represent four routers with
same cost paths to the same destination
prefix, as shown in Figure 12. Two OSPF Rx
ports each advertise two OSPF neighbors,
each with the same route advertisement.
Ixias IxExplorer OSPF Routing Protocol
Emulation can be used to run this test.
Figure 12. OSPF Equal Cost Path Verification Test topology.
Input Parameters
Table 4. OSPF Equal Cost Path Verification Test parameters.
Traffic Rate Rate at which traffic is sent to the destination network.
Number of Ports The number of Tx (traffic) and Rx (OSPF) ports
Number of
Routes
The number of routes can be increased and load balancing take
place over several destinations.
Number of
Routers Per Port
The number of emulated routers per physical port can be varied.
Methodology
1. Establish the number of test ports
needed to advertise the number of
OSPF adjacencies required.
2. Advertise LSAs from each adjacency
for the same route. Each emulated
router advertises one route path with
the same metric.
3. Confirm that the DUT has reached
full state with each OSPF router and
verify equal cost paths exist and are
all in the forwarding table.
4. Run continuous traffic to destination
IP addresses in the advertised
networks.
5. Increase the number of ports or
adjacencies per port with the same
route.
Results. This test results in a rate metric for
each destination port. Figure 13 shows
example test results using Ixias IxExplorer
application. Notice the semi-even traffic
distribution across the four equal cost
paths.
Figure 13. Equal Cost Path Verification Test, statistical results.
Glossary
Adjacency A neighbor relationship with the respective Designated
Router (DR) or Backup Designated Router (BDR) on
the network. In a point-to-point network, the opposing
router would be adjacent.
Area Border Router
(ABR)
The area border router serves two areas and must
have at least one interface connected to the backbone
area or a virtual link to bridge between.
Autonomous System
Boundary Router
(ASBR)
A boundary router that redistributes external routing
information from one IGP into OSPF and bridges two
routing domains together.
Backup Designated
Router (BDR)
The BDR is also an elected device, ready to minimize
down time should the DR fail. In this event, the BDR
assumes DR responsibility, and another router is
elected BDR.
Database Description
Packets (DBDs)
Database description packets describe a routers
OSPF database to a neighbor. DBDs also handle
Master/Slave election.
Designated Router (DR) The DR is the elected router with the highest priority
on a broadcast network. The DR entity minimizes the
number of adjacencies formed and disseminates
routing information to adjacencies.
Hello Protocol Used to keep adjacencies current by sending every 10
seconds. The Hello protocol also handles discovery
and DR/BDR elections in OSPF.
Link State
Acknowledgment
An explicit acknowledgment of received Link State
Advertisements (LSAs). Usually several LSAs are
acknowledged in a single packet.
Link State
Advertisement (LSA)
An LSA is a route advertisement in its raw form. It
contains metric, prefix, and masking information.
Link State Request The Link State Request, a packet sent during the
ExStart/Exchange stages, is based on what was
learned or not learned in the DBDs.
Link State Update The update packet contains LSAs in their full form.
Not So Stubby Area
(NSSA)
Not So Stubby Areas are an extension of Stub Areas.
However, unlike Stub Areas, NSSAs can import a small
number of external routes for later distribution into the
rest of the OSPF routing domain.
Acknowledgements
Authors: Dean Lee, Dennis Crowe
Editor, Illustrator: Elliott Stewart
OSPF Areas OSPF areas are borders to the backbone and serve as
redistribution and summarization points. Routers in a
area can be grouped, and routes within can be
summarized for easy table maintenance.
Stub Area A group of routers categorized as a Stub Area has no
exiting point to other areas. Stub areas enable
consolidation of networks and summarization. The
routers inside do not have to carry the full network
route table but only a default route.

Ospf Ixia Tests

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ospf Ixia Tests

Enviado por

Direitos autorais:

Formatos disponíveis

White Paper

Open Shortest Path First (OSPF)

Você também pode gostar