netstat -p プロトコル

netstat -p プロトコルは、プロトコル変数に指定された値に関する統計情報を示します (udp,tcp,sctp,ip,icmp)。これは、プロトコルの既知の名前またはその別名のいずれかです。

一部のプロトコル名と別名は、/etc/protocols ファイルにリストされています。 null 応答は、報告する数が存在しないことを示します。その統計情報ルーチンが存在しない場合は、プロトコル変数に指定された値のプログラム・レポートが不明です。

以下の例は、以下の出力を示しています。ipプロトコル：

# netstat -p ip
ip:
        45775 total packets received
        0 bad header checksums
        0 with size smaller than minimum
        0 with data size < data length
        0 with header length < data size
        0 with data length < header length
        0 with bad options
        0 with incorrect version number
        0 fragments received
        0 fragments dropped (dup or out of space)
        0 fragments dropped after timeout
        0 packets reassembled ok
        45721 packets for this host
        51 packets for unknown/unsupported protocol
        0 packets forwarded
        4 packets not forwardable
        0 redirects sent
        33877 packets sent from this host
        0 packets sent with fabricated ip header
        0 output packets dropped due to no bufs, etc.
        0 output packets discarded due to no route
        0 output datagrams fragmented
        0 fragments created
        0 datagrams that can't be fragmented
        0 IP Multicast packets dropped due to no receiver
        0 successful path MTU discovery cycles
        1 path MTU rediscovery cycle attempted
        3 path MTU discovery no-response estimates
        3 path MTU discovery response timeouts
        1 path MTU discovery decrease detected
        8 path MTU discovery packets sent
        0 path MTU discovery memory allocation failures
        0 ipintrq overflows
        0 with illegal source
        0 packets processed by threads
        0 packets dropped by threads
        0 packets dropped due to the full socket receive buffer
        0 dead gateway detection packets sent
        0 dead gateway detection packet allocation failures
        0 dead gateway detection gateway allocation failures

強調表示されているフィールドについて、以下に説明します。

受信されたパケットの合計数
受け取った IP データグラムの合計数。
不正なヘッダー・チェックサムまたはドロップされたフラグメント
出力に次のように表示される場合bad header checksumまたはfragments dropped原因dup or out of spaceこれは、パケットを破壊するネットワーク、または十分な大きさではないデバイス・ドライバー受信キューのいずれかを示します。
受信フラグメント数
受け取ったフラグメントの合計数。
Dropped after Timeout (タイムアウト後に除去)
もしfragments dropped after timeoutがゼロ以外の場合には,time to life counter世界とはipデータグラムのすべてのフラグメントが到着する前に、ネットワークがビジーであったためにフラグメントが期限切れになりました。これを回避するには、no コマンドを使用して ipfragttl ネットワーク・パラメーターの値を大きくします。もう 1 つの理由として考えられるのは、mbuf の不足です。この場合は thewall の値を大きくしてください。
このホストから送信されたパケット
このシステムで作成され、送信された IP データグラムの数。このカウンターは、転送されたデータグラム (パススルー・トラフィック) を含みません。
作成されたフラグメント
IP データグラムが送信されたときに、このシステムで作成されたフラグメントの数。

IP 統計を表示する場合は、以下の比率を確認してください。packets receivedへfragments received. MTU ネットワークが小さい場合のガイドラインとして、パケットの 10% 以上がフラグメント化されている場合は、さらに調査して原因を判別する必要があります。フラグメントの数が多い場合は、リモート・ホスト上で IP レイヤーの上位にあるプロトコルが、インターフェースの MTU よりデータのサイズが大きい IP へ、データを渡しています。ネットワーク・パス内のゲートウェイ/ルーチンも、ネットワーク内のほかのノードより MTU サイズがかなり小さい可能性があります。同じロジックを以下に適用できます。packets sentおよびfragments created.

フラグメント化が行われると CPU のオーバーヘッドが大きくなるので、その原因を特定することが重要です。アプリケーションによっては、その性質上、フラグメント化が起きるものもあります。例えば、少量のデータを送信するアプリケーションでは、フラグメント化が行われます。ただし、アプリケーションが大量のデータを送信する場合でも、フラグメント化が起きる場合は、その原因を特定する必要があります。多くの場合、使用される MTU のサイズは、システムで構成された MTU のサイズではありません。

以下の例は、以下の出力を示しています。udpプロトコル：

# netstat -p udp
udp:
        11623 datagrams received
        0 incomplete headers
        0 bad data length fields
        0 bad checksums
        620 dropped due to no socket
        10989 broadcast/multicast datagrams dropped due to no socket
        0 socket buffer overflows
        14 delivered
        12 datagrams output

注目すべき統計情報は次のとおりです。

正しくないチェックサム
ハードウェア・カードまたはケーブルのカードが原因で、チェックサムが無効になることがあります。
Dropped due to No Socket (ソケットがないため除去された)
受け取った UDP データグラムのうち、宛先ソケット・ポートが開かれなかった数。結果として、ICMP Destination Unreachable - Port Unreachableメッセージが送信されていなければなりません。ただし、受け取った UDP データグラムがブロードキャスト・データグラムである場合は、ICMP エラーが生成されません。この値が大きい場合は、アプリケーションがソケットをどのように処理しているかを調べてください。
ソケット・バッファー・オーバーフロー
ソケット・バッファーのオーバーフローは、送信および受信 UDP ソケットが不十分であること、nfsd デーモンが少なすぎること、または nfs_socketsize、udp_recvspace および sb_max の値が小さすぎることが原因であると考えられます。

netstat -p udp コマンドによってソケットのオーバーフローが示された場合は、サーバー上の nfsd デーモンの数を増やす必要があります。まず、影響を受けるシステムを CPU または入出力の飽和状態について調べ、no -a コマンドを使用してその他の通信レイヤーの推奨設定値を調べます。システムが飽和状態の場合は、その負荷を減らすか、またはリソースを増やす必要があります。

以下の例は、以下の出力を示しています。tcpプロトコル：

 # netstat -p tcp
tcp:
        576 packets sent
                512 data packets (62323 bytes)
                0 data packets (0 bytes) retransmitted
                55 ack-only packets (28 delayed)
                0 URG only packets
                0 window probe packets
                0 window update packets
                9 control packets
                0 large sends
                0 bytes sent using largesend
                0 bytes is the biggest largesend
        719 packets received
                504 acks (for 62334 bytes)
                19 duplicate acks
                0 acks for unsent data
                449 packets (4291 bytes) received in-sequence
                8 completely duplicate packets (8 bytes)
                0 old duplicate packets
                0 packets with some dup. data (0 bytes duped)
                5 out-of-order packets (0 bytes)
                0 packets (0 bytes) of data after window
                0 window probes
                2 window update packets
                0 packets received after close
                0 packets with bad hardware assisted checksum
                0 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short
                0 discarded by listeners
                0 discarded due to listener's queue full
                71 ack packet headers correctly predicted
                172 data packet headers correctly predicted
        6 connection requests
        8 connection accepts
        14 connections established (including accepts)
        6 connections closed (including 0 drops)
        0 connections with ECN capability
        0 times responded to ECN
        0 embryonic connections dropped
        504 segments updated rtt (of 505 attempts)
        0 segments with congestion window reduced bit set
        0 segments with congestion experienced bit set
        0 resends due to path MTU discovery
        0 path MTU discovery terminations due to retransmits
        0 retransmit timeouts
                0 connections dropped by rexmit timeout
        0 fast retransmits
                0 when congestion window less than 4 segments
        0 newreno retransmits
        0 times avoided false fast retransmits
        0 persist timeouts
                0 connections dropped due to persist timeout
        16 keepalive timeouts
                16 keepalive probes sent
                0 connections dropped by keepalive
        0 times SACK blocks array is extended
        0 times SACK holes array is extended
        0 packets dropped due to memory allocation failure
        0 connections in timewait reused
        0 delayed ACKs for SYN
        0 delayed ACKs for FIN
        0 send_and_disconnects
        0 spliced connections
        0 spliced connections closed
        0 spliced connections reset
        0 spliced connections timeout
        0 spliced connections persist timeout
        0 spliced connections keepalive timeout

注目すべき統計情報は次のとおりです。

Packets Sent
Data Packets
Data Packets Retransmitted
受信パケット数
Completely Duplicate Packets
Retransmit Timeouts

TCP 統計情報の場合は、送信されたパケットの数と再送されたデータ・パケットの数を比較してください。再送されたパケットの数が、送信されたパケットの合計数の 10% から 15% を超える場合は、TCP でタイムアウトが起きています。この場合は、ネットワーク・トラフィック量が多すぎるために、タイムアウト前に肯定応答 (ACK) が戻りません。受信ノード上のボトルネックまたは一般的なネットワーク上の問題によっても、TCP の再送が行われることがあります。これにより、ネットワーク・トラフィック量が多くなり、さらにネットワーク・パフォーマンス上の問題が大きくなります。

また、受信されたパケットの数、および完全に重複しているパケットの数を比較してください。送信ノード上の TCP が、受信ノードから ACK を受け取る前にタイムアウトになると、パケットが再送されます。パケットの重複は、受信ノードが最終的にすべての再送パケットを受け取ったときに発生します。重複パケットの数が 10% から 15% を超えると、問題はやはりネットワーク・トラフィック量が多くなりすぎること、または受信ノードにボトルネックが生じることです。パケットが重複すると、ネットワーク・トラフィック量が多くなります。

再送タイムアウトの値は、TCP がパケットを送信したのに、ACK を時間内に受け取らなかったときに発生します。このとき、パケットは再送されます。この値は続いて再送が行われるたびに増分されます。このように再送が連続すると、CPU 使用率が高くなり、受信ノードがパケットを受け取らなかった場合は、パケットは最終的に破棄されます。