[dtrace-discuss] DTrace Network Providers, take 2

Mon Jun 11 20:11:25 PDT 2007

G'Day Folks,

I'm restarting work on the proposed DTrace network providers. These are
the stable providers intended for use by Solaris end users for general
observability, similar to what the "io" provider achieves for disk I/O.

I have been busy on other projects during the last 6 months, so little has
progressed since the last (long) dtrace-discuss thread with the subject
"DTrace Network Provider".

I've just reread that thread - and I'm grateful to have had so much useful
feedback so far. I've reintegrated some feedback with what I've learnt
through using the network provider during the past 6 months, and I'm
considering some new changes - which would be take 2 of the prototype
network providers.

For now I'm sticking to just discussing the internet layer protocols.

Summary

Take 1 (current):

        Probes          Args
        ip:::send       ipstateinfo_t, ipinfo_t, ipv4info_t, ipv6info_t
        ip:::receive    ipstateinfo_t, ipinfo_t, ipv4info_t, ipv6info_t

more details: http://www.opensolaris.org/os/community/dtrace/NetworkProvider

This provider has been great to use in testing. A key issue is the
uglyness of having ipv4info_t and ipv6info_t as different args; although
this hasn't been much of a problem as ipinfo_t is usually used instead.

Take 2 (proposed):

        Probes                  Args
        ip:::send               cstateinfo_t, ipinfo_t
        ip:::receive            cstateinfo_t, ipinfo_t
        ipv4:::send             cstateinfo_t, ipinfo_t, ipv4info_t
        ipv4:::receive          cstateinfo_t, ipinfo_t, ipv4info_t
        ipv6:::send             cstateinfo_t, ipinfo_t, ipv6info_t
        ipv6:::receive          cstateinfo_t, ipinfo_t, ipv6info_t
        ipsec:::send            cstateinfo_t, ipinfo_t, ipsecinfo_t
        ipsec:::receive         cstateinfo_t, ipinfo_t, ipsecinfo_t
        icmp:::send             cstateinfo_t, ipinfo_t, icmpinfo_t
        icmp:::receive          cstateinfo_t, ipinfo_t, icmpinfo_t
        arp:::send              cstateinfo_t, arpinfo_t
        arp:::receive           cstateinfo_t, arpinfo_t
        rarp:::send             cstateinfo_t, arpinfo_t
        rarp:::receive          cstateinfo_t, arpinfo_t
        ...

Providers such as "ipv4" and "ipv6" are for specific protocol analysis,
and their 3rd argument is an endian correct structure of the protocol
members (DTrace translator). A pointer to the raw protocol struct will
be provided. (this assumes that "ipv4" is an allowed provider name, as
it could potentially clash with a USDT provider called "ipv" that is
asked to trace PID 4).

Some discussion points about the new suggestions follow.

1) ipinfo_t

This provides common details from the IP protocols that we expect to
have available,

        ipinfo_t,
                ip_protocol     int             /* protocol */
                ip_plength      uint            /* payload length */
                ip_saddr        string          /* source address */
                ip_daddr        string          /* destination address */

ip_protocol could be just the IP protocol number (4 or 6), or borrow existing
definitions such as AF_INET/AF_INET6, ETHERTYPE_IP/ETHERTYPE_IPV6 or use
/etc/protocols - as these may better accomodate future protocol additions.
Using the IP protocol number (4/6) would be the least suprising choice for
the end user.

2) cstateinfo_t

This provides connection state information if available,

        cstateinfo_t,
                cs_cid          uint64_t        /* connection ID (conn_t *) */
                cs_loopback     int             /* loopback state */

and may be extended to include details such as,

                cs_zoneid       int             /* zone ID */
                cs_ip_stack     uint64_t        /* stack ID (ip_stack_t *) */

cs_cid isn't provided as a conn_t *, as that would expose an unstable
interface; instead it is provided as a uint64_t, as it can be useful as a
connection ID (and people can cast it as a conn_t * for raw debugging).

3) ip provider

"ip" is the internet protocol provider, which is a convience provider for
tracing all internet protocol traffic (anything with an IP header).
It may be expanded in the future to cover future internet layer data
protocols (protocols that serve the same purpose as IPv4/IPv6).

4) ip provider & ipsec

Since "ip" is a convience provider, we have the possibility of casting
data that is useful (for convience) rather than what is strictly in the
protocol. For example, IPSec, where packets have the tunnel source and dest
and the actual source and dest, could be traced as follows:

        Probes          Arguments contain
        ipv4:::         tunnel source and dest
        ipv6:::         tunnel source and dest
        ipsec:::        actual source and dest, and tunnel source and dest
        ip:::           actual source and dest

(assuming this is doable - I need to check if ip::: probes can be placed
so to not see duplicates of IPSec traffic).

This would allow the ipv4 provider to probe the IPv4 protocol, and the ip
provider to probe the actual end points of our communication.

5) ICMP

To stress the intent of these providers, an IPv4 ICMP send would fire,

        ip:::send       Generic info
        ipv4:::send     IPv4 packet info
        icmp:::send     ICMP details (type, code, ...)

perhaps snoop -V helps explain this,

192.168.1.109 -> 192.168.1.3  ETHER Type=0800 (IP), size=98 bytes
192.168.1.109 -> 192.168.1.3  IP  D=192.168.1.3 S=192.168.1.109 LEN=84, ID=3232, TOS=0x0, TTL=255
192.168.1.109 -> 192.168.1.3  ICMP Echo request (ID: 20076 Sequence number: 0)

The ip and ipv4 providers will trace the "IP" line, and the icmp provider
will trace the "ICMP" line.

6) Nifty-IP (hypothetical)

In the distant future, Aliens from the Pleiades cluster make contact with
Earth. They have been searching the galaxy for a quality operating system
that they can install on their interstellar battleships, and are delighted
to have found this thing that Earth people call "Solaris". However, they
need to communicate with their own internet layer protocol, which roughly
translated into English is called "nifty-IP". Work begins to support
nifty-IP in Solaris 16, partly as a good jesture for our alien neighbours,
and partly because they aggreed to pay in tons of solid gold.

The following providers would trace nifty-IP,

        ip:::           Generic info
        nifty-ip:::     nifty-ip packet info (niftyipinfo_t)

An integration difficulty with ip::: is that of matching fields in ipinfo_t.
That should work as follows,

        ip_protocol     no problem - nifty-ip gets its own protocol number
        ip_plength      no problem - nifty-ip must move some length of data
        ip_saddr        no problem - although may be unintelligible
        ip_daddr        no problem - although may be unintelligible

The assumptions are that any future internet layer protocol will move
data from address A to address B, and that data will have a measurable
length.

The cstateinfo_t members shouldn't be a problem, as they are specific to
Solaris and not the protocol.

cheers,

Brendan

-- 
Brendan
[CA, USA]