File: mrtuser.html

package info (click to toggle)
mrt 2.2.2a-6
links: PTS
area: main
in suites: etch, etch-m68k
size: 3,140 kB
ctags: 4,853
sloc: ansic: 56,465; sh: 2,801; perl: 1,065; makefile: 321
file content (1742 lines) | stat: -rw-r--r-- 74,845 bytes
parent folder | download | duplicates (4)
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<TITLE>MRT User's Guide</TITLE>
</HEAD>
<BODY LINK="#0000ff" VLINK="#800080">

<B><FONT FACE="Arial" SIZE=7><EM><P ALIGN="CENTER"><A NAME="_Toc409238192"><A NAME="_Toc409241003"></P>
<P ALIGN="CENTER">&nbsp;</P>
<P ALIGN="CENTER">&nbsp;</P>
<P ALIGN="CENTER">MRT User/Configuration Guide</P>
</B></FONT></EM><I><FONT FACE="Arial" SIZE=6><STRONG><P ALIGN="CENTER">Version 2.0.0 Alpha</P>
</FONT><FONT FACE="Arial" SIZE=4><P ALIGN="CENTER">(Draft 11/5/99</P>
</I></FONT><FONT SIZE=7><P>&nbsp;</P>
<H2>&nbsp;</H2>
</FONT><FONT SIZE=5><H1><A NAME="_Toc410609075"><A NAME="_Toc451331937"></A></A>Table of Contents</A></A> &nbsp;<DIR>

</FONT></STRONG><FONT SIZE=2><P>Table of Contents&#9;</FONT><A HREF="#_Toc451331937">*</A></P>
<FONT SIZE=2><P>Introduction&#9;</FONT><A HREF="#_Toc451331938">*</A></P>
<FONT SIZE=2><P>Document Conventions&#9;</FONT><A HREF="#_Toc451331939">*</A></P>
<FONT SIZE=2><P>Related MRT Manuals&#9;</FONT><A HREF="#_Toc451331940">*</A></P>
<FONT SIZE=2><P>Getting Help&#9;</FONT><A HREF="#_Toc451331941">*</A></P>
<FONT SIZE=2><P>Credits&#9;</FONT><A HREF="#_Toc451331942">*</A></P>
<FONT SIZE=2><P>1.  Overview&#9;</FONT><A HREF="#_Toc451331943">*</A></P>
<FONT SIZE=2><P>2.  Getting Started&#9;</FONT><A HREF="#_Toc451331944">*</A></P>
<FONT SIZE=2><P>Configuration Commands&#9;</FONT><A HREF="#_Toc451331945">*</A></P>
<FONT SIZE=2><P>Combining MRT Programs&#9;</FONT><A HREF="#_Toc451331946">*</A></P>
<FONT SIZE=2><P>Tracing/Logging&#9;</FONT><A HREF="#_Toc451331947">*</A></P>
<FONT SIZE=2><P>3.  MRTd&#9;</FONT><A HREF="#_Toc451331948">*</A></P>
<FONT SIZE=2><P>Synopsis&#9;</FONT><A HREF="#_Toc451331949">*</A></P>
<FONT SIZE=2><P>Options&#9;</FONT><A HREF="#_Toc451331950">*</A></P>
<FONT SIZE=2><P>Description&#9;</FONT><A HREF="#_Toc451331951">*</A></P>
<FONT SIZE=2><P>Sample Configuration Files&#9;</FONT><A HREF="#_Toc451331952">*</A></P>
<FONT SIZE=2><P>Configuration Guide&#9;</FONT><A HREF="#_Toc451331953">*</A></P>
<FONT SIZE=2><P>Interactive Interface Commands&#9;</FONT><A HREF="#_Toc451331954">*</A></P>
<FONT SIZE=2><P>4.  BGPsim&#9;</FONT><A HREF="#_Toc451331955">*</A></P>
<FONT SIZE=2><P>Synopsis&#9;</FONT><A HREF="#_Toc451331956">*</A></P>
<FONT SIZE=2><P>Options&#9;</FONT><A HREF="#_Toc451331957">*</A></P>
<FONT SIZE=2><P>Description&#9;</FONT><A HREF="#_Toc451331958">*</A></P>
<FONT SIZE=2><P>Sample Configuration File&#9;</FONT><A HREF="#_Toc451331959">*</A></P>
<FONT SIZE=2><P>Configuration Commands&#9;</FONT><A HREF="#_Toc451331960">*</A></P>
<FONT SIZE=2><P>Interactive Interface Commands&#9;</FONT><A HREF="#_Toc451331961">*</A></P>
<FONT SIZE=2><P>5.  SBGP&#9;</FONT><A HREF="#_Toc451331962">*</A></P>
<FONT SIZE=2><P>Synopsis&#9;</FONT><A HREF="#_Toc451331963">*</A></P>
<FONT SIZE=2><P>Options&#9;</FONT><A HREF="#_Toc451331964">*</A></P>
<FONT SIZE=2><P>Description&#9;</FONT><A HREF="#_Toc451331965">*</A></P>
<FONT SIZE=2><P>6.  ROUTE_BTOA&#9;</FONT><A HREF="#_Toc451331966">*</A></P>
<FONT SIZE=2><P>Synopsis&#9;</FONT><A HREF="#_Toc451331967">*</A></P>
<FONT SIZE=2><P>Options&#9;</FONT><A HREF="#_Toc451331968">*</A></P>
<FONT SIZE=2><P>Description&#9;</FONT><A HREF="#_Toc451331969">*</A></P>
<FONT SIZE=2><P>7.  ROUTE_ATOB&#9;</FONT><A HREF="#_Toc451331970">*</A></P>
<FONT SIZE=2><P>Synopsis&#9;</FONT><A HREF="#_Toc451331971">*</A></P>
<FONT SIZE=2><P>Options&#9;</FONT><A HREF="#_Toc451331972">*</A></P>
<FONT SIZE=2><P>Description&#9;</FONT><A HREF="#_Toc451331973">*</A></P>
<FONT SIZE=2><P>8. Data Distiller&#9;</FONT><A HREF="#_Toc451331974">*</A></P>
<FONT SIZE=2><P>Synopsis&#9;</FONT><A HREF="#_Toc451331975">*</A></P>
<FONT SIZE=2><P>Options&#9;</FONT><A HREF="#_Toc451331976">*</A></P>
<FONT SIZE=2><P>Description&#9;</FONT><A HREF="#_Toc451331977">*</A></P>
<FONT SIZE=2><P>Operations&#9;</FONT><A HREF="#_Toc451331978">*</A></P>
<H1>&nbsp;</H1></DIR>
</H1>
<FONT SIZE=7><STRONG><P>&nbsp;</P>
</FONT></STRONG><B><FONT SIZE=5><P>Copyright (c) 1997, 1998, 1999</P>
</B></FONT><FONT FACE="Courier" SIZE=3><P>&nbsp;</P>
<P>&nbsp;</P>
<P>The Regents of the University of Michigan ("The Regents") and Merit Network, Inc.  All rights reserved.<BR>
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:</P>
<P>1.  Redistributions of source code must retain the above <BR>
    copyright notice, this list of conditions and the <BR>
    following disclaimer.</P>
<P>2.  Redistributions in binary form must reproduce the above <BR>
    copyright notice, this list of conditions and the <BR>
    following disclaimer in the documentation and/or other <BR>
    materials provided with the distribution.</P>
<P>3.  All advertising materials mentioning features or use of <BR>
    this software must display the following acknowledgement:</P><DIR>
<DIR>

<P>This product includes software developed by the University of Michigan, Merit Network, Inc., and their contributors.</P></DIR>
</DIR>

<P>4.  Neither the name of the University, Merit Network, nor the<BR>
    names of their contributors may be used to endorse or <BR>
    promote products derived from this software without <BR>
    specific prior written permission.</P>
<P>THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. </P>
</FONT><H2><A NAME="_Toc451331938">Introduction</A></H2>
<P>&nbsp;</P>
<P>This chapter introduces the <I>MRT User/Configuration Guide</I> and explains how to obtain further information about MRT.</P>
<H3><A NAME="_Toc451331939">Document Conventions</A></H3>
<P>The following document conventions are used in the <I>User Guide:</P>

<UL>
</I><LI>Commands and keywords are in <B>boldface</B>.</LI>
<LI>User-supplied variables are enclosed in &lt;angle brackets&gt;.</LI>
<LI>Optional elements are shown in [square brackets].</LI>
<LI>Alternative but required keywords are grouped in {braces} and separated by a vertical bar.</LI></UL>

<H3><A NAME="_Toc451331940">Related MRT Manuals</A></H3>
<P>The following additional documentation is available for MRT users (see (http://www.merit.edu/net-research/mrt/html/mrt_doc/):</P>

<UL>
<I><LI>Installation Guide </LI>
<LI>Programmer's Manual</LI>
</I><LI>Tutorial (in preparation)</LI></UL>

<P>The MRT web site will also have the most up-to-date documentation and code.</P>
<H3><A NAME="_Toc451331941">Getting Help</A></H3>
<P>For more information about MRT, send mail to mrt-support@merit.edu. </P>
<P>The MRT development team is available to answer questions and provide configuration advice.  We are also very interested in bug reports, feature requests, and general feedback.</P>
<P>A mailing list, mrt-discuss-request@merit.edu, is also available for MRT users to share advice and experiences with the toolkit.</P>
<H3><A NAME="_Toc451331942">Credits</A></H3>
<P>MRT was originally developed by Merit Network, Inc., under National Science Foundation grant NCR-9318902, "Experimentation with Routing Technology to be Used for Inter-Domain Routing in the Internet." The current research is supported by the National Science Foundation (NCR- 9710176) and a gift from Intel Corporation. </P>
<P>The design and ideas behind many of the MRT libraries draws heavily on the architecture pioneered in the GateD routing daemon. </P>
<P>The University of Michigan/Merit Network MRT development team includes: Craig Labovitz, Masaki Hirabaru, Farnam Jahanian, Susan Hares and Susan Rebecca Harris. Additional code and architecture ideas were supplied by Marc Unangst and John Scudder. </P>
<P>Francis Dupont developed the initial BGP4+ code. </P>
<P>The public domain Struct C-library of linked list, hash table and memory allocation routines was developed by Jonathan Dekock &lt;dekock@cadence.com&gt;.</P>
<P>David Ward &lt;dward@netstar.com&gt; provided bug fixes and helpful suggestions.</P>
<P>Pedro Roque developed the first port to Linux IPv6, and wrote many of the Linux kernel interface routines.</P>
<P>Mark Turner &lt;mturner@cisco.com&gt; added several new features to BGPSim.</P>
<P>We would also like to thank our other colleagues in Japan, Portugal, the Netherlands, the UK, and the US for their many contributions to the MRT development effort. </P>
<P>&nbsp;</P>
<H2><A NAME="_Toc451331943">1.  Overview</A></H2>
<P>&nbsp;</P>
<P>The MRT toolkit has been used to build a wide variety of tools, ranging from production Internet and 6bone routing daemons to BGP fault-injection and traffic generation test packages.  MRT software is in active use at universities and commercial organizations throughout the country and internationally. </P>
<P>MRT uses novel approaches to routing architecture design, and incorporates features such as parallel lightweight processes, multiple processor support, and shared memory.  The object-oriented, modular design of the software encourages the rapid addition and prototyping of experimental routing protocol and inter-domain policy algorithms.  </P>
<P>Although MRT has been designed with multi-threaded, multi-processor architectures in mind, the software will run in emulation mode on non-thread capable operating systems.</P>
<P>Today, MRT applications and libraries enjoy a diverse user community, researchers and commercial developers across the Internet.  See the <B>Tutorial</B> for examples on how users are adopting MRT technology.</P>
<P>You can use MRT applications and libraries to:</P>

<UL>
<LI>Serve as the backbone routing software for your IPv6 or IPv4 network connection.</LI>
<LI>Simultaneously handle tasks such as routing policy communication, routing policy calculation, and maintenance of a RIB, and distribute these tasks over multiple processors or multiple machines</LI>
<LI>Generate and analyze route flap statistics  </LI>
<LI>Generate real-time graphical maps of Internet routing </LI>
<LI>Capture a BGP peering session and monitor it in real time</LI>
<LI>Record and replay sequences of events, such as routing failures</LI></UL>

<P>The toolkit includes two main categories of tools: Routing and Network Performance measurement tools. A high level description of the toolkit applications is provided below:  </P>
<H4>Routing Tools</H4>

<UL>
<B><LI>MRTd</B><A HREF="#mrt"></A></LI>
<LI><B></B>A routing daemon supporting RIPng, BGP4+, multiple RIBs (route server), and RIP1/2.  MRTd reads Cisco Systems-like router configuration files and supports a Cisco Systems router-like telnet interface. </LI>
<B><LI>BGPsim</B>A<B> </B>BGP4+ traffic generator/simulator.</LI>
<B><LI>SBGP</B>A simple BGP4+ speaker and listener<B>.</LI>
<LI>Route_BtoA</B>Converts binary MRT messages to ASCII<B>.</LI>
<LI>Route_AtoB</B>Converts ASCII descriptions of MRT messages to binary MRT message format. Binary MRT messages can be piped into other MRT programs, including SBGP and BGPSim.</LI></UL>

<P>&nbsp;</P>
<H2><A NAME="_Toc451331944">2.  Getting Started</A></H2>
<P>&nbsp;</P>
<P>See the <B>MRT Installation Guide</B> for information on building and installing MRT programs</P>
<P>All MRT programs can be invoked from the command line, or from the Unix boot/startup script. Below is an example of starting the MRTd routing daemon from the command line:</P><DIR>
<DIR>

<CODE><P>&gt; /usr/local/bin/mrtd </P></DIR>
</DIR>

</CODE><P>Once running, most MRT-based tools will begin to listen for user telnet connections on the TCP port specified in /etc/services. MRT-based programs may be configured by editing a configuration file, or by invoking the configuration utility from the interactive user telnet interface. Below is an example of telneting to the user interactive interface (UII) port on a machine running the MRTd routing daemon. The &quot;mrtd&quot; number has been configured in /etc/services (see the Installation Manual for more information).</P><DIR>
<DIR>

<CODE><P>&gt;telnet 127.0.0.1 mrtd </P>
<P>MRT version 1.5.2 ALPHA February 22, 1999</P>
<P>User Access Verification</P>
<P>[71] password&gt; ***</P>
<P>[71] MRTd&gt;</P></DIR>
</DIR>

</CODE><P>If a password is specified in the configuration file, it must be supplied at the password prompt.  Initially, MRT programs default to no password access control and restrict user interactive telnet to the loopback address or the interface address of the local machine.</P>
<P>The MRT user interface supports Unix shell-like redirection (<B>&gt;</B> or <B>&gt;&gt;</B> <B>filename</B>) for output. To edit a line, emacs-like line editing, including ^a, ^e, ^b, ^f, ^d, ^k, ^u and ^c, is available. To reuse a previous line, the tcsh-line history function is available by typing ^p and ^n.</P>
<P>Most MRT-based tools share a common subset of user management and configuration commands. The command language used by MRT shares many similarities with the language used on Cisco Systems routers. </P>
<P>Commands common to most MRT tools include:</P>

<UL>
<B><LI>show config</B>view the configuration file</LI>
<B><LI>show version</B>show the current version</LI>
<B><LI>show threads</B>show the status of application threads</LI>
<B><LI>config<FONT SIZE=4>*</B></FONT>enter configuration mode </LI>
<B><LI>enable</B>enter enable mode<B> </LI>
<LI>write<FONT SIZE=4>*</B></FONT>save volatile memory configuration to disk<B> </LI>
<LI>reboot<FONT SIZE=4>*</B></FONT>restart the application </LI>
<B><LI>help</B>shows all commands available</LI>
<B><LI>exit</B>leave the UII interface</LI></UL>
<DIR>
<DIR>

<B><FONT SIZE=4><P>*&#9;</B></FONT>Note that if you set enable password in your configuration, the enable command is required in order to execute some potentially dangerous commands, such as config, write, and reboot (marked with an asterisk <B><FONT SIZE=4>* </B></FONT>above.)</P></DIR>
</DIR>

<H3><A NAME="_Toc451331945">Configuration Commands</A> </H3>
<P>When MRT programs are started for the first time and no configuration file exists on disk, the programs will create a default configuration in volatile memory. This configuration may be modified in memory by issuing the &quot;<B>config&quot;</B> command from the UII telnet interface prompt.  Modifications to volatile memory may be saved to disk using the &quot;<B>write</B>&quot; command. Modifications not saved to disk will be lost if the application terminates or is rebooted.</P>
<P>Upon startup, MRT programs will search for the default configuration file for the application (usually /etc/&lt;application_name.conf&gt;). The user may also override the default configuration file by providing a &quot;-<B>f &lt;filename&gt;</B> &quot; flag on the command line of the application.</P>
<P>Beginning with this version (v. 1.5.1 alpha), all configuration commands may be issued even through the interactive, telnet interface. Configuration changes can also be made directly to the configuration file on disk.  If changes are made the program must be restarted, or <B>rebooted</B>, to reread the changed configuration file. </P>
<H4>Most configuration commands have no-style commands, such as no ip route ..... to remove them from the configuration. Command prefixes can be used for both IPv4 and IPv6 configurations, but IPv6 features may not be available on IPv4-only platforms. </H4>
<P>The following configuration commands are common to most MRT-based programs:</P>
<B><P>line vty</B>configures the user interface (by telnet)</P>
<B><FONT SIZE=2><P>password &lt;string></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets a password <string> for telnet interface. Note that if a password is not set, access verification will not be performed and interactive user telnet connections will only be available from the local host.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>access-class <access-list number></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>If <access-list number> is specified, telnet connections will be restricted to IP addresses allowed by the access list.  See the access-list description below for more information.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>port <number> </P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Changes the port number with <number> for the telnet interface. The default is the port value specified in /etc/services for the application name. If a /etc/services entry does not exist, the port number assigned to the service defaults to "mrt" or 5674.</P>
<B><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

<P>exec-timeout <minutes></B>[<seconds>]</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Sets the timeout on idle UII connections to the number of <minutes> and <seconds>.  At the end of the timeout interval, the idle UII connection is closed.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>addr <address>  </P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Specifies the address at which the UII connections are accepted.  The default is all addresses available on the host.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>login</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Enables connections from other hosts.</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><B><P>enable password</B>sets enable password</P>
<B><FONT SIZE=2><P>enable password &lt;string&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets enable password &lt;string&gt; for the enable command.</P>
<B><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><P>debug</B>controls debug options</P>
<B><FONT SIZE=2><P>debug <flag> [<file> [&lt;size&gt;]]</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Logs debug messages matching priority <flag> to the named <file>.  If the file size limit is specified with <size>, the file will be truncated after reaching the <size> byte limit. If <file> is omitted, stderr will  be selected.  </P></DIR>
</DIR>
</DIR>
</DIR>

<PRE>		<flag></FONT><B> .... info, norm, trace, parse, packet, state, timer, all
		<file> .... filename or "stdout". 
&#9;&#9;                             Some applications also support &quot;syslog&quot;
&#9;&#9;&#9;
		<size> .... maximum size (bytes) of logfile.  
		            File is truncated and restarted after reaching <size>.
</PRE><DIR>
<DIR>
<DIR>
<DIR>

<U><FONT SIZE=2><P>NOTE:</B></U> Debugging may significantly impact the performance of mrtd and other daemons. We recommend using binary packet dump update option for statistics collection and event logging.</P>
</FONT><B><PRE>
</PRE></DIR>
</DIR>
</DIR>
</DIR>

<P>access-list</B>defines a filter</P>
<B><FONT SIZE=2><P>access-list <number> {permit|deny} <prefix> [refine|exact]</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Defines an access list <number>, which permits or denies access if the condition is matched. <B>all</B> can be specified as <prefix>.  <B>exact</B> will be assumed if neither <B>refine</B> or <B>exact</B> is specified.  <B>exact</B> matches only the prefix, while <B>refine</B> matches more specific prefixes, excluding the prefix itself.</P>
<P>Matches are performed in the order in which they appear. At the end of a list with the same number, deny all is assumed.</P>
</FONT><B><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

<P>!</B>comment and separator</P><DIR>
<DIR>

<FONT SIZE=2><P>Comments can appear at the beginning of a line, or any other place in the line.  However, only comments appearing at the beginning of a line are stored in memory.</P></DIR>
</DIR>

</FONT><B><P>redirect</B>allows shell-like redirection of output (&gt; or &gt;&gt;).</P><DIR>
<DIR>

<B><FONT SIZE=2><P>redirect</B> &lt;directory&gt;</P><DIR>
<DIR>

<P>Allows redirection to files in this directory.  Unrestricted redirection was deemed a security problem.</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><P><A NAME="_Toc409238193"><A NAME="_Toc409241004"><A NAME="mrt">After editing the configuration file, the user may return to the top-level of the interactive telnet interface by typing a <B>^Z</B> or entering <B>exit</B>. Below is an example of an interactive telnet session using the configuration mode of an MRT application:</P><DIR>
<DIR>

<FONT FACE="Courier New" SIZE=2><P>Config&gt; ?       </P>
<P>  access-list                   </P>
<P>  as-path                       </P>
<P>  debug                         </P>
<P>  dump                          </P>
<P>  dump-binary                   </P>
<P>  exit                          Quit from the current level</P>
<P>  gateway                       </P>
<P>  interface                     </P>
<P>  no                            </P>
<P>  password                      </P>
<P>  quit                          Quit from the current level</P>
<P>  redirect                      </P>
<P>  route                         </P>
<P>  route-map                     </P>
<P>  router                        </P>
<P>  show                          </P>
</FONT><P>&nbsp;</P></DIR>
</DIR>

<H3><A NAME="_Toc451331946">Combining MRT Programs</A></H3>
<P>Many MRT programs (sbgp, route_btoa, bgpsim) can be combined together using Unix shell-like pipe features. For example:</P><DIR>
<DIR>

<CODE><P>sbgp -o stdout | route_btoa -i stdin </P></DIR>
</DIR>

</CODE><P>Programs can also use System5 message passing with -r and -w options. Note that this feature is limited/experimental in this release.</P>
<H3><A NAME="_Toc451331947">Tracing/Logging</A></H3>
<P>All MRT programs support logging. The <B>v</B> command line option will turn on verbose logging to stdout. More advanced logging options may be set in the configuration file using the <B>debug</B> command. </P>
<B><U><P>NOTE:</B></U> Debugging may significantly impact the performance of mrtd and other daemons. We recommend using binary packet dump update option for statistics collection and event logging<FONT SIZE=2>.</P>
</FONT><P>MRT supports five different debugging flags: NORM, PACKET, PARSE, TRACE, STATE, PARSE, POLICY, and ALL.  </P><DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>

<P>NORM&#9;Logging from normal operations.  Includes error messages and significant events</P>
<P>PACKET&#9;Logging of receipt and transmission of packets (e.g., BGP updates)</P>
<P>PARSE&#9;Logging of config file parsing and UII configuration changes</P>
<P>POLICY &#9;Application of filter lists or routing policy.</P>
<P>STATE&#9;Protocol state machine changes and other events (e.g., BGP state machine changes)</P>
<P>TRACE &#9;Detailed logging of operations</P>
<P>ALL&#9;All logging turned on</P></DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>

<P>MRT debugging information may be forwarded to the UII vtty by issuing the command <B>terminal monitor</B>.</P>
<H2><A NAME="_Toc451331948">3.  MRTd</A></A></A></H2>
<P>MRTd is a multi-threaded routing daemon with support for BGP4, RIP1/2, RIPng, and BGP4+ (for IPv6) and multiple RIBs (i.e. route server). MRTd reads Cisco Systems-like router configuration files and includes a Cisco Systems router-like interactive telnet interface. </P>
<P>At the moment, BGP, RIPng, and BGP4+ are completely supported.  RIP1/2 and its interaction with other protocols are not supported. Development of OSPF and PIM-DM is currently underway.</P>
<H3><A NAME="_Toc451331949">Synopsis</A></H3>
<H4>mrtd [-v] [-n] [-f configuration file] [-l rib file] [-r] [-m]</H4>
<H3><A NAME="_Toc451331950">Options</A></H3>
<B><FONT SIZE=2><DL>
<DT>-f configuration_file </DT>
</B><DD>Read the specified configuration file. By default, MRT tries to read /etc/mrtd.conf. </DD>
<B><DT>-v </DT>
</B><DD>Turn on verbose logging to standard output.  This is useful to turn on logging before the debug commands are read in the configuration file. </DD>
<B><DT>-n </DT>
</B><DD>Specify that MRT will not modify the kernel routing table.  (This option is used to test MRT configurations with actual routing data.) </DD>
<B><DT>-r </DT>
</B><DD>Dont install routes in the RIB.</DD>
<B><DT>-l routing database </DT>
</B><DD>Load routes from a routing table dump and use these prefixes in the simulation. The routing database file must be in MRT message format. The programs included in the route_atob directory will convert GateD, RSd and Cisco Systems routing table dumps to MRT RIB format.</DD>
<B><DT>-m </DT>
</B><DD>Use a new dump format.</DD>
</FONT><DT>&nbsp;</DT>
</DL>
<H3><A NAME="_Toc451331951">Description</A></H3>
<P>MRT first reads its configuration file (by default /etc/mrtd.conf) to configure routing protocols, route peerings, and routing policy.  The configuration file closely resembles those used by Cisco Systems routers. </P>
<P>After reading the configuration file, MRT scans the kernel for existing routes, scans the kernel interface list, and then initiates routing protocol communications.  MRT also begins listening on the mrt service port, &quot;mrtd,&quot; (specified in /etc/services) for user telnet connections. </P>
<H3>&nbsp;</H3>
<H3><A NAME="_Toc451331952">Sample Configuration Files</A></H3>
<P>A sample IPv4 MRT configuration file is shown below:</P>
<B><PRE></PRE><DIR>
<DIR>

</B><FONT FACE="Courier" SIZE=1><P>Line vty</P>
<P>   password </FONT><FONT SIZE=1>my_password</FONT><FONT FACE="Courier" SIZE=1>    login</P>
</FONT><FONT SIZE=1><PRE>!
debug norm stdout
!
access-list 1 deny 0.0.0.0/0
access-list 1 permit all
access-list 2 permit 192.168.0.0/16
!
router bgp 185
neighbor 192.168.10.2 remote-as 65
neighbor 192.168.10.2 distribute-list 1 in
neighbor 192.168.10.2 distribute-list 2 out
neighbor 198.108.60.244 remote-as 185
redistribute static
redistribute rip
!
router rip
network 192.168.10.0/24
network 198.108.60.0/24
redistribute static
redistribute bgp
!
ip route 192.168.100.0/24 192.168.10.100
ip route 192.168.150.0/23 192.168.10.100
ip route 192.168.190.1/24 192.168.10.100
ip route 10.0.0.0/8 192.168.10.100
</FONT></PRE></DIR>
</DIR>

<P>Following is a sample IPv6 configuration file:</P><DIR>
<DIR>

<FONT FACE="Courier" SIZE=1><P>Line vty</P>
<P>   password my_passwordhttp://pythia.uoregon.edu/~llynch/nanog16.html   port 5674   login</P>
<P>!</P>
<P>dump bgp view 1 /susr/masaki/tmp/ipv6/bgp.routes.%y%m%d.%H:%M 60m</P>
<P>dump bgp updates /susr/masaki/tmp/ipv6/bgp.updates.%y%m%d.%H:%M 15m</P>
<P>debug all /tmp/MRTd.log 1000000</P>
<P>redirect /tmp</P>
<P>!</P>
<P>access-list 1 deny 3ffe:1c00::/24 refine !merit internal</P>
<P>access-list 1 permit all</P>
<P>!</P>
<P>access-list 99 deny all</P>
<P>!</P>
<P>as-path access-list 1 permit ^1673 ! just an example, it's always true</P>
<P>!</P>
<P>router bgp 237 ! define own AS number</P>
<P>  aggregate-address 3ffe:1c00::/24 summary-only as-set</P>
<P>  neighbor 3ffe:0dfe:fffe::9 remote-as 1673 ! eBGP</P>
<P>  neighbor 3ffe:0dfe:fffe::9 description ANS</P>
<P>  neighbor 3ffe:0dfe:fffe::9 distribute-list 1 out ! drop specific</P>
<P>  neighbor 3ffe:0dfe:fffe::9 filter-list 1 in ! as path filter</P>
<P>  neighbor 3ffe:1c00::3 remote-as 237 ! iBGP</P>
<P>  neighbor 3ffe:1c00::3 description CC</P>
<P>  neighbor 3ffe:1c00::3 bgp4+ 1 ! use RFC version of BGP4 MP</P>
<P>  neighbor 3ffe:1c00:0:60::112 remote-as 112 ! for test</P>
<P>  neighbor 3ffe:1c00:0:60::112 remote-as 112 description MRT</P>
<P>  neighbor 3ffe:1c00:0:60::112 distribute-list 99 in ! drop everything</P>
<P>  neighbor 3ffe:1c00:0:60::112 bgp4+ 1 ! ! use RFC version of BGP4 MP</P>
<P>  redistribute static ! inject static routes</P>
<P>  redistribute direct ! inject connected routes</P>
<P>!</P>
<P>router ripng</P>
<P>  network 3ffe:1c00:0:60::/64</P>
<P>  network 3ffe:1c00:0:12::/64</P>
<P>  network cti1</P>
<P>  network cti2</P>
<P>  redistribute static</P>
<P>  redistribute direct</P>
<P>  redistribute bgp</P>
<P>  distribute-list 99 in cti2</P>
<P>  distribute-list 99 out cti2</P>
<P>!</P>
<P>ip route 0.0.0.0/0 198.108.60.1 ! default route</P>
<P>ip route 3ffe:1c00::/24 ::1 ! merit pTLA</P>
<P>&nbsp;</P></DIR>
</DIR>

</FONT><H3><A NAME="_Toc409238194"><A NAME="_Toc409241005"><A NAME="_Toc451331953">Configuration Guide</A></A></A></H3>
<P>This section introduces the command sets for: </P>

<UL>
<LI>Configuring MRTd and BGPsim </LI>
<LI>Using MRTs interactive interface to monitor the status of MRTd and BGPsim. </LI></UL>

<P>For information about the <B>uii, debug, </B>and<B> access-list </B>configuration commands, see Chapter 2, &quot;Getting Started.&quot; </P>
<H4>Configuration Commands</H4>
<P>As mentioned in Chapter 2, all of the below options may be configured directly through the UII telnet interface. Administrators may also choose to edit the configuration file directly on disk. In this case, MRTd must be <B>rebooted</B> before the changes will take affect.</P>
<FONT FACE="Arial"><H5>Configuring Routes and Policy</H5>
</FONT><P>MRTd supports most of the common Cisco Systems routing policy commands, including access lists, as-path access lists and route maps.</P>
<P>&nbsp;</P>
<B><P>route</B>defines a static route</P>
<B><FONT SIZE=2><P>route <prefix> <next hop> [<interface>]</P><DIR>
<DIR>
<DIR>
<DIR>

</B></FONT><P>Establishes a static route to a destination <prefix> via <next hop>.    <next hop> may be an IPv4 or IPv6 address and must be consistent with <prefix>. To use a specific interface, specify <interface>.</P>
<B><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

<P>as-path access-list</B>defines an as-path access-list</P>
<B><FONT SIZE=2><P>as-path access-list &lt;number&gt; {permit|deny} &lt;as-regular-expression&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B></FONT><P>Defines an as-path access-list &lt;number&gt;, which permits or denies access if &lt;as-regular-expression&gt; is matched.  </P>
<P>Matches are performed in the order in which they appear.  At the end of a list with the same number, deny .* is assumed.<FONT SIZE=2> </P>
</FONT><FONT SIZE=3><P>The as regular expressions are as follows:</P>
</FONT><FONT SIZE=2><P>&lt;number&gt;  an as number (1 through 65535)</P>
<P>.           Matches any single as number</P>
<P>*          Matches 0 or more sequences of the pattern</P>
<P>+          Matches 1 or more sequences of the pattern</P>
<P>?          Matches 0 or 1 occurrences of the pattern</P>
<P>^          Matches the beginning of the as path</P>
<P>$          Matches the end of the as path</P>
<P>|           Matches one of the alternatives</P>
<P>()         Encloses a pattern</P>
</FONT><FONT SIZE=3><P>For example:</P>
</FONT><FONT SIZE=2><P>.* &#9;&#9;any AS path, including null</P>
<P>237$&#9;&#9;originated from AS 237</P>
<P>237&#9;&#9;via AS 237</P>
<P>^(237|10)&#9;from AS 237 or AS 10</P>
<P>^$&#9;&#9;originated from this AS</P>
<B><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

<P>network &lt;prefix&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Configure routes originating in BGP.</P>
</FONT><H4>&nbsp;</H4></DIR>
</DIR>
</DIR>
</DIR>

<B><P>route-map</B>define a route-map</P>
<B><FONT SIZE=2><P>route-map <number></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Defines the conditions to modify attributes of any updates.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>       route-map </B>sub commands</P>
<B><P>set as-path [prepend] <as-path-string></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets or prepends <as-path-string> to the as-path of the route.  Note that there is no matching function implemented.</P>
<PRE><as-path-string></FONT><B> ... <number>...    a sequence of AS numbers<BR>
        [ <number>... ]  a set of AS numbers
</PRE>
<FONT SIZE=2><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

<P>set community [additive] (<number>|no-export|no-advertise)</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets community attribute to the route, or appends if additive is specified.  <BR>
 <number> values are 1 to 4294967200.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set origin (igp|egp <as>|incomplete)</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets the origin code.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set next-hop &lt;address&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets the nexthop attribute. If the address is an IPv6 global address, it is set as BGP4+ next hop. In addition, If the address is an IPv6 link-local address, it is set as BGP4+ next hop link local address.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set metric <number></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets the metric value (MED).</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set local-preference <number></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets the local preference value.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set dpa as <number> <number></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets the DPA values.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set atomic-aggregate</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets automatic aggregate attribute.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>set aggregator as <number> </B>&lt;address&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Sets aggregator information.  &lt;address&gt; should be IPv4.</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><FONT FACE="Arial"><H5>Configuring Routing Protocols</H5>
</FONT><P>MRTd supports BGP4, BGP4+, RIP2, and RIPng. This version includes partial support for OSPF, and a PIM-DM implementation is underway.</P>
<B><P><A NAME="_Hlk444334573">router</B>configures routing protocol</P>
<B><FONT SIZE=2><P>router bgp </B>&lt;as number&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Enables assignment of the BGP (or BGP4+ if IPv6 is available) routing protocol <as number> to the routing process.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><DL>
<DT></A>router ripng</DT>
</DL><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Enables RIPng routing protocol.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><DL>
<DT>router rip</DT>
</DL><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Enables RIP routing protocol.</P></DIR>
</DIR>
</DIR>
</DIR>

<P>The following commands are available for the <B>router bgp </B>command.</P>
<B><P>neighbor <peer address> remote-as </B>&lt;peer's as number&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Adds an entry of BGP neighbor with <peer address>.    <BR>
&lt;peer's as number&gt; should be an AS number to which the peer belongs.<BR>
Must precede other neighbor commands for <peer address>.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address>  update-source <source address > </P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Specifies the addresses for outgoing BGP connections and at which incoming BGP connections are accepted.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address>  next-hop-self </P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Forces the next hop in the AS path to be the host itself.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor </B>&lt;peer address&gt; <B>(transparent-as|transparent-nexthop</B>)</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Set transparent option for neighbor, as in use as a route server.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor </B>&lt;peer address&gt; <B>passive</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Does not initiate BGP connectionsonly accepts them.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address>  maximum-prefix <number > </P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sets the maximum number of prefixes incuded in a BGP update.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address> distribute-list <number> {in|out}</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Applies access-list <number> to incoming (in) or outgoing (out) route updates for a peer with <peer address>.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor </B>&lt;peer address&gt; <B>filter-list </B>&lt;number&gt; <B>{in|out}</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Applies as-path access-list &lt;number&gt; to incoming (in) or outgoing (out) route updates for a peer with &lt;peer address&gt;.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor &lt;</B>peer address<B>&gt; weight &lt;</B>num<B>&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Set a weight associated with a peer.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor</B> &lt;peer address&gt; <B>trace</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Enable tracing of a BGP peer.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address> route-map <number> {in|out}</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Applies a route-map <number> to incoming (in) or outgoing (out) route updates for a peer with <peer address>.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address> route-reflector-client</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Sends routes to an internal peer even if learned from another internal peer (route reflection.)</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address> description </B>&lt;string&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Attaches &lt;string&gt; to the neighbor as a description.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address> (holdtime|keepalive|connectretry|starttime) &lt;num&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Set the timer for a neighbor.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor </B>&lt;name&gt;<B> neighbor-list </B>&lt;num&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Allows anonymous neighbor peers.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>neighbor <peer address> bgp4+ (0|1|old|new|rfc|auto)</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Specifies BGP4+ packet format.  The default is 0.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>redistribute <proto></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Redistributes routes from <proto> such as rip to BGP.</P>
<B><P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

<P>aggregate-address <prefix> [summary-only] [as-set]</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Creates an aggregate entry to <prefix>. summary-only suppresses  all more specific routes from updates. as-set merges as paths to  generate as-set path attribute.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>bgp router &lt;id&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Defines the router ID used in BGP.  The router ID should be an IPv4 address assigned to the host.  The default is one of the addresses available on the host; which is picked up by MRT automatically. </P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>bgp cluster-id &lt;id&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Defines the cluster ID used in the BGP reflector.  The default is the same as the router ID. </P>
<P> </P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><B><P>router rip/ripng</B>RIP/RIPng routing</P>
<FONT SIZE=2><P>The following commands are available for the <B>router RIP/RIPng </B>command.</P>
<B><P>network {<prefix>|<interface>}</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Specifies interface(s) by <prefix> or by name. to turn on RIP/RIPng.  All interfaces included under <prefix> will be enabled.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>distribute-list <number> {in|out} <interface></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Applies access-list <number> to incoming (in) or outgoing (out) route updates on <interface>.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>redistribute <proto></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Redistributes routes from <proto> to RIP/RIPng.</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><FONT FACE="Arial"><H5>Statistics Collection</H5>
</FONT><P>MRTd can log both routing table dumps and binary traces of all BGP events in a format parseable by other MRT (and soon Zebra) tools. So, for example, BGP updates can be recorded via MRTd and later replayed to test peers through bgpsim or sbgp. <I>The MRT Programmers Manual</I> includes a description of the MRT packet formats.</P>
<B><P>dump bgp--</B>dump BGP updates, state changes, and routes</P>
<B><FONT SIZE=2><P>dump-binary [{ip|ipv6}] bgp routes <filename> [<duration>]</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Dump BGP routing table in binary MRT format.  <filename> can be in strftime() format. If <duration> is specified, the file will be reopened every <duration>, re-evaluating the filename.  If <B>ip</B> or <B>ipv6 </B>is specified, only the routes of the address will be dumped.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>dump [{ip|ipv6}] bgp {routes|updates|all} <filename> [<duration>]</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Dumps BGP/BGP4+ routes, updates, or all into the file <filename>.<BR>
 <filename> can be in strftime() format. If <duration> is specified, the file will be reopened every <duration>, re-evaluating the filename. If <B>ip</B> or <B>ipv6 </B>is specified, only the routes of the address will be dumped.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>dump bgp view &lt;view number&gt; <filename> [<duration>]</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Dump routing table for specified view.</P>
</FONT><H3>&nbsp;</H3></DIR>
</DIR>
</DIR>
</DIR>

<H3><A NAME="_Toc451331954">Interactive Interface Commands</A></H3>
<P>MRTd and BGPsim provide an interactive user interface for management (e.g., viewing the routing table) and configuration.</P>
<P>The following commands are specific to MRTd and BGPSim. Additional commands are described in Chapter 2, &quot;Getting Started.&quot;</P>
<H4>clear bgp * &lt;name&gt;  Close/reset BGP peering session with this peer *</H4>
<H4>config *  Enter configuration mode</H4>
<H4>quit  Exit mode, or exit UII interface</H4>
<H4>show  show system information</H4>
<B><FONT SIZE=2><P>show [{ip|ipv6}] bgp</P>
<P>show [{ip|ipv6}] bgp summary</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show BGP peers summary</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show [{ip|ipv6}] bgp neighbors  </P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show BGP peers and their status</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show bgp neighbors </B>(&lt;peer address&gt;|&lt;name&gt;|*) <B>errors</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show recent BGP errors/notifications with this peer.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show bgp neighbors </B>(&lt;peer address&gt;|&lt;name&gt;|*) <B>routes</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show BGP routes sent to this peer</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show [{ip|ipv6}] bgp routes</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show BGP routing table</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show [{ip|ipv6}] bgp regexp </B>&lt;as-regular expression&gt; </P><DIR>
<DIR>
<DIR>
<DIR>

<P>Show BGP routes matching the as-path regular expression.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show [{ip|ipv6}] bgp prefix </B>&lt;prefix&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

<P>Show BGP routes matching this prefix.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show config</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show the current configuration</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><B><P>&#9;&#9;<FONT SIZE=2>show interfaces</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show all interfaces available</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show ip</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show IPv4 routing table</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show ipv6</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show IPv6 routing table</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show rib</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show the central routing table</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show rip</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show RIP status</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show rip routes</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show RIP routing table</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show ripng</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show RIPng status</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>show ripng routes</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Show RIPng routing table</P></DIR>
</DIR>

<B><P>show view </B>&lt;view number&gt;</P>
<P>Show the BGP routing table for this view.</P>
<P>&nbsp;</P></DIR>
</DIR>

</FONT><H4>dump &amp; load  dump and load bgp binary routing table dump to/from disk</H4>
<B><FONT SIZE=2><P>dump [{ip|ipv6}] bgp routes &lt;filename&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Dumps bgp routes into the file &lt;filename&gt;.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>load [{ip|ipv6}] bgp routes &lt;filename&gt;</P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Loads bgp routes from the file &lt;filename&gt;.  Note that this will introduce inconsistency into the routing table.</P>
<P>&nbsp;</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><H4>trace  log protocol information to disk or UII</H4>
<B><FONT SIZE=2><P>trace [{ip|ipv6}] bgp </FONT><FONT SIZE=4>*</P><DIR>
<DIR>
<DIR>
<DIR>

</B></FONT><FONT SIZE=2><P>Enable tracing of BGP protocol.</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>trace bgp neighbor </B>(&lt;peer address&gt;|&lt;peer name&gt;) </FONT><B><FONT SIZE=4>*</P><DIR>
<DIR>
<DIR>
<DIR>

</B></FONT><FONT SIZE=2><P>Enable tracing on the peer.  (The &quot;terminal monitor&quot; command is required to watch this at the UII.)</P></DIR>
</DIR>
</DIR>
</DIR>

<B><P>trace  bgp view (*|inet|inet6|&lt;num&gt;) </FONT><FONT SIZE=4>*</P><DIR>
<DIR>
<DIR>
<DIR>

</B></FONT><FONT SIZE=2><P>Enable tracing of view routing table changes.</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><H4>quitquit the mode or disconnect</H4><DIR>

<B><FONT SIZE=4><P>*  </B></FONT>Note that if you set enable password in your configuration, the enable command is required in order to execute some potentially dangerous commands, such as clear bgp, config, and trace bgp (marked with an asterisk<B><FONT SIZE=4>* </B></FONT>above.)</P>
<B><P>&nbsp;</P>
</B><DL>
<DT>&nbsp;</DT></DIR>

<DT>Following are examples of the interactive interface <A NAME="bgpsim">commands:</DT>
</DL><DIR>

<CODE><P>[21] MRTd&gt; show ip</P>
<P>4 prefixes</P>
<P> P Pref Time     Destination                Next Hop                 If</P>
<P>*S    1 74:42:37 0.0.0.0/0                  198.108.60.1             ep0</P>
<P>*C    0 74:42:37 127.0.0.0/8                0.0.0.0                  lo0</P>
<P>*C    0 74:42:37 192.168.12.0/24            0.0.0.0                  lo0</P>
<P>*C    0 74:42:37 198.108.60.0/24            0.0.0.0                  lo0</P>
<P>[17] MRTd&gt; show ripng</P>
<P>&nbsp;</P>
<P>Routing Protocol is "ripng" (Using IPV6)</P>
<P>Listening on port 521 (socket 10)</P>
<P>Sending updates every 30 seconds +/- 15, next due in 29 seconds</P>
<P>Triggered update and split horizon (no poisoned reverse) implemented</P>
<P>Invalid after 180 seconds, hold down 180, flushed after 120</P>
<P>&nbsp;</P>
<P>106 ripng routes and 107 ripng attributes active</P>
<P>106 hash entries</P></DIR>

</CODE><H2><A NAME="_Toc409238195"><A NAME="_Toc409241006"></H2>
<H2><A NAME="_Toc451331955">4.  BGPsim</A></A></A></H2>
<P>BGPsim simulates complex BGP4 routing environments with possibly high levels of routing instability/change. </P>
<P>BGPsim includes a perl program, BGPsim.pl, which is used to generate ASCII descriptions of BGP traffic for use with route_btoa and sbgp.  (The BGPsim Perl code is still quite rough.) </P>
<H3><A NAME="_Toc451331956">Synopsis</A></H3>
<B><P>BGPsim [-f configuration_file] [l routing table] [-v] [-s] [-m]</P>
</B><H3><A NAME="_Toc451331957">Options</A></H3>
<B><FONT SIZE=2><DL>
<DT>-f configuration_file </DT>
</B><DD>Read the specified configuration file. By default, bgpsim tries to read ./bgpsim.conf. </DD>
<B><DT>-v </DT>
</B><DD>Turn on verbose logging to standard output.  This is useful to turn on logging before the debug commands are read in the configuration file. </DD>
<B><DT>-s </DT>
</B><DD>By default, BGPSim does not set mandatory BGP attributes, including origin, nexthop and ASPath. If this flag is used, BGPsim will add these attributes and prepend the local AS to the ASPath. </DD>
<B><DT>-m </DT>
</B><DD>Use a new dump format.</DD>
</FONT><DT>&nbsp;</DT>
</DL>
<H3><A NAME="_Toc451331958">Description</A></H3>
<P>By default, BGPsim looks for "./bgpsim.conf". The format of the configuration file is described below. BGPsim also has an interactive (Cisco Systems router-like) interface: telnet to port 5674 on the machine running BGPsim. </P>
<B><U><P>NOTE:</B></U> <U> </U>BGPsim does not include mandatory attributes by default. You will need to explicitly include a nexthop, origin, and apsath attribute in your BGPsim configuration<U>. Also note that </U>BGPSim does not prepend its own AS by default.</P>
<H3> <A NAME="_Toc451331959">Sample Configuration File</A></H3>
<P>A sample BGPsim configuration file is shown below.</P>
<PRE>
network-list 1 
range 10.0.0.0/8 11.0.0.0
stability 10 jitter 4
map 1
!
route-map 1
set nexthop 198.108.60.8
set aspath 185 123 23 23 12 
set origin igp
!

network-list 2 
range 192.32.0.0/24 192.32.255.0
stability 9 jitter 3
change 12 jitter 4
route-map 2 3
!
route-map 2
set next-hop 198.108.60.244
set as-path 185 123 23 23 12
set origin igp
set community 56:123 
set dpa as 56 121
set local-preference 23
!
route-map 3
set as-path 185 100 10 102 
set origin igp
set community 100:345
set dpa as 3 23
set local-preference 83
!
router bgp 185
  neighbor 198.108.60.244 remote-as 65
  neighbor 198.108.60.112 remote-as 165</PRE>
<P>&nbsp;</P>
<P>This file describes two simulation processes, as defined by network-list 1 and 2, which changes routes to two BGP peers (AS 65 and AS165). </P>
<P>The first simulation process, network-list 1, changes routes (10.0.0.0/8 and 11.0.0.0/8) as defined in range every 10 seconds.  This simulates an announcement of the routes first, and then a withdrawal after 10 seconds.  Ten seconds after the withdraw, the next announcement is propagated.  Thus the announcements and withdraws are repeated every 10 seconds.  These routes have attributes defined in route-map 1:  nexthop is 198.108.60.8 and aspath is a sequence of 123 23 23 12. </P>
<P>The second network list describes simulation of the range of routes from 192.32.0.0/24 to 192.32.255.0/24 (i.e. 192.32.1.0/24, 192.32.2.0/24, etc.) All of these routes have an initial aspath of (123 23 23 12), a next-hop of 198.108.60.244, and others as defined in route-map 2. These attributes change every 12 seconds among route-maps 2 and 3. </P>
<P>The peers (AS 65 and AS165) receive routing updates originated by these two simulation processes. </P>
<H3><A NAME="_Toc451331960">Configuration Commands</A></H3>
<P>For information about the <B>uii, debug, </B>and<B> access-list </B>configuration commands, see Chapter 2, &quot;Getting Started.&quot;  In addition to the MRTd configuration commands, the following are available in BGPsim to simulate routing changes: </P>
<B><FONT SIZE=2><P>network-list <number></P><DIR>

</B><P>Defines a network-list with <number>. This definition behaves like a routing process which generates routing changes within a range defined by range subcommand by an interval defined by stability subcommand, changing route attributes as specified by change and route-map subcommands.</P></DIR>

</FONT><P>Options include:</P><DIR>
<DIR>

<B><FONT SIZE=2><P>range <start prefix> <end prefix></P><DIR>
<DIR>

</B><P>Defines a range to announce and withdraw, starting with <start prefix> up to <end prefix> (inclusive).  The range is along classful boundaries.</P></DIR>
</DIR>

<B><P>stability <interval number of seconds> </B>[<B>jitter <jitter number></B>]</P><DIR>
<DIR>

<P>Defines an interval <number> in second to change routes.  Routes are announced first and then withdrawn after the interval. Thus, with the interval, announce and withdraw <B>repeat</B>. Jitter adds/subtracts a random number of seconds between 0 and &lt;jitter number&gt; to the interval.</P></DIR>
</DIR>

<B><P>change <interval umber of seconds> </B>[<B>jitter <jitter number></B>] </P><DIR>
<DIR>

<P>Defines an interval <number> in second to change attributes of  routes being announced. route-map subcommand defines a sequence. Jitter adds/subtracts a random &lt;number&gt; of seconds from the timer.</P></DIR>
</DIR>

<B><P>map <number> ...</P><DIR>
<DIR>

</B><P>Defines a sequence of route-maps to be used. The next route-mapis adopted after the interval defined in change subcommand. At the end of list, the first route-map is adopted as a next. The first route-map behaves as a default, that is, this is always adopted before adopting other route-maps.</P></DIR>
</DIR>

<B><P>file <filename> ...</P><DIR>
<DIR>

</B><P>Loads routes from routing table dump file  <filename> rather than using a range of addresses. </P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><P>BGPSim also adds several commands to bgp router commands:</P>
<B><FONT SIZE=2><P>neighbor <peer address>  stability <seconds></P><DIR>
<DIR>
<DIR>
<DIR>

</B><P>Define stability for TCP peering session with this peer.</P></DIR>
</DIR>
</DIR>
</DIR>

</FONT><H3><A NAME="_Toc451331961">Interactive Interface Commands</A></H3>
<P>The BGPsim interactive interface supports the following commands in addition to MRTd interactive interface commands: </P>
<B><FONT SIZE=2><P>show simulation </P>
<P>stop simulation</P>
<P>start simulation</P>
</B></FONT><H2><A NAME="_Toc409238196"><A NAME="_Toc409241007"></H2>
<H2><A NAME="_Toc451331962">5.  SBGP</A></A></A></H2>
<P><A NAME="sbgp">SBGP is a simple BGP4 speaker and listener. SBGP does not apply policy to routes, nor does it maintain a routing information base (RIB) of routes it has previously learned. Rather, SBGP provides a mechanism for monitoring routing information sent from a peer, and for injecting routing information into a peering session. </P>
<H3><A NAME="_Toc451331963">Synopsis</A></H3>
<B><P>sbgp [-av] [-i binary_data_in_file] [-o binary_data_out_file] [-l log_file] [-f config_file] [-c port] [-d port] [my AS] [peer_IP peer_AS]... </P>
</B><H3><A NAME="_Toc451331964">Options</A></H3>
<B><FONT SIZE=2><P>-a </P><DIR>

</B><P>Accept peering BGP connection from all peers. </P></DIR>

<B><P>-v </P><DIR>

</B><P>Turn on verbose logging to standard output. </P></DIR>

<B><P>-i binary_data_in_file </P><DIR>

</B><P>Inject routes from this file into every peering session. Use the file name 'stdin' to read input from standard in. </P></DIR>

<B><P>-o binary_data_out_file </P><DIR>

</B><P>Save route updates from all peering sessions into this file. Use the file name 'stdout' to write output to standard out. </P></DIR>

<B><P>-l log_file </P><DIR>

</B><P>Write logging information to this file. By default, SBGP logs to /tmp/bgp.log.pid, where pid is the process ID number of the SBGP process. </P></DIR>

<B><P>-f config_file </P><DIR>

</B><P>Not supported yet </P></DIR>

<B><P>-p </P><DIR>

</B><P>Not supported yet </P></DIR>

<B><P>-c port</P><DIR>

</B><P> Connect to this port on all BGP peers. </P></DIR>

<B><P>-d port</P><DIR>

</B><P> Listen on this port for BGP peering connections. </P></DIR>

<B><P>[my AS] [peer_IP peer_AS]... </P><DIR>

</B><P> Use my AS for my Autonymous System number and open peering sessions with each peer_IP address. </P>
</FONT><H3>&nbsp;</H3></DIR>

<H3><A NAME="_Toc451331965">Description</A></H3>
<P>As arguments, SBGP takes the local AS number followed by the IP address and AS number of the BGP4 peer. Multiple peer IP addresses and AS pairs may be specified. For example:</P>
<B><P>sbgp AS2011 enss131.t3.ans.net AS690</P>
</B><P>attempts to initiate a BGP4 peering session with the old NSFNET backone on enss131. By default, SBGP writes logging information to /tmp/bgp.log. </P>
<P>The following command directs tracing information to stdout (the -v option) and will save MRT messages containing the contents of BPG4 update packets to /tmp/data (the -o option).</P>
<B><P>sbgp -vo data AS2011 enss131.t3.ans.net AS690</P>
</B><H4>Note that the remote peer must be configured to accept a BGP4 peering session from the machine on which SBGP is running. </H4>
<P>The following command will inject routes stored in the binary MRT message file data into the peering sessions with enss131:</P>
<B><P>sbgp -vi data AS185 enss131.t3.and.net AS690</P>
</B><DL>
<DT><A NAME="route_btoa"></DT>
</DL>
<H2><A NAME="_Toc409238197"><A NAME="_Toc409241008"></H2>
<H2><A NAME="_Toc451331966">6.  ROUTE_BTOA</A></A></A></H2>
<P>ROUTE_BTOA converts binary MRT messages to ASCII. By default, the program writes human-readable ASCII descriptions of MRT message streams or files to standard out. Binary MRT messages may be generated by programs such as SBGP and MRTd for monitoring, research, and statistics collection purposes. In this release of MRT, route_btoa supports the parsing of BGP, BGP+ and RIPng packets.</P>
<P>Route_btoa includes a Perl version of the program. In general, the compiled version is probably more robust and up-to-date than the Perl code. </P>
<H3><A NAME="_Toc451331967">Synopsis</A></H3>
<H4>route_btoa [-m] [-i input_binary_file] </H4>
<H3><A NAME="_Toc451331968">Options</A></H3>
<B><FONT SIZE=2><P>-i binary_data_in_file </P><DIR>

</B><P>Read routes from this file binary MRT file. Using a file name of 'stdin' will read input from standard in. </P></DIR>

<B><P>-m </P><DIR>

</B><P>Create machine-parseable output. </P></DIR>

</FONT><H3><A NAME="_Toc451331969">Description</A></H3>
<P>The following command writes a formatted, ASCII description of BGP4 update packets from a peering session with the NSFNET backbone to standard output: </P>
<B><P>sbgp -bo stdout | route_btoa -i stdin</P>
</B><P>Below is an example of the output produced by route_btoa. Most of the fields should be self-explanatory.</P><DIR>
<DIR>

<CODE><P>&gt; /statistics/bin/route_btoa2 -i /cache/mae-east/bgp.980114.21:30 </P></DIR>
</DIR>

<P>TIME: 01/14/98 21:30:00</P>
<P>TYPE: BGP/UPDATE</P>
<P>TO: AS2885   192.41.177.169</P>
<P>FROM: 4.0.0.10 AS1</P>
<P>ASPATH: 1</P>
<P>ORIGIN: IGP         </P>
<P>NEXT_HOP: 192.41.177.2</P>
<P>MULTIEXIT: 1546</P>
<P>ANNOUNCE:</P>
<P>  140.249.0.0    </P>
<P>&nbsp;</P>
<P>TIME: 01/14/98 21:30:01</P>
<P>TYPE: BGP/UPDATE</P>
<P>TO: AS2885   192.41.177.169</P>
<P>FROM: 144.228.107.1 AS1239</P>
<P>ASPATH: 1239 6453 5769</P>
<P>ORIGIN: IGP         </P>
<P>NEXT_HOP: 192.41.177.241</P>
<P>MULTIEXIT: 91</P>
<P>ANNOUNCE:</P>
</CODE><P>Route_BtoA also supports the generation of machine-readable output. This mode generates output that is easily parsed by awk or Perl scripts for statistics calculations. Note that &quot;<B>-m</B>&quot; mode does not preserve information about packet boundaries. The format for each line of the machine-readable output for BGP4 and BGP4+ packets is:</P><DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>

<B><P>Protocol</B> | <B>Time</B> | <B>Type</B> | <B>PeerIP</B> | <B>PeerAS</B> | <B>Prefix | &lt;update dependant information&gt;</P></DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>
</DIR>

</B><P>Where <B>protocol</B> is BGP, or BGP4. The <B>time</B> is number of seconds since epoch when the packet was recorded. The <B>type</B> is A for announcement, or W for withdrawal. <B>PeerIP</B> and <B>PeerAS</B> are the IP address and AS number of the BGP peer from which we received the update. <B>Prefix</B> is the route prefix described in the update.</P>
<P>For BGP announcements, update-dependant information contains:</P>
<B><P>ASPATH</B> | <B>Origin</B> | <B>NextHop</B> | <B>Local_Pref</B> | <B>MED | Community</P>
</B><P>Where <B>ASPATH</B> is the autonomous system path of the update. <B>Origin</B> is IGP, EGP, or Unknown. And <B>local_pref</B>, <B>MED</B> and <B>Community</B> are as the names imply. Below is an example of route_btoa machine output of MRTd-collected BGP packets:</P><DIR>
<DIR>

<CODE><P>BGP|884831400|A|4.0.0.10|1|140.249.0.0/16|1|IGP|192.41.177.2|0|1546</P>
<P>BGP|884831401|A|144.228.107.1|1239|205.113.0.0/16|1239 6453</P>
<P>5769|IGP|192.41.177.241|0|91</P></DIR>
</DIR>

<P>BGP|884831402|W|204.70.7.53|3561|198.163.111.0/24</P>
<P>BGP|884831402|W|204.70.7.53|3561|199.212.219.0/24</P>
<P>BGP|884831402|W|204.70.7.53|3561|199.235.123.0/24</P><DIR>
<DIR>

<P>BGP|884831402|W|204.70.7.53|3561|204.112.101.0/24</P>
<P>BGP|884831402|W|204.70.7.53|3561|204.112.232.0/24</P>
<P>BGP|884831402|W|204.70.7.53|3561|205.189.8.0/24</P>
<P>BGP|884831402|W|204.70.7.53|3561|205.211.8.0/24</P>
</CODE><P>&nbsp;</P></DIR>
</DIR>

<H2><A NAME="route_atob"></H2>
<H2><A NAME="_Toc409238198"><A NAME="_Toc409241009"><A NAME="_Toc451331970">7.  ROUTE_ATOB</A></A></A></H2>
<P>Route_AtoB converts ASCII descriptions of MRT messages to binary. By default, the program writes binary MRT message streams or files to standard out. </P>
<P>Route_AtoB includes a perl version of the program.  In general, the compiled version is probably more robust and up-to-date than the perl code. </P>
<H3><A NAME="_Toc451331971">Synopsis</A></H3>
<H4>route_atob -i ASCII_input_file </H4>
<H3><A NAME="_Toc451331972">Options</A></H3>
<B><DL>
<DT>-i ascii_input_file </DT>
</DL><DIR>

</B><FONT SIZE=2><P>Read ASCII descriptions of MRT messages from this file. Using a file name of 'stdin' will read input from standard in. </P></DIR>

</FONT><H3><A NAME="_Toc451331973">Description</A></H3>
<P>The following command sequence will inject the routes described in in the input file into the BGP peering session with enss131. </P>
<B><CODE><P>route_atob -i /tmp/input | sbgp -i stdin enss131 AS690</CODE> </P>
</B><P>See the output of route_btoa for the grammer required by route_atob. </A></A></A></A></A></P>
<H2><A NAME="_Toc451331974">8. Data Distiller</A></H2>
<P>Data Distiller generates summary reports on the number of routing messages seen at one or more peering points. Data are gathered by passive (i.e. listening only) participation in the BGP peering session. </P>
<H3><A NAME="_Toc451331975">Synopsis</A></H3>
<B><P>datadstl [-f config_file] [-p uii_port] [-v] [-d]</P>
</B><H3><A NAME="_Toc451331976">Options</A></H3>
<B><FONT SIZE=2><P>-d </P><DIR>

</B><P>Run Data Distiller as a daemon. The process detaches from its controlling tty, closes inherited file descriptors, etc.  This option  overrides the <B>-v</B> option. </P></DIR>

<B><P>-f configuration_file</P><DIR>

</B><P>Read the specified configuration file.  If Data Distiller is not running in daemon mode, the default is datadstl.conf in the working directory.  If running in daemon mode, the default is datadstl.conf in the root directory. </P></DIR>

<B><P>-p </P><DIR>

</B><P>Specifies the port on which to accept UII telnet connections.  (Default: 5680) </P></DIR>

<B><P>-v </P><DIR>

</B><P>Log to stdout.  If this option is specified and a log filename is included in the config file, log messages will be sent to stdout until the appropriate line in the config file is read.  Note that the <B>-d</B> option overrides the <B>-v</B> option.  Running Data Distiller as a daemon requires closing all inherited file descriptors, including stdout/stderr. </P></DIR>

</FONT><H3><A NAME="_Toc451331977">Description</A></H3>
<P>Data Distiller reads raw MRTd data files and cooks them into a variety of periodic reports. These reports are disseminated to the IPMA Java clients using either a web (HTTP) server, or the Dolphin server. </P>
<P>Data may be collected either by Data Distiller, or by a separate MRTd process. The former is the simplest way of running Data Distiller. However, in certain situations, running separate MRTd processes may be desired. You may, for example, wish to limit the load on the machine at the peering point. </P>
<P>If Data Distiller is responsible for data collection, it will need access to low numbered ports so that it can establish a BGP peering session. On most systems, this means root access. </P>
<P>If MRTd is collectiong the data, Data Distiller must be able to access the filesystem to which MRTd is dumping the data. Distributed file systems (such as NFS) work well with Data Distiller.  If the data will be in AFS, please be sure to take heed of token expiration issues. </P>
<H3><A NAME="_Toc451331978">Operations</A></H3>
<P>Data Distiller periodically updates its state from the MRTd raw data files. It then generates cooked data. This data can either be stored using the file system, or published to the Dolphin data dissemination server. Any exceptional events (such as the server disconnecting) are logged. Data Distiller can also be configured to log more mundane events, such as processing of the raw data files, or the action of outputting each cooked data file. </P>
<H4>Telnet Interface</H4>
<P>Data Distiller uses the MRT UII facility for its telnet interface, and supports standard MRT commands for remote monitoring and administration. The telnet interface can be disabled through the configuration file.  Note that Data Distiller does not look in /etc/services for its UII port number.</P>
<P>Data Distiller also supports remote configuration. Any command that may appear in a configuration file may also be issued via the telnet interface. </P>
<H4>Configuration </H4>
<P>Although Data Distiller can be configured over a telnet connection, it is easier, and more reliable, to do so via the configuration file. Below is a sample. </P>
<P>&nbsp;</P>
<FONT FACE="Courier New" SIZE=2><P>! ASExplorer, FlapGraph, and FlapTableDaily are the currently supported cooked</P>
<P>! data types. Each corresponds to one Java visualization tool.</P>
<P>!</P>
<P>! A command that begin with any of these applies only</P>
<P>! to that data type. All other commands are "global" -- they affect the</P>
<P>! operation of Data Distiller generally.</P>
<P>!</P>
<P>! ---------------------------------------------------------------------------- !</P>
<P>!</P>
<P>! Specify logging.</P>
<P>!   format: log &lt;level&gt; [logpath max-length]</P>
<P>!   log normal messages to /tmp/latest.log. don't exceed 100K for logfile</P>
<P>debug norm /tmp/latest.log 100000</P>
<P>!   also log trace-level messages</P>
<P>debug trace</P>
<P>!</P>
<P>! ---------------------------------------------------------------------------- !</P>
<P>!</P>
<P>! UII Configuration</P>
<P>!    which port to listen on?</P>
<P>!      format: uii_port &lt;port #&gt;</P>
<P>!      listen on port 5690</P>
<P>uii_port 5690</P>
<P>!    what's the password for access?</P>
<P>!      format: password &lt;string&gt;</P>
<P>!      password is CHANGEME</P>
<P>password CHANGEME</P>
<P>!</P>
<P>! ---------------------------------------------------------------------------- !</P>
<P>!</P>
<P>&nbsp;</P>
<P>! Data Capture</P>
<P>! </P>
<P>! peering -- who do we capture BGP traffic from?</P>
<P>!   who are we?</P>
<P>!     format: router bgp &lt;local as number&gt;</P>
<P>!     we are AS -5000 </P>
<P>router bgp -5000</P>
<P>!   who do we peer with, and where?</P>
<P>!     format: neighbor &lt;ip addr&gt; remote-as &lt;as number&gt;</P>
<P>!     peer with AS 0 at 192.168.1.1</P>
<P>neighbor 192.168.1.1 remote-as 0</P>
<P>!     and AS -1000 at 192.168.5.5</P>
<P>neighbor 192.168.5.5 remote-as -1000</P>
<P>!</P>
<P>! storage -- where do we put the captures, and how often?</P>
<P>!   format: dump bgp updates &lt;capture path&gt;/&lt;peering point&gt;/bgp.%y%m%d.%H:%M &lt;interval&gt;</P>
<P>!   store the captures in /bgpdata/mae-east, and dump the data every 15 minutes</P>
<P>!   if you change the format specifier for the date, you'll need to change</P>
<P>!   parsename in bgp_db.c</P>
<P>dump bgp updates /bgpdata/mae-east/bgp.%Y%m%d.%H:%M 15m</P>
<P>!</P>
<P>! ---------------------------------------------------------------------------- !</P>
<P>! </P>
<P>! "Global" Configuration (affects all cooked data types)</P>
<P>!</P>
<P>! Tell Data Distiller where to find the datafiles.</P>
<P>!   format: database_directory &lt;capture path&gt;</P>
<P>!   our files are in /bgpdata.</P>
<P>!   (this is the same as capture path in "dump bgp updates".)</P>
<P>database_directory /bgpdata</P>
<P>!</P>
<P>! The data files that we read have their starting time as part of the filename.</P>
<P>! Data Distiller needs to know whether the time is in UTC or localtime.</P>
<P>!   format: filename_timezone_local {0|1}</P>
<P>!   filenames are in localtime</P>
<P>filename_timezone_local 1</P>
<P>!</P>
<P>! How much time is covered by each data file? </P>
<P>!   format: file_timespan &lt;interval (in seconds)&gt;</P>
<P>!   This is the same interval as in "dump bgp updates", except that this must</P>
<P>!   be in seconds.</P>
<P>file_timespan 900</P>
<P>!</P>
<P>! If Data Distiller is publishing data frequently (as it is in this sample</P>
<P>! conifguration), then a significant amount of time will be spent reading</P>
<P>! directory information. This can be avoided by using the directory cache.</P>
<P>! Here we indicate how long the cache is considered valid (a value of 0 will,</P>
<P>! of course, effectively disable the cache).</P>
<P>! Be careful not to set this value to more than the bucket size for the</P>
<P>! FlapGraph/FlapTableDaily data (15 minutes), because you may miss updates if</P>
<P>! you do.</P>
<P>!   format: dircache_time &lt;time (in seconds)&gt;</P>
<P>!   invalidate the directory cache info after 5 minutes</P>
<P>dircache_time 300</P>
<P>!</P>
<P>! ---------------------------------------------------------------------------- !</P>
<P>! </P>
<P>! ASExplorer Configuration</P>
<P>!</P>
<P>! In our installation, the BGP data files are placed in directories according to</P>
<P>! the peering point at which they were collected. But the ASExplorer tool</P>
<P>! would like to know which probe machine collected the data. We implement the</P>
<P>! mapping with these configuration commands. This is rather "cosmetic", and</P>
<P>! optional.</P>
<P>!   format:  ASExplorer probe_name &lt;directory&gt; &lt;probe machine&gt;</P>
<P>!   files in mae-east directory contain data collected by host rs2.mae-east.rsng.net</P>
<P>ASExplorer probe_name mae-east rs2.mae-east.rsng.net</P>
<P>!   files in mae-west have data from rs2.mae-west.rsng.net</P>
<P>ASExplorer probe_name mae-west rs2.mae-west.rsng.net</P>
<P>!   files in aads have data from rs2.mae-west.rsng.net</P>
<P>ASExplorer probe_name aads rs2.aads.rsng.net</P>
<P>!</P>
<P>! How often should ASExplorer cooked data be updated?</P>
<P>!   format: ASExplorer update_interval &lt;interval (in seconds)&gt;</P>
<P>!   update ASExplorer data every 60 seconds</P>
<P>ASExplorer update_interval 60</P>
<P>! ASExplorer generates summary information for a sliding window. Here we specify</P>
<P>! the window size.</P>
<P>!   format: ASExplorer report_time_range &lt;interval (in seconds)&gt;</P>
<P>!   gather ASExplorer data over the last 90 minutes</P>
<P>ASExplorer report_time_range 4500</P>
<P>!</P>
<P>! Where do we put the cooked data? There are two possibilities.</P>
<P>! We can either save the data in the filesystem, or we can feed it to</P>
<P>! the Dolphin server. Examples follow.</P>
<P>!</P>
<P>!   Output Method?</P>
<P>!   format: ASExplorer output_method {dolphin|files}</P>
<P>ASExplorer output_method files</P>
<P>!   Method specific configuration: files</P>
<P>!     Where to put the output files?</P>
<P>!     format: ASExplorer basedir &lt;path&gt;</P>
<P>!     place the files in /web/stats. as /web implies, this should</P>
<P>!     be a directory accessible to your webserver.</P>
<P>ASExplorer basedir /web/stats</P>
<P>!   Method specific configuration: dolphin</P>
<P>!     What's the hostname of the Dolphin server?</P>
<P>!     format: ASExplorer salamander &lt;hostname&gt;</P>
<P>! ASExplorer salamander nowhere.nil</P>
<P>!     What port is Dolphin listening on?</P>
<P>!     format: ASExplorer port &lt;port #&gt;</P>
<P>! ASExplorer port 8899</P>
<P>!</P>
<P>! ---------------------------------------------------------------------------- !</P>
<P>! </P>
<P>! FlapGraph Configuration</P>
<P>!</P>
<P>! These commands are analagous to the ones for ASExplorer. See the ASExplorer</P>
<P>! example above for details.</P>
<P>!</P>
<P>FlapGraph update_interval 90</P>
<P>FlapGraph output_method files</P>
<P>FlapGraph basedir /web/stats</P>
<P>!</P>
<P>! </P>
<P>! FlapTableDaily Configuration</P>
<P>!</P>
<P>FlapTableDaily update_interval 105</P>
<P>FlapTableDaily output_method files</P>
<P>FlapTableDaily basedir /web/stats</P>
</FONT><P>!</P>
<FONT FACE="Courier New" SIZE=2><P>! ---------------------------------------------------------------------------- !</P>
<P>! </P>
<P>! Miscellaneous Configuration</P>
<P>!</P>
<P>! FlapGraph and FlapTableDaily data contain summary information about acitivity</P>
<P>! since midnight. This can be done based on localtime, or UTC. We recommend</P>
<P>! using UTC. (Note: this option is not independently configurable. The command</P>
<P>! can be issued referencing either FlapGraph or FlapTableDaily, but will affect</P>
<P>! both.) This option is primarily for backward compatibility with some internal</P>
<P>! tools. You should use UTC.</P>
<P>!   format: {FlapGraph|FlapTableDaily} use_localtime {0|1}</P>
<P>!   publish FlapGraph (and FlapTableDaily) data in UTC</P>
<P>FlapGraph use_localtime 0</P>
<P>!   equivalenty, we could have used FlapTableDaily use_localtime 0</P>
<P>!</P>
</FONT><H4>Configuring Client Tools </H4>
<P>In &lt;basedir&gt;, create a file called .conf. It should have the following information: </P>
<FONT FACE="Courier New" SIZE=2><P>Transport=HTTP</P>
<P>ToolListInternicURL=http://www.merit.edu/ipma/ipmaconf/</P>
<P>ASExplorer.RefreshInterval=&lt;"ASExplorer update_interval" value&gt;</P>
<P>FlapGraph.RefreshInterval=&lt;"FlapGraph update_interval" value&gt;</P>
<P>FlapTable.RefreshInterval=&lt;"FlapTable update_interval" value&gt;</P>
</FONT><P>The first two lines should be copied exactly. In the last three lines, substitute the apporpriate values from the Data Distiller configuration file. </P>
<H4>&nbsp;</H4>
<H4>File Directories</H4>
<P>The various directories might be arranged as follows: </P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P><IMG SRC="Image11.gif" WIDTH=697 HEIGHT=418></P></BODY>
</HTML>