MRDEBUG

NAME

SYNOPSIS

DESCRIPTION

mrdebug allows the user to display the multicast routes taken by a message in a given network. It reads in the topology and subnet descriptions from the files supplied and given a source, calculates the multicast tree. Mrdebug can display either the entire tree or the path from the source to a particular destination. The user can modify the topology dynamically and redisplay the multicast tree or path of any source.

OPTIONS

-m

read filename for a list of the subnets in the network. See format description below. If no subnet file is specified, mrdebug will assume that the subnet filename is the same as the topology filename with ".subnets" or ".sn" appended. If neither of these files exists, mrdebug will print an error message and exit.

-s

use source name as the initial source for multicast messages.

-d

use destination name as the initial destination for multicast messages.

-p

Print the path of minimum distance (using reverse direction edge metrics) between the specified source and destination and then exit. If there are multiple paths of the same minimum distance, they are each printed. This option is used in conjunction with the -s and -d options.

-t

print the multicast tree for messages from the given source and exit. This option is used in conjunction with the -s option.

-a

allocate extra room for number new nodes, that did not appear in the topology file, to be added while running the program.

-l

Use the forward direction edge metrics for multicast path and tree determination. The default is reverse direction.

-v

turn on verbose mode.

-i

indent number spaces for each level when printing a tree or path.

-o

write output to filename.

Topology File Format

The topology file is normally generated by the program mrmap(1) and has the same format as the mrmap output. The router interface names in the input file can either be specified by IPnumber (ie. 128.3.112.48) or in the resolved name form DNSname(IPnumber) (ie. vet.ee.lbl.gov(128.3.112.48) as would be produced by running hf on an input file containing only IPnumbers). Each time an interface is referenced in the file, it should be in the same format. If they are in different formats, mrdebug will not recognize the two interfaces as the same. The network file can contain 3 different record types:

> from to [metric/thresh]

says there is an edge from "from" to "to" with the given metric and threshold. There may be other edge attributes listed after the threshold such as tunnel, srcrt, and querier. These attributes are optional and must be separated by /'s. "From" will always be a valid IP interface. "To" is usually an IP interface but may be "0.0.0.0". These "0.0.0.0" entries can be used to list the attributes of a subnet connection. The square brackets around the attributes are required and the metric and threshold must come first in the list of attributes. Each direction of a tunnel must be specified separately in the input file. Each interfaces that connects to a subnet must appear at least once as a "from" interface and with the "to" interface being either another interface on the same subnet or "0.0.0.0". These entries are required to allow specification of the attributes of all the connections.

= interfaceA interfaceB

says that IP addresses interfaceA and interfaceB represent 2 different interfaces on the same router.

? interface

entries of this form normally appear if the network file was created automatically by querying the actual network routers. It says that the interface appeared in the "to" field of a ">" line but didn't respond to a query for its multicast routing information so the metric and threshold of the edges from this interface are unknown. Tunnels to this interface will be mirrored by mrdebug with the same metric and threshold as used in the incoming direction. The subnet connection, if it exists, will be given a metric of 1 and a threshold of 1. The subnet connection and tunnels leaving this interface will be marked SUSPECT.

Example topology file:

> 128.1.0.0  128.3.0.0 [2/3/tunnel]
> 128.1.0.0  128.2.0.0 [4/5/tunnel/srcrt/down]
? 128.2.0.0
= 128.3.0.0  128.4.0.3 
> 128.4.0.3  128.4.0.4 [1/10]
= 128.4.0.4  128.2.0.0

Subnet File Format

Example subnet file:

128.1
128.2
128.4
128.21.5

NOTE:

The subnet file may contain entries that do not match any of the interfaces named in the network file. There may also be interfaces in the network file that have no specified subnet.

User Interface

        s.  Specify a new source
        d.  Specify a new destination
        o.  Specify a new output file
        t.  Print source tree ( #ttl can be specified as an argument)
        p.  Print path from source to destination
        u.  Print unreachable interfaces
        n.  Print the adjacency list for a node
        h.  Print the change history
        l.  Reverse link metric direction used
        e.  Explain output symbols
        r.  Remove a tunnel  or interface from the network
        a.  Add a tunnel or interface to the network
        c.  Change a metric and threshold
        v.  Toggle verbose mode
        w.  Write the current network to a network input file
        q.  Quit this program
        ?.  Print this list

(NOTE: Interfaces and subnets can be specified by the format used in the input files or by IPnumber. Commands that take arguments will normally allow the arguments to be specified on the same line as the option separated by spaces.)

s

specify the source interface or subnet for all subsequent multicast messages.

d

specify the destination interface or subnet for all subsequent path requests.

o

Each time the o option is specified, the current output file is closed and the specified new file is opened. If no file name is specified, output will go to stdout. The user can specify that output is to be appended to an existing file by placing an additional argument of a after the file name.

t

Print the multicast tree for messages multicast from the current source. Up to two arguments can be supplied with the t option. If an interface or subnet is specified, it is assumed to be the new source and replaces the existing source. If an argument in the form #number is supplied, number is taken as the ttl (time to live) specified in the multicast message. This argument allows display of the truncated multicast tree produced by the given ttl. Note the pound sign is required to appear at the beginning of the ttl argument.

NOTE: When changes in the network topology occur, the actual multicast routing protocol will only change from an existing path to a new path if the new path is of shorter distance. Thus, the tree printout produced by mrdebug may not exactly match the actual multicast tree if there are multiple paths of equal distance from the source to some of the destinations. The p option can be used to enumerate all the possible paths that could be in use by the actual multicast routing protocol to reach a destination.

p

Print the path of minimum distance (using reverse direction edge metrics) between the specified source and destination. If there are multiple paths of the same minimum distance, they are each printed. The source and destination interfaces or subnets can be specified as arguments. If only one interface or subnet is specified as an argument, it is assumed to be the destination.

u

Print the unreachable interfaces. This option is called with the same syntax as the t option except instead of printing the tree, it prints the interfaces that would not be reached by the specified tree.

n

Print the adjacency list for the router. This option takes an interface or subnet as an argument and prints out all the interfaces at the router along with their connectivity.

h

Print a history of the modifications which have been made to the current network during this session. An argument can be supplied with this option to limit the printout to the last number changes.

l

Reverse the link metric direction in use in determining multicast paths and trees.

e

Explain the output symbols in the various printouts produced by the program.

r

Remove a tunnel or interface. If called with two arguments that are interfaces it disables the specified tunnel in both directions. If called with two arguments that are an interface and a subnet, it disables the subnet connection at that interface but leaves any existing tunnels at the interface. If called with one argument that is an interface, all tunnels and subnet connections at the interface are disabled.

a

Add a tunnel or interface. This option is called using the same syntax as the r option. If the tunnel or interface is currently down, then it is brought up. If the interface(s) are unknown, the user is given the opportunity to add them to the network. If a previously unknown tunnel is specified, the user is prompted for the attributes of the new edge. These must be specified in the same syntax as used in the input file. This option requires the -a command line option. Note that, the use must specify all subnets in the subnet file. New subnets cannot be specified dynamically.

c

Change the metric or threshold on a tunnel or subnet connection. If two interfaces are specified, then the specified tunnel in the given direction will be changed. The user will be prompted for new values for the metric and threshold. If a single interface is specified, then it is assumed that this interface's connection to its subnet is to be modified.

v

Toggle the verbose mode on or off. This mode when "on" prints informative messages about what the program is doing while it is running.

w

Write the current network out to the file name specified as an argument. This function allows the user to save network changes to a file that can be used as a network input file in a later execution of mrdebug.

q

Quit the mrdebug program.

?

Print the list of available commands.

Output

Source trees and paths

are printed textually with indentation used to show tree level. An interface is printed in the tree directly below the interface at the next higher level of the tree and indented one position. If a message arrives at a router through a different interface than it departs from, the departure interface is shown indented one position below the arrival interface. Each interface is printed as it appeared in the network input file.

The numbers printed after the interface name are tree level/metric-to-here/ttl required to reach here. The word SUSPECT will be printed at the end of the line if this tunnel was only specified in one direction in the input file and the interface appeared with a ? in the input file. The metric-to-here is computed by adding the reverse direction metrics of the edges traversed to get to the given point in the tree. An entry of the tree will appear with a metric of -1 if the message will be sent to this router along this path, but it is not from the expected interface and will therefore be discarded by the router. In this case, all interfaces at the receiving router will be printed with the -1 metric.

Unreachable interfaces

include those interfaces unreachable due to a specified ttl having truncated the broadcast tree. If an interface is marked as down, the entire interface is down and therefore unreachable regardless of the ttl or source.

Adjacency list (n option)

The mask defines the subnet mask used by the program for source address resolution. The m/t at each interface lists the current metric and threshold for the interface. The type field is coded by byte. The low order byte (1st) gives interface type: Tunnel = 1, Querier = 2, Srcrt (source routed) = 4, Subnet connection = 8. The 2nd byte gives interface internal information: Assumed = 1. The interface is assumed to be a tunnel if the input file did not specify it as a tunnel but the "to" interface did not fit the subnet mask. The 3rd byte gives current interface status: Down = 1, Disabled = 2, Suspect = 4. The 5th byte gives multicast routing information: Leaf = 1, Child = 2, Parent = 4 (for an explanation of these variables see S. Deering's thesis). As an example, a type of 0x20405 would mean that this is a source routed tunnel that is suspect and has been determined to be a child interface for multicast routing.

NOTES ABOUT METHODOLOGY

Mrdebug predicts the routes taken by messages multicast through a given network. The program was designed initially to predict the paths taken by messages multicast on the Internet Multicast-Backbone (M-Bone). The M-Bone routers use a distance vector routing protocol to determine their minimum distance and next hop router to each subnet in the network. The distance vector information is maintained by exchanging distance vector tables with neighboring routers. A router adds its distance to the neighbor to the entries of the distance vector table reported by the neighbor. The router then updates its own table if any of the entries in the neighbor's adjusted table report a shorter distance then currently contained in the router's own table. The router also updates the next hop to be the neighbor whose update changed the table entry.

When a multicast message is forwarded from a neighboring router, the message is only accepted if the neighbor is the next hop router to the source of the message. The message, if accepted, is copied to the other interfaces containing neighbors that have either a greater distance to the source or with an equal distance and higher address. There are some additional rules limiting the number of interfaces the message is copied to but they will not be described here. Each router recalculates which interfaces to copy messages to each time it receives an distance vector update from a neighbor. The end result of the multicast routing protocol is that a message is always disseminated down a minimum spanning tree rooted at the message's source. This multicast routing protocol is used on the internet M-Bone, and is based primarily on the work presented by Steve Deering in his doctoral thesis (see references).

The distributed operation of the multicast routing protocol is simulated by mrdebug as a single process. Mrdebug uses Dijkstra's algorithm to calculate the distance vector routing table entries. Ties are resolved by using the lower address neighbor as the next hop. Distances between routers are determined by using the reverse direction edge metrics. Each router's distance vector routing table entry in mrdebug lists the next hop neighbor and the minimum distance to the specified source. Since the next hop neighbor is expected to forward messages from the source to this router, that neighbor is referred to by mrdebug as the parent. The interfaces that should receive copies of a message from a given source are calculated by mrdebug by looking directly at the neighboring routers' distance vector routing tables and using the algorithms specified in Steve Deering's thesis. Due to the existence of subnets in the network, routers may receive redundant copies of a message. When this occurs, the interfaces at these routers appear on this path of the tree printout with a -1 metric. These interfaces will also appear in the tree along their shortest path with their proper metric.  

REFERENCES

AUTHOR

Index

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Topology File Format

Subnet File Format

User Interface

Output

NOTES ABOUT METHODOLOGY

REFERENCES

AUTHOR