107 lines
4.9 KiB
Plaintext
107 lines
4.9 KiB
Plaintext
ibtracer
|
|
1/11/05
|
|
|
|
Description:
|
|
ibtracer is used to build a source route into a UD packet and validate the
|
|
path taken to a destination. It is based on a client/server architecture and
|
|
relies on a special ibtracer IB agent in each node along the way. It can
|
|
deal with switches which do not currently run this agent but validation for
|
|
that part of the path is impossible.
|
|
|
|
Syntax:
|
|
ibtracer [-I mthca0] [-p port] [-r <# retries>] [-t <timeout in msec>] \
|
|
[-l LID] [-g DGID] [-v]
|
|
|
|
Architecture:
|
|
IBA 1.2 defines a new set of vendor specific MADs which include OUI. OpenIB
|
|
will use one of these classes (0x30) to implement ibtracer (and the vendor
|
|
MAD option of ibping).
|
|
|
|
Note that these are general service MADs and rely on the network being up.
|
|
If the network is not up, then DR SMPs must be used. There are a number of
|
|
separate SMP tools for this.
|
|
|
|
The OpenIB vendor specific MAD agent will support the following attributes:
|
|
ClassPortInfo (0x0001) and SourceRoute (0x0010). There may be an additional
|
|
attribute (TBD) to support ibping but this can be done out of the same agent.
|
|
|
|
Only the VendorGet method needs to be supported by this agent. No traps
|
|
are currently defined for this class.
|
|
|
|
Although from the ibtracer client perspective, these vendor MADs are sent
|
|
on outgoing ports, it is the server (agent) which needs to validate the
|
|
incoming port. As a result of this, it is the expected incoming port
|
|
at the next hop which needs to be added to the SourceRoute attribute.
|
|
SourceRoute requests (Gets) and responses (GetResps) are exchanged
|
|
directly between the source node where the ibtracer command is initiated
|
|
and each hop along the way to the destination until the destination is
|
|
reached. As the hops to the destination are walked, the incoming ports are
|
|
added to the SourceRoute attribute and checked when the packet is received
|
|
by that hop that it did arrive on that port. If it did not arrive on that
|
|
port, an error is indicated in the status field (status 7). In either case,
|
|
the port it did arrive on is put in the SourceRoute attribute in the GetResp.
|
|
|
|
One of DLID or DGID must be specified in the ibtracer invocation.
|
|
If DGID is specified, a PathRecord request is made to the SA
|
|
to obtain the DLID. Other than that, no SM or SA is involved with
|
|
ibtracer although the SM is needed to set up the forwarding tables.
|
|
|
|
Once the DLID is obtained from either the command invoication or the SA,
|
|
a DR SMP packet is sent to the next hop to obtain the PortInfo attribute
|
|
to obtain the base LID for the next hop. A VendorGet(ClassPortInfo) is
|
|
then attempted to see if this management class is supported on that node.
|
|
If it is (a VendorGetResp is received), a VendorGet(SourceRoute)
|
|
to the next hop LID is attempted after updating the source route attribute
|
|
with the local port number from the returned PortInfo attribute. Upon
|
|
receipt of the VendorGet(SourceRoute), the receiving agent validates the
|
|
port number it is received on with the port number in the SourceRoute
|
|
attribute. It indicates failure when they do not match and in either case
|
|
the port is was received on is put back into the VendorGetResp(SourceRoute).
|
|
|
|
If the next hop does not support this management class, this is indicated
|
|
(if -v is enabled) and the algorithm proceeds with the next hop. The
|
|
algorithm is terminated when the next hop LID is the DLID (factoring in
|
|
the LMC).
|
|
|
|
Note that rather than doing much of this with DR SMPs directly,
|
|
these could be SA requests (using PortInfoRecords and LinkRecords,
|
|
or TraceRecords). Investigation would need to be done to validate
|
|
whether these SA attributes are supported by the various SMs
|
|
(although OpenSM is most important in terms of OpenIB). TraceRecords
|
|
are optional and are not believed to be currently supported. It can
|
|
be done with just PortInfoRecords and LinkRecords.
|
|
|
|
Since vendor MADs are UD, there is a retransmission strategy (timeout/retry)
|
|
which have defaults but are settable on the command line.
|
|
|
|
-v option displays entire path. Note that the incoming (rather than outgoing)
|
|
ports are displayed. Without -v specified, just success or failure is
|
|
displayed.
|
|
|
|
Reversible paths are used for the responses. Note that the path from A to
|
|
B might not be the same from B to A so ibtracer needs to be initiated at
|
|
both ends if this is of interest.
|
|
|
|
This tool cannot currently be used for multicast tracing. There are a
|
|
couple of reasons for this. Base switch port 0 does not support
|
|
multicast and it is not a requirement of enhanced switch port 0
|
|
to support this so there would be more hop skipping. Also, the attribute
|
|
format would need to be enhanced for this as well as the client needing
|
|
to handle multiple responses to a single request.
|
|
|
|
|
|
SourceRoute attribute format
|
|
|
|
Actual Incoming Port Number (valid on response) - 1 byte
|
|
Current Hop Count - 1 byte
|
|
Vector of Incoming Port Numbers (0-63) - 64 bytes
|
|
|
|
|
|
Outstanding Questions
|
|
|
|
Should SL be supported rather than assume SL 0 ?
|
|
|
|
Should GRH be supported (and tied to GID specification in command invocation) ?
|
|
|
|
Is multicast tracing important ?
|