.\" .\" rsvptrace man page .\" Subramaniam Vincent .\" 29 May 1997. .\" .TH RSVPTRACE 8 "23 Jun 1997" "USC/ISI" .SH NAME rsvptrace \- Resource Reservations diagnostic utility .SH SYNOPSIS .na .B rsvptrace [ .B \-h .I hops ] [ .B \-H ] [ .B \-L .I Last-hop ] [ .B \-m .I path-mtu ] [ .B \-s .I timeout ] [ .B \-U|T ] [ .B \-p .I proto# ] .B .I session .B .I sender .br .ad .SH DESCRIPTION .LP \fIRsvptrace\fP is an RSVP reservation diagnostic tool. It collects a trace of reservation state information for a given session, along the reverse path from a given last-hop node towards a given sender. Each RSVP hop along the reverse path adds its response to the request, and forwards the request to the appropriate previous hop. Upon receiving replies, \fIrsvptrace\fP prints out the responses, with any errors found. .SH OPTIONS .TP .B \-h Specifies the maximum number of rsvp hops that this diagnostic trace can span, after which a reply will be returned, and diagnosis terminated. The default is 10 hops. .TP .B \-H Specifies that the reply is not sent back directly to the requester, but hop-by-hop (HBH) to the Last-hop. The Last-hop node then sends the replies to the requester. The default is to send the reply directly to the requester. This option is useful when the path being diagnosed traverses a firewall. .TP .B \-m Specifies maximum MTU of the diagnostic packet, in bytes. The default MTU is 1400. .TP .B \-s Specifies the retransmit timeout period in seconds for the first diagnostic request. .TP .B \-L Specifies the Last-hop node, as a host name or IP address. Diagnostics commence from this rsvp hop. If this parameter is omitted, the current node is used as the Last-hop. .TP .B \-U|T Specifies the Session IP protocol to be UDP or TCP, rspectively. The default is UDP. .TP .B \-p Specifies the Session IP protocol using the numeric IP protocol ID. If multiple U/T/p options are given on the command line, the last option will override the others. .TP .B \-n Disolays only numeric/dotted-decimal IP addresses, avoiding all reverse name lookups on IP addresses. .TP .B session Specifies the RSVP session to be traced, in the format \fIaddr/port\fP. This is a required parameter. .TP .B sender addr/port Specifies the RSVP sender towards which diagnostic trace will be done, in the format \fIaddr/port\fP. This is a required parameter. .SH How it works .LP A trace starts when a trace request is sent to the Last-hop node, (if the -L parameter is specified) or to the current node. The Last-hop node must implement RSVP. Each node will forward the trace request to the previous RSVP hop corresponding to that session and sender. Before forwarding, each node will add its local reservation state pertaining to that sessio to the trace. When the sender is reached or the maximum scope of the diagnostic is attained, a reply is sent back to the requester. .LP The completed trace request will normally be unicast directly back to the requesting node, as a trace reply. However, the -H parameter will force a hop-by-hop (HBH) reply mode: the reply is sent hop-by-hop from the replying node back to the Last hop node, and thence to the requesting node. In this case, the route for the reply is created as the diagnostic request travels towards the sender, with each RSVP node adding an entry to a ROUTE object in request message. The HBH reply mode is intended for tracing through a firewall. An error encountered during the trace may terminate the trace early and force a reply. For example, there may be no PATH state for that sender on a node. Another more complicated situation occurs when the request packet grows too large for the MTU towards the previous hop. The diagnostic packet is then fragmented at a response boundary and one reply is sent back. A trimmed request is then forwarded upstream. .LP If a request does not receive a reply, \fIrsvptrace\fP times out and resends upto three times. The timeout increases exponentially each time. The default timeout value for the first request is 10 seconds. .LP \fIRsvptrace\fP collects the replies and prints out the responses out in order. .LP For further details, please read the reference Internet Draft. .SH SAMPLE OUTPUT .LP We present a sample output of a trace below. The session is 224.10.10.10/25000. The sender is 10.0.0.1/8888. There is an FF style reservation in place for the sender in this session. .LP % rsvptrace 224.10.10.10/25000 10.0.0.1/8888 .LP Rsvptrace from 40.0.0.1 to 10.0.0.1/8888 for session 224.10.10.10/25000 .br Querying reverse path... .br Timeout in 10 seconds... .br Reply from 10.0.0.1, 4 hop(s), 4 response(s) 1) 40.0.0.1 [arr time: 14:12:59.478] .br [IN->30.0.0.2, OI<-40.0.0.1, Phop->30.0.0.1, timer: 30, DTTL: 0] .br [Gen T=[100K(40K) InfB/s 0 65.5K]] .LP 2) 30.0.0.1 [arr time: 14:18:55.866] .br [IN->20.0.0.2, OI<-30.0.0.1, Phop->20.0.0.1, timer: 30, DTTL: 64] .br [Gen T=[100K(40K) InfB/s 0 65.5K]] [CL T=[20K(5K) InfB/s 0 65.5K] ] FF .br {10.0.0.1:8888} .LP 3) 20.0.0.1 [arr time: 14:18:55.989] .br [IN->10.0.0.2, OI<-20.0.0.1, Phop->10.0.0.1, timer: 30, DTTL: 64] .br [Gen T=[100K(40K) InfB/s 0 65.5K]] [CL T=[20K(5K) InfB/s 0 65.5K] ] FF .br {10.0.0.1:8888} .LP 4) 10.0.0.1 [arr time: 14:18:56.027] .br [IN->local, OI<-10.0.0.1, Phop->N/A, timer: 30, DTTL: 64] .br [Gen T=[100K(40K) InfB/s 0 65.5K]] [CL T=[20K(5K) InfB/s 0 65.5K] ] FF .br {10.0.0.1:8888} .LP The responses are numbered starting at the last hop and ending at the node that sent the reply. (in this case the sender itself). Here is a brief explanation of the output. .LP 1) 40.0.0.1 [arr time: 14:12:59.478] .br The first line indicates the specific node at which this response was recorded and the arrival time of the request. .LP [IN->30.0.0.2, OI<-40.0.0.1, Phop->30.0.0.1, timer: 30, DTTL: 0] .br The second line lists the incoming interface for that \fIsender\fP on the specific \fIsession\fP, the outgoing interface being traced, and the previous hop. It also gives the value for the refresh timeout being used at that RSVP node. The DTTL value is the number of non-RSVP routing hops between the downstream RSVP router and the RSVP router that added this response. .LP [Gen T=[60(80) InfB/s 30 80]], [CL T=[1(2) InfB/s 3 4] ] FF .br The third line lists the Effective Tspec, the flowspec, and the style of the reservation in place, if any, on the outgoing interface. If the reservation is a merged reservation this will be indicated with the M symbol. If there is no reservation, only the Tspec of the sender will be listed. .LP {10.0.0.1:8888} .br The fourth line lists all the senders sharing this reservation. If the reservation is shared, multiple senders may be listed on successive lines. .SH SEE ALSO rtap(8), rstat(8), rsvpeep(8), rsvpd(8) .SH References L. Zhang and A. Terzis, "RSVP Diagnostic Messages", Internet Draft - draft-ietf-rsvp-diagnostic-msgs-03.txt, April 1997. .SH Implementation differences with the specification .LP This release does not strictly implement the internet draft specification for RSVP diagnostic messages. The response address (where the reply is sent to) in the specification is an IP address, identifying the target system. The response address in this implementation includes the ephemeral UDP port of the trace program. The final hop RSVP router (from where the reply is sent) will send the UDP diagnostic reply to the waiting trace program. The advantages are that muliple traces can be simultaneously run from the same system and this is independent of whether Rsvpd is running on the system or not. .SH BUGS