• No results found

Internet Topology Discovery Using Active Probing

N/A
N/A
Protected

Academic year: 2021

Share "Internet Topology Discovery Using Active Probing"

Copied!
130
0
0

Loading.... (view fulltext now)

Full text

(1)

U

NIVERSIT

A DEGLI

`

S

TUDI

R

OMA

T

RE

D

OTTORATO DI

R

ICERCA IN

I

NGEGNERIA

I

NFORMATICA

XVIII C

ICLO

– 2006

Internet Topology Discovery Using Active Probing

(2)
(3)

U

NIVERSIT

A DEGLI

`

S

TUDI

R

OMA

T

RE

D

OTTORATO DI

R

ICERCA IN

I

NGEGNERIA

I

NFORMATICA

XVIII CICLO- 2006

Lorenzo Colitti

Internet Topology Discovery Using Active Probing

Thesis Committee

Prof. Giuseppe Di Battista (Advisor)

Reviewers

(4)

Lorenzo Colitti

Viale dell’Umanesimo 47

00144 Roma

Italy

E

-

MAIL

:

lorenzo@colitti.com

WWW

:

http://www.colitti.com/lorenzo/

(5)
(6)
(7)

Introduction

The size, rate of change, and fragmented administration of the Internet make it impractical to represent its topology using conventional methods such as network diagrams. In order to ob-tain accurate, up-to-date, and comprehensible information on topology, the use of automated tools is essential.

Many methods for automatic network topology discovery have been proposed in recent years. While facing the same problems, the methods differ in the approach they adopt and in the data sources they make use of. Some concern themselves with interdomain topology discovery at the Autonomous System level, others perform intra-domain topology discovery at the node level. Some simply query existing data sources and present the results, while others actively probe the network and observe the effects in order to deduce topology. Since they measure the actual behaviour of the network at the time of the discovery process, the methods that make use of active probing can produce more accurate and up-to-date results. Furthermore, they allow the discovery process to be targeted at areas of particular interest, without concerning themselves with the behaviour of the rest of the network.

This thesis focuses on novel applications of active probing for topology discovery that were developed in the course of my research work between 2002 and 2005. Two main results are presented: methodologies for topology discovery in networks involving IPv6-in-IPv4 tunnels and methodologies for discovering the propagation of BGP announcements in the interdomain topology. In both cases the results obtained are compared to those obtainable by simply querying known sources of information, showing that active probing allows for much greater accuracy and targeted observation. The IPv6 work has already been published in con-ference and journal form [31, 32], while the work on BGP, currently available as a technical report [33] has recently been accepted for publication at an international conference [34].

The document is organised in four parts. Part I provides an introduction to network topology discovery: Chapter 1 presents motivations and applications, Chapter 2 provides initial definitions, and Chapter 3 provides a taxonomy of existing methods and tools. Part II presents our IPv6-in-IPv4 tunnel discovery methods: Chapter 4 gives an introduction to IPv6 tunnelling and the types of tunnels used, Chapter 5 gives an overview of the methods, and

(8)

Chapter 6 presents applications and results. Part III presents our BGP probing methods: an introduction to the problem and an analysis of the shortcomings of existing methodologies in Chapter 7 is followed by a description of the methods in Chapter 8, and applications and results in Chapter 9. Part IV contains conclusions.

Acknowledgements

I am grateful to the members of my research group Giuseppe Di Battista, Maurizio Patrignani and Maurizio Pizzonia, without whom this work would not have been possible. Valuable contributions to this work came from Massimo Rimondini, who worked on the evaluation of our active BGP techniques, and from Davide De Micco, who implemented the Tunnelcheck and Tunneltrace tools.

I would like to thank Henk Uijterwaal, Monica Cortes and the RIS team at the RIPE NCC for hosting me and providing me with the opportunity to perform measurements from the test-boxes of the TTM project, access to the RIS database and routing infrastructure, and support for routing equipment tests. I would also like to thank Kenjiro Cho and the WIDE project for comments and help on MTU measurements from Japan, and Maurizio Goretti and Gabriele Barbagallo from CASPUR for access to IPv6 routing infrastructure. Finally, thanks go to Daniel Karrenberg, Tim Griffin, Geoff Huston, Randy Bush and Ruediger Volk for useful discussion.

(9)

Contents

I

Background

1

1 Internet Topology Discovery 3

1.1 Motivations . . . 3

1.1.1 An example: troubleshooting routing oscillations . . . 4

1.2 Applications . . . 5

2 Background and Definitions 9 2.1 Topology discovery . . . 9

2.2 Network layers . . . 9

2.3 The Internet Protocol . . . 10

2.4 IP addresses and names . . . 11

2.5 IP routing . . . 11

2.5.1 Address prefixes . . . 12

2.5.2 Node-level and AS-level routing . . . 12

2.5.3 Basic BGP concepts . . . 12

3 Topology Discovery Methods 15 3.1 Introduction . . . 15

3.1.1 Topology discovery at various network layers . . . 15

3.1.2 IP topology discovery . . . 16

3.2 Methods using equipment queries . . . 16

3.2.1 Evaluation . . . 17

3.3 Methods using registry data . . . 18

3.3.1 Internet registries . . . 18

3.3.2 Topology discovery using registry data . . . 19

3.3.3 Evaluation . . . 20

3.4 Methods using BGP routing data . . . 21

3.4.1 BGP Data Sources . . . 21 iii

(10)

3.4.2 Static analyses: BGP routing table dumps . . . 22

3.4.3 Dynamic analyses: BGP update traces . . . 24

3.4.4 Evaluation . . . 26

3.5 Methods using probe packets . . . 27

3.5.1 Traceroute and hop-limited probes . . . 27

3.5.2 Alias resolution . . . 29

3.5.3 Distributed probing . . . 30

3.5.4 Obtaining interdomain topology using probe packets . . . 31

3.5.5 Implementations . . . 31

3.5.6 Evaluation . . . 34

3.6 Conclusions . . . 35

II

IPv6-in-IPv4 Tunnel Discovery

37

4 Introduction 39 4.1 Tunnelling . . . 39

4.1.1 IPv6-in-IPv4 tunnels . . . 39

4.1.2 Types of tunnels . . . 40

4.2 Motivations for tunnel discovery . . . 44

4.3 The tunnel discovery problem . . . 44

4.4 Our approach . . . 45

5 Tunnel Discovery Methods 47 5.1 Definitions . . . 47

5.2 Tunnel discovery methods . . . 48

5.2.1 Primitives . . . 48

5.2.2 Discovery rules . . . 49

5.3 Tunnel discovery tools . . . 56

5.3.1 FindMTU . . . 56

5.3.2 Tunnelcheck . . . 56

5.3.3 Tunneltrace . . . 57

6 Applications and Results 59 6.1 Experimental results . . . 59

6.1.1 Status of the 6bone registry . . . 59

6.1.2 Rule validity data . . . 60

6.1.3 MTU survey . . . 61

(11)

CONTENTS v

6.2 Security considerations . . . 64

6.3 Conclusions . . . 64

III

Active BGP Probing

67

7 Introduction 69 7.1 The problem . . . 69

7.2 Shortcomings of existing methods . . . 70

7.3 Our approach . . . 71

8 Active BGP Probing 75 8.1 Background and definitions . . . 75

8.2 BGP probing primitives . . . 77

8.2.1 Withdrawal observation . . . 77

8.2.2 AS-set stuffing . . . 78

8.2.3 Practical limitations . . . 79

8.3 Discovery techniques . . . 79

8.3.1 Obtaining a feasibility graph . . . 80

8.3.2 Path feasibility determination . . . 82

8.3.3 Path preference comparison . . . 82

8.4 Effects of route-flap dampening . . . 83

8.5 Operational impact and ethical issues . . . 83

8.5.1 Feasibility and impact of large AS-sets . . . 84

8.5.2 Impact on routers . . . 85

8.5.3 Impact on debugging . . . 85

8.5.4 Ethical considerations . . . 86

9 Applications and Results 87 9.1 Experimental setup . . . 87

9.2 Generating BGP updates:announcer . . . 88

9.3 Results . . . 88

9.3.1 Prefix propagation discovery . . . 88

9.3.2 Comparison with the full AS graph . . . 90

9.3.3 Discovering the peers of an upstream ISP . . . 91

9.3.4 Path feasibility determination and preference comparison . . . 92

9.3.5 Impact of route-flap dampening . . . 96

(12)

IV

Conclusions

99

10 Conclusions 101

10.1 Contribution to the field . . . 101

10.2 The importance of active probing . . . 101

10.3 Security implications . . . 102

(13)

List of Figures

1.1 How topology discovery tools can aid troubleshooting . . . 4

2.1 An example IP topology . . . 10

3.1 Polyphemus displaying an OSPF network . . . 17

3.2 Output of WHOIS queries to the RIPE database . . . 18

3.3 Hermes displaying IRR data . . . 19

3.4 Example output from thetraceroutecommand . . . 28

3.5 Resolving IP aliases . . . 30

3.6 Example topologies obtained by Rocketfuel . . . 34

4.1 IPv6-in-IPv4 encapsulation . . . 40

4.2 Types of tunnels . . . 41

4.3 Three IPv6 sites interconnected using 6to4 tunnels . . . 43

4.4 Routing using a 6to4 relay router . . . 43

4.5 An IPv6-in-IPv4 tunnel . . . 45

5.1 A link in a path and its associated interfaces . . . 50

5.2 Packet injection . . . 51

5.3 Injected ping . . . 52

5.4 Example FindMTU output . . . 56

6.1 Percentage of tunnelled prefixes . . . 62

6.2 Evolution of the percentage of tunnelled prefixes . . . 63

6.3 Bypassing IPv6 firewalls using tunnels . . . 65

7.1 Discovering additional topology using AS-set stuffing . . . 72

7.2 Complete topology discovered using our methods . . . 73

8.1 Limitations of AS-set stuffing . . . 78 vii

(14)

8.2 The level-by-level exploration algorithm . . . 81 9.1 Sampleannouncerconfiguration file . . . 89 9.2 Extent of the topologies obtained using BGP probing . . . 91 9.3 Using targeted announcements to discover the peers of an upstream ISP . . . 93 9.4 Path preference comparison . . . 93 9.5 Effects of route flap dampening . . . 97

(15)

List of Tables

5.1 Classification of tunnel discovery rules . . . 50

6.1 Status of tunnels in the 6bone registry . . . 60

6.2 Path MTU values from our vantage points to the Internet . . . 61

9.1 Extent of the topologies obtained using BGP probing . . . 90

9.2 A comparison of our methods with conventional strategies . . . 92

9.3 Path feasibility determination results. . . 94

9.4 Path preference comparison results. . . 95

(16)
(17)

Part I

Background

(18)
(19)

Chapter 1

Internet Topology Discovery

Automated discovery tools are essential to obtain up-to-date, accurate, and comprehensible information on topology. This information is useful both for studying the structure of the Internet and the behaviour of network protocols and for operational purposes.

1.1

Motivations

In the Internet, as in any network, knowledge of the topology is a fundamental prerequisite for the efficient administration of the network itself. Troubleshooting, network planning, performance analysis and optimisation, network service placement, and simulation all require that the underlying network topology be known to some degree. While in small networks with relatively simple and static topologies it may still be possible to rely on human memory, manual control and documents such as maps, such an approach is not feasible in the Internet for several reasons.

The first is its size. The Internet is a global network that connects hundreds of millions of nodes [67], and, taken as a whole, is beyond human memory or comprehension. Thus, any useful representation of the Internet needs to filter the information to be displayed, visualising only small portions of the network at a time or displaying the topology at varying degrees of detail. This cannot be done using static documents such as network maps, but it may be done with topology discovery tools. For instance, a tool could display only the interdomain topology of the Internet — or only the portion of the Internet involved by a particular Internet Service Provider (ISP)’s traffic, or only the interconnections between networks up to a certain distance away — while still allowing the user to examine the rest of the topology as desired. The second reason is the distributed administration of the Internet. The Internet is par-titioned into tens of thousands [65] of independent administrative domains known as Au-tonomous Systems (ASes). Each AS is responsible for routing network traffic within its

(20)

(a) (b)

Figure 1.1: How topology discovery tools can aid troubleshooting: (a) a list of BGP updates; (b) the same data presented by the BGPlay tool as a graphical animation. The graphical layout produced by BGPlay is orders of magnitude easier to understand for a human operator.

boundaries and does not typically reveal internal details to other ASes. Depending on its size, the AS may be further subdivided into smaller portions that are managed separately. Even if this is not the case and the complete topology of an AS is available to the AS’s ad-ministrators, up-to-date information on routing in and between other ASes is rarely available. Finally, the Internet is in constant change. Virtually all networks of any appreciable size rely on routing protocols to distribute routing information through the network dynamically, to deal with connectivity problems, and to perform traffic engineering. Interdomain routing changes constantly due to routing policy changes, network faults, and configuration errors. Furthermore, networks are continually being upgraded and reconfigured to deal with chang-ing traffic patterns, peerchang-ing strategies, and equipment replacement. Thus, even if it were somehow possible manually to create a map of any sizable portion of the Internet, maintain-ing it up-to-date would be a virtually impossible task.

1.1.1

An example: troubleshooting routing oscillations

As an example of how topology discovery tools can help address these problems, consider Fig. 1.1, which shows prolonged routing oscillations around the network of AS 28998 on 29 April 2004. Without any topology discovery and visualisation tools, an administrator of any other network — indeed, anyone except the administrators of AS 28998 themselves — who observed poor connectivity to destinations in AS 28998 would be hard pressed to discover the cause of the problem. Once the oscillations had stopped, this would no longer even be possible, because routers do not log the history of routing changes.

(21)

1.2. APPLICATIONS 5

Route Views project [131] collect BGP routing updates from multiple sources around the world and archive the results, thus allowing anyone to view routing changes that occurred in the recent past. Fig. 1.1(a) shows the output of a query to the RIS service, which is a list of BGP updates. Since the list is over 30 screenfuls long and reports routing information from tens of different ASes, it is still difficult for an operator to interpret. Fig 1.1(b) shows the same data interpreted and visualised by the BGPlay tool [30], which constructs an interdomain topology graph from the routing data and displays routing changes by animating the graph. The topology of the network and the routing oscillations are immediately visible. Thus, all a network operator has to do to display routing instabilities is enter a time interval and a network prefix into one of the BGPlay instances [115, 116]. This drastically reduces the time necessary to diagnose and resolve network faults.

1.2

Applications

As we have seen, if up-to-date, accurate, up-to date, and comprehensible information on topology is desired, automated tools are essential. We will now discuss how this information may be used. Firstly, from a more theoretical perspective, topology information is useful to comprehend of the behaviour of the network and the protocols it uses. For example, it is useful for:

Inferring properties of the Internet and modelling its growth The availability of topology data allows research on graph-theoretic and topological properties of the Internet. For example, pioneering work by Faloutsos et al. [45] showed that, despite the apparent randomness of the Internet, several power laws hold on its topology with a very high degree of correlation, and that the Internet is a scale-free network with a power-law de-gree distribution. Subsequent work revealed further power-laws [84]. Such work can provide insights of the driving forces of the Internet’s evolution and on how to model the processes of Internet growth [139].

Network simulation The first step in any simulation is the characterisation of the phenom-ena to be simulated. Obtaining credible results from network simulations requires that the topologies used in the simulations be realistic; however, network topology gener-ation, especially for large networks, is not as simple a problem as it might seem [98]. The development of realistic topology generators requires knowledge of the topology of real networks, and thus topology discovery tools [90, 26, 128].

Analysis of protocol behaviour Network protocols are designed to be independent of the underlying network topology. However, while topology should have no effect on the correctness of network protocols, it can have a major impact on their performance.

(22)

For example, the impact of topology on routing protocol performance has been exten-sively studied by Labovitz et al. in [76], which touches on the relationship between interdomain topology and BGP convergence times, and by Mao et al. in [86], which examines how topology influences the impact of route flap dampening. The impact of topology on the scalability of multicast is analysed in [100] and [105]. Related work has also studied the impact of topology on the efficacy of denial-of-service counter-measures [119, 97].

Topology-aware algorithms The availability of topological information allows the devel-opment of algorithms that use this information to maximise quality of service. For example, knowledge of the interdomain topology allows multihomed ASes to apply route selection algorithms in a scalable way [80].

Inferring business relationships between ISPs The AS-level topology of the Internet is a product of the interconnections between the ASes that participate in the global routing system and of the BGP routing policies of those ASes. BGP allows the specification of complex routing policies, which in today’s Internet are motivated not only by technical reasons but also by economic considerations such as only providing transit service to paying customers or controlling the cost of links [17, 64]. Therefore, analysis of the AS-level topology of the Internet can be used to deduce the commercial relationships between the ISPs that make up the core of the network [48, 127, 38]. This not only offers insight into the economic underpinnings of the structure of the current Internet, but also has more practical implications for peering agreements and the choice of transit providers.

Secondly, from a more practical perspective, effective and automated topology discovery tools are helpful in various operational scenarios. For example, they are useful for:

Troubleshooting Analysis and resolution of network faults obviously requires the availabil-ity of accurate and up-to date information on the topology of the network itself. In small to medium-sized networks, where information on topology is likely available in the form of design documents and maps but is not easy to keep up-to-date, the avail-ability of real-time network topology discovery tools can help reduce overhead. For larger, more dynamic networks and especially in interdomain routing, where topology is complex and topology information is often not available, the use of tools is essential both to obtain the information and to present it in a manner comprehensible to network operators.

Network planning and optimisation Optimising network performance and performing ef-fective traffic engineering obviously requires that the topology and the behaviour of the

(23)

1.2. APPLICATIONS 7

network be known. While in small networks this information is likely to be available, for large networks it may be harder to obtain; in interdomain routing, where network performance depends to a great extent on the BGP policies and peering agreements of neighbouring ASes, this is often considered to be proprietary information. In Part III we present methodologies for interdomain topology discovery that also allow the par-tial discovery of routing policies of other ASes.

Service placement Knowledge of topology allows network administrators to determine the optimal placement of network services. Since users topologically closer to the service will, all other things being equal, experience better performance, knowledge of the network topology can help ensure good performance and spread server load. This is especially true in distributed architectures such as a high-traffic web sites or content distribution networks [104].

Although all these applications require network topology discovery, they differ in the data they use and in the topologies they concern themselves with. A description of existing topol-ogy discovery methods, the principles they use and the data they obtain, is given in Chapter 3; but before we discuss these, Chapter 2 will provide background information and definitions of the terms which we will use in the rest of this work.

(24)
(25)

Chapter 2

Background and Definitions

Before discussing topology discovery techniques, we provide a brief introduction to the ar-chitecture of the Internet and definitions of the terms that will be used later in the text.

2.1

Topology discovery

We define network topology discovery as a process by which an entity on the network gathers information about the topology of the network itself. Topology discovery can occur in many ways and at many levels in the network and is strongly tied to the network architectures and protocols used. Therefore, before discussing topology discovery methodologies we provide a brief introduction to the architecture of the Internet and the protocols it uses.

2.2

Network layers

Network implementations are usually designed as a layered architecture, in which every layer provides communication primitives to the layer immediately above it using the primitives provided by the layer immediately below it. Communication between different nodes in the network occurs between two entities in the same level through a set of rules known as a

protocol. The ISO OSI model [69], which is often used as a reference model for network

implementations, describes a seven-layer architecture. The lowest layer is the physical layer, which specifies the physical characteristics of the communications medium and the signals that travel on it. Immediately above the physical layer is the data-link layer (henceforth, link

layer), which defines the logical organisation of bits on the medium. Both these layers vary

from one part of the network to the other according to the communications media and the protocols used in that part of the network. The third layer, the network layer, is common to

(26)

Figure 2.1: An example IP topology showing hosts, routers, links and interfaces

all the nodes in a network; this layer provides routing, that is, it takes care of transferring data from one node in the network to another using one or more network links.

2.3

The Internet Protocol

The network-layer protocol used by the Internet is the Internet Protocol (IP). The version of IP currently in use in the majority of the Internet is IPv4 [102], but many nodes and networks also implement IPv6 [37]. The routing behaviour of IPv4 and IPv6 are very similar, as are the routing architectures and topologies used with the two protocols; thus, most of what follows can be applied indifferently to either protocol, and unless it is necessary to distinguish between IPv4 and IPv6 because of differences in behaviour or operational practices, in the following we will simply write “IP”.

We term node a device that implements IP; a router is a node that forwards IP packets for other nodes, and a host is a node that is not a router. A link a communication medium offered by the underlying link-layer protocol over which IP may transmit packets (for example, an Ethernet network). An interface is a node’s attachment to a link (for example, an Ethernet interface). See Fig. 2.1. IP addresses are assigned to interfaces. In IPv4 an interface usually has one IP address, while in IPv6 an interface typically has more than one address assigned to it.

(27)

2.4. IP ADDRESSES AND NAMES 11

2.4

IP addresses and names

IPv4 addresses are 32 bits long and are written in “dotted-quad” decimal notation, such as

193.204.161.49. IPv6 addresses are 128 bits long and are written in colon-separated

hex-adecimal notation, such as 2001:760:4::1 (where:: is the abbreviation of two or more consecutive groups of zeros).

Since IP addresses are inconvenient to remember, most Internet hosts also have names associated with them. Mappings between names and IP addresses and vice versa are handled by the Domain Name System (DNS) [93, 92]. For example, the namewww.ripe.net corre-sponds to the IPv4 address193.0.0.214and the IPv6 address2001:610:240:0:a843::8. The DNS is a distributed database in which domain names are maintained in a hierarchical tree structure. At the top of the hierarchy are the DNS root servers, which maintain the au-thoritative list of servers for top-level domains such as .com, .net and .org. Any DNS query, except for queries made for a local domain, requires a response from a root server to be an-swered; however, since answers are cached, only a small percentage of total DNS queries actually reach the root servers.

2.5

IP routing

IP handles the delivery of packets between nodes on the Internet. It requires the underly-ing link-layer technologies to support the delivery of a packet from one node to another on the same link, and provides the transport layer with best-effort, connectionless delivery of a packet from one node to any other node1on the Internet, regardless of network topology and of the underlying link-layer technologies used [125].

If the source and destination nodes are not on the same link, the packet will pass through one or more routers on the way to its destination, where every router shares a link with the next router in the path or with the destination. Routing in IP is typically destination-based: every router maintains a forwarding table, which contains, for every destination, the address of the next router and the outgoing interface that the packet needs to be sent on. When a packet needs to be forwarded, the router consults its routing table and sends the packet to the next router or to the destination. The path taken by a packet is thus not known in advance, but determined by the routers along the path at the time of forwarding.

IP does not specify how routing tables are generated; they may be constructed manually or generated automatically using a routing protocol that propagates information on how des-tinations in the network can be reached. In practice, the manual construction of routing tables is infeasible except in extremely small networks, and routing in the Internet is dynamic and handled by routing protocols.

(28)

2.5.1

Address prefixes

In order to reduce the number of routing table entries, IP addresses are routed in contiguous blocks of addresses known as prefixes. All the addresses of a prefix have the first n bits of the addresses in common, where n is the prefix length. Prefixes may be written as the first address of the prefix followed by a slash and the prefix length, such as193.204.0.0/15for an IPv4 prefix or2001:760::/32for an IPv6 prefix. When the IPv4 addressing architecture was first proposed, addresses were divided into classes according to where they were located in the address space and prefixes were 8, 16, or 24 bits long according to the class of the addresses they contained. Since the introduction of Classless Inter-Domain Routing (CIDR) [106], prefix lengths are no longer constrained to these values.

2.5.2

Node-level and AS-level routing

Routing in the Internet takes place at two hierarchical levels. At the highest level, the Internet is partitioned into tens of thousands of networks known as Autonomous Systems (ASes). An AS typically corresponds to an ISP or to a large organisation and is identified by an integer number.

Within an AS, routing occurs at the node level and is handled by an IGP (Interior Gateway Protocol) such as OSPF [95] or IS-IS [21]. An IGP typically has complete knowledge of the topology of the network and provides rapid convergence and shortest-path routing within an AS, but does not easily scale to beyond a few thousand routes and thus cannot be used to route the entire Internet.

At the AS level, routing is handled by an EGP (Exterior Gateway Protocol), which takes care of routing between ASes without concern for their internal structure. In this way, global routing is achieved without routers needing to know the internal details of any AS except their own. The EGP currently in use in the Internet is BGP version 4 [107].

2.5.3

Basic BGP concepts

Here we briefly define the basic BGP concepts that we will need in the following chapters. A more complete description is given in Section 8.1; for a more thorough treatment, see [126].

Two BGP routers that exchange routing information are said to have a peering between them; the routers which peer with a given router are named its peers. By extension, we say that two ASes are peers if there is a BGP peering between them. BGP communicates routing information on peerings using messages known as updates, which can be either

announce-ments, which advertise the reachability of a prefix, or withdrawals, which communicate that

the prefix is unreachable.

(29)

2.5. IP ROUTING 13

BGP routing information for the prefix. This information is propagated from AS to AS in accordance with the routing policies of each AS; the AS-path attribute of an announcement contains the list of ASes that propagated the announcement. The AS-path of a BGP route is then used for forwarding: traffic to the route flows through the ASes in the path in the opposite direction as the corresponding announcement.

(30)
(31)

Chapter 3

Topology Discovery Methods

Network topology discovery and analysis have been the subject of much research in recent years. Many methods for automatic network topology discovery have been proposed; these methods differ in the layer of the network stack they operate at, in the level of the topology they examine, and in the data sources they use.

3.1

Introduction

Many methods for automatic network topology discovery have been proposed in recent years. While facing the same problems, the methods differ in the approach they adopt and in the data sources they make use of. This chapter will give a brief overview of existing topology discovery methods. We will characterise methods according to the layer in the protocol stack they operate at (link-layer, network layer, or higher layers), the level of the topology they examine (node-level or interdomain) and the data sources they use.

3.1.1

Topology discovery at various network layers

Topology discovery may be performed at various layers of the network stack. For example, methods have been proposed to discover the link-layer topology of Ethernet networks by performing SNMP [24] queries on the network elements (bridges) themselves. The first ap-proaches used information from vendor-specific management information structures (MIBs) to deduce the topology; subsequent work showed that it was possible to use standard MIBs to obtain the same information, with the constraint that each bridge needed to have forwarding entries for every other bridge in the network [13]. Further work reduced this requirement, allowing larger networks to be discovered [83], and provided guarantees of completeness of the topology obtained [7]. More recent work has proposed methods which do not require

(32)

access to management information and use probe packets to deduce the topology from the normal forwarding behaviour of the network elements themselves [8]. Discovery can also performed at higher levels. For example, in [60], the authors map the hierarchy of NLANR web proxy servers; more recent work specifies algorithms for using multicast DNS to search for services on the local network [28].

Discovery of the topology of the Internet itself, however, must occur at the network layer, because it is this layer that deals with topology and routing: the lower layers only have local significance, and the higher layers in the stack deal exclusively with end-to-end data transfer without concerning themselves with intermediate nodes. It is thus with the network layer that we will henceforth deal.

3.1.2

IP topology discovery

The topology of an IP network can be represented as a graph where the vertices are nodes and the edges are links between nodes. The path taken by a packet is a sequence of edges in the topology that is determined by the intermediate routers according to the contents of their routing tables at the time that each router forwards the packet. Since routing occurs on two different levels, the node level and the AS level, the topology of the Internet is in effect a two-level hierarchical topology, and methods have been proposed to analyse both levels.

The topology discovery methods proposed in the literature differ in how they obtain topo-logical information. Some simply query existing data sources, perform data integration and inferences, and present the results; others perform network management queries on network equipment; still others actively probe the network and observe the effects in order to deduce topology. Since the focus of this work is on the particular class of topology discovery mech-anisms that use active probing, in the following we will classify existing methodologies on the basis of the data sources they use.

3.2

Methods using equipment queries

An obvious way to obtain information about network topology is to query the routers them-selves. As we have seen, this method is successful in performing topology discovery at the link layer, and the same approach can be followed at the network layer. Taken together, the routers of a network have sufficient information to reach every part of the network, and there-fore have enough information to reconstruct the network topology completely. Thus, it is in principle sufficient to query every router in the network once and aggregate the results. If a link-state routing protocol such as IS-IS or OSPF is used, the process is much simpler. Since link-state protocols maintain a complete map of the network in every router, a complete topology may be obtained simply by querying one router in the network. (If the network is

(33)

3.2. METHODS USING EQUIPMENT QUERIES 17

(a) (b)

Figure 3.1: Polyphemus displaying an OSPF network: (a) the inter-area topology and the internal topology of area 1; (b) the inter-area topology and a window showing detailed infor-mation about one of the routers.

subdivided into zones such as OSPF areas, every router only has a map of its own zone, and one query must be made to a router in each zone.) Router queries may be carried out using management protocols such as SNMP [24] or by logging on to the routers using protocols such as Telnet.

An example of a tool which uses equipment queries for topology discovery is Polyphe-mus [5]. This tool discovers the topology of OSPF networks using SNMP queries and inter-actively displays the results. Topology is displayed on two hierarchical levels: the inter-area topology, which shows the areas and the interconnections between them, and the intra-area topology, which shows all the routers and links in a given area. Polyphemus also allows the user to obtain more detailed information about a router, such as its interfaces, IP ad-dresses, and directly connected links, by clicking on it. Examples of the tool’s output are in Fig. 3.1(a), which shows the area topology in the background window and the inter-nal topology of area 1 in the foreground window, and Fig. 3.1(b), which shows Polyphemus displaying detailed information about one of the routers.

3.2.1

Evaluation

The use of network management queries allows complete, accurate, and up-to-date topologies to be obtained. However, it requires administrative access to network equipment. Therefore, while these methods can be very useful to map local networks or even an entire AS, they cannot be used in the Internet at large.

(34)

inetnum: 193.0.0.0 - 193.0.7.255

netname: RIPE-NCC

descr: RIPE Network Coordination Centre

descr: Amsterdam, Netherlands

remarks: Used for RIPE NCC infrastructure.

country: NL admin-c: AMR68-RIPE admin-c: RDK-RIPE tech-c: OPS4-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-MNT mnt-lower: RIPE-NCC-MNT

source: RIPE # Filtered

[...]

aut-num: AS3333 [...]

import: from AS13184

195.69.145.45 at 195.69.144.68 action pref=100; accept ANY export: to AS13184 195.69.145.45 at 195.69.144.68 announce AS-RIPENCC

import: from AS112

195.69.144.39 at 195.69.144.68 action pref=100;

accept ANY [...]

(a) (b)

Figure 3.2: Output of WHOIS queries to the RIPE database: (a) output of an IP address query; (b) routing policies returned by an AS number query.

3.3

Methods using registry data

3.3.1

Internet registries

There are many publicly-available registries that contain information about the Internet and Internet topology. For example, the Regional Internet Registries [71], the organisations that are responsible for allocating IP addresses and AS numbers to ISPs, maintain databases of information that are publicly accessible using the WHOIS [135] protocol. The information contained in these databases includes blocks of IP addresses, AS numbers, operational contact information, and network descriptions. As an example, Fig. 3.2(a) shows the (partial) output of a query to the RIPE database [108] for an IPv4 address: the answer is a block of IP addresses that contains the address requested.

A number of organisations also maintain routing registries in which ISPs can document their routing policies. These registries are usually accessible through the WHOIS protocol and through web interfaces and are written in the Routing Policy Specification Language (RPSL) [1], which supports IPv4 networks only, or more recently in RPSLng [10], which also supports IPv6 and multicast networks. Taken together, these databases form the Internet Routing Registry (IRR). The IRR is mainly intended for operational purposes: for example, operators can look up information on the routing policies and peering agreements of other ASes and the prefixes they originate and can use this information to determine their own routing policies. It is also possible to automatically create BGP filters and router configura-tions from the registries using tools such as IRRToolSet [68]; indeed, some large ISPs rely on these mechanisms for route filtering and do not allow their customers to participate in BGP routing unless they document their routing policies in a routing registry. For an example of how routing policies are expressed in RPSL, see Fig. 3.2(b), which shows part of the output

(35)

3.3. METHODS USING REGISTRY DATA 19

(a) (b)

Figure 3.3: Hermes displaying IRR data: (a) the topology around AS 818; (b) the routing policies of AS 818.

of a query to the RIPE routing registry for AS 3333. The excerpt indicates that AS 3333 accepts all BGP routes sent to it by AS 13184 and AS 112 and propagates to AS 13184 the routes originated by the ASes in the as-set named AS-RIPENCC (an as-set is a RPSL object that specifies a set of ASes).

3.3.2

Topology discovery using registry data

Since they list interconnections between ASes, the routing registries can be used for topol-ogy discovery. The main challenge faced by methods that take this approach is not topoltopol-ogy discovery itself, since they limit themselves to visualising documented and publicly acces-sible information, but data integration. There are many routing registries (a list [91] on the IRR website contains more than 50 registries at the time of this writing), and each of these contains partial information. Even though some routing registries, such as the RADB and the RIPE routing registry, mirror a large number of other registries, no single registry provides a complete data set.

An example of a topology discovery and visualisation tool which uses information con-tained in the routing registries is Hermes [22]. Hermes is a system for exploring the inter-connections between ASes based on IRR data. It collects information from a large number of routing registries, integrates it, and presents the resulting topologies. A graphical user in-terface allows the user to filter the data sources used, interact with the topologies displayed (for example by expanding as-sets), and obtain more detailed information such as complete routing policies, a list of BGP routers in an AS, and a list of the routes originated by an AS.

(36)

Examples of Hermes’s output are shown in Fig 3.3: Fig 3.3(a) shows the result of a query for AS 818, and Fig 3.3(b) shows the routing policies of that AS.

3.3.3

Evaluation

Topology discovery methods that use routing registry information have various advantages. Firstly, they do not have to explore the network to obtain the topology and thus are simpler to implement and more efficient than methods that require network exploration. Secondly, they provide high-level information (routing policies) that is difficult to obtain in other ways. As we shall see in Section 3.4.2, more recent work does to a certain extent allow the deduction of commercial relationships, and thus routing policies, by observing the the network [48, 127], but the information obtained is not as detailed as that provided by the routing registries.

However, these methods also have several limitations, which are mainly due to the fact that they are based on analysing the information that ISPs provide about their routing policies rather than examining the state of the network itself. These limitations include:

Incomplete information The information stored in the registries is incomplete. For vari-ous reasons, including administrative overhead and confidentiality, not all ISPs publish their routing policies in routing registries. Even for those that do, the level of detail provided varies.

Data quality The information stored in the registries is of varying quality. Information about an object in one registry often overlaps with, and sometimes even contradicts, informa-tion about the same object in other registries. Furthermore, it is not clear to what degree the information in the IRR corresponds to the actual state of the global routing system. Indeed, the low confidence of the operational community in the data contained in the IRR has prompted the creation of the Routing Registry Consistency Check (RRCC) project [58], which produces daily reports on the consistency of routing registry infor-mation with operational data [110]. A more formal analysis of the quality of data in the IRR can be found in [121], which reports that although the data can provide sig-nificant and unique information that cannot be found elsewhere, it also contains many inaccuracies.

Non real-time operation Since the information in the registries must be manually updated, it is not always up-to-date with the actual routing policies applied by ISPs. Further-more, by its very nature, IRR data cannot reflect the current state of routing in the network. Since the information it contains is static, it cannot, for example, provide any information about how the network is reacting to network faults, whether given portions of the network are reachable, whether backup links are being used, and so on.

(37)

3.4. METHODS USING BGP ROUTING DATA 21

Due to these limitations, more recent work has focused on other sources of information for topology discovery. However, IRR data can still be a useful source of information for topol-ogy discovery methods, especially if combined with other data sources. For example, [140] combines IRR data with BGP routing information obtained from various sources.

3.4

Methods using BGP routing data

Another way to obtain information on the interdomain topology is to deduce it from BGP routing information. The problems faced by methods that take this approach are mostly due to the distributed nature of BGP: unlike link-state protocols such as OSPF or IS-IS, BGP has no unified view of the network. Instead, every BGP router chooses its best path to a given destination and propagates this best path to its neighbours. Therefore, every BGP router has its own view of the network, which depends on the choices made by its neighbours, on the order in which it received their routing announcements, and even, as recent work has shown, on non-deterministic factors [55, 56].

3.4.1

BGP Data Sources

The distributed nature of BGP routing information, while one of the main reasons why BGP is able to scale to networks the size of the Internet, makes obtaining a complete view of the network a virtually impossible undertaking. Therefore, topology discovery methods that use BGP information typically obtain and integrate information from multiple data sources in order to provide as complete a topology as possible. The data sources used include:

Looking glasses and route servers A looking glass is a web interface to a BGP router, and a

route server is a BGP router that permits interactive login access. Looking glasses and

route servers are usually made available to the public with the purpose of facilitating debugging by network operators, but they can also be exploited by network topology discovery tools in order to obtain BGP routing information. Looking glasses usually allow querying for BGP data and sometimes the use of a limited set of debugging tools such asping ortraceroute. Route servers usually allow the user to run most non-privileged router commands. There are many publicly accessible looking-glasses and various publicly accessible route servers; a list can be found online at [74].

BGP dumps Services such as the RIPE NCC RIS [109] and the University of Oregon Route Views project (ORV) [131] collect routing information from BGP routers around the world and store the results. This is done by deploying route collectors in various lo-cations around the world which peer with BGP routers from multiple ASes, which we name collector-peers. The projects periodically save snapshots of the routing state

(38)

observed by the route collectors at given times (table dumps) and files containing all the routing updates received by the collectors in the preceding time interval (update

traces). The data are made available online as files in the MRT format [11].

Online databases The RIS maintains the most recent BGP data collected (currently, three months of data) in a database and provides a web interface to perform queries. The results can be output both in HTML format, which is more convenient for operators, and in text format, which can be used by topology discovery tools.

3.4.2

Static analyses: BGP routing table dumps

Initial topology discovery methodologies focused on BGP table dumps. The most obvious application is simply visualising the topology induced by the AS-paths they contain: the fact that an AS-path appears in a BGP table dump implies1that there is an inter-AS link (i.e. a BGP peering) between every consecutive pair of ASes in the path. An early example of AS-level topology visualisation is described in [61], which uses the general purpose topology visualisation tool Otter. However, BGP tables have also been used by a large body of work on topics as diverse as mapping IP addresses to AS numbers [87] and evaluating the quality of different topology generation approaches [128, 15]. A brief overview of this work follows.

Evaluating the impact of routing policies and BGP performance

BGP table data has been used to investigate the efficiency of the routing policies ordinarily used in the Internet and the efficiency of the BGP protocol itself. A comparison of routing table dumps with node-level topology [129] showed that in a significant number of cases the presence of routing policy constraints leads to the use of longer AS-paths than if BGP were free to choose the shortest path, and to longer node-level paths than would be used if the Internet used node-level shortest-path routing.

Inferring AS relationships

Pioneering work by Gao [48] used BGP table dumps to infer the commercial relationships between ISPs. Current BGP routing policies are complex and motivated not only by technical reasons but also by economic factors such as only carrying traffic for paying customers or controlling the cost of links [17, 64]; Gao simplifies relationships between ASes to three

1This is not guaranteed to be true, because BGP implementations make it possible to modify the attributes of routes. This, for example, allows operators to insert into the AS-path the numbers of ASes which did not actually propagate the update. We are not aware of any efforts to evaluate the extent of the problem by the topology discovery community, possibly because of the feeling that other data quality and completeness issues have a much greater impact on accuracy than intentionally incorrect routing information. However, from an operational point of view the fear that BGP might be used for malicious purposes has spurred the development of various BGP security architectures such as as S-BGP [73] and soBGP [133].

(39)

3.4. METHODS USING BGP ROUTING DATA 23

classes, customer-provider (where one AS pays the other for “transit”, i.e. connectivity to parts of the Internet it cannot reach on its own), peer-to-peer (where two ASes exchange traffic between each other and each other’s customers without any financial compensation) and sibling-to-sibling (where two ASes provide mutual transit to each other, such as in the case of mergers and acquisitions between ISPs).

The basic assumption is that every AS providing transit must be paid for the service (and thus is a provider), and that every AS receiving transit pays for the service (and thus is a customer). Therefore, since IP traffic flows along the path taken by BGP announcements in the opposite direction, the commercial relationship between a given pair of ASes poses restrictions on the prefixes that may be announced on the peering between those ASes. For example, (i) a customer may announce to a provider its own prefixes and its customers’ prefixes, but not prefixes received from a peer or from a provider; (ii) a peer may announce to a peer only its own prefixes and its customers’ prefixes, but not prefixes received from a provider or from a peer; (iii) a provider may announce any prefix to a customer. These constraints can be applied to the AS-paths that appear in routing tables, and “valid” paths are paths that respect the constraints. Based on these constraints and the fact that a provider is typically larger than its peers and that peers are typically of comparable size, Gao proposes heuristics for inferring the types of inter-AS relationships and evaluates them by comparing them to internal AT&T information and IRR data, with very good results.

Further work on the problem was carried out by Subramanian et al. [127], who relaxed the problem by not inferring sibling-to-sibling links and provided a more elegant mathematical formulation in the form of an optimisation problem with the goal of maximising the number of valid paths. They named this problem the ToR problem, for Types of Relationships, and conjectured that it is NP-complete. They provided a heuristic solution and used it to give a five-level hierarchical classification of the ASes in the Internet, with a topmost level consist-ing of an almost complete clique between 20 “Tier 1” providers, which have no providers and peer amongst themselves. The NP-completeness of ToR was then proved by Erlebach et al. [44] and indipendently by Di Battista et al. [38], who also developed mathematically rigorous approximate solutions to the ToR problem and proved that peer-to-peer links cannot be inferred in the ToR problem formulation.

The quality of the inter-AS relationships inferred by these methods was analysed in [138], which compared their results to information on inter-AS relationships documented in IRR data and obtained by observing documented BGP community attributes [25]. The authors find that the accuracy of the relationships inferred is very high for customer–provider rela-tionships, but much lower (between 25% and 50%) for peer-to-peer relationships.

(40)

Evaluation of the quality of BGP information

BGP table dumps have been used to verify the quality of IRR data and vice versa. In [121], the authors assess the quality of data contained in the IRR system, showing that although IRR data can provide unique information that cannot be found in BGP table dumps, it also contains many inaccuracies. Conversely, Chang et al. [26] compares ORV table dumps to information collected from looking glasses and IRR data, showing that the table dumps only produce an incomplete picture of AS interconnections and that fusing the information from all data sources reveals a graph with 25-50% more AS interconnections. Finally, Broido et al. [14] compares BGP table dumps with node-level topology data, finding that the AS-level topologies induced by node-level data have much denser inter-AS connectivity than those observed in BGP table dumps.

3.4.3

Dynamic analyses: BGP update traces

The use of BGP update traces allows research on the dynamic behaviour of the Internet to be performed. Although research published as early as 1997 had used BGP update traces obtained from production routers [52, 77], the public availability of BGP update traces from RIS and ORV was the enabling factor for much subsequent research on interdomain routing; a brief overview of this work follows.

Visualising route changes

Perhaps the most obvious application of BGP update traces is visualising interdomain rout-ing changes. Several tools were developed for this purpose. One such tool is BGPlay [30], which combines table dumps with update traces to display the interdomain topology graph for a given prefix and displays routing changes to that prefix by animating the graph (see Fig. 1.1(b)). BGPlay uses advanced graph-drawing algorithms to display the interdomain topology and has been deployed both by RIS and ORV to provide an easily accessible user interface to the data they collect [115, 116]. Another tool, Link-Rank [79], takes a comple-mentary approach: it generates topology graphs in which edges are labelled with the number of BGP prefixes that are routed through that peering, thus providing a measure of the impact of a routing change and helping to identify the AS that caused it.

Analysis of BGP behaviour and performance

The analysis of BGP update traces has been instrumental in understanding the real-world be-haviour of BGP and analysing the causes of routing instability in the Internet. For example, in 1997 Labovitz et al. used BGP update traces to examine Internet routing instability, dis-covering that 99% of routing updates observed at the five major U.S. exchange points were

(41)

3.4. METHODS USING BGP ROUTING DATA 25

redundant and did not reflect actual topology changes [77]. The authors suggested that the majority of these was due to a specific implementation decision by one router vendor whose routers did not maintain state on which announcements had been made to peers, thus sending large numbers of redundant withdrawal messages — behaviour that nevertheless conformed to the BGP specification current at that time [82]. After publication, the router vendor modi-fied their implementation and two years later, the number of routing updates observed at the same collection points was an order of magnitude lower [78].

A study of Internet convergence times carried out the following year showed that the measured upper bound of interdomain convergence delay was an order of magnitude than previously thought, with some events triggering routing oscillations up to fifteen minutes long [76]. The authors observed that BGP announcements are propagated much faster than withdrawals and showed that this is due to the propagation of invalid paths. A router that receives a withdrawal only concludes that the destination is unreachable (and sends a with-drawal) when there are no other routes to the destination; before that, it will first switch to alternate paths, consequently sending out corresponding announcements to its neighbours. Route announcements and path changes thus continue until all possible paths are exhausted.

In 2003, Mao et al. [85] introduced BGP beacons, which are prefixes that are announced and withdrawn at regular intervals. The use of beacons coupled with a global network of ob-servation points provided by RIS and ORV route collectors allowed the authors to treat BGP updates using signal theory, modelling the global routing system as “a giant non-deterministic signal transducer” to analyse BGP convergence delays and update inter-arrival times (and thus route propagation times). The same work examines the effects of route flap dampening, a practice which suppresses the propagation of updates for a certain prefix if the prefix is the subject of too many BGP update messages in a short time [132]. Further work subsequently showed that the impact of route flap dampening on BGP convergence was much worse than previously thought, and that in certain topologies a single withdrawal followed by a single announcement of the same route was sufficient for the route to be suppressed for a substantial length of time [86].

Work has also been done on determining the root cause of BGP events, that is, identifying the AS or the peering responsible for routing changes, by correlating BGP updates for many different prefixes at different measurement points and using heuristics to determine “stable” links [18, 46]. The authors find that in many cases it is possible to pinpoint the origin of the routing changes to a single AS or to a BGP peering between two ASes.

Inferring topology from BGP dynamics

BGP update traces have also been used to deduce information about network topology. An-dersen et al. [2] used passive monitoring of BGP messages to cluster prefixes based on

(42)

sim-ilarities between their update times, which allows the individuation of groups of prefixes internal to an AS that are routed in similar ways, for example to the same ISP Point of Pres-ence (PoP). This has implications for intra-AS topology discovery: by grouping the prefixes internal to an AS, it is possible to reduce the number of probes that must be performed to map its internal topology.

Other work used update traces to deduce information about the interdomain topology that is not visible in table dumps. As with table dumps, the presence of an AS-path in an update implies the presence of an inter-AS link between every consecutive pair of ASes in the AS-path; however, the use of update traces has the advantage of detecting the presence of inter-AS links that were not visible when the table dumps were made. This makes it much more likely, for example, to detect backup links that are only used if primary links fail. This approach was proposed in [39], which reports that the combination of update traces with table dumps reveals a significantly larger number of inter-AS links than can be seen in table dumps alone. A more comprehensive approach was followed by Zhang et al. [140], who augmented BGP table dumps and update traces with looking glasses, route servers, and IRR data.

3.4.4

Evaluation

Topology discovery methods that use BGP routing information have several advantages. Firstly, this information is readily available in public repositories, so it is not necessary to deploy a measurement infrastructure and explore the network to determine the topology. Sec-ondly, unlike IRR data, the information provided by BGP corresponds to the actual state of the network: although it provides only a partial topology due to the distributed nature of BGP, the data is current and correct.

Unlike BGP table dumps, the use of BGP update traces allows the the dynamic behaviour of the network to be examined; this in turn allows the study of BGP behaviour and the detec-tion of backup links. Update traces are also extremely useful for operadetec-tional purposes such as troubleshooting. Finally, since this information is obtained by real-time participation in the routing protocol of the Internet, these methods arguably provide much more up-to-date data than is contained in the IRR, which is often outdated, and than can be obtained by network probing, which requires long exploration times to explore any significant part of the network. For example, the data collected by the RIS route collectors is saved and uploaded to a central location every five minutes and inserted in the database shortly afterwards, and thus is almost immediately available.

However, methods using BGP update traces also have disadvantages. Firstly, they do not provide any information on the node-level topology of the Internet. Secondly, they require non-trivial infrastructure to collect and store the updates. Finally, even when used in conjunc-tion with BGP table dumps, they provide a less complete picture of interdomain routing than

(43)

3.5. METHODS USING PROBE PACKETS 27

can be obtained, for example, using node-level probing [14].

3.5

Methods using probe packets

A large class of topology discovery methods takes the approach of deducing the topology from the behaviour of the network itself. This can be done in various ways.

A naive approach is to use diagnostic and debugging facilities of the network protocols themselves. However, IP provides only very basic diagnostic and debugging functionality. IPv4 header options that can be used for debugging include the source routing options and the record route option [102]. The source routing options allow the source node of a packet to specify a list of routers to be traversed by the packet itself, but source routed packets are discarded in the vast majority of IPv4 networks because of security implications and because it allows packets to contravene routing policies. The record route option requests every router that forwards the packet to include the IP address of the outbound interface on the path in the option data field; unfortunately, the IP header only has space for nine such addresses, which is insufficient for topology discovery except in small networks; furthermore, similarly to source routing, packets with this option set are often discarded.

IP’s companion control protocols, ICMP [101] for IPv4 and ICMPv6 [35] for IPv6, pro-vide simple debugging functionality in the form of the echo request and echo reply messages. If a node receives an echo request message, it will respond with an echo reply message ad-dressed to the host that sent the request. These messages are used by thepingtool to discover whether a node is attached to the network and functioning and to measure the round-trip time (RTT) to the node. Other control messages, such as ICMP subnet mask requests [94] and ICMPv6 node information queries [36], can provide more information, but both are typically subject to administrative control and often filtered at the network level.

3.5.1

Traceroute and hop-limited probes

Given these limitations, the approach taken is usually that of injecting non-typical packets (hereafter probe packets) and observing the network’s response in the form of error mes-sages. Perhaps the first and best-known example is thetraceroutetool [70], proposed and implemented by Deering and Jacobson in 1989. Traceroute discovers the path taken by pack-ets sent to a particular IP address in a simple but ingenious way using the Time-to-Live (TTL) field in the IPv4 header (or the equivalent Hop Limit field in the IPv6 header). The purpose of these fields is to stop routing loops from leading to packets being forwarded indefinitely in the network without ever reaching their destination: every time a router forwards a packet, the value of the field is reduced by one, ensuring that the packet will be discarded after a number of hops equal to the initial value of the field. When a router discards a packet for

(44)

traceroute to etna.switch.ch (130.59.10.30), 30 hops max, 38 byte packets 1 ghost.garr.net (193.206.158.11) 3.100 ms 1.403 ms 1.176 ms 2 rc-dirgarrb1.rm.garr.net (193.206.131.121) 4.578 ms 4.225 ms 4.437 ms 3 rt-rc-1.rm.garr.net (193.206.134.161) 5.389 ms 5.553 ms 5.068 ms 4 rtg-rt-2.rm.garr.net (193.206.134.230) 6.129 ms 7.038 ms 7.621 ms 5 mi-rm-g.garr.net (193.206.134.13) 14.972 ms 15.176 ms 16.366 ms 6 garr.it1.it.geant.net (62.40.103.89) 15.283 ms 16.362 ms 15.351 ms 7 it.ch1.ch.geant.net (62.40.96.33) 27.943 ms 28.032 ms 29.242 ms 8 swiCE2-P6-1.switch.ch (62.40.103.18) 28.977 ms 28.597 ms 29.119 ms 9 swiEZ2-G2-2.switch.ch (130.59.36.42) 34.267 ms 34.276 ms 33.899 ms 10 swiCS3-G3-2.switch.ch (130.59.36.17) 34.109 ms 33.285 ms 33.126 ms 11 scsnms.switch.ch (130.59.1.30) 33.448 ms * 33.613 ms

Figure 3.4: Example output from thetraceroutecommand. The asterisk indicates that there was no response to the second probe packet with TTL 11.

this reason, it informs the source with an IMCP or ICMPv6 “Time Exceeded” message, thus revealing its IP address.

Traceroute starts the discovery process by sending the target IP address a certain number of probe packets with a TTL of 1. The TTL of these packets expires at the first router, which replies with a Time Exceeded packet whose source address is one of the router’s IP addresses (more precisely, the IP addresses of the interface that the message is sent out on, i.e. the interface through which the address of the probing host is routed [4, section 4.3.2.4]). The IP address of the first router is thus known. Traceroute then sends a series of packets with a TTL of 2 to the target IP address, obtains the IP address of the second router, and so on. It stops when it receives a reply that indicates that the destination has been reached or until a predefined maximum number of hops is reached.

The output of traceroute is a list of IP addresses belonging to the routers which responded to the probe packets at each TTL and their response times in milliseconds; an example is in Fig. 3.4. Note that the this list is not necessarily the path taken by all (or, indeed, any one of) the packets, because each probe packet is routed independently and routing changes may occur while traceroute is running.

Traceroute may perform explorations using ICMP echo request packets or using other packets, typically UDP packets. If ICMP is used, the destination node (if reached) replies with an echo reply message whose source address is the destination address of the probe packet. For an UDP packet, if the destination port on the destination node is unused2, the node replies with an ICMP port unreachable message whose source address is the address of one of the node’s interfaces, but not necessarily the destination address of the probe packets. This allows the host running traceroute to infer that the source of this message and the destination

2If UDP is used for traceroutes, the probing host chooses high-numbered destination ports in order to minimise the likelihood of contacting a UDP service that is running on the destination node: if this were to happen, the destination node would likely not reply at all.

(45)

3.5. METHODS USING PROBE PACKETS 29

address of the probe packets belong to the same node. As we will see in the following section, this has important implications for topology discovery.

Although hop-limited probes are a very useful tool, they have limitations. The most obvious limit is that they only discover the path towards a given node, and not the return path, which may be different if routing is asymmetric. The presence of asymmetric routing also does not allow inferences to be made on the delay of the link between two consecutive hops from the round-trip times reported, even if there are no routing changes during probing: the difference in the RTTs between two consecutive routers might be due to the link between the routers, or to one of the routers using a different return path. Another limit is that traceroute only reports the address of one of the interfaces of a given link, the one belonging to the router further away from the source. This weakness can be partially addressed by using a ping with the record route option, but this does not provide any information about routers more than 8 hops away.

3.5.2

Alias resolution

These limitations notwithstanding, many topology discovery methods either use traceroute directly (e.g. [96]) or use the same principle of hop-limited probe packets to obtain topolog-ical information. The basic principle used is to probe the network from multiple points to obtain a number of paths, then fuse the paths to obtain a topology.

This presents a problem, however. The goal is to generate a graph of the network in which the vertices represent nodes and edges represent links, but the paths obtained by hop-limited probe methods do not contain nodes, but interfaces. Since a router has, by definition, more than one interface, a means must be found to assign interfaces to routers. This problem is known in the literature as the problem of resolving aliases. For example, consider the topology in Fig. 3.5(a). If we used hop-limited probes to trace the paths to D1 from two

different directions, we might obtain the two paths A1C1D1 and B1C2D1. From these, we

might infer the topology in Fig 3.5(b), which is incorrect.

As we saw in the previous section, a UDP packet sent to an unused port provokes an ICMP port unreachable error message whose source address is one of the node’s interfaces, but not necessarily the interface that the UDP packet was sent to. This behaviour allows IP aliases to be resolved: if a probe is sent to a router interface with IP address A, and the resulting port unreachable message has source address B, then A and B belong to the same router. This property is used by many topology discovery systems [96, 53, 62].

A new method was proposed by Spring et al. [123], who noted that in many router im-plementations, consecutive packets sent by the same router have consecutive values of the identification field in the IP header. Thus, to determine if two IP addresses are aliases, the probing host may send consecutive packets to the two potential addresses and examine the

Figure

Figure 1.1: How topology discovery tools can aid troubleshooting: (a) a list of BGP updates;
Figure 2.1: An example IP topology showing hosts, routers, links and interfaces
Figure 3.1: Polyphemus displaying an OSPF network: (a) the inter-area topology and the internal topology of area 1; (b) the inter-area topology and a window showing detailed  infor-mation about one of the routers.
Figure 3.2: Output of WHOIS queries to the RIPE database: (a) output of an IP address query; (b) routing policies returned by an AS number query.
+7

References

Related documents

Performance Metrics for VAAI vSphere Plug-in for Array Management SIOC VASA AQDT VADP VASRM Storage DRS HARDWARE * (CONTINUED) Supported Drives FC or SAS HDD

It can be said that the above mentioned articles that deal with food sovereignty implicitly, show the dedication and importance the Government places within

A teleradiology report should contain the type of the service (primary interpretation, second opinion etc.), the name of both the transmitting and receiving sites, the

Generalized Satake diagrams were first considered by Heck in [ He84 ] where they are shown to classify involutions of root systems such that the restricted Weyl group is the Weyl

Corporate communication networks can be implemented using permanently connect- ed digital trunks between several HiPath systems with the CorNet NQ protocol and between HiPath

This is a Service Level Agreement (SLA) between Barclaycard and A RETAILER for the provision of full service support for the Barclaycard owned Merchant Authorisation and Settlement

AWS also delivers enterprise-quality services for businesses that want to leverage state-of-the-art infrastructure, giving customers the ability to better manage applications,

Given the positive trends for both monetary and multidimensional child poverty, it is not surprising to find that having enough household income is indeed important