LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

minor indexing updates; packet filter introduction written

This commit is contained in:
mabrown 2003-05-14 03:48:09 +00:00
parent 6d1aa0bf99
commit 9182936234
4 changed files with 340 additions and 157 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

191
LDP/guide/docbook/linux-ip/ether.xml
View File

@ -946,63 +946,107 @@ Received 2 response(s)</computeroutput>
</para>
</section>
</section>
<section id="ether-arp-proxy">
<title>Proxy ARP</title>
<indexterm zone="ether-arp-proxy">
<primary>ARP, proxy</primary>
</indexterm>
<para>
FIXME; manual proxy ARP (see also
<xref linkend="adv-proxy-arp"/>), kernel proxy ARP, and the newly
supported <filename>/proc/sys/net/ipv4/conf/$DEV/medium_id</filename>.
</para>
<anchor id="ether-arp-proxy-mediumid"/>
<indexterm zone="ether-arp-proxy-mediumid">
<primary>sysctl</primary>
<secondary><constant>medium_id</constant></secondary>
</indexterm>
<indexterm zone="ether-arp-proxy-mediumid">
<primary><constant>ARP, proxy</constant></primary>
<secondary>with kernel</secondary>
<tertiary><constant>medium_id</constant></tertiary>
</indexterm>
<para>
For a brief description of the use of medium_id, see
<ulink url="http://www.ssi.bg/~ja/#medium_id">Julian's
remarks</ulink>.
</para>
<anchor id="ether-arp-proxy-kernel"/>
<indexterm zone="ether-arp-proxy-kernel">
<primary>ARP, proxy</primary>
<secondary>with kernel</secondary>
<tertiary><constant>proxy_arp</constant></tertiary>
</indexterm>
<indexterm zone="ether-arp-proxy-kernel">
<primary>sysctl</primary>
<secondary><constant>proxy_arp</constant></secondary>
</indexterm>
<para>
FIXME; Kernel proxy ARP with
<filename>/proc/sys/net/ipv4/conf/$DEV/proxy_arp</filename>.
</para>
<para>
</para>
</section>
<section id="ether-arp-filtering">
<title>ARP filtering</title>
<indexterm zone="ether-arp-filtering">
<primary>ARP filtering</primary>
</indexterm>
<indexterm zone="ether-arp-filtering">
<primary><command>ip arp</command></primary>
</indexterm>
<para>
This section should be part of the "ghetto" which will
include documentation on <command>ip arp</command>. There's nothing
more to add here at the moment (low priority).
</para>
<para>
<programlisting>
</section>
<section id="ether-arp-proxy">
<title>Proxy ARP</title>
<indexterm zone="ether-arp-proxy" significance="preferred">
<primary>ARP, proxy</primary>
</indexterm>
<para>
Occasionally, an IP network must be split into separate segments. Proxy
ARP can be used for increased control over packets exchanged between two
hosts or to limit exposure between two hosts in a single IP network.
The technique of proxy ARP is commonly used to interpose a device with
higher layer functionality between two other hosts. From a practical
standpoint, there is little difference between the functions of a
<link linkend="bridging-packet-filter">packet-filtering bridge</link> and
a firewall performing proxy ARP. The manner by which the interposed
device receives the packets, however, is tremendously different.
</para>
<example id="ex-ether-arp-proxy">
<title>Proxy ARP Network Diagram</title>
<mediaobject id="image-ether-arp-proxy">
<imageobject>
<imagedata fileref="images/ether-arp-proxy.eps" format="EPS"/>
</imageobject>
<imageobject>
<imagedata fileref="images/ether-arp-proxy.png" format="PNG"/>
</imageobject>
<imageobject>
<imagedata fileref="images/ether-arp-proxy.jpg" format="JPG"/>
</imageobject>
</mediaobject>
</example>
<para>
The device performing proxy ARP (&masq-gw;) responds for all ARP queries
on behalf of IPs reachable on interfaces other than the interface on
which the query arrives.
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<para>
FIXME; manual proxy ARP (see also
<xref linkend="adv-proxy-arp"/>), kernel proxy ARP, and the newly
supported sysctl <filename>net/ipv4/conf/$DEV/medium_id</filename>.
</para>
<anchor id="ether-arp-proxy-mediumid"/>
<indexterm zone="ether-arp-proxy-mediumid">
<primary>sysctl</primary>
<secondary><constant>medium_id</constant></secondary>
</indexterm>
<indexterm zone="ether-arp-proxy-mediumid">
<primary><constant>ARP, proxy</constant></primary>
<secondary>with kernel</secondary>
<tertiary><constant>medium_id</constant></tertiary>
</indexterm>
<para>
For a brief description of the use of medium_id, see
<ulink url="http://www.ssi.bg/~ja/#medium_id">Julian's
remarks</ulink>.
</para>
<anchor id="ether-arp-proxy-kernel"/>
<indexterm zone="ether-arp-proxy-kernel">
<primary>ARP, proxy</primary>
<secondary>with kernel</secondary>
<tertiary><constant>proxy_arp</constant></tertiary>
</indexterm>
<indexterm zone="ether-arp-proxy-kernel">
<primary>sysctl</primary>
<secondary><constant>proxy_arp</constant></secondary>
</indexterm>
<para>
FIXME; Kernel proxy ARP with the sysctl
<filename>net/ipv4/conf/$DEV/proxy_arp</filename>.
</para>
<para>
Note....until this section is written, this
<ulink url="http://mailman.ds9a.nl/pipermail/lartc/2003q2/008315.html">post</ulink>
by Don Cohen is rather instructive.
</para>
</section>
<section id="ether-arp-filtering">
<title>ARP filtering</title>
<indexterm zone="ether-arp-filtering">
<primary>ARP filtering</primary>
</indexterm>
<indexterm zone="ether-arp-filtering">
<primary><command>ip arp</command></primary>
</indexterm>
<para>
This section should be part of the "ghetto" which will
include documentation on <command>ip arp</command>. There's nothing
more to add here at the moment (low priority).
</para>
<para>
<programlisting>
<prompt># </prompt><userinput>ip arp help</userinput>
<computeroutput>Usage: ip arp [ list | flush ] [ RULE ]
ip arp [ append | prepend | add | del | change | replace | test ] RULE
@ -1012,23 +1056,22 @@ RULE := [ table TABLE_NAME ] [ pref NUMBER ] [ from PREFIX ] [ to PREFIX ]
TABLE_NAME := [ input | forward | output ]
ACTION := [ deny | allow ]
ALTER := [ src IP ] [ llsrc LLADDR ] [ lldst LLADDR ]</computeroutput>
</programlisting>
</para>
<para>
The
<ulink url="http://www.ssi.bg/~ja/#iparp"><command>ip
arp</command></ulink> tool.
Patches and code for the
<ulink url="http://www.ssi.bg/~ja/#noarp">noarp
route flag</ulink>.
</para>
<para>
FIXME; add a few paragraphs on <command>ip arp</command> and the noarp
flag.
</para>
<para>
</para>
</section>
</programlisting>
</para>
<para>
The
<ulink url="http://www.ssi.bg/~ja/#iparp"><command>ip
arp</command></ulink> tool.
Patches and code for the
<ulink url="http://www.ssi.bg/~ja/#noarp">noarp
route flag</ulink>.
</para>
<para>
FIXME; add a few paragraphs on <command>ip arp</command> and the noarp
flag.
</para>
<para>
</para>
</section>
<section id="ether-vlan">
<title>Connecting to an Ethernet 802.1q VLAN</title>

15
LDP/guide/docbook/linux-ip/links.xml
View File

@ -265,16 +265,11 @@
If your copy of &iproute2; did not get packaged
with <filename>ip-cref.ps</filename> or if you prefer online HTML,
the command reference is available
<foreignphrase>in toto</foreignphrase> as
<ulink url="http://linux-ip.net/gl/ip-cref/">HTML
at linux-ip.net</ulink>,
<ulink url="http://www.linuxgrill.com/iproute2.doc.html">HTML
at www.linuxgrill.com</ulink>,
<ulink url="http://defiant.coinet.com/iproute2/ip-cref/">HTML
at defiant.coinet.com</ulink>,
<ulink url="http://snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html">HTML
at snafu.freedom.org</ulink> or as
<ulink url="http://defiant.coinet.com/iproute2/ip-cref.ps">PostScript</ulink>.
<foreignphrase>in toto</foreignphrase> as HTML at
<ulink url="http://linux-ip.net/gl/ip-cref/">linux-ip.net</ulink>,
<ulink url="http://www.linuxgrill.com/iproute2.doc.html">www.linuxgrill.com</ulink>,
or
<ulink url="http://snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html">snafu.freedom.org</ulink>.
</para>
</listitem>
<listitem>

181
LDP/guide/docbook/linux-ip/packetfilter.xml
View File

@ -50,15 +50,35 @@
the characteristics of that packet. There are two fundamental types of
packet filters. A static packet filter is a set of rules against which
every packet is checked, and allowed or denied.
</para>
<para>
A dynamic packet filter keeps track of the connections currently passing
the firewall. This is usually described as a stateful or dynamic packet
filtering engine. Netfilter provides the capability for linux (2.4+) to
operate as a stateful packet filtering device.
</para>
<para>
The network layer portion of a firewall solution, packet filtering is
For a brief digression, consider the term <wordasword>stateful packet
inspection</wordasword>. This term has been used in two distinctly
different meanings. At least one commercial security company
differentiates between stateful packet filtering and stateful packet
inspection
<footnote>
<para>
See the following
<ulink url="http://www.netmaster.com/products/ggos-dpf.pdf">PDF</ulink>
from NetMaster Digital Security. Although I may disagree with their
use of terms, I can appreciate their clear attempt to explain their
use of these two terms.
</para>
</footnote>.
Supposedly, a stateful packet inspection engine is able to examine the
contents of a packet and make a limited guess as to the legitimacy of
the application layer content. While I would call this an application
layer proxy, I do not use the product. For the purposes of this
documentation, the terms stateful packet inspection and stateful packet
filtering are synonomous.
</para>
<para>
Packet filtering, the network layer portion of a firewall solution, is
one part of a good security stance. As the embodiment and manifestation
of an organizational security policy for network layer traffic, the
packet filter restricts traffic flows between networks and hosts. There
@ -68,7 +88,7 @@
<para>
The use of packet filtering to enforce these traffic flows is not
restricted to routers and firewalls alone. Standalone servers and
workstations can use these very same tools to protect themselves. There
workstations can use these same tools to protect themselves. There
are a couple of common approaches to packet filtering. Generally,
network security professionals subscribe to the notion that the
filtering policy should deny or drop all traffic and selectively allow
@ -81,12 +101,6 @@
This specifity enables an administrator a great deal of flexibility for
protecting resources and limiting traffic flows.
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<section id="pf-history">
<title>History of Linux Packet Filter Support</title>
<para>
@ -95,36 +109,39 @@
the mid- and late-1990s, <command>ipfwadm</command> exposed the three
packet filtering chains of kernel 2.0 to the user: in, forward, and out.
Individual entries added to these chains would be traversed in order in
the ruleset. The first matching rule in each chain would be used, and
every packet passing through a router would traverse each of these
each ruleset. The first matching rule in each chain would be used, and
every packet passing through a router would traverse these three
chains.
</para>
<para>
With the advent of linux 2.2, users could create their own chains and
chain structures. The kernel architecture was different, but
from the user's perspective, the manner in which the rules were written
was only slightly different. Rule chains, traversed rather like
subroutines and manipulated with <command>ipchains</command>,
could be arbitrarily complex and nested. The built-in
packet filtering chains are input, output and forward. The first
matching rule in any chain called from one of the built-in chains
would be used. Every packet passing through a router would traverse (at
least) the three built-in rule chains. There is backward compatible
support for <command>ipfwadm</command> syntax via a wrapper shell script
which converts the command to an <command>ipchains</command> syntax.
chain structures. The kernel architecture was different from that of
the earlier kernel, but from the user's perspective, the manner in
which the rules were written was only slightly different. Rule
chains, traversed rather like subroutines and manipulated with
<command>ipchains</command>, could be arbitrarily complex and nested.
The built-in packet filtering chains had names: input, output and
forward. The first matching rule in any chain called from one of the
built-in chains would be used. Every packet passing through a router
would traverse (at least) the three built-in rule chains. There is
backward compatible support for <command>ipfwadm</command> syntax via
a wrapper shell script which converts the command to an
<command>ipchains</command> syntax.
</para>
<para>
In kernel 2.4, the netfilter architecture which provides functionality
other than packet filtering, allows
users to create the arbitrary chains and chain structures similar to
those supported by linux 2.2. The built in chains are
INPUT, FORWARD, and OUTPUT. A major difference in the use of chains was
introduced in linux 2.4; packets passing through a router will traverse
the FORWARD chain only. User-defined <command>iptables</command> chains
resemble branches rather than subroutines. Under linux 2.4,
In kernel 2.4, the
<link linkend="pf-netfilter">netfilter architecture</link>
which provides functionality other than packet filtering, allows users
to create the arbitrary chains and chain structures similar to those
supported by linux 2.2. The built in chains are INPUT, FORWARD, and
OUTPUT. A major difference in the use of chains was introduced in
linux 2.4; packets passing through a router will traverse the FORWARD
chain only. User-defined <command>iptables</command> chains resemble
branches rather than subroutines. Under linux 2.4,
<command>ipchains</command> compatibility is maintained with a kernel
module. For <command>ipfwadm</command> compatibility, the kernel module
and the aforementioned wrapper shell script function adequately.
module. For <command>ipfwadm</command> compatibility, the kernel
module and the aforementioned wrapper shell script function
adequately.
</para>
<para>
The packet filtering support under linux has grown increasingly
@ -134,15 +151,18 @@
capabilities of linux with support for stateful packet filtering.
</para>
</section>
</section>
<section id="pf-shortcomings">
<title>Limits and Weaknesses of Packet Filtering</title>
<para>
Although the functionality offered by linux kernels for protecting
network resources with packet filtering allows tremendously specific
network layer access control and auditing capability, it alone cannot
successfully and completely protect network resources. There are
weaknesses in and limits to the usefulness of packet filters.
</para>
<section id="pf-limits">
<title>Limits of the Usefulness of Packet Filtering</title>
<para>
Although the functionality offered by linux kernels for protecting
network resources with packet filtering allows tremendously specific
network layer access control and auditing capability, it alone cannot
successfully and completely protect network resources. There are
limits to the usefulness of packet filters.
</para>
<para>
In cases where a packet filter restricts access to a resource based on
the source IP address attempting to access that resource, the packet
@ -187,6 +207,25 @@
validate data streams. Proxies are often integrated with packet
filters for a tight network layer and application layer firewall.
</para>
<para>
Tunnels are one of the most common ways to subvert a packet filter.
They come in wide varieties: ssh tunnels which allow users to
transport TCP sessions into or out of a network; GRE tunnels, which
allow arbitrary packets to be encapsulated in an IP packet; UDP
tunnels; VPN tunnels; TAP/TUN tunnels; and application layer transport
tunnels, such as RPC over HTTP/HTTPS. Some of these tunnels are very
difficult to prevent with packet filtering, while others are trivial to
block.
</para>
<para>
Perhaps it is apparent, why **FIXME** adversarial relationship between
packet filters and content....limitation of packet filter....hence
proxies...blah blah blah.
</para>
<para>
Use of ICMP, when to block ICMP; tunneling through lax packet filters
with ICMP (trinoo, ICMPchat).
</para>
<para>
Another area of network security which is not addressed by packet
filtering is encryption. Encryption can be used at a number of
@ -194,10 +233,11 @@
packets, with Secure Sockets Layer (SSL), which encrypts a single
application layer session. IPSec operates at layer 3, while SSL
operates above layer 4. Packet filtering does not directly address
the issue of encryption in any way.
the issue of encryption in any way. Both are tools used in an
ongoing effort to maintain and secure a network.
</para>
<para>
There are a few good starting place for users wishing for some
There are a few good starting place for those needing
guidelines on securing machines. First, the
<ulink url="http://tldp.org/HOWTO/Security-Quickstart-HOWTO/index.html">Security
Quickstart HOWTO</ulink> is a good place to begin. There is also the
@ -214,33 +254,36 @@
network immune from security issues.
</para>
</section>
</section>
<section id="pf-weakness">
<title>Weaknesses of Packet Filtering</title>
<para>
Stateless packet filters. (cf. iptables connection tracking), cf. state
vs. stateless discussion.
</para>
<para>
Use of ICMP, when to block ICMP; tunneling through lax packet filters
with ICMP (trinoo, ICMPchat).
</para>
<para>
spoofed source addresses, xref binding non-local addresses
</para>
<para>
confounded application layer protocols like FTP, H323
</para>
<para>
DoS on connection tracking packet filters
</para>
<para>
DoS on rate limiters ?
</para>
<para>
</para>
<para>
</para>
<section id="pf-weakness">
<title>Weaknesses of Packet Filtering</title>
<para>
The weaknesses of static (or stateless) packet filters and stateful
packet filters are different in a few ways. Stateless packet filters
frequently block SYN scans of networks, but ....
</para>
<para>
Stateless packet filters. (cf. iptables connection tracking), cf. state
vs. stateless discussion.
</para>
<para>
</para>
<para>
confounded application layer protocols like FTP, H323
</para>
<para>
Because of the nature of connection tracking and state awareness,
stateful packet filters are vulnerable to resource exhaustion and
deliberate attempts to trip rate-limiting features.
</para>
<para>
DoS on connection tracking packet filters
DoS on rate limiters ?
</para>
<para>
</para>
<para>
</para>
</section>
<section id="pf-weakness-stateless">
<title>Complex Network Layer Stateless Packet Filters</title>
<para>

110
LDP/guide/docbook/linux-ip/tools-diagnostics.xml
View File

@ -1,7 +1,10 @@
<!-- $Id$ -->
<appendix id="tools-diagnostics">
<title>Diagnostics</title>
<title>Diagnostic Tools</title>
<indexterm zone="tools-diagnostics">
<primary>diagnostic tools</primary>
</indexterm>
<para>
Now that we have covered most of the basic tools for management of
routes, IP addresses, and a few Ethernet tools, we come to a set of
@ -38,6 +41,14 @@
</para>
<section id="tools-ping">
<title><command>ping</command></title>
<indexterm zone="tools-ping" significance="preferred">
<primary><command>ping</command> command</primary>
</indexterm>
<indexterm zone="tools-ping">
<primary><command>ping</command> command</primary>
<secondary>description of</secondary>
<seealso>ICMP echo request and ICMP echo reply</seealso>
</indexterm>
<para>
<command>ping</command> is one of the oldest IP utilities around.
Simply put, <command>ping</command> asks another host if it is alive,
@ -69,14 +80,19 @@
operation can provide some insight into the state of a network or a
series of networks.
</para>
<indexterm zone="tools-ping">
<primary>ICMP echo reply</primary>
<secondary>tunnelling data in</secondary>
<seealso><command>ping</command></seealso>
</indexterm>
<para>
In most cases, the ICMP echo-request packets and echo-reply packets,
upon which <command>ping</command>'s functionality relies, are allowed
through routers and firewalls, however with the advent of trojans and
distributed denial of service tools which transmit information within
ICMP packets, some networks and network administrators block ICMP at
their borders. For an example of such a trojan, see this <ulink
url="http://staff.washington.edu/dittrich/misc/tfn.analysis">dissection
their borders. For an example of such a trojan, see this
<ulink url="http://staff.washington.edu/dittrich/misc/tfn.analysis">dissection
of the trinoo</ulink> distributed denial of service tool. As a result
of these nefarious uses of echo-request and echo-reply packets, some
cautious network administrators block all non-essential ICMP at their
@ -107,6 +123,10 @@
</para>
<section id="tools-ping-simple">
<title>Using <command>ping</command> to test reachability</title>
<indexterm zone="tools-ping-simple">
<primary><command>ping</command> command</primary>
<secondary>basic use</secondary>
</indexterm>
<para>
In its simplest form, <command>ping</command> is used interactively
on the command line to test reachability of a remote host. Again,
@ -194,6 +214,11 @@ round-trip min/avg/max/mdev = 0.179/0.208/0.231/0.024 ms</computeroutput>
<example id="ex-tools-ping-simple-count">
<title>Using <command>ping</command> to specify number of packets to
send</title>
<indexterm zone="ex-tools-ping-simple-count">
<primary><command>ping</command> command</primary>
<secondary>sending specified number of packets
(<option>-c</option>)</secondary>
</indexterm>
<programlisting>
<prompt>[root@morgan]# </prompt><userinput>ping -c 10 -n 192.168.100.17</userinput>
<computeroutput>PING 192.168.100.17 (192.168.100.17) from 192.168.98.82 : 56(84) bytes of data.
@ -231,6 +256,10 @@ round-trip min/avg/max/mdev = 38.173/38.480/39.568/0.423 ms</computeroutput>
<example id="ex-tools-ping-simple-quiet">
<title>Using <command>ping</command> to specify number of packets to
send</title>
<indexterm zone="ex-tools-ping-simple-quiet">
<primary><command>ping</command> command</primary>
<secondary>quiet mode (<option>-q</option>)</secondary>
</indexterm>
<programlisting>
<prompt>[root@morgan]# </prompt><userinput>ping -q -c 10 -n 192.168.100.17</userinput>
<computeroutput>PING 192.168.100.17 (192.168.100.17) from 192.168.98.82 : 56(84) bytes of data.
@ -256,6 +285,10 @@ round-trip min/avg/max/mdev = 37.853/38.370/39.320/0.430 ms</computeroutput>
</section>
<section id="tools-ping-stress">
<title>Using <command>ping</command> to stress a network</title>
<indexterm zone="tools-ping-stress">
<primary><command>ping</command> command</primary>
<secondary>stressing a network (<option>-f</option>)</secondary>
</indexterm>
<para>
Occasionally, you'll want to stress the network to test how many
packets you can squeeze through a link, and how gracefully
@ -287,6 +320,10 @@ round-trip min/avg/max/mdev = 37.840/62.234/97.807/12.946 ms</computeroutput>
<example id="ex-tools-ping-stress-size">
<title>Using <command>ping</command> to stress a network with large
packets</title>
<indexterm zone="ex-tools-ping-stress-size">
<primary><command>ping</command> command</primary>
<secondary>specifying packet size (<option>-s</option>)</secondary>
</indexterm>
<programlisting>
<prompt>[root@morgan]# </prompt><userinput>ping -s 512 -c 400 -f -n 192.168.99.254</userinput>
<computeroutput>PING 192.168.99.254 (192.168.99.254) from 192.168.98.82 : 512(540) bytes of data.
@ -321,6 +358,10 @@ round-trip min/avg/max/mdev = 47.854/295.711/649.595/153.345 ms</computeroutput>
</section>
<section id="tools-ping-record-route">
<title>Recording a network route with <command>ping</command></title>
<indexterm zone="tools-ping-record-route">
<primary><command>ping</command> command</primary>
<secondary>recording a route (<option>-R</option>)</secondary>
</indexterm>
<para>
The options we have outlined above are common options to
<command>ping</command>, but now, let's look at some of the less
@ -386,6 +427,10 @@ round-trip min/avg/max/mdev = 47.893/52.102/56.311/4.209 ms</computeroutput>
</section>
<section id="tools-ping-ttl">
<title>Setting the TTL on a <command>ping</command> packet</title>
<indexterm zone="tools-ping-ttl">
<primary><command>ping</command> command</primary>
<secondary>setting a TTL manually (<option>-t</option>)</secondary>
</indexterm>
<para>
Now, frankly, I'm not sure of a practical use for the following
option to <command>ping</command>, however, you can specify the TTL
@ -423,6 +468,10 @@ round-trip min/avg/max/mdev = 47.893/52.102/56.311/4.209 ms</computeroutput>
</section>
<section id="tools-ping-tos">
<title>Setting ToS for a diagnostic <command>ping</command></title>
<indexterm zone="tools-ping-tos">
<primary><command>ping</command> command</primary>
<secondary>setting ToS flag manually (<option>-Q</option>)</secondary>
</indexterm>
<para>
Type of Service (ToS) is increasingly in use on backbones across the
Internet which has brought with it Service Level Agreements (SLA).
@ -470,6 +519,10 @@ round-trip min/avg/max/mdev = 36.323/43.978/51.633/7.655 ms</computeroutput>
</section>
<section id="tools-ping-specify-source">
<title>Specifying a source address for <command>ping</command></title>
<indexterm zone="tools-ping-specify-source">
<primary><command>ping</command> command</primary>
<secondary>preferring a source address (<option>-I</option>)</secondary>
</indexterm>
<para>
Occasionally, you'll find yourself on a heavily packet filtered
host, or a host which employs conditional routing for packets with
@ -543,6 +596,9 @@ round-trip min/avg/max/mdev = 53.976/61.630/69.285/7.658 ms</computeroutput>
</section>
<section id="tools-traceroute">
<title><command>traceroute</command></title>
<indexterm zone="tools-traceroute" significance="preferred">
<primary><command>traceroute</command> command</primary>
</indexterm>
<para>
<command>traceroute</command> is a utility for identifying the network
path a packet will take to a destination. Like ping, it can be called
@ -565,6 +621,9 @@ round-trip min/avg/max/mdev = 53.976/61.630/69.285/7.658 ms</computeroutput>
</para>
<section id="tools-traceroute-basic">
<title>Using <command>traceroute</command></title>
<indexterm zone="tools-traceroute" significance="preferred">
<primary><command>traceroute</command> command</primary>
</indexterm>
<para>
The default packet type created by <command>traceroute</command>
is a UDP packet. The first packet will be addressed to udp/33435
@ -574,6 +633,10 @@ round-trip min/avg/max/mdev = 53.976/61.630/69.285/7.658 ms</computeroutput>
</para>
<example id="ex-tools-traceroute-basic">
<title>Simple usage of <command>traceroute</command></title>
<indexterm zone="tools-traceroute">
<primary><command>traceroute</command> command</primary>
<secondary>basic use</secondary>
</indexterm>
<programlisting>
<prompt>[root@isolde]# </prompt><userinput>traceroute -n 192.168.99.35</userinput>
<prompt>[root@isolde]# </prompt><userinput>tcpdump -nn -i eth0 not tcp</userinput>
@ -628,6 +691,10 @@ tcpdump: listening on eth0
<section id="tools-traceroute-icmp">
<title>Telling <command>traceroute</command> to use ICMP echo request
instead of UDP</title>
<indexterm zone="tools-traceroute-icmp">
<primary><command>traceroute</command> command</primary>
<secondary>using ICMP packets (<option>-I</option>)</secondary>
</indexterm>
<para>
</para>
<para>
@ -635,6 +702,10 @@ tcpdump: listening on eth0
</section>
<section id="tools-traceroute-tos">
<title>Setting ToS with <command>traceroute</command></title>
<indexterm zone="tools-traceroute-icmp">
<primary><command>traceroute</command> command</primary>
<secondary>setting ToS flags (<option>-t</option>)</secondary>
</indexterm>
<para>
</para>
</section>
@ -652,6 +723,9 @@ tcpdump: listening on eth0
</section>
<section id="tools-netstat">
<title><command>netstat</command></title>
<indexterm zone="tools-netstat" significance="preferred">
<primary><command>netstat</command> command</primary>
</indexterm>
<para>
The <command>netstat</command> utility summarizes a variety of
characteristics of the networking stack. With
@ -677,6 +751,11 @@ tcpdump: listening on eth0
<section id="tools-netstat-socket">
<title>Displaying socket status with
<command>netstat</command></title>
<indexterm zone="tools-netstat-socket">
<primary><command>netstat</command> command</primary>
<secondary>displaying socket status
(<option>--inet</option>)</secondary>
</indexterm>
<para>
One of the most common uses of the <command>netstat</command>
utility is to determine the state of sockets on a machine.
@ -960,6 +1039,11 @@ tcp 0 240 192.168.99.254:ssh 192.168.99.35:42948 ESTABLISHED
<section id="tools-netstat-route">
<title>Displaying the main routing table with
<command>netstat</command></title>
<indexterm zone="tools-netstat-route">
<primary><command>netstat</command> command</primary>
<secondary>displaying the main routing table
(<option>-r</option> or <option>--route</option>)</secondary>
</indexterm>
<para>
One of the most common uses of <command>netstat</command>,
especially in cross-platform environments is the reporting of the
@ -1014,7 +1098,12 @@ Source Destination Gateway Flags MSS Window irtt Iface
</section>
<section id="tools-netstat-interface">
<title>Displaying network interface statistics with
<command>netstat</command></title>
<command>netstat</command> command</title>
<indexterm zone="tools-netstat-interface">
<primary><command>netstat</command> command</primary>
<secondary>displaying network interface statistics
(<option>-i</option> or <option>--interface</option>)</secondary>
</indexterm>
<para>
<command>netstat -i</command> summarizes interface statistics in a
terse format. This format
@ -1033,6 +1122,11 @@ Source Destination Gateway Flags MSS Window irtt Iface
<section id="tools-netstat-statistics">
<title>Displaying network stack statistics with
<command>netstat</command></title>
<indexterm zone="tools-netstat-statistics">
<primary><command>netstat</command> command</primary>
<secondary>displaying IP stack statistics
(<option>-s</option> or <option>--statistics</option>)</secondary>
</indexterm>
<para>
</para>
<para>
@ -1041,6 +1135,11 @@ Source Destination Gateway Flags MSS Window irtt Iface
<section id="tools-netstat-masquerade">
<title>Displaying the masquerading table with
<command>netstat</command></title>
<indexterm zone="tools-netstat-masquerade">
<primary><command>netstat</command> command</primary>
<secondary>displaying the masquerading table
(<option>-M</option> or <option>--masquerade</option>)</secondary>
</indexterm>
<para>
For machines which perform masquerading, typically dual-homed
packet-filtering firewalls like &masq-gw; a tool to list the current
@ -1075,6 +1174,8 @@ Source Destination Gateway Flags MSS Window irtt Iface
<section id="tools-tcpdump">
<title><command>tcpdump</command></title>
<para>
The <command>tcpdump</command> utility is a not as friendly as some
other network diagnostic tools. Some of the output is
</para>
<para>
</para>
@ -1093,6 +1194,7 @@ Source Destination Gateway Flags MSS Window irtt Iface
packet analysis.
</para>
<para>
</para>
<para>
</para>