Network Products
Digital Trace Facility - DTF
Release Notes
Version 3.1

Abstract

DTF is a utility which traces packets as they traverse through the protocol layers within a router. DTF is a superset of Digital's CTF (Common Trace Facility), supporting multiple platforms and TCP/IP networks. This document contains the release notes, for a complete description and usage information the user is referred to the DTF User Guide a version of which is also contained within the DTF kit.

Contents

    April 1997

    The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document.

    The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license.

    No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies.

    Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.

    Digital Equipment Corporation 1995,1996.

    All Rights Reserved.

    The following are trademarks of Digital Equipment Corporation: DBMS, DECdfs, DECdns, DECnet, Digital, OpenVMS, PATHWORKS, Rdb/VMS ULTRIX, VAX, VAX-11 RSX, VAX DOCUMENT, VMS, VMScluster, VMS POSIX, and the DIGITAL logo.

Version 3.1
  1. clearVISN WinDTF V2.0 - Windows NT/95 kit

    2. DTF for Microsoft Window NT/95 has been redesigned with a new User Interface. The new features include :-

    • Split decode. A Brief decode window that shows all recieved trace packets. This window allows a one-shot decode for all displayed entries as a full verbose decode in the main display.
    • Color decoding. WinDTF now supports color decoding in the main display.
    • Configuration saving. WinDTF now allows the user to save previously created trace configurations and reload them at a later date.
    • Raw decoding support extended, to include all the packet types known to DTF.
    • Search facility, now supports all the DTF search options, including the "quit after X matches", and display non-matches option.
    • Wait after X packets option is now supported under WinDTF.
    • Printing support. The ability to print, and print preview the decoded output in the main display has been added. Plus the main display text can be cut and paste as Rich Text Format data to a compatible editor.
  2. Foreign Decode File format support.

    3. DTF now supports the following foreign file formats to read trace data from.

    • ASCII (representing hex data)
    • HP495x
    • IRIS
    • UNIX CTF, VMS CTF,
    • W&G
    • XRAY
     
  3. Additional X25 decode support.
  4. Additional IPv6 decode.

    5. DTF can now decode IPv6 routes in I-ISIS packets.

  5. ISDN tracepoint support.

    6. The ISDN tracepoints are now supported for DRS routers.

  6. Trace packet caching.

    7. The -Q, cache last 'number' trace packets, option has been added. A number specified after -Q determines the maximum number of tracepackets that will be written to the binary trace data file.

  7. Quit after X matches.

    8. The -q, stop search after 'number' of matches, is used in conjunction with the search facility and will stop the trace with the -q switch has been satisfied.

  8. Show non-matches suring a search.

    9. The -S, show non-matches is search,  has been added to allow the viewing of packets that do not match the search criteria. When color decoding is switch off, the phrase, "search MATCH on the next packet-----v" is display before the matching trace packet.
     

Version 3.0
  1. clearVISN WinDTF V1.1 - Windows NT/95 kit

    2. DTF for Microsoft Window NT/95 is will be shipped as a separate kit from the clearVISN DECNIS Configurator.

    • This kit will be available from September running DTF V3.0 code.
    • This release of the window software contains support for VNSwitch tracepoints.
  2. No support for Ultrix kit

    3. Support for the dtfultrix.tar kit has been removed from this release.

  3. Alpha LINUX kit introduced

    4. Introduced to complement the Intel LINUX kit.

  4. DTF Definition Language (DDL)

    5. Allows the DTF user to write new decode routines to add extra features to DTF if necessary. Currently the decode DDL routines are compiled with a separate executable provided with DTF and the resulting output file which must be called DTF.DDS can then be used by DTF to decode tracepoint data where necessary.

    Some of the existing decode routines that were hard-coded inside DTF and have been migrated to DDL language modules. These modules are provided for the user to append further decode features to taylor DTF to their needs.

    To take advantage of the DDL extention to DTF, the user must make sure that the DTF.DDS file is included in the same directory as the DTF_EVENTS.DAT file.

    Documentation for programming DDL decode routines will be available later in the year.

  5. IPv6 Support

    6. The decoding of IPv6 information is now supported. For Digital Unix users, DTF is able to connect to DRS and VNSwitch routers via IPv6 to access tracepoints.

    For example :-

    dtf 5F15:ABCD:1234:5678:9ABC:01FF:FE67:89AB:"ethernet interface *"

    dtf ::16.36.42.75:"ethernet interface *"

  6. IGMP V1 and V2 Support

    7. Full support for IGMP V2 and V1 in d_igmp.ddl

  7. DVMRP V3 Support

    8. Full support for DVMRP V3 in d_dvmrp.ddl. This should be backwards compatible with older DVMRP versions.

  8. Bug Fix - Fixed a bug in the ip_chksm() routine

    9. This didn't ensure that the trailing byte in an odd lengthed packet was zero before performing the checksum calculation. The result was that occasionally odd lengthed packets would be flagged as having a bad checksum.

Version 2.5
  1. No support for Windows NT/95 kit

    2. Support for the dtfw32.zip kit is removed from this release. This kit was the original console based WindowsNT/95 console application. This has been superceeded by the GUI version of DTF which is shipping with the DECNIS Configurator V1.1 kit. In a future release the GUI version will be supplied as a separate DTF kit, until then the full DECNIS Configurator kit must be installed in order to use DTF on WindowsNT/95.

  2. VNSwitch900 support

    3. This release supports the VNSwitch900 V2 router. The tracepoints for the VNSwitch are described in the new dtf_events.002 file (the VNSwitch reports a router-id of 2).

    DTF on the VNSwitch900 Family

    The VNSwitch900 Router family performs all packet forwarding and bridging in its Fast-Path processor (FP), with only terminating and multicast sent to the Application processor (AP) for processing. There are no DTF tracepoints in the FP which means that forwarded and bridged packets will not be traced. This is not a serious problem since in general Router and Bridge control packets (and indeed all protocol control packets) are either terminating or are multicast and so would be processed by the AP and hence are traceable. In fact by removing the forwarded packets from the traced data we are able to catch that many more control packets on any one tracepoint. 
    VNS Supported Tracepoints.
    Tracepoint Filters Description
    ethernet interface name tx, rx, aarptx, aarprx, apltx, aplrx, arptx, arprx, dntx, dnrx, iptx, iprx, ipxtx, ipxrx, ipv6tx, ipv6rx, moptx, moprx, ositx, osirx, xnstx, xnsrx Traces all packets received by the AP on the Ethernet interface and all packets transmitted over that interface that originated from the router.
    fddi interface name tx, rx, arptx, aarprx, apltx, aplrx, arptx, arprx, dntx, dnrx, iptx, iprx, ipxtx, ipxrx, ipv6tx, ipv6rx, moptx, moprx, ositx, osirx, xnstx, xnsrx Traces all packets received by the AP on the FDDI interface and all packets transmitted over that interface that originated from the router.
    virtual interface name tx, rx, aarptx, aarprx, apltx, aplrx, arptx, arprx, dntx, dnrx, iptx, iprx, ipxtx, ipxrx, ipv6tx, ipv6rx, moptx, moprx, ositx, osirx, xnstx, xnsrx Traces all packets received by the AP on the VLAN interface and all packets transmitted over that interface that originated from the router.
    igmp interface name tx, rx Traces all IGMP packets transmitted and received by the IGMP module on the AP over the specified interface.
    ip interface name tx, rx, icmptx, icmprx, ospftx, ospfrx, tcptx, tcprx, udptx, udprx, Traces all packets transmitted and received by the IP module on the AP over the specified interface. All IP packets received on the AP are traced by this tracepoint, however not all IP packets transmitted by the AP pass through this tracepoint. In particular most IP packets originated by the routing control protocols such as RIP and OSPF are sent directly to the data-link drivers and by-pass this tracepoint. Packets originated by the UDP (other than RIP) and TCP based protocols do pass through this tracepoint.
    ospf interface name tx, rx Traces all packets transmitted and received by the OSPF module on the AP over the specified interface.
    event subsystem subsystem-list info,trace,error,always Traces all the ELS messages. The instance name is actually a list of ELS subsystems whose messages are to be traced. By default all message types are traced, the filters can be used to restrict the trace to messages of a particualr type.
      
Version 2.4
  1. New -Z switch (extension to /DATA on VMS)

    2. This switch takes a string which determines how undecoded data should be output. This switch replaces the old -z switch. The parameter is either a single character [a (to display the output as ASCII, equivalent to -z), h (HEX) or 0 (suppressed)] or a type name (as in the -T (/TYPE) switch) to apply as a second decode. This allows, for example, NSP sessions carrying CMIP data to be decoded.

  2. New -W switch (/WIDTH= on VMS)

    3. This switch specifies the number of columns available on the output device. The default is 132. This switch only has an effect in brief mode, where it determines how many characters are output on a line before the output is truncated. By specifiying a value of 0 truncation is suppressed. This is useful when piping the raw output from DTF into some other utility, for instance the UNIX command line below can be used to send a stream of hex bytes with each packet terminated by a newline.

      # dtf -lH -W0 16.36.16.100:"ethernet interface Eth/0" > myapp
  1. Bug Fix: Crash while decoding long frames in Brief mode.

    2. For very long decode frames (typically those from BOOTP) DTF would occasionally crash due to corruption of some of its data structures. This is fixed in this release.

  2. Bug Fix: Crash while displaying ASCII decoded data containing % characters.

    3. For output displaying ASCII decoded data which contained the % character DTF would crash.This is fixed in this release.

  3. Bug Fix: Crash decode CTF DAT files.

    4. DTF would crash if it encountered a TRACE_REC_LOST record in a CTF DAT file. This is fixed in this release.

Version 2.3

  1. Kit Format Change for VMS

    2. The format of the VMS and Alpha VMS kits has changed in this release. These kits are now distributed as self-extracting executables. When these images are executed they produce a VMS saveset which can be used by VMSINSTAL to install DTF. The procedure is as follows...

      $ copy dtfaxp023.exe sys$update:

      $ set default sys$update

      $ run dtfaxp023

      $ @vmsinstal dtfaxp sys$update:

  2. Customizable Brief Headers.

    3. The format and contents of the DTF headers output in brief mode can now be customized by specifying the positions and sizes of the various fields in the new DTF_BRIEF_FORMAT environment variable. The format of this variable is ... 

    "field1[=width]|field2[=width]|..."
    Each field specifier has an optional width and is separated from other field specifiers by a | character. The field specifiers are shown in the table below, note that specifiers cannot be abbreviated in the environment variable.
    SEQUENCE Trace data sequence number
    TIME Time of received data
    NUMBER Tracepoint number
    NAME Tracepoint instance name
    EVENT Event name
    SIZE Packet size
    For instance, the default brief header format can be achieved using the DTF_BRIEF_FORMAT string below, note that a negative field width indicates that the contents of the field should be aligned to the left. 
    "time|number|event=-8|name=-8"
  3. DECSwitch 900EF Virtual Interface Tracepoint

    4. Support for tracing Virtual Interfaces (i.e. routing interfaces associated with VLANs) on the DECSwitch 900EF is included in this release. VLANs are supported in Version 2.0 of the DECSwitch Routing code. A VLAN may comprise both FDDI and Ethernet ports.

    All routed packets sent and received on a Virtual Interface can be traced using the "virtual interface VIRT/*" tracepoint. Transmitted packets are always formatted as Ethernet packets even if an FDDI interface is part of the VLAN. Received packets are formatted as either FDDI or Ethernet depending on the type of interface on which they were received.

    The physical ports (Ethernet and FDDI) can still be traced using the "ethernet interface eth/*" and "fddi interface fdd/*" tracepoints respectively, however if the port is part of a VLAN no transmit routed packets will be traced (since they are sent over the Virtual Interface). You can still trace the received routed packets on physical ports even if the port is part of a VLAN.

  4. Token Ring Decode

    5. Basic Token Ring header decode is provided. The decode will output the source and destination MAC address fields and the Access and Frame Control fields. Only simple non-MAC frames are currently decoded, the RIF field is not decoded.

    There are currently no token ring tracepoints in the Routers so the decode is limited to pipe mode.

  5. 3-Way ISIS Handshake Option.

    6. Decode has been added for the ISIS Routing protocol 3-way handshake option.

Version 2.2

  1. VMSINSTAL support.

    2. The VMS and AXP kits can now be installed from VMSINSTAL.COM. Simply run VMSINSTAL and specify the kit as DTF. Note that the names of the VMS and AXP savesets have changed accordingly. If you want to install DTF privately (as apposed to system wide) you'll have to unpack the saveset by hand.

  2. DTF_LOCAL_NAMES.DAT file.

    3. The value to name translation tables have been removed from the DTF image and placed in a new data file (DTF_NAMES.DAT). So that users can add local mappings to the tables if necessary DTF will also look for a read a DTF_LOCAL_NAMES.DAT file, users can add extra (or replacement defintiions) to this file using the same format as the DTF_NAMES.DAT file. The Names file includes UDP and TCP port mappings, Ethernet MAC address and OUI mappings and various others. The names files are read once when DTF starts up.

  3. Triggered RIP Decode.

    4. This release contains decode support for the Triggered RIP protocol messages.

  4. Multicast Traceroute Decode.

    5. This release contains decode support for the Multicast Traceroute IGMP messages. The decode supports the draft-ietf-idmr-traceroute-ipm-00.txt IETF draft.

  5. Improved Brief Mode.

    6. The information displayed in brief mode has been reduced in this release, so that there is less duplication and the lines are shorter.

  6. Unix Man Page.

    7. With this release a unix man page (dtf.8) is included in the Ultrix, Digitial Unix and Linux kits. This file should be copied into the man8 directory in the standard man directories.

  7. Changed Statistics Report.

    8. The statistics reported at the end of a session has been changed. The timing for the packets per second counter is now taken from the timestamps reported by the Router rather than the elapsed time on the local host. This provides more accurate packet per second information. Note that the packets per second rate is calculated from the subset of the packets received which are displayed, i.e. it is the rate for the packets which match the filter list and search strings.

  8. Multiple Tracepoints Bug.

    9. When using multiple tracepoints over a TCP connection, not all the tracepoints would be activated. This is because the routers would only process the first TRACE_ON message in the buffer they received from their TCP module (even if there was more than one message contained in the buffer). The fix is to delay 1 second after sending a TRACE_ON message before sending the next, this should be enough time for the message to be delivered to the DTF module within the router. DECnet connections do not have this problem.

Version 2.1

  1. Multiple Tracepoints.

    2. The command line interface has been extended to allow upto 4 tracepoints to be specified for the session. The tracepoint names are separated by commas, the same change has been made to the filters and protocol switches, i.e. the filters and protocol for each tracepoint is separated by commas. This means that individual filters in a filter list for one particular tracepoint must now be separated either with spaces ro with semi-colons.

  2. Blocking Filters.

    3. Blocking filters can on be specified in the filters list be prepending a !; character to the filter name. The * filter name is also introduced to mean all filters.

  3. Protocol Switch.

    4. The protocol switch allows the user to specifiy which protocol header to display, only packets that contain that protocol header are displayed and only the specified protocol header is shown.

  4. IPV6 Decode.

    5. Partial support for IPV6 packets is included.

Version 2.0

  1. DEC RouteAbout family supported.

    2. Access is via TCP only, a new events file (DTF_EVENTS.001) defines the filters available. Note that the tracepoints for this router are different from those for the DECNIS/WR90.

  2. Protocol switch.

    3. This new switch is used to limit the protocol headers which are displayed to the one belonging specified protocol.

Version 1.1

  1. DTF_EVENTS.DAT File.

    2. The events file has been split into a common file which maps a router identifiers to names and a set of router specific files. This allows router specific filters to be supported.

  2. Highlighting.

    3. The various portions of the output are now highlighted in the output display. Highlighting can be disabled using the -D switch. Highlighting is automatically disabled if the output is being sent to an output file (i.e. the -o switch is used).

  3. Coloring.

    4. The various portions of the output are now colored in the output display. Coloring can be disabled using the -C switch. Coloring is automatically disabled if the output is being sent to an output file (i.e. the -o switch is used).

  4. Relative Timing.

    5. The new switch -R allows time to be display relative to the previous packet rather than as an absolute value.

  5. More packet decode.