mirror of https://github.com/tLDP/LDP
Fixing "ethernet" which should be "Ethernet".
This commit is contained in:
parent
6dac742743
commit
177919277b
|
@ -25,6 +25,14 @@
|
|||
</section>
|
||||
<section id="adv-proxy-arp">
|
||||
<title>Breaking a network in two with proxy ARP</title>
|
||||
<indexterm zone="adv-proxy-arp">
|
||||
<primary>proxy ARP</primary>
|
||||
<see>ARP, proxy</see>
|
||||
</indexterm>
|
||||
<indexterm zone="adv-proxy-arp">
|
||||
<primary>ARP, proxy</primary>
|
||||
<secondary>with <command>arp</command></secondary>
|
||||
</indexterm>
|
||||
<para>
|
||||
Proxy ARP is a technique for splitting an IP network into two
|
||||
separate segments. Hosts on one segment can only reach hosts in the
|
||||
|
@ -36,7 +44,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Occasionally, this technique is incorrectly called proxy ARP bridging.
|
||||
An ethernet bridge operates on frames and a router operates on packets.
|
||||
An Ethernet bridge operates on frames and a router operates on packets.
|
||||
The proxy ARP router should have routes to all hosts on both segments.
|
||||
Once the router can reach all locally connected destinations via the
|
||||
correct interfaces, you can begin to configure the proxy ARP
|
||||
|
@ -65,7 +73,7 @@
|
|||
subnet (maybe as small as a /30 network, with two usable IPs) makes an
|
||||
excellent sequestered location for a host which requires more
|
||||
protection or even, a generally untrusted host which shouldn't have
|
||||
complete access to the ethernet to which the other machines connect.
|
||||
complete access to the Ethernet to which the other machines connect.
|
||||
</para>
|
||||
<para>
|
||||
For a practical example of this, see the relationship between the
|
||||
|
@ -101,7 +109,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
&masq-gw; replies that &isolde; should send packets for
|
||||
192.168.100.1 to its ethernet address, 00:80:c8:f8:5c:71
|
||||
192.168.100.1 to its Ethernet address, 00:80:c8:f8:5c:71
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -118,7 +126,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
&service-router; replies that &masq-gw; should send packets for
|
||||
192.168.100.1 to its ethernet address, 00:c0:7b:7d:00:c8
|
||||
192.168.100.1 to its Ethernet address, 00:c0:7b:7d:00:c8
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -136,7 +144,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
&masq-gw; replies that &service-router; should send packets for
|
||||
192.168.100.17 to its ethernet address, 00:80:c8:f8:5c:74
|
||||
192.168.100.17 to its Ethernet address, 00:80:c8:f8:5c:74
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -153,7 +161,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
&isolde; replies that &masq-gw; should send packets for
|
||||
192.168.100.17 to its ethernet address, 00:80:c8:e8:4b:8e
|
||||
192.168.100.17 to its Ethernet address, 00:80:c8:e8:4b:8e
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -202,9 +210,9 @@
|
|||
</para>
|
||||
</section>
|
||||
<section id="adv-multi-ethernet">
|
||||
<title>Multiple connections to the same ethernet</title>
|
||||
<title>Multiple connections to the same Ethernet</title>
|
||||
<para>
|
||||
Assume a machine has multiple connections to the same ethernet segment,
|
||||
Assume a machine has multiple connections to the same Ethernet segment,
|
||||
and has individual IPs bound to each interface. A peculiar feature of
|
||||
linux is its willingness to respond to ARP requests for any IP bound
|
||||
to any interface. This can lead to ARP flux, a situation where a
|
||||
|
|
|
@ -230,7 +230,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
</example>
|
||||
<para>
|
||||
For the moment, ignore the loopback interface (lo) and concentrate
|
||||
on the ethernet interface. Examine the output of the
|
||||
on the Ethernet interface. Examine the output of the
|
||||
<command>ifconfig</command> command. We can learn a great deal about
|
||||
the IP network to which we are connected simply by reading the
|
||||
<command>ifconfig</command> output. For a thorough discussion of
|
||||
|
@ -250,7 +250,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
<para>
|
||||
Because &tristan; will
|
||||
advertise that it accepts packets with a destination address of
|
||||
192.168.99.35, any frames (packets) appearing on the ethernet
|
||||
192.168.99.35, any frames (packets) appearing on the Ethernet
|
||||
bound for 192.168.99.35 will reach &tristan;. The process of
|
||||
communicating the ownership of an IP address is called ARP. Read
|
||||
<xref linkend="ether-arp-overview"/> for a complete discussion of
|
||||
|
@ -282,11 +282,11 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
and broadcasting as "chatty network traffic".
|
||||
</para>
|
||||
<para>
|
||||
Broadcast techniques are used at the ethernet layer and the IP layer, so
|
||||
the cautious person talks about ethernet broadcasts or IP broadcast.
|
||||
Broadcast techniques are used at the Ethernet layer and the IP layer, so
|
||||
the cautious person talks about Ethernet broadcasts or IP broadcast.
|
||||
Refer to
|
||||
<xref linkend="ether-arp-overview"/>, for more information on a common
|
||||
use of broadcast ethernet frames.
|
||||
use of broadcast Ethernet frames.
|
||||
</para>
|
||||
<para>
|
||||
IP Broadcast techniques can be used to share information with all
|
||||
|
@ -336,8 +336,8 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
falls inside the address space 192.168.99.0/24. We also note that
|
||||
the machine &tristan;
|
||||
will route packets bound for 192.168.99.0/24 directly onto the
|
||||
ethernet attached to eth0. This line in the routing table
|
||||
identifies a network available on the ethernet attached to eth0
|
||||
Ethernet attached to eth0. This line in the routing table
|
||||
identifies a network available on the Ethernet attached to eth0
|
||||
("Iface") by its network address ("Destination") and size ("Genmask").
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -430,7 +430,7 @@ round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms</computeroutput>
|
|||
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
|
||||
before hitting the Ethernet, &tristan; adds its IP to the
|
||||
list of IPs in the option field in the header.
|
||||
</simpara>
|
||||
</callout>
|
||||
|
@ -528,7 +528,7 @@ round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms</computeroutput>
|
|||
</para>
|
||||
<para>
|
||||
The absence of a static route has caused two extra packets to be
|
||||
generated on the ethernet for no benefit. Not only that, but
|
||||
generated on the Ethernet for no benefit. Not only that, but
|
||||
&tristan; will eventually expire the temporary route entry
|
||||
<footnote>
|
||||
<para>
|
||||
|
@ -606,7 +606,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
join the LAN.
|
||||
</para>
|
||||
<para>
|
||||
Once the machine is booted and connected to the ethernet, it's
|
||||
Once the machine is booted and connected to the Ethernet, it's
|
||||
ready for IP reconfiguration. In order to join an
|
||||
IP network, the following information is required. Refer to the
|
||||
<link linkend="example-network-netmap">network map and
|
||||
|
@ -757,7 +757,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
interface after configuration to verify settings.
|
||||
</para>
|
||||
<example id="ex-basic-ifconfig-up">
|
||||
<title>Bringing up an ethernet interface with <command>ifconfig</command></title>
|
||||
<title>Bringing up an Ethernet interface with <command>ifconfig</command></title>
|
||||
<programlisting>
|
||||
<prompt>[root@morgan]# </prompt><userinput>ifconfig eth0 192.168.99.14 netmask 255.255.255.0 up</userinput>
|
||||
<prompt>[root@morgan]# </prompt><userinput>ifconfig eth0</userinput>
|
||||
|
@ -844,9 +844,9 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
network, and the use of
|
||||
<link linkend="tools-ifconfig"><command>ifconfig</command></link> and
|
||||
<link linkend="tools-route"><command>route</command></link> it's
|
||||
simple to readdress a machine on just about any ethernet you can
|
||||
simple to readdress a machine on just about any Ethernet you can
|
||||
attach to. The benefits of familiarity with these commands extend to
|
||||
non-ethernet IP networks as well, because these commands operate on the
|
||||
non-Ethernet IP networks as well, because these commands operate on the
|
||||
IP layer, independent of the link layer.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -971,8 +971,8 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
Communicate Using IP</title>
|
||||
<listitem>
|
||||
<para>
|
||||
Each host must have a good connection to the ethernet. Verify a
|
||||
good connection to the ethernet with <command>mii-tool</command>,
|
||||
Each host must have a good connection to the Ethernet. Verify a
|
||||
good connection to the Ethernet with <command>mii-tool</command>,
|
||||
documented in
|
||||
<xref linkend="tools-mii-tool"/>.
|
||||
</para>
|
||||
|
|
|
@ -43,8 +43,8 @@
|
|||
<para>
|
||||
This guide provides an overview of many of the tools available
|
||||
for IP network administration of the linux operating system,
|
||||
kernels in the 2.2 and 2.4 series. It covers ethernet, ARP,
|
||||
routing, NAT, and other topics central to the management of IP
|
||||
kernels in the 2.2 and 2.4 series. It covers Ethernet, ARP,
|
||||
IP routing, NAT, and other topics central to the management of IP
|
||||
networks.
|
||||
</para>
|
||||
</abstract>
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
Bridging, once the realm of hardware devices, can also be performed by a
|
||||
linux machine. Along with bridging comes the capability of filtering
|
||||
and transforming frames (or even higher layer protocols) via hooks
|
||||
at the ethernet layer with the <command>ebtables</command> and
|
||||
at the Ethernet layer with the <command>ebtables</command> and
|
||||
<command>iptables</command> commands.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
@ -6,17 +6,17 @@
|
|||
<primary>Ethernet</primary>
|
||||
</indexterm>
|
||||
<para>
|
||||
The most common link layer network in use today is ethernet. Although
|
||||
there are several common speeds of ethernet devices, they function
|
||||
The most common link layer network in use today is Ethernet. Although
|
||||
there are several common speeds of Ethernet devices, they function
|
||||
identically with regard to higher layer protocols. As this documentation
|
||||
focusses on higher layer protocols (IP), some fine distinctions about
|
||||
different types of ethernet will be overlooked in favor of depicting the
|
||||
uniform manner in which IP networks overlay ethernets.
|
||||
different types of Ethernet will be overlooked in favor of depicting the
|
||||
uniform manner in which IP networks overlay Ethernets.
|
||||
</para>
|
||||
<para>
|
||||
Address Resolution Protocol provides the necessary mapping between link
|
||||
layer
|
||||
addresses and IP addresses for machines connected to ethernets. Linux
|
||||
addresses and IP addresses for machines connected to Ethernets. Linux
|
||||
offers control of ARP requests and replies via several
|
||||
not-well-known <filename>/proc</filename> interfaces;
|
||||
<filename>net/ipv4/conf/$DEV/proxy_arp</filename>,
|
||||
|
@ -57,16 +57,16 @@
|
|||
</para>
|
||||
<para>
|
||||
ARP defines the exchanges between network interfaces connected to an
|
||||
ethernet media segment in order to map an IP address to a link layer
|
||||
Ethernet media segment in order to map an IP address to a link layer
|
||||
address on demand. Link layer addresses are hardware addresses (although
|
||||
<link linkend="tools-ip-link-set-address">they are not immutable</link>)
|
||||
on ethernet cards and IP addresses are logical addresses
|
||||
assigned to machines attached to the ethernet. Subsequently in this
|
||||
on Ethernet cards and IP addresses are logical addresses
|
||||
assigned to machines attached to the Ethernet. Subsequently in this
|
||||
chapter, link layer addresses may be known by many different names:
|
||||
ethernet addresses, Media Access Control (MAC) addresses, and even
|
||||
Ethernet addresses, Media Access Control (MAC) addresses, and even
|
||||
hardware addresses.
|
||||
Disputably, the correct term from the kernel's perspective is "link
|
||||
layer address" because this address can be changed (on many ethernet
|
||||
layer address" because this address can be changed (on many Ethernet
|
||||
cards) via command line tools. Nevertheless, these terms are not
|
||||
realistically distinct and can be used interchangeably.
|
||||
</para>
|
||||
|
@ -74,38 +74,38 @@
|
|||
<title>Overview of Address Resolution Protocol</title>
|
||||
<para>
|
||||
Address Resolution Protocol (ARP) exists solely to glue together the
|
||||
IP and ethernet networking layers. Since networking hardware
|
||||
such as switches, hubs, and bridges operate on ethernet frames, they
|
||||
IP and Ethernet networking layers. Since networking hardware
|
||||
such as switches, hubs, and bridges operate on Ethernet frames, they
|
||||
are unaware of the higher layer data carried by these frames
|
||||
<footnote>
|
||||
<para>
|
||||
Some networking equipment vendors have built devices which are
|
||||
sold as high performance switches and are capable of performing
|
||||
operations on higher layer contents of ethernet frames.
|
||||
operations on higher layer contents of Ethernet frames.
|
||||
Typically, however, a switching device is not capable of
|
||||
operating on IP packets.
|
||||
</para>
|
||||
</footnote>.
|
||||
Similarly, IP layer devices, operating on IP packets need to be able
|
||||
to transmit their IP data on ethernets. ARP defines the
|
||||
to transmit their IP data on Ethernets. ARP defines the
|
||||
conversation by which IP capable hosts can exchange mappings of
|
||||
their ethernet and IP addressing.
|
||||
their Ethernet and IP addressing.
|
||||
</para>
|
||||
<indexterm zone="ether-arp-request">
|
||||
<primary>ARP request</primary>
|
||||
</indexterm>
|
||||
<anchor id="ether-arp-request"/>
|
||||
<para>
|
||||
ARP is used to locate the ethernet address associated with a desired IP
|
||||
ARP is used to locate the Ethernet address associated with a desired IP
|
||||
address. When a machine has a packet bound for another IP on a locally
|
||||
connected ethernet network, it will send a broadcast ethernet frame
|
||||
containing an ARP request onto the ethernet. All machines with the same
|
||||
ethernet broadcast address will receive this packet
|
||||
connected Ethernet network, it will send a broadcast Ethernet frame
|
||||
containing an ARP request onto the Ethernet. All machines with the same
|
||||
Ethernet broadcast address will receive this packet
|
||||
<footnote>
|
||||
<para>
|
||||
The kernel uses the ethernet broadcast address configured on the
|
||||
The kernel uses the Ethernet broadcast address configured on the
|
||||
link layer device. This is rarely anything but ff:ff:ff:ff:ff:ff.
|
||||
In the extraordinary event that this is not the ethernet broadcast
|
||||
In the extraordinary event that this is not the Ethernet broadcast
|
||||
address in your network, see
|
||||
<xref linkend="tools-ip-link-set-address"/>.
|
||||
</para>
|
||||
|
@ -136,7 +136,7 @@
|
|||
<para>
|
||||
In <xref linkend="ex-basic-ping"/>, we used <command>ping</command> to
|
||||
test reachability of &masq-gw;. Using a packet sniffer to capture
|
||||
the sequence of packets on the ethernet as a result of &tristan;'s
|
||||
the sequence of packets on the Ethernet as a result of &tristan;'s
|
||||
attempt to ping, provides an example of ARP <foreignphrase>in flagrante
|
||||
delicto</foreignphrase>. Consult the
|
||||
<link linkend="example-network-netmap">example network map</link> for a
|
||||
|
@ -146,7 +146,7 @@
|
|||
<para>
|
||||
This is an archetypal conversation between two
|
||||
computers exchanging relevant hardware addressing in order that they
|
||||
can pass IP packets, and is comprised of two ethernet frames.
|
||||
can pass IP packets, and is comprised of two Ethernet frames.
|
||||
</para>
|
||||
<indexterm zone="ex-ether-arp-overview">
|
||||
<primary><command>arping</command></primary>
|
||||
|
@ -179,8 +179,8 @@
|
|||
<primary>ARP request</primary>
|
||||
</indexterm>
|
||||
<simpara>
|
||||
This broadcast ethernet frame, identifiable by the
|
||||
destination ethernet address with all bits set
|
||||
This broadcast Ethernet frame, identifiable by the
|
||||
destination Ethernet address with all bits set
|
||||
(ff:ff:ff:ff:ff:ff) contains an ARP request from &tristan;
|
||||
for IP address 192.168.99.254. The request includes the
|
||||
source link layer address and the IP address of
|
||||
|
@ -204,7 +204,7 @@
|
|||
<simpara>
|
||||
The machine which initiated the ARP request (&tristan;)
|
||||
now has enough information to encapsulate an IP packet in
|
||||
an ethernet frame and forward it to the link layer address
|
||||
an Ethernet frame and forward it to the link layer address
|
||||
of the recipient (00:80:c8:f8:5c:73).
|
||||
</simpara>
|
||||
</callout>
|
||||
|
@ -223,8 +223,8 @@
|
|||
</calloutlist>
|
||||
</example>
|
||||
<para>
|
||||
This example is the commonest example of ARP traffic on an ethernet.
|
||||
In summary, an ARP request is transmitted in a broadcast ethernet
|
||||
This example is the commonest example of ARP traffic on an Ethernet.
|
||||
In summary, an ARP request is transmitted in a broadcast Ethernet
|
||||
frame. The ARP reply is a unicast response, containing the desired
|
||||
information, sent to the requestor's link layer address.
|
||||
</para>
|
||||
|
@ -296,7 +296,7 @@
|
|||
</programlisting>
|
||||
</example>
|
||||
<para>
|
||||
These two uses of <command>arping</command> can help diagnose ethernet
|
||||
These two uses of <command>arping</command> can help diagnose Ethernet
|
||||
and ARP problems--particularly hosts replying for addresses which do
|
||||
not belong to them.
|
||||
</para>
|
||||
|
@ -336,7 +336,7 @@ Received 1 response(s)
|
|||
<para>
|
||||
Address Resolution Protocol, which provides a method to connect
|
||||
physical network addresses with logical network addresses
|
||||
is a key element to the deployment of IP on ethernet networks.
|
||||
is a key element to the deployment of IP on Ethernet networks.
|
||||
</para>
|
||||
</section>
|
||||
<section id="ether-arp-cache">
|
||||
|
@ -406,7 +406,7 @@ Received 1 response(s)
|
|||
expiration of entries in the ARP cache.
|
||||
</para>
|
||||
<para>
|
||||
When a host is down or disconnected from the ethernet, there is a
|
||||
When a host is down or disconnected from the Ethernet, there is a
|
||||
period of time during which other hosts may have an ARP cache entry
|
||||
for the disconnected host. Any other machine may display a neighbor
|
||||
table with the link layer address of the recently disconnected host.
|
||||
|
@ -513,7 +513,7 @@ Received 1 response(s)
|
|||
<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
|
||||
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>
|
||||
|
@ -597,9 +597,9 @@ Received 1 response(s)
|
|||
<para>
|
||||
Complete ARP suppression is not difficult at all. ARP suppression can
|
||||
be accomplished under linux on a per-interface basis by setting the
|
||||
noarp flag on any ethernet interface.
|
||||
noarp flag on any Ethernet interface.
|
||||
Disabling ARP will require static neighbor table mappings
|
||||
for all hosts wishing to exchange packets across the ethernet.
|
||||
for all hosts wishing to exchange packets across the Ethernet.
|
||||
</para>
|
||||
<para>
|
||||
To suppress ARP on an interface simply use <command>ip
|
||||
|
@ -627,7 +627,7 @@ Received 1 response(s)
|
|||
When a linux box is connected to a network segment with multiple
|
||||
network cards, a potential problem with the link layer address
|
||||
to IP address mapping can occur.
|
||||
The machine may respond to ARP requests from both ethernet interfaces.
|
||||
The machine may respond to ARP requests from both Ethernet interfaces.
|
||||
On the machine creating the ARP request, these multiple answers can
|
||||
cause confusion, or worse yet, non-deterministic population
|
||||
of the ARP cache. Known as ARP flux
|
||||
|
@ -645,7 +645,7 @@ Received 1 response(s)
|
|||
</para>
|
||||
<para>
|
||||
This is a simple illustration of the problem in a network where a
|
||||
server has two ethernet adapters connected to the same media
|
||||
server has two Ethernet adapters connected to the same media
|
||||
segment. They need not have IP addresses in the same IP network for
|
||||
the ARP reply to be generated by each interface. Note the first
|
||||
two replies received in response to the ARP broadcast request.
|
||||
|
@ -710,12 +710,12 @@ Received 4 response(s)</computeroutput>
|
|||
determine the interface through which to send the
|
||||
reply, instead of the default behaviour
|
||||
(<link linkend="ex-ether-arp-flux">shown above</link>), replying
|
||||
from all ethernet interfaces which receive the request.
|
||||
from all Ethernet interfaces which receive the request.
|
||||
</para>
|
||||
<!--
|
||||
|
||||
FIXME; read the spec, why is this smart? Doesn't this mean
|
||||
using the informational data in the ethernet frame?
|
||||
using the informational data in the Ethernet frame?
|
||||
|
||||
-->
|
||||
<para>
|
||||
|
@ -963,7 +963,7 @@ Received 2 response(s)</computeroutput>
|
|||
</indexterm>
|
||||
<indexterm zone="ether-arp-proxy-mediumid">
|
||||
<primary><constant>ARP, proxy</constant></primary>
|
||||
<secondary>with kernel <constant>medium_id</constant></secondary>
|
||||
<secondary>with kernel</secondary>
|
||||
<tertiary><constant>medium_id</constant></tertiary>
|
||||
</indexterm>
|
||||
<para>
|
||||
|
@ -1031,7 +1031,7 @@ ALTER := [ src IP ] [ llsrc LLADDR ] [ lldst LLADDR ]</computeroutput>
|
|||
</section>
|
||||
</section>
|
||||
<section id="ether-vlan">
|
||||
<title>Connecting to an ethernet 802.1q VLAN</title>
|
||||
<title>Connecting to an Ethernet 802.1q VLAN</title>
|
||||
<indexterm zone="ether-vlan">
|
||||
<primary>VLAN</primary>
|
||||
</indexterm>
|
||||
|
@ -1039,7 +1039,7 @@ ALTER := [ src IP ] [ llsrc LLADDR ] [ lldst LLADDR ]</computeroutput>
|
|||
Virtual LANs are a way to take a single switch and subdivide it into
|
||||
logical media segments. A single switch port in a VLAN-capable switch
|
||||
can carry packets from multiple virtual LANs and linux can understand
|
||||
the format of these ethernet frames. For more on this, see
|
||||
the format of these Ethernet frames. For more on this, see
|
||||
<ulink url="http://www.candelatech.com/~greear/vlan.html">the linux
|
||||
802.1q VLAN implementation site</ulink>.
|
||||
</para>
|
||||
|
@ -1054,8 +1054,8 @@ ALTER := [ src IP ] [ llsrc LLADDR ] [ lldst LLADDR ]</computeroutput>
|
|||
support under linux. Ben McKeegan wrote a
|
||||
<ulink url="http://www.wanfear.com/pipermail/vlan/2002q4/002882.html">good
|
||||
summary</ulink> of the MTU/MRU issues involved with VLANs and 10/100
|
||||
Ethernet. Gigabit ethernet drivers are not hamstrung with this problem.
|
||||
Consider using gigabit ethernet cards from the outset to avoid these
|
||||
Ethernet. Gigabit Ethernet drivers are not hamstrung with this problem.
|
||||
Consider using gigabit Ethernet cards from the outset to avoid these
|
||||
potential problems.
|
||||
</para>
|
||||
<example id="ex-ether-vlan">
|
||||
|
@ -1231,7 +1231,7 @@ The interface eth3 is up, shutting it down it to enslave it.</computeroutput>
|
|||
Immediately noticeable, there is a new flag in the <command>ip link
|
||||
show</command> output. The <constant>MASTER</constant> and
|
||||
<constant>SLAVE</constant> flags clearly report the nature of the
|
||||
relationship between the interfaces. Also, the ethernet interfaces
|
||||
relationship between the interfaces. Also, the Ethernet interfaces
|
||||
indicate the master interface via the keywords <constant>master
|
||||
bond0</constant>.
|
||||
</para>
|
||||
|
|
|
@ -161,19 +161,19 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>&isdn-router;</entry>
|
||||
<entry>(ethernet)</entry>
|
||||
<entry>(Ethernet)</entry>
|
||||
<entry>192.168.99.1/24</entry>
|
||||
<entry>00:c0:7b:45:6a:39</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&branch-router;</entry>
|
||||
<entry>(ethernet)</entry>
|
||||
<entry>(Ethernet)</entry>
|
||||
<entry>192.168.98.254/24</entry>
|
||||
<entry>00:c0:7b:37:af:91</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&service-router;</entry>
|
||||
<entry>(ethernet)</entry>
|
||||
<entry>(Ethernet)</entry>
|
||||
<entry>192.168.100.1/24</entry>
|
||||
<entry>00:c0:7b:7d:00:c8</entry>
|
||||
</row>
|
||||
|
|
|
@ -30,7 +30,7 @@
|
|||
Second, I assume the reader is comfortable with command line tools
|
||||
and the Linux, Unix, or BSD environments. Finally, I assume the
|
||||
reader has working
|
||||
network cards and a Linux OS. For assistance with ethernet cards, the
|
||||
network cards and a Linux OS. For assistance with Ethernet cards, the
|
||||
there exists a good
|
||||
<ulink url="http://www.tldp.org/HOWTO/Ethernet-HOWTO.html">Ethernet
|
||||
HOWTO</ulink>.
|
||||
|
@ -46,8 +46,8 @@
|
|||
</para>
|
||||
<para>
|
||||
This guide has been written primarily as a companion reference to IP
|
||||
networking on ethernets. Although I do allude to other link layer types
|
||||
occasionally in this book, the focus has been IP as used in ethernet.
|
||||
networking on Ethernets. Although I do allude to other link layer types
|
||||
occasionally in this book, the focus has been IP as used in Ethernet.
|
||||
Ethernet is one of the most common networking devices supported under
|
||||
linux, and is practically ubiquitous.
|
||||
</para>
|
||||
|
|
|
@ -118,7 +118,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Address Resolution Protocol is used to provide the glue between
|
||||
ethernet link layer information (hardware addresses) and the IP
|
||||
Ethernet link layer information (hardware addresses) and the IP
|
||||
layer. This
|
||||
<ulink url="http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html">page</ulink>
|
||||
is instructive in ARP.
|
||||
|
@ -356,6 +356,24 @@
|
|||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="links-ipfwadm">
|
||||
<title><command>ipfwadm</command> Resources</title>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Not covered in this documentation, <command>ipfwadm</command> is
|
||||
only supported in the linux 2.2 and 2.4 kernels via backward
|
||||
compatible interfaces to the internal packet filtering
|
||||
architectures. Read more on <command>ipfwadm</command>
|
||||
<ulink url="http://www.xos.nl/linux/ipfwadm/paper/">here</ulink>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="links-systems">
|
||||
<title>General Systems References</title>
|
||||
<itemizedlist>
|
||||
|
@ -372,7 +390,7 @@
|
|||
For a description of the
|
||||
<ulink url="http://www.gnumonks.org/ftp/pub/doc/packet-journey-2.4.html">path
|
||||
a frame on the wire takes</ulink> through the kernel from
|
||||
the ethernet through to the upper layers, Harald Welte's
|
||||
the Ethernet through to the upper layers, Harald Welte's
|
||||
brief proves instructive.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -587,7 +605,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
The 2.2 and 2.4 series support bonding of interfaces which allows
|
||||
both link aggregation (IEEE 802.3ad) and failover use of ethernet
|
||||
both link aggregation (IEEE 802.3ad) and failover use of Ethernet
|
||||
interfaces. The canonical source for documentation about bonding
|
||||
is <filename>Documentation/networking/bonding.txt</filename> in
|
||||
the kernel source distribution.
|
||||
|
@ -669,7 +687,7 @@
|
|||
<para>
|
||||
The <ulink url="http://www.tazenda.demon.co.uk/phil/net-tools/">net-tools</ulink>
|
||||
package is a collection of basic utilities for managing the
|
||||
ethernet and IP layer under linux.
|
||||
Ethernet and IP layer under linux.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<title>Diagnostics</title>
|
||||
<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
|
||||
routes, IP addresses, and a few Ethernet tools, we come to a set of
|
||||
tools which are used primarily to help you figure out what is wrong in
|
||||
your network, where a route is broken, or even, simply, whether a host
|
||||
is reachable.
|
||||
|
@ -175,7 +175,7 @@ round-trip min/avg/max/mdev = 0.179/0.208/0.231/0.024 ms</computeroutput>
|
|||
As with much data collection, you need a large sample set of data to
|
||||
draw conclusions about your network. You can usually conclude that
|
||||
something is quite wrong if you cannot reach a remote host, but you
|
||||
should be cautious when concluding that your ethernet card is bad
|
||||
should be cautious when concluding that your Ethernet card is bad
|
||||
simply because round-trip times to a destination on the LAN is high.
|
||||
It is more likely that there's another problem. Collecting
|
||||
<command>ping</command> data from a number of hosts to a number of
|
||||
|
@ -280,7 +280,7 @@ round-trip min/avg/max/mdev = 37.840/62.234/97.807/12.946 ms</computeroutput>
|
|||
packet loss. By increasing the packet size of the packet we are
|
||||
sending across the link we can get a sense for how quickly
|
||||
performance degrades on this link. If we use a much larger packet
|
||||
size (still smaller than ethernet's 1500 byte frame), we see even
|
||||
size (still smaller than Ethernet's 1500 byte frame), we see even
|
||||
more packet loss. We'll specify a packet size of 512 bytes with the
|
||||
<option>-s</option> option.
|
||||
</para>
|
||||
|
@ -369,7 +369,7 @@ round-trip min/avg/max/mdev = 47.893/52.102/56.311/4.209 ms</computeroutput>
|
|||
in smaller networks.
|
||||
</para>
|
||||
<para>
|
||||
The first IP we hit is our own IP on the way out our ethernet
|
||||
The first IP we hit is our own IP on the way out our Ethernet
|
||||
interface, 192.168.98.82. Then it is a palindromic journey through
|
||||
the network stacks of each of the following hosts in order:
|
||||
&branch-router;, &isdn-router;, &tristan;, and back again
|
||||
|
@ -808,7 +808,7 @@ tcp 0 0 192.168.98.82:44320 192.168.100:netbios-ssn TIME_WAIT</c
|
|||
</para>
|
||||
<para>
|
||||
The first line describes a TCP connection to the IP locally hosted
|
||||
on &morgan;'s ethernet interface. The connection was initiated from
|
||||
on &morgan;'s Ethernet interface. The connection was initiated from
|
||||
an ephemeral port (40991) on &tristan; to a service running on port
|
||||
22. The service normally running on this well-known port is sshd,
|
||||
so we can conclude that somebody on &tristan; has connected to the
|
||||
|
|
|
@ -4,29 +4,29 @@
|
|||
<title>Ethernet Layer Tools</title>
|
||||
<para>
|
||||
The section here will cover tools which manipulate, display
|
||||
characteristics of or probe ethernet devices. Because ethernet is one
|
||||
characteristics of or probe Ethernet devices. Because Ethernet is one
|
||||
of the most available and widely spread networking media in use today,
|
||||
we'll concentrate on ethernet rather than other link layer protocols.
|
||||
we'll concentrate on Ethernet rather than other link layer protocols.
|
||||
</para>
|
||||
<para>
|
||||
As with any networking stack, the lower layers must be functioning
|
||||
properly in order for the higher layer protocols to operate. The tools
|
||||
covered in this section will provide the resources you need to verify
|
||||
the proper operation of your linux machine in an ethernet environment.
|
||||
the proper operation of your linux machine in an Ethernet environment.
|
||||
</para>
|
||||
<para>
|
||||
You probably knew before reading this that you can look at the link
|
||||
light on your ethernet switch/hub and the link light on your ethernet
|
||||
light on your Ethernet switch/hub and the link light on your Ethernet
|
||||
card to verify a good connection. Now you can use
|
||||
<link linkend="tools-mii-tool"><command>mii-tool</command></link> to
|
||||
ask the ethernet driver if it agrees. Once you have verified a good media
|
||||
ask the Ethernet driver if it agrees. Once you have verified a good media
|
||||
connection, you may want to set other link layer characteristics on your
|
||||
ethernet device. For this,
|
||||
Ethernet device. For this,
|
||||
<link linkend="tools-ip-link"><command>ip link</command></link> is
|
||||
the perfect tool.
|
||||
</para>
|
||||
<para>
|
||||
To see if anybody is using an IP address already on the ethernet to
|
||||
To see if anybody is using an IP address already on the Ethernet to
|
||||
which you are connecting, you can use
|
||||
<link linkend="tools-arping"><command>arping</command></link>
|
||||
and if you want to play with the arp tables, the
|
||||
|
@ -69,7 +69,7 @@
|
|||
<para>
|
||||
The MAC address in the third column is always a six part hexadecimal
|
||||
number. In practice, the MAC address (also known as the hardware
|
||||
address or the ethernet address) is not normally needed for the
|
||||
address or the Ethernet address) is not normally needed for the
|
||||
majority of troubleshooting problems, however knowing how to retrieve
|
||||
the MAC address can help when tracking down problems in a network
|
||||
<footnote>
|
||||
|
@ -78,12 +78,12 @@
|
|||
to join the network were suddenly and apparently inexplicably
|
||||
receiving addresses in an unexpected netblock.
|
||||
After some head-scratching and judicious use of
|
||||
<command>tcpdump</command> to record the ethernet address of the
|
||||
<command>tcpdump</command> to record the Ethernet address of the
|
||||
DHCP server giving out the bogus IP information, the administrator
|
||||
was able to track down a device through the switch to a port on
|
||||
the LAN.
|
||||
It turned out to be a tiny (4-port) hub with an embedded DHCP server
|
||||
which was intended for home use! The knowledge of the ethernet
|
||||
which was intended for home use! The knowledge of the Ethernet
|
||||
address of the rogue DHCP server was the key to physically
|
||||
locating the device.
|
||||
</para>
|
||||
|
@ -119,7 +119,7 @@
|
|||
respond for ARP requests on eth3 for the IP 192.168.100.17. If the
|
||||
<systemitem class="systemname">service-router</systemitem> has a
|
||||
packet bound for 192.168.100.17, it will generate an ARP request to
|
||||
which we will respond with the ethernet address of our eth3 interface.
|
||||
which we will respond with the Ethernet address of our eth3 interface.
|
||||
</para>
|
||||
<para>
|
||||
Moments after you have added this arp table entry, you realize that
|
||||
|
@ -160,19 +160,19 @@
|
|||
An almost unknown command (mostly because it is not frequently
|
||||
necessary), the <command>arping</command> utility performs an action
|
||||
similar to <link linkend="tools-ping"><command>ping</command></link>,
|
||||
but at the ethernet layer. Where <command>ping</command> tests the
|
||||
but at the Ethernet layer. Where <command>ping</command> tests the
|
||||
reachability of an IP address, <command>arping</command> reports the
|
||||
reachability and round-trip time of an IP address hosted on the local
|
||||
network.
|
||||
</para>
|
||||
<para>
|
||||
There are several modes of operation for this utility. Under normal
|
||||
operation, <command>arping</command> displays the ethernet and IP
|
||||
operation, <command>arping</command> displays the Ethernet and IP
|
||||
address of the target as well as the time elapsed between the
|
||||
arp request and the arp reply.
|
||||
</para>
|
||||
<example id="ex-tools-arping-listing">
|
||||
<title>Displaying reachability of an IP on the local ethernet with <command>arping</command></title>
|
||||
<title>Displaying reachability of an IP on the local Ethernet with <command>arping</command></title>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>arping -I eth0 -c 2 192.168.100.17</userinput>
|
||||
<computeroutput>ARPING 192.168.100.17 from 192.168.100.254 eth0
|
||||
|
@ -189,13 +189,13 @@ Received 2 response(s)</computeroutput>
|
|||
<command>-A</command> option. A kernel with support for <link
|
||||
linkend="adv-non-local-bind">non-local bind</link> can be used with
|
||||
arping for the nefarious purpose of wreaking havoc on
|
||||
an otherwise properly configured ethernet. By performing gratuitous arp
|
||||
an otherwise properly configured Ethernet. By performing gratuitous arp
|
||||
and broadcasting incorrect arp information, arp tables in poorly
|
||||
designed IP stacks can become quite confused.
|
||||
</para>
|
||||
<para>
|
||||
<command>arping</command> can detect if an IP address is
|
||||
currently in use on an ethernet. Called duplicate address detection,
|
||||
currently in use on an Ethernet. Called duplicate address detection,
|
||||
this use of <command>arping</command> is increasingly common in
|
||||
networking scripts.
|
||||
</para>
|
||||
|
@ -227,13 +227,13 @@ Received 2 response(s)</computeroutput>
|
|||
address is in use by
|
||||
<systemitem class="systemname">tristan</systemitem>,
|
||||
<systemitem class="systemname">dietrich</systemitem> receives a
|
||||
response. Any response by a device on the ethernet indicating that an
|
||||
response. Any response by a device on the Ethernet indicating that an
|
||||
IP address is in use will cause the <command>arping</command> command
|
||||
to exit with a non-zero exit code (specifically, exit code 1).
|
||||
</para>
|
||||
<para>
|
||||
Note, that the ethernet device must already be in an UP state (see
|
||||
<xref linkend="tools-ip-link"/>). If the ethernet device has not been
|
||||
Note, that the Ethernet device must already be in an UP state (see
|
||||
<xref linkend="tools-ip-link"/>). If the Ethernet device has not been
|
||||
brought up, the <command>arping</command> utility will exit with a
|
||||
non-zero exit code (specifically, exit code 2).
|
||||
</para>
|
||||
|
@ -251,7 +251,7 @@ Received 2 response(s)</computeroutput>
|
|||
flags</link>, <link linkend="tools-ip-link-set-mtu">change MTU</link>,
|
||||
<link linkend="tools-ip-link-set-name">the name of the interface</link>,
|
||||
and even the <link linkend="tools-ip-link-set-address">hardware and
|
||||
ethernet broadcast address</link>.
|
||||
Ethernet broadcast address</link>.
|
||||
</para>
|
||||
<para>
|
||||
The <command>ip link</command> tool provides the following two verbs:
|
||||
|
@ -314,8 +314,8 @@ Received 2 response(s)</computeroutput>
|
|||
(MTU)</link> the active queueing mechanism (if any), and
|
||||
the queue size if there is a queue present. The second line will
|
||||
always indicate the type of link layer in use on the device, and
|
||||
link layer specific information. For ethernet, the common case,
|
||||
the current hardware address and ethernet broadcast address will be
|
||||
link layer specific information. For Ethernet, the common case,
|
||||
the current hardware address and Ethernet broadcast address will be
|
||||
displayed.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -331,7 +331,7 @@ Received 2 response(s)</computeroutput>
|
|||
I have not found need to use the <command>ip link
|
||||
set</command> command with any of the toggle flags Regardless,
|
||||
here's an example of the proper operation of the utility. Paranoid
|
||||
network administrators or those who wish to map ethernet addresses
|
||||
network administrators or those who wish to map Ethernet addresses
|
||||
manually should take special note of the <command>ip link set arp
|
||||
off</command> command.
|
||||
</para>
|
||||
|
@ -577,12 +577,12 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</para>
|
||||
</section>
|
||||
<section id="tools-ip-link-set-address">
|
||||
<title>Changing hardware or ethernet broadcast address with
|
||||
<title>Changing hardware or Ethernet broadcast address with
|
||||
<command>ip link set</command></title>
|
||||
<para>
|
||||
This command changes the hardware or broadcast address of a device
|
||||
as used on the media to which it is connected. Supposedly there can
|
||||
be name clashes between two different ethernet cards sharing the
|
||||
be name clashes between two different Ethernet cards sharing the
|
||||
same hardware address. I have yet to see this problem, so I suspect
|
||||
that changing the hardware address is more commonly used in
|
||||
vulnerabliity testing or even more nefarious purposes.
|
||||
|
@ -591,10 +591,10 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
Alternatively, one can set the broadcast address to a different
|
||||
value, which as Alexey remarks as an aside in the
|
||||
&iproute2; manual will "break networking."
|
||||
Changing the ethernet broadcast address implies that no
|
||||
Changing the Ethernet broadcast address implies that no
|
||||
conventionally configured host will answer broadcast ARP frames
|
||||
transmitted onto the ethernet. Since conventional ARP requests
|
||||
are sent to the ethernet broadcast of
|
||||
transmitted onto the Ethernet. Since conventional ARP requests
|
||||
are sent to the Ethernet broadcast of
|
||||
<constant>ff:ff:ff:ff:ff:ff</constant>, broadcast frames sent after
|
||||
changing the link layer broadcast address will not be received by
|
||||
other hosts on the segment. To echo
|
||||
|
@ -629,7 +629,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</para>
|
||||
<para>
|
||||
Note, however, in the tcpdump output, the effect of changing
|
||||
the ethernet broadcast address. As discussed in the paragraph
|
||||
the Ethernet broadcast address. As discussed in the paragraph
|
||||
above, changing the broadcast is probably not a good idea
|
||||
<footnote>
|
||||
<para>
|
||||
|
@ -638,9 +638,6 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</para>
|
||||
</footnote>.
|
||||
</para>
|
||||
</section>
|
||||
<section id="tools-ip-link-conclusion">
|
||||
<title></title>
|
||||
<para>
|
||||
As you can see, the <command>ip link</command> utility is a treasure
|
||||
trove of information and allows a great deal of control over the
|
||||
|
@ -760,7 +757,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
<para>
|
||||
This creates an entry in the neighbor table which maps
|
||||
192.168.100.1 to link layer address 00:c0:7b:7d:00:c8. Subsequent IP
|
||||
packets bound for 192.168.100.1 will be encapsulated in ethernet
|
||||
packets bound for 192.168.100.1 will be encapsulated in Ethernet
|
||||
frames with 00:c0:7b:7d:00:c8 in the destination bytes. This
|
||||
permanent mapping cannot be overridden by ARP. It would need to be
|
||||
removed with
|
||||
|
@ -857,9 +854,9 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
<section id="tools-mii-tool">
|
||||
<title><command>mii-tool</command></title>
|
||||
<para>
|
||||
A key tool for determining if you are connected to the ethernet, and
|
||||
A key tool for determining if you are connected to the Ethernet, and
|
||||
if so, at what speed. The <command>mii-tool</command> program
|
||||
does not support all ethernet devices, as some ethernet devices have
|
||||
does not support all Ethernet devices, as some Ethernet devices have
|
||||
their own vendor-supplied tools to report the same information. The
|
||||
<command>mii-tool</command> source code is based on a tool called
|
||||
<command>mii-diag</command> which provides slightly more information
|
||||
|
@ -871,14 +868,14 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
you'll encounter in output from <command>mii-tool</command>
|
||||
<footnote>
|
||||
<para>
|
||||
There is a standard speed/ethernet transmission style supported by
|
||||
There is a standard speed/Ethernet transmission style supported by
|
||||
<command>mii-tool</command> to which I have not referred. That is
|
||||
100BaseT4. 100BaseT4 provides support for 100 megabit ethernet
|
||||
100BaseT4. 100BaseT4 provides support for 100 megabit Ethernet
|
||||
networking over Category 3 rated cable. This is probably not a
|
||||
concern for most recently upgraded network infrastructure. The
|
||||
standard networking cable pulled in new construction and
|
||||
renovation is now Category 5 cable which supports 100Base-Tx-FD
|
||||
and possibly gigabit ethernet. So, let's relegate 100BaseT4 to
|
||||
and possibly gigabit Ethernet. So, let's relegate 100BaseT4 to
|
||||
this footnote, and resume.
|
||||
</para>
|
||||
</footnote>.
|
||||
|
@ -914,7 +911,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</table>
|
||||
<para>
|
||||
The raw number indicates the number of bits which can be exchanged
|
||||
between two ethernet devices over the wire. So 10 megabit ethernet
|
||||
between two Ethernet devices over the wire. So 10 megabit Ethernet
|
||||
can support the transmission of ten million bits per second. The
|
||||
suffix to each identifier indicates whether both hosts can send and
|
||||
receive simultaneously or not. Half duplex means that each device can
|
||||
|
@ -923,7 +920,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</para>
|
||||
<para>
|
||||
The simplest use of <command>mii-tool</command> reports the link
|
||||
status of all ethernet devices on a system. Any argument
|
||||
status of all Ethernet devices on a system. Any argument
|
||||
to <command>mii-tool</command> is interpreted as an interface name to
|
||||
query for link status.
|
||||
</para>
|
||||
|
@ -945,22 +942,22 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
<para>
|
||||
In the above example, we can infer that
|
||||
<systemitem class="systemname">tristan</systemitem> has only one
|
||||
ethernet device (or no ethernet drivers loaded for any other present
|
||||
ethernet devices). The first ethernet device has successfully
|
||||
Ethernet device (or no Ethernet drivers loaded for any other present
|
||||
Ethernet devices). The first Ethernet device has successfully
|
||||
negotiated a 100 megabit full duplex connection with the device to
|
||||
which it is connected.
|
||||
</para>
|
||||
<para>
|
||||
Although a great rarity, you may have occasion to dictate to the
|
||||
ethernet interface the speed at which it should talk to the switch or
|
||||
Ethernet interface the speed at which it should talk to the switch or
|
||||
hub. <command>mii-tool</command> supports a mode of operation under
|
||||
which you indicate supported modes for autonegotiation. Normally, two
|
||||
connected devices will negotiate the fastest possible commonly shared
|
||||
speed. You can select what speeds you want to support on an ethernet
|
||||
speed. You can select what speeds you want to support on an Ethernet
|
||||
interface by using <command>mii-tool</command>.
|
||||
</para>
|
||||
<example id="tools-mii-tool-advertise">
|
||||
<title>Specifying ethernet port speeds with <command>mii-tool --advertise</command></title>
|
||||
<title>Specifying Ethernet port speeds with <command>mii-tool --advertise</command></title>
|
||||
<programlisting>
|
||||
<prompt>[root@tristan]# </prompt><userinput>mii-tool mii-tool --advertise 10baseT-HD,10baseT-FD</userinput>
|
||||
<computeroutput>restarting autonegotiation...</computeroutput>
|
||||
|
@ -970,12 +967,12 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</example>
|
||||
<para>
|
||||
After we specified that we wished only to support 10baseT-HD and
|
||||
10baseT-FD as acceptable speeds, mii-tool caused the ethernet driver
|
||||
10baseT-FD as acceptable speeds, mii-tool caused the Ethernet driver
|
||||
to renegotiate port speed with the attached device. Here we selected
|
||||
10baseT-FD.
|
||||
</para>
|
||||
<example id="tools-mii-tool-force">
|
||||
<title>Forcing ethernet port speed with <command>mii-tool --force</command></title>
|
||||
<title>Forcing Ethernet port speed with <command>mii-tool --force</command></title>
|
||||
<programlisting>
|
||||
<prompt>[root@tristan]# </prompt><userinput>mii-tool --force 10baseT-FD</userinput>
|
||||
<prompt>[root@tristan]# </prompt><userinput>mii-tool</userinput>
|
||||
|
@ -987,7 +984,7 @@ default via 192.168.99.254 dev eth0</computeroutput>
|
|||
</programlisting>
|
||||
</example>
|
||||
<para>
|
||||
After manipulating the speed at which the ethernet driver would
|
||||
After manipulating the speed at which the Ethernet driver would
|
||||
communicate with the connected device on &tristan;, we chose to
|
||||
restart the autonegotiation process without forcing a particular speed
|
||||
or advertising a particular speed.
|
||||
|
|
|
@ -63,7 +63,7 @@
|
|||
<command>ifconfig</command></title>
|
||||
<para>
|
||||
In its simplest use, <command>ifconfig</command> merely reports the
|
||||
IP interface and relevant statistics. For ethernet devices, the
|
||||
IP interface and relevant statistics. For Ethernet devices, the
|
||||
hardware address, IP address, broadcast, netmask, IP interface states,
|
||||
and some other additional information is presented. For other
|
||||
interfaces, different information may be presented to the user, but
|
||||
|
@ -139,7 +139,7 @@ lo Link encap:Local Loopback
|
|||
</example>
|
||||
<para>
|
||||
Naturally, when we view the active interfaces after downing the first
|
||||
ethernet interface, we see that eth0 is no longer present. This is
|
||||
Ethernet interface, we see that eth0 is no longer present. This is
|
||||
exactly what we had intended. Now to bring up the interface, we'll
|
||||
need the IP address and netmask information.
|
||||
</para>
|
||||
|
@ -191,12 +191,12 @@ lo Link encap:Local Loopback
|
|||
</para>
|
||||
<para>
|
||||
The first line of each interface definition represents data which
|
||||
cannot be altered with ifconfig. If we consider only ethernet
|
||||
cannot be altered with ifconfig. If we consider only Ethernet
|
||||
interfaces, the link encapsulation will always say "Ethernet", and the
|
||||
hardware address cannot be altered with <command>ifconfig</command>
|
||||
<footnote>
|
||||
<para>
|
||||
If you need to change the hardware address of an ethernet
|
||||
If you need to change the hardware address of an Ethernet
|
||||
interface, you have a strange need, but you can accomplish this
|
||||
using the <link linkend="tools-ip-link-set-address"><command>ip
|
||||
link set address</command></link> command.
|
||||
|
@ -209,12 +209,12 @@ lo Link encap:Local Loopback
|
|||
The third line indicates the current states of the interface, maximum
|
||||
transmission unit, and the metric for this interface. Possible
|
||||
state options are itemized in the table below. The maximimum
|
||||
transmission unit is routinely set to 1500 bytes for ethernet and
|
||||
transmission unit is routinely set to 1500 bytes for Ethernet and
|
||||
promptly forgotten. MTU suddenly becomes important when IP packets
|
||||
are forwarded across a link layer which requires a smaller MTU. Thus
|
||||
<command>ifconfig</command> provides a method to set the MTU on an
|
||||
interface. For more on MTU, see <xref linkend="routing-icmp-mtu"/>. The
|
||||
remaining lines of output are taken from the ethernet driver. See
|
||||
remaining lines of output are taken from the Ethernet driver. See
|
||||
further discussion of these statistics below.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -407,13 +407,13 @@ lo Link encap:Local Loopback
|
|||
<para>
|
||||
The final fields in the first line of output for each device entry
|
||||
refer to the traffic control queueing discipline (qdisc) and the
|
||||
ethernet buffer transmit queue length (qlen). For more on
|
||||
Ethernet buffer transmit queue length (qlen). For more on
|
||||
understanding and using traffic control under linux, see
|
||||
<ulink url="http://lartc.org/howto/">the LARTC documentation</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
The second line of output describes the link layer characteristics
|
||||
of the device. For ethernet devices, this will always say
|
||||
of the device. For Ethernet devices, this will always say
|
||||
"link/ether" followed by the hardware address of the device and the
|
||||
media broadcast address. For more detail on the link layer
|
||||
characteristics of a device see <xref linkend="tools-ip-link"/>.
|
||||
|
|
|
@ -163,7 +163,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
<para>
|
||||
A quick glance down this routing table also provides us with a good
|
||||
deal of knowledge about the topology of the network. Immediately we
|
||||
can identify four separate ethernet interfaces, 3 locally connected
|
||||
can identify four separate Ethernet interfaces, 3 locally connected
|
||||
class C sized networks, and one tiny subnet (192.168.100.0/30). We
|
||||
can also determine that there are two networks reachable via static
|
||||
routes behind internal routers.
|
||||
|
@ -246,7 +246,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
for locally connected networks in a routing cache. After a bit of
|
||||
reflection, you come to realize that there is on need to cache an IP
|
||||
route for a locally connected network because the machine is
|
||||
connected to the same ethernet. So, any given destination has an
|
||||
connected to the same Ethernet. So, any given destination has an
|
||||
entry in either the arp table or in the routing cache. For a
|
||||
clearer picture of the differences between each of the cached
|
||||
routse, I'd suggest adding a <option>-e</option> switch.
|
||||
|
@ -359,7 +359,7 @@ Source Destination Gateway Flags MSS Window irtt Iface
|
|||
</para>
|
||||
<para>
|
||||
Occasionally, however, you'll have a single machine with an IP
|
||||
address in a different range on the same ethernet as some other
|
||||
address in a different range on the same Ethernet as some other
|
||||
machines. Or you might have a single machine which is reachable
|
||||
via a router. Let's look at these two scenarios to see how we can
|
||||
create static routes to solve this routing need.
|
||||
|
@ -411,7 +411,7 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
|
|||
reach.
|
||||
</para>
|
||||
<para>
|
||||
Even rarer, you may encounter a situation where a single ethernet
|
||||
Even rarer, you may encounter a situation where a single Ethernet
|
||||
network is used to host multiple IP networks. There are reasons
|
||||
people might do this, although I regard this is bad form. If
|
||||
possible, it is cleaner, more secure, and easier to troubleshoot if
|
||||
|
@ -789,7 +789,7 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
<footnote>
|
||||
<para>
|
||||
I'm going to specifically neglect a discussion of bridging and
|
||||
broadcast addresses for now. Let's assume a simple ethernet
|
||||
broadcast addresses for now. Let's assume a simple Ethernet
|
||||
where the entire IP network is on one hub or switch.
|
||||
</para>
|
||||
</footnote>.
|
||||
|
@ -807,7 +807,7 @@ local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1</computeroutpu
|
|||
When a user initiates a connection to localhost (let's say
|
||||
localhost:25, where a private SMTP server is listening), the
|
||||
connection could, of course, come from the IP assigned to any of
|
||||
the ethernet interfaces. It makes the most sense, however, for the
|
||||
the Ethernet interfaces. It makes the most sense, however, for the
|
||||
source IP to be set to 127.0.0.1, since the connection is
|
||||
actually initiated from on the local machine. Some services
|
||||
running on a local machine rely on the loopback interface and
|
||||
|
|
Loading…
Reference in New Issue