Heuristics for Internet Map Discovery R. Govindan, H. Tangmunarunkit Presented by Zach Schneirov

Mercator Infers a topological Internet map through –Hop-limited probes –Informed random address probing –Resolution of aliases

Why build router-level maps? It is the first step in understanding the large-scale physical structure of the Internet It can be used in input simulations It can directly determine network scaling limits

What exactly is an Internet map? A map in this case is a graph with nodes as routers and links as indications of adjacency, where adjacent routers have one IP hop between them

Previous work All previous maps have built router adjacencies using probes from a single node Obtained destination addresses from BGP routing tables and generated addresses with random prefixes Used routing activity between autonomous systems, with links representing inter-ISP peering Used router-level support, such as SNMP and multicast IGMP queries to find neighbor lists

Goals Map the Internet from any single arbitrary node Use only hop-limited probes (implies an absence of a database) Map must be complete Not impose significant overhead At least as fast as previous methods

Methods Informed random address probing Source-routed path probing Alias resolution

Informed random address probing Targets of probes depend on previous probes and IP block allocation policies Two ways to generate an address: –Guess an IP addressable prefix based on prefix of source address in responses to probes –Assume that other subnets at the same prefix level are neighbors

IRAP Procedure Start with an IP prefix (taken from the host machine by default) Repeating these two methods will gradually build a population of IP address prefixes –1st method ensures that addressable prefixes are explored first –2nd ensures that all possible addresses are explored

IRAP Procedure (continued) Terminates when one of the following occurs: –Subsequent ICMP-time-exceeded packets are not received –Mercator detects a loop –Chosen destination address is reached Sequence of routers is inserted into the map of links: (R1, R2, R3) becomes R1->R2, R2->R3

Reducing Overhead for IRAP Avoids probing known routers multiple times by adjusting the TTL to skip the furthest known router in the map

Speeding up map discovery Uses lottery scheduling algorithm to select prefixes –Each prefix is assigned a lottery tick –Probability of that prefix’s ticket “winning” is proportional to the faction of successful probes to the prefix Results in a bias towards densely- addressed prefixes

Source-routing Cross-links can be discovered by sending probes in one direction instead of sending them radially That is, send probes to already- discovered routers This essentially allows Mercator to send probes from multiple locations by proxy

Determining if router can do source-routing Send UDP datagrams to a random high port See if router sends back an ICMP-port- unreachable message

Alias resolution Problem: a single host can have multiple IP aliases. Probes technically discover router interfaces--not routers themselves Solution: paths from Mercator to destination host can overlap in the cases of: –Policy differences –Primary and backup paths –Source-routed paths probing from different perspectives

Alias resolution procedure Send UDP packets to non-existent ports on a router ICMP port-unreachable message will contain the outgoing interface for the return route If this is different than the original destination interface, then these interfaces are aliases for the same router Alias probes can also be source-routed to deal with incomplete backbone routing tables

Mercator Software Design Implemented from scratch for greater experimental flexibility Implemented with Libserv –Allows non-blocking network and file system access –So simultaneous independent path probes, source-routed path probes, and alias probes are possible Periodically saves map for reverting to and resumption from previous states

Theoretical Results How well do these methods satisfy the goals? –Cannot guarantee discovery of all aliases due to finite perspectives –Cannot find shared media –Map is not instantaneous –Unable to find adjacencies between physical neighbors who aren’t on speaking terms

More results-Map is incomplete Can’t discover details of networks that do not route traffic to other autonomous systems It is however complete with respect to the portion of the Internet over which packets tend to travel between hosts

Real world results Ran Mercator on a Linux PC with 15 simultaneous probes Found 150,000 interfaces and 200,000 links in 3 weeks Could only discover 20,000 router interfaces due to unroutable addresses Source-routed paths discovered only 3,000 paths

Internet map validation Compared subgraphs against published ISP maps using DNS names of routers All but one link was discovered for an ISP and an educational/research network More complexly-meshed ISPs have not been tested Will improve with more widespread use of ICMP-time-exceeded messages and source- routing

Measuring ISP Topologies with Rocketfuel N. Spring, R. Mahajan, D. Wetherall

Rocketfuel Directly measure router-level ISP topologies more efficiently than brute- force Uses BGP routing tables Eliminates redundant measurement Better alias resolution DNS for identifying ISPs

Goals Infer high quality ISP topological maps Use as few measurements as possible An ISP will consist of multiple POPs (point-of-presence) connected by backbones

Methods Uses only traceroute for measuring paths Merges traceroute paths from multiple sources to multiple destinations Choose traceroutes that contribute the most information (directed probing and path reductions) Alias resolution through “personality” Identifying routers through DNS

Directed probing Use BGP routing information to choose only the traceroutes likely to transit the target ISP Traceroutes will transit the ISP if they are: –Sent to dependent prefixes (sent to a destination within the ISP) –Sent from within a dependent prefix (traceroute server is within the ISP) –Either may be true depending on several different destination prefixes in BGP table

Expected problems with directed probing Incomplete routing tables or non- determinism in the routing tables will cause: –False positives: when traceroutes are performed on paths that don’t traverse ISP –False negatives: when removing traceroutes results in less information

Path reductions Don’t do traceroutes that enter and/or leave the ISP through the same points; they will probably take the same path through the ISP Ingress reduction Egress reduction Next-hop AS reduction

Ingress reduction Egress reduction Next-hop AS reduction

Alias resolution Improves Mercator’s UDP-port- unreachable triggering Assumes that router aliases will have some set of characteristics that is constant between its aliases Tests one pair of addresses at a time

Alias resolution methods Compare TTLs in responses to UDP requests Test ICMP rate limiting –If two probes to two addresses are sent right away with only one response returned, then it is a single router Assume that packets sent consecutively will have incrementing IP ID in the response

Identifying routers How to determine –Which routers correspond to the ISP in question –What are the routers’ physical locations? –Which other routers they connect to? Use DNS names –Support of BGP on routers is irrelevant –Can identify network edges by changes in names –Customer nodes (cable, DSL, dialup) are named differently –Can guess location through naming convention

Rocketfuel Results Statistics for 10 mapped ISPs using 294 publicly available traceroute servers

Traceroute reduction results