I actually mentioned this in the previous class (class four), but forgot to include it in the notes for that class...
Several students asked about some of the hardware types in the lab. Consider the uname output from one of the HP machines:
xibalba % ssh nag uname -a
HP-UX nag B.10.20 A 9000/735
Nag is a 9000/735 series server running a flavor of unix called HP/UX
(pronounced `h-pux'). To learn more about HP hardware, you can
visit the following site:
How about the output of the uname command for Solaris machines. There are two types in the lab:
bfs % uname -a
SunOS bfs 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-Enterprise
cardinal % uname -a
SunOS cardinal.cs.colorado.edu 5.7 Generic_106542-08 i86pc i386 i86pc
In both cases the operating system is SunOS 5.7 (aka Solaris 7) but the
underlying hardware architecture is different. Bfs is a sparc
(specifically a SUNW,Ultra-Enterprise type of sparc) while cardinal
is just an intel-based machine called i86pc by Solaris.
For information about Sun sparc hardware:
And for information about PC hardware:
saclass % uname -a
OpenBSD saclass 2.8 GENERIC#96 sparc
saclass % ssh saclass-2 uname -a
Linux saclass-2 2.2.16-22 #1 Tue Aug 22 16:16:55 EDT 2000 i586 unknown
saclass % ^2^3
ssh saclass-3 uname -a
OpenBSD saclass-3 2.8 GENERIC#399 i386
saclass % ^3^4
ssh saclass-4 uname -a
Linux saclass-4 2.2.14-5.0 #1 Tue Mar 7 20:54:26 EST 2000 sparc unknown
Read the uname(1) manpage for the relevent OS to find out exactly
what each field means as well as what other arguments are available.
Please carefully read the handout from class, the introduction to Stevens' excellent first volume on TCP/IP networking. If you did not get a handout, please contact me. See: Books for information about the books I mentioned in class.
The linux networking Howto has some good info:
Also, there is a very comprehensive archive of networking information:
This site has an amazing wealth of information ranging from the physical (i.e. electrical) specifications for various types of ethernet through descriptions of the various TCP/IP protocols and on to more advanced and usefult topics like DNS and routing .
The remainder of this section will give a very rough overview of the lecture and high-light some of the important concepts..
Layer Example Protocols
----- -----------------
Application ssh ftp telnet
Transport tcp udp
Network ip arp rarp
Link ethernet ppp
Each protocol has a defined header (hdr) that sort of acts like a destination and return address that get written on a postal envelope. We will look at the various header definations more closely below.
The various protocols sort of act like layers of an onion as each layer wraps up a previous layer as data. For example, first ssh encrypts some user data and hands it off to tcp which adds a header of its own to the front of the packet of data and hands it off to ip . The process is repeated, where IP adds a header of its own and gives the packet to the ethernet driver:
+---------------------+
| SSH DATA | Application layer
+---------------------+
+-----+---------------------+
| TCP | DATA | Transport layer
| Hdr | |
+-----+---------------------+
+-----+---------------------------+
| IP | DATA | Network layer
| Hdr | |
+-----+---------------------------+
+-------+---------------------------------+
| Ether | DATA | Link layer
| Hdr | |
+-------+---------------------------------+
Then the ethernet packet is sent out on the wire.. the destination host
receives the packet and proceeds to unwrap it. The ethernet code
knows it is an IP packet, so it takes off the ethernet header information
and hand the packet off to the IP code. The IP code figures out that the
packet is a TCP packet so it removes the IP header information and hands the
packet off to the TCP code. The TCP code figures out that the packet is
for a particular SSH session, removes the TCP header information and hands
the data to the SSH process.
In general, it is important to understand that the link layer is dealing with communication between machines that are physically connected to each other over some kind of media like twisted-pair copper wire in the traditional ethernet case or your telephone-line in the PPP case when you dialup from home. (There are some caveats, of course, like wireless networking..)
Ethernet is an example of a broadcast medium. That is, every host on the local ethernet "hears" everything that every other machine on that net "says". (more on ethernet below).
<some chunk of ethernet with five hosts attached to it>
===+=============+==============+==============+==============+====
| | | | |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| A | | B | | C | | D | | E |
+---+ +---+ +---+ +---+ +---+
PPP, which stands for Point-to-Point-Protocol is not a broadcast medium. Instead it is communication between only two machines and there aren't any other hosts on the link. Most often the link is enabled through the use of modems where each machine uses a modem attached to one of its serial ports to connect to and communicate over a voice-grade telephone line. (Such telephone lines are refered to as POTS for Plain Old Telephone Service).
PPP link over phone line:
+---+ +-----+
| H +----+=<telephone-system>=+----+ ISP |
+---+ +-----+
The communication method that is used on an ethernet media has been compared to that utilized during a polite dinner party :
[the] IEEE standard was published in 1985, and its formal title is
" IEEE 802.3 Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications." This standard
provides an "Ethernet like" system based on the original DIX Ethernet
technology. All Ethernet equipment since 1985 is built according to the
IEEE 802.3 standard, which is pronounced "eight oh two dot three."
<some chunk of ethernet with five hosts attached to it>
===+=============+==============+==============+==============+====
| | | | |
| | <- drop ---> | | |
| | cables | | |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| A | | B | | C | | D | | E |
+---+ +---+ +---+ +---+ +---+
Each host on the subnet has a nic (Network Interface Card) with
a unique six byte address, called an ethernet address or
sometimes a MAC address (for machine address).
Ethernet, as has been said, is a broadcast medium, so every host hears every transmission from every other host. However, the nic will compare the destination address in each received packet with its own address and reject packets that don't match. Exceptions to this are if a special ethernet address (also, confusingly, called a broadcast address) is used as the destination address. This special address consists of six bytes of all 1 . It is used by the ARP and RARP protocols (see below) to request information from any host that knows the answer.
Another way to get a nic to process packets that don't have a matching destination address is to place the device into promiscuous mode which causes all packets to be processed no matter what. Programs like tcpdump use this feature, as do the more nefarious passwd-sniffing programs used by hackers.
Technically, once a packet has been encapsulated with an ethernet header it is called a frame .
Here is a look at the format of the ethernet header :
0 bytes 6 12 14 + 4 bytes
+------------+------------+------+--------- --+----------+
| DEST addr | SRC addr | Type | DATA 46 - 1500 Bytes | CRC |
+------------+------------+------+--------- --+----------+
The Maximum Transmission Unit is the largest size packet that can be transmitted at once over a given type of media. For ethernet the MTU is 1500 bytes. For PPP links the MTU can be much smaller, and is often negotiated when the PPP session is started.
A related concept is called path MTU . Imagine a packet traversing the internet from your home computer to some web-server. There may be a number of different link-layer media types that get traversed as your packet travels to its destination, including your PPP link, ethernet when it reaches your ISP, and then perhaps ATM as it traverses a larger carrier like Qwest . The smallest MTU that lies between you and your destination is the path MTU , ATM, it turns out, has a very small MTU (chosen by committe, I'm serious!) that is 53 bytes.
The ARP and RARP protocols sort of straddle the layers between link and network. They rely on the underlying link protocol (ethernet) to function but they are not supposed to be transmitted off of a local subnet, so they aren't really network layer protocols.
ARP, or Address Resoluton Protocol is used by machines to find out the ethernet addresses of other machines on the local subnet. Each machine (once operational) on the subnet knows its own IP address and its own ethernet address. Other machines on the same subnet may only know another local machine by its IP address. If one machine needs to transmit data to the another, and only knows its IP address, it will use ARP to query for that machine's ethernet address. Once another ethernet address has been discovered it will be kept locally in the arp cache . You can use the arp(8) command to manipulate this cache. Use the -a argument to simply list the cache's contents:
coatl % arp -a
cs-gw3-fs.cs.colorado.edu (128.138.242.193) at 0:e0:f7:94:6:20
locust.cs.colorado.edu (128.138.242.195) at 8:0:20:8d:23:75
squid.cs.colorado.edu (128.138.242.196) at 8:0:20:9f:1f:2a
tlaloc-242d.cs.colorado.edu (128.138.242.200) at 8:0:20:23:e:98
weezle.cs.colorado.edu (128.138.242.202) at 0:a0:98:0:5:70
fiche.cs.colorado.edu (128.138.242.203) at 0:a0:98:0:7:20
cacheflow.cs.colorado.edu (128.138.242.205) at 0:a0:c9:55:35:64
The hostname, IP address, and ethernet address are given for each
entry in the cache. If a machine is not responding correctly to
ARP requests, you can use the arp command to manually enter the
necessary information into another machine's arp cache.. this is
hardly every necessary.
RARP is kind of the opposite of ARP. It is the Reverse Address Resolution Protocol. Diskless workstations that boot over the net and machines being newly installed may get their IP address using the RARP protocol. In this case, a machine knows its own ethernet address and uses RARP to send a query "here is my ethernet address, please tell me my IP address". A RARP server machine (running rarpd(8) ) will respond with the necessary information (if it is configured in the /etc/ethers file on the RARP server machine).
The Network layer is responsible for getting data between any two hosts, not just two hosts on the same local subnet. The important protocol of the network layer is the IP protocol (Internet Protocol). An important related protocol is known as ICMP or Internet Control Message Protocol.
A fundamental network layer concept is routing or the path a packet of data takes between the source and destination hosts. We will spend some time talking about routing next week.
Every machine attached to the internet is assigned a unique 32-bit quantity called its IP address . The address is often divided into four eight-bit quanties and represented as a dotted-quad of octets . For example, look at the IP address for the host bfs.cs.colorado.edu in the CSEL lab:
suod % grep bfs /etc/hosts
128.138.202.9 bfs.cs.colorado.edu bfs beefus uinal # enterprise3500
Bfs's IP address is 128.138.202.9 as represented in the dotted-quad
notation.
For more than simple organizational reasons, these addresses are arranged in a structured space of separate sub-networks. For example, The subnet for the host bfs is 128.138.202.0 .
A host's IP address is thus divided into a network part and a host part. A netmask is used to tell how many bits (starting from the most significant bit) are for the network and how many bits are for the host. To continue our example, the netmask for the 128.138.202.0 subnet is 255.255.255.0 . This particular netmask has the first 24 most significant bits with a value of 1 (the network part) and the last 8 bits are 0 (the host part).
The 128.138.202.0 subnet has an address space of 256 addresses (I.e. 2 to the power of 8). The very first address of a subnet always just defines the subnet, it can not be used for any host. The very last address of the subnet is almost always the broadcast address for the subnet (i.e. hosts will use it to send one message to every host on the subnet). The subnet must have a broadcast address and the last address of the subnet is traditionally allocated for this purpose.
You can get the above information for a particular host by using the ifconfig(8) command:
bfs:tor % ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ffffff00
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 128.138.202.9 netmask ffffff00 broadcast 128.138.202.255
bfs:tor %
Two interfaces are listed in the output of this command for our example
machine, bfs . The first interface lo0 is a special one. It is
known as the loopback interface and it is fake ethernet interface
implemented in software. One purpose of the loopback interface is to
provide an ethernet-like interface for higher-level software that can
use the same networking code that is used to contact remote machine
to contact the local machine without actually
using the physical network.
The second interface hme0 is a 100 Megabit Fast Ethernet interface that is common on a lot of newer Sparc Ultra hardware. Notice that in the case of both interfaces, a line like the following is given:
inet 128.138.202.9 netmask ffffff00 broadcast 128.138.202.255
The note inet out front indicates that this is TCP/IP style networking.
This is followed by the IP address associated with the interface and
then the netmask, which is represented in hex (base 16). Finally
the broadcast address is given.
A traditional arrangement of the entire 32-bit address space was to divide it into several different classes as follows:
Class Network-Bits Address Range
----- ------------ -------------
A 8 0.0.0.0 thru 127.255.255.255
B 16 128.0.0.0 thru 191.255.255.255
C 24 192.0.0.0 thru 223.255.255.255
D special 224.0.0.0 thru 239.255.255.255
Allocation of IP address into groups as above proved to be short-sighted
and many smaller groups of address have been re-allocated to avoid
running out.. One important thing to remember about these address classes
is the number of bits there will be in the network-part of an address
based on the class of the address. For example, a "class C style"
address will have 24 bits in the network part of the address, leaving
8 bits for the host part.
Astute observers will note that the CSEL subnet (128.138.202.0) is a class C style subnet with 24 bits for the network part, but it falls inside the boundary of class B addresses! The university was allocated a class B network (the 128.138.0.0 ) which has 16 bits for the host part. Now imagine what a flat subnet with 65,000 hosts on it. Pretty frightening. From an administrative point of view, subnets make perfect sense. From a security point of view (as we will explore in subsequent classes) it makes sense as well!
[As an aside, if you also look at the "why subnet" issue historically, it makes sense. Ethernet has physical length limitations (i.e the ethernet cable itself was restricted to 300 meters in length, which could be extended using repeaters to boost the signal between the 300 meter segments, but only to a maximum of 4 repeaters). From this limitation alone, you could not connect all 16,000 hosts to the same subnet.]
The Internet Protocol is the fundamental protocol in use on the internet as all higher level applications ultimately make use of it. You will be perhaps surprised to note that IP itself is considered to be both unreliable and connectionless .
By unreliable it is meant that there are no guarantees that a given IP packet will reach its intended destination.
By connectionless it is meant that the IP drivers in the kernel do not keep track of any state information regarding the transmission of IP packets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Length|Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| < IP options *may* be present > |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The version is a 4-bit field. The current version of IP is 4.
The Length is also a 4-bit field, and represent the number of 32-bit words in the header. Generally, if no options are present, the length will simply by 5.
The Type-of-Service field is a 8-bit quantity and it is used for various routing concerns like "minimize delay" or "maximize throughput".
The total length of the packet follows and is a 16-bit quantity, resulting in the maximum size of an IP packet being 65535 bytes.
The 16-bit Identification field follows. Every IP packet sent by a given host is given a unique ID number.
The next 16 bits, comprising flags and *fragment offset* are used during routing for when a large IP packet must be fragmented to fit a (smaller) MTU media. The fragments are tagged with their offset in the original packet so that the destination host may correctly re-assemble the fragmented packet.
The 8-bit Time-to-live (TTL) field sets a limit on the number of routers the packet may traverse before it is "dropped" and not sent on any further. The reason for this is to avoid routing loops where a packet could go through a repeating cycle of routers (that are configured incorrectly, for example) forever. Each time the packet goes through a router, the TTL is decremented by one. When the TTL reaches zero, the packet is dropped.
The next 8-bit field is the protocol which specifies the type of data being carried by the IP packet. Common protocols are TCP, UDP and ICMP.
The header-Checksum is a 16 bit field and is computed only over the header of the IP packet. It is used to verify the integrity of the header information.
Finally we get to the 32-bit source and destination IP addresses.
Any IP options if they are present, will follow the two IP addresses. Some defined options include:
The Internet Control Message Protocol is considered to be part of the network layer. However it still relies on IP to transmit the ICMP messages.
The transport layer protocols provide an interface between application layer programs and the IP network layer. TCP and UDP are the two choices. An important concept at the transport layer is the port number. The port numbers are used to idnetify the source and destination application processes.
Many well known services "listen" at defined port numbers (either TCP or UDP depending on the service). For example, SSH listens on TCP port number 22.
UDP is the User Datagram Protocol. Similar to IP itself, UDP is an unreliable and connectionless protocol. A UDP packet is sent off by the application process and no guarantee is made that it will reach the destination application process.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP packet Length | UDP packet checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All four fields are 16-bit quantities. The UDP checksum is frequently
not used, and the packet length is actually redundant based on
other information (like the fact that the header is constant size
and the IP header contains a packet length field).
UDP is useful for situations that don't require the guarantee of delivery, and where all the data to be transmitted is small. Applications like this include DNS queries, finger, or ntp (which is used to synchronize time on different hosts). UDP is also useful because it is fast. There is no overhead involved in sending a UDP packet in comparison to sending a TCP packet.
TCP is the Transmission Control Protocol. Unlike UDP, TCP is considered to be both reliable and connected . The point is that both ends of a TCP connection maintain state about that connection; the connection is negotiated initially, and every transmission is given an ID and it must be specifically acknowledged by the receiving end. Unacknowledged data is retransmitted until acknowledgement is received.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source and destination port numbers are both 16-bit quantities.
The Sequence number is the ID number of the current TCP packet, a
32-bit quantity. The 32-bit Acknowledgment number is set to be the
ID sequence number of the TCP packet being acknowleged (if the ack flag
is set). Various flags are set by TCP to indicate certain conditions:
The Domain Name System is used to map between symbolic hostnames like bfs.cs.colorado.edu and IP addresses like 128.138.202.9 . Programs make use of C library routines (called the resolver library) to access the DNS system. The file /etc/resolv.conf is referenced to determine in what domain a given (unqualified) hostname should be look for, as well as the IP addresses of nameservers to contact for information. Here is the /etc/resolv.conf file from bfs :
bfs:tor % cat /etc/resolv.conf
search cs.colorado.edu colorado.edu
nameserver 128.138.202.19 ; nago
nameserver 128.138.202.9 ; bfs
nameserver 128.138.243.151 ; mroe
nameserver 128.138.192.205 ; suod
bfs:tor %
The first line gives a list of domains to search, while the remaining lines
specify nameservers. Each is tried in turn, and subsequent nameservers
are only accessed if earlier ones don't respond to queries.
You can interface with DNS using a command-line utility called nslookup(8) :
bfs:tor % nslookup suod
Server: nago.cs.colorado.edu
Address: 128.138.202.19
Name: suod.cs.colorado.edu
Addresses: 128.138.192.205, 128.138.243.135
bfs:tor %
The command first tells you the name and address of the nameserver you
are contacting and then gives the query results. It may also be used
interactively.
I only briefly want to mention multicast IP. Most routers on the internet do not yet understand multicast IP. In order for routers that do understand it to talk to one another, they re-encapsulate multicast IP data inside another IP packet to safely send through NON multicast aware routers. The destination multicast router will unwrap the outer (extra) IP packet before sending it onto to local multicast destinations.
This concept of wrapping IP inside IP is known as tunneling and has many other uses: notably, you can use SSH to tunnel other protocols like telnet or ftp. Read the ssh(1) manpage for more details.
A simple host is considered to be one with only a single network interface and only a single default route to the internet. In this section we'll look at basic information and commands necessary for configuring such a host on an ethernet subnet.
The following shell scripts are responsible for configuring a system's networking at boot time:
Lets look at another section from the afterboot manpage:
Verify network interfaces configured correctly
The first thing to do is an ifconfig -a to see if the network interfaces
are properly configured. Correct by editing /etc/hostname.interface
(where interface is the interface name, e.g. ``le0'') and then using if-
config(8) to manually configure it if you do not wish to reboot. The
loopback interface will look something like:
lo0: flags=8009<UP,LOOPBACK,MULTICAST>
inet 127.0.0.1 netmask 0xff000000
an ethernet interface something like:
le0: flags=9863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
inet 192.168.4.52 netmask 0xffffff00 broadcast 192.168.4.255
and, a PPP interface something like:
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST>
inet 203.3.131.108 --> 198.181.0.253 netmask 0xffff0000
There is a bit more to this section in the manpage, giving pointers
for multicast routing and DHCP .
To statically configure a TCP/IP network interface you need the following pieces of information:
le0 at ledma0 offset 0x8c00000 pri 6: address 08:00:20:1e:14:73
le0: 16 receive buffers, 4 transmit buffers
One easy way to recognize the ethernet devices in the dmesg output is
to look for the six byte ethernet address given in standard : separated
hexidecimal bytes like so:
08:00:20:1e:14:73
In this case we have an le ethernet driver, and our interface is le0 .
The le is a standard Lance chipset 10-base-T interface found on
Sparc hardware before the Ultra series Sparcs (which have hme fast
ethernet).
By the way: the first three bytes of the six-byte ethernet address (i.e. in this case 08:00:20 actually identify the manufacturer of the ethernet hardware. The three bytes 08:00:20 will only be found starting ethernet addresses on Sun manufactured ethernet boards. See: http://www.eiu.edu/~csec/mac_numbers.html for a list of similar relationships. The information can useful in helping to track down a network problem on a crowded subnet when IP level information is unavailable.
The command that is used to manipulate network interfaces is called ifconfig(8) . You can (usually) use the -a argument to ifconfig to have it list out currently recognized ethernet devices. Here are some examples:
saclass-2 % ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:10:83:02:56:72
inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:122935 errors:0 dropped:0 overruns:0 frame:0
TX packets:108812 errors:0 dropped:0 overruns:0 carrier:0
collisions:56 txqueuelen:100
Interrupt:10 Base address:0x6400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
The saclass-2 machine is a RedHat box. The ifconfig information you
get is quite verbose, but also very readable. You also get usage statistics
for each interface. Now look at the output on saclass the OpenBSD box:
saclass:tor {109} ifconfig -a
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32972
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
lo1: flags=8008<LOOPBACK,MULTICAST> mtu 32972
le0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet autoselect (10baseT)
inet 128.138.192.13 netmask 0xffffffc0 broadcast 128.138.192.63
inet6 fe80::a00:20ff:fe77:f46f%le0 prefixlen 64 scopeid 0x1
be0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet 10baseT (10baseT half-duplex)
status: active
inet6 fe80::a00:20ff:fe77:f46f%be0 prefixlen 64 scopeid 0x2
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
...
There are a whole bunch of interfaces listed when you type the 'ifconfig -a'
command on an OpenBSD box. You should notice that most of them are
not up .
Some versions of Un*x do not recognize the -a flag. Notably:
nag:tor % ifconfig -a
ifconfig: no such interface
nag:tor % ifconfig lan0
lan0: flags=b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,MULTICAST>
inet 128.138.202.20 netmask ffffff00 broadcast 128.138.202.255
nag:tor %
You can also use ifconfig to to turn network interfaces up or down
(where up means the interface is ready to send and receive packets).
Normally, a machine's network interfaces are ifconfig'd at boot time.
Sometimes, though, you will need to re-configure an interface because
it has invalid information - either because of a simple typo or because
the machine has been moved to a different IP address and subnet.
Also, if you are dealing with some remote machine with only one network interface you definately do not want to ifconfig that interface down because then the machine will suddenly be off the net and totally unreachable. The only solution is to go and log on to the machine's console and re-configure the interface.
Here is an example of configuring an interface. The machine is named coatlicue and it is the gateway box for my personal home network. I am configuring one of two ethernet interface on the machine, the interface that is "inside" talking on my internal net. See below for more details about this network.
First have a look at the interfaces:
coatlicue% ifconfig -a
lo0: flags=8009<UP,LOOPBACK,MULTICAST>
inet 127.0.0.1 netmask 0xff000000
lo1: flags=8008<LOOPBACK,MULTICAST>
le0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
media: Ethernet 10baseT
inet 198.11.19.5 netmask 0xffffff80 broadcast 198.11.19.127
le1: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
media: Ethernet 10baseT
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
coatlicue% ping 10.0.0.2
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=3.293 ms
Now, I'll use ifconfig to bring the interface down:
coatlicue% sudo ifconfig le1 down
Password:
And to prove it, watch ping now fail:
coatlicue% ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
ping: sendto: Network is down
ping: wrote 10.0.0.2 64 chars, ret=-1
Now, I'll ifconfig the interface back up, and we can see ping work again:
coatlicue% sudo ifconfig le1 up 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
coatlicue% ping 10.0.0.2
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=3.293 ms
Notice how you specify each necessary item of information when
you configure the interface: device , IP-address , netmask ,
and broadcast . The device and IP address are mandatory. If the netmask
or broadcast address are not specified, then ifconfig will make default
assumptions based on the class of the IP address and using a rule
that always places the broadcast address as the very last address on the
subnet.
Sometimes you will need to specify additional information that is relevant for a particular ethernet device. For example, on my SparcClassic, the on-board ethernet can be either AUI or 10baseT and this needs to specified (depending on which interface is used):
coatlicue % sudo ifconfig le0 up 198.11.19.5 netmask 0xffffff80 media 10baseT
You will need to read the ifconfig manpage as well as specific manpages
for your particular ethernet device if you need figure out this sort
of additional configuration information.
To change IP interface information on an OpenBSD box:
Again, let's take a look at the afterboot manpage:
Check for correct routing
Do a netstat -r -n command. The output will look something like:
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
default 192.168.4.254 UGS 0 11098028 - le0
127 127.0.0.1 UGRS 0 0 - lo0
127.0.0.1 127.0.0.1 UH 3 24 - lo0
192.168.4 link#1 UC 0 0 - le0
192.168.4.52 8:0:20:73:b8:4a UHL 1 6707 - le0
192.168.4.254 0:60:3e:99:67:ea UHL 1 0 - le0
Fix by editing the file /etc/mygate and using route delete and route add
if you do not wish to reboot. See route(8).
Every host keeps a list of current routing information known
as the machine's routing table . You use the route(8) command
to manipulate the information in this table. You can use the netstat(8)
command with the -r and -n flags to get a listing of the routing table.
For example,
let's look at the routing table for saclass.cs.colorado.edu :
saclass % netstat -rn | more
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 128.138.192.1 UGS 4 281214 1500 le0
10.0.0/24 link#2 UC 0 0 1500 be0
10.0.0.1 8:0:20:77:f4:6f UHL 0 399 1500 lo0
10.0.0.2 link#2 UHL 2 639 1500 be0
10.0.0.3 link#2 UHL 2 299966 1500 be0
127/8 127.0.0.1 UGRS 0 0 32972 lo0
127.0.0.1 127.0.0.1 UH 3 127 32972 lo0
128.138.192.0/26 link#1 UC 0 0 1500 le0
128.138.192.1 0:0:c:e:68:44 UHL 1 0 1500 le0
128.138.192.13 127.0.0.1 UGHS 1 18887 32972 lo0
224/4 127.0.0.1 URS 0 0 32972 lo0
...
For a simple host (unlike saclass )
with only a single network interface, there are three important items.
127.0.0.1 127.0.0.1 UH 3 2149 - lo0
128.138.192.0/26 link#1 UC 0 0 - le0
default 128.138.192.1 UGS 2 713247 - le0
The only difference between a simple host and a more complex one (with more
than one network interface) is that there are routes for each interface
redistered in the routing table. For example,
10.0.0/24 link#2 UC 0 0 1500 be0
The netstat command can also be used to show a number of other types
of network statistics for your machine. We will explore those uses
more below. The -r flag tell netstat to print the routing table and
the -n flag tells netstat to list hosts by IP address and not by
their symbolic hostnames. [ The reason for listing things by IP address
instead of their "symbolic" hostname is that if your nameservice - DNS -
is not working, then you will have a huge delay as the nameservice queries
timeout. ]
Each entry in the table lists routing information either for how to reach a particular network or how to reach a particular host .
128.138.192.22 8:0:20:1a:f4:9c UHL 3 67122 - le0
128.138.192.23 0:a0:cc:66:15:1e UHL 0 11327 - le0
So far in this section we have been looking at routing tables on an OpenBSD machine.
Now have a look at the routing table for a RedHat linux box:
xibalba % netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
This is a RedHat linux PC named xibalba that is one my private home subnet.
The linux routing table is a little unusual: what are all those 0.0.0.0 addresses?
In the first column (the Destination ) the 0.0.0.0 address means default route .
The 0.0.0.0 address in the Gateway column can be interpreted as local interface
(i.e. the host's own ethernet or loopback interface.
coatlicue % sudo route delete default
coatlicue % sudo route add default 10.0.0.1
xibalba % sudo route delete default
xibalba % sudo route add default gw 10.0.0.1
The two OS's route commands are fairly similar for adding and removing the
default route; notice the RedHat ( xibalba ) version requires the gw argument.
The last item on the agenda in terms of setting up the network personality of a simple host is to configure your nameservice files. And, finally, one last look at the afterboot manpage:
BIND Name Server (DNS)
If you are using the BIND Name Server, check the /etc/resolv.conf file.
It may look something like:
domain nts.umn.edu
nameserver 128.101.101.101
nameserver 134.84.84.84
search nts.umn.edu. umn.edu.
lookup file bind
If using a caching name server add the line "nameserver 127.0.0.1" first.
For a local caching name server to run you will need to set "named_flags"
in /etc/rc.conf and create the named.boot file in the appropriate place
for named(8). The same holds true if the machine is going to be a name
server for your domain. In both these cases, make sure that named(8) is
running (otherwise there are long waits for resolver timeouts).
As you know, nameservice is the system by which a client host can query
a name server to translate symbolic hostnames (e.g. bfs.cs.colorado.edu )
into IP addresses (e.g. 128.138.202.9 ).
We will talk about the Domain Name System ( DNS ) in more detail next week,
as well as the basic configuration concepts necessary for a DNS server.
Setting up a client host for using DNS is much easier.
Software applications make use of DNS through a special C library
called the resolver library. The process of converting a hostname into
an IP address is known as address resolution .
To configure a a client host's nameservice you need to edit the /etc/resolv.conf file. Here is the file from saclass :
saclass % cat /etc/resolv.conf
search cs.colorado.edu
nameserver 128.138.202.19
lookup file bind
The first line of this file gives a list of domains to be searched to find
a given host. The list may contain arbitrarily many space seperated domain names.
For example, if your home machine was in the domain of your ISP, say indra.net and
you wanted to also reference cs.colorado.edu hosts by only their unqualified
hostname (e.g. bfs ) then you could use a search line as follows:
search indra.net cs.colorado.edu
The second line specifies the IP address of a nameserver that will be
contacted to for nameservice queries. There may be up to three of these
lines (and there should be for robustness) and each nameserver is queried
in order with subsequent servers only being used if previous ones do
not return answers (i.e. the nameserver machine is down or broken).
The final line is an option that can be specified in the OpenBSD resolv.conf file only. This line specifies that the resolver libraries should first check the local /etc/hosts file to find IP addresses and only query a nameserver if the hosts file does not contain a match (i.e. the specified hostname is not in the hosts file). You can change this behavior in exactly the same fashion on a RedHat (or other SysV-like OS's) box by editing the /etc/nsswitch.conf file; the relevant line this file might look like this:
hosts: files dns
Again, this tells the resolver library to first check the /etc/hosts file
and then contact a nameserver.
Both the OpenBSD and RedHat resolver libraries may be give a number of different options to control such things as the timeout length between unanswered queries and the number of attempts tried before giving up on a given server. Read the following manpages for details:
We saw in class how to set up both OpenBSD and RedHat Linux boxes to be DHCP clients. This means that, when their network interfaces are configured, instead of specifying a static IP address, the DHCP protocol is used to request a dynamic IP address from a (local) DHCP server. Setting up such a server under OpenBSD is trivial. Turn on the DHCP service in the /etc/rc.conf file and then edit the file /etc/dhcpd.conf to indicate the range of IP addresses that can be given out. You can also match specific IP addresses to specific ethernet addresses.
Here is part of the configuration file on my home gateway box:
shared-network LOCAL-NET {
option domain-name "colorado.edu";
option domain-name-servers 128.138.129.76, 128.138.240.1;
subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.1;
default-lease-time 3600;
range 10.0.0.33 10.0.0.34;
range 10.0.0.38 10.0.0.127;
host judith {
hardware ethernet 00:90:27:66:de:a5;
fixed-address 10.0.0.32;
}
host baelzebub {
hardware ethernet 0:d0:9:2c:be:6e;
fixed-address 10.0.0.35;
}
}
}
To see the slides that I used in the lecture, see: ./snmp.HTML/index
The TCP/IP Illustrated: The Protocols, Vol. 1
W. Richard Stevens
bn.com Price: $53.75
In-Stock: Ships within 24 hours
Format: Hardcover, 576pp.
ISBN: 0201633469
Publisher: Addison Wesley Longman, Inc.
Pub. Date: November 1993
TCP/IP Illustrated: The Implementation, Vol. 2
Gary R. Wright W. Richard Stevens
bn.com Price: $64.00
In-Stock: Ships within 24 hours
Format: Hardcover, 1200pp.
ISBN: 020163354X
Publisher: Addison Wesley Longman, Inc.
Pub. Date: October 1994
TCP/IP Illustrated, Vol. 3
W. Richard Stevens Gary R. Wright
bn.com Price: $45.95
In-Stock: Ships 2-3 days
Format: Hardcover, 328pp.
ISBN: 0201634953
Publisher: Addison Wesley Longman, Inc.
Pub. Date: January 1995
UNIX Network Programming: Networking APIs: Sockets and XTI, Vol. 1
W. Richard Stevens
bn.com Price: $66.75
In-Stock: Ships within 24 hours
Format: Hardcover, 2nd ed., 1009pp.
ISBN: 013490012X
Publisher: Prentice Hall
Pub. Date: July 1997
Advanced Programming in the UNIX Environment
W. Richard Stevens R. Richard Stevens
bn.com Price: $55.75
In-Stock: Ships within 24 hours
Format: Hardcover, 1st ed., 768pp.
ISBN: 0201563177
Publisher: Addison Wesley Longman, Inc.
Pub. Date: February 1992
Internetworking with TCP/IP: Principles, Protocols, and Architecture, Vol. 1
Douglas E. Comer David L. Stevens
bn.com Price: $64.75
In-Stock: Ships within 24 hours
Format: Hardcover, 3rd ed., 613pp.
ISBN: 0132169878
Publisher: Prentice Hall
Pub. Date: April 1995
Internetworking with TCP\IP: Design, Implementation, and Internals, Vol. 2
Douglas E. Comer David Stevens
bn.com Price: $64.75
In-Stock: Ships 2-3 days
Format: Hardcover, 2nd ed., 525pp.
ISBN: 0131255274
Publisher: Prentice Hall
Pub. Date: April 1994
Edition Desc: 2ND
Go to: top /
index
Source document: class05.txt
Last modified: 0
Category: guide
Obsoletes: