JNOS Commands Manual - The R Commands
Jump Table/Index
Quick Headings Reference List |
The R Command Set
rarp The 'rarp' commands are associated with the Reverse Address Resolution Protocol (RARP). RARP is used where a station knows its own Ethernet address or callsign but does not know its own IP address. rarp Display RARP statistics. rarp query <interface> <ether_address|callsign> [<ether_address|callsign> ...] Issue a RARP request for an IP address for <ether_address> or <callsign>, via <interface>. rdate <subcommand> Remote Date (rdate) is used to set the time of the local JNOS system based on the time obtained from a remote system's time server. The Unix time (port 37) protocol is used. rdate offset [<+|-><hour_offset>] Causes the time read from the remote system to be adjusted by adding in the indicated <hour_offset>, which may be negative. If no <hour_offset> is provided, the current offset is displayed. Note: the time server provides the time in UTC. If an environment variable, TZ, is properly maintained, then an offset of zero should suffice. Otherwise, use the number of hours difference between local and UTC time. This offset command IS OBSOLETE and is no longer compiled into JNOS after release 1.10M. rdate server <hostname> Causes a connect to <hostname> TCP port 37, from which a time is obtained, adjusted by an offset if one was given, and then used to set the time on the local system. record [off | <filename>] Opens <filename> and appends to it all data received or sent in the current session. (This includes up/downloading to a mailbox). For example, if you are in a Telnet session and want to initiate recording, you will need to use the <F10> key to escape back to command mode to issue the 'record' command. The message "Recording into <filename>" will be displayed and another "JNOS>" prompt will be issued. Enter CR on a blank line and you will return to the Telnet session with recording activated. The command 'record off' stops recording and closes the file; this is done automatically when the associated session is closed. remark Writes its arguments to the current output stream. Similar to the MS-DOS 'echo' command. Example: remark "do: source \dial_usl.nos...to dial USL and start PPP." Writes the quoted string to the current output stream. remote [-s <syskey>] [-g <gwkey>] remote [-p <port>] [-k <key>] [-a <kickaddr>] <host> kick | exit | reset remote [-p <port>] [-k <key>] [-r addr/#bits] <host> add | drop; The remote command can be invoked three ways. First, to set a key phrase used by the remote server process to validate commands sent to it. Second, to send a UDP packet to a specified host commanding it to exit JNOS, reset the processor, or force a retransmission on TCP connections. Third, to send a UDP packet to a specified host commanding it to either add or drop an encapped route to a specified host or subnet via the sending system's IP address, that is, register ourselves as a gateway for a specified host or subnet for a finite period. For the second and third forms of the remote command to be accepted, the remote system must be running the remote server. Also, the port number specified in the remote command must match the port number given when the server was started on the remote system. Further, if the remote system established a key phrase, then that phrase must also be provided via the -k option, so the remote system can check that it matches. If the port numbers or keywords do not match, or if the remote server is not running on the target system, the command packet is ignored. Even if the command is accepted there is no acknowledgement. The 'kick' subcommand forces a retransmission timeout on all TCP connections that the remote node may have with the local node. If the '-a' option is used, connections to the specified host are kicked instead. No key is required when using the 'kick' subcommand. The 'exit' and 'reset' subcommands are mainly useful for restarting JNOS on a remote unattended system after the configuration file has been updated. The remote system should invoke JNOS automatically upon booting, preferably in an infinite loop. The add or drop subcommands allow a JNOS system with a dynamically- assigned IP address, to register as a gateway with a cooperating system having a known IP address. The duration of the route thus established is controlled by the remote system, typically 15 minutes. Since UDP packets are not guaranteed to be delivered, it might be wise to send remote commands more frequently than the timeout. See the at command, well suited to this purpose. remote -s [<key>] The 'exit' and 'reset' subcommands of 'remote' require a password. The password is set on a given system with the '-s' option, and it is specified in a command to a remote system with the '-k' option. If no password is set with the '-s' option, then the 'exit' and 'reset' subcommands are disabled. remote -g [<gwkey>] The 'add' and 'drop' subcommands of remote may require a password. The password is set on a given system with the '-g' option, and it is specified in a command to a remote system with the '-k' option. Note that 'remote' is an experimental feature in JNOS; it is not yet supported by any other non-KA9Q-derived TCP/IP implementations, although a version of the remote command for BSD Unix exists. rename <oldfilename> <newfilename> Renames <oldfilename> to <newfilename>. This performs the same function as the DOS rename command. repeat [milliseconds] command Starts a new session screen with the output of the command updated every interval in milliseconds. If you hit F10 it ends the session. Example: repeat 1000 tcp status repeats every second 'tcp status' command rewrite <address> Will show the result of the mail rewrite process, that is, how <address> is changed based on the contents of Rewritefile (default location is /spool/rewrite). The result of rewriting determines whether an incoming message is stored in an area (and, which area receives the message), or whether it is stored into /spool/mqueue for handling by SMTP. The rewrite command is useful for testing modifications to Rewritefile. Example: rewrite n8fow@n8fow.ampr.org shows the mail rewriting that will be done for mail addressed to n8fow@n8fow.ampr.org. REWRITE FILE The Rewrite file is used to perform a one-to-one mapping between a message's destination (To:) addresses as received by JNOS, and the destination addresses as actually used by JNOS. Each record within the rewrite file comprises a single line, containing either two or three fields separated by spaces. The first field is the template field; if a destination address matches the template, it is replaced by the second field after variable substitution. The rewrite process terminates after the first template match, with JNOS using the resultant value as the new destination address, unless there is an optional third field which contains the single letter "r". In this case, JNOS rescans the rewrite file from the beginning, attempting to match the new destination address with one of the templates. If no template matches the destination, it is used unchanged as the result. If the address resulting from rewrite contains an "@" it is sent via smtp. Otherwise it should be the name of an area. There is one special case: "refuse" as the destination causes the message to be rejected. A template contains a combination of verbatim ascii text, and special characters "?*+\". To treat a special character as an ordinary character, precede it by '\'. The '?' character matches any single character, '*' matches any number of consecutive characters (including zero), and '+' matches a sequence of one or more characters. In the second field, the character "$", followed by a single digit in the range 1 to 9, represents the string that matched the respective '*' or '+' in the template. For example, tcpip@* tcp *@tcpip tcp rewrites all addresses beginning or ending with "tcpip" to the tcp area. The two-character sequence, $H, in the second field is replaced by the hostname of the system, as set by the hostname command. SAMPLE REWRITE FILE (edit to suit your call and neighbors): # Sample rewrite file for K5ARH pbbs, also known as w5ddl.ampr.org # # Special destinations: refuse => send NO (ax.25) or Bad host (smtp) # (a.k.a. "areas") nts* => mailbox writable by all (i.e., kill cmd works) # Also, ST used in forwarding. # help => never flag as already read, so L shows all # take x%y@me and reprocess as x@y *%*@w5ddl* $1@$2 r *%*@localhost* $1@$2 r # For dual-id'ed BBSes, treat @one as @other: *@k5arh* $1@w5ddl r # # Next, pass real FQDN's unchanged *@*.edu $1@$2.edu *@*.com $1@$2.com *@*.gov $1@$2.gov *@*.org $1@$2.org *@*.net $1@$2.net *@*.mil $1@$2.mil # # Now addresses we discard with impunity (junk, useless stuff from gatewayed systems) #eg, astro@* refuse #eg, *@dist9 refuse dx@ww refuse # # Handle local sysop, and sysop bulls sysop k5arh sysop@w5ddl* k5arh sysop@allla allla sysop@* sysop *@sysop sysop # # Now pass specific bulletins on to our areas # NOTE: It is important that the lines below are kept in that order # (Ie TO sorting FIRST, then AT sorting !!) # Otherwize something like 'amsat@allusa' will end up in the 'allusa' area # instead of the 'amsat' area where I prefer it. tcpip@* tcpip wanted@* wanted want@* wanted need@* wanted wp@* btrbbs sale@* sale 4sale@* sale trade@* sale swap@* sale dx@* dx races@* races fcc@* fcc amsat@* amsat arrl@* arrl ares@* ares nasa@* nasa gulf@* gulf keps@* keps larc@* larc kd5sl@* btrbbs # *@gulf gulf *@nasa nasa *@amsat amsat *@ares* ares *@arrl arrl *@arl arrl *@la allla *@allla allla *@allus* allus *@allbbs* allus *@us* allus *@usa allus *@franca franca *@ww ww laoep@* laoep *@laoep* laoep # # LARC is local Lafayette distribution *@larc larc *@test test # # Anything left @w5ddl is private mail to my users *@w5ddl* $1 w5ddl@* k5arh # # Handle local hosts I forward to: *@n5knx* n5knx *@wu3v* wu3v # Now BBSes we pass north/east/westward *@wb5bke* bkebbs *@kb5ogn* ognbbs *@ka5nmn* ognbbs *@k4ry* k4ry *@ka4pkb* ka4pkb *@w5ksi* norbbs *@kb4gbs* norbbs *@kk4cq* norbbs *@n5ssy* norbbs *@w4iax* norbbs *@n5uxt* norbbs *@wd5ghw* btrbbs *@kd5sl* btrbbs *@ae5v* aexbbs *@ke5l* aexbbs *@wg5w* aexbbs *@kb5bfv* lchbbs *@n2ktq* lchbbs *@wb5txn* lchbbs *@kb5tbb* cnbbbs *@kb5vjy* aexbbs *@wa4imz* cnbbbs *@ka5kth* cnbbbs *@wb5fro* cnbbbs *@f6cnb* cnbbbs *@w0gvt* cnbbbs ka3zyp@* cnbbbs # # Handle frequent mistakes or special cases or some other reason I now forget: 71*@* aexbbs kb5bfv lchbbs kb5bfv@* lchbbs ae5v@* aexbbs kc5gwh@* bkebbs kc5gwh bkebbs n5ssy norbbs ka5nmn@* ognbbs ka5ydj@* norbbs n5ssy@* norbbs wb5vtn@* norbbs n5eqo@* norbbs # <<<others here>>> # NTS local, in-state, outside *@705* ntslocal *@71* aexbbs *@706* lchbbs *@70* btrbbs *@ntstx* cnbbbs *@nts* nts # Now state-specific forwarding (if any) *@*.tx* cnbbbs # # Continents via HF at west f6cnb *@*.eu cnbbbs *@*.oc cnbbbs *@*.noam cnbbbs *@*.na cnbbbs *@*.usa cnbbbs *@*.as cnbbbs *@*.af cnbbbs *@*.sa cnbbbs # # Anything else means we must add more, above *@* check # # Try to handle addressing mistakes by mbox users! */* check *\* check *&* check *.* check rip <subcommand> The commands given here are used for RIP. After this list of commands is the list for RIP-2. The RIP-2 implementation includes compatibility with RIP-1. The sets of commands are separated here to improve clarity. rip accept <gateway> Remove the specified gateway from the RIP filter table, allowing future broadcasts from that gateway to be accepted. rip add <hostid> <seconds> <flags> Add an entry to the RIP broadcast table. The IP routing table will be sent to <hostid> every interval of seconds. If <flags> is specified as 1, then "split horizon" processing will be performed for this destination. That is, any IP routing table entries pointing to the interface that will be used to send this update will be removed from the update. If split horizon processing is not specified, then all routing table entries except those marked "private" will be sent in each update. (Private entries are never sent in RIP packets). If flags is 2, the broadcast will also advertise a route to the system itself. Flags are accumulative, i.e. a value of 3 will mean both "split horizon" and "me too". See also the 'route' command. Triggered updates are always done. That is, any change in the routing table that causes a previously reachable destination to become unreachable will trigger an update that advertises the destination with metric 15, defined to mean "infinity". Note that for RIP packets to be sent properly to a broadcast address, there must exist correct IP routing and ARP table entries that will first steer the broadcast to the correct interface and then place the correct link-level broadcast address in the link-level destination field. If a standard IP broadcast address convention is used (e.g. 44.26.0.0 or 44.26.255.255) then chances are you already have the necessary IP routing table entry (unusual subnet or cluster-addressed networks may require special attention!) However, an 'arp add' command will be required to translate this address to the appropriate link level broadcast address; For example, arp add 44.255.255.255 ax25 qst-0 for an AX25 packet radio channel. (If there are multiple AX25 interfaces, make a unique address for each interface.) rip drop <dest> Remove an entry from the RIP broadcast table. rip kick Immediate command to send a rip update. rip merge [on|OFF] This flag controls an experimental feature for consolidating redundant entries in the IP routing table. When rip merging is enabled, the table is scanned after processing each RIP update. An entry is considered redundant if the target(s) it covers would be routed identically by a less "specific" entry already in the table. That is, the target address(es) specified by the entry in question must also match the target addresses of the less specific entry and the two entries must have the same interface and gateway fields. For example, if the routing table contains Dest Len Interface Gateway Metric P Timer Use 44.2.3.4 32 ax0 44.96.1.2 1 0 0 0 44.2.3.0 24 ax0 44.96.1.2 1 0 0 0 then the first entry would be deleted as redundant since packets sent to 44.2.3.4 will still be routed correctly by the second entry. Note that the relative metrics of the entries are ignored. rip refuse <gateway> Refuse to accept RIP updates from the specified <gateway> by adding the gateway to the RIP filter table. It may be later removed with the 'rip accept' command. rip request <gateway> Send a RIP Request packet to the specified <gateway>, causing it to reply with a RIP Response packet containing its routing table. rip status Display RIP status, including a count of the number of packets sent and received, the number of requests and responses, the number of unknown RIP packet types, and the number of refused RIP updates from hosts in the filter table. A list of the addresses and intervals to which periodic RIP updates are being sent is also shown, along with the contents of the filter table. rip trace [0|1|2] Default is 0. This variable controls the tracing of incoming and outgoing RIP packets. Setting it to 0 disables all RIP tracing. A value of 1 causes changes in the routing table to be displayed, while packets that cause no changes cause no output. Setting the variable to 2 produces maximum output, including tracing of RIP packets that cause no change in the routing table. rip ttl <seconds> Displays or sets the time to live timer to 'seconds'. Normal time-out value is 240 seconds. This is not the ttl in a rip broadcast (16 = infinite). Set this timer before starting rip. Change this timer only in cooperation with your surrounding nodes. Default is 240 seconds. End of RIP-1 commands. ********************************************************************* The following text is provided by N0POY who did the NOS implementation of RIP-2. This document covers the implementation of RIP-2 (RFC 1388) in NOS. Specifically the WG7J version of NOS. RIP-2 is an enhanced version of the RIP protocol (RFC 1058). RIP and RIP-2 are an interior gateway protocol (IGP). RIP-2 for NOS was implemented by Jeff White, N0POY. This documentation is for the beta release V0.9 of RIP-2 RIP-2 Features The NOS implementation implements all features of the normal RIP protocol (RFC 1058) and all features of the RIP-2 protocol (RFC 1388) except multicasting (which NOS does not currently implement) and Route Tags (NOS does not implement any EGPs). Features include: Routing Domains Authentication Proxy routing Filtering of naughty nodes Optional refusal of a default route Enhanced logging and tracing Route subnet masks correctly maintained Optional refusal to accept older RIP version broadcasts Mixing of RIP-1 and RIP-2 support NOS RIP COMMANDS RIP ACCEPT <gateway> The RIP ACCEPT command resumes the acceptance of RIP broadcasts from a specific node given in the <GATEWAY> field. RIP ACCEPT 192.55.248.1 or RIP ACCEPT skeggi.tcman.ampr.org RIP ADD <DEST> <INTERVAL> [<FLAGS>] [<RIPVER>] [AUTH <PASSWORD>] [RD <routing domain>] The RIP ADD command adds a node to the list of stations that are to be broadcast to with the local nodes routing table. <DEST> is the destination node, usually a broadcast address. <INTERVAL> is the number of seconds between broadcasts. <FLAGS> are the RIP flags used (see below for the flags), it is a hexadecimal number. <RIPVER> is the version of the RIP broadcasts. This may be a 1 or 2. The AUTH identifier precedes the authentication password to be included with the RIP broadcasts to this destination. The RD identifier precedes the routing domain number. This number must range from 0 to 65535. The authentication fields and routing domain fields are only valid with RIP-2 broadcasts. The password must be 16 characters or fewer. Printable ASCII characters are recommended, but not required. RIP <FLAGS>: 0x01 Do 'split horizon' processing 0x02 Include ourselves in the routing broadcast 0x04 Broadcast RIP packets (default type) 0x08 Multicast RIP packets (not implemented) (RIP-2) 0x10 Poisoned Reverse on 0x20 Authentication data to be included in broadcast (RIP-2) Recommend flags are Split Horizon, and Poisoned Reverse or 0x11. Authentication and routing domain data entered here only applies to the outgoing RIP broadcasts. See RIP AUTHADD and RIP AUTHDROP for entering acceptable passwords and routing domains. Example: RIP ADD SKEGGI.TCMAN.AMPR.ORG 30 0x31 2 AUTH frodo RD 2 RIP ADD BIGGUS.TCMAN.AMPR.ORG 300 0x11 1 RIP PROXY <SRC> <DEST> <INTERVAL> [<FLAGS>] [AUTH <PASSWORD> [RD <ROUTING DOMAIN>] The RIP PROXY command adds a node to the list of stations that are to be broadcast to with the local nodes routing table. <SRC> is the node that the broadcast will "point" to. <DEST> is the destination node, usually a broadcast address. <INTERVAL> is the number of seconds between broadcasts. <FLAGS> are the RIP flags used (see above for the flags), it is a hexadecimal number. The AUTH identifier precedes the authentication password to be included with the RIP broadcasts to this destination. The RD identifier precedes the routing domain number. This number must range from 0 to 65535. The authentication fields and routing domain fields are only valid with RIP-2 broadcasts. The password must be 16 characters or fewer. Printable ASCII characters are recommended, but not required. Proxy RIP is tricky, complex and not needed for normal use. Do NOT use proxy rip unless you understand what you are doing. Proxy RIP's primary use would be to advertise routes to another machine that is acquiring routing information via another routing protocol. See RFC 1388 for further details. RIP DROP <dest> [<DOMAIN>] RIP DROP removes a routing broadcast entry. If a RIP-2 broadcast was entered, the correct routing domain needs to be entered, since it is possible to broadcast multiple routing domains to the same address. Example: RIP DROP SKEGGI.TCMAN.AMPR.ORG 2 RIP AUTHADD <interface> <routing domain> [<password>] RIP AUTHADD adds an acceptable routing domain and optionally a password to a specific interface. Example: RIP AUTHADD ax0 2 frodo RIP AUTHADD en0 3 RIP AUTHDROP <interface> <routing domain> RIP AUTHDROP removes an acceptable routing domain (and password if any) from a specific interface. Example: RIP AUTHDROP ax0 2 RIP REJECT <version> RIP REJECT is used to ignore older RIP broadcasts, as they may cause undesirable routing table alterations. The version number is the version number and below that are ignored. RIP version 0 (XNS RIP) is always ignored. The default is 0. To ignore RIP-1 broadcasts: RIP REJECT 1 would do the job. RIP FILTER <on|OFF> RIP FILTER ON will cause advertisements to the default route (0.0.0.0) to be tossed and ignored. The default is OFF. This can serve as a LID filter. Default routes should NOT be advertised, unless there is a specific reason (i.e. this machine is a gateway to the rest of the Internet). RIP MERGE <on|OFF> RIP MERGE ON will cause overlapping routing entries to be merged into one routing entry. The default is OFF. For example N0BEL.TCMAN.AMPR.ORG is a route to 192.133.30.0/28, and 192.133.30.16/28, with merging on this would become a single entry of 192.133.30.0/27. RIP REFUSE <gateway> RIP REFUSE will reject all RIP broadcasts from the GATEWAY station. RIP ACCEPT is the opposite. By default all stations are accepted. RIP REQUEST <GATEWAY> RIP REQUEST asks the gateway station to send a routing table now, rather than waiting for periodic updates. RIP STATUS RIP STATUS will display various statistics for RIP-1 and RIP-2, RIP broadcasts, RIP refusals, and acceptable Interface, Domain and Password combinations. It also displays the refusing version level. The DEFAULT interface is for every interface. Thus unless removed, and RIP-2 broadcast with a domain of 0 does not require a password and will be accepted. RIP TRACE <level> [<FILE>] RIP TRACE will begin tracing RIP operations. The higher the level, the more detailed the logging. Level 9 is the useful maximum, with level 0 (the default) being no logging. If a file is specified, logging will go to that file, else logging appears on the console. RIP TTL <time-To-LIVE> RIP TTL sets the time-to-live before RIP entries expire from the routing tables. The default should work for almost all cases. End of RIP-2 Description rlogin <host> Sets up an 'rlogin' session via port 511 to a Unix-compatible host. Default terminal is a vt100-compatible terminal (with keyboard mappings as defined with the 'fkeys' command). rmdir <directory> Remove a sub-directory from the current working directory. The sub-directory must be empty before 'rmdir' can be used. route [<subcommand>] With no arguments, 'route' displays the IP routing table. route add <desthostid>[/bits] | default <iface> [<gatewayhostid> | direct] [<metric>] NOTE: Attempting tcp connections to an address without an existing route fails immediately. This command adds an entry to the routing table. It requires at least two more arguments, the desthostid of the target destination and the name of the interface <iface> to which its packets should be sent. If the destination is not local, the gateway's hostid should also be specified. (If the interface is a point-to-point link, then <gatewayhostid> may be omitted even if the target is non-local because this field is only used to determine the gateway's link level address, if any. If the destination is directly reachable, <gatewayhostid> is also unnecessary since the destination address is used to determine the interface link address). If <rspf> is used and the system is a switch / router to multiple routes, the keyword 'direct' can be used instead of a <gatewayhostid> to set the metric higher than the default of 1. This way routes advertised by other rspf stations can be cheaper and get selected. If 'direct' is given but <metric> not, an new algorithm is used to set the metric dependent on the number of subnet mask bits. The optional /bits suffix to the destination host id specifies how many leading bits in the host id are to be considered significant in the routing comparisons. If not specified, 32 bits (i.e., full significance) is assumed. With this option, a single routing table entry may refer to many hosts all sharing a common bit string prefix in their IP addresses. For example, ARPA Class A, B and C networks would use suffixes of /8, /16 and /24 respectively. E.g. the command route add 44/8 ax0 44.64.0.2 causes any IP addresses beginning with "44" in the first 8 bits to be routed to 44.64.0.2; the remaining 24 bits are "don't- cares". When an IP address to be routed matches more than one entry in the routing table, the entry with largest 'bits' parameter (i.e., the "best" match) is used. This allows individual hosts or blocks of hosts to be exceptions to a more general rule for a larger block of hosts. The special destination 'default' is used to route datagrams to addresses not matched by any other entries in the routing table; it is equivalent to specifying a /bits suffix of /0 to any destination hostid. Care must be taken with 'default' entries since two nodes with default entries pointing at each other will route packets to unknown addresses back and forth in a loop until their time-to-live (TTL) fields expire. (Routing loops for specific addresses can also be created, but this is less likely to occur accidentally). There is one built-in interface: loopback. Loopback is generally for internal purposes, although destinations explicitly routed via this interface result in the packet being dropped, i.e., loopback can be used as a bit-bucket! Here are some examples of the route command: # Route datagrams to IP address 44.0.0.3 to SLIP line #0. # No gateway is needed because SLIP is point-to point. route add 44.0.0.3 sl0 # Route all default traffic to the gateway on the local Ethernet # with IP address 44.0.0.1 route add default ec0 44.0.0.1 # The local Ethernet has an ARPA Class-C address assignment; # route all IP addresses beginning with 192.4.8 to it route add 192.4.8/24 ec0 # The station with IP address 44.0.0.10 is on the local AX.25 channel route add 44.0.0.10 ax0 #An encapsulation link to 192.4.8.12 where the subnet 44.64.0.0 is accessible. The Internet does not know #where we are but we just use them with what they know: route add 44.64.0.0/16 encap 192.4.8.12 4 route addprivate <dest hostid>[/bits] | default <iface> [<gateway hostid> [<metric>]] This command is identical to 'route add' except that it also marks the new entry as private; it will never be included in outgoing RIP updates. It will also not be shown in themailbox 'IProute' command. route drop <dest hostid>[/bits] Delete an entry from the table. If a packet arrives for the deleted address and a default route is in effect, it will be used. route flush Delete (drop) all temporary routes, that is, routes added with an expiration timer (eg, by RIP). route look <hostname> Display just the routing table entry used to reach <hostname>. route sort [off|ON] Display or set the route display sort flag. When set, the route command will sort its report, which tends to display similar routes together. When reset, the report is by decreasing number of significant bits used in comparing host addresses. rspf <subcommand> RSPF is the Radio Shortest Path First protocol. Each station listens for RRH (Router to Router Hello) messages. When such a RRH message is received, it will figure out if the link is bi-directional by pinging the other station. The protocol is described in the RSPF 2.1 specification. rspf interface <interface> <quality> <horizon> <interface> is the required interface rspf should use. quality is from 1 to 127, horizon is between 1 to 255. End nodes should have the quality set to 1. Immediate nodes normally set the quality to 8. The normally used value for horizon is 32. rspf mode [vc | datagram | none] Display the preferred mode for RSPF. Modes are vc (Virtual Circuit) and datagram. none resets the preferred mode. rspf rrhtimer [seconds] Display or set the rrh timer value. rspf suspecttimer [<seconds>] Display or set the suspect timer value. rspf timer [<seconds>] Display or set the update timer value.
(Courtesy KBNorton Computer Services)