The ip provider provides probes for tracing both IPv4 and IPv6 protocols.
This provider became available in Solaris Nevada build 93; It is not available in Solaris 10.
The ip probes are described in the table below.
|send||Probe that fires whenever the kernel network stack sends an ip packet.|
|receive||Probe that fires whenever the kernel network stack receives an ip packet.|
These probes trace packets on physical interfaces and also packets on loopback interfaces that are processed by ip. An IP packet must have a full IP header to be visible by these probes.
Note: loopback tcp packets on Solaris may be processed by tcp fusion, a performance feature that by-passes the ip layer. These fused packets will not be visible using the ip:::send and ip:::receive probes. They are typically all loopback tcp packets after the tcp handshake.
The argument types for the ip probes are listed in the table below. The arguments are described in the following section.
|send||pktinfo_t *||csinfo_t *||ipinfo_t *||ifinfo_t *||ipv4info_t *||ipv6info_t *|
|receive||pktinfo_t *||csinfo_t *||ipinfo_t *||ifinfo_t *||ipv4info_t *||ipv6info_t *|
The pktinfo_t structure is where packet ID info can be made available for deeper analysis if packet IDs become supported by the kernel in the future.
The pkt_addr member is currently always NULL.
The csinfo_t structure is where connection state info can be made available if connection IDs become supported by the kernel in the future.
The cs_addr member is currently always NULL.
The ipinfo_t structure contains common IP info for both IPv4 and IPv6.
|ip_ver||IP version number. Currently either 4 or 6.|
|ip_plength||Payload length in bytes. This is the length of the packet at the time of tracing, excluding the IP header.|
|ip_saddr||Source IP address, as a string. For IPv4 this is a dotted decimal quad, IPv6 follows RFC-1884 convention 2 with lower case hexadecimal digits.|
|ip_daddr||Destination IP address, as a string. For IPv4 this is a dotted decimal quad, IPv6 follows RFC-1884 convention 2 with lower case hexadecimal digits.|
The ifinfo_t structure contains network interface info.
|if_name||Interface name as a string. For example, "eri0", "lo0", "ip.tun0", "<unknown>".|
|if_local||Is-local status. 1: is a local interface, 0: is not a local interface, -1: is unknown.|
|if_ipstack||ipstack ID, for associating ip stack instances, or NULL.|
|if_addr||Pointer to raw kernel structure for advanced debugging only.|
The ifinfo_t details are provided for debugging convenience in the ip layer, if that information is available. There may be some types of traffic where some or all of that information is not available during the ip layer, for which the members may be: "<null>", -1, NULL, NULL.
The ipv4info_t structure is a DTrace translated version of the IPv4 header.
|ipv4_ver||IP version (4).|
|ipv4_ihl||IPv4 header length, in bytes.|
|ipv4_tos||Contents of IPv4 type of service field.|
|ipv4_length||IPv4 packet length (header + payload) at time of tracing, in bytes.|
|ipv4_ident||IPv4 identification field.|
|ipv4_flags||IPv4 flags. See the ipv4_flags table below for bitwise values.|
|ipv4_offset||IPv4 fragment offset, in bytes.|
|ipv4_ttl||IPv4 time to live.|
|ipv4_protocol||IPv4 encapsulated protocol number. See /usr/include/netinet/in.h for the protocol list (IPPROTO_*).|
|ipv4_protostr||IPv4 encapsulated protocol, as a string. Eg, "TCP".|
|ipv4_checksum||IPv4 header checksum, if available at time of tracing.|
|ipv4_src||IPv4 source address, as an ipaddr_t.|
|ipv4_dst||IPv4 destination address, as an ipaddr_t.|
|ipv4_saddr||IPv4 source address, as a dotted decimal quad string.|
|ipv4_daddr||IPv4 destination address, as a dotted decimal quad string.|
|ipv4_hdr||Pointer to raw IPv4 header at the time of tracing.|
See RFC-791 for a detailed explanation for these IPv4 header fields. If the packet is IPv6, these members are either "<null>", 0, or NULL depending on type.
The ipv6info_t structure is a DTrace translated version of the IPv6 header.
|ipv6_ver||IP version (6).|
|ipv6_tclass||IPv6 traffic class.|
|ipv6_flow||IPv6 flow label.|
|ipv6_plen||IPv6 payload length at time of tracing, in bytes.|
|ipv6_nexthdr||IPv6 next header protocol number. See /usr/include/netinet/in.h for the protocol list (IPPROTO_*).|
|ipv6_nextstr||IPv6 next header protocol, as a string. Eg, "TCP".|
|ipv6_hlim||IPv6 hop limit.|
|ipv6_src||IPv6 source address, as an in6_addr_t.|
|ipv6_dst||IPv6 destination address, as an in6_addr_t.|
|ipv6_saddr||IPv6 source address, as an RFC-1884 convention 2 string with lower case hexadecimal digits.|
|ipv6_daddr||IPv6 destination address, as an RFC-1884 convention 2 string with lower case hexadecimal digits.|
|ipv6_hdr||Pointer to raw IPv6 header at the time of tracing.|
See RFC-2460 for a detailed explanation for these IPv6 header fields. If the packet is IPv4, these members are either "<null>", 0, or NULL depending on type.
Some simple examples of ip provider usage follow.
This DTrace one-liner counts received packets by host address:
The output above shows that 28 IP packets were recieved from 192.168.1.109, 14 IP packets from 127.0.0.1, and so on.
This DTrace one-liner prints distribution plots of sent payload size by destination:
The following DTrace script traces IP packets and prints various details:
This example output shows tracing packets as they pass in and out of tunnels:
The fields printed are:
|CPU||CPU id that event occurred on|
|DELTA(us)||elapsed time since previous event|
|SOURCE||source IP address|
|DEST||destination IP address|
Note: The output may be shuffled slightly on multi-CPU servers due to DTrace per-CPU buffering; keep an eye on changes in the CPU column, or add a timestamp column and post sort.
This DTrace script provides a neat summary for both send and receive IP traffic, including the next level protocol:
This script was run on a system with both IPv4 and IPv6 interfaces for several seconds:
The fields printed are:
|SADDR||source IP address|
|DADDR||destination IP address|
|PROTO||IP next level protocol|
|COUNT||number of packets|
The example output above provides a quick summary of network activity with host address details; we can see that both 192.168.1.109 and 192.168.1.108 are swapping many packets via TCP.
The ip provider uses DTrace's stability mechanism to describe its stabilities, as shown in the following table. For more information about the stability mechanism, see Chapter 39, Stability.
|Element||Name stability||Data stability||Dependency class|