OSPF extension to support multi-area networks with arbitrary ......IPv4 (OSPFv2) and IPv6 (OSPFv3)....

OSPF extension to support multi-area networks witharbitrary topologies

Andre Pinheiro Pires

Thesis to obtain the Master of Science Degree in

Telecommunications and Informatics Engineering

Supervisor: Prof. Rui Jorge Morais Tomaz Valadas

Examination Committee

Chairperson: Prof. Ricardo Jorge Fernandes ChavesSupervisor: Prof. Rui Jorge Morais Tomaz Valadas

Members of the Committee: Prof. Joao Luıs Da Costa Campos Goncalves Sobrinho

June 2018

Declaration

I declare that this document is an original work of my own authorship and that it fulfills all the require-

ments of the Code of Conduct and Good Practices of the Universidade de Lisboa.

Acknowledgments

First, I would like to thanks to professor Rui Valadas for his help, guidance and for thinking clearly

when problems arose.

Thanks also to my family, especially my parents for the support and to my brother for all the encour-

age and advice throughout all these years.

To my closed friends that constantly help me focus on this work and pursue my objectives. And last

but not least, to my girlfriend, for is presence, love and support.

iii

Abstract

OSPF is one of the main players for routing inside Autonomous Systems. It currently has support for

IPv4 (OSPFv2) and IPv6 (OSPFv3). OSPF supports structuring the network in multiple areas, but has

two critical limitations:(i) the network of areas is restricted to a two-level hierarchy and (ii) the paths

between routers located in different areas may not be the shortest path. This dissertation performed

an experimental validation of an extension to the OSPFv2 protocol that supports multi-area networks

with arbitrary topologies, based on the proposal presented in [1], that updating only the Area Border

Routes, interoperates with current OSPFv2 implementations. We implement both OSPFv2 and the

corresponding multi-area extension in Python, using Linux as the hosting operating system, and tested

it using GNS3 and Cisco routers.

This MSc dissertation was supported by Instituto de Telecomunicacoes.

Keywords

Internet, OSPF, routing, link state, Inter-Area Routing.

v

Resumo

O OSPF e um dos principais protocolos de encaminhamento usados num Sistema Autonomo. Actual-

mente tem suporte para IPv4 (OSPFv2) e IPv6 (OSPFv3). O OSPF suporta topologias de rede com

varias areas, mas tem duas limitacoes crıticas: (i) a rede de areas e restrita a uma hierarquia de dois

niveis e (ii) os caminhos entre routers localizados em areas diferentes podem nao ser os caminhos de

menor custo. Esta dissertacao apresenta uma validacao experimental a uma extensao ao protocolo

OSPFv2 que suporta redes multi-area com topologias arbitrarias, com base na proposta apresentada

em [1], que, atualizando apenas os Area Border Routers, e capaz de operar com as implementacoes

atuais do OSPFFv2. Implementamos o OSPFv2 e a extensao para multi-area em Python, usando Linux

como o sistema operativo e o testamos usando GNS3 e os roteadores da Cisco.

Esta dissertacao foi apoiada pelo Instituto de Telecomunicacoes.

Palavras Chave

Internet, OSPF, routing, link state, Inter-Area Routing.

vii

Contents

1 Introduction 2

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Contributions of this work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Intra-domain routing 7

2.1 Distance Vector protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Count-to-infinity problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Link State protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Construction of the forwarding table . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Hello protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Flooding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 OSPF protocol 17

3.1 Link State Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.2 Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.3 AS-External-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.4 Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.5 Designated and backup designated routers . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Mechanisms to keep LSDB updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Hello protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2 Flooding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.3 Initial LSDB syncronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Hierarchical routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

ix

4 Inter-area routing using a Link State approach 31

4.1 Limitations of current OSPF versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 The solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 LSDB of the overlay network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2 Integration with the current version of the OSPF . . . . . . . . . . . . . . . . . . . 36

5 Implementation 39

5.1 Design Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Intra-area routing implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1 The Interface class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.2 The LSDB class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.2.A LSAs for area routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.2.B Graph of the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.3 Area forwarding table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.4 Concurrent computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 Inter-area routing implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.1 LSDB of the overlay network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.2 Graph of the overlay network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3.3 Shortest path calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4 OSPF packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5 User interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.6 Python sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6.1 Multicast Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6.2 Unicast Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6.3 Deliver for multicast and unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6 Evaluation 57

6.1 Adjacency between a Cisco router and our router . . . . . . . . . . . . . . . . . . . . . . . 58

6.1.1 Hello packets and Designated Router election . . . . . . . . . . . . . . . . . . . . 58

6.1.2 Database description process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Opaque-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2.1 Creation of opaque-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.3 OSPF multi-area with a cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7 Conclusion 73

x

List of Figures

1.1 The Internet as a network of intra-domain routings. . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Abstract Graph model of a computer network. . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Count-to-infinity in a linear network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Count-to-infinity in a linear network solved with the split-horizon method. . . . . . . . . . . 11

2.4 Construction of the Link State Database (LSDB). . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Dijkstra algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Structure of an OSPF network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Format of the Header of the LSAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Format of Router-LSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Format of Network-LSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 Format of AS-External-LSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Format of Intra-Area-Prefix-LSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7 2-level hierarchical routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.8 Format of the Summary-LSAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.9 Hierarchical network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.10 Inter-Area LSAs present in every area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.11 LSDB of router R6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Example of OSPF routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Multi-area network. Image from [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 ABR overlay graph of network in figure 4.2. Figure from [1]. . . . . . . . . . . . . . . . . . 34

4.4 Format of the new LSAs for OSPFv2 and OSPFv3. . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Opaque LSAs Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6 Format of the LS type on the LSA Header for OSPFv3. . . . . . . . . . . . . . . . . . . . . 37

5.1 Data flow in the OSPF implementation for intra-area routing. . . . . . . . . . . . . . . . . . 41

xi

5.2 Data flow in the OSPF implementation in the interface class. . . . . . . . . . . . . . . . . 42

5.3 Interface’s state machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Neighbor state Machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5 Data flow in the OSPF implementation of the LSDB element. . . . . . . . . . . . . . . . . 44

5.6 UML of the OSPFv2 LSAs for intra-area routing. . . . . . . . . . . . . . . . . . . . . . . . 45

5.7 Graph example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.8 Data flow in the OSPF implementation of the forwarding table. . . . . . . . . . . . . . . . . 46

5.9 Thread initialization and end during the initial running seconds. . . . . . . . . . . . . . . . 47

5.10 Data flow in the OSPF implementation of the forwarding table. . . . . . . . . . . . . . . . . 48

5.11 Data flow in the OSPF implementation of the ABR LSDB. . . . . . . . . . . . . . . . . . . 49

5.12 UML of the new LSAs for inter-area routing. . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.13 Pseudocode for the algorithm for the shortest path calculations. . . . . . . . . . . . . . . . 51

5.14 UML representing the implementation of the OSPF packets. . . . . . . . . . . . . . . . . . 52

5.15 List of commands that the user has to interact with the implementation. . . . . . . . . . . 53

5.16 Code to parametrize the socket used to receive multicast packets. . . . . . . . . . . . . . 54

5.17 Code to parametrize the socket used to receive unicast packets. . . . . . . . . . . . . . . 54

5.18 Code to parametrize the socket used to deliver packets. . . . . . . . . . . . . . . . . . . . 55

6.1 Network topology to test the adjacency between a Cisco router and our router. . . . . . . 58

6.2 Packets captures in the link between the routers, using Wireshark. . . . . . . . . . . . . . 59

6.3 Hello packets data from the scenario illustrated on figure 6.2. . . . . . . . . . . . . . . . . 60

6.4 Link State Database presented on the Cisco Router. . . . . . . . . . . . . . . . . . . . . . 61

6.5 Link State Database and graph presented on our router for the area 0.0.0.0. . . . . . . . 61

6.6 Link State Database presented on Cisco router for the area 0.0.0.0 and list of neighbors. 62

6.7 Network topology to test the Opaque LSAs. . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.8 Area forwarding table and ABR LSDB on ABR 1.2.3.4. . . . . . . . . . . . . . . . . . . . 63

6.9 ABR 5.6.7.8 initialization, it area forwarding table and area LSDB. . . . . . . . . . . . . . 64

6.10 Capture of the packets transmitted between routers R1 and R3, during the synchronization

of ABR 5.6.7.8 with router R3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.11 LSDB of the intra-area router R1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.12 Area forwarding table and ABR LSDB on ABR 1.2.3.4. . . . . . . . . . . . . . . . . . . . 66

6.13 Graph of the overlay network and kernel forwarding table of ABR 1.2.3.4. . . . . . . . . . 67

6.14 Forwardinf table of router R2 and a connectivity test from R2 to R4. . . . . . . . . . . . . . 67

6.15 Network topology to test OSPFv2 with arbitrary topology. . . . . . . . . . . . . . . . . . . 68

6.16 Graph calculated of the overlay network, from ABR 1.2.3.4. . . . . . . . . . . . . . . . . 68

6.17 Type-3 Summary-LSAs received by router R1 relative to the prefix 50.50.50.0. . . . . . . 69

xii

6.18 OSPF forwarding table of router R1 and traceroute to the prefix 50.50.50.2. . . . . . . . 69

6.19 Type-3 Summary-LSAs received by router R1 relative to the prefix 50.50.50.0. . . . . . . 70

6.20 OSPF forwarding table of router R1 and traceroute to the prefix 50.50.50.2. . . . . . . . 71

xiii

Acronyms

ABRs Area Border Routers

ABR Area Border Router

ACK Acknowledgement

AID Area ID

ASBRs Autonomous System Border Routers

ASBR Autonomous System Border Router

ASes Autonomous Systems

AS Autonomous System

BDR Backup Designated Router

BGP Border Gateway Protocol

DB Description Database Description

DR Designated Router

DV Distance Vector

IP Internet Protocol

IS-IS Intermediate System to Intermediate System

ISP Internet Service Provider

LS ACK Link State Acknowledgement

LS Request Link State Request

LS Update Link State Update

xv

LSAs Link state advertisements

LSA Link state advertisement

LSDBs Link State Databases

LSDB Link State Database

LS Link State

OSPF Open Shortest Path First

RID Router ID

RIP Routing Information Protocol

SN Sequence Number

xvi

1Introduction

Contents

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Contributions of this work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2

1.1 Motivation

The Internet is composed by different types of equipment, which connected create a way to com-

municate from one end to another: end devices, switching equipment, and communication media. The

end devices and switching equipment attach the communication media through interfaces. There are

ingoing interfaces to receive traffic and outgoing interfaces to transmit traffic. End devices, usually called

hosts, are the source of information. The information exchanged between hosts is carried in packets that

are routed from source to destination through the networking infrastructure. This network infrastructure

is a mesh of switching equipment and physical communication media. Switching equipment transfers

packets ingoing to outgoing interfaces according to the forwarding tables. The physical communication

media provide connectivity between equipment, hosts or switching. There are different technologies

for communication media like optical fiber, coaxial cables or wireless media. These technologies dif-

fer in its properties like speed, range and the percentage of packets that are lost or corrupted during

transmission.

Figure 1.1: The Internet as a network of intra-domain routings.

The world wide web is divided into many routing domains, creating a notion of routing inside a domain

and routing between different domains. These domains are called Autonomous System (AS). Figure

1.1 illustrates this idea. The routing inside a domain is called intra-domain routing. A typical example

of an intra-domain is the network of an Internet Service Provider (ISP). The routing between domains

is called inter-domain routing. The routing between and inside domains needs to be configured and

updated, for example, to recover from some fault. This configuration cannot be done manually since it

is not scalable. So, it is necessary that routers can communicate with each other, to calculate the best

path and to recover from some fault. This effort is accomplished through routing protocols that, running

on the routers and communicating with their neighbors, jointly calculate the best routing path and update

this information regularly to recover from errors. Open Shortest Path First (OSPF) [2] and Intermediate

3

System to Intermediate System (IS-IS) [3] are the main players in today’s intra-domain routing. The de

facto standard protocol for inter-domain routing is the Border Gateway Protocol (BGP) [4].

This work focuses on intra-domain routing. Inside a routing domain, the network can be structured in

parts called areas. In this case, there will be intra-area routing protocol to control routing inside an area

and inter-area routing protocol to control routing between areas. The idea behind the creation of multiple

areas is to reduce the amount of data needed to control routing and primarily to decrease the number

of entries in the databases. In the OSPF case, splitting an intra-domain into different areas can reduce

the number of entries in the forwarding table and minimize the amount of data necessary to transmit and

store to control routing [5].

The purpose of any routing protocol is to dynamically communicate information about all network

paths used to reach a destination and to select, from those paths, the best route to reach a destination

network. There are two approaches for intra-domain routing: Distance Vector (DV) and Link State

(LS). On DV routing, the routing information is only exchanged between directly connected neighboring

routers. This means that a router knows from which neighbor a route was learned, but it does not know

how that neighbor learned the route. To make a routing decision, routers only have their local view and

the cost to prefixes through their neighbors. DV routing protocols suffer from routing loops. A routing

loop happens when a data packet is continually routed through the same routers over and over. When

this happens, routers cannot converge to a final topology. On LS routing, every router shares his local

view about the network to ensure all routers possess a complete view of the network topology.

OSPF is a routing protocol for intra-domain that uses a LS approach for intra-area routing and a

DV approach for inter-area routing. Because of the convergence problems of DV protocols, the current

versions of the OSPF restrict the construction of arbitrary multi-area topologies, requiring that all areas

in OSPF have to be directly attached to a special area, called backbone [6]. Thereby, OSPF routers

send all traffic not destined for their area through the backbone area.

1.2 Contributions of this work

This work performed an experimental validation of an extension of the OSPF protocol to support

multi-area networks with arbitrary topologies, based on the proposal presented in [1]. This extension

removes two limitations of the hierarchical version of OSPFv2: it allows arbitrary mult-area topologies,

and assures that routing is always though the shortest path. In addition, the extension requires updating

only the Area Border Routers and, besides that, it interoperates with current OSPFv2 implementations.

The implementation of this approach was written in Python programming language, and was tested

with Cisco routers [7] emulated in GNS3 [8].

4

1.3 Structure of the report

The following chapters organize this document:

2 Intra-domain routing

3 OSPF protocol

4 Inter-area routing using a Link State approach

5 Implementation

6 Evaluation

7 Conclusion

Chapter 2 introduces the two different types of routing algorithms for intra-domain routing, the link

state and distance vector algorithms. Chapter 3 describes the OSPF routing protocol, particularly, how

the network is represented in the databases, what are the mechanisms used to keep the database

updated and synchronized, and how to structure the network in smaller areas to achieve scalability

gains. Chapter 4 presents the extension for the OSPF protocol using a Link State approach for inter-

area routing. Chapter 5 describes the implementation of the solution presented in the previous chapter.

Chapter 6 presents the tests carried out on the implementation. Finally, chapter 7 shows the conclusion

of the work and presents the future work.

5

2Intra-domain routing

Contents

2.1 Distance Vector protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Link State protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7

A router executes two essential tasks to allow communication between two different locations. First

calculates the best path from senders to receivers. Second delivers a packet received using the best

path calculated. The first task is accomplished by routing protocols that, running a routing algorithm and

using as input the information received from their router neighbors, computes the best routes through

the network and places that result in a forwarding table.

Routing information flows in the opposite direction of the data information. It is originated at the

destinations, where they advertise the address prefixes at which they want to be reachable. Typically a

host is directly connected to one router, the default router for the host. When the host sends packets, it

will send it to the default router.

A Graph is typically used to formulate routing problems [9]. A Graph G = (N,E) is a set of routers

N and edges E that connect two routers. Routers represent routers and edges represent the physical

link between routers. An edge has a value representing the cost of the respective link. The cost of the

link could be correlated with the length of the physical links, the speed of the link or the monetary cost

associated. For this work, it is not relevant to know how the cost is determined. It is only essential that

an edge has an associated cost. The cost may depend on the direction of the communication, having

two costs for the same edge. This means that the cost c(x, y), where x is the originator router and y is

the destination router in a link, is different from the cost c(y, x).

Figure 2.1: Abstract Graph model of a computer network.

Figure 2.1 shows an abstraction graph for a network. In this figure, and to simplify the perception

of the image, the label attached to the links is the cost for the communication between them, whatever

8

the direction of the communication. LK1 is a shared link, an abstraction of a layer-2 network, and can

potentially connect many layer-3 devices; examples of shared links technologies are Ethernet (switched

and non-switched), Token Ring, and Wi-Fi. From router N1 to router N6, and without going through a

router twice, we will have seven different paths:

1 : N1 → N2 → N6

2 : N1 → N2 → N5 → N6

3 : N1 → N2 → N3 → N4 → N5 → N6

4 : N1 → N4 → N5 → N6

5 : N1 → N4 → N5 → N2 → N6

6 : N1 → N4 → N3 → N2 → N6

7 : N1 → N4 → N3 → N2 → N5 → N6

After computing the link path, the conclusion is that the best route to deliver a packet from N1 to N6

is following the path number 1 since that is the least-cost path. In this scenario, the path number 1 is

also the shortest path having the smallest number of links between the source and the destination.

There are two main groups of routing protocols: Distance Vector and Link State. The main difference

between them is that in the Link State protocol every router has a global view of the network and in the

Distance Vector case, routers only have is local knowledge and estimate cost for it destination prefixes.

2.1 Distance Vector protocols

Distance vector protocols are characterized by the absence of the global knowledge of the network.

This type of protocols holds a local knowledge considering that each router knows its directly-connected

neighbors and the link costs to these neighbors. Additionally, routers perform an iterative process of

computation, exchanging information with neighbors to eventually compute the global shortest path.

This iterative process does not has a predefined stop condition; the process ends when there is no

information to transmit. The algorithm of these protocols is also asynchronous, meaning that the routing

information need not be sent simultaneously by all routers.

The least-cost path from a router x to router y is calculated using a Bellman-Ford equation, dx(y) =

minv∈V (cost(x, v) + dv(y)), where V is the set of neighbors. The equation is quite simple. It obtains the

minimum among all neighbors of the sum og two components: the cost from the router to the neighbor

(cost(x, v)) with the cost advertised by the neighbor (dv(y)). The Bellman-Ford equation provides the

entries for the forwarding table. It is according to the forwarding table that routers know what interface

they should use to deliver the packet received from a source host or a router.

9

2.1.1 Synchronization

With the DV algorithms, each router needs to maintain three key routing information: the cost from

itself to the neighbors, the distance vectors containing an estimation from itself to all destinations and

the distance vectors from all of it neighbors.

To keep the routing information updated, from time to time every router sends a copy of its distance

vectors. When a router receives a new distance vector from a neighbor, it saves the new distance vector

and uses the Bellman-ford equation to update its distance vectors. After the update, the router sends

its updated distance vectors to each of its neighbors, which can, in turn, update their distance vectors.

As long as all the routers exchange their distance vectors, each cost estimate converges to the actual

least-cost path. For example, the Routing Information Protocol (RIP) protocol (Version 2) [10] sends

updates every 30 seconds.

When a router detects some change in the link cost from itself to a neighbor or some link failure,

it updates its distance vectors and if there is a difference in the cost of the least-cost path, informs its

neighbors with the new distance vector.

2.1.2 Count-to-infinity problem

The distance vector algorithms have a problem so-called count-to-infinity that can constantly increase

the cost from the routers to a specific one.

Figure 2.2: Count-to-infinity in a linear network.

Consider the example of Figure 2.2, with a linear network. Suppose that, after convergence of the

algorithm, the edge connecting routers n1 and n2 fails. When router n2 advertise a cost equal to infinite,

router n3 advertise a cost equal to 3. When router n2 receives the distance vector from neighbor n3 it

estimates that can connect to router n1 through router n3 with a cost equal to 5 and advertise his new

distance vectors. Router n3, when receives the new distance vectors from router n2, estimates the cost

to router n1 and advertise his new distance vectors again. Router n4 and n2 update and announce their

distance vectors and receives the distance vectors from router n3 and router n3 update and advertise

10

his distance vectors with the update of router n2. The synchronization of the network never stop, and

the cost of the estimates from routers n2, n3 and n4 to router n1 will continue to grow and the routers

will never understand that router n1 has become unreachable.

To partially solve the problem of routing loops, the DV protocols use a method called split-horizon.

This approach prevents loops’ creation by prohibiting a router from advertising a router back onto the

interface from which it was learned. With this technique, routers will announce different path cost es-

timates to distinct neighbors. Routers will advertise the correct estimative to all neighbors except the

next hop. To the next hop, they will advertise an infinite cost. This does not harm the operation of the

distributed and asynchronous Bellman-Ford algorithm because the estimate of the next hop will not be

affected by an announcement from a router that is for sure farther from the destination.

Figure 2.3 shows what happens if the split-horizon method is applied to the previous network case.

Figure 2.3: Count-to-infinity in a linear network solved with the split-horizon method.

2.2 Link State protocols

The Link State protocols work differently compared to the Distance Vector protocols. In the LS pro-

tocols the routers of the network cooperate to share and maintain a global knowledge of the topological

information, i.e. the description of the routers and links between them, and the addressing information,

i.e. the description of the global addresses assigned to routers and links. The routing information must

be the same for all routers. This means that the routers must keep the network map synchronized, and

to represent the network it is necessary that all routers and links have unique identifiers.

To keep the network topology and link costs synchronized, each router is responsible for disseminat-

ing its knowledge of the network ( its local view) to all other routers, i.e. its identity in the network, the

identifiers of the links attached to it and the cost to each of these links.

OSPF is an intra-domain routing protocol for Internet Protocol (IP) networks [11] that uses a link state

routing algorithm and it is used inside Autonomous Systems (ASes). Information about the identity of a

router or the identifier and cost of its links, is called in OSPF a Link state advertisement (LSA) and the

11

router to which it refers is the designated router. Routers join the received Link state advertisements

(LSAs) with their own to construct the network map. This information is stored in the LSDB. The

dissemination of the LSAs is performed through a controlled and reliable flooding process, that will be

explained in section 2.2.3

Figure 2.4: Construction of the LSDB.

The figure 2.4 illustrates the construction of the LSDB that happens when routers connect each other

to construct a computer network. The junction of the LSAs create the LSDB. Note that at every state in

the figure, all routers have already disseminated their LSAs through the network. Once the dissemination

12

of the LSAs is complete, the forwarding table is obtained.

2.2.1 Construction of the forwarding table

Every router obtains the forwarding table from the LSDB using Dijkstra’s algorithm, presented on

figure 2.5. It functions by computing the shortest path tree from the initial router to every other router in

the graph and, in one iteration, can calculate the shortest paths from the source router to every other

router. Dijkstra uses two lists, one to keep track of the routers already visited, denoted as V and another

to know the routers not visited yet, denoted as Uv. Every router has a label that indicates the actual

shortest cost from the source router. This label is temporary until the cost in the label becomes the true

shortest cost. Initially, the label is infinite for every router except the source router. For the source router,

the label is equal to zero. From now on, the algorithm will use the local view from every router, looking

for the routers with the lowest label value to the routers with bigger label value. Every time the algorithm

receives the LSA of some router, that router changes from the Uv list to the V list. The first router to look

at is always the source router, considering that it will always be the router with the lowest label value.

At the origin router, for his neighbors, the label cost will change to the cost of the link, since that cost is

smaller than infinite. The source router is now considered visited and is changed from the Uv to the V

list. The first step in every iteration is a search for the router not visited yet i.e. in the Uv list, with the

lowest label cost. This router, referred as router k, is now considered visited and placed on V . From

the current router, router k, it is calculated the distance of each neighbor in Uv from the source router.

If the calculated distance is less than the known distance, the shortest distance is updated. This means

that the label cost of that neighbor is updated to the calculated distance and the previous router is the

next router k. The algorithm return to step 1 until all routers have been included in list V , the list of the

already visited routers.

Figure 2.5: Dijkstra algorithm.

13

2.2.2 Hello protocol

Networks are not static, and a protocol that manages and distributes the network map needs to

be prepared for changes. These changes can be caused by a router or link failure, by the change of

the weight of some interface or by introducing a new router in the network. To propagate changes in

the network to the network map, routers must monitor the state of it is interfaces. One way to do it is

inspecting the state of the neighboring routers for every outgoing link. This is how the Hello protocol

works. To maintain an updated list of the identifiers of the routers currently active on each outgoing link,

routers exchange control message with their neighbors. This protocol is relatively simple and is used

in several other protocols. The Link State protocols like OSPF used a Hello protocol to know what and

where are the routers alive in a network.

2.2.3 Flooding process

The key to avoid a broadcast storm is choosing when a packet should be flooded. We say that this

flooding process is controlled. LS protocols like OSPF use a flooding process to disseminate the LSA

through the network.

To make routers remember whether or not they already have transmitted a message that is being

flooded, messages need to be labeled with a unique identifier, and these identifiers must be stored at

routers while messages pass by. When a router receives a broadcast packet, it first checks whether

the packet is in this list. If so, the packet is dropped; if not, the packet is duplicated and forwarded to all

neighbors routers, except the router from which the packet has just been received. The originating router

transmits the packet to be flooded through all its neighbors. These two simple rules, the transmission

rule and the unique identification of packets, ensures that the packet initially transmitted is delivered to

all other routers and that the packet will not keep circulating infinitely in a case of networks with cycles.

This is called controlled flooding.

To assure a reliable system, i.e., a packet that needs to be flooded is received by all the intended

recipients without exception, every router needs to send an Acknowledgement (ACK) message to the

router that send to him the routing information, meaning that the message was received. This simple

rule guarantees that every router receives the packet.

14

This chapter describes the two principal groups of routing protocols: Distance Vector and Link State

protocols. Distance Vector protocols are characterized by the absence of the global knowledge of the

network. This type of protocols holds a local knowledge considering that each router knows its directly-

connected neighbors and the link costs to these neighbors. Also, Distance Vector protocols suffer a

problem so-called count-to-infinity that can constantly increase the cost from the routers to a specific

one.

In Link State protocols, routers of the network cooperate to share and maintain a global knowledge of

the topological information. With this information, every router in the network is able to calculate the

best route for every destination and construct its forwarding table. This information needs to be the

same for all routers. To do so, Link State protocols use a flooding protocol that assures that every

router receives the information. Also, a Hello protocol is in use to detect all the member in the network

and some changes in the topology that may occur.

15

3OSPF protocol

Contents

3.1 Link State Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Mechanisms to keep LSDB updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Hierarchical routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

17

The OSPF protocol is an intra-domain routing protocol for IP networks [11]. It uses a link state rout-

ing algorithm (see section 2.2) and it is used inside ASes. The current versions of OSPF are OSPFv2

for IPv4 [2] and OSPFv3 for IPv6 [12]. OSPFv2 uses global addresses as topological identifiers. In

OSPFv3 the global addresses are now IPv6 addresses, but it keeps using IPv4 addresses as topo-

logical identifiers. Unlike OSPFv2, OSPFv3 separates the addressing information from the topological

information.

OSPF allows that every router has a complete graph of the network. The graph is constructed based

on the local view of every router which is updated when some change occurs, for example, when a link

fails. All the information about the network is maintained by every router in a database, the LSDB. It is

from the LSDB that every router calculates the shortest path for every destination.

Figure 3.1: Structure of an OSPF network.

OSPF networks are connected to other AS using a protocol for inter-domain routing like BGP. The

routers in the frontier between ASes are called Autonomous System Border Router (ASBR). The OSPF

network can be divided into different zones, called areas. To allow communication between different

areas, special routers, called Area Border Router (ABR), located in the frontier between areas, run an

inter-area routing protocol among them, to advertise the address prefixes available at each area. Figure

3.1 shows an example of an OSPF network with four areas. To connect those four areas, two Area

Border Routers (ABRs) are used. An ASBR is in Area 2 to connect to another AS.

3.1 Link State Database

The LSDB of an AS describes the network as a graph. To describe the network, the LSDB will have a

collection of LSAs, each one representing a piece of the network. To represent the network, five different

18

types of LSAs are used:

• Router-LSAs: used to describe one router and its outgoing links;

• Network-LSAs: describes a transit shared link and the routers attached to it;

• AS-External-LSAs: used to describe destinations external to the AS;

• Intra-Area-Prefix-LSA: only used on OSPFv3 to disseminate addressing information internal to an

area;

• Summary LSA (Inter-area LSA): utilized advertise prefixes and ASBR locations across areas.

Each router in an AS originates one or more LSAs. The originator router is responsible for dissemi-

nating the LSA. All types of LSAs has area scope, except the AS-External-LSA that has domain scope.

The flooding scope defines how far in the network the LSA will be propagated unchanged. Area scope

means that the LSA is propagated only inside the area is originated and domain scope means that the

LSA is propagated in all the OSPF network. As described above, every separate type of LSA as a

different function. Each LSA begins with a standard header with 20 bytes. To uniquely identify a LSA, a

combination of three fields is required: the Advertising Router, field that identifies the router originator

using its Router ID, the LS Type, used to identify the type of LSA, and the Link State ID, to distinguish

among LSAs of the same type and from the same router. The freshness of the LSA is determined by

the combination of the LS Sequence Number, the LS Checksum and the LS Age. In OSPF, the topologi-

cal information of an area is also provided by the Router-LSA and the Network-LSA. Router-LSAs and

Network-LSAs provide address information in OSPFv2 and, in OSPFv3, also the Intra-Area-Prefix-LSAs

provide address information. Summary-LSAs are only relevant when the network is divided into areas

(see section 3.3).

Figure 3.2: Format of the Header of the LSAs.

19

3.1.1 Router-LSAs

Each router originates one Router-LSA to represent itself and its outgoing links. Each of these LSAs

describes all outgoing router links for one area the router is connected to. The first 20-bytes of the LSA

consist of the generic header, described in section 3.1. The router also uses the bit B to indicate if it is an

ABR and the bit E to indicate if it is an ASBR. The Router-LSA in OSPFv2 considers four types of links.

This means that the kind of attached network types each link. This is performed in the Type field of the

Router-LSA. The different types of networks are point-to-point links (Type=1), transit networks (Type=2),

stub networks (Type=3), and virtual links (Type=4). In OSPFv3 the stub network type is not considered

since it provides addressing information.

Each link is also labeled with its Link ID on OSPFv2. This gives a name of the entity on their side

of the link. Point-to-point links are identified by the neighbor RID, transit networks are identified with

the IPv4 address of the Designated Router (DR) interface attached to the link and stub networks are

identified by the IP network identifier. The Link Data field gives extra information depending on the

type of link. For point-to-point links, links for transit networks and virtual links this field specifies the IP

address of the interface associated. For links to stub networks, the field specifies the stub network’s

mask.

In OSPFv3 all interfaces descriptions include the interface identifier of the local interface Interface

ID and the neighbor interface Neigbor Interface ID besides the Router ID (RID) of the neighbor

Neigbor Router ID. The interface identifiers are required to assure uniqueness in the link identification.

The neighbor in interfaces to transit shared links is the link DR and, therefore, the Neighbor Router ID

is the RID of the DR, and the Neighbor Interface ID is the identifier of the DR interface that attaches

to the link.

The cost assigned to outgoing interfaces is specified in the Metric field. The cost of outgoing inter-

faces is configurable and always must be non-zero, except links to stub networks [2].

The creator router floods the LSA only for the respective area.

Figure 3.3: Format of Router-LSA.

20

3.1.2 Network-LSAs

A Network-LSA is generated to identify a transit network present in the computer network. This type

of LSA describes all the routers attached to the transit network. The router responsible for originating

the Network-LSA is the DR (see section 3.1.5) for the network.

The Network-LSA in OSPFv2 lists the adjacent routers to the transit network, including the DR. The

Attached Router field is the RID of the DR. In the Network Mask field it includes the network mask

associated with the transit network. The Network-LSA in OSPFv3 similar. However, it no longer includes

the network mask since it is restricted to provide only topological information.

Figure 3.4: Format of Network-LSA.

3.1.3 AS-External-LSAs

AS-External-LSAs are the Type 5 LSAs. These LSAs are originated by the Autonomous System

Border Routers (ASBRs) and address prefixes external to the AS. In OSPFv2 the prefix and mask

are carried in the Link State ID and Network Mask fields. For OSPFv3 the same information is in

the Address Prefix and Prefix Lenght fields. In OSPFv3 the Link State ID is a locally generated

tag used to distinguish Type 5 LSAs originated by the same ASBR, since each LSA can only carry

information about one address prefix.

In both versions of OSPF, the Metric field of AS-External-LSAs carries an external cost associated

with the advertised address prefix. OSPF considers two types of external routes and uses the E flag

to distinguish between them. If the flag is set to 0 the cost to the external destination is the external cost

advertised in the LSA plus the cost from the internal router to the ASBR that injects the LSA; if the flag

is set to 1 the only cost to consider is the cost to the external destination advertised by the LSA. The

AS-External-LSA has global flooding scope. This means that the AS-External-LSAs bring no information

on the path towards the originating ASBR.

3.1.4 Intra-Area-Prefix-LSAs

OSPFv3 introduces the Intra-Area-Prefix-LSA to advertise the addressing information assigned to

the topological elements. This LSA has area flooding scope.

An Intra-Area-Prefix-LSA describes IPv6 prefixes, also indicating the topological element the prefixes

are assigned to.

21

Figure 3.5: Format of AS-External-LSA.

The association between address prefixes and topological elements is done by relating each Intra-

Area-Prefix-LSA with a topological LSAs (Router-LSAs or Network-LSAs) using three fields: the Referenced

LS Type, the Referenced Advertising Router, and the Referenced Link State ID. The Referenced

Advertising Router and Referenced Link State ID fields are equal to the Advertising Router and

Link State ID fields of the referenced topological LSA. The Referenced LS Type field distinguishes

between a reference to Router-LSAs and Network-LSAs: it equals 0x2001 for Router-LSAs and 0x2002

for Network-LSAs. A prefix assigned to a transit network is advertised through an Intra-Area-Prefix-LSA

pointing to the Network-LSA that represents the link, and having an interface cost of zero. An IPv6

address assigned to a router is advertised through an Intra-Area-Prefix-LSA pointing to its Router-LSA,

and having an interface cost of zero.

Figure 3.6: Format of Intra-Area-Prefix-LSA.

22

3.1.5 Designated and backup designated routers

Every transit network has a DR and a Backup Designated Router (BDR). The DR plays a special

role in the flooding process. The BDR replaces the DR in case of failure.

In OSPF, the DR and BDR are elected through the Hello protocol. The DR is the first router that is

started on a shared link. The BDR is the second one. If the DR abandons the shared link, the BDR

becomes DR, and a new BDR needs to be elected. The choice falls on the router with higher Router

Priority. If two or more routers have the same priority, the router sending the Hello with the highest

RID wins. If the priority setting on an OSPF router is configured to 0, that means it can never become a

DR or BDR. OSPF selects the DR as the first router to be switched on a shared link to make sure that

joining routers always get the most updated LSDB during the initial synchronization process.

When an interface of a router attached to a shared link is switched on, it enters in a waiting state

listening for Hello messages and also sending its Hello messages This state takes 4 times the time of

the periodicity of the Hello packets. If no Hello messages are received during a period, called Router-

DeadInterval, the router declares itself as the DR. When it receives a Hello message advertising a DR

but not a BDR, it accepts the DR and claims itself as the BDR. In a case of inconsistent information, for

example, two routers advertising different DR or BDR, that becomes DR is the one with higher Router

Priority.

3.2 Mechanisms to keep LSDB updated

OSPF uses three tools to maintain LSDB updated and synchronized:

• Hello protocol - used to discover active neighbors and links, and for DR and BDR election;

• Flooding process - to install, update and delete LSAs in the LSDB;

• Initial LSDB synchronization - to initialize the LSDB of a new router in the network.

3.2.1 Hello protocol

OSPF establishes neighborhood relationships using the Hello protocol referred in section 2.2.2.

Routers become neighbors after establishing bidirectional communications, meaning that a router only

considers another router its neighbor on a link when it sees itself listed in the Hello message trans-

mitted by the neighbor. The Hello messages include the router identifier, RID, and the identifier of the

area where the sending interface belongs to, the Area ID (AID). The first step in synchronizing the

LSDB is the establishment of a neighborhood relationship on a link. This protocol is the base for all the

implementations of the OSPF.

23

In OSPF, the periodicity of HELLO transmissions is 10 seconds on LANs and the lifetime is 40

seconds. The neighborhood relationship is only established if the router’s interfaces are assigned to the

same area.

The Hello messages contain a list of the RID and priority of every active router on the shared link. In

OSPFv2 the Designated Router field contains the IPv4 address of the DR interface that attached to the

link. The Backup Designated Router field contains the IPv4 address of the BDR interface connected

to the shared link. In OSPFv3, the DR and BDR field carry the RID of the routers.

3.2.2 Flooding process

The flooding process is a mechanism used to install, update and remove LSAs in a LSDB. OSPF

uses the age-lifetime mechanism discussed in section 2.2.3. The goal of this mechanism is to make

sure that LSAs get deleted from the LSDB if not updated for a long time. OSPF uses a count up process

that can go up to 1 hour. The age-lifetime process to refresh the age occurs every 30 minutes. The age

of LSAs is incremented while they stay in the LSDB using the local clock of the router.

The Sequence Number (SN) is the first criteria to decide which LSA is more recent. The SN is a

32-bit number. The checksum and the age are also used to select the fresher LSAs. The checksum is

used as a tiebreaker when two LSAs have the same SN; the age is used as a tiebreaker when two LSAs

have the same SN and same checksum. When two LSAs have the same SN and same checksum, if

the ages differ by more than 15 minutes (MaxAgeDiff), the LSA with lower age is considered fresher;

otherwise, they are considered equally fresh. According to page 159 of [13], the use of the checksum as

tiebreak after the SN helps to solve the problem of comparing LSA instances that have the same SN and

the same age but different content, that could occur during the initial LSDB synchronization. Suppose

the following sequence of three events: (i) a router originates an LSA instance with SN=1, (ii) is switched

off, and (iii) again switched on before 15 minutes have elapsed (MaxAgeDif). In this case, the router

will generate a new LSA instance that will be considered equally fresh but may have different contents.

Apparently, the problem just described has a very low probability of occurrence.

OSPF uses a controlled and reliable flooding mechanism. In general, when a router receives on an

interface a new or fresher instance of an LSA it retransmits the received LSA through all other interfaces

and acknowledges the reception of the LS using a SW protocol. The LSAs are transported in LS Update

messages, and their acknowledgments are carried in Link State Acknowledgement (LS ACK) messages.

Both these messages can transmit information about more than one LSA.

On shared links, the DR (see section 3.1.5) acts as an intermediary in the flooding process. An LSA

that is flooded on a shared link is sent to the DR, which is them retransmit it to all the routers of the shared

link. This is achieved by using multicast IP addresses: the DR and BDR transmit messages on the All

SPFRouters address, which is read by all routers attached to the link. Other routers transmit on the

24

AllDRouters which is only read by the DR and BDR. OSPF included two major optimizations to minimize

the number of LS ACK messages. The first is the delay in the transmission of the LS ACK messages to

group several LSA acknowledgment in a single message, called delayed acknowledgment. The second

is called implied acknowledgment and occurs if a router interface is waiting for the acknowledgment of

an LSA and the same instance (with same freshness) of that LSA arrives at the router.

3.2.3 Initial LSDB syncronization

The LSDB present in all routers needs to be the same if they belong to the same area. When the

connection of two neighbors comes up, they need to synchronize their Link State Databases (LSDBs)

before forwarding data traffic. To achieve the synchronization of the databases, each router sends a

sequence of Database Description (DB Description) packets that describe the LSAs contained in its

LSDB. The DB Description packets contain the headers of the LSAs that every router contains [6]. The

DB Description packets have a field, called DD Sequence Number, that is used to identify every packet.

When a router observes that a neighbor has a more recent LSA instance than its own, requests that

LSA to the neighbor.

The process of sending and receiving DB Description packets it is called Database Exchange Pro-

cess. During this, the two routers create a master-slave relationship. The master router sends DB

Description packets, and the slave has to ACK with the DD sequence number of the received packet.

This state is called ExStart. The Database Exchange Process is achieved when a router knows the

link state headers of all LSAs of its neighbor. Then, the router sends Link State Request (LS Request)

packets to the neighbor requesting the desired LSAs, and the neighbor responds by flooding the LSAs

in Link State Update (LS Update) packets. This process is controlled by three flags: the I-bit, set while

the router is in the master-slave relationship, the M-bit, set while the router has additional LSA headers

to send, and the MS-bit, set whenever the router believes it is the master. Just after this process is

complete, the router declares itself synchronized and is part of the network.

To reduce the time required to reach the OSPF ExStart state and expedite the forwarding table

convergence there is a process called Immediate Replying Hellos [14]. In this process, when a router

is in a state lower than 2-way and receives an Hello packet from a neighbor, it replies immediately with

another Hello packet. However, the implementation of this process is not mandatory for all routers.

3.3 Hierarchical routing

LSR protocols require the storage of LSDB in every router. When the network is large, some routers

could suffer from lack of memory to store the LSDB. One way to resolve this problem is to structure to

network topology in smaller areas in such a way that routers only need to keep the network map of the

25

area they belong. An area identifier in OSPFv2 and OSPFv3 is a 32-bit number (IPv4 address) unique in

the routing domain. The configuration of multiple areas in OSPF is done by associating ABR interfaces

with specific areas. In this topology routers inside an area need to know what are the destinations

available outside their areas. These destinations are injected by ABRs, routers that are connected to at

least two different areas that, using an inter-area routing protocol, disseminate addressing information

across areas and determine paths to support communication between routers in different areas. Routers

internal to an area keep only one LSDB and ABRs keep as many LSDBs as areas they are directly

attached to.

In a multi-area network, neighbor ABRs are routers that have at least one interface in the same area.

Each ABR collects information, from the LSDBs it is attached, about the prefixes available in that areas.

The addressing information is composed of the prefix identifier and the shortest path cost from the ABR

to that prefix. This information is injected into the inter-area routing protocol. This protocol disseminates

the addressing information over the ABR’s network and updates the shortest path cost to the advertised

address prefix as the information travels from the destination ABR to the source ABRs. Each ABR

needs to be capable of computing the shortest path from itself to its neighbor ABRs. It can calculate the

shortest path using the information on LSDB of the area they are attached in common.

Both in OSPFv2 and OSPFv3 exists a particular area called backbone or Area 0. This area contains

all the ABRs, i.e., all areas need to be connected to Area 0. The backbone is responsible for distributing

routing information between non-backbone areas. When a packet needs to travel from a non-backbone

area to another non-backbone area, it must go through the backbone area. The path used could be

divided into three parts: the intra-area path from the source router to one of the ABRs of the originating

area; path in the backbone area, and intra-area path in the destination area. In these three different

areas, the shortest path will be calculated only taking into account the view of that area. A consequence

of this is that the used path may not be the shortest one. OSPF uses a DV approach for inter-area

routing. The use of DV mechanisms for exchanging routing information between areas is the reason for

requiring all areas to attach directly to the OSPF backbone. Hierarchical routing protocols are difficult

to design. Most of the protocol bugs found in OSPF over the years have been in the area routing

support [6].

Multi-area routing could be pictured with the backbone as a hub of the non-backbone areas. When

a non-backbone area wants to send a packet to another area, the packet must be forwarded to the hub,

the backbone. Figure 3.7 helps us understand the two levels of the hierarchical OSPF.

3.3.1 Summary-LSAs

There are two types of Summary-LSAs, Type 3 and Type 4. These LSAs are distance vectors

originated by an ABR. They represent destinations from an area and are communicated to the rest

26

Figure 3.7: 2-level hierarchical routing.

of the areas of the AS.

A Type 3 LSA is also called Network-Summary-LSA in OSPFv2 and Inter-Area-Prefix-LSA in OSPFv3.

These LSAs are used when the destination is an address prefix. In this case, the LSA’s Link State ID

field is a subnet IP address. For a Summary-LSA Type 3, the Advertising Router field contains the

RID of the ABR and the Link State ID is the advertised subnet IP address. This LSA also has a

Network Mask field for the network mask of the destination subnet and a Metric field for the cost from

the Advertising Router to the destination network.

The Type 4 Summary-LSAs are also called ASBR-Summary-LSA in OSPFv2 and Inter-Area-Router-

LSA in OSPFv3. These LSAs are used to solve a problem related with the AS-External-LSAs (see

section 3.1.3. AS-External-LSAs do not give information about the path for the ASBR that announces

an external destination since they are flooded with AS scope. The ASBR-Summary-LSA (OSPFv2)

and Inter-Area-Router-LSA (OSPFv3) LSAs are distance-vectors originated by ABRs to represent the

ASBRs of the areas they are directly attached to and are disseminated through an inter-area routing

Figure 3.8: Format of the Summary-LSAs.

27

protocol. They reference the corresponding AS-External-LSAs through the RID of the ASBRs. In the

ASBR-Summary-LSA the RID is carried in the Link State ID field, and in the Inter-Area-Router-LSA in

the Destination Router ID field.

Figure 3.9: Hierarchical network.

Figure 3.9 shows an example of a network with three areas. Routers R1 and R6 are area-internal

routers, R5 is an ASBR and all the others routers are ABRs. ap1, ap2, and ap3 are address prefixes

that need to be disseminated in the network. All the links are point-to-point except the link between

router R4 e R5, lk1, that is a transit network. The ABR routers send distance vectors to distribute

the area-external routing information among ABRs, the Network-Summary LSAs in OSPFv2 and the

Inter-Area-Prefix-LSA in OSPFv3.

Figure 3.10: Inter-Area LSAs present in every area.

Figure 3.10 shows the Inter-Area LSAs present in every area. This image shows the update of the

Inter-Area LSAs. For example, the Inter-Area-Router-LSA for the router R5 is first flooded in area 0 by

the router R2 with the cost of 1. When this LSA arrives at routers R3 and R4, each one of them updates

the cost in the Metric field and changes the Advertising Router field with its RID.

Figure 3.11 shows the LSDB of router R6. Note that the Router-LSAs about routers R3 and R4

28

only present the interfaces that are in Area 2. On the LSDB, there is a Network-LSA that describes the

transit network lk1 and also an Intra-Area-Prefix-LSA indicating the IPv6 address, ap2, associated with

the topological element, lk1. Router R6 receives an AS-External-LSA announcing the external address

prefix ap3. Since this LSA has AS scope, the Inter-Area-Router-LSAs are crucial to calculate the best

path to the external destination.

Figure 3.11: LSDB of router R6.

29

This chapter describes the OSPF routing protocol. There are two versions of the OSPF: OSPFv2 for

IPv4 and OSPFv3 for IPv6. The OSPF is a Link State routing protocol used in intra-domain routing.

The information about the network is divided in different LSAs and are maintained by every router in it

LSDB.

Every router have the same LSAs, having the same information about the network. It is from the

LSDB that every router calculates the shortest path for every destination. To represent the network,

four different types of LASs are used in OSPFv2: Router-LSAs to describe a router and its outgoing

links; Network-LSAs to describe transit shares links and the routers attached to it; AS-External-LSAs to

describe destinations external to the AS; Summary-LSAs to advertise prefixes and locations of ASBRs

across areas.

To keep the LSDB updated and equal the OSPF protocols use 3 mechanisms. The Hello protocol

is used to discover active neighbors and links in the network and to elect the Designated Router and

Backup Designated Router in a shared link. Also, OSPF uses a controlled and reliable flooding process

to install, update and delete LSAs in LSDB. To achieve the synchronization of the databases more

faster, OSPF uses an initial LSDB synchronization process to populate the LSDB of a new router.

OSPF allows structuring the network topology in smaller areas. A router only needs to keep the LSAs

of the areas they belong, having a different LSDB for every area. Routers between areas, called

Area Border Routers, play a special role since they are responsible to determine paths to support

communication between areas and inject external destinations through the area. All the ABRs must

be connected to a special area, called backbone. Summary-LSAs represent destinations of an area

outside that area. They are disseminated as Distance Vectors with the initial cost from the ABR to the

advertised destination.

30

4Inter-area routing using a Link State

approach

Contents

4.1 Limitations of current OSPF versions . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 The solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

31

4.1 Limitations of current OSPF versions

The current OSPF version is based on a Distance Vector approach for inter-area routing. As re-

ferred in section 2.1, the distance vector protocol uses the asynchronous and distributed version of the

Bellman-Ford algorithm. This algorithm does not prevent routing loops from happening and suffers from

the count-to-infinity problem (see section 2.1.2). To avoid the creation of routing loops, OSPF restricted

the area design to a 2-level hierarchical structure, where the lower levels need to send all traffic through

the upper level when they want to communicate with other lower level areas.

Figure 4.1: Example of OSPF routing.

OSPF prevents the advertisement of some routing information to avoid loops in the network. This pro-

hibition affects the number of routing alternatives, and optimal global routing may be achieved on some

occasions. OSPF prevents ABRs from advertising, inside an area, routes to area-internal addresses

or routers to area-external addresses that cross that area (using Type-3 Summary LSAs). Moreover, a

router always prefers an intra-area route (against an inter-area route) when building it forwarding table.

To illustrate how these restrictions can prevent selected paths from being the shortest ones, consider

the example of figure 4.1. It is clear that the shortest path from the source router R1 to the destination

router R3 is R1 → ABR1 → R2 → ABR2 → R3 with a cost of 4. However, OSPF does not allow the

use of this path for this communication, since both routers, source and destination, are in the same area

(because ABR2 cannot advertise into area 1 the path to R1 via ABR1). So the path used will be the

direct link from R1 to R3, with a cost of 5.

Section 16 of the OSPF specification [2], details the algorithm used to calculate the OSPF routing

table. The router calculates first the intra-area routes by building the shortest path tree for each attached

area. Afterwards, it calculates the inter-area routes using the Summary-LSAs. This means that the

router only uses intra-area routes for internal destinations.

32

4.2 The solution

One way to solve the problems described in the previous section is to replace the inter-area routing

protocol by a Link State protocol. This solution, proposed in [1], allows multi-area networks with arbitrary

topologies.

Figure 4.2: Multi-area network. Image from [1].

Figure 4.2 shows a multi-area network of four areas with the following elements:

• Routers R2, R3, R4, R5 and R6 are ABRs;

• R8 is an ASBR;

• ap1, ap2, and ap3 are address prefixes that need to be disseminated in the network;

• R1 and R7 are area-internal routers.

This network could not be implemented in the current OSPF version since the multi-area topology

contains a cycle, i.e., from any area it is possible to cross all other areas and end in the starting area

(for example R1 → R2 → R5 → R8 → R7 → R6 → R3 → R1). OSPF allows an exception to this

rule through so-called virtual links. Virtual links are tunnels that allow the connection to the backbone

from areas that are not physically attached to it. However, virtual links require manual configuration and

inherit the problems of static routes.

The figure 4.3 shows an abstraction of the network composed only by the ABRs where the links

that connect the ABRs represent the shortest path between them. The labels in the links are the cost

33

Figure 4.3: ABR overlay graph of network in figure 4.2. Figure from [1].

of each shortest path connection between ABRs. We call this network the ABR overlay. This figure

suggests the use of a Link State routing approach to inter-area routing. In this approach, each ABR will

share its local view of the ABR overlay to construct and maintain the graph of the ABR overlay network.

Particularly, each ABR share who its neighboring ABRs are and what are the costs of intra-area shortest

paths towards them, using the LSDB of its directly attached areas. It also disseminates information on

the address prefixes and ASBRs available in these areas. Every ABR will maintain a LSDB describing

the ABR overlay.

4.2.1 LSDB of the overlay network

Similarly to intra-area routing, in inter-area routing every ABR needs to flood to all other ABRs its

local view of the ABR overlay, i.e., the ABR identifier, the identifier of its neighbor ABRs and also the

cost of the shortest path towards them and the information about the prefixes present in the areas. As in

the case of single-area, topological and addressing information must be separated. For the topological

information we will use ABR-LSAs, and for the addressing information, we will use Prefix-LSAs and

ASBR-LSAs. The format of these LSAs is presented in figure 4.4.

The ABR-LSAs will contain the identifier of the originating router, the identifier of the neighboring

ABRs and the cost of the shortest path towards them. The Prefix-LSAs include the identifier of the

originating ABR, the address prefix and the cost of the shortest path from the originator ABR to the

shared link at which the prefix was assigned. The ASBR-LSAs will perform the same work done by the

ASBR-Summary-LSA in OSPFv2 and Inter-Area-Router-LSA in OSPFv3, disseminating the location of

the ASBRs.

These new three types of LSAs need to be flooded with AS scope to guarantee that will be received

34

Figure 4.4: Format of the new LSAs for OSPFv2 and OSPFv3.

by every ABR. Using the ABR-LSAs and Prefix-LSAs, every ABR will know the address prefix of every

destination. These new LSAs will be almost equal for OSPFv2 and OSPFv3; the only difference will be

the LSA Header.

With this solution, each ABR could determine the inter-area shortest path from itself to external

destinations, using Dijkstra’s algorithm. ABRs have unrestricted access to all AS routes thought this

graph and, therefore, optimal global routing is always assured.

Applying this solution to the network topology of figure 4.1 (a) to communicate from router R1 to

router R2, ABR2 will know that ABR1 has a cost to router R2 of 1, based on the LSDB of the overlay

network. This way, and applying the Dijkstra’s algorithm, will calculate that the best route to router R2

crosses ABR1. Without the restrictions of the current OSPF, ABR2 will inform router R1 that has a path

with a cost of 2 to router R2, which is the optimal global routing and the route that router R2 will use.

35

4.2.2 Integration with the current version of the OSPF

To achieve interoperability between versions of OSPF, these new LSAs cannot be flooded as an

arbitrary new type, since routers only flood the known types 1 to 5.

In OSPFv2, it will be used the Opaque LSA [15], allowing the flooding of the new LSAs through all

the routing domain. There are three types of Opaque LSAs, which differ on the flooding scope wanted:

type 9 is used for link flooding scope, type 10 for area flooding scope and type 11 for domain flooding

scope. Since we need to reach all the ABRs, the type used will be type 11. To distinguish the three

new LSAs, that will have the same flooding scope, it will be used the Opaque Type field (see figure 4.5).

Taking into account the already registered Opaque Types in [15] the ABR-LSAs will be identified by the

Opaque Type equals 20, the Prefix-LSAs equals to 21 and the ASBR-LSAs equals to 22.

Since routers handle opaque-LSAs as normal LSAs, there is no need to create a process for the

initial synchronization of the LSDB of the overlay network. The opaque-LSAs are exchanged during the

DB Description Process of the OSPFv2. However, opaque LSAs are only flooded with opaque-capable

routers. This means that all routers in the AS need to be opaque-capable. An opaque router learns of its

neighbor’s opaque capability at the beginning of the DB Description Process during the ExStart state.

A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of the header OSPF for

its DB Description packets.

The OSPF Opaque-LSA specification [15] makes some considerations about when link-state type-11

Opaque LSAs are flooded throughout the AS. They alert to the fact that there must be a way for OSPF

routers in remote areas to check the availability of the LSA originator. Specifically if an OSPF router

originates a type-11 LSA and, after that, goes out of service. In our case, the Opaque LSAs are based

on the information presented in the area LSDBs. When some router goes out of service, the LSDB

of the corresponding area changes. That update of the area LSDB triggers a process to update the

Opaque-LSAs.

Figure 4.5: Opaque LSAs Header.

36

The Opaque LSAs have the same header structure as normal LSAs since the Opaque Type and

Opaque ID fields correspond to the Link State ID.

Figure 4.6: Format of the LS type on the LSA Header for OSPFv3.

Despite the Option field that was removed, the LSA Header is almost the same for OSPFv2 and

OSPFv3. Although, the LS Type on OSPFv3 have now 2 bytes and the high-order three bits of the

field encode general properties of the LSA. The U-bit on the LSA Header for OSPFv3 (see figure 4.6)

indicates how the LSA should be handled by a router that does not recognize the LSA’s type. If set to 0

means that should be treated as if it had link-local flooding scope; if the bit is set to 1, the LSA should

be stored and flooded as an unknown LSA. The S1 and S2 bits indicate the flooding scope of the LSA.

For the case of the new LSAs, they need to be flooded with the bit S2 set to 1 and S1 to 0 to achieve AS

scope.

The ABRs will perform a translation of the ASBR-LSAs and the Prefix-LSA to the LSAs that the

current implementation knows. This critically reduces the number of routers that need to be updated by

the network administrator since only ABRs will need to be updated. The ASBR-LSAs will be converted in

ASBR-Summary-LSAs for OSPFv2 and Inter-Router-Prefix-LSA for OSPFv3 before injecting the LSAs

in the areas attached. The Prefix-LSAs will be converted in Summary-LSAs for OSPFv2 and Inter-Area-

Prefix-LSAs for OSPFv3 before the injection on the areas the ABR is attached. The AS-External-LSAs

will have the same treatment that is performed in the current versions of OSPF.

Using the network topology of figure 4.1 (b), let’s assume that router R1 has an address prefix to

announce, called ap1. ABR1 and ABR2 will disseminate through all the network its ABR-LSAs with the

LS Type field as 11 and with equal Opaque Type field. Moreover, the two ABRs will disseminate a Prefix-

LSA to announce the address prefix ap1. ABR1 will announce a cost of 1, and ABR2 will announce

a cost of 6. With this information, ABR2 will determine that it can communicate with router R1 using

the path that crosses area 2 and it will inform the areas attached to, using a Type-3 LSA. Router R3 will

calculate that the shortest path from it to router R1 is crossing area 2, which is the optimal global routing.

37

The OSPF uses a Distance Vector approach for inter-area communication and restricts the area topol-

ogy to a 2-level hierarchy, where the upper level corresponds to the backbone area. Furthermore,

OSPF prohibits the advertisement of some routing information to avoid loops in the network. This af-

fects the number of routing options and the global optimal routing may not e achieved when the shortest

path crosses more than one area.

This chapter describes a Link State approach for inter-area routing. An abstraction of the network com-

posed only by ABRs, called ABR overlay, is described in three new LSAs: ABR-LSAs to disseminate

the topological information of the ABR overlay; Prefix-LSAs to inform the address prefix and cost of the

shortest path to a prefix; ASBR-LSAs to give the location of the ASBRs.

To achieve interoperability between versions of OSPF, these new LSAs cannot be flooded as a new

type. For OSPFv2 we use Opaque LSAs type 11 to achieve AS flooding scope and use the opaque

type field to differentiate between the three new LSAs. Moreover, ABRs perform a translation of the

ASBR-LSAs to ASBR-Summary-LSAs and the Prefix-LSAs to Network-Summary-LSAs to reduce the

number of routers that need to be updated.

38

5Implementation

Contents

5.1 Design Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Intra-area routing implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Inter-area routing implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 OSPF packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5 User interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.6 Python sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

39

5.1 Design Options

The solution presented on the previous chapter, as refereed, works over the actual implementation

of OSPF described in [2] for intra-area routing. To implement and evaluate our solution, we have to use

an implementation of the intra-area routing as described in [2]. We decided to implement the intra-area

routing solution on our own, instead of using another implementation, because the cost to learn and

manipulate another implementation appeared to be bigger than the cost of implementing ourselfs an

implementation that gives us total control.

The solution described in 4.2 was implemented only for OSPFv2 and for routers connected only

to transit networks. Giving the limitation of time, we decided to implement only two of the new LSAs,

the ABR-LSA and Prefix-LSA, and leave the ASBR-LSA implementation for a future work. This means

that our implementation does not support connections to other Autonomous Systems. To simplify our

implementation, our routers do not have implemented the Immediate Replying OSPF Hello procedure,

as explained on 3.2.3.

Our implementation of the solution was developed in Python [16] running in a Fedora [17] machine.

Was programmed using an object oriented approach, because it promotes hierarchy that allows incre-

mental development from small and simple to more complex elements. It is important to highlight this

feature because it allows OSPF packets to share a header with their pairs. The same occurs with LSAs.

The programming language used was Python, because it is easy to understand, has a big community

and has enough performance for this project.

5.2 Intra-area routing implementation

The figure 5.1 illustrates the most relevant parts of the implementation. The main class is responsible

for connecting all the important elements of the implementation. It is responsible for interacting with

the user, giving him the information needed to manage the network and also configure the network.

Moreover, it is responsible for waiting for the multicast packets that may arrive at the active interfaces.

It can switch-on an interface for the OSPF process and give it the tools to interact with the LSDB of the

same area. It is also responsible for creating and updating it Router-LSA for every area it is attached.

5.2.1 The Interface class

Figure 5.2 shows the data flow of information at interface level. The interface is responsible for

managing the relationship with neighbors, to read the received packets, respond to them if necessary

and notify its neighbors and its router when some changes on the network are detected.

To maintain adjacencies with neighbors, the interface is also responsible for sending periodic Hello

40

Figure 5.1: Data flow in the OSPF implementation for intra-area routing.

packets, compute the Designated Router of the network the interface is attached to, , as described in

section 3.1.5, and also perform the Database Description Process described in section 3.2.3.

The Interface runs by the rules of a state machine defined in section 9.3 of the OSPF specification [2],

illustrated in figure 5.3. When an interface is switched on, changes its state from Down to Waiting. In

the Waiting state, the interface starts to send periodic Hello packets and wait for Hello packets from its

neighbors and stays in this state for 40 seconds. After the wait time, the interface uses the Hello packets

received to decide the next state. If the router is the only one connected to the network, it will become

the Designated Router and changes it state to DR. If there is already one router connected to the same

network, it will become the Backup Designated Router and changes to the state Backup. If there are

at least two routers connected to the transit link, it will change to the state DROther. The state of the

interface is essential to define what are the responsibilities of the router in that transit link. In a cold start

situation, the Designated Router will be the router with the biggest priority or, in case of a tie, the router

with the biggest RID. The Backup Designated Router will be the router with the second biggest priority

or, in case of a tie, the router with the second biggest RID.

Every time it creates a new neighbor adjacency the interface creates a Neighbor object and adds that

object to the database of neighbors. Every neighbor in the database is controlled by a state machine

illustrated by figure 5.4. Our implementation uses a simplified state machine as described in section

10.3 of the OSPF [2], since our implementation is only for routers connected to transit networks. In our

implementation, the neighbor is only created after reaching the 2-Way state. This means that the imple-

mentation only lists a neighbor when it sees its RID listed in the Hello packets sent by the neighbor. So

when we create a Neighbor object, the object is started in the 2-Way state. From this point, the router

and its neighbor start the Database Description process, and the Neighbor object changes its state to

ExStart. In this state, the routers decide which router is the master and define the initial DB Description

41

Figure 5.2: Data flow in the OSPF implementation in the interface class.

sequence number. With the master and slave defined and DB Description sequence number deter-

mined, the neighbor changes its state to Exchange. During this state, each router describes its entire

LSDB by sending Database Description packets to the neighbor. The slave router starts this process by

sending DB Description packet containing the LSA Header it contains in the LSDB of the area, acknowl-

edging the DB Description sequence number sent by the master. The master responds with its LSA

present in the LSDB and increments the DB Description sequence number by one. The slave acknowl-

edges DB Description packets sent by the master through echoing of the sequence number. Using the

information received in Exchange state, the routers know what are the LSAs that ist neighbor contains

and can identify what LSAs that it does not have and the ones for which the neighbor has a newer in-

stance. During the Loading state, it can request these LSAs, sending Link State Request packets to the

neighbor with the header of the LSAs to request. When the receiving of LSAs is complete, it changes it

state to Full, meaning that it is fully adjacent to the neighbor and is part of the network. This adjacency

will now have to appear in Router-LSAs and Network-LSAs.

42

Figure 5.3: Interface’s state machine.

Figure 5.4: Neighbor state Machine.

5.2.2 The LSDB class

The LSDB, as illustrated in figure 5.5, is responsible for, in each second, update the LS Age field of

all the LSA it has. When the LSDB receives a new LSA, it has to verify if it already has an instance of

that LSA. If there is an LSA with the same identifier older than the received one it is removed and the

received one replaces it.

If the LSA received by the LSDB is a Network-LSA or a Router-LSA, it constructs the graph of the

elements present in the area and calculates the shortest path to the destinations advertised by the

Network-LSAs, using the Dijkstra’s algorithm, as described in 2.2.1. The shortest paths are delivered to

the forwarding table element.

Since our implementation does not support connections to other Autonomous Systems, only LSAs

with area scope area exchanged. The received LSAs are flooded throughout all the active interfaces of

the router that are running the OSPF and attached to the same area, except the router interface where

the LSA was received. If it was the router that creates the new LSA, it sends to it all the active interfaces

of the router that are running the OSPF and are attached to the same area.

5.2.2.A LSAs for area routing

The LSAs are represented in our implementation as class objects. There are different types of LSAs.

Each LSA is represented by a different type of object. Since all LSAs have an equal header, we use

the hierarchy mechanism to facilitate the building of the data. The figure 5.6 is an UML describing the

LSAs.As present, the Router-LSA, Network-LSA, and Summary-LSA classes are hierarchically inferior

to the class LSA.

The LSA class represents the common header of the LSAs. It defines methods related to the at-

43

Figure 5.5: Data flow in the OSPF implementation of the LSDB element.

tributes of the header. The method CountAge() is a method to increment the LS Age field by one.

setMaxAge() is used to change the LS Age field of the LSA to the value of 3600. The method getHeaderPack()

is used to return the header of the LSA in a machine’s native format for the communication between ma-

chines.

The Router-LSA, Network-LSA and Type-3 Summary-LSA represent the body of the LSA. They re-

define methods from the LSA class based on the proper functions of the different LSAs, which have

different structures. The method printLSA() present some information about the LSA to the user.

calculateChecksum() is used to calculate the checksum and updates the Checksum attribute in the LSA

class. calculateLength() does a similar job but regarding the Lenght attribute. getLSAtoSend() is a

method that returns all the LSA, header and body, in a machine’s native format.

5.2.2.B Graph of the network

The shortest path module uses the Dijkstra’s algorithm, as described in 2.2.1. It uses a graph of the

network as the base for the algorithm execution. The graph is created using the LSAs present in the

LSDB of the area. Our implementation, since it does not support connection with other ASes, only uses

the Router-LSAs and Network-LSAs to construct the graph of the network.

Figure 5.7 shows an example of the construction of the graph. The figure 5.7 (a) shows the example

network. Figure (b) shows the LSDB of the network of figure 5.7 (a). Finally, in figure (c) we represent

the graph of the network, created using the LSAs present in the LSDB. The nodes of the graph represent

the routers and the links of the area. Routers are identified by its RID and links by its Designated Router.

The edges of the graph represent a connection between the nodes. Interfaces described in Router-

44

Figure 5.6: UML of the OSPFv2 LSAs for intra-area routing.

LSAs represent a connection between two nodes, one router to one link. The cost of the respective

edge represents the cost of the interface. The Router IDs listed on the Attached Routers field of the

Network-LSA represent a connection between a link and a router.

5.2.3 Area forwarding table

The figure 5.8 shows the process that happens when the forwarding table receives a new shortest

path to some destination. When the forwarding table receives a computed shortest path, it has to verify

if there is already an entry to the same destination. If that occurs, the entry is replaced by the received

one if they differ on the cost or path to the destination.

A path to a destination is a list of nodes of the graph from the router to the destination. For example,

the path from the router R1 to the subnet Link 3 of the figure 5.7 (a) is [R1, Link 1, R3, Link 3].

The second element of the path determines the outgoing interface and the third element the next hop.

The second element of the path is always the Designated Router of the link. The Designated Router is

compared to the IP addresses assigned to the interfaces to verify if both are on the same subnet. When

45

Figure 5.7: Graph example.

Figure 5.8: Data flow in the OSPF implementation of the forwarding table.

both are in the same subnet, the outgoing interface is found.

5.2.4 Concurrent computing

Main, interface and the LSDB are the principal classes of the implementation. The three have many

tasks that have to be performed in parallel. To do so, they use Python Threads [18] to divide the use of

the processor capabilities into time slots for different tasks.

The figure 5.9 shows how the different threads are triggered. The main thread is responsible for the

user interaction and also runs another thread to wait for multicast packets. When the user switches on

an interface, an interface object is initialized, and a new thread - one per Interface object - is launched

to control the state of the interface and send the periodic Hello packets. At this moment, a new LSDB

object is initialized and a thread to increase the age of the LSAs present is started. Every interface

object represents and controls a physical interface. When the interface has a new neighbor adjacency,

a Neighbors object is created to represent it. Every neighbor object will run another thread to control

its state and increase its inactivity timer. When the router receives a Hello packet from the neighbor, it

restarts to zero it inactivity timer. If the inactivity timer reaches 40 seconds, the Neighbor is no more

considered adjacent, and its object is removed from the list of neighbors of the interface.

46

Every interface object will also start a new thread when it needs to perform the Designated Router

Election process. Also, when the interface creates a new neighbor adjacency, it starts the Database

Description Process, running on a new thread. When a Router-LSA or Network-LSA is created or

received in the LSDB, it starts a new thread to remake the graph, using the LSAs of the respective

LSDB and recalculate the shortest paths to the destinations.

Figure 5.9: Thread initialization and end during the initial running seconds.

47

5.3 Inter-area routing implementation

To implement our solution for inter-area routing, we made a minimal adaptation of the main element,

presented in figure 5.1. When the router is connected to more than one area, the main class is also

responsible for creating and updating the ABR-LSA, presented in section 4.2.1. This new LSA is ap-

pended to the LSDB of the overlay network. It is important to remember that every area will have its

LSDB.

The area forwarding table presented in figure 5.8 acts as auxiliary to construct the Prefix-LSA. As

presented in figure 5.10, the router creates a new Prefix-LSA every time that some entry in the area

forwarding table is added or replaced. It is important to notice that a new Prefix-LSA is only created if

the cost of the destination changes. If the path changes but the cost stay the same, there is no need to

update the Prefix-LSA for the destination.

Figure 5.10: Data flow in the OSPF implementation of the forwarding table.

5.3.1 LSDB of the overlay network

ABR-LSAs and Prefix-LSAs are added to the LSDB of the overlay network, called ABR LSDB. The

ABR LSDB does a similar process as performed by the LSDB of an area. The two differences are that

the ABR LSDB recomputes and recalculates the shortest paths to the destinations every time it receives

a new LSA, not depending on the type of LSA, and it delivers the shortest path calculated to the real

forwarding table, called kernel forwarding table. Figure 5.11 illustrate this process.

As described in section 4.2.1 every ABR will use three new LSAs to flood its local vision of the overlay

network. In this implementation, given the limitation of time, we decide to implement two of them and

leave the ASBR-LSA implementation for a future work.

Similarly to our implementation of the OSPFv2 LSAs, described in section 5.2.2, the new LSAs flow

in the implementation as objects. Also, ABR-LSAs and Prefix-LSAs have a common header, the Opaque

LSA Header described on 4.2.2. This is similar to the LSA Header and only changes in one field of the

structure.

The Opaque LSA class corresponds to the header of the LSAs. The method CountAge() is a method

to increment the LS Age field by one. setMaxAge() is used to change the LS Age field of the LSA to the

value of 3600. The method getHeaderPack() is used to return the header of the LSA in a machine’s

native format for the communication between machines.

48

Figure 5.11: Data flow in the OSPF implementation of the ABR LSDB.

The two new LSAs are hierarchy inferior to the Opaque LSA class and correspond to the body of the

LSA. The method printLSA() present some information about the LSA to the user. calculateChecksum()

is used to calculate the checksum and updates the Checksum attribute in the LSA class. calculateLength()

does a similar job but regarding the Lenght attribute. getLSAtoSend() is a method that returns all

the LSA, header and body, in a machine’s native format. The methods addLinkData(entry) and

removeLinkData(entry) in the ABR-LSA class are to, respectively, add or remove a new ABR Neighbor

in the LSA.

5.3.2 Graph of the overlay network

The graph of the overlay network is important to calculate the shortest paths to the destinations

advertised in the Prefix-LSAs.

The graph is constructed using the ABR-LSAs present in the LSDB of the overlay network. Every

ABR-LSA is a node in the graph, identified by the Advertising Router field of the LSA, which includes

the RID of each router. Every neighbor is a node. The edges represent shortest paths between ABRs.

Every edge has a value, representing the shortest path cost from the originating router to the identified

ABR neighbor.

5.3.3 Shortest path calculation

The figure 5.13 shows the pseudocode used for the calculation of the shortest path to the destina-

tions. The function receives the list of the LSAs that describe the ABR overlay network, the RID of its

49

Figure 5.12: UML of the new LSAs for inter-area routing.

routers, the graph of the overlay network and a pointer to the Forwarding table object.

For every destination announced by a Prefix-LSA, it is calculated its global shortest path cost, adding

the value of the Metric field of the Prefix-LSA to the shortest path cost from the ABR doing the calcu-

lation to the ABR advertising the Prefix-LSA. This process is repeated for every Prefix-LSA announcing

the same prefix, and the least cost path is elected the global shortest path. In this process, Dijkstra’s

algorithm is performed every time that we need to calculate the global shortest path cost from one router

to the Prefix-LSA advertiser. This could be improved by running only one time Dijkstra’s algorithm since

it calculates the shortest path for all the destination in a single run.

The forwarding table object receives the new shortest paths. Similarly to the area forwarding table

present on section 5.2.3, the entries of the forwarding table are only updated when the cost or path

is different from the previous entry. If there is no previous entry for the destination, it is added to the

entries list of the forwarding table object. When an entry on the list is updated or when a new entry is

appended it is also added or updated on the forwarding table of the operating system, using the ip route

command [19]. If an entry of the forwarding table object did not receive any new entry, that means that

there as some change on the network topology and is not possible to communicate to the respective

destination. In this case, the entry for this unreached destination is removed from the forwarding table

50

Figure 5.13: Pseudocode for the algorithm for the shortest path calculations.

of the operating system and from the forwarding table object.

To achieve interoperability with the current OSPFv2 implementations, the ABRs flood in each area

they are directly attached to, Type-3 Summary-LSAs for the destinations that are added or updated in

the forwarding table of the operating system. This notifies the intra-area routers about exterior paths

to an interior or exterior destination. However, since the OSPF restricts the use of area-external routes

when the source and destination routers are in the same area, as described on section 4.1 the global

shortest path is not achieved when the global path for an area-internal destination crosses other areas.

5.4 OSPF packets

OSPF packets are represented in the implementation as class objects. Figure 5.14 shows a UML of

the OSPF packets. There is a class hierarchy superior to represent the header of the OSPF packets.

This header has the same structure for every packet. The OSPF packet object is hierarchy inferior, so

they are also an OSPF header object.

In our implementation, our LS Update packet delivers only one LSA. Also, we send an LS Acknowl-

edgment for every LS Update received. This option was only to simplify the implementation process.

Since the implementation has been used in a controlled scenario, where there are no packets lost, we

do not wait for the respective LS Acknowledgment packet when we send an LS Update packet.

51

Figure 5.14: UML representing the implementation of the OSPF packets.

5.5 User interaction

The main class is responsible for the user interaction. To do so, it has a list of commands that allow

the user to view information about the networks the LSAS flooded and to make changes on the network.

The figure 5.15 shows a list of the commands that the user has to interact with the implemented

router.

The user can switch on an interface using the interface command, followed by the identifier of the

interface, the IP address of the area it will be connected and the cost for the outgoing interface. For

example, the command interface ens33 0.0.0.0 5 switches on the interface ens33 on the backbone

area, giving to the interface a cost of 5.

To visualize the LSAs received and created on the backbone area the command lsdb 0.0.0.0 should

be use. To visualize the LSDB of the overlay network the command is lsdb ABR. It is also possible to

consult the forwarding table of the operating system using the command kernel forwwarding table.

The interface IP address and netmask are not configured in our implementation. To do so, can be

used the desktop application of the operating system or using the ip addr command [19]. For example,

52

Figure 5.15: List of commands that the user has to interact with the implementation.

the command ip addr add 20.20.20.1/24 dev ens33 configure interface ens33 with the IP address

20.20.20.1 having 24 bits allocated for the network prefix.

5.6 Python sockets

Routers communicate, sending OSPF packets, using network sockets. A network socket is an in-

ternal endpoint for sending or receiving packets. We use unicast and multicast packets according on

the OSPF specification. Unicast packets are used in the one-to-one communication from one sender to

one receiver. The Database Description packets are an example of unicast packets. Multicast packets

are used when packets are addressed to a group of destinations, in one-to-many communications. An

example of multicast packets in our implementation is the Hello packets.

5.6.1 Multicast Receiver

Figure 5.16 shows the code used to parametrize the socket to receive multicast packets. Since the

implementation is for OSPFv2, the socket created uses use the address family for IPv4 with the AF INET

definition. Also, since OSPF does not use a transport protocol, the socket type is SOCK RAW. The Bind()

method is called with the multicast. The port is also defined as 89, the port used by OSPF. The socket

is also associated on all the interfaces of the router, excepts the loopback interface.

5.6.2 Unicast Receiver

Figure 5.17 shows the code used to define the socket to receive unicast packets. The method

unicastReceiver() receives the interface address to associate with the socket. Similarly to the multi-

cast receiver, the unicast one is defined as AF INET since the address family is IPv4 and the socket type

is SOCK RAW, since it will receive raw IP packet. To specify the local endpoint as a defined interface, the

53

Figure 5.16: Code to parametrize the socket used to receive multicast packets.

Bind() method is called with the IP address received by the method. The port is defined as 89, the port

used by OSPF.

Figure 5.17: Code to parametrize the socket used to receive unicast packets.

5.6.3 Deliver for multicast and unicast

Figure 5.18 shows the code used to define the socket to transmit packets. The method deliver()

receives the packet to deliver, the list of interfaces where the packet must be sent, the destination IP

address and a flag that defines if the packet is a multicast or unicast one. In both cases, the socket

created uses IPv4 addresses and is a raw socket. If the packet is multicast, the socket is defined to

send the packet through all the interfaces listed in the attribute addr int. If the packet is unicast, it is

not necessary to define the outgoing interface, since, the router knows which is the outgoing interface,

54

consulting the forwarding table of the operating system.

Figure 5.18: Code to parametrize the socket used to deliver packets.

This chapter describes the implementation of the solution described in the previous chapter. Our solu-

tion as developed using Python 2.7 prepared to run on Linux Fedora machines. The implementation of

the intra-area routing of the ABRs was made on our own.

The solution was implemented only to OSPFv2 and with routers connected only to transit networks.

Also, connections to other AS is not supported.

55

6Evaluation

Contents

6.1 Adjacency between a Cisco router and our router . . . . . . . . . . . . . . . . . . . . 58

6.2 Opaque-LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3 OSPF multi-area with a cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

57

The main objective of the evaluation is to prove the correct implementation and operation of the

solution.

The evaluation was performed on a laptop running Windows 10 Pro [20] as operation system, using

GNS3 [8] integrated with the VMWare Worksation Pro [21] to emulate a router using our implementation.

The Wireshark [22] tool was used to analyze the packets transmitted between routers. To test the

integration with the current version of OSPFv2, the GNS3 is the platform that integrates the Cisco [7]

routers with our own routers. The Cisco routers use the image c7200.

6.1 Adjacency between a Cisco router and our router

To test the correct adjacency between a Cisco router and our implementation we used the network

of figure 6.1. It was used to test the adjacency in two different environments differing on the Designated

Router of the link between the router. It was first switched on the Cisco router, becoming them the

Designated Router. After that, our router is switched-on and becomes the Backup Designated router of

the link. Then the Cisco router is switched off and our router becomes the Designated Router. The Cisco

router is switched on again and becomes the Backup Designated Router of the link between routers.

The router R2 is the Cisco router and its RID is 2.2.2.2. The router 1.2.3.4 is our router, and the

label corresponds to its RID. The subnet between them is 20.20.20.0 with a netmask 255.255.255.0.

The Cisco router has one interface with the IP 20.20.20.2, and our router has one interface with the IP

20.20.20.1.

Figure 6.1: Network topology to test the adjacency between a Cisco router and our router.

6.1.1 Hello packets and Designated Router election

The figure 6.2 shows the packets sent between the neighboring routers during the initial synchro-

nization process and adjacency creation. During this process, all the types of OSPF packets are used.

The Hello packets are the base of the process, assuring that the routers have bidirectional connectivity

between them. The image shows us the time of capture of each packet. With this information, we can

see that the two routers send the Hello packets with a periodicity of 10 seconds.

58

Figure 6.2: Packets captures in the link between the routers, using Wireshark.

The figure 6.3 shows the content of the Hello packets send by the two routers at the beginning and

end of the synchronization. In this figure we can verify that each router list the other in its Hello packets,

in the Active Neighbor field. Also it is important to notice that the routers agree in the DR and BDR

election.

6.1.2 Database description process

In the scenario illustrated in figure 6.2, the Cisco router is first initiated and becomes the Designated

Router. The packet 18 is a Hello packet sent by the Cisco router. This is the first hello packet with the RID

of our implementation in the Neighbor field. When our implementation receives this packet, it detects a

new neighbor and adds it to the list of neighbors. Our next Hello packets will also carry this RID of the

Cisco router in the Neighbor field. This is proved by the visualization of the Length column on the image

and with figure 6.3. At that moment, and after the Designated Router election, our implementation starts

the Database Description Process. The packets 19 and 20 correspond to the ExStart state, where the

master, the slave and database description sequence number are defined. The Cisco Router is elected

master since it has a higher RID. Packets 21, 22 and 24 are transmitted during the Exchange state when

routers exchange the LSA Headers. The following LS Requests and LS Updates corresponds to the

Loading state. When routers receive all the LSAs requested, they change the neighbor state to Full.

At this moment, both routers consider each neighbor was adjacent.

The packet 42 is an LS Update sent by our router with an update of the Router-LSA, since the type

of link changed from stub to transit. Packet 43 is a LS Update with the Network-LSA that represents the

59

Figure 6.3: Hello packets data from the scenario illustrated on figure 6.2.

link, sent by the Cisco Router since it is the Designated Router. It is important to notice that all the LS

Update packets are well acknowledged with a LS Acknowledge packet by the two routers.

Figure 6.4 shows the LSDB of the Cisco router for the area 0.0.0.0. It is visible in the figure the

Router-LSA of the Router 1.2.3.4. Also, the figure shows the list of neighbors of the router and our

router is listed as BDR in the Full state.

The figure 6.5 shows the LSDB for the area 0.0.0.0 of our router and the graph constructed for the

same area. The figure shows that routers exchanged their Router-LSAs and the Network-LSA created

by the Cisco router. The figure shows also the graph - as a description of nodes - constructed for the

area, using the LSAs present on the LSDB.

After the network synchronized, the Cisco router was switched off. Upon expiration of the Router-

DeadInterval - the number of seconds before its neighbors declare the router down - our router becomes

60

Figure 6.4: Link State Database presented on the Cisco Router.

Figure 6.5: Link State Database and graph presented on our router for the area 0.0.0.0.

the Designated Router, and the link changes its type, from transit to stub link.

After, the Cisco router is switched on again, and the synchronization is performed again. During the

Database Description process, the Cisco router receives its Network-LSA advertised previously. This

LSA is flushed, i.e. the router changes it LS Age field to the maximum value of 3600 seconds and floods

the LSA to our router to be removed from the LSDB. The Cisco router receives a new Router-LSA

instance from our router, since the link type is now a transit link, and a Network-LSA, created by our

router, that describes the link.

The figure 6.6 shows the LSDB on the Cisco router. There are 3 LSAs: two Router-LSAs, one for

every router and a Network-LSA, this time advertised by our router since it is now the Designated router

of the network. Our router is also listed on the neighbor’s list as DR of the transit link, and the neighbor’s

state Full.

With this test, we confirm that our router is able to make adjacencies with the current versions of the

OSPFv2, connected to transit networks.

61

Figure 6.6: Link State Database presented on Cisco router for the area 0.0.0.0 and list of neighbors.

6.2 Opaque-LSAs

To est the creation and flooding of the Opaque-LSA, is was used the network topology illustrated

on figure 6.7. There are three areas on the network, area 0.0.0.0, 1.1.1.1 and 2.2.2.2. Two ABRs

connect the three areas. The ABR identified by 1.2.3.4 connects the areas 0.0.0.0 and 1.1.1.1..

The ABR 5.6.7.8. connects the areas 1.1.1.1 and 2.2.2.2

Figure 6.7: Network topology to test the Opaque LSAs.

On area 0.0.0.0 there is an intra-area router R2 in a RID 2.2.2.2. The ABR 1.2.3.4 is present in

this area and it is connected to this router.

On area 1.1.1.1, there are the two ABR and two intra-area routers, router R1, with a RID 1.1.1.1.1,

and router R3, with a RID 3.3.3.3. The ABR 1.2.3.4 is connected with router R1 and this is connected

with router R3. The intra-area router R3 is connected with the ABR 5.6.7.8.

On area 2.2.2.2 there is a intra-area router R4, with a RID 4.4.4.4, connected to the ABR 5.6.7.8.

62

Every interface has a cost of 1.

6.2.1 Creation of opaque-LSAs

The ABR-LSAs are created by the ABR routers only when two interfaces are switched on. When

that occurs, the routers create a ABR-LSA and search for its neighboring ABRs by looking up for the

Router-LSA present in each area LSDBs with the B-bit active. This process is repeated every time a new

or a more recent Router-LSA is added to an area LSDB. Prefix-LSAs are created using the information

of the area forwarding table. Every entry in the area forwarding table leads to a Prefix-LSA.

On the network topology shown in figure 6.7, only the routers R2, R1 and R3 are connected, and

router R1 and R3 have already created a neighbor adjacency and synchronized their LSDB. The ABR

1.2.3.4 is then activated, and its two interfaces are switched on. Since the ABR has two interfaces

activated, it creates its ABR-LSA, with no ABR neighbors listed. The Prefix-LSAs are also created and

updated every time the ABR finds a new path for some destination inse an area it is directly attached to.

The figure 6.8 shows the area forwarding table of the 1.2.3.4 and the LSDB of the overlay network.

On the area forwarding table, we can see an entry for every destination of areas that router is connected.

These destinations are advertised by the Network-LSAs. Every entry in the area forwarding table is

composed by the prefix, the shortest path, cost and the next-hop address. For every destination in

the area forwarding table, there is a Prefix-LSA in the LSfDB of the overlay network, advertising the

prefix and the cost from the ABR to the prefix. Also, there is a ABR-LSA, representing the ABR in the

overlay network. This network only contains one ABR at this moment, so this ABR-LSA does not list any

neighbor.

Figure 6.8: Area forwarding table and ABR LSDB on ABR 1.2.3.4.

6.2.2 Flooding

The new LSAs need to be flooded with AS scope to guarantee that they will be received by every

other ABR. To do so in OSPFv2, the Opaque LSA is used, with Opaque type 11.

63

In the scenario illustrated in figure 6.7, all the intra-area routers are already connected and have

already synchronized with their active neighbors. Now the ABR 5.6.7.8 is activated and its interfaces

are switched on. The figure 6.9 shows the area forwarding table and ABR LSDB of the ABR 5.6.7.8,

after the initial synchronization with neighbors.The image shows every Prefix-LSA created by the router

to advertise its shortest path to prefixes in the area forwarding table.

Figure 6.9: ABR 5.6.7.8 initialization, it area forwarding table and area LSDB.

The figure 6.10 shows the packets transmitted between the two intra-area routers of the area 1.1.1.1

(R1 and R3), during the initial synchronization of the ABR 5.6.7.8 with the intra-area router R3. The first

3 LS Update packets contain a new instance of the Router-LSA of the router R3, the Router-LSA of ABR

5.6.7.8 and the Network-LSA advertised by the router R3 to describe the link 40.40.40.0. All the other

LS Update packets correspond to the delivery, by the router R3 to its neighbor R1, of the new or updated

version of the ABR-LSAs and Prefix-LSAs created by the ABR 5.6.7.8. There are more LS Updates

packets transmitted than the needed ones because our implementation updates its LSAs when some

changes on the LSDB occur.For example, when we send a new instance of a Prefix-LSA and the Type-3

Summary-LSA describing the same prefix our router sends a LS Update packet for every LSA. For future

work, we could reduce the number of updates of the LSAs by group new instances of LSAs in one LS

Update packet.

Type-3 Summary LSAs are delivered to the intra-area routers, to inform them about prefixes internal

and external to the area, which are reachable by the ABR. This gives interoperability with the current

implementation of OSPFv2.

The figure 6.11 shows the LSDB of the router R1. This router receives the ABR-LSA - opaque type

20 - and Prefix-LSAs - opaque type 21. The Type-11 Opaque LSAs are not understood by this router

but it keeps them in the LSDB and describes them in the Database Description packets sent during the

synchronization of the databases. This router also receives the Type-3 Summary-LSAs, advertising the

internal and external destinations reachable thought the ABR 5.6.7.8. The Summary-LSAs relative to

30.30.30.0 and 40.40.40.0 will not be considered in the computation of the shortest paths from R1 o

these prefixes, since only intra-area routes are considered for internal destinations. In fact, under the

current OSPF specifications, ABR 5.6.7.8 would not be allowed to inject thee LSAs in area 1.1.1.1.

64

Figure 6.10: Capture of the packets transmitted between routers R1 and R3, during the synchronization of ABR5.6.7.8 with router R3.

Figure 6.11: LSDB of the intra-area router R1.

65

Afterwards, ABR 1.2.3.4 is initiated and its two interfaces are switched on. During the DB Description

Process ABR 1.2.3.4 receives the Router-LSAs and Network-LSAs that describe the areas it is at-

tached. With this information, the router calculates the intra-area shortest path to the prefixes advertised

by the Network-LSAs. Also, it receives the ABR-LSA and Prefix-LSAs advertised by ABR 5.6.7.8.

Figure 6.12 we can see the area forwarding table of the ABR 1.2.3.4 with entries for every intra-

area destination. Also, the figure shows the LSDB of the overlay network, containing the ABR-LSA and

Prefix-LSAs advertised by ABR 5.6.7.8, alongside the ABR-LSA and its Prefix-LSAs.

Figure 6.12: Area forwarding table and ABR LSDB on ABR 1.2.3.4.

Figure 6.13 shows the graph of the overlay network on ABR 1.2.3.4. We can see that the ABRs

have a connection between them since both are in area 1.1.1.1. The figure also shows the kernel

forwarding table of ABR 1.2.3.4. Using the LSAs present in the LSDB of the overlay network, the router

creates the graph of the ABRs and calculates the global shortest paths to all the prefixes announced in

Prefix-LSAs. Also, it adds entries in the kernel forwarding table to give connectivity to the network, using

the global shortest paths.

The global shortest paths calculated are advertised as type-3 Summary-LSAs for the areas the router

is attached. In figure 6.14 we can see the forwarding table of the router R2. We can see that the intra-area

router R2 learned from the type-3 Summary-LSAs advertised by the router 1.2.3.4 a connection to all

the subnets in the network, besides the network it is directly connected. Also, router R2 has connectivity

to the other edge of the network, the router R4, using a path that crosses the tree areas of the network.

With this test we prove that the new LSAs are being flooded thought all the routers in the network,

having AS-scope.

66

Figure 6.13: Graph of the overlay network and kernel forwarding table of ABR 1.2.3.4.

Figure 6.14: Forwardinf table of router R2 and a connectivity test from R2 to R4.

6.3 OSPF multi-area with a cycle

With our solution OSPFv2 supports multi-area with arbitrary topologies. The figure 6.15 shows a

network topology with three areas and three ABRs. This network could not be implemented in the

67

current OSPF version since the multi-area topology contains a cycle. In this topology R1, R2, R3 and R4

are intra-area router and 1.2.3.4, 5.6.7.8 and 9.10.11.12 are ABRs. All the interfaces, to transmit a

packet, have associated a cost of 1, except the interface of router R1 connected to router R3 that has a

cost of 10.

Figure 6.15: Network topology to test OSPFv2 with arbitrary topology.

The figure 6.16 shows the graph of the overlay network calculated after the flooding of the Opaque-

LSAs by the ABRs. This graph is equal in all the ABRs. All the ABRs have found the shortest path to

their neighboring ABRs. The shortest path from ABR 1.2.3.4 to ABR 5.6.7.8 has a cost of 12. In the

reverse direction, the shortest path from ABR 5.6.7.8 to 1.2.3.4 has a cost of 3. All the other shortest

paths between ABRs have a cost of 2.

Figure 6.16: Graph calculated of the overlay network, from ABR 1.2.3.4.

The figure 6.17 shows the Type-3 Summary-LSAs received by router R1 relative to the prefix 50.50.50.0.

It receives one Type-3 Summary-LSA from ABR 1.2.3.4 advertising a cost to the destination of 4 and

another Type-3 Summary-LSA from 5.6.7.8 advertising a cost of 1. The router must add this cost to

the shortest path cost from itself to the advertising ABR, in order to determine the least cost path to

50.50.50.0.

The shortest path cost from router R1 to ABR 1.2.3.4 is 1 and to ABR 5.6.7.8 is 11. So, the global

shortest path from router R1 to the prefix 50.50.50.0 is thougth ABR 1.2.3.4, with a cost of 5. The

figure 6.18 shows the OSPF forwarding table of router R1. Also, it shows the result of the traceroute

68

Figure 6.17: Type-3 Summary-LSAs received by router R1 relative to the prefix 50.50.50.0.

command to the prefix 50.50.50.0, showing that the router chooses to communicate with this prefix

using the path that crosses the ABR 1.2.3.4.

Figure 6.18: OSPF forwarding table of router R1 and traceroute to the prefix 50.50.50.2.

Afterwards, we change the cost of the interface of router R2 connected to the ABR 9.10.11.12 from

1 to 10. This forces router R2 to change its Router-LSA. The update of this LSAs makes ABRs 1.2.3.4

69

and 9.10.11.12 update their Prefix-LSAs and ABR-LSAs. With this change on the topology, the Prefix-

LSA of the prefix 50.50.50.0 advertised by the ABR 1.2.3.4 has a new cost of 13. As the figure 6.19

shows, the Type-3 Summary-LSA created by the 1.2.3.4 to advertise the prefix 50.50.50.0 is updated

with the new cost.

Figure 6.19: Type-3 Summary-LSAs received by router R1 relative to the prefix 50.50.50.0.

With the new Type-3 Summary-LSA received, router R1 recalculates the shortest path to the prefix

50.50.50.0. The figure 6.20 shows the new OSPF forwarding table, where we can see that now it sends

packets to subnet 50.50.50.0 with a cost of 12 via router R3 (next hop address is 30.30.30.2). Also, the

figure shows the result of the traceroute command to the prefix 50.50.50.0, showing that the router

R1 now chooses to communicate with this prefix using the path that crosses the ABR 5.6.7.8.

With this test we prove that it is possible to allow OSPF to have multi-area networks with arbitrary

topologies.

70

Figure 6.20: OSPF forwarding table of router R1 and traceroute to the prefix 50.50.50.2.

In this chapter, we provide an evaluation of the implementation. We use the GNS3 platform to integrate

our implemented solution, running on VMS, with Cisco routers.

The first tests prove the adjacency of our implemented ABR with the Cisco routers. These tests prove

the good function of the intra-area implementation of the OSPFv2.

The second tests prove the well functioning of the Opaque-LSAs, proving that the new LSAs are being

flooded through all the router in the network.

The third tests evaluate the extension and prove that it allows multi-area with arbitrary typologies, being

adaptable to changes in the topology. Moreover, these tests prove that this extension interoperates with

the current OSPFv2 implementations.

71

7Conclusion

73

Link State routing is widely used in today’s Internet for routing inside Autonomous Systems. The

OSPF protocol builds and maintains a map of the network that is constructed with the local view of every

router in the network. Each router stores in a LSDB the network map constructed by joining its local

view with the local views of the other routers. It is based on this LSDB, that is equal in every router, that

routers build their forwarding tables.

When an LSDB become large, OSPF offers the possibility of structuring the network in smaller areas.

Each area will have its LSDB that will be different from the LSDB of other areas. OSPF uses a DV

approach for inter-area routing, i.e. for the exchange of routing information across areas.

OSPF restricts their multi-area networks to a 2-level hierarchical structure due to the convergence

problems of the distance vector routing protocols. Also, the current version of OSPF does not achieve

optimal global routing in some situations.

This document presents a solution that removes these restrictions, based on a Link State Routing

for inter-area communications. The solution introduces three new LSAs. ABR-LSAs describe the ABR

overlay network. The Prefix-LSAs and ASBR-LSA describe destination addresses. To achieve inter-

operability with the current versions of OSPF, the solution makes use of the Type-3 Summary-LSAs in

OSPFv2 to inject inside each area information of area-external address prefixes, and the shortest cost

to reach them. The solution will also use the ASBR-LSAs to inject information on area-external ASBRs

and the shortest cost to reach them.

Our implementation was designed for OSPFv2 and routers connected only to transit networks. The

ASBR-LSAs were not implemented, so our solution was not evaluated when connected to others ASes.

The evaluation shows that our solution works for OSPFv2, allowing multi-area with arbitrary topolo-

gies. Also, it only requires updating the Area Border Routers, and it interoperates with current OSPFv2

implementations

For future work it is important to evaluate this solution in other scenarios. For example, it is essential

to implement and test the injection AS external destinations using ASBR-LSAs. Also, we need to evalu-

ate the solution for different types of links, like point-to-point links or stub links. Another point for future

work is the submission of this extension as an Internet Draft.

74

Bibliography

[1] R. Valadas, “OSPF extension for the support of multi-area networks with arbitrary topologies,”

arxiv.org, 2017. [Online]. Available: http://arxiv.org/abs/1704.08916

[2] J. Moy and Ascend Communications, “RFC 2328 - OSPF Version 2,” 1998. [Online]. Available:

https://tools.ietf.org/html/rfc2328

[3] International Standardization Organization (ISO), “Information technology - Telecommunications

and information exchange between systems - Intermediate System to Intermediate System intra-

domain routeing information exchange protocol for use in conjunction with the protocol for providing

the connectionless,” vol. 2004, no. Iso 8473, p. 201, 2002.

[4] Y. Rekhter and T.J. Watson Research Center, “RFC 1771 -A Border Gateway Protocol 4,” 1995.

[Online]. Available: https://tools.ietf.org/html/rfc1771

[5] Cisco Systems, “What Are OSPF Areas and Virtual Links? - Cisco,” 2016. [Online]. Available:

http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13703-8.html

[6] J. T. Moy, OSPF: Anatomy Of An Internet Routing Protocol, Addison-Wesley, Ed., 1998.

[7] I. Cisco Systems, “Cisco Systems, Inc.” [Online]. Available: http://www.cisco.com/

[8] G. T. Inc., “GNS3.” [Online]. Available: https://www.gns3.com/

[9] J. F. Kurose and K. W. Ross, Computer Networking A Top-Down Approach, 2013, no. 5.

[10] G. Malkin and Bay Networks, “RFC 2453 - RIP Version 2,” 1998. [Online]. Available:


[11] J. T. Moy, OSPF Complete Implementation. Addison Wesley, 2001.

[12] IETF, “RFC 5340 - OSPF for IPv6,” 2008. [Online]. Available: http://www.ietf.org/rfc/rfc5340.txt

[13] N. W. Group and J. Moy, “Multicast Extensions to OSPF Status of this Memo,” Options, pp. 1–70,

1994.

75

http://arxiv.org/abs/1704.08916



http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13703-8.html

http://www.cisco.com/

https://www.gns3.com/


http://www.ietf.org/rfc/rfc5340.txt

[14] Z. Kou, “Update to OSPF Hello procedure.” [Online]. Available: https://tools.ietf.org/html/

draft-kou-ospf-immediately-replying-hello-02

[15] L. Berger, “The OSPF Opaque LSA Option,” pp. 1–17, 2008. [Online]. Available: https:

//tools.ietf.org/html/rfc5250

[16] P. S. Foundation, “Python.org.” [Online]. Available: https://www.python.org/

[17] “Get Fedora.” [Online]. Available: https://getfedora.org/

[18] Python Software Foundation, “16.2. threading — Higher-level threading interface — Python 2.7.12

documentation.” [Online]. Available: https://docs.python.org/2.7/library/threading.html

[19] M. Litvak, “ip(8) - Linux man page.” [Online]. Available: https://linux.die.net/man/8/iphttp:

//linux.die.net/man/8/ip

[20] Microsoft, “Windows — Official Site for Microsoft Windows 10 Home, S & Pro OS, laptops, PCs,

tablets & more,” 2017. [Online]. Available: https://www.microsoft.com/en-us/windows

[21] VMware Inc., “Windows VM — VMware Workstation Pro,” 2017. [Online].

Available: https://www.vmware.com/products/workstation-pro.htmlhttps://www.vmware.com/uk/

products/workstation-pro.html%0Ahttps://www.vmware.com/products/workstation-pro.html

[22] W. Foundation, “Wireshark.” [Online]. Available: https://www.wireshark.org/

76

https://tools.ietf.org/html/draft-kou-ospf-immediately-replying-hello-02

https://tools.ietf.org/html/draft-kou-ospf-immediately-replying-hello-02



https://www.python.org/

https://getfedora.org/

https://docs.python.org/2.7/library/threading.html

https://linux.die.net/man/8/ip http://linux.die.net/man/8/ip

https://linux.die.net/man/8/ip http://linux.die.net/man/8/ip

https://www.microsoft.com/en-us/windows

https://www.vmware.com/products/workstation-pro.html https://www.vmware.com/uk/products/workstation-pro.html%0Ahttps://www.vmware.com/products/workstation-pro.html

https://www.vmware.com/products/workstation-pro.html https://www.vmware.com/uk/products/workstation-pro.html%0Ahttps://www.vmware.com/products/workstation-pro.html

https://www.wireshark.org/

OSPF extension to support multi-area networks with arbitrary ......IPv4 (OSPFv2) and IPv6 (OSPFv3)....

Documents

Transcript of OSPF extension to support multi-area networks with arbitrary ......IPv4 (OSPFv2) and IPv6 (OSPFv3)....