mirror of https://github.com/tLDP/LDP
tweaks while editing routing; entities
This commit is contained in:
mabrown
parent
618b1c7dcf
commit
07e4bfa915
|
|
@ -69,7 +69,7 @@
|
|||
<footnote>
|
||||
<para>
|
||||
Leonardo calls this "dumb NAT" because the NAT performed by
|
||||
<command>iproute2</command> at the routing stage is stateless.
|
||||
&iproute2; at the routing stage is stateless.
|
||||
</para>
|
||||
</footnote>.
|
||||
</para>
|
||||
|
|
@ -276,7 +276,7 @@
|
|||
can assist in managing multiple Internet connections. We'll outline
|
||||
here some of the more common setups involving multiple Internet
|
||||
connections and how to manage them with <command>iptables</command>,
|
||||
<command>ipchains</command>, and <command>iproute2</command>. One of
|
||||
<command>ipchains</command>, and &iproute2;. One of
|
||||
the first distinctions you can make when planning how to use multiple
|
||||
Internet connections is what inbound services you expect to host and
|
||||
how you want to split traffic over the multiple links.
|
||||
|
|
@ -512,7 +512,7 @@ Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
|
|||
<xref linkend="adv-routing-fwmark"/>.
|
||||
</para>
|
||||
<para>
|
||||
<command>iproute2</command> supports the use of fwmark as a selector
|
||||
&iproute2; supports the use of fwmark as a selector
|
||||
for rule lookups, so we can use fwmarks in the routing policy
|
||||
database to cause packets to be conditionally routed based on that
|
||||
fwmark. This can lead to great complexity if a machine has multiple
|
||||
|
|
@ -522,7 +522,7 @@ Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
|
|||
<para>
|
||||
A convention I find sensible is to use the same number for a routing
|
||||
table and fwmark where possible. This simplifies the maintenance of
|
||||
the systems which are using <command>iproute2</command> and fwmark,
|
||||
the systems which are using &iproute2; and fwmark,
|
||||
especially if the table identifier and fwmark are set in a
|
||||
configuration file with the same variable name. Since we are
|
||||
testing this on the command line, we'll just make sure that we can
|
||||
|
|
@ -620,7 +620,7 @@ Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
|
|||
we'll discuss how this client IP would reach each of the services
|
||||
published on &masq-gw;'s two public networks. The IPs used for
|
||||
the services will be 67.17.28.10 and 205.254.211.17.
|
||||
Now, whether you are using NAT with <command>iproute2</command> or
|
||||
Now, whether you are using NAT with &iproute2; or
|
||||
with iptables, you'll run across the problem here outlined. Here
|
||||
is the flow of the packet through &masq-gw; to the server and back
|
||||
to the client.
|
||||
|
|
@ -639,7 +639,7 @@ Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
|
|||
packet is accepted, rewritten, and routed; from 64.70.12.210 to
|
||||
192.168.100.17; if <command>iptables</command> DNAT,
|
||||
packet is rewritten in PREROUTING chain of nat table, then
|
||||
routed; if <command>iproute2</command>, packet is routed and
|
||||
routed; if &iproute2;, packet is routed and
|
||||
rewritten simultaneously
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -661,7 +661,7 @@ Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
|
|||
<listitem>
|
||||
<para>
|
||||
routing decision is made; default route (via 205.254.211.254) is
|
||||
selected; if <command>iproute2</command> is used, packet is
|
||||
selected; if &iproute2; is used, packet is
|
||||
also rewritten from 67.17.28.10 to 64.70.12.210
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -706,7 +706,7 @@ Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
|
|||
</para>
|
||||
<example id="ex-adv-multi-internet-inbound">
|
||||
<title>Multiple Internet links, inbound traffic; using
|
||||
<command>iproute2</command> only
|
||||
&iproute2; only
|
||||
<footnote>
|
||||
<para>
|
||||
This example makes no reference to packet filtering. If you are
|
||||
|
|
|
|||
|
|
@ -405,14 +405,6 @@ round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms</computeroutput>
|
|||
</para>
|
||||
<example id="ex-basic-ping-non-local">
|
||||
<title>Testing reachability of non-local hosts</title>
|
||||
<programlistingco>
|
||||
<areaspec>
|
||||
<area id="ex-bpnl-tristan-out" coords="8"/>
|
||||
<area id="ex-bpnl-masq-gw-out" coords="9"/>
|
||||
<area id="ex-bpnl-wan-gw-in" coords="11"/>
|
||||
<area id="ex-bpnl-masq-gw-in" coords="12"/>
|
||||
<area id="ex-bpnl-tristan-in" coords="13"/>
|
||||
</areaspec>
|
||||
<programlisting>
|
||||
<prompt>[root@tristan]# </prompt><userinput>ping -R -c 1 -n 205.254.211.254</userinput>
|
||||
<computeroutput>PING 205.254.211.254 (205.254.211.254) from 192.168.99.35 : 56(84) bytes of data.
|
||||
|
|
@ -421,50 +413,59 @@ round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms</computeroutput>
|
|||
1 packets transmitted, 0 packets received, 100% packet loss
|
||||
PING 205.254.211.254 (205.254.211.254) from 192.168.99.35 : 56(84) bytes of data.
|
||||
64 bytes from 205.254.211.254: icmp_seq=0 ttl=255 time=238 usec
|
||||
RR: 192.168.99.35
|
||||
205.254.211.179
|
||||
RR: 192.168.99.35 <co id="ex-bpnl-tristan-out" linkends="ex-bpnl-tristan-out-text"/>
|
||||
205.254.211.179 <co id="ex-bpnl-masq-gw-out" linkends="ex-bpnl-masq-gw-out-text"/>
|
||||
205.254.211.254 <co id="ex-bpnl-wan-gw-in" linkends="ex-bpnl-bpnl-wan-gw-in-text"/>
|
||||
205.254.211.254
|
||||
205.254.211.254
|
||||
192.168.99.254
|
||||
192.168.99.35
|
||||
192.168.99.254 <co id="ex-bpnl-masq-gw-in" linkends="ex-bpnl-masq-gw-in-text"/>
|
||||
192.168.99.35 <co id="ex-bpnl-tristan-in" linkends="ex-bpnl-tristan-in-text"/>
|
||||
|
||||
--- 192.168.99.254 ping statistics ---
|
||||
1 packets transmitted, 1 packets received, 0% packet loss
|
||||
round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms</computeroutput>
|
||||
</programlisting>
|
||||
<calloutlist>
|
||||
<callout arearefs="ex-bpnl-tristan-out">
|
||||
<para>
|
||||
As the packet passes through the IP stack on &tristan;,
|
||||
before hitting the ethernet, &tristan; adds its IP to the
|
||||
list of IPs in the option field in the header.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-bpnl-tristan-out"
|
||||
id="ex-bpnl-tristan-out-text">
|
||||
<simpara>
|
||||
As the packet passes through the IP stack on &tristan;,
|
||||
before hitting the ethernet, &tristan; adds its IP to the
|
||||
list of IPs in the option field in the header.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-bpnl-masq-gw-out">
|
||||
<para>
|
||||
This is &masq-gw;'s public IP address.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-bpnl-masq-gw-out"
|
||||
id="ex-bpnl-masq-gw-out-text">
|
||||
<simpara>
|
||||
This is &masq-gw;'s public IP address.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-bpnl-wan-gw-in">
|
||||
<para>
|
||||
Our intended destination! (Anybody know why there are
|
||||
two entries in the record route output?)
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-bpnl-wan-gw-in"
|
||||
id="ex-bpnl-bpnl-wan-gw-in-text">
|
||||
<simpara>
|
||||
Our intended destination! (Anybody know why there are
|
||||
two entries in the record route output?)
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-bpnl-masq-gw-in">
|
||||
<para>
|
||||
This is &masq-gw;'s private IP address.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-bpnl-masq-gw-in"
|
||||
id="ex-bpnl-masq-gw-in-text">
|
||||
<simpara>
|
||||
This is &masq-gw;'s private IP address.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-bpnl-tristan-in">
|
||||
<para>
|
||||
And finally, &tristan; will add its IP to the option field
|
||||
in the header of the IP packet just before the packet
|
||||
reaches the calling <command>ping</command> program.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-bpnl-tristan-in"
|
||||
id="ex-bpnl-tristan-in-text">
|
||||
<simpara>
|
||||
And finally, &tristan; will add its IP to the option field
|
||||
in the header of the IP packet just before the packet
|
||||
reaches the calling <command>ping</command> program.
|
||||
</simpara>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</programlistingco>
|
||||
</example>
|
||||
<para>
|
||||
By testing reachability of the local network 192.168.99.0/24 and
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
<filename>net/ipv4/conf/$DEV/medium_id</filename>, and
|
||||
<filename>net/ipv4/conf/$DEV/hidden</filename>. For even
|
||||
finer control of ARP requests than is available in stock kernels,
|
||||
there are kernel and <command>iproute2</command> patches.
|
||||
there are kernel and &iproute2; patches.
|
||||
</para>
|
||||
<para>
|
||||
Bridging, once the realm of hardware devices, can also be performed by a
|
||||
|
|
@ -203,7 +203,7 @@
|
|||
<para>
|
||||
To display the ARP cache, the venerable and cross-platform
|
||||
<command>arp</command> admirably dispatches its duty. As with many of
|
||||
the <command>iproute2</command> tools, more information is available
|
||||
the &iproute2; tools, more information is available
|
||||
via <command>ip neighbor</command> than with <command>arp</command>.
|
||||
<xref linkend="ex-ether-arp-cache"/> below illustrates the differences
|
||||
in the output between the output of these two different tools.
|
||||
|
|
@ -307,73 +307,74 @@
|
|||
</para>
|
||||
<example id="ex-ether-arp-cache-timeout">
|
||||
<title>ARP cache timeout</title>
|
||||
<programlistingco>
|
||||
<areaspec>
|
||||
<area id="ex-eact-reachable" coords="2"/>
|
||||
<area id="ex-eact-stale" coords="4"/>
|
||||
<area id="ex-eact-delay" coords="6"/>
|
||||
<area id="ex-eact-probe" coords="8"/>
|
||||
<area id="ex-eact-incomplete" coords="10"/>
|
||||
</areaspec>
|
||||
<programlisting>
|
||||
<prompt>[root@tristan]# </prompt><userinput>ip neighbor show 192.168.99.7</userinput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud reachable</computeroutput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud reachable <co id="ex-eact-reachable" linkends="ex-eact-reachable-text"/></computeroutput>
|
||||
<prompt>[root@tristan]# </prompt><userinput>ip neighbor show 192.168.99.7</userinput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud stale</computeroutput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud stale <co id="ex-eact-stale" linkends="ex-eact-stale-text"/></computeroutput>
|
||||
<prompt>[root@tristan]# </prompt><userinput>ip neighbor show 192.168.99.7</userinput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud delay</computeroutput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud delay <co id="ex-eact-delay" linkends="ex-eact-delay-text"/></computeroutput>
|
||||
<prompt>[root@tristan]# </prompt><userinput>ip neighbor show 192.168.99.7</userinput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud probe</computeroutput>
|
||||
<computeroutput>192.168.99.7 dev eth0 lladdr 00:80:c8:e8:1e:fc nud probe <co id="ex-eact-probe" linkends="ex-eact-probe-text"/></computeroutput>
|
||||
<prompt>[root@tristan]# </prompt><userinput>ip neighbor show 192.168.99.7</userinput>
|
||||
<computeroutput>192.168.99.7 dev eth0 nud incomplete</computeroutput>
|
||||
<computeroutput>192.168.99.7 dev eth0 nud incomplete <co id="ex-eact-incomplete" linkends="ex-eact-incomplete-text"/></computeroutput>
|
||||
</programlisting>
|
||||
<calloutlist>
|
||||
<callout arearefs="ex-eact-reachable">
|
||||
<para>
|
||||
Before the entry has expired for 192.168.99.7, but after the
|
||||
host has been disconnected from the network. During this
|
||||
time, &tristan; will continue to send out ethernet frames with
|
||||
the destination frame address set to the link layer address
|
||||
according to this entry.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-eact-reachable"
|
||||
id="ex-eact-reachable-text">
|
||||
<simpara>
|
||||
Before the entry has expired for 192.168.99.7, but after the
|
||||
host has been disconnected from the network. During this
|
||||
time, &tristan; will continue to send out ethernet frames with
|
||||
the destination frame address set to the link layer address
|
||||
according to this entry.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-eact-stale">
|
||||
<para>
|
||||
It has been <constant>gc_stale_time</constant> seconds since
|
||||
the entry has been verified, so the state has changed to
|
||||
stale.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-eact-stale"
|
||||
id="ex-eact-stale-text">
|
||||
<simpara>
|
||||
It has been <constant>gc_stale_time</constant> seconds since
|
||||
the entry has been verified, so the state has changed to
|
||||
stale.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-eact-delay">
|
||||
<para>
|
||||
This entry in the neighbor table has been requested. Because
|
||||
the entry was in a stale state, the link layer address was
|
||||
used, but now the kernel needs to verify the accuracy of the
|
||||
data. The kernel will soon send an ARP request for the
|
||||
destination IP address.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-eact-delay"
|
||||
id="ex-eact-delay-text">
|
||||
<simpara>
|
||||
This entry in the neighbor table has been requested.
|
||||
Because the entry was in a stale state, the link layer
|
||||
address was used, but now the kernel needs to verify
|
||||
the accuracy of the data. The kernel will soon send
|
||||
an ARP request for the destination IP address.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-eact-probe">
|
||||
<para>
|
||||
The kernel is actively performing address resolution for the
|
||||
entry. It will send a total of
|
||||
<constant>ucast_solicit</constant> frames to the last known
|
||||
link layer address to attempt to verify reachability of the
|
||||
address. Failing this, it will send
|
||||
<constant>mcast_solicit</constant> broadcast frames before
|
||||
altering the ARP cache state and returning an error to any
|
||||
higher layer services.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-eact-probe"
|
||||
id="ex-eact-probe-text">
|
||||
<simpara>
|
||||
The kernel is actively performing address resolution for the
|
||||
entry. It will send a total of
|
||||
<constant>ucast_solicit</constant> frames to the last known
|
||||
link layer address to attempt to verify reachability of the
|
||||
address. Failing this, it will send
|
||||
<constant>mcast_solicit</constant> broadcast frames before
|
||||
altering the ARP cache state and returning an error to any
|
||||
higher layer services.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout arearefs="ex-eact-incomplete">
|
||||
<para>
|
||||
After all attempts to reach the destination address have
|
||||
failed, the entry will appear in the neighbor table in this
|
||||
state.
|
||||
</para>
|
||||
<callout
|
||||
arearefs="ex-eact-incomplete"
|
||||
id="ex-eact-incomplete-text">
|
||||
<simpara>
|
||||
After all attempts to reach the destination address have
|
||||
failed, the entry will appear in the neighbor table in this
|
||||
state.
|
||||
</simpara>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</programlistingco>
|
||||
</example>
|
||||
<para>
|
||||
The remaining neighbor table flags are visible when inital ARP
|
||||
|
|
|
|||
|
|
@ -146,13 +146,13 @@
|
|||
example of the difference between linux only tools and generally available
|
||||
unix-like tools is the difference between the traditional
|
||||
<command>ifconfig</command> and <command>route</command> commands,
|
||||
available under most variants of unix, and the <command>iproute2</command>
|
||||
available under most variants of unix, and the &iproute2;
|
||||
command suite, written specificially for linux.
|
||||
</para>
|
||||
<para>
|
||||
Because this guide concerns itself with the features, strengths, and
|
||||
peculiarities of IP networking with linux, the <command>iproute2</command>
|
||||
command suite assumes a prominent role. The <command>iproute2</command>
|
||||
peculiarities of IP networking with linux, the &iproute2;
|
||||
command suite assumes a prominent role. The &iproute2;
|
||||
tools expose the strength, flexibility and potential of the linux
|
||||
networking stack.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If your copy of <command>iproute2</command> did not get packaged
|
||||
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
|
||||
|
|
@ -233,9 +233,9 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Julian Anastasov has been working on many aspects of traffic
|
||||
control and advanced routing with the <command>iproute2</command>
|
||||
control and advanced routing with the &iproute2;
|
||||
package. He has provided a large number of patches to
|
||||
<command>iproute2</command> and some documentation with
|
||||
&iproute2; and some documentation with
|
||||
for the linux virtual server (LVS) in addition to a great deal of
|
||||
code for LVS. See his <ulink
|
||||
url="http://www.linuxvirtualserver.org/~julian/">main
|
||||
|
|
@ -648,7 +648,7 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <command>iproute2</command> package provides command-line
|
||||
The &iproute2; package provides command-line
|
||||
support for the full functionality of the linux IP stack. This
|
||||
package, written by Alexey Kuznetsov, is available
|
||||
<ulink url="ftp://ftp.inr.ac.ru/ip-routing/">here</ulink> and is
|
||||
|
|
|
|||
|
|
@ -3,39 +3,62 @@ a:visited { color: #009900 ; text-decoration: none ; }
|
|||
a:hover { color: #009900 ; text-decoration: underline ; }
|
||||
a:active { color: #009900 ; text-decoration: underline ; }
|
||||
|
||||
a.local:link { color: #009900 ; text-decoration: none ; }
|
||||
a.local:visited { color: #009900 ; text-decoration: none ; }
|
||||
a.local:hover { color: #009900 ; text-decoration: underline ; }
|
||||
a.local:active { color: #009900 ; text-decoration: underline ; }
|
||||
|
||||
a.nonlocal:link { color: #0000ff ; text-decoration: none ; }
|
||||
a.nonlocal:visited { color: #0000ff ; text-decoration: none ; }
|
||||
a.nonlocal:hover { color: #0000ff ; text-decoration: underline ; }
|
||||
a.nonlocal:active { color: #0000ff ; text-decoration: underline ; }
|
||||
|
||||
BODY {
|
||||
color: black ;
|
||||
font-size: 1.0em ;
|
||||
font-family: "New Century Schoolbook", Times, serif ;
|
||||
color : black ;
|
||||
/* font-size : 1.0em ; */
|
||||
font-family : "New Century Schoolbook", Times, serif ;
|
||||
}
|
||||
|
||||
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
|
||||
/* */
|
||||
/* variable list attributes */
|
||||
/* */
|
||||
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
|
||||
|
||||
div.variablelist {
|
||||
margin : 1em 5% 1em 5% ;
|
||||
}
|
||||
|
||||
.variablelist .term {
|
||||
font-weight: bold ;
|
||||
font-weight : bold ;
|
||||
}
|
||||
|
||||
.variablelist .emphasis {
|
||||
font-weight : bold ;
|
||||
}
|
||||
|
||||
p.copyright {
|
||||
padding-left: 1.0em ;
|
||||
padding-right: 1.0em ;
|
||||
margin: 0em 0% 0.2em 0% ;
|
||||
font-size: 0.7em ;
|
||||
font-family: Verdana, Arial, Helvetica ;
|
||||
text-align: right ;
|
||||
color: #808080 ;
|
||||
padding-left : 1.0em ;
|
||||
padding-right : 1.0em ;
|
||||
margin : 0em 0% 0.2em 0% ;
|
||||
font-size : 0.7em ;
|
||||
font-family : Verdana, Arial, Helvetica ;
|
||||
text-align : right ;
|
||||
color : #808080 ;
|
||||
}
|
||||
|
||||
.revhistory {
|
||||
padding-left : 0.5em ;
|
||||
padding-right : 0.5em ;
|
||||
margin : 0em 0% 0.2em 0% ;
|
||||
font-size : 0.5em ;
|
||||
/* font-family : Verdana, Arial, Helvetica ; */
|
||||
text-align : right ;
|
||||
color : #808080 ;
|
||||
}
|
||||
|
||||
.calloutlist {
|
||||
padding-left: 0.5em ;
|
||||
padding-right: 0.5em ;
|
||||
margin: 0em 0% 0.2em 0% ;
|
||||
font-size: 0.5em ;
|
||||
/* font-family: Verdana, Arial, Helvetica ; */
|
||||
text-align: right ;
|
||||
color: #808080 ;
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,12 @@
|
|||
<!-- some entitiies used in the code....should probably be shoved
|
||||
into another file someplace else -->
|
||||
|
||||
<!ENTITY local "<constant>local</constant>" >
|
||||
<!ENTITY main "<constant>main</constant>" >
|
||||
<!ENTITY src "<constant>src</constant>" >
|
||||
<!ENTITY fwmark "<constant>fwmark</constant>" >
|
||||
<!ENTITY iproute2 "<command>iproute2</command>" >
|
||||
|
||||
<!ENTITY wan-gw
|
||||
'<systemitem class="systemname">wan-gw</systemitem>' >
|
||||
<!ENTITY masq-gw
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
This chapter will introduce two types of NAT available under linux. One,
|
||||
<link linkend="nat-stateless">full NAT or stateless NAT</link>, is
|
||||
available under kernel 2.2 and kernel 2.4 via the
|
||||
<command>iproute2</command> userspace interface. Available only under
|
||||
&iproute2; userspace interface. Available only under
|
||||
kernel 2.4,
|
||||
<link linkend="nat-dnat">destination NAT (DNAT)</link> is an important
|
||||
derivative of full NAT. DNAT configuration from userspace is accomplished
|
||||
|
|
@ -138,7 +138,7 @@
|
|||
<para>
|
||||
Providing inbound services via NAT can be accomplished in several
|
||||
different ways. Two common techniques are to use
|
||||
<command>iproute2</command> NAT and netfilter DNAT.
|
||||
&iproute2; NAT and netfilter DNAT.
|
||||
Less common (and possibly less desirable) one can use port redirection
|
||||
tools. Depending on which tool is employed,
|
||||
different characteristics of a packet can trigger the address
|
||||
|
|
@ -146,7 +146,7 @@
|
|||
</para>
|
||||
<para>
|
||||
The simplest form of NAT under linux is
|
||||
<link linkend="nat-stateless"><command>iproute2</command> NAT</link>.
|
||||
<link linkend="nat-stateless">&iproute2; NAT</link>.
|
||||
This type of NAT requires two matching commands, one to cause the kernel
|
||||
to rewrite the inbound packets (<userinput>ip route add nat $NATIP
|
||||
via $REAL</userinput>)
|
||||
|
|
@ -155,7 +155,7 @@
|
|||
retain no state for connections. It will simply transform any packets
|
||||
passing through. By contrast, netfilter is capable of retaining state
|
||||
on connections passing through the router and selecting packets more
|
||||
granularly than is possible with only <command>iproute2</command> tools.
|
||||
granularly than is possible with only &iproute2; tools.
|
||||
</para>
|
||||
<para>
|
||||
Before the advent of the netfilter engine in the linux kernel, there
|
||||
|
|
@ -256,15 +256,15 @@
|
|||
NAT. It involves rewriting addresses passing through a
|
||||
routing device: outbound packets will undergo source address rewriting
|
||||
and inbound packets will undergo destination address rewriting. The
|
||||
<command>iproute2</command> suite of tools provides the two commands
|
||||
&iproute2; suite of tools provides the two commands
|
||||
required to configure the kernel to perform network address translation
|
||||
on packets passing through the machine. This section will cover only
|
||||
stateless NAT, which can only be accomplished under linux with the
|
||||
<command>iproute2</command> tools, although it can be
|
||||
&iproute2; tools, although it can be
|
||||
<link linkend="ex-nat-dnat-full">simulated with netfilter</link>.
|
||||
</para>
|
||||
<para>
|
||||
Creating an <command>iproute2</command> NAT mapping has the side
|
||||
Creating an &iproute2; NAT mapping has the side
|
||||
effect of causing the kernel to answer ARP requests for the NAT IP.
|
||||
For more detail on ARP filtering, suppression and conditional ARP, see
|
||||
<xref linkend="ch-ether"/>. This can be considered alternatively a
|
||||
|
|
@ -277,8 +277,8 @@
|
|||
</para>
|
||||
<para>
|
||||
Whether or not it is using a packet filter, a linux machine can perform
|
||||
NAT using the <command>iproute2</command> suite of tools. This chapter
|
||||
will document the use of <command>iproute2</command> tools for NAT with
|
||||
NAT using the &iproute2; suite of tools. This chapter
|
||||
will document the use of &iproute2; tools for NAT with
|
||||
<link linkend="nat-stateless-simple">a simple example</link> and
|
||||
<link linkend="nat-stateless-howto">an explanation of the required
|
||||
commands</link>, then an example of
|
||||
|
|
@ -467,7 +467,7 @@
|
|||
</para>
|
||||
</section>
|
||||
<section id="nat-stateless-rpdb">
|
||||
<title><command>iproute2</command> NAT with Multiple Private
|
||||
<title>&iproute2; NAT with Multiple Private
|
||||
Networks</title>
|
||||
<para>
|
||||
Naturally, NAT introduces a complexity to the network in which it is
|
||||
|
|
@ -550,7 +550,7 @@
|
|||
</section>
|
||||
</section>
|
||||
<section id="nat-stateless-pf-interaction">
|
||||
<title>Using a packet filter with <command>iproute2</command> NAT</title>
|
||||
<title>Using a packet filter with &iproute2; NAT</title>
|
||||
<para>
|
||||
Because NAT rewrites the packet as it passes through your linux box,
|
||||
packet filtering can become complex. With attentiveness to the
|
||||
|
|
@ -574,11 +574,11 @@
|
|||
<para>
|
||||
Let's examine the IP addresses on a packet traversing each of the input,
|
||||
forward and output chains in an <command>ipchains</command>
|
||||
installation as it is operated upon by the <command>iproute2</command>
|
||||
installation as it is operated upon by the &iproute2;
|
||||
NAT code.
|
||||
</para>
|
||||
<table id="tb-nat-pf-ipchains">
|
||||
<title>Filtering an <command>iproute2</command> NAT packet with
|
||||
<title>Filtering an &iproute2; NAT packet with
|
||||
<command>ipchains</command></title>
|
||||
<tgroup cols="3" align="center" colsep="1" rowsep="1">
|
||||
<colspec colname="c1"/>
|
||||
|
|
@ -733,10 +733,10 @@
|
|||
<para>
|
||||
These rules are the minimum set of <command>ipchains</command> rules
|
||||
needed to support a NAT'd TCP service. This concludes our discussion of
|
||||
publishing a service to the world with <command>iproute2</command> based
|
||||
publishing a service to the world with &iproute2; based
|
||||
NAT and protecting the service with <command>ipchains</command>. As you
|
||||
can see, the complexity of supporting NAT with
|
||||
<command>iproute2</command> can be substantial, which is why we'll
|
||||
&iproute2; can be substantial, which is why we'll
|
||||
examine the benefits of inbound NAT (DNAT) with netfilter in the next
|
||||
section.
|
||||
</para>
|
||||
|
|
@ -756,7 +756,7 @@
|
|||
<para>
|
||||
In a devilishly subtle difference, netfilter DNAT does not cause the
|
||||
kernel to answer ARP requests for the NAT IP, where
|
||||
<command>iproute2</command> NAT automatically begins answering ARP
|
||||
&iproute2; NAT automatically begins answering ARP
|
||||
requests for the NAT IP. If the NAT IP is in a locally
|
||||
</para>
|
||||
<example id="ex-nat-dnat-all">
|
||||
|
|
@ -799,7 +799,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Full network address translation, as performed with
|
||||
<command>iproute2</command> can be simulated with both netfilter
|
||||
&iproute2; can be simulated with both netfilter
|
||||
SNAT and DNAT, with the potential benefit (and attendent resource
|
||||
consumption) of connection tracking.
|
||||
</para>
|
||||
|
|
@ -842,7 +842,7 @@
|
|||
</para>
|
||||
<para>
|
||||
PAT address translation has one important benefit over NAT (with the
|
||||
<command>iproute2</command> tools). Let's assume that you have only
|
||||
&iproute2; tools). Let's assume that you have only
|
||||
five public IP addresses for which you have paid dearly. Additionally,
|
||||
let's assume that you want to run services on standard ports. You had
|
||||
hoped to connect four SMTP servers, two SSH servers and five HTTP servers.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@
|
|||
</para>
|
||||
<para>
|
||||
PAT address translation has one important benefit over NAT (with the
|
||||
<command>iproute2</command> tools). Let's assume that you have only
|
||||
&iproute2; tools). Let's assume that you have only
|
||||
five public IP addresses for which you have paid dearly. Additionally,
|
||||
let's assume that you want to run services on standard ports. You had
|
||||
hoped to connect four SMTP servers, two SSH servers and five HTTP servers.
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@
|
|||
<link linkend="ether-arp-proxy-kernel">enable it in your 2.4
|
||||
kernel</link>. If you require more control than afforded by the kernel
|
||||
proxy ARP functionality and you wish to recompile
|
||||
<command>iproute2</command> and your kernel, you can use the
|
||||
<command>iproute2</command> extension,
|
||||
&iproute2; and your kernel, you can use the
|
||||
&iproute2; extension,
|
||||
<link linkend="ether-arp-filtering"><command>ip arp</command></link>.
|
||||
Otherwise, you might try this script.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -241,7 +241,7 @@ Received 2 response(s)</computeroutput>
|
|||
<section id="tools-ip-link">
|
||||
<title><command>ip link</command></title>
|
||||
<para>
|
||||
Part of the <command>iproute2</command> suite, <command>ip
|
||||
Part of the &iproute2; suite, <command>ip
|
||||
link</command> provides the ability to
|
||||
<link linkend="tools-ip-link-show">display link layer
|
||||
information</link>,
|
||||
|
|
@ -397,7 +397,7 @@ Received 2 response(s)</computeroutput>
|
|||
<para>
|
||||
Users who would like more information about flags on link layer
|
||||
devices and their meanings should refer to Alexey Kuznetsov's
|
||||
excellent <command>iproute2</command> reference. See the
|
||||
excellent &iproute2; reference. See the
|
||||
<xref linkend="links-iproute2"/> for further links.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -518,9 +518,9 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
<title>Using <command>ip link set</command> to change the MTU</title>
|
||||
<para>
|
||||
Changing the MTU on an interface is a classical example of an
|
||||
operation which, prior to the arrival of <command>iproute2</command>
|
||||
operation which, prior to the arrival of &iproute2;
|
||||
one could only accomplish with the <command>ifconfig</command>
|
||||
command. Since <command>iproute2</command> has separate
|
||||
command. Since &iproute2; has separate
|
||||
utilities for managing the link layer, addressing, routing, and
|
||||
other IP-related objects, it becomes clear even with
|
||||
the command-line utilities that the MTU is really a function of
|
||||
|
|
@ -590,7 +590,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
<para>
|
||||
Alternatively, one can set the broadcast address to a different
|
||||
value, which as Alexey remarks as an aside in the
|
||||
<command>iproute2</command> manual will "break networking."
|
||||
&iproute2; manual will "break networking."
|
||||
Changing the ethernet broadcast address implies that no
|
||||
conventionally configured host will answer broadcast ARP frames
|
||||
transmitted onto the ethernet. Since conventional ARP requests
|
||||
|
|
@ -671,7 +671,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
-->
|
||||
|
||||
<para>
|
||||
Part of the <command>iproute2</command> command suite, <command>ip
|
||||
Part of the &iproute2; command suite, <command>ip
|
||||
neighbor</command> provides a command line interface to
|
||||
<link linkend="ex-tools-ip-neighbor-show">display the neighbor table
|
||||
(ARP cache)</link>,
|
||||
|
|
@ -681,7 +681,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
entries</link> and
|
||||
<link linkend="ex-tools-ip-neighbor-flush">remove a large number of
|
||||
entries</link>.
|
||||
For peculiarities and commonalities of the <command>iproute2</command>
|
||||
For peculiarities and commonalities of the &iproute2;
|
||||
tools, refer to
|
||||
<xref linkend="tools-iproute2-remarks"/>.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
traditional utility for IP management. We will also examine the newer
|
||||
and more flexible <link
|
||||
linkend="tools-ip-address"><command>ip address</command></link>, a key
|
||||
part of the <command>iproute2</command> package.
|
||||
part of the &iproute2; package.
|
||||
</para>
|
||||
<section id="tools-ifconfig">
|
||||
<title><command>ifconfig</command></title>
|
||||
|
|
@ -348,7 +348,7 @@ lo Link encap:Local Loopback
|
|||
<section id="tools-ip-address">
|
||||
<title><command>ip address</command></title>
|
||||
<para>
|
||||
Part of the <command>iproute2</command> suite, <command>ip
|
||||
Part of the &iproute2; suite, <command>ip
|
||||
address</command> can
|
||||
<link linkend="tools-ip-address-show">list the IP addresses</link>
|
||||
affiliated with
|
||||
|
|
@ -601,7 +601,7 @@ lo Link encap:Local Loopback
|
|||
As you can see, the <command>ip address</command> utility provides a
|
||||
wealth of information and a great deal of control over the IPs
|
||||
associated with each device. For more detailed information about
|
||||
the <command>iproute2</command> package and included tools, see
|
||||
the &iproute2; package and included tools, see
|
||||
<xref linkend="links-iproute2"/>.
|
||||
</para>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@
|
|||
on to the increasingly used <link linkend="tools-ip-route"><command>ip
|
||||
route</command></link> and <link linkend="tools-ip-rule"><command>ip
|
||||
rule</command></link> tools which are part of the
|
||||
<command>iproute2</command> package.
|
||||
&iproute2; package.
|
||||
</para>
|
||||
<section id="tools-route">
|
||||
<title><command>route</command></title>
|
||||
|
|
@ -631,7 +631,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
<section id="tools-ip-route">
|
||||
<title><command>ip route</command></title>
|
||||
<para>
|
||||
Another part of the <command>iproute2</command> suite of tools for IP
|
||||
Another part of the &iproute2; suite of tools for IP
|
||||
management, <command>ip route</command> provides management tools for
|
||||
manipulating any of the routing tables. Operations
|
||||
include
|
||||
|
|
@ -655,7 +655,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
the <option>table</option> parameter.
|
||||
</para>
|
||||
<para>
|
||||
Fortunately, as mentioned earlier, the <command>iproute2</command>
|
||||
Fortunately, as mentioned earlier, the &iproute2;
|
||||
suite of tools does not rely on DNS for any operation so, the
|
||||
ubiquitous <option>-n</option> switch in previous examples will not be
|
||||
required in any example here.
|
||||
|
|
@ -1108,7 +1108,7 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
</para>
|
||||
<para>
|
||||
There are other options to the <command>ip route add</command>
|
||||
documented in Alexey's thorough <command>iproute2</command>
|
||||
documented in Alexey's thorough &iproute2;
|
||||
documentation. For further research, I'd suggested acquiring and
|
||||
reading this manual.
|
||||
</para>
|
||||
|
|
@ -1144,7 +1144,7 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
here to learn a bit more about how to set up NAT in your network,
|
||||
then you should know that the <command>ip route add nat</command> is
|
||||
only half of the solution. You must understand that performing NAT
|
||||
with <command>iproute2</command> involves one component to rewrite
|
||||
with &iproute2; involves one component to rewrite
|
||||
the inbound packet (<command>ip route add nat</command>), and
|
||||
another command to rewrite the outbound packet (<link
|
||||
linkend="tools-ip-rule-add-nat"><command>ip rule add
|
||||
|
|
@ -1154,8 +1154,8 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
</para>
|
||||
<para>
|
||||
Alexey documents clearly in the appendix to the
|
||||
<command>iproute2</command> manual that the NAT provided by the
|
||||
<command>iproute2</command> suite is stateless. This is distinctly
|
||||
&iproute2; manual that the NAT provided by the
|
||||
&iproute2; suite is stateless. This is distinctly
|
||||
unlike NAT with netfilter. Refer to <xref linkend="nat-dnat"/> and
|
||||
<xref linkend="state-conntrack"/>
|
||||
for a better look at the connection tracking and network address
|
||||
|
|
@ -1164,9 +1164,9 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
<para>
|
||||
The <command>ip route add nat</command> command is used to rewrite
|
||||
the destination address of a packet from one IP or range to another
|
||||
IP or range. The <command>iproute2</command> tools can only operate
|
||||
IP or range. The &iproute2; tools can only operate
|
||||
on the entire IP packet. There is no provision directly within the
|
||||
<command>iproute2</command> suite to support conditional rewriting
|
||||
&iproute2; suite to support conditional rewriting
|
||||
based on the destination port of a UDP datagram or TCP segment.
|
||||
It's the whole packet, every packet, and nothing but the packet
|
||||
<footnote>
|
||||
|
|
@ -1198,7 +1198,7 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
<xref linkend="nat-stateless-pf-interaction"/>.
|
||||
</para>
|
||||
<para>
|
||||
Not only can <command>iproute2</command> support network address
|
||||
Not only can &iproute2; support network address
|
||||
translation for single IPs, but also for entire network ranges. The
|
||||
syntax is substantially similar to the syntax above, but uses a
|
||||
CIDR network address instead of a single IP.
|
||||
|
|
@ -1222,7 +1222,7 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
</para>
|
||||
<para>
|
||||
Again, this is only one half of the story for NAT with
|
||||
<command>iproute2</command>. Please be certain to read
|
||||
&iproute2;. Please be certain to read
|
||||
the section below for usage information on <link
|
||||
linkend="tools-ip-rule-add-nat"><command>ip rule add
|
||||
nat</command></link>, in addition to <xref linkend="ch-nat"/> which
|
||||
|
|
@ -1491,14 +1491,14 @@ local 127.0.0.1 from 127.0.0.1 dev lo
|
|||
<section id="tools-ip-rule">
|
||||
<title><command>ip rule</command></title>
|
||||
<para>
|
||||
Another part of the <command>iproute2</command> software package,
|
||||
Another part of the &iproute2; software package,
|
||||
<command>ip rule</command> is the single tool for manipulating the
|
||||
routing policy database under linux (RPDB). For a fuller discussion
|
||||
of the RPDB, see <xref linkend="adv-rpdb"/>. The RPDB can be <link
|
||||
linkend="tools-ip-rule-show">displayed with <command>ip rule
|
||||
show</command></link>. Particular rules can be added and removed with
|
||||
(predictably, if you have been reading the sections on the other
|
||||
<command>iproute2</command> tools) <link
|
||||
&iproute2; tools) <link
|
||||
linkend="tools-ip-rule-add"><command>ip rule add</command></link>
|
||||
command and the <link
|
||||
linkend="tools-ip-rule-add"><command>ip rule del</command></link>
|
||||
|
|
@ -1683,7 +1683,7 @@ local 127.0.0.1 from 127.0.0.1 dev lo
|
|||
<title><command>ip rule add nat</command></title>
|
||||
<para>
|
||||
As discussed more thoroughly in <xref linkend="ch-nat"/>, this is the
|
||||
other half of <command>iproute2</command> supported network address
|
||||
other half of &iproute2; supported network address
|
||||
translation. The two components are <link
|
||||
linkend="tools-ip-route-add-nat"><command>ip route add
|
||||
nat</command></link> and <command>ip rule add nat</command>.
|
||||
|
|
@ -1739,7 +1739,7 @@ local 127.0.0.1 from 127.0.0.1 dev lo
|
|||
<section id="tools-ip-rule-del">
|
||||
<title><command>ip rule del</command></title>
|
||||
<para>
|
||||
Naturally, no <command>iproute2</command> tool would be complete
|
||||
Naturally, no &iproute2; tool would be complete
|
||||
without the ability to undo what has been done. With <command>ip
|
||||
rule del</command>, individual rules can be removed from the RPDB.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -80,24 +80,24 @@
|
|||
|
||||
</section>
|
||||
<section id="tools-iproute2-remarks">
|
||||
<title>Some general remarks about <command>iproute2</command>tools</title>
|
||||
<title>Some general remarks about &iproute2;tools</title>
|
||||
<para>
|
||||
This is a meant to be a collected set of thoughts which don't fit
|
||||
anyplace else about the <command>iproute2</command> tools. If you are
|
||||
anyplace else about the &iproute2; tools. If you are
|
||||
reading this in search of more details about the
|
||||
<command>iproute2</command> tools, you should run (not walk) to your
|
||||
&iproute2; tools, you should run (not walk) to your
|
||||
nearest command line, and execute the following command:
|
||||
<userinput>bash -c ' gv $( locate ip-cref.ps ) '</userinput>.
|
||||
</para>
|
||||
<para>
|
||||
In any case, I suggest that the reader consult the
|
||||
documentation which comes with the <command>iproute2</command>
|
||||
documentation which comes with the &iproute2;
|
||||
package for canonical answers.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The <command>iproute2</command> suite exposes all of the
|
||||
The &iproute2; suite exposes all of the
|
||||
networking functionality of the linux kernel where the venerable
|
||||
tools
|
||||
(<link linkend="tools-ifconfig"><command>ifconfig</command></link>,
|
||||
|
|
@ -107,7 +107,7 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Each of the <command>iproute2</command> object names can be
|
||||
Each of the &iproute2; object names can be
|
||||
shortened to the shortest unique set of characters. This means
|
||||
that <command>ip route show</command> can be abbreviated
|
||||
<command>ip ro s</command> and <command>ip rule show</command> can
|
||||
|
|
@ -116,7 +116,7 @@
|
|||
convenient shortcuts on the command line are often confusing in
|
||||
documentation. For this reason, I have preferred examples
|
||||
featuring the complete object names and action verbs. Note also
|
||||
below that <command>iproute2</command> accepts not only
|
||||
below that &iproute2; accepts not only
|
||||
abbreviations but also synonyms as described in
|
||||
<xref linkend="tb-tools-iproute2-remarks"/>.
|
||||
</para>
|
||||
|
|
@ -124,25 +124,25 @@
|
|||
<listitem>
|
||||
<para>
|
||||
There are some syntactic synonyms available within the
|
||||
<command>iproute2</command> package. See this
|
||||
&iproute2; package. See this
|
||||
<xref linkend="tb-tools-iproute2-remarks"/> for a complete list
|
||||
of synonyms.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Because the <command>iproute2</command> command suite is under
|
||||
Because the &iproute2; command suite is under
|
||||
development, there may be slight differences between the output
|
||||
described in this documentation and that of your release of
|
||||
<command>iproute2</command>. I have tried to focus on the
|
||||
overwhelmingly common uses of the <command>iproute2</command>
|
||||
&iproute2;. I have tried to focus on the
|
||||
overwhelmingly common uses of the &iproute2;
|
||||
tools rather than the ones which are under active development, and
|
||||
are subject to syntactic changes or new output presentations.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
There are extensions to the <command>iproute2</command> command
|
||||
There are extensions to the &iproute2; command
|
||||
suite, which can alter the sets of objects or syntax
|
||||
available for manipulation and inspection. Where these are
|
||||
covered in detail in this documentation, they will be relegated to
|
||||
|
|
@ -155,13 +155,13 @@
|
|||
<para>
|
||||
</para>
|
||||
<para>
|
||||
There are some common synonyms in <command>iproute2</command> syntax.
|
||||
There are some common synonyms in &iproute2; syntax.
|
||||
Outlined below in <xref linkend="tb-tools-iproute2-remarks"/> is a list
|
||||
of the common synonyms. Note, that these synonyms are available in
|
||||
addition to the abbreviations indicated above.
|
||||
</para>
|
||||
<table id="tb-tools-iproute2-remarks">
|
||||
<title><command>iproute2</command> Synonyms</title>
|
||||
<title>&iproute2; Synonyms</title>
|
||||
<tgroup cols="2" align="center" colsep="1" rowsep="1">
|
||||
<thead>
|
||||
<row>
|
||||
|
|
@ -192,13 +192,13 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
<para>
|
||||
Because the <command>iproute2</command> suite of tools is so tightly
|
||||
Because the &iproute2; suite of tools is so tightly
|
||||
integrated with linux, it is not available for other operating
|
||||
systems. This is at once its strength and weakness. For users
|
||||
contemplating linux for the first time, <command>ifconfig</command>,
|
||||
<command>netstat</command>, and <command>route</command> are familiar
|
||||
and they feel intuitive. More experienced users and control freaks
|
||||
will find the <command>iproute2</command> tools attractive and perhaps
|
||||
will find the &iproute2; tools attractive and perhaps
|
||||
indispensable.
|
||||
</para>
|
||||
</section>
|
||||
|
|
|
|||
Loading…
Reference in New Issue