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

Contents

Abstract .....................................................................................................................................5Introduction ..............................................................................................................................5What is OSPF? ..........................................................................................................................6

OSPF operation ..................................................................................................................6OSPF network types ..........................................................................................................8OSPF topology ....................................................................................................................8Summarization ............................................................................................................... 10OSPF and IPv6 ................................................................................................................ 11

OSPF Challenges ................................................................................................................... 11Scalability ........................................................................................................................ 11Quick convergence ......................................................................................................... 11Load balancing ............................................................................................................... 12Security ........................................................................................................................... 12Interoperability ................................................................................................................ 12

Why Test for OSPF? ............................................................................................................... 12Test Solution Requirements ................................................................................................. 13

Optimized hardware platform ........................................................................................ 13Emulation flexibility ........................................................................................................ 13High scalability ................................................................................................................ 13Integrated control and data plane testing .................................................................... 13Test automation ............................................................................................................. 13

Ixia’s Approach to OSPF Testing ........................................................................................... 14OSPF conformance testing ............................................................................................ 14OSPF scalability and performance testing .................................................................... 14

Conclusion ............................................................................................................................. 15Appendix: Sample OSPF Test Plans ..................................................................................... 16

1. OSPF Conformance Test ........................................................................................... 162. OSPF Scalability Test ................................................................................................. 193. OSPF Route Convergence Test ................................................................................. 214. OSPF Equal Cost Path Verification Test .................................................................... 23

Glossary ................................................................................................................................. 25Acknowledgements ............................................................................................................... 26

OSPF Conformance and Performance Testing Copyright © Ixia, 2004 3

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 OSPF’s functionality and making it the most logical IGP choice for today’s 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 Dijkstra’s 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 withtheir own router ID contained;transit to 2-way.

Designated Router (DR) andBackup Designated Router (BDR) elected;transit to Exstart.

Negotiate master/slave router and sequencenumber of Database Description packets.

Database description packet exchanges.LSAs are requested and sent.Transit to either Loading or Full State aftercompleting database description.

Newly learned routes are asked for;current database is being processed.

more LSAexchangesrequired

LSA listempty

The router is synchronized with the neightborand 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 Dijkstra’s algorithm — the “Shortest Path First” tree calculation. OSPF calculates metrics by applying the formula 108 /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 network’s 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 router’s links (interfaces) to the area. All of the router’s 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 network’s 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 router’s 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 IPv6’s Authentication Header and Encapsulating Security Payload.

OSPF Challenges OSPF faces several key challenges in supporting today’s 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 today’s 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 today’s 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 IPv6’s 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 today’s 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 SolutionRequirements

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 tester’s ability to measure the functionality and performance of OSPF devices and networks.


Ixia’s Approach toOSPF 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 Ixia’s 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 Ixia’s 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 Ixia’s 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 OSPF’s 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: SampleOSPF Test Plans

The test plans presented here include several examples showing how Ixia’s 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 Test’s (DUT’s) 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. Ixia’s 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.

DUTOR

Linuxworkstation

Linuxworkstation 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. Ixia’s 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 parametersTable 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


Methodology1. 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. Ixia’s IxScriptMate application can be used to configure, control, and execute this test.

Figure 10. OSPF Route Convergence Test topology.

Input parametersTable 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. Ixia’s IxExplorer OSPF Routing Protocol Emulation can be used to run this test.

Figure 12. OSPF Equal Cost Path Verification Test topology.

Input ParametersTable 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.


Methodology1. 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 Ixia’s IxExplorer application. Notice the semi-even traffic distribution across the four equal cost paths.

Figure 13. Equal Cost Path Verification Test, statistical results.


GlossaryAdjacency 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 SystemBoundary Router

(ASBR)

A boundary router that redistributes external routing information from one IGP into OSPF and bridges two routing domains together.

Backup DesignatedRouter (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 DescriptionPackets (DBDs)

Database description packets describe a router’s 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 StateAcknowledgment

An explicit acknowledgment of received Link State Advertisements (LSAs). Usually several LSAs are acknowledged in a single packet.

Link StateAdvertisement (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

Documents

ospf testing

ospf scalability

ospf conformance testing

ospf challenges

data plane testing

test automation

high scalability

test solution requirements