Au 079 Inst

V3.1.0.
cover
Front cover
AIX 5L
TCP/IP I: Configuring
(Course Code AU07)
Instructor Guide
ERC 9.1
IBM Certified Course Material

Instructor Guide
Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AFS AIX AIX 5L
DFS HACMP MVS
pSeries RISC System/6000 RS/6000
SecureWay SP System/370
400
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Intel, Intel Inside (logos), MMX and Pentium are trademarks of Intel Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product and service names may be trademarks or service marks of others.
June 2006 Edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an as is basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
Copyright International Business Machines Corporation 1997, 2006. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
V3.1.0.1
Instructor Guide
TOC Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Instructor Course Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Course Presentation Material Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Unit 1. TCP/IP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
What Is TCP/IP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Requests for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
An Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
TCP/IP Layering for AIX/UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Network Support in AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Media Access Control (MAC) Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
IP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Internet Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Internet Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Internet Address Class Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
Special Internet Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-47
Physical and Logical Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50
LANs and Address Resolution Protocol (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53
ICMP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
Ports and Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-60
/etc/services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64
Connectionless versus Connection Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-66
UDP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-70
TCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
The TCP Window Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-77
Some Standard TCP/IP Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-80
UDP Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-83
TCP Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-86
Network Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
LAN Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-93
Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-97
Subnetted Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-100
Subnetting Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-103
Default Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-106
Subnet Mask Off-the-Byte Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-108
Subnetting Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-112
Copyright IBM Corp. 1997, 2006 Contents iii

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Optional Activity: Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-114

Supernetting (CIDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-116
IP Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-119
IP Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-121
Checkpoint (1 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-124
Checkpoint (2 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-126
Checkpoint (3 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-128
Checkpoint (4 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-130
Exercise: TCP/IP Concepts - IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-132
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-134
Unit 2. Hardware Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
HMC Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
HMC Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
Configuring a New HMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
Guided Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12
HMC Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14
Information Center and Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17
HMC Server Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
HMC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22
HMC Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-25
Network Settings - Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-27
Network Settings - LAN Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-29
Network Settings - LAN Adapter Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31
Network Settings - LAN Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-35
Network Settings - Name Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-38
Network Settings - Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-40
Connecting HMC to Managed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-43
HMC and Managed System LAN Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-47
Remote Access to the HMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50
Enable or Disable Remote Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-53
Load WebSM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-55
Remote HMC Login Using WebSM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-58
Using HMC Commands Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-61
HMC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-63
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-65
Exercise: HMC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-67
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-69
Unit 3. Configuring TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
TCP/IP Software Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4
TCP/IP Customization Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
Configuring Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
Ethernet Network Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13
Defining and Configuring Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
iv AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
TOC Minimum Configuration and Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17

Further Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
ifconfig Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Host Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
/etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Starting Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
/etc/inetd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
TCP/IP Startup Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35
Verifying Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Verifying Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Verifying Address Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Verifying Open Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Unit 4. Configuring Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
IEEE 802.1Q VLAN (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
IEEE 802.1Q VLAN (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Simple VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Adding VLAN Access (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Adding VLAN Access (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
What is Virtual I/O? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
Why Virtualize I/O? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Benefits of Virtualized I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
IBM System p5 VIrtual Ethernet Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
p5 Hypervisor Ethernet Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
Virtual Ethernet Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Creating a Virtual Ethernet Adapter (1 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37
AIX Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
Multiple VLANs on a Virtual Ethernet Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Virtual Ethernet VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54
21 Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58
Unit 5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Gateways for TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Routing Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
IP Routing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Copyright IBM Corp. 1997, 2006 Contents v

Instructor Guide
Viewing the Routing Table: netstat -rn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13

Establishing Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16
Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
Configuring Routing through SMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
route Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24
route Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-26
Routing Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28
ICMP Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-31
ping -R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-33
traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-35
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-37
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-39
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-41
Unit 6. Dynamic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
Dynamic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Autonomous Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
Routing Information Protocol (RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10
How RIP Updates Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13
RIP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-15
How RIP Handles Multiple Paths to the Same Network . . . . . . . . . . . . . . . . . . . . .6-17
Configuring the routed Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19
RIP Version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-22
/etc/gated.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25
gdc Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-28
Configuring RIP Using the gated Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-32
Opening Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-35
OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-37
Configuring OSPF Using the gated Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-39
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-41
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-43
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-45
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-47
Unit 7. Shared Ethernet Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
Virtual I/O Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5
Virtual I/O Server Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8
Configuring the Virtual I/O Server (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-11
Configuring the Virtual I/O Server (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14
Shared Ethernet Adapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16
Shared Ethernet Adapter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
Adding External Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-21
Shared Ethernet Adapter Bridge (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-23
What is Link Aggregation? (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-32
vi AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
TOC What is Link Aggregation? (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34

Network Interface Backup (NIB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38
Etherchannel Prior to AIX 5L V5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-41
Add a Link Aggregation (AIX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-44
Add a Link Aggregation (VIOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-48
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-50
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-52
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-54
Unit 8. Network Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Virtual IP Address (VIPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Create Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Multipath Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Cost Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Displaying the User-configurable Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Setting the Cost Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Current Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Multipath Routing Policy (AIX 5L V5.2 and Later) . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
What is Path MTU? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
Enabling/Disabling Path MTU Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
Path MTU Discovery and Multipath Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
Dead Gateway Detection (DGD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Passive DGD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Active DGD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
Active DGD Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Network Tunables (no Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38
Managing Tunables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41
Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-51
Unit 9. Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Internet Domain Name Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
DNS Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
DNS Reverse Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Types of Name Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Forwarded Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Domain or Flat Network? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Planning a Domain Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
BIND Version Support in AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31
Scenario - Domain Name Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
Copyright IBM Corp. 1997, 2006 Contents vii

Instructor Guide
Setting Up the Primary Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-37

/etc/named.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-39
Scripts to Build Zone Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-41
Name Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-43
IP Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-47
Local IP Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-50
Cache File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-52
Final Primary Name Server Setup Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-55
Setting Up the Secondary Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-57
Secondary named Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59
Local IP Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-61
Cache File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-63
Final Secondary Name Server Setup Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-65
Caching-Only Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-67
Setting Up the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-69
Conversion to BIND 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-72
Controlling the named Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-74
Active Database Dump Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-76
Adding a Static Host to the Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-78
nslookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-80
Noninteractive Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-82
Interactive Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-84
Debugging with nslookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-86
dig Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-89
Checkpoint (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-91
Checkpoint (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-93
Checkpoint (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-95
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-97
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-99
Unit 10. Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
Dynamic Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7
BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-10
Leasing an IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-13
DHCP Client-Server Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-15
DHCP Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-19
Selected DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-21
DHCP AIX Implementation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-23
Configure a DHCP Server on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-26
/etc/dhcpsd.cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-29
Configuring a DHCP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-32
Configuring a DHCP/BOOTP Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-34
Dynamic DNS Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-36
DDNS Update Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-38
DDNS Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-41
DDNS Wrapper Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-44
viii AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
TOC Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-46

Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-48
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-50
Unit 11. Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Debugging Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
TCP/IP Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Overview of Troubleshooting Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
List System Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
List Device Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
List Device Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16
Network Interface Parameters Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
snap Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
Display Network Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22
Test Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24
Test Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28
Check Address Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Isolating Name Resolution Problems with DNS . . . . . . . . . . . . . . . . . . . . . . . . . 11-33
Display Network Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-35
Display Transport UDP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-37
Display Transport TCP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-39
Display Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
Display pmtu Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-45
Display Network Interface Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-47
Monitor State of an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-49
Display Device Driver Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-51
Display Dropped Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-53
Trace Packets with the iptrace Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-55
iptrace Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-57
View a Trace Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-60
Sample Problem Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-62
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-65
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-67
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-69
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-71
Unit 12. NFS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Sharing Data on a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
NFS Version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
NFS Networking Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Stateless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
Exporting Server File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Local Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
Remote Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21
mount Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Copyright IBM Corp. 1997, 2006 Contents ix

Instructor Guide
CacheFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25
Virtual File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-27
NFS Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29
portmap Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-31
mountd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-33
biod (Block I/O Daemon) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-35
nfsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-37
How NFS Shared Files Are Protected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-39
UNIX Authorization - Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-41
UNIX Authentication - Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-44
ACL Support in NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-46
NFS File Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-48
NFS File Lock Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-50
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-55
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-57
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-59
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-61
Unit 13. Configuring NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2
Prerequisite Conditions for Implementing NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4
Implementation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6
Configuring the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8
Identify What to Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10
The /etc/exports File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12
exportfs Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-14
/etc/rc.nfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-16
/etc/inittab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19
Activating an NFS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21
Client Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-23
Create Local Mount Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-25
Start NFS Client Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-27
Manual Remote Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-29
Manual cacheFS Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-32
cfsadmin Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-34
Why Do Manual Mounts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-37
Predefined Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-39
Creating Predefined Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-41
The /etc/filesystems File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-43
Options Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-45
Predefined Mounts Invoked From Command Line . . . . . . . . . . . . . . . . . . . . . . . .13-48
Activating an NFS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-50
Using SRC to Manage NFS Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-52
Stopping and Starting NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-54
Unmounting Remote Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-57
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-60
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-62
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-64
x AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
TOC Unit 14. Automounter and NFS Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Automounter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
Automounter Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Automount Indirect Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Automount Direct Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Automount Master Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
automount Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14
Automounter Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16
Invoking the Remote Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18
Remote Mount Table Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20
NFS Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22
/etc/inetd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
What a Server Is Exporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
rpcinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
Appendix A. Checkpoint and Activity Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Appendix B. Command Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Appendix C. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
Appendix D. TCP/IP and NFS/NIS Commands and Files. . . . . . . . . . . . . . . . . . . . D-1
Appendix E. Summary of the no Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .X-1
Copyright IBM Corp. 1997, 2006 Contents xi

Instructor Guide
xii AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
TMK Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AFS AIX AIX 5L
DFS HACMP MVS
pSeries RISC System/6000 RS/6000
SecureWay SP System/370
400
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Intel, Intel Inside (logos), MMX and Pentium are trademarks of Intel Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product and service names may be trademarks or service marks of others.
Copyright IBM Corp. 1997, 2006 Trademarks xiii

Instructor Guide
xiv AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
pref Instructor Course Overview

This is a five-day course for personnel responsible for the
configuration, support, and use of TCP/IP on AIX Version 5. This
course has 14 lectures units and 13 exercises. It teaches the skills
necessary to begin implementing and using Kerberos, DHCP, Virtual
Ethernet, static and dynamic routing, DNS, and NFS. Also included is
a unit on troubleshooting common network problems. The course
emphasis should be on configuring and implementing TCP/IP and its
related applications in the AIX environment. In order to do this, some
discussion of concepts is provided before delving into the sections that
cover the configuring steps. However, go into only as much depth as is
reasonably needed to set up and do simple problem determination.
Due to the needs of different audiences, the Instructor Notes often
include additional information that provides greater depth than might
normally be covered. This information is provided as a means to
handle these varying audiences and is by no means expected to be
included as part of the normal discussion unless the need arises.
Consider all additional information material as handy reference
material. For those individuals interested in exploring in detail the
concepts, theory, and algorithms behind the various protocols and
applications, there are several in-depth architecture courses available
from IBM. This course was designed to first cover topics related to the
TCP/IP protocol suite including name service and troubleshooting, and
then finish the week with a discussion of two commonly used
applications built on a TCP/IP foundation, and NFS. This course has
been updated to support AIX 5.3 environment.
Copyright IBM Corp. 1997, 2006 Instructor Course Overview xv

Instructor Guide
Course Description
AIX 5L TCP/IP I: Configuring
Duration: 5 days
Purpose
The purpose of this course is to teach TCP/IP network configuration
and administration including the skills necessary to begin
implementing and using Dynamic Host Configuration Protocol
(DHCP), Virtual Ethernet, Shared Ethernet Adapter, static and
dynamic routing, Domain Name System (DNS) and Network File
System (NFS) on AIX 5L.
Audience
Network Administrators or other personnel responsible for the
configuration, use, and support of TCP/IP and common network
services on AIX 5L.
Prerequisites
Students should have completed the following course:
AIX 5L System Administration I: Implementation (AU14/Q1314)
Or have the following basic AIX skills:
Have a working knowledge of the AIX environment and commands
Be able to work with SMIT in configuring your system
Be able to edit files with vi (visual editor)
Understand file systems, directories, files, and their security
Understand the concept of mounting file systems
Have a basic knowledge of general networking concepts
Objectives
After completing this course, you should be able to:
Discuss the basic concepts of TCP/IP protocols and addressing
Describe TCP/IP broadcasting and multicasting functions
Configure TCP/IP on AIX
xvi AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
pref Configure Virtual Ethernet connections on AIX

Connect multiple TCP/IP networks using static and dynamic
routing
Configure Shared Ethernet Adapter
Describe Domain Name System (DNS) function
Configure DNS on AIX
Describe Dynamic Host Configuration Protocol (DHCP) function
Configure DHCP on AIX
Perform basic troubleshooting of network problems
Describe Network File System (NFS) function
Configure NFS on AIX
Contents
TCP/IP protocols and addressing
TCP/IP broadcasting and multicasting
TCP/IP subnet masking
Configuring TCP/IP
Configuring Virtual Ethernet
Static and dynamic routing
Shared Ethernet Adapter
Configuring Virtual IP Address (VIPA), multipath routing, dead
gateway detection, and network options (no command)
Domain Name System (DNS) configuration
Dynamic Host Configuration Protocol (DHCP)
Introduction to troubleshooting network problems
NFS Concepts
Configure NFS
Copyright IBM Corp. 1997, 2006 Course Description xvii

Instructor Guide
Course Agenda
Day 1
(00:30) Introduction
(03:00) Unit 1 TCP/IP Concepts
(00:45) Exercise 1 IP Addressing and Subnetting
(01:15) Unit 2 Hardware Management Console
(01:00) Exercise 2 HMC Configuration
Day 2
(01:05) Unit 3 Configuring TCP/IP
(00:40) Exercise 3 Configuring TCP/IP
(01:00) Unit 4 Configuring Virtual Ethernet
(01:00) Exercise 4 Configuring Virtual Ethernet
(01:00) Unit 5 Routing
(00:50) Exercise 5 Static Routing
Day 3
(01:00) Unit 6 Dynamic Routing
(00:20) Exercise 6 Dynamic Routing
(01:00) Unit 7 Shared Ethernet Adapter
(01:00) Exercise 7 Shared Ethernet Adapter
(00:30) Unit 8 Network Control
(01:00) Exercise 8 Configuring Network Options
Day 4
(02:30) Unit 9 DNS
(00:45) Exercise 9 DNS
(01:15) Unit 10 DHCP
(01:00) Exercise 10 DHCP
(01:00) Unit 11 Problem Determination
(00:30) Exercise 11 Problem Determination
Day 5
(01:00) Unit 12 NFS Concepts
(01:00) Unit 13 Configuring NFS
(01:00) Exercise 12 Configuring NFS
(00:40) Unit 14 Automounter and NFS
(00:40) Exercise 13 Automounter and NFS
xviii AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
pref Course Presentation Material Overview

Included in this package are landscape, black and white paper copies of each of the
student visuals included in the Student Notebook. The paper copies are to be used to
reproduce overhead transparencies require to teach the course. It is recommended that
black-on-clear transparencies be used to reproduce the package.
In addition to the student visuals, a welcome visual SHOULD be included. To ensure that
each student is attending the correct course for which they originally enrolled, the welcome
visual should be used to provide the student with the course name and course code upon
entering the classroom.
It is advised that upon checking out the classroom prior to the start of class, there be two
overhead projectors in the classroom. This will guarantee that there is a working overhead
projector available at all times for the duration of the class.
The paper copies and the transparencies created from the paper copies are the property of
IBM. By way of protecting our intellectual properties, neither the paper copies nor the
transparencies should be given to anyone other than a course certified instructor. The
copies are not to be used for any purpose other than teaching the course. The security of
this package and the products created as a result of this package are the responsibility of
the course certified instructor.
Copyright IBM Corp. 1997, 2006 Course Presentation Material Overview xix
Instructor Guide
Text highlighting
The following text highlighting conventions are used throughout this book:
Bold Identifies file names, file paths, directories, user names,
principals, menu paths and menu selections. Also identifies
graphical objects such as buttons, labels and icons that the
user selects.
Italics Identifies links to web sites, publication titles, is used where the
word or phrase is meant to stand out from the surrounding text,
and identifies parameters whose actual names or values are to
be supplied by the user.
Monospace Identifies attributes, variables, file listings, SMIT menus, code
examples and command output that you would see displayed
on a terminal, and messages from the system.
Monospace bold Identifies commands, subroutines, daemons, and text the user
would type.
xx AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
Uempty Unit 1. TCP/IP Concepts
What This Unit Is About

This unit is an introduction to networking and Transmission Control
Protocol/Internet Protocol (TCP/IP). It describes the protocols of
TCP/IP, explains how those protocols work together, and defines
important terminology associated with TCP/IP. It also goes into detail
about network addressing.
What You Should Be Able to Do

After completing this unit, you should be able to:
Describe the layered TCP/IP model
List and describe the protocols included in the TCP/IP protocol
suite
Explain network addressing
Define key networking terms
Interpret an IP address given the address and its subnet mask
Explain the purpose of multicasting
How You Will Check Your Progress

Accountability:
Checkpoint questions
Paper exercises
References
Info Center AIX 5L Version 5.3 Commands Reference
Info Center AIX 5L Version 5.3 System Management Guide:
Communications and Networks
Copyright IBM Corp. 1997, 2006 Unit 1. TCP/IP Concepts 1-1

Instructor Guide
Unit Objectives
After completing this unit, the student should be able to:
Describe the layered TCP/IP model
List and describe the protocols included in the TCP/IP protocol
suite
Explain network addressing
Define key networking terms
Interpret an IP address given the address and its subnet mask
Explain the purpose of multicasting
Copyright IBM Corporation 2006
Figure 1-1. Unit Objectives AU079.1
Notes:
1-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
Uempty Instructor Notes:

Purpose Introduce the objectives to be covered in the TCP/IP concepts lecture.
Details This is a long unit; be sure to take breaks at appropriate intervals.
In this lecture, we want to agree on the meanings of some networking terms and become
familiar with the basic architecture and protocols. We then go into some depth on the most
common TCP/IP interfaces and TCP/IP addressing.
Our attempt is to go to a level that can aid in understanding how to configure a system. We
avoid going to full depth on the architecture and protocols. Our purpose is developing
configuring skills. We want to emphasize the hands-on time in the lab exercises.
Discussion Items How many of you already have worked with TCP/IP networks? To
what degree? For how many of you is this completely new, somewhat new, or review?
Transition Statement Let's first look at what TCP/IP is.

Instructor Guide
What Is TCP/IP?
Transmission Control Protocol/Internet Protocol
Protocol suite used on the Internet
Set of protocols (rules) which define how computers (hosts)
communicate on a network
Designed for heterogeneous systems
Supports different network types
Open standards
Figure 1-2. What Is TCP/IP? AU079.1
Notes:
Introduction
The acronym TCP/IP stands for Transmission Control Protocol/Internet Protocol. A
more accurate name for this set of protocols is the Internet Protocol Suite, which is
sometimes referred to simply as the IP Stack.
A set of protocols
TCP/IP is a set of protocols or rules that define various aspects of how two computers in
a network may communicate with each other. A protocol is a set of rules which describe
the mechanisms and data structures involved. Using these definitions, vendors can
write software to implement the protocols for particular systems.

V3.1.0.1
Instructor Guide
Uempty Functions of various protocols

There are many different protocols which cover different aspects of networking, such as
addressing hosts in the network, data representation and encoding, message passing,
interprocess communications, and application features, such as how to send mail or
transfer files across the network.
Networking protocols support a variety of systems

Where possible, the protocols are defined independently of any operating system,
network hardware, or machine architecture. In order to implement TCP/IP on a system,
interface software must be written to allow the protocols to use the available
communications hardware.

Instructor Guide
Instructor Notes:
Purpose Provide a brief description of what the acronym TCP/IP stands for and what it
can do.
Details This visual is meant to be used as a starting place for our discussion of the
various protocols that make up the suite commonly called TCP/IP. Emphasize that TCP/IP
is a suite or group of protocols that are organized into layers. We discuss the various layers
and the more commonly used protocols in each layer as we proceed through this unit.
Transition Statement Now that we know what TCP/IP is, let's see how it came into
being.

V3.1.0.1
Instructor Guide
Uempty
History
Late 1960s DARPA primary funding agency
Mid 1970s ARPANET point-to-point leased line

interconnection
1980 Internet established, ARPANET as
backbone
1983 Use of TCP/IP mandatory in
ARPANET
Mid 1980s BSD UNIX incorporates TCP/IP
Late 1980s TCP/IP available on almost all

computer systems
1990s TCP/IP becomes protocol of choice
for most organizations; explosive
growth of Internet
Figure 1-3. History AU079.1
Notes:
Initial funding
TCP/IP is the result of work commissioned in 1968 by the US Department of Defense,
Advanced Research Projects Agency (DARPA). Many other research and vendor
organizations have contributed to the development of TCP/IP.
Role of ARPANET
Using leased lines, DARPA implemented a point-to-point network called ARPANET with
protocols which eventually evolved into TCP/IP. In 1980, ARPANET became the
backbone to the Internet which linked many US government, military, research,
educational, and commercial organizations. By 1983, all hosts in ARPANET, now called
the Internet, used TCP/IP protocols.

Instructor Guide
Association of TCP/IP and UNIX

The popularity of TCP/IP has been due mainly to its association with UNIX systems. In
particular, DARPA provided funding for the University of California, Berkeley to integrate
TCP/IP into the Berkeley Software Distribution (BSD).
Widespread use
TCP/IP currently is widely used throughout the world.

V3.1.0.1
Instructor Guide

Purpose Discuss the timeline on the history of TCP/IP.
Details Cover the key dates as listed.
TCP/IP began as a US government research project to address heterogeneous
networking. Money was given to BSD to code it. A trial network was built in universities and
government research labs to test it--ARPANET.
It became immensely popular for a variety of reasons:
Need for heterogeneous networking solution-most vendors had good networking
protocols for only their systems
Growth of UNIX--95% of CS departments at universities
Inexpensive
Simple, small size of code
Federal government required
The point of our discussion is not that TCP/IP is the best networking protocol, although it
has many virtues. Our point is that the marketplace is choosing it right now for
heterogeneous networking. Now, what is it and how do we configure it?
TCP/IP development was from a pragmatic view--since it was developed as a research
project, the developers did not have deep pockets for design, development,
documentation, or support.
The focus has always been on can you make it work on the network (Internet)?
Additional Information Networks have become a fundamental part of today's
information systems. They form the backbone for information sharing in enterprises,
governmental and scientific groups.
Transition Statement The TCP/IP protocol suite is not owned by any specific
organization. To ensure that the evolution and development of new protocols follow some
sort of standard procedure, the Internet Activity Board, later named Internet Architecture
Board, was founded. They control and manage further Internet protocol development. This
development involves the use of documents called Requests for Comments (RFCs). Let's
take a look at how this works.

Instructor Guide
Requests for Comments (RFCs)
RFC 791
Internet
Protocol
Issued by Internet Architecture Board (IAB)

TCP/IP standards
Information on managing TCP/IP networks
Identified by number with larger numbers indicating newer RFCs
Figure 1-4. Requests for Comments (RFCs) AU079.1
Notes:
Organizations involved in TCP/IP development

Some TCP/IP development is initiated by an organization called the Internet
Architecture Board (IAB), which oversees development of the Internet network and the
TCP/IP software it uses. The actual development of standards is performed by the
Internet Engineering Task Force (IETF) which reports to the IAB. The IETF is divided
into a number of working groups which pursue specific projects. Other TCP/IP
development is performed by vendor organizations that write protocols which may
become Internet standards.

V3.1.0.1
Instructor Guide
Uempty The RFC process

The IAB distributes documents called Requests For Comments (RFCs) which describe
TCP/IP protocols and provide other relevant information. RFCs are the primary source
of TCP/IP and Internet information. They include:
- Administrative information
- Requirements and guidelines
- Protocols and standards
- Measurement and statistics
- Historical information
Anyone can submit a document for publication as an RFC. Submissions must be made
via electronic mail to the RFC Editor. They are reviewed technically by the task forces,
individual technical experts, or the RFC Editor, as appropriate.
The RFC series consists of a wide range of documents, ranging from informational
documents of general interest to specifications of standard Internet protocols.
Once a document is assigned an RFC number and published, that RFC is never revised
or re-issued with the same number. There is never a question of having the most recent
version of a particular RFC. However, a protocol, such as File Transfer Protocol (FTP),
may be improved and redocumented many times in several different RFCs. It is
important to verify that you have the most recent RFC on a particular protocol.
Availability of RFCs
RFCs are available through the Internet from http://www.ietf.org.

Instructor Guide
Instructor Notes:
Purpose Show the process used to determine what changes are made to the TCP/IP
protocol suite.
Details Don't spend a lot of time discussing RFCs and the details of the process. Much
of the information provided here is to help answer questions students may have regarding
the RFC process.
Additional Information The following information is provided as an aid to instructors in
case students ask for more detailed information. It is not necessary to provide all this
information to students as it would be overkill for most at this point.
There are two independent classifications of protocols. The first is the maturity level or
state of standardization. State can be as follows:
Standard
Draft standard
Proposed standard
Experimental
Informational
Historic
The following is the requirement level or status of this protocol. Status can be as follows:
Required
Recommended
Elective
Limited use
Not Recommended
The status or requirement level is difficult to portray in a one-word label. The status labels
should be considered only as an indication, and a further description, or applicability
statement, should be consulted.
Transition Statement Now that you have a better understanding of how TCP/IP
developed, let's look closer at the environment in which it is used.

V3.1.0.1
Instructor Guide
Uempty
Network Topologies
LAN Hub
tch
Swi
Hub
Switched
MAN Network
direct-connect d
lease/line tche
Swi work
Net
WAN
modem
microwave
satellite
Figure 1-5. Network Topologies AU079.1
Notes:
Introduction
TCP/IP is supported on many different types of networks, from very low-speed serial
lines to cell-switched wide area networks, fast local area networks to very fast
multi-gigabit networks. Each vendor offers a variety of products to support a range of
network types.
Local area network (LAN)

Characteristics of a local area network (LAN) include the following:
- Offers high speeds (up to several gigabits/sec) over short distances (a few km)
- Computers must connect directly to network media (via a transceiver or tap)
- Provides networking for systems that are geographically close to one another

Instructor Guide
Metropolitan area network (MAN)

Key points regarding a metropolitan area network (MAN) include the following:
- Metropolitan area networks are networks which fall between a LAN and a WAN.
They cover a metro area and distances of approximately 5-100 km.
- Typical examples of MAN networks are Cell Switching ATM and Long Haul Fibre
Gigabit Ethernet.
- A MAN often acts as a high-speed network to allow sharing of regional resources
(similar to a large LAN). It is also frequently used to provide a shared connection to
other networks using a link to a WAN.
- Such networks are typically owned by ISPs.
Wide area network (WAN)

Key characteristics of a wide area network (WAN) include the following:
- Systems in the network can be far apart.
- Computers are often connected indirectly (modems, public telephone networks).
- Generally slower speeds than LANs, but catching up to LAN speeds. Some
examples:
ADSL 1.5 to 8.2 mbits/sec downstream, 64 kbits/sec to 1 mbits/sec upstream
T1 (US) up to 1.54 mbits/sec, E1 (Europe) up to 2 mbits/sec
T2 (US) up to 6.3 mbits/sec
T3 (US) up to 45 mbits/sec, E3 (Europe) up to 34.4 mbits/sec
T4 (US) up to 275 mbits/sec)
OC-3 up to 155.52 mbits/sec
- Medium: Copper can accommodate up to T2. For T3/T4, a higher frequency
medium is required such as microwave, satellite or fibre optic.
- Usually owned by multiple organizations.
- Mostly point-to-point connections.
Virtual local area network (VLAN)

Virtual local area networks (VLANs) can be thought of as logical broadcast domains. A
VLAN splits up groups of network users on a real physical network into segments of
logical networks.

V3.1.0.1
Instructor Guide

Purpose Introduce some networking terms.
Details Specifically, we want to compare/contrast a LAN, MAN and a WAN. The class
focus is LAN. By the end of the next page, the students are introduced to networking
terminology and understand it in the TCP/IP context.
At this point, the instructor should provide examples of LAN, MAN, and WAN
configurations.
Additional Information There are three basic types of local area network architecture:
Ring - information is passed sequentially in a circle
Bus - medium is shared by all; information is broadcast and all stations receive it
Star - central hub coordinates information passing between stations; point-to-point for
WAN
The IEEE 802.1Q VLAN support can be configured over any supported Ethernet adapters.
If connecting to a switch, the switch must support 802.1Q VLAN
The no option ifsize specifies the maximum number of network interface structures per
interface of a single type (e.g. Ethernet). The ifsize needs to be large on machines that
support hotplug adapters and on DLPAR configurations because adapters can be added
on the fly, and the static interface tables must be large enough to accept the worst case
number of adapters that may be added for this system or partition. Previously, the default
value of this parameter was 8, and it needed to be increased to include not only the
Ethernet interfaces for each adapter, but also any VLAN logical devices that were
configured. AIX 5L Version 5.3 documentation indicates that the default value of this
parameter has been increased to 256. (You can use the command no -L ifsize to verify
this or to demonstrate this to the students.) Also, the ifsize is now adjusted as required at
boot time. This should decrease the need for system administrator action to adjust this
parameter. See the entry for no in the AIX 5L Version 5.3 Commands Reference or the
corresponding man page for additional information.
Transition Statement Let's see what this all means in a typical interconnected
communications environment known as an internet.

Instructor Guide
An Internet
Gateway Serial router

Token
Ring modem modem
FDDI
router Gateway
X.25
Ethernet
Figure 1-6. An Internet AU079.1
Notes:
What is an internet?
An internet is a term applied to a number of networks connected or internetworked
together. An internet can be a combination of similar networks or of heterogeneous
networks. In an internet, data can be transferred transparently from one host to another
without the sending host needing to know the route taken or the type or number of
connections involved.
A well-known public internet is the Internet, which consists of millions of systems and
users.

V3.1.0.1
Instructor Guide
Uempty Internet-related terms

Some terms that are important to know when talking about systems and connections in
an internet are:
- host: A computer attached to the network
- local host: The computer at which the user is working
- foreign or remote host: Any other computer in the network
- server: A host that contains the information to be accessed
- client: A host requesting services or data from another computer
- Internet: Heterogeneous networks connected together
- router: A device that connects multiple networks
- gateway: In TCP/IP terminology, this is synonymous with router

Instructor Guide
Instructor Notes:
Purpose Identify the terms used for elements in a network. This sets the foundation for
the terminology used all week.
Details
host Any computer attached to the network with a TCP/IP address. This
includes machines of any size or functionality such as mainframes,
servers, workstations, PCs, terminals, printers, and so forth. Each host is
given a unique name and address so that it can be identified in the
network.
gateway/router In the context of TCP/IP, these two are historically synonymous. This is a
host with interfaces to two or more networks. This can be either a
dedicated machine that simply provides the function of moving data from
one network to another, or it can be a machine that does other work as
well, such as running applications.
client/server Hosts can play different roles in a network. As a client, a host plays the
role of a requestor of services from an application that is running often
times on another host in the network. The server is the provider of the
services being requested by the client. The types of services often
needed and supplied by client and server hosts and applications include:
print services
file sharing
computer sharing
Generally, TCP/IP hosts can function as both clients and servers at the same time, either
providing the same types of services or different services.
When working in a network, it is important to be aware of the system on which you are
currently working. In order to distinguish hosts, the following terminology is used:
Local host - the machine on which the user is working
Foreign (or remote) host - any other host on the network
Discussion Items If a system is a router with connections to three networks which
network does it belong to? Answer: It belongs to all three.
Transition Statement Let's begin to take a closer look at how the TCP/IP protocol suite
is put together.

V3.1.0.1
Instructor Guide
Uempty
TCP/IP Layering for AIX/UNIX
OSI 7 Layer Model TCP/IP Layer Model
Application FTP HTTP DNS TFTP

Application
Presentation TELNET SMTP NFS NIS SNMP
Session
Transport TCP UDP
Transport
Network Internet IPv4 IPv6 ICMP ARP
Ethernet IEEE 802.3 Token-Ring

Data Link Network
Interface X.25 PPP ATM FDDI
BNC UTP Cat 5 Fibre

Physical Physical
RJ45 Serial Copper AUI
Figure 1-7. TCP/IP Layering for AIX/UNIX AU079.1
Notes:
The OSI 7 layer model

The International Organization for Standardization (ISO) has specified a set of protocols
for connection of hosts on a network. This set of protocols is referred to as the Open
System Interconnection (OSI) 7 layer model. This model is the international standard for
networking and is a non-proprietary network architecture. It is a model that can be used
to describe different networking functions. Some applications, such as NFS,
implemented in TCP/IP are actually based on the OSI layering model, as we shall see
later in the week. When this is the case, the Presentation and Session layers have to be
hard coded into the application.

Instructor Guide
Usefulness of layered models

The OSI and TCP/IP models, like other networking architectures, are layered
descriptions. This layering is useful for at least two reasons:
- It simplifies the definitions, since only a limited set of functions needs to be defined
in each layer
- It simplifies migration to new technologies, since typically a new technology will only
affect one or two layers
The TCP/IP layer model

There are five layers defined for TCP/IP. As shown on the visual, each of these layers
includes several protocols. The five layers are the following:
- Physical
- Network interface
- Internet
- Transport
- Application
Only the Internet Protocol (IP) and the Internet Control Message Protocol (ICMP) at the
Internet layer are mandatory. The network below can be anything that supports remote
communication. An internet communication equipment supplier will have written IP
software that is compatible with the device and operating system and that also complies
with the communication requirements for internet hosts. As part of that software, there
must be a provision to report errors by means of ICMP. Usually, there is an Address
Resolution Protocol (ARP) that can correlate hardware addresses to IP addressing.
What is above the Internet protocol in the transport layer is very much up to the network
implementer. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
are most common, but there are dozens of other transport protocols available.
The individual layers in the TCP/IP model are described in more detail in the following
paragraphs.
Physical layer
The physical layer specifies electrical and mechanical characteristics of the hardware
used for communication.

V3.1.0.1
Instructor Guide
Uempty Network interface layer

The network interface is the connection to the actual network hardware. This interface
may or may not provide reliable delivery, and may be packet- or stream-oriented. In
fact, TCP/IP does not specify any protocol here, but can use almost any network
interface available, which illustrates the flexibility of the IP layer. Examples are IEEE
802.X (for local area networks such as the IBM Token-Ring Network or the
collision-detect IEEE 802.3 networks), X.25, Fiber Distributed Data Interface (FDDI),
serial, and asynchronous transfer mode (ATM).
Internet layer
The Internet layer provides the virtual network image of internet (that is, this layer
shields the higher layers from the typical network hardware architecture below it). The
Internet Protocol (IP) is the most important protocol here, or, to be exact, the Internet
Protocol is mandatory along with the Internet Control Message Protocol (ICMP). The
Internet layer does not provide reliability, flow control or error recovery, and also doesn't
assume reliability from the lower layers. It is a connectionless protocol.
Transport layer
The transport layer provides for the end-to-end delivery of data. As previously
mentioned, examples of protocols at this level are TCP (connection-oriented) and UDP
(connectionless).
Application layer
In this context, an application is a user process cooperating with another process on the
same or a different host. Examples are TELNET (protocol for remote terminal
connections), File Transfer Protocol (FTP) and Simple Mail Transfer Protocol (SMTP).
Glossary
Refer to the Glossary included in this document for a definition of terms used
throughout the course, including those referenced on this page.

Instructor Guide
Instructor Notes:
Purpose Briefly introduce the OSI 7 layer model and then concentrate on the TCP/IP
layered architecture. When describing the OSI model layers, make reference to a suitable
application like NFS which uses 7 layers. For example, Presentation = XDR, Session =
RPC.
Details Concept of protocol--Who does what and how you do it. Example of diplomatic
protocol. To open trade relations with a king, I do not run into his office and say, Let's do
business. My aide contacts his minister to set up a meeting. My aide opens the door; his
minister introduces us. We give greetings and acknowledgements. Now we begin to
exchange information. Networking protocol defines who does what networking services
when. How you do it is the syntax of the headers, size of packets, delay times, and so forth.
A protocol suite is a set of protocols that is designed to work together and satisfies the
requirements of a protocol model.
Powerful modularizing exists when you layer network services. This is defining who does
what. Refer to the drawing on the visual. You see designs like this in most all modern
networking protocols.
Physical layer: Sometimes you may come across only four layers in the TCP/IP model. If
this is the case, it is assumed the Network Interface layer and Physical layer have been
merged together.
Network Interface: Roughly equivalent to the device driver for the network hardware.
Responsible for detecting and possibly correcting errors that occur at the physical layer.
Internet Layer: Responsible for addressing routing and error handling within the network.
Transport Layer: Responsible for end-to-end delivery of data. Two modes of operation,
namely connection-oriented and connectionless communication.
Application Layer: User applications such as file transfer, electronic mail, network
management, and so forth.
The advantage of layering is that applications can run over different mediums without
rewriting. As new network technologies come out, porting is easier, simply add a device
driver. Also, as an application writer, you do not have to imbed networking protocols in a
program; you just have to identify the appropriate host to the protocol stack and hand it a
stream of data.
Discussion Items Do I want the application to be hard-coded for Token-Ring, Ethernet,
and so forth, or type of cabling? No--all this should be transparent to user and programmer.
Additional Information OSI Layers Information (If required!)
The Application Layer is the layer that most users of a computer are familiar with. The
Application Layer contains programs, compilers, and so forth. From a network point of
view, the user interfaces to network daemons and network utilities operate at this layer,
as well as super daemons.

V3.1.0.1
Instructor Guide
Uempty The Presentation Layer performs character set conversion, byte swapping, and so
forth.
The Session Layer performs the initiation and termination of interaction between
clients and servers. Applications may or may not have knowledge of the connections
taking place at the Session Layer.
The Transport Layer provides the mechanism to transport messages from one
process and one host to another process on the same or another host.
The Network Layer delivers packets from one host to another, with the hosts
potentially being located on different networks. The Network Layer uses virtual network
addresses to specify source and destination hosts.
The Data Link Layer provides the delivery of frames from one host to another, with the
hosts being connected on the same network. It also maps virtual network addresses to
physical network addresses.
The Physical Layer provides the actual transmission of data from one host to another.
This layer is controlled by hardware and firmware.
Transition Statement Let's take a closer look at the different layers of the TCP/IP
protocol layers of the TCP/IP protocol suite beginning at the network interface layer.

Instructor Guide
Network Support in AIX

Standard Ethernet (en) 10 mbit/sec - Gigabits/sec
IEEE 802.3 (et) 10 mbit/sec - Gigabits/sec
Token Ring (tr) 4 or 16 mbit/sec
FDDI (fi) 100 mbit/sec
X.25 (xs) 64 kb/sec
SLIP (sl) 64 kb/sec
PPP (pp) 64 kb/sec
ISDN (pp) 64 - 128 kb/sec
X.25 (xt) 64 kb/sec
ATM (at) 155 mbit/sec (OC3 SONET)
SOCC (so) 220 mbit/sec
Fibre Channel (fc) 800 mbit/sec
SP Switch (css) 1.2-4 gigabits/sec
Figure 1-8. Network Support in AIX AU079.1
Notes:
LAN interfaces
The Ethernet, IEEE 802.3, FDDI, and Token-Ring interfaces are for use with local area
networks.
Serial point-to-point WAN interfaces

The Serial Line Internet Protocol (SLIP), Point to Point Protocol (PPP), Integrated
Services Digital Network (ISDN), and X.25 interfaces are for use with serial
point-to-point wide area network connections.
SOCC
The serial optical channel converter (SOCC) is a high-speed serial channel converter
that is used for point-to-point links.

V3.1.0.1
Instructor Guide
Uempty ATM
Asynchronous transfer mode (ATM) is used for high-speed full duplex communications
in a LAN, MAN, or WAN environment using existing wiring (FDDI, OC3 SONET, Fibre
Channel, T3).
Fibre Channel
Fibre Channel is a high-speed fibre optic-based communications protocol which is
mostly used for storage device access in Storage Area Network (SAN) environments.
Scalable Parallel (SP) switch

The SP switch is used in IBM Deep computing to symmetrically link in parallel multiple
pSeries machines.

Instructor Guide
Instructor Notes:
Purpose Introduce some of the network interfaces that are available with AIX.
Details You may want to mention that this visual hasnt been updated recently and might
not reflect some recent developments.
This is the first of several visuals that walk up the TCP/IP protocol suite. In a classroom
with two projectors leave the last page on the other projector while showing these. This
helps students place the component--keep the big picture.
TCP/IP can work over many different interfaces and adapter cards.
Discussion Items How many of you work with sites with Token-Ring? How many with
Ethernet? What other types of connections do you have?
Additional Information Current network adapter types and associated feature codes
include the following:
4962 - 10/100 Mbps Ethernet PCI II
5701 - 10/100/1000 Mbps Base-TX Ethernet PCI-X
2732 - HiPPI
1810 - GX Dual Port 4x IB HCA
5718 - 10Gbps Ethernet SR
5719 - 10Gbps Ethernet LR
The 10GBASE-SR media types are designed for use over short wavelength (850 nm)
multimode fiber (MMF). The design goal of these media types is from 2 meters to 300
meters of fiber distance, depending on the type and quality of the multimode fiber. Longer
distances are possible depending on the qualities of the fiber optic cable used. The
10GBASE-SR media type is designed for use over dark fiber, meaning a fiber optic cable
that is not in use and that is not connected to any other equipment.
The 10GBASE-LR media types are designed for use over long wavelength (1310 nm)
single-mode fiber (SMF). The design goal of these media types is from 2 meters to 10
kilometers (32,808 feet) of fiber distance, depending on cable type and quality (longer
distances are possible). The 10GBASE-LR media type is designed for use over dark fiber.
There are other 10G standards - such as 10GBASE-LW/SW (designed for connecting
SONET equipment) - for which IBM does not produce adapters for use with AIX.
Be aware of the difference between FIBER and FIBRE (medium and protocol).
ATM has become an important international standard for high-speed, cell-relay networking.
It is capable of carrying voice data and video over existing wiring. It is applicable to both
LAN and WAN networking and is standards based.
For information on high-speed networks, refer to High-Speed Networking Technology: An
Introductory Survey, GG24-3816-02 and for ATM support, refer to Internetworking over

V3.1.0.1
Instructor Guide
Uempty ATM: An Introduction, SG24-4699-0. For more information regarding the SP Switch, refer
to Understanding and Using the SP Switch (SG24-5161-00).
Transition Statement Ethernet, Token-Ring and FDDI all have burned-in addresses on
the hardware adapter. Let's see how that address is structured.

Instructor Guide
Media Access Control (MAC) Address
All Network Adapters have a unique 48-bit MAC Address
00000010 01100000 10001100 00101110 10011011 11001010 Binary
02:60:8C:2E:9B:CA Hexadecimal
or
02608C2E9BCA Hexadecimal
Use the lscfg command to display a MAC address:

# lscfg -v -l <adapter name>
Figure 1-9. Media Access Control (MAC) Address AU079.1
Notes:
Introduction
Each network adapter has a unique 48-bit media access control (MAC) address.
Eight bits make up one byte or one octet, so a MAC address can also be thought of as
consisting of 6 bytes or 6 octets, as shown on the visual.
As the visual also shows, a MAC address can be represented using 12 hexadecimal
digits, since 1 hexadecimal digit can represent 4 bits.
Assignment of MAC addresses

Each network adapter has its own unique physical address. Every adapter
manufacturer has different blocks of physical addresses and assigns addresses from
these blocks in sequence as individual adapters are manufactured. IBM's range
consists of addresses starting with 10005A, 10005C, and 08005A.

V3.1.0.1
Instructor Guide
Uempty Use of a locally administered address (LAA)

Most LAN adapters allow a locally administered address (LAA) to be used instead of the
manufacturer assigned address.
Displaying a MAC address

An efficient way of viewing an adapters MAC address in AIX is to use the lscfg
command shown on the visual.

Instructor Guide
Instructor Notes:
Purpose Describe the physical or hardware address.
Details Hardware address--48 bits or in hex.
The address is usually burned in. Each manufacturer has a unique value for the first 24
bits. Some cards can be overwritten.
This is used by administrators. For example, when using machines that boot from a server
to find its IP address, the hardware address has to be supplied in configuration files to the
server.
Locally administered addresses can be useful to indicate the physical position of
equipment. For example, the first byte can represent the country, the second the city, the
third the building, the fourth the floor, and the fifth the room.
Transition Statement Before discussing how the hardware address is used, we need to
move up one layer to the Internet layer and discuss the packet delivery protocol, IP.

V3.1.0.1
Instructor Guide
Uempty
IP Protocol
Packet delivery protocol (datagram)
Best effort - no guarantees
IP addressing specifies the source and target hosts
Handles the routing of packets to other machines in the network or
other networks
Packet fragmentation and reassembly
Fragment size determined by MTU
Priority indication
Figure 1-10. IP Protocol AU079.1
Notes:
A packet delivery protocol

The Internet Protocol (IP) is the layer that hides the underlying physical network by
creating a virtual network view. It is a best-effort, connectionless packet delivery
protocol.
IP addresses
IP uses IP addresses to specify source and target hosts on the Internet. The IP address
is unique for every host.
The IP datagram header

The IP datagram has a header containing information for IP and data that is only
relevant to the higher-level protocols.

Instructor Guide
IP routing
IP routing is an important function of the IP layer. The IP routing mechanism only
considers the IP network address part of destination IP addresses. Each host keeps an
IP routing table.
Fragmentation and reassembly of information

IP also uses its maximum transmission unit (MTU) to fragment large amounts of data
into the appropriate size for transmission, and reassembles the information on the
receiving side.
Indication of priority
Each IP packet can have a priority indication which identifies the type of service that is
needed: low latency, high bandwidth, low cost or maximum reliability. Unfortunately, this
priority mechanism is not often implemented: all packets are often using the same path
to a destination, regardless of their type of service, and are transmitted on a first-come
first-served basis.

V3.1.0.1
Instructor Guide

Purpose Familiarize the students with the Internet Protocol. Point out that we have
moved up a layer in the TCP/IP architecture. We just finished covering the physical and
network interface.
Details Internet protocol is one of the core network services in the TCP/IP suite. It
accomplishes the passing of packets to the correct network. This activity is also known as
routing.
An important part of making IP work is assigning logical network addresses. Each network
has a unique address common to every host on that network. IP has tables identifying
where to send packets for other networks.
IP adds a header to the packet. This packet has source and destination IP addresses.
Additional Information The following header information is provided to you to help
answer questions students may have along the way and to aid you in interpreting output
from the iptrace command. It is not meant to be used as part of the normal lecture but as
back-up information in case it is needed.
Header length: number of 32-bit words in the header including any options present. This
implies a 60-byte limit on the size of an IP header (This is actually a limiting factor for
some IP options such as record route.)
TOS: is composed of a 3-bit precedence field (an option used by the Department of
Defense). The four types of service bits then are: minimize delay, maximize
throughput, maximize reliability, minimize monetary cost. (Only one of the four bits
may be turned on.)
Total length: total length of IP datagram in bytes. Combining this field with the header
length field yields the start of the user data. The 16-bits set a maximum size of 65535
bytes for an IP datagram.
Identification field: uniquely identifies each datagram transmitted by a host. Normally
incremented by 1 each time a datagram is sent.
Time-to-live: (TTL) sets an upper limit on the routes through which a datagram may
pass; it limits the lifetime of the datagram. This field is initialized by the sender to some
value (typically 255, 64, or 32) and decremented by one by every router the datagram
traverses. When it reaches 0 the sender is notified with an ICMP TTL error. This field
helps prevent routing loops and minimizes the effect of misconfigured routers.
Protocol field: used by IP to demultiplex incoming datagrams. It identifies which protocol
gave the data to IP to send.
Header checksum: calculated over the IP header only. It is the 16 bit ones complement
sum of the header.
Options: a variable length list of optional information. The current options are:
- Security and handling restrictions (military use)

Instructor Guide
- Record route (have each router insert its address)

- Timestamp (have each router record its timestamp and address)
- Loose source routing (specify a list of IP addresses to traverse)
- Strict source routing (specify a strict ordered list of IP addresses)
Transition Statement Addressing is central to the IP protocol. Let's take a look at how
this is structured.

V3.1.0.1
Instructor Guide
Uempty
Internet Address
32-bit Address
64 32 16 8 4
128
2 1
10000001 00100001 10010111 00000111

129 . 33 . 151 . 7
Dotted Decimal
Two Address Portions
Network Address Local Host Address
Figure 1-11. Internet Address AU079.1
Notes:
Introduction
The Internet Protocol V4 (IP V4) uses a 32-bit, two-part logical address field. As shown
on the visual, the 32 bits may be divided into four octets (bytes).
Parts of the IP address

The two parts are the network address portion and the host address portion.
The network address portion indicates the logical network to which the host belongs.
Each logical network must have a unique network address. The host address portion
indicates a specific host on the specific logical network.

Instructor Guide
One address per network interface

Each network interface in a router has its own unique IP address. Thus, if a router has
more than one network interface it has more than one address.
Ways of representing the IP address

The machine uses the binary representation of the IP address. The 32-bit address is
divided into four octets (bytes).
When referring to an address, it is usually written in dotted decimal notation where each
byte written in decimal is separated by a period.
In AIX, the decimal value of the bits ranges from high to low with the left most bit in
every byte having the highest value of 128. To calculate the decimal value of a byte
simply add together the decimal value of the bit position where the bits are turned on
(they have a bit value of 1). The resulting sum is the decimal value of the bytes. An
example is shown on the visual.
Using the bc command

There is a handy command in UNIX that aids in the conversion of binary to decimal and
vice versa. It is the bc command, which is an interactive command that works as shown
in the following examples:
- To convert binary to decimal:
$ bc
ibase=2
11111111 (provide binary number)
255 (result is the decimal value)
- To convert decimal to binary:
$ bc
obase=2
192 (provide decimal number)
11000000 (result is the binary value)

V3.1.0.1
Instructor Guide

Purpose Describe the characteristics of an IP V4 address.
Details Allows logical grouping of hosts. All addresses on the same network will have
the same network number.
It has 32-bit, dotted decimal characteristics.
The network and host ID are combined in 32 bits. Flexibility makes it adaptable to different
scenarios.
An IP address is really assigned to a network interface, not to a system. A system may
have more than a single IP address associated with it; but since most systems have a
single network interface, interface names have generally become synonymous with host
names.
Discussion Items If your organization has a few networks with lots of hosts, do you
want to use most of the address for host IDs or network IDs? Host IDs.
Additional Information The original network protocol on the ARPANET gave every
system an 8-bit address. Host addresses were later expanded to 16-bits and eventually to
32 bits. The Internet Protocol v6 uses 128-bit addresses.
Transition Statement The IP address has been further broken down by class which
specifies which portion of the 32 bits is the network portion.

Instructor Guide
Internet Addressing
7 bits 24 bits
Class A 0 Net-ID HOST-ID
14 bits 16 bits
Class B 10 Net-ID HOST-ID
21 bits 8 bits
Class C 110 Net-ID HOST-ID
28 bits
Class D 1110 Multicast Address
27 bits
Class E 11110 Experimental and Research
Figure 1-12. Internet Addressing AU079.1
Notes:
Parts of an IP address
There are two logical addresses in each IP address:
- A network address, representing the physical network within the Internet. The
network address of the IP address is unique and is handled by an Internet registry.
- A local address or host address, specifying an individual host or gateway within that
network.
This idea can be represented as follows:
IP address = <network address><host address>

V3.1.0.1
Instructor Guide
Uempty IP address classes

The first bits of the IP address indicate the class of the address and specify how the rest
of the address should be separated into its network and host part. This determines the
number of networks and hosts within each class.
There are five classes of IP addresses:
- Class A addresses were designed for and are used by extremely large
organizations, such as IBM, which has the 9 address range.
- Class B addresses are used by large organizations.
- Class C addresses were designed for use by small organizations. However, class C
addresses are currently the only addresses available. So, whether you are a small
or large organization, the Internet registry can only assign you class C addresses.
- Class D addresses are used in multicasting. Multicasting is an efficient way of
transmitting data on a network.
- Class E addresses are not used commercially and are reserved for research and
experimental use.

Instructor Guide
Instructor Notes:
Purpose Explain the different classes of IP addresses.
Details This visual is very similar to the next one, so keep discussion separate. IP has
different classes of networks for the different scenarios described.
The initial bit pattern shows whether it is a class A, B, C, or D address.
A Class A address consists of an 8-bit network address and a 24-bit host address. The first
bit in the network address is dedicated to indicating the network class leaving seven bits for
the actual network address. Since the highest number seven bits can represent in binary is
128, there are 128 possible Class A networks. IBM has the Class A network of 9. Since
there are so few Class A addresses to give out, the organization must be extremely large.
A Class B address consists of a 16-bit network address and a 16-bit host address. The first
two bits in the network address are dedicated to indicating the network class leaving 14 bits
for the actual network address.
A Class C address consists of a 24-bit network address and an 8-bit host address. The first
three bits in the network address are dedicated to indicating the network class leaving 21
bits for actual network addresses.
A Class D address is a multicast address which effectively is a broadcast to a fixed group
of machines than can be on different networks. There is no network or host portion. The
first 4 bits are 1, 1, 1, 0 and the remaining 28 bits identify the multicast group.
When deciding which network address class to use, you need to consider how many hosts
there will be on a network. If your organization is small and has less than 256 hosts on the
network, a Class C address is sufficient. If you are connecting to the Internet, an address
needs to be obtained from the appropriate Internet Address Registry. In the United States
this is the American Registry for Internet Numbers (ARIN). In most cases today, ARIN does
not assign IP addresses to end users. Instead, it allocates blocks of contiguous Class C
addresses to the larger Internet Service Providers. They then assign addresses from this
block to their customers and to smaller ISPs to whom they sell bandwidth. Typically, a
customer who later wishes to transfer to another ISP must return the IP numbers and
renumber with the new ISP.
Discussion Items Which class for which scenarios? Do you need to know initial bit
pattern? NO--but it has obvious effects on the IP address--refer to next page.
Additional Information In Class A addresses, the first bit (0) is also referred to as the
high order bit. In Class B, the highest order bits are set to the first two (1 and 0). In Class C,
the highest order bits are set to the first three (110).
There are actually five classes of IP addresses. The fifth class is Class E. The first five bits
of the 32 bit address are 11110. The remaining 27 bits are reserved for future use. This
class is seldom seen but is used for research and experimentation.
Transition Statement Let's see how many networks and hosts we can have within each
address class.

V3.1.0.1
Instructor Guide
Uempty
Internet Address Class Ranges
Number of Networks in each Class = 2Number of bits
Number of Hosts in each Network = (2Number of bits) - 2
Class Range Number of Networks Number of Hosts

A 1-127 128 16.7 Million
B 128-191 16384 65534
C 192-223 2.1 Million 254
D 224-239 Multicast
Figure 1-13. Internet Address Class Ranges AU079.1
Notes:
Number of networks and number of hosts for each class

Lets consider the number of available networks and the possible number of hosts in
each network for the four classes of IP addresses that are used commercially:
- Class A addresses allocate seven bits for the network address, thus providing for
128 (27) networks, each of which can have up to 16,777,214 (224 - 2) hosts (since
24 bits are allocated for the host address).
- Class B addresses allocate 14 bits for the network address, providing for 16,384
(214) networks, each of which can have up to 65,534 (216 -2) hosts (since 16 bits are
allocated for the host address).
- Class C addresses allocate 21 bits for the network address, providing for 2,097,152
(221)networks, each of which can have up to 254 (28 - 2) hosts (since 8 bits are
allocated for the host address).

Instructor Guide
- Class D addresses are reserved for multicasting. (Multicasting is a limited area type
of broadcasting.) There is no network or host portion in a multicast address. It is an
integer number registered with the Internet Network Information Center (InterNIC)
that identifies a group of machines.

V3.1.0.1
Instructor Guide

Purpose Describe the class ranges of IP addresses.
Details The expression shown for the Number of Hosts in each Network includes
parentheses around 2Number of Bits to make it clear that 2 must be raised to the appropriate
power before the final 2 is subtracted from the interim result. (Some students may object to
the parentheses, since the default order of operations for such expressions already
indicates that the first 2 should be raised to the appropriate power before the second 2 is
subtracted.)
Ranges:
The first octet of a Class A address is in the range of 1-127.
The first octet of a Class B address is in the range of 128-191.
The first octet of a Class C address is in the range of 192-223.
The first octet of a Class D address is in the range of 224-239.
Additional Information The InterNIC Web site is operated by the Internet Corporation
for Assigned Names and Numbers (ICANN) to provide the public information regarding
Internet domain name registration services. Refer to the ICANN Web site at
http://www.icann.org (particularly the FAQ available at that site) for more information about
ICANN and InterNIC.
At this point, be sure that students understand:
Binary to decimal conversion
The parts of an Internet address
What determines the class of an Internet address class
Internet address ranges and the associated calculations that have been covered
Transition Statement Some addresses are reserved. Let's see which ones they are
and for what they are used.

Instructor Guide
Special Internet Addresses
127.0.0.1 Loopback
Identify a
Network Address 0000000000000000 Network
Direct
Network Address 1111111111111111 Broadcast
Address
! What is the Difference?
Limited
11111111111111111111111111111111 Broadcast
Address
Figure 1-14. Special Internet Addresses AU079.1
Notes:
The loopback address

The Internet Protocol defines the special network address 127.0.0.1, as a local
loopback address. Hosts use local loopback addresses to send messages to
themselves. The local loopback address is set by the configuration manager during the
system startup process. Everything sent to the loopback address or one of the host's IP
addresses is sent to the loopback interface.
Network addresses
An IP address with all host bits set to zero identifies a network. For example, 26.0.0.0
refers to network 26; 128.66.0.0 refers to network 128.66. Addresses in this form are
used in routing tables to refer to networks.

V3.1.0.1
Instructor Guide
Uempty Broadcast addresses

An IP address with all host bits set to ones is a broadcast address. It is used to
simultaneously address every host on a network. A datagram sent to 128.66.255.255 is
delivered to each system on the 128.66 network.
The limited broadcast address

An IP address with all host and network bits set to one (255.255.255.255) is for all hosts
regardless of their network number. However, routers rarely pass these packets from
one network to another.

Instructor Guide
Instructor Notes:
Purpose Identify reserved IP addresses.
Details All 0 bits stand for this this network with host address portion = 0 used in
routing to designate the network portion of the address.
All 1 bits stand for all all networks or all hosts used to send broadcast messages to all
hosts on a network.
Additional Information Some routers (for example, Cisco) now use loopback
addresses other than 127.0.0.1.
Some old versions of BSD (BSD 4.2 and earlier) used a broadcast address where the host
bits were all set to zero. This would play havoc with routing which uses all zeros in the host
address to mean a network address. Most systems derived from BSD 4.2 or earlier have
been patched or upgraded to resolve this problem.
Transition Statement Let's see how these addresses get assigned.

V3.1.0.1
Instructor Guide
Uempty
Address Assignment
Private networks
Choose any valid addresses/names (within reason)
Should use reserved private network addresses (RFC 1918)
10.0.0.0 / 172.16.0.0 - 172.31.0.0 / 192.168.0.0
The Internet
African Network Information Center (AfriNIC)
American Registry for Internet Numbers (ARIN)
Asia Pacific Network Information Centre (APNIC)
Latin American and Caribbean IP Address Regional Registry
(LACNIC)
Rseaux IP Europens (RIPE)
Figure 1-15. Address Assignment AU079.1
Notes:
Addresses for private networks

When you are implementing a TCP/IP network, you must select addresses for the
networks/hosts you are connecting. If your network is not going to be connected to any
public internet, you can choose whatever valid addresses you wish. It is a good idea to
use the addresses reserved for private networks as described in RFC 1918.
Addresses if connecting to the Internet

If you wish to connect to the Internet, you must contact the appropriate Regional
Internet Registry (RIR), the central body that allocates network addresses in your
region. For networks located in the United States or Canada, contact the American
Registry for Internet Numbers (ARIN) (http://www.arin.net).

Instructor Guide
Role of Internet Service Providers (ISPs)

In most cases today, the RIR does not assign IP addresses directly to end users.
Instead, it allocates blocks of Class C addresses to the larger Internet Service Providers
(ISPs). The ISPs then assign addresses to their customers. Your RIR or your ISP will
probably require you to provide information about the current size of your company, the
number of networks/hosts you have, and an estimate of future requirements. Based
upon that information, you are assigned one or more network addresses for your
organization to use.
Current RIRs
There are currently five RIRs:
- African Network Information Center (AfriNIC), covering the continent of Africa
(www.afrinic.net)
- American Registry for Internet Numbers (ARIN), which we have already mentioned
- Asia Pacific Network Information Centre (APNIC), covering the Asia Pacific region
(http://www.apnic.net)
- Latin American and Caribbean IP Address Regional Registry (LACNIC), covering
the Latin American and Caribbean region (www.lacnic.net)
- Rseaux IP Europens (RIPE), covering Europe, the Middle East, and parts of Asia
(http://www.ripe.net)

V3.1.0.1
Instructor Guide

Purpose Describe how network addresses get assigned.
Details The spelling of Centre in Asia Pacific Network Information Centre is not a
mistake.
Students often ask how they should find out their IP address, where do they come from,
and so forth. This visual and the student notes should help answer those questions. Be
sure to mention that things are changing rapidly in the Internet due to the tremendous
growth it has experienced. Thus, the information on the previous page may change at
some time.
Transition Statement We've talked about physical addresses and Internet (or logical)
addresses. Let's see how the system uses these.

Instructor Guide
Physical and Logical Addressing
Used by Address Type Mapping
People Host Name

Name Resolution
Software Logical Address
Address Resolution
Hardware Physical Address
Figure 1-16. Physical and Logical Addressing AU079.1
Notes:
Physical address
Each adapter vendor has a separate range of addresses for its adapters. Each network
adapter manufactured by the vendor is assigned a unique identifier taken from this
range of addresses. This identifier (physical address) is stored in ROM on the adapter.
Logical address
The IP Protocol deals only with logical or Internet addresses. These addresses are
assigned by the system administrator of your LAN. Each network interface has its own
unique Internet address.

V3.1.0.1
Instructor Guide
Uempty Host name

Each host in a TCP/IP network has a unique name for ease of identification by users.
Administrators give a unique name to each network adapter card. Every name is
resolved to one IP address, which is then resolved to one physical address.

Instructor Guide
Instructor Notes:
Purpose Discuss how referencing a network device occurs at three levels.
Details Referencing a system occurs at three levels: people, software, hardware.
Software uses IP addresses.
Each IP address has to be translated into a hardware address at the network interface
level.
With multiple cards, each interface must have a unique IP address assigned to it and, if
using names, a unique name.
Transition Statement We have covered the basic facilities of the Internet Protocol.
Let's look at another protocol in the Internet layer - ARP.

V3.1.0.1
Instructor Guide
Uempty
LANs and Address Resolution Protocol (ARP)
The ARP protocol is used to determine the MAC address of your
party
Broadcast destination IP address to anyone
Only the destination replies with its MAC address
ARP is invoked automatically by IP if the destination MAC address
is not known
Cached in the ARP table
View table with arp -a
128.10.1.1 128.10.1.2 128.10.1.3

sys1 00608C2FB5A5 sys2 sys3
2 1 2
"128.10.1.1 is 00608C2FB5A5" "Who is 128.10.1.1" "Not me!! Discard"
3 ARP Table:
sys1 128.10.1.1 00608C2FB5A5 Ethernet
Figure 1-17. LANs and Address Resolution Protocol (ARP) AU079.1
Notes:
Introduction
The Address Resolution Protocol (ARP) is responsible for converting unique IP
addresses into unique physical machine addresses. ARP uses the broadcast facility of
networks to discover the hardware (physical) address.
The ARP broadcast request

The broadcast (from an ARP request) is received by all hosts on the network, but only
one will recognize its own IP address and respond with an address resolution reply. The
ARP broadcast request contains the following:
- IP address of the requestor host
- IP address of the target host
- The hardware address of the requestor
- Other information like hardware type (Token-Ring, Ethernet, and so forth)

Instructor Guide
Responding to the ARP broadcast request

The host that recognizes its own IP address from the ARP broadcast request packet
supplies the missing information, which includes its own hardware address, and uses
the hardware address of the requestor to send a response. All other hosts on the
network discard the packet.
The ARP table

ARP maintains a table of mappings between IP logical addresses and network-specific
physical addresses for network types where a single interface has multiple possible
destinations (for example, Ethernet, Token-Ring, FDDI). Interfaces which use
point-to-point connections (for example, PPP) do not require ARP because there is only
one possible destination.
When data is to be sent to the network, the destination hardware address is determined
from the ARP table. If your host does not have the destination hardware address in the
ARP table, ARP on your system is used to obtain the address (by broadcasting a
request to the network). Thereafter, the address of the destination is in your ARP table.
(Note: X.25 does not use broadcasts. All possible destinations must be preloaded into
the ARP table.)
Discarding of ARP table entries

Entries in the ARP table are normally discarded if they have not been used for 20
minutes. This is because if you change the adapter in a system, it has a new hardware
address, but the previous entry is still in the table. Twenty minutes is seen as a
reasonable time to change an adapter without causing unnecessary network
broadcasts. The default time-out of 20 minutes can be changed using the no command.
Viewing the ARP table

You can use the following command to view the ARP table:
# arp -a

V3.1.0.1
Instructor Guide

Purpose Describe the role ARP plays.
Details ARP normally is transparent to the user and administrator.
Each device has a hardware and logical address. At the Internet level, we use logical
addresses; at the network level, we use hardware addresses. ARP does the
translation/resolution.
Explain ARP using the illustration on the visual and a sample transmission from one
workstation to the other. Use an explanation similar to the following:
If sys2 wishes to communicate with sys1, sys2 broadcasts an ARP request for sys1's
hardware address. The ARP request contains sys2's IP hardware address and sys1's IP
address. When sys1 receives the ARP request, it places an entry for sys2 in its ARP
cache, then responds directly to sys2 with an ARP response containing its IP hardware
address. Board work: When sys2 receives sys1's response, it places sys1's IP hardware
address in its ARP cache. Once the ARP cache exists at sys2 and sys1, sys2 is able to
send packets directly to sys1 without resorting again to ARP.
ARP cache is built automatically. The kernel maintains these tables and its information is
not directly available to users or applications. The ARP broadcast only goes to hosts within
the range of its own network. It does not get sent across routers.
Additional Information ARP is used with Ethernet, Token-Ring, and FDDI, but it does
not translate addresses for X.25, SLIP, or Serial Optical since these are point-to-point.
When any system that supports ARP receives ARP request packets, the system notes the
IP and hardware address of the requesting system and updates its ARP table if necessary.
If the receiving system's IP address does not match the requested address, the system
discards the requested packet.
Students may ask questions about proxy ARP, gratuitous ARP, or reverse ARP. If you wish
to answer the questions in class, try to be brief so it doesn't interfere with time spent on
other topics. Otherwise, take it offline. In brief:
Proxy ARP- Allows a router to answer ARP requests on one of its networks for hosts on
another of its networks. It fools the ARP request sender into thinking the router is the
destination host when in reality the destination host is on one of the other networks
attached to the router. If the results of the arp -a command show more than one IP
address mapped to the same hardware address, this may be an indication that proxy
ARP is in use. (It may also be an indication that two adapters have the same hardware
address.) Some implementations of ARP provide messages if more then one IP address
is mapped to the same physical address. AIX sends such messages if an IP address or
hardware address is received that matches its own.
Gratuitous ARP - This is when a host sends an ARP request for its own IP address,
usually at the time it is initializing an interface. This facility provides a way for a host to
determine if another host is already configured with the same IP address. If the host
sending the gratuitous ARP has just changed its hardware address, this causes any

Instructor Guide
other host on the same network which has an entry in its ARP cache for the old
hardware address, to update its table.
Reverse Address Resolution Protocol (RARP) - RARP provides a way for a machine
to find out its IP address if it only knows its hardware address. This is most often used by
diskless systems during boot up. The system broadcasts its hardware address to the
network, and a server set up on the network responds with the IP address of that
system. RARP is rarely used now because all the information it can provide is the IP
address. bootp is often used instead, and it is capable of passing additional information
such as:
- Host name
- Subnet mask
- Default gateway
- Nameserver
- Boot file
- Vendor specific information
Transition Statement Let's look at another protocol in the Internet Layer.

V3.1.0.1
Instructor Guide
Uempty
ICMP Protocol
Used to communicate error and control messages for IP
Integral to IP operation, but functionally separate
ICMP messages are sent using IP datagrams
Reports errors on any IP datagram with the exception of IP
datagrams containing ICMP messages
Used by the ping command
Figure 1-18. ICMP Protocol AU079.1
Notes:
Internet Control Message Protocol (ICMP) messages

The Internet Control Message Protocol (ICMP) is used to report errors in IP datagram
processing and send IP-related control messages.
Types of ICMP messages are: destination unreachable, source quench, redirect, echo
request and echo reply, time exceeded, parameter problem, timestamp and timestamp
reply, information request and reply, and address mask request and reply.
Integration of ICMP
ICMP uses IP as if it were a higher-level protocol; however, ICMP is an integral part of
IP and must be implemented by every IP module. ICMP is a standard protocol and is
required. Also, ICMP is embedded in the kernel, and no API is provided for this
protocol.

Instructor Guide
Restrictions on ICMP error reporting

ICMP can report errors on any IP datagram with the exception of ICMP messages. This
restriction is required to avoid infinite reflections.
Use of ICMP messages by the ping command

The most common use of ICMP by network administrators is through the use of the
ping command, which sends out an ICMP echo request, expecting an ICMP echo reply
from the destination host.

V3.1.0.1
Instructor Guide

Purpose Briefly describe the ICMP protocol.
Details ICMP is used to report errors encountered with IP datagrams. It is strictly an
error reporting mechanism and does not make IP a reliable (connection-oriented) protocol.
Transition Statement Before moving up a layer to the transport layer and seeing what
TCP and UDP functions are, we need to define some terms used by these protocols; ports
and sockets.

Instructor Guide
Ports and Sockets
A port identifies the application on the host
Server side ports are well-known and fixed

Stored in /etc/services
Client side ports are dynamic and > 1023

Every client connection uses a new port
A socket is a combination of IP address, protocol and port number
A pair of sockets defines a unique application network connection
TCP and UDP both implement ports independently of each other
Figure 1-19. Ports and Sockets AU079.1
Notes:
Ports
Each process that wants to communicate with another process needs to identify itself in
some way. The logical construct used by TCP/IP to accomplish this task is called a port.
A port is a 16-bit number that uniquely identifies application processes (also called
network services). The source port number and the destination port number are
contained in the header of each TCP segment or UDP packet.
Port numbers are defined in the /etc/services file. Port numbers from 0-1023 are called
well-known published ports and are reserved for standard applications like telnet and
ftp.
When a datagram arrives at its destination based on the destination address, IP checks
the protocol. The data delivered to the transport protocol contains the destination port
number that tells the transport protocol to which application process the data needs to
go.

V3.1.0.1
Instructor Guide
Uempty Sockets
A socket is a combination of IP address and port number and protocol family, which
uniquely identifies a single network process. A socket is also referred to as a
communication end point.
Connections
To distinguish between duplicate requests sent to the destination host, the source
socket information is included as part of the request. The combination of information of
both sockets makes the connection unique as shown below:
<protocol, source-address, local-port, destination address,
destination-port>
Request 1:
<tcp,128.66.12.2,3044,192.178.16.2,23>
Request 2:
<tcp,128.66.12.2,3050,192.178.16.2,23>
An association is the 5-tuple (five pieces of information transferred as shown above)
that completely specifies the two processes that comprise a connection.
A half-association specifies each half of a connection which includes the protocol,
source or destination address, and source or destination port.

Instructor Guide
Instructor Notes:
Purpose Define the principles of ports and sockets with the TCP/IP suite.
Details Introducing port and sockets does not fit in smoothly at this point, but they are
needed in describing UDP, TCP, and /etc/services, which follow. Before two programs can
communicate with each other, both must initialize communication end points. Connections
to a system are distinguished by a port number, which serves as a sort of mailbox number
for datagrams. Once a port has been assigned, any datagrams the application program
sends through the port will have the port number in the transport port field.
Additional Information Another analogy that may be used to explain ports and sockets
may be as follows:
SOCKET TELEPHONE
IP Address:
Network# Area Code
Host ID Phone#
Port# Extension
The socket interface is one of several application programming interfaces (APIs) to the
communication protocols. Designed to be a generic communication programming
interface, it was first introduced by the 4.2BSD UNIX system. Although it has not been
standardized, it has become a de facto industry standard.
We can differentiate three socket interface types, based on the service provided by each
type:
1. Stream socket interface
It defines a reliable connection-oriented service (over TCP for example). Data is sent
without errors or duplication and is received in the same order as it is sent. Flow control
is built in to avoid data overruns. No boundaries are imposed on the exchanged data,
which is considered to be a stream of bytes. An example of an application that uses
stream sockets is the File Transfer Program (FTP).
2. Datagram socket interface
It defines a connectionless service (over UDP for example). Datagrams are sent as
independent packets. The service provides no guarantees; data can be lost or
duplicated, and datagrams can arrive out of order. No disassembly and reassembly of
packets is performed. An example of an application that uses datagram sockets is the
Network File System (NFS).
3. Raw socket interface
It allows direct access to lower-layer protocols such as IP and ICMP. This interface is
often used for testing new protocol implementations. An example of an application that
uses raw sockets is the PING command.

V3.1.0.1
Instructor Guide
Uempty The port numbers from 0 up to 1023 are called well known port numbers and are fixed by
the Internet Assigned Number Authority (IANA). The port numbers above 1023 are free.
However, if you intend to offer a certain service on the Internet, you can register with the
IANA and get a certain port number assigned to it. IANA maintains a document entitled
Port Numbers (last updated 12 January 2006 at the time these materials were written).
The port numbers listed are divided into three ranges: the Well Known Ports, the
Registered Ports, and the Dynamic and/or Private Ports. As previously mentioned, the Well
Known Ports are those from 0 through 1023. The Registered Ports are those from 1024
through 49151. The Dynamic and/or Private Ports are those from 49152 through 65535.
Port Numbers is currently available at http://www.iana.org/assignments/port-numbers.
From November 1977 through October 1994, IANA periodically published tables of the
Internet protocol parameter assignments in RFCs entitled, Assigned Numbers. The most
current of these Assigned Numbers RFCs had Standard status and carried the designation:
STD 2. Since 1994, this sequence of RFCs has been replaced by an online
database/document accessible through a web page (currently, www.iana.org). RFC 3232
noted this fact and officially obsoleted RFC 1700 (the last of the sequence of Assigned
Numbers RFCs), whose status changed to Historic. RFC 1700 is obsolete, and its values
are incomplete and in some cases may be wrong.
Confusion that could be caused by two different applications trying to use the same port
numbers on one host, is avoided by designing applications in such a way that they must
request an available port from a list of unused and not assigned port numbers. Due to this
dynamic port assignment for ports above 1023, the number may change when an internal
process is invoked several times. TCP and UDP both use the same port principle.
Transition Statement Let's take a look at an example of the /etc/services file, which
lists port numbers and their corresponding services.

Instructor Guide
/etc/services
# Network services, Internet style
#
tcpmux 1/tcp # TCP Port Service Multiplexer
tcpmux 1/udp # TCP Port Service Multiplexer
compressnet 2/tcp # Management Utility
compressnet 2/udp # Management Utility
compressnet 3/tcp # Compression Process
compressnet 3/udp # Compression Process
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # Message Send Protocol
msp 18/udp # Message Send Protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
Figure 1-20. /etc/services AU079.1
Notes:
Introduction
The purpose of the /etc/services file is to define the port portion of the socket and
protocols used for Internet services. The fields are: official Internet service name,
socket port number used for the service, transport protocol used for the service, and
aliases, if desired. The file can be edited as necessary.
Note that this visual does not show a complete listing of the file.
Port number ranges

Some processes use the same port number (referred to as a well-known port) in all
TCP/IP implementations. All other ports are dynamically assigned by the system. These
types of ports are identified by different port number ranges, which are listed below:
0-1023 well-known ports
1024 and up generic processes

V3.1.0.1
Instructor Guide

Purpose Discuss the role of /etc/services.
Details This file defines the ports and protocols used for Internet services. inetd checks
for the services in /etc/inetd.conf and the port numbers to listen on from /etc/services.
A listing of the well-known ports is included in the document Port Numbers, which is
currently available at http://www.iana.org/assignments/port-numbers. (RFC 1700, the last
of the sequence of Assigned Numbers RFCs, is obsolete, and its values are incomplete
and in some cases may be wrong.)
Transition Statement Before discussing the more commonly used protocols in a bit
more detail, let's discuss the difference between connectionless and connection-oriented
communications.

Instructor Guide
Connectionless versus Connection Oriented
TCP
Connection Oriented
n ection
Con
W E
Connectionless UDP
Figure 1-21. Connectionless versus Connection Oriented AU079.1
Notes:
Connectionless networks
Another important principle in networking is the presence or absence of a connection.
You may think, But of course there is a connection. True, however, the network may
not be aware of it. For a so-called connectionless network (protocol), the network does
not keep track of the state of the successive packets of information between two
communication partners. The network treats each packet, called a datagram, as an
individual unit without making any assumptions about the relationship of that packet to
other packets in the network. The connection between the individual pieces of
information is made at a higher level; this may be the transport level or the application
itself.
This means, for example, that, a client employing a connectionless network must send
a datagram containing a request to a server, which the server receives without prior
notice. The server must construct one or more datagrams containing the response, and
send those to the requester. All those datagrams, as far as the network is concerned,

V3.1.0.1
Instructor Guide
Uempty are unrelated to each other. The relationship between the datagrams is based only on
agreements between users of the network.
Connection-oriented networks
A connection-oriented network, on the other hand, actively participates in the
establishment of a connection between the two remote partners. The network can
distinguish packets that flow between two communicating entities from all other packets
in the network. The packets that belong to a connection are numbered and sequenced,
making detection of missing packets and other errors easy. Having participated in the
connection setup also means that the network has knowledge of all connections, and
can therefore manage its resources on a connection basis.

Instructor Guide
Instructor Notes:
Purpose Describe the difference between connectionless and connection-oriented
sessions.
Details
Connection Oriented Communication
Three phases: Setup, Data Transfer, Takedown
Analogous to the phone system
Characteristics:
- Guaranteed delivery via acknowledgements
- Flow control via windowing
Determine route during Setup phase
Connection-oriented protocols mirror the telephone system. (The visual is meant to
suggest this comparison.) There are three phases in telephone communication:
1. Setup Phase --> dialing, saying hello and getting the right party on the line
2. Data Transfer Phase --> Talking
3. Take-Down --> saying good-bye and hanging up.
As part of the setup phase, connection-oriented protocols typically offer guaranteed
delivery of data, using acknowledgements to assure data is transmitted correctly. When
one end of a connection sends data to the other end, it holds onto a copy of the data until it
receives an acknowledgement that the data was received properly. If it does not receive an
acknowledgement within a certain window (or before a timer pops), it retransmits the data.
After five or six retransmissions without success, the sending station takes down the
connection, sequence numbers are used to correlate acknowledgements, and windowing
techniques (one can send a window worth of data and must then wait for an
acknowledgement) are used for flow control. In addition, data routes are typically
determined as part of the connection process. The same route is used for the duration of
the connection. Since routes are determined at connection setup time, data packets do not
need to contain a long address to route it; a connection identifier is enough.
Connectionless Networks
Connectionless networks more closely resemble the mail system. (The visual is meant to
suggest this comparison.) The mailing system requires that each and every letter, postcard,
or packet has the full address of the receiver. The postal service delivers mail without prior
notice to the receiver. The receiver reads it and may decide to answer (a return address
must be included then). There is no setup of a connection, no fixed paths for delivery and
each piece of mail is routed independently of the others.
In connectionless networks, each data packet must contain all the information required to
get it to its destination. Each packet can be routed without regard to which path the

V3.1.0.1
Instructor Guide
Uempty previous packet took or which path the next packet takes. If a link goes down, there is no
connection to take down; subsequent packets are simply routed over alternate paths.
Most connectionless protocols do not acknowledge receipt of data or have any mechanism
for flow control (they offer best effort delivery). However, using a connectionless network
does not preclude a higher level protocol implementing an acknowledgment scheme and
flow control.
An example from daily life may serve to illustrate the functioning of connectionless
transport.
A person from Scandinavia moves for a longer period of time to the United States of
America, with the intention of returning to his/her country. To keep up with the day-to-day
happenings in the homeland, the decision was made to order Dagens Nyheter (the local
newspaper) to be sent to the United States for the period of one year. Since the news
doesn't have to be the latest news, surface transportation was ordered.
Note: A generic term can be used here, Class of Service. For example, airmail could have
been selected instead of surface mail.
After moving to the United States of America, it takes at least one month before the first
Dagens Nyheter arrives. Also, the delay between two deliveries varies and more important,
there is no guarantee whatsoever that all newspapers arrive in the same order as they
have been sent. It is up to the user to sort them in the correct sequence for reading. Should
a newspaper fail to arrive, it is up to the reader to detect the missing newspaper and to ask
specifically for a substitute.
To summarize the basic properties of a connectionless network:
Single phase data transfer (no setup or take-down)
Analogous to the mail system
Characteristics
- Best effort delivery without acknowledgement
- Typically no flow control mechanism
- Each data frame contains all routing information
Transition Statement Let's now take a look at the UDP protocol in the transport layer.
UDP is an example of a connectionless protocol.

Instructor Guide
UDP Protocol
A connectionless application interface to IP
No reliability, error recovery or flow control
Provides a multiplexer/demultiplexer function for sending/receiving
IP datagrams
Uses ports
Does not assure datagram delivery or duplication protection
Figure 1-22. UDP Protocol AU079.1
Notes:
Overview of UDP
UDP is a simple, connectionless transport protocol. It is basically an application
interface to IP. It adds no reliability, flow control or error recovery to IP. It simply serves
as a multiplexer/demultiplexer for sending or receiving IP datagrams, using ports to
direct the datagrams.
UDP allows the sender to specify a source and a destination source port number which
could be a well-known port. A checksum is computed to ensure the reliability of the
addresses. These two features ensure the sending and receiving applications have the
correct delivery of a message. No other reliability is added to the UDP protocol.
UDP and IP do not provide any reliability, so it is up to the application program to
provide for flow control and error recovery.

V3.1.0.1
Instructor Guide
Uempty Standard applications using UDP

Standard applications using UDP are:
- Trivial File Transfer Protocol (TFTP)
- Domain Name Server (DNS)
- Remote Procedure Call (RPC), used by Network File System (NFS)
- Network Computing System (NCS)
- Simple Network Management Protocol (SNMP)
Favorable and unfavorable environments for UDP applications

Most UDP applications are developed and tested on local area networks which offer
excellent speed and reliability. The connectionless, unreliable nature of the User
Datagram Protocol is not apparent under such circumstances. UDP applications
developed for this kind of network may be very fast and reliable. However, when using
less reliable and slower long-distance connections, the same UDP application may be
very disappointing in its performance. Data security and integrity are not provided by
any IP/UDP network services, but are the sole responsibility of the application program.

Instructor Guide
Instructor Notes:
Purpose Explain the UDP protocol.
Details Explain that there are two types of services to support the user application--TCP
and UDP. Both are used to take a stream of data from the program and break it into
packets.
UDP provides a connectionless service. This means it takes the message and sends it to
the destination without waiting for an acknowledgement. As a result, it is usually quick.
An analogy useful in discussing UDP is mailing a letter. Do you know whether the
addressee receives it? Do you know when it is received? If you send more than one letter,
do you know whether the letters arrive in order? No, but all those considerations require
overhead.
Sometimes UDP is called unreliable because it does not provide those services. Actually,
the implementation is such that the network is reliable, so that loss is rare. If delivery is
critical, then the necessary steps to ensure reliability are built into the application.
Transition Statement TCP is the other commonly used transport protocol. It is a
connection-oriented protocol. Let's see how it differs from UDP.

V3.1.0.1
Instructor Guide
Uempty
TCP Protocol
Connection-orientated application interface to IP
Provides reliability and error recovery
Each byte transmitted requires an acknowledgment
Retransmission of missing packets
Flow control
Receiver indicates to the sender the number of bytes it can
receive without buffer overflow
Full duplex
Figure 1-23. TCP Protocol AU079.1
Notes:
Introduction
The Transmission Control Protocol (TCP) is a connection-oriented, end-to-end, reliable
protocol providing logical connections between pairs of processes. Within TCP, a
connection is uniquely defined by a pair of sockets.
Characteristics of TCP
TCP can be characterized by the following facilities:
Stream data transfer: TCP transfers a contiguous stream of bytes through the
network. The application does not have to bother with chopping the data into basic
blocks or datagrams.
Reliability: TCP assigns a sequence number to each byte transmitted and expects a
positive acknowledgement from the receiving TCP. If the acknowledgement is not
received within a time-out interval, the data is retransmitted.

Instructor Guide
Flow control: The receiving TCP indicates to the sender the number of bytes it can
receive beyond the last received segment without causing overrun and overflow in
its internal buffers.
Multiplexing: TCP allows many processes within a single host to use TCP
communications facilities simultaneously. This is achieved through the use of ports.
Logical connections: TCP initializes and maintains certain status information for
each data stream. The combination of this status, including sockets, sequence
numbers, and window sizes, is called a logical connection.
Full duplex: TCP provides for concurrent data streams in both directions.

V3.1.0.1
Instructor Guide

Purpose Explain the role of TCP and compare to UDP.
Details TCP is the protocol used by most applications.
It is connection-oriented, meaning that it goes through a setup and handshaking phase
before actually transmitting. During the handshaking, the exchanged TCP segments
include the initial sequence numbers from both sides, to be used on subsequent data
transfers.
TCP sends data in variable length segments. Sequence numbers are counted byte per
byte. Acknowledgements specify the sequence number of the text byte that the receiver
expects to receive. The sender continues to transmit segments to the receiver up to when
the window size is reached. The window does not slide until an ACK (acknowledgement) is
received indicating the receiver is expecting bytes outside of the window.
If it fails to receive an ACK by the receiver, it sends it again.
TCP can be characterized by the following facilities it provides for the applications using it:
Stream Data Transfer
From the application's viewpoint, TCP transfers a contiguous stream of bytes through
the connection. The application does not have to bother with chopping the data into
basic blocks or datagrams. TCP does this by grouping the bytes in TCP segments,
which are passed to IP for transmission to the destination.
Sometimes, an application needs to be sure that all the data passed to TCP has
actually been transmitted to the destination. For that reason, a push function is
defined. It pushes all remaining TCP segments still in storage to the destination host.
The normal close connection function also pushes the data to the destination.
Reliability
TCP assigns a sequence number to each byte transmitted, and expects a positive
acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a
time-out interval, the data is retransmitted. As the data is transmitted in blocks (TCP
segments), only the sequence number of the first data byte in the segment is sent to
the destination host.
The receiving TCP uses the sequence numbers to rearrange the segments when
they arrive out of order and to eliminate duplicate segments.
Flow Control
The receiving TCP, when sending an ACK back to the sender, also indicates to the
sender the number of bytes it can receive beyond the last received TCP segment
without causing overrun and overflow in its internal buffers. This is sent in the ACK in
the form of the highest sequence number it can receive without problems. This
mechanism is also referred to as a window mechanism, which is discussed in more
detail later in this unit.

Instructor Guide
Multiplexing
Is achieved through the use of ports, just as with UDP.
Logical Connections
The reliability and flow control mechanism described above requires that TCP
initialize and maintain certain status information for each data stream. The
combination of this status information, including sockets, sequence numbers and
window-sizes, is called a logical connection (or virtual circuit). Each connection is
uniquely identified by the pair of sockets used by the sending and receiving
processes.
Full Duplex
TCP provides for concurrent data streams in both directions.
Transition Statement Let's take a look at the flow control, called windowing, used by
TCP in more detail.

V3.1.0.1
Instructor Guide
Uempty
The TCP Window Principle
Segment size = 4096 (4 KB)
Window size = 32768 (32 KB)
initial window
S S S S S S S S W W W W W W W W ...
Send 32 KB of data, window closed
window slides
A S S S S S S S M W W W W W W W ...
Received ACK of 4 KB of data, window open
A S S S S S S S S W W W W W W W ...
Next 4 KB data sent, window closed
A sent / ACKed S sent / not ACKed M may be sent immediately W waiting to be sent
Figure 1-24. The TCP Window Principle AU079.1
Notes:
Possible principles for a simple transport protocol (not for TCP)

A simple transport protocol might use the following principles:
- Send a packet and then wait for an acknowledgement from the receiver before
sending the next packet
- If an acknowledgement is not received within a certain amount of time, retransmit
the packet
While this mechanism ensures reliability, it only uses a part of the available network
bandwidth because the sender is forced to wait for an acknowledgement after each
transmission.

Instructor Guide
Principles for a more efficient protocol

A more efficient method might be a protocol where the sender groups its packets to be
transmitted using the following rules:
- The sender may send all packets within a defined window without receiving an
acknowledgement but must start a time-out timer for each of the packets
- The receiver must acknowledge each packet received, indicating the sequence
number of the last well-received packet
- The sender slides the window on each acknowledgment received
Discussion of example on visual

In our example, the sender transmits packets 1 to 8 without waiting for any
acknowledgment.
At the moment the sender receives the ACK 1 (acknowledgment for packet 1), it may
slide its window to exclude packet 1.
It's important to note that the windows and acknowledgments are actually based on
octet numbers within the stream sent from one application to the other. While the
receiving system might send an acknowledgment for all data up to and including a
particular packet, the acknowledgment is actually for all data up to a particular octet
number. Thus, it's possible for a system to acknowledge only part of a packet. Note,
however, that there is no selective acknowledgment facility, in which a receiver can
acknowledge particular octets in the stream without also acknowledging all octets
earlier in the stream. In other words, when a receiving system acknowledges octet N, it
is also acknowledging all octets earlier in the stream.
Advantages of window mechanism

This window mechanism ensures:
- Reliable transmission.
- Better use of the network bandwidth (better throughput).
- Flow control. Thus, the receiver can delay replying to a packet with an
acknowledgment. The decision would be based on:
Number of free buffers available
The current window-size

V3.1.0.1
Instructor Guide

Purpose Introduce the window concept of sending data as a flow control mechanism.
Details The idea of this visual is to show how a simple windowing mechanism works. Go
through the example as follows:
Assuming a window of eight packets, an application may send eight packets without having
to wait for an acknowledgment. After the eighth packet, the window is said to be closed and
no further packet may be sent to the destination system.
In our example, an acknowledgment for packet 1 has been received, which slides the
window up one, thus enabling the application to also send packet number 9.
The ideal window is one that enables an application to send a continuous stream of
packets without having to wait for an acknowledgment and to avoid causing problems for
either the network (congestion) or the receiver (overrun).
Additional Information
Selective acknowledgements - Although TCP has a mechanism to recover from the loss of
a single segment in a window, in the case of multiple segments, the sender generally has to
retransmit not only the lost segment but also segments received normally. This causes a
significant impact on throughput especially when the network is unreliable or congested. To
avoid these unnecessary retransmissions, use another mechanism, called selective
acknowledgement (SACK), which is defined in RFC 2018. By enabling SACK, the sender
only has to retransmit segments that have been really lost during transmission.
Another network option available for flow control is increasing TCPs initial window size, as
described in RFC 2414. The network option tcp_init_window is only used when RFC
2414 is turned on. (See the entry for the no command in the AIX 5L Version 5.3 Commands
Reference (or the corresponding man page), particularly the portions dealing with the
rfc2414 and tcp_init_window options, for more details.)
Transition Statement We are now ready to move to the application layer. Let's see
what applications use TCP/IP to handle their communication needs.

Instructor Guide
Some Standard TCP/IP Applications

FTP DNS
TFTP SMTP
SNMP TELNET
Common Principles
They use either UDP or TCP as the transport mechanism

They use the client-server model of interaction
Figure 1-25. Some Standard TCP/IP Applications AU079.1
Notes:
File Transfer Protocol (FTP)

File Transfer Protocol (FTP) provides for the copying of files from one machine to
another. It requires reliable end-to-end transfer, so it uses TCP.
Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP) also provides for the copying of files from one
machine to another. It has been implemented on the UDP protocol and lacks most of
the features of FTP. The only thing it can do is read or write a file from or to a server. It
has no provisions for user authentication.

V3.1.0.1
Instructor Guide
Uempty Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) is used to communicate management
information between network management stations and the agents in the network
elements.
Domain Name System (DNS)

Domain Name System (DNS) allows a host in a domain to act as a name server for
other hosts within the domain.
Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer Protocol (SMTP) provides message and note exchange between
TCP/IP hosts.
TELtypewriter Network (TELNET)

TELtypewriter Network (TELNET) provides an interface for one host to access the
resources of another host as though it were a locally attached terminal.

Instructor Guide
Instructor Notes:
Purpose Identify some of the most common applications in the TCP/IP suite. We are
now at the top layer of the architecture.
Details Explain the acronyms so students will understand when you refer to them. There
are many other applications that use TCP/IP. Some others can be seen by looking at the
/etc/services file where applications, the protocol they use, and the port numbers they use
are listed. Remember, these applications are the ones that have registered with the IANA.
Others may have ports assigned dynamically at startup when they register with the
portmap daemon. We discuss the portmap daemon when we get to NFS.
Transition Statement Let's put this all together and see how application data flows
through the protocol layers.

V3.1.0.1
Instructor Guide
Uempty
UDP Data Flow
APPLICATION
DATA DATA
User
Kernel
Transport Layer UDP DATA
Datagram
FRAGMENT 1 FRAGMENT 2
Internet Layer IP UDP DA IP TA Datagram
MTU
(IP Fragmentation)
Network
LINK IP UDP DA CHKSUM Frame
Interface
Layer
MTU: Maximum Transmit Unit
Figure 1-26. UDP Data Flow AU079.1
Notes:
Copying data to kernel memory

The data coming from user space must be copied to kernel memory. The maximum
data that can be copied to and reside in kernel memory is defined by global and
socket-specific variables.
Transport layer activity

Once the memory space is allocated to hold the application data, and the data is
physically copied from user to kernel space, the transport layer, in this case UDP, adds
a header which specifies the source and destination application port address, the length
of the datagram and a checksum.
The UDP layer does not provide a reliable transport mechanism, and it is up to the
application to provide some sort of mechanism that assures the consistency of the data
being transported.

Instructor Guide
IP layer activity
Since UDP does not control the amount of data to be sent in each datagram or UDP
message, and it is only limited by the amount of memory assigned to the specific
socket, the IP layer must assure that the amount of data passed to the lower layers can
be handled by them. This is not global, but it is based on the destination address of the
outgoing message, which defines the adapter to be used to send the packet.
If the total amount of data to be sent through a specific adapter, including protocol
headers, is larger than the amount of data that the adapter can handle at once (MTU),
the IP layer fragments (the process is called IP fragmentation) the data to comply with
the MTU. Each fragment includes an IP header with a sequence number that is used by
the destination system to reassemble the packet. If the destination address is not local,
the packet is not reassembled until arrival at its final destination, which means that each
fragment could be even more fragmented if MTUs are smaller in other intermediate
networks.
Network interface layer activity

Finally, the data is sent to the adapter by the interface layer which adds a header with
source and destination MAC addresses, network architecture (Ethernet) and type (IP),
and a final checksum.

V3.1.0.1
Instructor Guide

Purpose Explain the UDP data flow.
Details The maximum amount of data that UDP can send at once is limited by the size
of the memory buffer assigned to a specific UDP socket, and the maximum packet size that
the IP layer can handle in each packet.
UDP does not assure that the data is received in the same order that it was sent, and the IP
layer only assures that each UDP packet arrives complete. It is up to the application to
reassemble the final message which is the ultimate goal of the application communication.
Transition Statement Let us look at TCP data flow.

Instructor Guide
TCP Data Flow

APPLICATION
DATA DATA
User
Kernel
Transport Layer TCP DA TCP TA Segment
MSS
Internet Layer IP TCP DA IP TCP TA Packet

MTU
(NO IP Fragmentation)
Network
LINK IP TCP DA CHKSUM Frame
Interface
Layer
MSS: Maximum Segment Size

MTU: Maximum Transmit Unit
Figure 1-27. TCP Data Flow AU079.1
Notes:
Passing data to transport layer

Data from an application is passed to TCP in a stream of bytes through a socket buffer.
Transport layer processing

TCP takes the stream of bytes and breaks it into segments, adding header information
to each segment. TCP header information includes byte sequence numbers and port
numbers. TCP then passes the TCP segment to the IP layer.
IP layer processing
IP adds its header information of IP destination and source address to the TCP
segments and passes the IP packet to the network interface.

V3.1.0.1
Instructor Guide
Uempty Network interface layer processing

The network interface adds its header information, such as the physical address, and
an interface checksum, and then sends the frame down the wire.
Destination host activity

At the destination host, the reverse happens as each layer removes its information,
checks for accuracy, and passes the information to the next layer until it finally reaches
the destination application.

Instructor Guide
Instructor Notes:
Purpose Explain TCP data flow.
Details A TCP/IP network can transfer any unstructured stream of data. In order to
transport this data across a network, it is split into multiple pieces by the transport layer
(TCP or UDP). These are reassembled by the transport layer at the destination so that the
application receives the data in the same form as it was sent.
TCP will add header information for TCP on the destination system. This identifies the
destination program and includes checksums to ensure data integrity and sequence
numbers so that packets are repackaged in the correct order.
An IP datagram is the basic unit of information passed across the network. It contains the
source and destination address along with the data from the transport layer. Internet
protocol is responsible for routing this datagram to its destination.
The network interface layer then packages the data for transmission across the physical
media. The transmitted package is called a frame. The size and format of a frame varies
between different types of networks.
A datagram can be larger than the maximum frame size for a particular type of network.
These datagrams are fragmented by the network interface into multiple frames. Each frame
is sent (with appropriate checksums and sequence numbers), and the receiving network
interface reassembles these before passing the datagram to the IP layer on the destination
host.
Transition Statement Now that we have an idea of the layers, let's see how these are
used to connect networks together.

V3.1.0.1
Instructor Guide
Uempty
Network Connections
Ethernet
Token Bridge Hub
Ring
(IP)
Repeater
Gateway
Token
Ring X.25
(SNA)
router
Gateway
Figure 1-28. Network Connections AU079.1
Notes:
Physical network
On a physical network, all hosts are linked by the same media, such as a single
Ethernet or token ring.
Logical network
A logical network consists of one or more physical networks connected by repeaters or
bridges. All hosts in a logical network share the same IP network address.
With a bridge or repeater, the network is considered by TCP/IP to be one network
because all data is passed between networks at a level lower than the network layer.
This means only one IP network address is required to address all hosts on the
interconnected physical networks.

Instructor Guide
Inter-network (internet)
An inter-network or internet contains multiple logical networks connected by routers or
TCP/IP gateways. All data is passed at the network layer so each component network
must be given a separate IP network address. It is IP that is providing the router
functionality based upon those IP network addresses.
The linking of logical networks that use different protocols is done through a gateway
which may even perform a protocol conversion. This is a relatively new use of the term
gateway in TCP/IP discussions and can often be confusing if taken out of context.

V3.1.0.1
Instructor Guide

Purpose Describe what devices and methods are used to connect networks together.
Details In normal networking terminology, there are four roles a machine can perform in
a network to connect two networks together:
Repeater
- Sends electrical signals from one physical network to another of the same type
- Boosts electrical signal for longer distances
- Provides no filtering of traffic between two networks
- Hardware only device
Bridge
- Links two similar physical networks (that is, compatible frame formats) to make them
look like one (for example, Token-Ring to Token-Ring or Ethernet to Token-Ring)
- Filters frames based upon multiple criteria including: hardware address, network
protocol
- Independent of network layer protocol
- Provided as custom link layer software on normal computer or custom hardware
Router
- Provided by network layer protocols, like IP
- Reads datagrams from one network interface and can pass them to a different
interface on a dissimilar type of network with an incompatible frame format.
- Makes routing decisions based upon network layer addresses
- Network layer software on normal computer or custom hardware
- Any TCP/IP computer with multiple adapters can be a router
Gateway
- Can link logical networks using different protocols, (for example, TCP/IP or OSI or
SNA)
- May perform protocol conversion
- Usually converts application data rather than arbitrary packets (for example, mail
gateway to convert X.400 mail into TCP/IP mail)
- Custom software at or above transport layer
Brouter
- A device that performs both bridging and routing
Hub
- A device that provides a central connection point for computers in a network. Most
hubs today are active hubs which monitor performance, collisions and regenerate
weak signals. There are, however, important differences between hubs and
switches. (See next visual.)

Instructor Guide
Many composite bridge or router devices exist which can be used to link different types of
networks and pass data between them.
This chart is a good place to introduce the fact that a router or host with multiple interfaces
must have a different IP address for each interface.
Note: In TCP/IP, the term gateway is often used to refer to an IP router. To know which way
the term gateway is being used, check the context in which it is being used.
Additional Information A network in general terms can be seen as a collection of
network nodes or switches through which a packet or datagram must travel to reach a
predetermined exit point from the network. Selecting a path through a number of those
switches that guarantees the service requirements of the user is typically a task associated
with routing and routers. The observant reader may notice that this definition is also true for
bridges in a local area network. It is therefore useful to make a distinction between a bridge
and a router.
A bridge makes two physical networks appear like one single logical network.
A router makes two physical networks appear like two logical networks.
Transition Statement Now, let's look at a newer technology that is very similar to
bridging.

V3.1.0.1
Instructor Guide
Uempty
LAN Switching
Single logical Switches can provide:
IP network Full duplex transmission
VLAN support
Virtual Etherchannel
LAN Segment Layer 3 routing
VLAN LAN Segment
Ethernet
Switch
Figure 1-29. LAN Switching AU079.1
Notes:
Two similar technologies: LAN switching and bridging

LAN switching is a technology very similar to bridging. As with bridging, a number of
physical networks are connected in a way that is transparent to the IP layer. The result
is that IP sees the group of physical networks as a single logical network, and therefore
a single IP network address is used throughout all the physical networks.
Switches are commonly used with LAN technologies such as Ethernet, token ring, FDDI
and ATM.
Like bridges, switches operate at the network interface layer. Thus, as frames pass
through a switch, they never reach the IP layer. For this reason, some vendors argue
that switches are more efficient than routers. They also are able to handle multiprotocol
traffic (for example, IP, IPX, SNA) in a more consistent way than routers can.

Instructor Guide
Differences between switches and bridges

The primary differences between switches and bridges are:
Switches use more modern technology and are therefore faster than bridges.
Switches normally provide advanced features such as VLAN support, full duplex
transmission, Layer 3 routing, and Etherchannel. Each of these advanced features is
described further in the following paragraphs.
VLAN support
Use of VLANs allows the administrator to arbitrarily group systems from the physical
networks into virtual networks. This allows related systems to reside in the same logical
IP networks, improving performance and ease of use. A switch that you have
implemented VLANs on now has multiple broadcast domains, similar to those delimited
by routers. But you still need a router to route from one VLAN to another; the switch
can't do this by itself, unless it is Layer 3 capable. (Refer to the paragraph below entitled
Routing for more details.)
Full duplex transmission

The analogy is a car intersection. If more than one car reaches the intersection at the
same time, each has to wait for its turn to proceed. But a switch is like a tunnelled
intersection. Each car can take a tunnel through the intersection to get to its destination
without having to stop and wait for other traffic to go by. Now imagine what this would be
like with a dozen or even a hundred roads intersecting at a single point. The amount of
waiting and the potential for a collision crash increases significantly if every car has to
check all the other roads before proceeding. Therefore, unlike having 10 hosts
connected to a 100 Mbit Hub, each of the 10 hosts will share the bandwidth and have
the possibility of collisions. Whereas with 10 hosts connected to a switch, each
communication has its own dedicated 100 Mbit connection.
Routing
Certain advanced switches support Layer 3 routing. A Layer 3 switch is extremely
similar to a router. When a router receives a packet, it looks at the Layer 3 (the network
layer) source and destination addresses to determine the path the packet should take.
A standard switch relies on the MAC addresses to determine the source and destination
of a packet, which is Layer 2 (data) networking. The fundamental difference between a
router and a Layer 3 switch is that Layer 3 switches have optimized hardware to pass
data as fast as Layer 2 switches, yet they make decisions on how to transmit traffic at
Layer 3, just like a router would. Within the LAN environment, a Layer 3 switch is
usually faster than a router because it is built on switching hardware. For example,
many of Cisco's Layer 3 switches are actually routers that operate faster because they
are built on switching hardware with customized chips inside the box.

V3.1.0.1
Instructor Guide
Uempty Etherchannel
Etherchannel is a technology of logically grouping together interfaces on a multi-homed
host. This logically grouped series of interfaces appears as a single interface but in fact
shares multiple communication pipes. Both host and switch must support Etherchannel
for this to work.

Instructor Guide
Instructor Notes:
Purpose Provide an overview of LAN switching and how it relates to IP.
Details LAN switches are the follow-on technology to bridging. In principle, the two are
quite similar, since they both operate at layer two in the OSI model and are largely
transparent to layer three protocols such as IP. However, switches are much higher
performance devices and also support advanced features such as VLANs.
One technology used in some switches to boost performance is cut-through switching.
Here, the leading edge of the frame is transmitted on the outgoing interface before the
complete frame has been received into the switch. This is in contrast to the store and
forward technique used in bridges and most routers.
Switches are very popular today and it is quite common to find an entire building or even
campus that uses switches to create a single logical IP network.
Transition Statement When we discussed addressing earlier, it was mentioned that the
network address is assigned to you. What if you really need to have several physical
networks but have only one network address? Use subnetting.

V3.1.0.1
Instructor Guide
Uempty
Subnetting
Allows an autonomous system made up of multiple physical
networks to share the same Internet network address
The outside Internet Subnet 129.112.1

sees only 1 network,
Net 129.112
Outside
Subnet 129.112.2 Subnet 129.112.3
Figure 1-30. Subnetting AU079.1
Notes:
Limit in number of networks

The standard address classes allow only a limited number of networks. The number of
free addresses could easily become exhausted if every time an organization needed to
create a new physical network it had to get a new network ID from the InterNIC. Thus, a
better way to utilize existing addresses was developed - subnetting.
When to use subnetting

Subnetting can be used in the following situations:
- A new type of physical network is installed
- The number of hosts increases and the local physical network must be split into
multiple physical networks
- As the network grows larger and the distances increase, it may be necessary to
divide the network into smaller parts and establish gateways to interconnect them

Instructor Guide
Setting up subnetting
Implementation of subnetting involves the following steps:
- The network administrator decides how many subnetworks and hosts are necessary
- Network administrator selects how many and which bits of the host address portion
of the IP address are subnetted to be used as part of the network address portion
- The subnet mask is configured on the router and all machines on the subnets
With subnetting, one address may be known to the Internet, while internally the packets
are distributed to the correct network.

V3.1.0.1
Instructor Guide

Purpose Explain the concept of subnetting.
Details The success of the Internet is probably one of the major problems the designers
have had to face. The Internet's initial design was aimed at a prototype with a few dozen
networks to interconnect and a few hundred hosts. The designers couldn't have been more
mistaken when one compares the initial target with today's reality. Due to the explosive
growth of the Internet, the principle of assigned IP addresses became too inflexible to allow
easy changes to local network configurations.
To avoid having to request additional IP network addresses in these cases, the concept of
subnets was introduced. RFC 950 defines subnets for the Internet.
Today, all hosts that are connected to the Internet are required to support subnet
addressing. Subnet addressing takes the host ID part of the network address and splits it
into a subnet ID and a host ID. This makes good sense for class A and class B addresses
since attaching thousands and thousands of hosts to a single network is simply not
possible.
Create an understanding of the need for subnetting. Use the diagram as an example to
illustrate. For example: your company has the 129.112 network that allows them 65,534
hosts to be on their network. Is this manageable? Then, someone comes along and says
they want an Ethernet network. They ask their Internet registry for a new network number
but are turned down. How do they then connect the Ethernet? Solution: Add a subnet mask
to extend the network part of the address--so the Token-Ring becomes 129.112.1 and the
Ethernet is 129.112.2.
Each network can now connect up to 254 hosts.
Subnet masking is simply taking the network ID given to you and extending the network ID
portion of the address so that you can have multiple networks. You are simply borrowing
bits from the host octets and allowing them to be used to extend the network portion.
Transition Statement Now that we've seen an example of how subnetting can be used,
let's look at the structure of subnetwork addresses.

Instructor Guide
Subnetted Address
Address without subnetting:
Network Host
ID ID
With subnetting:
Subnetwork ID Address
Host
Network Subnet ID
Portion Portion
111 ... ... ... ... 111 000 ... 000 Mask
Figure 1-31. Subnetted Address AU079.1
Notes:
Introduction
With subnetting, the structure of the IP address is changed to allow several
subnetworks to be addressed within a single network. To do this, some of the bits
originally used for the host ID are taken for use as the subnetwork ID.
Address interpretation without subnetting and with subnetting

As shown on the visual, without subnetting, an IP address is regarded as being
composed of simply a network ID and a host ID. When subnetting is used, the IP
address is considered to have three parts: network ID, subnetwork ID and host ID. The
network ID is the same portion as in the non-subnetted case. The subnetwork and host
IDs are taken from the host ID of the non-subnetted address.
When subnetting is being performed, the hosts and routers in the local portion of the
internetwork treat the network and subnetwork portions of the address collectively as

V3.1.0.1
Instructor Guide
Uempty the subnetwork ID, which has the same purpose in the subnetted case that the network
ID does in the non-subnetted case. The host ID (the bits left after the subnetwork ID)
uniquely identifies hosts within subnetworks.
The subnet mask

All routers and hosts in the local portion of the internetwork must be informed of the
subnet mask in use. The mask indicates which bits in the IP address are to be treated
as the subnetwork ID, and which as host ID. Specifically, where a bit is one in the
subnet mask, then the corresponding bit in the IP address is considered to be part of
the subnetwork ID. Where a bit is zero in the mask, the corresponding address bit is
considered to be part of the host ID. Thus, the subnet mask allows IP hosts and routers
to identify which of the bits in the original host ID have been appropriated for use in the
subnetwork ID.
Special cases
Note that as with network and host IDs, the subnetwork portion is not allowed to consist
of all zeroes or all ones. Thus, while a one octet subnet portion provides 256
combinations of zeroes and ones, the values 00000000 and 11111111 are reserved and
therefore the octet provides addressing for only 254 subnetworks.

Instructor Guide
Instructor Notes:
Purpose Explain the structure of subnetted addresses.
Transition Statement Let's consider an example.

V3.1.0.1
Instructor Guide
Uempty
Subnetting Example
Class B address without subnetting:
Network ID Host ID
10000001 01110000 00000011 00000111
129 112 3 7
With subnetting:
Subnetwork ID Host ID
10000001 01110000 00000011 00000111 Address
129 112 3 7
11111111 11111111 11111111 00000000 Mask

255 255 255 0
Figure 1-32. Subnetting Example AU079.1
Notes:
Importance of the subnet mask

In the example on the visual, a class B network address is being used to address
several subnetworks. The subnet mask of 24 ones followed by 8 zeroes (written in
dotted decimal as 255.255.255.0) indicates that the leftmost three octets of the IP
address are to be used as the subnetwork ID and the rightmost octet as the host
address. This allows us to create subnetworks by varying the bits in the third octet from
the left. For example, one subnet could have the ID 129.112.3, while another could be
129.112.4, and so on.
View from inside and from outside the network

The assignment of subnets can be done locally, so that the whole network still appears
to be one IP network to the outside world. Thus, in the example on this visual, the
systems inside the class B network 129.112.0.0 could all use the subnet mask of
255.255.255.0 so that they will correctly understand the subnetwork structure. Systems

Instructor Guide
outside treat the network as a single class B network. As long as there is only one way
to enter and exit the network, this fiction is harmless, and in fact makes routing and
administration simpler outside the class B network. If there are multiple ways to
enter/exit the network, then at least some of the systems outside would also have to
understand the subnetworking structure.

V3.1.0.1
Instructor Guide

Purpose Explain the structure of subnetted addresses using an example.
Transition Statement Let's look at a type of subnet mask that does not change the way
systems treat IP addresses.

Instructor Guide
Default Subnet Masks
CLASS A
{ 11111111 00000000 00000000 00000000 Binary
255.0.0.0 Dotted Decimal
{
11111111 11111111 00000000 00000000 Binary
CLASS B
255.255.0.0 Dotted Decimal
11111111 11111111 11111111 0000000

CLASS C
{ 255.255.255.0
Binary
Dotted Decimal
Figure 1-33. Default Subnet Masks AU079.1
Notes:
Concept of masking
Subnet masks define the network address portion of the IP address.
A subnet mask is 32 bits. A bit value of 1 in the subnet mask indicates that bit position is
part of the network address portion of the IP address.
Default masks
There are default subnet masks set with each class of address. Using an address mask
that is the default for an address class indicates that subnets are not in use for the
network.

V3.1.0.1
Instructor Guide

Purpose Explain the concept of default subnet masks.
Details Review default masks. They are implied but not actually used. Explain the
concept of masking. A subnet is defined by applying a bit mask called a subnet mask. This
bit mask is applied to the IP address. If a bit is on (set to 1) in the mask, it is interpreted as
a network bit. If a bit in the mask is off (set to 0), the bit belongs to the host portion of the IP
address.
Think of putting a mask that is divided into four octets over a binary IP address. Anywhere
there are 1's, a hole is punched so you can see through them. The zeros hide what is
behind the mask. Thus, only the network portion is showing through the mask.
Transition Statement It's possible that the boundary between the subnetwork ID and
host ID is not aligned with the byte boundaries of the IP address.

Instructor Guide
Subnet Mask Off-the-Byte Boundary

Class B 10 Net-ID Host-ID
Address
255 255 240 0

Subnet Mask 1111111 11111111 11110000 00000000
Subnet
Host-ID
129 112 16
Subnet 1 10 000001 01110000 00010000 00000000
129 112 32
Subnet 2 10 000001 01110000 00100000 00000000
129 112 64
Subnet 3 10 000001 01110000 01000000 00000000
Figure 1-34. Subnet Mask Off-the-Byte Boundary AU079.1
Notes:
Introduction
The subnet portion of the IP address does not have to be adjacent to the network
portion. In fact, the subnet portion can be any bits from the host ID portion. The netmask
determines which bits from the host ID portion constitute the subnet bits.
Subnet requirements
Note the following requirements for subnets:
- Network address is constant for all subnets
- Hosts on a subnet usually share the same physical cable
- Subnet address is usually constant throughout the physical network
- At least one bit must be used for the host ID
- Subnetmask is netmask for IP class plus 0 or more bits

V3.1.0.1
Instructor Guide
Uempty - If used, subnetting must be used throughout a network associated with a given net
ID.
Discussion of example
The number of available networks in this example is 14 (24 -2).
The number of host addresses available per subnet are 4094 (212 -2). Valid subnet
network addresses are 16, 32, 48, 64... 224.
The following table lists the valid subnet values for subnet mask of 255.255.240.0.
Hex. value Subnet

value
0001 16
0010 32
0011 48
0100 64
0101 80
0110 96
0111 112
1000 128
1001 144
1010 160
1011 176
1100 192
1101 208
1110 224
For each of these subnets, 4094 addresses are available for hosts because the
right-most 12 bits are the host portion (giving 2 to the 12th power = 4096 possibilities)
and two of those possibilities (all zeros and all ones) are reserved.
The subnet 129.112.16.0 contains hosts whose IP addresses range from 129.112.16.1
to 129.112.31.254. Subnet 129.112.32.0 will have addresses ranging from 129.112.32.1
to 129.112.47.254.

Instructor Guide
Special cases
As in the IP addressing restrictions, all zeros and all ones cannot be used for subnet
ids. All zeros means this subnet and all ones means all subnets.

V3.1.0.1
Instructor Guide

Purpose Provide an example of a subnet ID not aligned on the octet boundary.
Details The subnet mask can be established to use any bits from the host ID portion of
the IP address but at least two bits must be reserved for use by the host ID.
To implement a convention for the subnet address, one could select one of the items from
the following (non-exhaustive) list:
Bits 0, 1, 8, and 9 are used for the subnet address; that is, the two high-order bits of
each of the bytes. This gives us 14 possible subnets (16 minus 2, as values 0 and all
ones have special meanings).
All even bits are used for the subnet address, the odd ones for the host address. This
gives us 254 possible subnets (256 minus 2).
The first 12 bits are used for the subnet address, the 4 last ones for the host address.
This gives us only 14 hosts per subnet.
The first byte is the subnet address; the second the host address. This gives us 254
possible subnets, each having up to 254 hosts.
There are many more possible choices.
While one is completely free to assign the subnet part of the local address, it is obvious that
assigning a contiguous block of bits at the beginning of the local address part makes the
addresses more readable. In general the use of non-continuous subnet masks is bad
practice.
Transition Statement Let's look at another example of an off-the-byte boundary subnet
mask.

Instructor Guide
Subnetting Scenario
Class B Network 129.112.0.0

Subnet mask = 255.255.192.0
129.112.128.1
129.112.64.1
129.112.64.3 Subnet
Subnet 129.112.128.0
129.112.64.0 129.112.128.3
129.112.64.2 129.112.128.2
255 255 192 0 255 255 192 0

11111111 11111111 11000000 00000000 Mask 11111111 11111111 11000000 00000000
129 112 64 0 129 112 128 0

10000001 01110000 01000000 00000000 Subnet 10000001 01110000 10000000 00000000
129 112 64 1 129 112 128 1

10000001 01110000 01000000 00000001 1st Host 10000001 01110000 10000000 00000001
129 112 127 255 129 112 191 255
. 10000001 01110000 01111111 11111111 Broadcast 10000001 01110000 10111111 11111111
Figure 1-35. Subnetting Scenario AU079.1
Notes:
Discussion of example on visual

This visual shows an example in which subnetting is used to address two subnetworks
with a single class B network address. The mask of 255.255.192.0 provides two valid
subnet IDs, 129.112.64 and 129.112.128. The IP addresses of the hosts and the routers
are shown in the diagram. Also shown for each subnetwork are the subnet mask,
subnet address, broadcast address and the first host address. The latter is the lowest IP
host address in the subnetwork.
Broadcast address
The broadcast address for a subnetwork is the address to which a packet would be sent
so that all systems in that subnetwork receive a copy. The broadcast address is formed
by taking the subnetwork's full address and setting all the host bits to one. This is
illustrated at the bottom of the visual.

V3.1.0.1
Instructor Guide

Purpose Explain the subnet masks, subnet IDs, host addresses and broadcast
addresses for this scenario.
Details Cover the broadcast example and how to break down the third octet to
determine the host portion and the network portion.
Transition Statement The exercise/activity on the next visual is provided for use at the
instructors discretion. For this reason, the visual title includes the words Optional Activity.
Pick the appropriate transition statement from the two suggestions given below, depending
on whether or not you decide to include the optional activity:
Lets do an exercise to help us make sure that everyone is comfortable with the
subnetting information thats just been presented.
-OR-
Were not going to do the subnetting activity on the next visual in class, but you may
want to complete this exercise on your own. Instead, lets move on to an example of
supernetting.

Instructor Guide
Optional Activity: Subnet Masks

1. Given a class B subnet mask of 255.255.255.192. How many
subnetworks can there be, and how many hosts per subnetwork?
2. BigBucks.com is about to set up business across Europe. Some

years ago, this organization acquired a class B network address
of 150.34.0.0. They have asked you to design a network that
allows for 15 networks and up to 1000 hosts per network, leaving
room for further expansion. What subnet mask should be used?
3. Given an IP address of 201.100.23.201 and a subnet mask of

255.255.255.224. What are the network address, the broadcast
address, and the IP address of the first host on the network?
Figure 1-36. Optional Activity: Subnet Masks AU079.1
Notes:

V3.1.0.1
Instructor Guide

Purpose Complete an activity designed to enhance student understanding of
subnetting.
Details Completion of this activity is optional. Skip it if you wish to do so.
A solution for this activity is given below:
Optional Activity: Subnet Masks - Solution

There can be 1022 subnetworks and 62 hosts per network.

A subnet mask of 255.255.248.0 is needed.

The network address is 201.100.23.192. The broadcast

address is 201.100.23.223. The first host on the network
would use the address 201.100.23.193.
Transition Statement Now, lets consider supernetting.

Instructor Guide
Supernetting (CIDR)
192.17.129.10 192.17.130.10
192.17.128.12
192.17.128.10
192.17.129.11
192.17.130.11
Router Router
192.17.128.11
192.17.129.12 192.17.130.12
255 255 252 0
Mask 11111111 11111111 11111100 00000000
192 17 128 0 Supernet Address

11000000 00001001 10000000 00000000
192 17 128 0
Networks 192 17 129 0 11000000 00001001 10000000 00000000
11000000 00001001 10000001 00000000
192 17 130 0
11000000 00001001 10000010 00000000
Figure 1-37. Supernetting (CIDR) AU079.1
Notes:
Overview of supernetting
Whereas subnetting takes part of the host portion of the IP address and adds it to the
network portion, supernetting works the opposite way. It effectively reduces the number
of bits used for the network portion. This technique allows a number of Class C
addresses to be aggregated into a single address for routing purposes.
Routing tables had become swollen with numerous Class C addresses by the early
1990s, leading to fears that some routes would be omitted, making those networks
unreachable. In response, a system called Classless Interdomain Routing (CIDR) was
developed. With CIDR, the Internet Registries allocate blocks of Class C addresses to
Internet Service Providers, who assign them to customers.

V3.1.0.1
Instructor Guide
Uempty Discussion of example

In our example, a company has been given three class C network addresses:
192.17.128.0, 192.17.129.0 and 192.17.130.0. These three addresses vary only in the
23th bit. By using a 22 bit network mask (255.255.252.0), these three class C networks
can be treated as a single larger network (hence allowing deletion of the routers from
the diagram). This allows the company to have up to 1022 hosts in the supernetted
network.
A router sending a packet to the supernetted network would consider only the first 22
bits in the host address. Thus, a packet addressed to 192.17.128.3 or to 192.17.129.77
would have the same destination network address of 192.17.128.0.
A network that has been supernetted in this way often has its address written as
192.17.128.0/22. In this example, the 192.17.128.0 is called the prefix since it the
sequence of bits that all addresses in the network must begin with. The /22 is an
alternative way of writing the mask, signifying 22 bits of ones beginning at the left, and
is an alternative way of writing 255.255.252.0.

Instructor Guide
Instructor Notes:
Purpose Provide an overview of how supernetting works.
Details CIDR is documented by RFCs 1517 through 1520. The RFCs refer to the
network address and mask as a prefix. The following is a table of the most commonly used
CIDR prefixes. For example, a prefix with a 24-bit mask allows 254 unique network
addresses the same as a Class C address. A prefix with a 15-bit mask allows 131,070
hosts the same as 128 Class B addresses. The 127 addresses consecutively numbered
after the prefix address will all be treated by routers as being part of that prefix.
CIDR prefix Number of host Equivalent
addresses Class Cs
/27 30 1/8
/26 62 1/4
/25 126 1/2
/24 254 1 (like a Class C)
/23 510 2
/22 1,022 4
/21 2,046 8
/20 4,094 16
/19 8,190 32
/18 16,382 64
/17 32,766 128
/16 65,534 256 (like a Class B)
/15 131,070 512
/14 262,142 1,024
/13 524,286 2,048
Transition Statement Now let's move on to consider IP multicasting, which allows a

group of nodes to receive the same message.

V3.1.0.1
Instructor Guide
Uempty
IP Multicasting
Allows a group of nodes in a network to receive the same message
Each node maintains a list of multicast addresses to which it
responds
Useful in:
Multimedia Applications, that is, video streaming
Dynamic routing updates
Minimizes the network load
Figure 1-38. IP Multicasting AU079.1
Notes:
Overview of multicasting
The problem with broadcasting is the processing load it places on hosts that aren't
interested in the broadcast. The intent of multicasting is to reduce the load on hosts not
interested in receiving the message. IP multicasting allows a group of nodes to receive
the same message. Each member of the group simply joins the same group to receive
the message. Contrary to broadcast messages where all nodes receive the message,
only the nodes interested in getting the message join the multicast group so that other
nodes on the network are not affected by the transmission of multicast packets on their
networks. Thus, this fits nicely for network conferencing applications.
Host groups
The set of hosts listening to a particular IP multicast address is called a host group.

Instructor Guide
Instructor Notes:
Purpose Briefly describe what multicasting is and the role it plays in the network.
Details IP multicasting is supported on Ethernet, token ring and FDDI adapters. IP
multicasting is used by many applications and other protocols, like Open Shortest Path
First (OSPF). We discuss OSPF later when we talk about routing.
With multicasting, a host specifically joins one or more multicast groups. If possible, the
interface card is told to which multicast groups the host belongs and only those multicast
frames are received.
The set of hosts listening to a particular multicast address is a host group. A host group can
span multiple networks. Membership in a host group is dynamic, that is, hosts may join and
leave groups at will. There is no restriction on the number of hosts in a group, nor does a
host have to belong to a group to send messages to that group.
IP Multicasting is used with Internet Chat, Internet Talk Radio, and Internet Phone.
Additional Information Some multicast groups are assigned well-known addresses.
These are called permanent host groups. (The idea here is similar to the well-known port
concept.)
Transition Statement Let's take a little closer look at how multicast addressing and
connections are handled.

V3.1.0.1
Instructor Guide
Uempty
IP Multicast Addressing
A logical address filter mechanism in the adapter is used to
determine whether or not to accept an incoming packet with a
multicast destination address
Standard socket interface used to create multicast connections
Multicast addresses are Class D addresses
28 bits
1110 Multicast address
224.0.0.0 to 239.255.255.255
Figure 1-39. IP Multicast Addressing AU079.1
Notes:
Levels of support for multicasting

RFC 1112 defines three levels of conformance to multicasting:
- Level 0: no support
- Level 1: support only for sending multicast messages
- Level 2: full support
At the time these materials were written, there was no requirement that all IP
implementations support multicasting. In general, hosts that don't support multicasting,
Level 0 hosts, are unaffected by multicast activity.
Level 1 support allows a host to take part in some multicast-based services, such as
resource location, but it does not allow a host to join any host groups.
Level 2 provides full support for all multicast activities.

Instructor Guide
Implementation of multicasting
Multicasting is implemented through socket-based APIs in application programs.
A reserved range of addresses

The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for
the use of routing protocols and other low-level topology discovery or maintenance
protocols, such as gateway discovery and group membership reporting.
Examples of multicast addresses

Some examples of currently assigned multicast addresses are the following:
- 224.0.0.1 All Systems on this Subnet
- 224.0.0.2 All Routers on this Subnet
- 224.0.0.9 RIP2 Routers
- 224.2.0.0 - 224.2.127.253 Multimedia Conference Calls

V3.1.0.1
Instructor Guide

Purpose Provide further information on how addressing is handled when doing
multicasting.
Details Multicasting is based on RFC 1112 Host Extensions for IP Multicasting. It uses a
standard socket interface to create the connections. The UDP/IP protocol is used to send
messages to members of the multicast group.
Level 2 support requires implementation of an IP protocol extension, the Internet Group
Management Protocol (IGMP)
Additional Information Extensions to the IP service interface as defined in RFC 1112
had to be defined for both sending and receiving IP multicasts. On sending an IP multicast,
the following extensions had to be made:
A way needed to be provided for the upper-layer protocol to specify the IP time-to-live of
an outgoing multicast datagram. The default should be 1 so that the application is
required to choose to multicast beyond a single network.
For hosts with more than one network interface, a way needed to be provided to identify
which interface to use for the multicast transmission. Only one interface is used for the
initial transmission with multicast routers responsible for forwarding it to any other
networks, if required. If an interface is not identified by the application, then a default
interface is used.
Three new set/get socket options had to be added at the IP protocol level to support the
new service requirements.
On receiving a multicast, the following extensions had to be made:
Incoming multicast IP datagrams are received by the upper-layer protocols using the
same operation as a regular IP process. However, before any datagrams destined for a
particular group can be received, an application must ask the IP module to join that
group. Thus, the IP service was extended to provide two new operations, the
JoinHostGroup and LeaveHostGroup operations. The JoinHostGroup operation
requests that this host become a member of the host group identified in the group
address and network interface passed to it, and the LeaveHostGroup operation
requests that the host give up its membership, once again based on the group address
and network interface provided to it. New setsockopt system calls were needed to
support these functions.
In addition, a new protocol, the Internet Group Management Protocol (IGMP), was added
for use by IP hosts to report their host group memberships to any immediately-neighboring
multicast routers. Like ICMP, IGMP is an integral part of IP. It is required to be implemented
by all hosts conforming to level 2 of the IP multicasting specification.
Transition Statement Lets now answer some checkpoint questions.

Instructor Guide
Checkpoint (1 of 4)
1. (True or False) IP addresses must be unique for each interface
on the network.
2. (True or False) Protocols define rules for orderly
communications.
3. A socket consists of:
a. A machine address and port number
b. An IP address, port number, and protocol family
c. A machine address and IP address
d. A host name and port number
4. A gateway in TCP/IP terminology is synonymous with:
a. Bridge
b. Repeater
c. Router
d. Logical link device
Figure 1-40. Checkpoint (1 of 4) AU079.1
Notes:

V3.1.0.1
Instructor Guide

Purpose Discuss the first group of checkpoint questions.
Details The checkpoint for this unit is longer than usual (and requires several visuals to
present), but this is appropriate because of the amount of material covered in the unit.
A Checkpoint Solution for this group of questions is given below.
Checkpoint Solutions (1 of 4)
on the network.
communications.
a. Bridge
b. Repeater
c. Router
Additional Information This is the first of four groups of checkpoint questions for this
unit.
Transition Statement Lets move on to the next group of questions.

Instructor Guide
Checkpoint (2 of 4)
5. How many bits make up the unique physical address of a network
adapter?
a. 16
b. 32
c. 48
d. 64
6. How many bits make up a Internet Protocol V4 address?
a. 16
b. 32
c. 48
d. 64
7. What are the two pieces of an Internet address?
_________________________________________
8. (True or False) When you accept the defaults, the portions of the
Internet address used for the network address and the local host
address are determined by the address class (A, B, or C).
Notes:

V3.1.0.1
Instructor Guide

Purpose Discuss the second group of checkpoint questions.
Details A Checkpoint Solution for this group of questions is given below.
adapter?
a. 16
b. 32
c. 48
d. 64
a. 16
b. 32
c. 48
d. 64
Network address and local host address
Additional Information This is the second of four groups of checkpoint questions for
this unit.
Transition Statement Lets move on to our third group of questions.

Instructor Guide
Checkpoint (3 of 4)
9. (True or False) An Internet address is usually written in a form
known as dotted decimal notation, where the value of each byte
of the address is written in decimal and the bytes are separated
by periods.
10. What is the special address 127.0.0.1?
__________________________________________________
__________________________________________________
11. What decimal value is used in the host address octets for
sending broadcast messages?
__________________________________________________
12. (True or False) ARP is designed for networks with broadcast
ability only.
13. Why is the client side port included in UDP and TCP headers?
__________________________________________________
__________________________________________________
__________________________________________________
Notes:

V3.1.0.1
Instructor Guide

Purpose Discuss the third group of checkpoint questions.
by periods.
This is the loopback address used by a system to send
messages to itself.
255 (all bits on)
ability only.
13. Why are port numbers included in UDP and TCP headers?
Port numbers distinguish between multiple processes
running on the same host. Server side ports (and the
transport layer protocol in use) also identify the network
service associated with the connection.
Additional Information This is the third of four groups of checkpoint questions for this
unit.
Transition Statement Lets move on to the final checkpoint questions for this unit.

Instructor Guide
Checkpoint (4 of 4)
14. If UDP discards a datagram, is there an ICMP message
generated? If not, why not?
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
15. (True or False) IP guarantees delivery of datagrams in the same
sequence as they are sent.
Notes:

V3.1.0.1
Instructor Guide

Purpose Complete the discussion of the checkpoint questions for this unit.
An ICMP message is not generated because the datagram
was delivered by IP to UDP. Once it reaches its destination,
IP has no knowledge of what is done with the datagram.
The statement is false. IP is a connectionless protocol.
Additional Information This is the last of four groups of checkpoint questions for this
unit.
Transition Statement Lets move on to the exercise for this unit.

Instructor Guide
Exercise: TCP/IP Concepts - IP Addressing
Exercise 1
Figure 1-44. Exercise: TCP/IP Concepts - IP Addressing AU079.1
Notes:

V3.1.0.1
Instructor Guide

Purpose Prepare the students for the lab.
Details Use this visual as a transition to the lab. Mention that this is a pencil and paper
exercise.
Additional Information None.
Transition Statement Lets review some of the key points from this unit.

Instructor Guide
Unit Summary
TCP/IP is a layered architecture consisting of physical, network,
Internet, transport, and application layers
The main protocols used in the TCP/IP protocol suite are IP,
ICMP, ARP and UDP, along with many network interfaces and
application protocols
The Internet Protocol has a 32-bit, two-part logical address which
represents a network and a host address
Important network-related terms discussed in this unit include
socket, gateway, router, and switch
When an IP address and a mask are provided, the network and
host addresses can be determined
IP multicasting allows efficient communications to multiple
receivers
Figure 1-45. Unit Summary AU079.1
Notes:

V3.1.0.1
Instructor Guide

Purpose Review some of the key points covered in the unit.
Details Feel free to mention points other than those on the visual if this seems
appropriate to you.
Additional Information None.
Transition Statement Lets continue with the next unit.

Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 2. Hardware Management Console

This unit introduces the Hardware Management Console (HMC),
which is a crucial network component in an IBM System p5TM
environment. The HMC applications provide a platform for
configuration and management of POWER5 processor-based servers.
The unit includes a discussion of the configuration of the HMC within
an internal or external TCP/IP environment.

Describe basic HMC functions
Configure an HMC
Configure the HMC network parameters
Configure remote access options
Enable/disable remote virtual console support

Accountability:
Checkpoint
Machine exercises
References
http://publib.boulder.ibm.com/infocenter/eserver/
v1r2s/en_US/index.htm
Sserver Information Center
Copyright IBM Corp. 1997, 2006 Unit 2. Hardware Management Console 2-1
Instructor Guide
Unit Objectives
Describe basic HMC functions
Configure an HMC
Configure the HMC network parameters
Configure remote access options
Enable/disable remote virtual console support
Notes:
Introduction
By the end of this unit, you should be able to describe the HMCs functions and features
and be able to configure associated network parameters.

V3.1.0.1
Instructor Guide

Purpose Review the objectives for this unit.
Details Mention that the HMC is a crucial network component in an IBM System p5
environment.
The material in this unit was taken directly from Unit 3 of AU73 (Logical Partitioning (LPAR)
on POWER5 pSeries Systems). Some of the material in the source unit was omitted
because it seemed unrelated to the current course (AU07).
Transition Statement We start with an overview of the HMC.
Instructor Guide
HMC Introduction
PC-based system required for the configuration and management of
partitions
Main HMC applications are:
Server and Partition
Licensed Internal Code Maintenance
HMC Management
Service Applications
Information Center and Setup
System Manager Security
Figure 2-2. HMC Introduction AU079.1
Notes:
Introduction
The Hardware Management Console (HMC) is a dedicated system that provides a
graphical and command-line user interface for the configuration and management of
logical partitions on LPAR-capable Sserver POWER5-based servers. The HMC is
required for many functions, including virtual Ethernet connections.
All releases of the HMC Version 4.x machine code manage an Sserver i5 server, but a
p5 server requires HMC Version 4.2 (or greater) software.
The HMC supports up to 32 managed systems and 160 partitions as of Version 4
Release 2.1 of the HMC software. The HMC 4.2.1 package is referenced by APAR
MB00654.

V3.1.0.1
Instructor Guide

Purpose Introduce the HMC.
Details This page introduces the HMC. The most important points on this page are that
the HMC is needed for any Sserver p5 and Sserver i5 servers that run LPARs, and that
it is an independent system. POWER4-based pSeries systems also used the HMC for
LPAR management.
Transition Statement The next page explains the hardware platform.
Instructor Guide
HMC Hardware and Software

PC-based console
Custom Linux and Java-based HMC software
Provides GUI application and restricted shell for command-line
Remotely accessible
Desktop Rack-mount
7315-C03 7310-CR2
Figure 2-3. HMC Hardware and Software AU079.1
Notes:
Intel architecture platform

As a flexible solution, the HMC is packaged in a customized Intel-based PC, running
Linux. The only function the HMC provides is the control of managed systems. A
managed system is what we call the Sserver system running one or more LPARs
that the HMC manages.
You cannot load any other applications onto the HMC.
System continues to work if HMC fails

The managed system continues to operate in the absence of an HMC by using partition
configuration information stored in NVRAM. Individual partitions can be rebooted using
a shut down command in the partitions operating system. The managed system can be
powered off and on, and restarts predefined partitions automatically if the HMC is not

V3.1.0.1
Instructor Guide
Uempty available. However, performing configuration changes to the partitions requires the
HMC.
HMC provides partition information backup facility to DVD-RAM

When you back up console data, HMC configuration data is saved to the DVD-RAM.
The HMC saves the data stored on its disk that is critical to support HMC operations,
and makes recovery a much easier scenario. You can restore a backup copy of hard
disk information to your HMC following the repair or replacement of the disk.
HMC software
New HMCs are shipped with preloaded HMC software. You should also receive a
recovery CD-ROM from which to reload the HMC software if necessary.
Instructor Guide
Instructor Notes:
Purpose Describe the HMC.
Details Describe the two hardware options for the HMC.
Define the term managed system on this page.
Although the HMC code is based on Linux, you cant just use any Intel PC because the
version of Linux only includes a specific set of device drivers.
Additional Information Try to keep the discussion away from the fact that customers
do not have full access to Linux on the HMC. Should a student comment on this, discuss
the stability of Linux on the HMC, and that to assure this stability IBM decided to make it a
secured system.
Transition Statement Lets look at how the HMC connects to its managed system(s).

V3.1.0.1
Instructor Guide
Uempty
Configuring a New HMC
Checklist to set up a new HMC
Connect network cables to HMC and FSP
Power on HMC
Login locally as hscroot
Check HMC software version
Use Guided Setup Wizard to configure HMC
Date/time, hscroot and root passwords, add users, configure
networking, configure service provider, connection monitoring
Reboot HMC
Upgrade HMC software if necessary
Apply power to managed systems
Set access passwords
Apply any activation codes
Figure 2-4. Configuring a New HMC AU079.1
Notes:
Hardware connections
Connect the HMC to the network and power it on. If you plan to use the HMCs modem
to dial up IBM service to transmit service errors, then connect a phone line to the
modem.
Access the HMC and check the configuration

Power on the HMC by pressing the power button. You see the Linux initialization
messages and then are prompted to log in. The default login account and password for
the HMC is hscroot and abc123. Since this is the same on all HMCs, you should
change the password immediately. New passwords must be at least 7 characters.
If this is a new HMC, you are automatically prompted to run the Guided Setup Wizard
which helps you set up a few critical options. You can rerun this wizard at any time, or
access the individual configuration options separately.
Instructor Guide
Logout, shutdown, or restart HMC

If you change the network configuration, you need to restart the HMC. To log out, shut
down, or restart the HMC, use the Console -> Exit menu option, then pick an option
(log out, restart, and so forth) on the pull-down list.

V3.1.0.1
Instructor Guide

Purpose Describe how to configure a new HMC.
Details This page gives the big picture of the process to configure a new HMC.
Transition Statement Lets look in more detail at the Guided Setup Wizard.
Instructor Guide
Guided Setup Wizard

Guided Setup Wizard appears when you start a new HMC for the
first time and log in
You can run it at anytime later
Reboot HMC when complete
Figure 2-5. Guided Setup Wizard AU079.1
Notes:
Introduction
This application is an easy way to configure your HMC for the first time. All of the
options available in the wizard can be accessed separately in the HMC applications.
There are more configuration options available which do not appear in the Guided
Setup Wizard.

V3.1.0.1
Instructor Guide

Purpose Show the options available in the Guided Setup Wizard.
Details Quickly show the options available in the Guided Setup Wizard.
Transition Statement Now, lets look at the HMC interface.
Instructor Guide
HMC Application Window
Logout and
Shutdown
Options
Navigation
pane
Content pane
Figure 2-6. HMC Application Window AU079.1
Notes:
Introduction
The visual above shows the HMC GUI interface with all of the applications visible.
HMC navigation window pane

The Navigation pane on the left displays a hierarchy of icons that represent the
collections of computers and their applications. Click the + and - icons to expand or
contract the application options.
The name that is highlighted is the HMCs name. If you use Console -> Add -> Hosts
from the menu option, you can add additional HMCs to the list and access their
applications by simply clicking on their name and logging in.
In fact, since the HMC application uses the Web-based System Manager (WebSM), you
may add any WebSM-manageable system in this way.

V3.1.0.1
Instructor Guide
Uempty HMC content window pane

The content window changes based on which application is activated. For example, if
you click the Server and Partition application, there is another application, Server
Management, listed. Clicking Server Management gives you access to a list of your
managed systems and their partitions.
Menu bar
The menu at the top of the window lists options such as Console, Host, Selected, View,
Window, and Help, as shown in the visual. These menu options change based on the
application that is activated. The Selected menu appears in all applications and lists
tasks available for whichever object is selected. For example, if you selected a partition,
you would see options on the Selected menu that can be performed on partitions. Using
the Selected menu is the same as using the right mouse button to bring up a pop up
menu.
Menu icons
Some functions are replicated as icons just under the menu bar. You can hide or reveal
these icons from the Window menu item.
Status bar
There is a status bar with five segments across the bottom of the HMC interface. The
first segment contains an open or closed lock which indicates whether the systems
management security has been configured on the HMC. The second segment contains
the state of the HMC, the third and fourth segments contains information on what is
being viewed, and the last segment shows which account you used to login to the HMC.
This status bar does not appear in the visual above.
Logout and shutdown options

On the physical HMC, use the Console menu to log out of the HMC interface and to
shut down or restart the HMC.
You may also shut down the HMC remotely through an SSH connection. Use the
hmcshutdown HMC command. The -r option will do a restart.
Syntax:
hmcshutdown -t {number-of-minutes | now } [ -r ] [ --help ]
Example to restart the HMC immediately:
hmcshutdown -t 0 -r
Instructor Guide
Instructor Notes:
Purpose Describe the major parts of the HMC interface.
Details Describe the following:
- Segmented window panes
- Menu options change depending on which application is activated
Right mouse button is same as Selected menu option
Show where to logout or reboot console
- Menu icons
- Expanding/contracting application listings
Describe the purpose of the Console -> Add menu option that is mentioned in the student
notes. This is how to add access to another HMC from an HMC and is not how to add a
managed system. After you add the second HMC to the first HMC, you simply click the
HMC, log in, and then have access to all the second HMCs applications. We cover this
again in a few pages.
This unit does not address the Licensed Internal Code nor the Service Applications areas
in detail. Describe them briefly here.
Transition Statement The first application we look at is the Information Center and
Setup Wizard. To get there just click this item in the navigation pane. The next page shows
what appears in the content pane.

V3.1.0.1
Instructor Guide
Uempty
Information Center and Setup Wizard
Figure 2-7. Information Center and Setup Wizard AU079.1
Notes:
Introduction
When you click the Information Center and Setup Wizard application, this is what
appears in the content pane on the HMC. There are two tasks available.
Information Center
You can access the Sserver Information Center through the HMC interface by clicking
the first task. This provides closed access to the Web-based Information Center. Closed
access means you are not free to surf the Web other than within the Information Center
pages. Later, when it is necessary to update the HMC software, the Information Center
is updated as well.
The Information Center is integrated into the HMC help screens, available from the IBM
Web site, and also shipped on CDs for installation on PCs or AIX systems.
Instructor Guide
Instructor Notes:
Purpose Describe HMC functions.
Details Describe the two tasks available on this screen. The students get a chance to try
these in the hands-on exercise.
Transition Statement Lets look at server management.

V3.1.0.1
Instructor Guide
Uempty
HMC Server Management
10.19.99.109
Managed Systems
SYS99
Figure 2-8. HMC Server Management AU079.1
Notes:
Introduction
From the Server Management application, you can create, maintain, and manage
partitions. The Server Management application is available under the Server and
Partition application.
Server Management content window

In this example, the HMC is managing two managed systems named 10.19.99.109
and SYS99. The window is arranged hierarchically. Each managed system has its
own list of partitions and system profiles.
Adding addition HMCs

Another option on this screen is to add another HMC to this HMCs application. It would
appear on the left in the Navigation pane. Use the Console -> Add host menu option.
Instructor Guide
Once another HMC is added, simply click its name and log in to access all of its
applications.
State column
There is a state column for many of the objects shown. In the visual above, the
managed systems are No Connection and Operating and the partitions are either Not
Available, Running, or Not Activated. These states and their meanings will be
covered later.
Operator Panel Value

For non-LPAR systems where there is one operating system image per hardware
system, status codes can show in the LCD panel on the front of the system. In a
partitioned environment, where many operating environments can run on the same
hardware system, the way to access these codes is from the HMC. When individual
partitions change state, codes appear in this column next to the partition names.

V3.1.0.1
Instructor Guide

Purpose Introduce the Server Management application.
Details Describe how to access the Server Management application.
Show how multiple managed systems might appear and explain briefly how they got there.
It is important to cover the difference in the types of systems that show up in the navigation
window list versus the Server Management content window.
Explain how another HMC can be added and accessed from here.
Mention the status and operator panel value column.
Transition Statement Now, lets look at the HMC configuration.
Instructor Guide
HMC Configuration
Figure 2-9. HMC Configuration AU079.1
Notes:
HMC Configuration application

This application has many of the configuration tasks for the HMC from setting the date
to doing scheduled backups of partition configuration data. Some of these applications
are fairly straightforward:
Customize Console Date and Time: You may need to reset the time if your console is
shipped from another time zone or if the battery-operated clock has its battery replaced.
View Console Events: This is a log of recent HMC activity. System power-on, partition
activation, partition shutdown, and results of a scheduled operation (such as a backup)
are all console events that are logged.
Test Network Connectivity: This is an interface to the UNIX ping command. You can
ping another host or IP address to test network connectivity.
Change Current Locale: When you power on the HMC you can choose the language
for your HMC to use. You can also use this application to change the language. You can

V3.1.0.1
Instructor Guide
Uempty choose languages such as English, German, Spanish, French, Hungarian, Japanese,
Italian, or Russian.
Configuring a new HMC

If youre following along with the example in this unit, now that you have changed the
passwords on your default user accounts, it is time to set the current locale and the
HMCs date and time. Remember the Guided Setup Wizard includes these as part of its
screens. Or, you can configure these options from the HMC Configuration application,
shown in the visual above.
Instructor Guide
Instructor Notes:
Purpose Introduce the HMC Maintenance applications group.
Details Introduce each of the options listed in this application. The student guide briefly
describes some of the options. We cover some of the others later.
Additional Information The screen shot on this visual was too large to fit on the page.
Nothing important has been left out of the screenshots except the OK and Cancel buttons
at the bottom.
Transition Statement Next, we see some of these applications in more detail; starting
with the Customize Network Settings option.

V3.1.0.1
Instructor Guide
Uempty
HMC Network Configuration
Information needed for configuring HMC network options
Private or open network for HMC to FSP

HMC hostname
IP addresses LAN to partitions
Open and other hosts
Domain name Network
DNS server IP address
DHCP setting
Default gateway IP address
Private
Additional routes HMC Network
Firewall configuration LAN to FSP
Figure 2-10. HMC Network Configuration AU079.1
Notes:
Introduction
In the next section of this unit, you see several screens where you must supply
information about your HMC and its network. This visual lists the options that you must
decide to enable or not, and the information that you need to enter. Plan ahead and
document all of this information before you attempt to configure the HMC. You need
some knowledge of basic TCP/IP configuration information or help in this area.
Private versus open network for HMC to FSP

One of the decisions you have is whether to connect the HMC to the Flexible Service
Processor (FSP) over a private network or over an open network. A private network is
one that is restricted to HMC and FSP connections. An open network has other network
hosts connected to it. The visual above shows a graphic with a private network
connecting the HMC to the FSP and an open network connecting the HMC to the
partitions. This is a typical configuration and the easiest to configure.
Instructor Guide
Instructor Notes:
Purpose Describe information needed before attempting to configure the HMCs
network settings.
Details Define an open network and a private network. Explain you can have the FSP
connected to the open network and not have a private network.
The next set of visuals show the screenshots where you enter in the network information
that is listed on this visual.
The basic network configuration can be set in the Guided Setup Wizard, so many of the
screens shown in the following visuals are similar to those used in the wizard. The
difference is that there are more options to configure when you go through the HMC
Configuration application.
Transition Statement Next, we see the first screen that pops up when you choose
Customize Network Settings from the HMC Configuration application.

V3.1.0.1
Instructor Guide
Uempty
Network Settings - Identification
Figure 2-11. Network Settings - Identification AU079.1
Notes:
Introduction
This visual shows the first screen you see after choosing Customize Network Settings
from the HMC Configuration application. Notice there are four tabs along the top.
Changing the network options in these screens requires a restart of the HMC for the
changed values to be used.
Identification tab
The console name is the HMCs hostname. Enter the HMCs hostname.
The domain name is the Domain Naming System (DNS) domain name in use for this
HMC. It may be something like companyname.com or engineering.acme.com.
Console description is a text area where you can put a description that uniquely
describes this HMC. Some HMCs are described by the managed systems they manage
or by their location.
Instructor Guide
Instructor Notes:
Purpose Describe the first network configuration screen.
Details Describe each input box and mention that you click the tabs at the top to change
to those screens. Click OK when youre done.
On this screen, enter the HMCs hostname and network domain name which will be used
by other hosts on the network to access this HMC.
Transition Statement Next is the LAN Adapters tab.

V3.1.0.1
Instructor Guide
Uempty
Network Settings LAN Adapters
Select interface and

click Details button
Figure 2-12. Network Settings - LAN Adapters AU079.1
Notes:
Choose a network interface to configure

Choose which interface you want to configure and click the Details button. The screen
that appears is shown on the next visual.
Instructor Guide
Instructor Notes:
Purpose Describe how to configure a network interface.
Details This visual shows how to choose which interface to configure.
Transition Statement The next page shows the Details screen.

V3.1.0.1
Instructor Guide
Uempty
Network Settings LAN Adapter Details
Figure 2-13. Network Settings - LAN Adapter Details AU079.1
Notes:
Introduction
The visual above appears after you choose an interface and click the Details button as
shown on the previous visual.
LAN Information
The first option allows you to choose a private or an open network for the HMC.
A private network means that the HMC connects to the managed systems over a
separate network which is not shared by other network traffic. The term open refers to
any general network that contains elements other than HMCs and service processors,
and that is not isolated for only HMC network traffic to its managed system.
It is recommended that you implement service network communications through a
private network, because of the additional security and ease of setup that it provides.
However, in some environments, this is not feasible because of physical wiring, floor
Instructor Guide
planning, or control center considerations. The same functionality is available on both

types of networks, although the initial setup and configuration on an open network
requires more manual steps.
Partition communication checkbox

The partition communication checkbox, if checked, configures this interface for
communications between the HMC and partitions. Check this box for the interface that
connects to the partitions.
Media Speed
The default of automatic detection for the Ethernet adapter media speed is
recommended for the initial setup. However, in some situations, you may want to
reduce the speed of the adapter to decrease the amount of processing power it uses for
large amounts of data, if, for instance, an Ethernet hub or switch is used and needs a
lower media speed.
Dynamic Host Configuration Protocol (DHCP) server

If you check the private network checkbox, you have the option of configuring this HMC
as a DHCP server. DHCP servers provide an automated method for dynamic client
configuration. The clients in this case are the service processors on the managed
systems that the HMC is managing. Clients that are DHCP-enabled automatically
obtain their own IP address and configuration parameters from the DHCP server. In a
private network, configure your first or only HMC as a DHCP server.
If you check the Open network checkbox, the Enable DHCP server option is grayed out
and not available.
A DHCP server has a range of IP addresses that it assigns to systems. If you configure
the HMC as a DHCP server, select one of the following standard nonroutable IP
address ranges for your private network. These ranges are shown in the visual.
It is recommended that you use the non-routable 192.168.0.2 - 192.168.255.254
address range when setting up the connection between the HMC and the managed
system.
If DHCP is not set up or the managed system cannot access the DHCP server, it uses
the default IP address of 192.168.2.147 for the first Ethernet interface and
192.168.3.147 for the second Ethernet interface.
The DHCP server in the HMC uses automatic allocation, which means that each unique
service processor Ethernet interface is reassigned exactly the same IP address each
time it is started. Each Ethernet interface has a unique identifier based upon a built-in
Media Access Control (MAC) address, which allows the DHCP server to reassign the
same IP parameters.

V3.1.0.1
Instructor Guide
Uempty DHCP Client/IP Address

In the last part of the LAN Adapter tab, you can choose whether this HMC is a DHCP
client or whether a specific IP address is assigned. In the example shown in the visual
above, this HMC is using the DHCP server (on itself), and the IP address is assigned
automatically. Notice that the IP address section is grayed out on the bottom.
Instructor Guide
Instructor Notes:
Purpose Describe the LAN adapter configuration settings.
Details Describe the difference between an open network and a private network.
Emphasize that the private network is only for HMC to FSP communications. The HMC still
needs to connect to a public network so that it can communicate with the daemons running
in the partitions for DLPAR operations and the service tools communications.
Describe when to setup the HMC as a DHCP server versus a client.
Describe how to use static addresses rather than setting up as a DHCP client. The
example on the visual shows a static address assigned. Be sure the students understand
the difference between setting up the HMC as a DHCP client and a DHCP server. The
example shows that the HMC is being configured as a DHCP server but that it itself is not a
DHCP client because it is being assigned the static address of 10.0.0.1.
Transition Statement Another option to set up for the LAN adapter is whether you want
to open the firewall for remote access. This is covered next.

V3.1.0.1
Instructor Guide
Uempty
Network Settings LAN Firewall
Add WebSM and

SSH to permit remote
access to HMC
Figure 2-14. Network Settings - LAN Firewall AU079.1
Notes:
Firewall configuration
In an open network, there is usually a firewall that controls outside access to your
company network. The HMC also has a firewall on each of its Ethernet adapters. If you
want to control the HMC remotely or give remote access to others when that HMC is on
a private network, modify the firewall settings of the Ethernet adapter on the HMC that
is connected to your open network.
To allow access, first select the IP addresses you want to allow through your firewall.
You can allow any IP address using a particular application, or specific IP addresses,
through the firewall.
Allow specific applications from any IP address

To allow any IP address using a particular application through the firewall:
a. In the top box, highlight the application.
Instructor Guide
b. Click Allow Incoming. The name of the application appears in the bottom box to
signify that it has been configured.
Allow specific applications from a specific IP address

To allow applications from specific IP addresses through the firewall:
a. In the top box, highlight an application
b. Click Allow Incoming by IP Address
c. On the Hosts Allowed panel, enter the clients IP address and network mask
d. Click Add and Ok
A few recommended settings

By default, WebSM and SSH traffic are not allowed through the firewall. To allow the
use of the remote WebSM client, add WebSM. To allow access to HMC using an SSH
terminal emulator, add Secure Shell.
Web Access (port 80) is already added in the default list which allows access from a
Web browser.

V3.1.0.1
Instructor Guide

Purpose Describe how to configure the HMC firewall.
Details The firewall application allows you to control remote access to the HMC. The
firewall prevents outside unauthorized access to the private network between the HMC and
its managed systems service processor. If you want to use the HMC remotely, you must
open up the firewall to allow some applications like WebSM and SSH access to the HMC.
Describe the difference between the Allow Incoming and the Allow Incoming by IP
Address buttons.
Remind the students that this pop-up window appeared when the Details button was
clicked on the LAN Adapters tab. Now when you click the OK button on the window shown
in this visual, the Details window closes and you are returned to the Customize Network
Settings window, which is shown in the next visual.
Transition Statement The next page shows how to configure name services on the
HMC.
Instructor Guide
Network Settings Name Services
Figure 2-15. Network Settings - Name Services AU079.1
Notes:
Name Service configuration

This tab configures the Domain Name Services (DNS) settings for the HMC. Name
services provide IP to hostname (and vice versa) mappings.
If the network where the HMC resides uses DNS services, check the DNS enabled box.
This configures the HMC to use DNS as a client. Enter the DNS server search order.
List DNS servers in the order that they are checked. As specified by the DNS protocol,
the second and third servers are only used if the ones above it on the list are not
available.
In the bottom portion of the screen, enter the domain suffix search order for your
network. For example, the HMC hostname might be george.rchland.ibm.com so with
the search orders specified in the visual above, every hostname will first be looked up in
the rchland.ibm.com domain. If no match is found, then the ibm.com domain is
searched.

V3.1.0.1
Instructor Guide

Purpose Describe how to configure DNS services.
Details This tab configures the HMC to be a DNS client.
If the students are familiar with setting up the UNIX /etc/resolv.conf file, then the items on
this visual look familiar.
Additional Information One change from the version 4 of the HMC software is that you
no longer have the ability to use an /etc/hosts file for static name and IP address mapping
on the HMC. You must use DNS services.
Transition Statement An HMC might also need to have network routes configured.
Instructor Guide
Network Settings Routing
Figure 2-16. Network Settings - Routing AU079.1
Notes:
Network routes
You may have a complex network structure where additional network routes may need
to be configured. There are a few reasons you may need to configure routes and these
reasons are not unique to an LPAR environment. An HMC needs to be able to reach its
partitions and those partitions may be on a remote network. A default gateway may be
all that you need to configure as the default gateway might be able to route all IP
packets to the correct network. Or, you might know of a more direct route to get to
partitions than the default gateway. You can add this route on this tab. Another reason is
that you may not have a complex network at all and are not using dynamic routing, in
which case, a few static routes may be all that you need.
Adding a route
To add a route, click the New button in the middle of the screen. The pop-up window
that appears is shown in the visual. Enter the destination network address, the gateway

V3.1.0.1
Instructor Guide
Uempty network address, the subnet mask in use, and choose which adapter to use. Click Ok to
enter the route.
Enable routed
You may wish to run the dynamic routed daemon. This daemon communicates with
other routed daemons to learn new, closer routes to remote networks.
Default gateway information

For many installations, the HMC simply needs to know the IP address of a gateway
system. The HMC then relies on this gateway for all routing services. Make sure that
the gateway device you choose is on the same subnet as the gateway system. For the
recommended setup, this would be eth1, the interface on the open network.
Instructor Guide
Instructor Notes:
Purpose Describe how to configure routing on the HMC.
Details Describe when to create routes and how to create them.
That is the end of the network configuration section. The HMC should be restarted and
then the administrator should use the ping command (HMC command line or from a
remote system) and the Test Network Connectivity HMC task to test the network
configuration.
For the last few screens, the configuration data that must be entered is standard for TCP/IP
networks. The person installing an HMC should ensure that the TCP/IP configuration
information entered fits into the overall network environment of the organization.
Transition Statement Thats it for the HMCs network configuration. Now that the HMC
is on the network, you need to connect it to its managed systems.

V3.1.0.1
Instructor Guide
Uempty
Connecting HMC to Managed System
Connect Ethernet cable
between HMC and FSP
Connect Ethernet cable from LAN to Partitions
HMC to open network
After configuring HMC, apply
power to managed system
Network
HMC finds it
Or, use Add Managed
System
Private
HMC Network
Default FSP IP addresses: LAN to service

192.168.2.147 and 192.168.3.147 processors
(if not using DHCP)
Figure 2-17. Connecting HMC to Managed System AU079.1
Notes:
Introduction
Now that youve powered on your new HMC and configured the basic network options,
lets see how to get the HMC communicating with the managed system. Both the HMC
and the managed system must be connected to the same network. The visual above
shows the HMC and the FSP connected to a private network.
In the visual, FSP refers to the Flexible Service Processor on the Sserver managed
system.
Connecting the Ethernet cables

Connect the HMC1 port on the managed system directly to the Ethernet port on the
HMC. For desktop HMC models, connect the cable to the integrated Ethernet port. For
rack-mounted HMC models, connect the cable to the bottom port (labeled port 1) of the
Instructor Guide
two vertically stacked Ethernet ports. This direct connection can be a straight or
cross-over Ethernet cable.
Connecting the managed system

If the managed system is on the same private network, the HMC automatically finds the
managed system as soon as you apply power to the managed system. Do not connect
the managed system to power until the HMC is fully configured and the Ethernet cable
between the HMC and the FSP is connected.
At first the System Management application is empty. After a short time, you see a
system appear with the state of No Connection. After a short time, this will disappear
and another entry appears with a state of Pending Authorization. At this point, select
the managed system name, and a pop-up window appears with three tabs. Enter a
password on each of these tabs. These passwords are used with the general and
admin accounts in the Advanced Systems Management Interface (ASMI), and the third
is for HMC-to-managed system communication.
It is recommended for ease of configuration to use a private network between the HMC
and the FSP. If you have multiple systems on an open network, you may need to use
the Add Managed System option on the menu so that you can connect to a specific
FSP.
IP Addresses
If the HMC is running DHCP, the IP address of the HMC is 192.168.0.1 and the first
FSP is 192.168.255.254.
If the FSP powers on and cannot find a DHCP server, it uses 192.168.2.147 for its first
Ethernet port and 192.168.3.147 for the second Ethernet port by default. You may
configure the FSP to use any IP address by using the ASMI application.
If you have multiple HMCs on the same network, only the first should be configured as a
DHCP server and the IP addresses shown above are for the first HMC and FSP.
Add the managed system

If necessary, you can use the Add Managed System menu option to add a new
managed system. This menu option is available from the Server Management
application in the menu bar or by right-clicking the content window. The next few visuals
walk through this procedure.
Secure connection using SSL

The HMC to FSP private network uses SSL for a secure connection. For SSL, we need
userids and passwords on the FSP. There are default userids admin and general
already set up, and an additional HMC userid when HMC is connected.

V3.1.0.1
Instructor Guide
Uempty The service processor issues the SSL certificate, and this SSL connection is
established when the managed Server is added to the HMC. When you connect the
HMC to the managed system and apply power, and the state of the managed system is
Pending Authorization, click the managed system name and you are prompted to set
up the three passwords. Be sure to document these in a safe place.
Instructor Guide
Instructor Notes:
Purpose Describe how to add a managed system to the HMC.
Details Describe a simple private network setup, where the HMC and managed system
are both on the same subnet.
Describe how the HMC automatically discovers the FSP, and the DHCP server on the HMC
assigns it an IP address. The state of the managed system is at first No Connection, then
changes to Pending Authorization. If it stays on No Connection and never changes to
Pending Authorization, then there is a problem. Try the Add Managed System option.
Once the state is Pending Authorization, left-click the managed system name and you are
prompted to enter three passwords to set up the SSL connection between the HMC and
the managed system: HMC Access, and the admin and general accounts for accessing
ASMI.
The next visual shows the menu option to begin the process of adding the managed
system manually to the HMCs Server Management application.
Transition Statement Now, lets see how to add the managed system in the HMC
interface.

V3.1.0.1
Instructor Guide
Uempty
HMC and Managed System LAN Topology
LAN to Partitions
Additional
LANs
Network
Ethernet
Service
Internal PCI Network
modem
IBM Private
HMC Network
LAN to service
processors
Figure 2-18. HMC and Managed System LAN Topology AU079.1
Notes:
Introduction
The visual above illustrates the big picture of how the HMC is connected to not only the
managed systems, but also to other networks.
The visual shows multiple HMCs connected to their managed systems over individual
private networks. These HMCs also connect to public networks to provide
communications to the partitions and to other workstations that you might use to access
the HMC remotely.
Also depicted is a modem connected to the HMC which will dial up IBM service when
particular types of errors are detected.
HMC security features

With all of these network connections, you might be wondering about how to keep the
HMC secure. The following are some of the security features on the HMC.
Instructor Guide
- Each set of HMC user accounts is HMC-specific.

- Login access to the HMC command line is available only through the use of the
secure shell (SSH) program and limits access to only authorized HMC command
line functions.
- Firewall settings on the HMC can restrict access to particular applications or IP
addresses.
- Granular user access controls allow you to define task and resource roles for user
accounts. For example, you can create a user who has access to operation tasks
only for a particular partition.
- You can define which HMC network services should be accessible on which
physical network interfaces. For example, you could limit remote WebSM or SSH
access to a single interface (or to none).

V3.1.0.1
Instructor Guide

Purpose Describe how the HMC may connect to managed systems and other systems
on the network.
Details The HMC not only must connect to the FSP of the managed systems, but it must
also have a network connection to the partitions. So if the service network is private, then
the HMC must also connect to an open network.
In addition, you may want to access the HMC remotely which means that it must connect to
an open network. (This is discussed further on the next page.)
Also shown on the visual is the modem connection (represented as a lightning bolt) to IBM
service.
Point the students to the HMC security features listed in the student notes.
Transition Statement The next page describes the HMC remote management options.
Instructor Guide
Remote Access to the HMC

3
3
SSH Access
to HMC
HMC commands
Network
2
2 Windows,
Linux, or AIX
client via
WebSM 1 Alternate
1 HMC
Figure 2-19. Remote Access to the HMC AU079.1
Notes:
Introduction
There are three options for accessing HMC functions remotely.
Another HMC (1)

Each HMC has the ability to connect to another HMC and access its functions. You
must log in to the second HMC.
To connect to another HMC from an HMC, use the Console -> Add -> Hosts menu
option, then enter the hostname or IP address of the remote HMC. The second HMC
appears in the navigation pane of the HMC interface. Click its name to log in. From
there you have all the capabilities that your login account allows on that HMC.

V3.1.0.1
Instructor Guide
Uempty WebSM client (2)

You may install WebSM client software on a Windows PC, an AIX workstation, or on a
Linux workstation. From WebSM you may connect to any HMC and access its
functions. You must log in to the HMC (both to install the remote client and to access the
HMC each time).
The WebSM client can be loaded from AIX standard distribution software or directly
from the HMC for Windows PCs and Linux (on Intel) workstations. To install the client
on Windows PCs and Linux workstations from the HMC, open a Web browser to the
following Web address where hmc-hostname is the actual hostname of the HMC:
http://hmc-hostname/remote_client.html
The page http://hmc-hostname/pc_client.html is the same as remote_client.html.
Supported platforms:
- Windows PCs: Windows 2000 and Windows XP
- Linux: Supported systems are Red Hat Versions 7 through 9 and SuSE
- All AIX 5L versions
SSH connection (3)

You can use a secure shell (SSH) connection directly to the HMC. When you log in, you
are given a restricted shell. Most partition management commands can be executed
using this restricted shell command line. There are also a limited number of Linux
commands available. Use the shell command echo $PATH after you login to see which
directories are available. A listing of these directories will show the commands
available. To see usage information, run the commands with the --help option.
The SSH access feature is disabled by default. You can enable this from the HMC.
SSH installation options

On Windows PCs, you must have an SSH application loaded. Heres an example of a
Web page that has a free SSH application:
http://www.chiark.greenend.org.uk/~sgtatham/putty/
On AIX, you need both OpenSSL and OpenSSH. Install OpenSSL first from the AIX
Toolbox for Linux Applications for POWER Systems CD-ROM. Then install the
OpenSSH package which is on the AIX 5L Expansion Pack CD-ROM. Both of these
CD-ROMs are shipped with the AIX 5L product media. For more information about how
to install and use the OpenSSH package, please refer to the Managing AIX Server
Farms Redbook available from http://www.redbooks.ibm.com.
On Linux, SSH is generally installed by default in the Linux distribution.
Instructor Guide
Instructor Notes:
Purpose Describe the HMC remote access options.
Details Describe each of the three options for accessing an HMC remotely.
The network cloud in the middle of the visual is an oversimplification of whatever the
network configuration might be.
Transition Statement The next page describes how to enable remote SSH and remote
partition virtual console access.

V3.1.0.1
Instructor Guide
Uempty
Enable or Disable Remote Options
SSH to the HMC to perform management tasks remotely
HMC Management --> HMC Configuration -> Enable or Disable
Remote Command Execution
Remote access to LPAR virtual terminals (consoles)

HMC Management --> HMC Configuration -> Enable or Disable
Remote Virtual Terminal
Figure 2-20. Enable or Disable Remote Options AU079.1
Notes:
Enabling remote HMC commands (SSH)

Recall that the remote HMC commands allow you to perform many partition
management operations from a remote command line. From this secure shell, you can
execute remote HMC commands to do things like activate a partition or query its status.
By default, the HMC does not allow SSH sessions, so you must enable this function
from the HMC Management -> HMC Configuration application.
Enabling Remote Virtual Terminals

Another remote option available from the HMC Configuration screen is a tool that allows
you to enable or disable the ability to use remote virtual terminal windows to the
partitions (that is, remote console windows). Simply click the Enable or Disable Remote
Virtual Terminal option and check the appropriate checkbox.
Instructor Guide
Instructor Notes:
Purpose Describe how to enable or disable SSH access to the HMC and the ability to
bring up virtual console windows remotely.
Details The visual shows how to enable the SSH remote command function of the HMC
and enable remote virtual terminals. By default, both of these are disabled.
Remind the students that they need to open the HMC firewall ports for SSH and WebSM if
they want to use those utilities.
Transition Statement Thats how you enable SSH access for command line access to
the HMC. The next visual shows how to load the WebSM client if you wish to use the
graphical interface from a remote workstation.

V3.1.0.1
Instructor Guide
Uempty
Load WebSM Client
For Linux and MS Windows clients, access WebSM Client

application from HMC
http://hmchost.domain/remote_client.html
Login as hscroot
Two choices
Java Web Start
InstallShield
For AIX clients, WebSM is standard
Figure 2-21. Load WebSM Client AU079.1
Notes:
Introduction
To use the HMC graphical interface remotely, you must load the WebSM client on the
remote Windows, Linux, or AIX workstation. This gives you access to most of the
functions on the actual HMC. One application you cannot access remotely is System
Manager Security.
WebSM client installation options

There are two installation options when installing the WebSM client from the HMC.
InstallShield: This remote client is installed via an InstallShield wizard and it must be
re-installed to obtain updates. This client is useful when running the Web-based System
Manager over a broadband connection (cable modem or DSL), because updates to the
console are not automatically downloaded.
Instructor Guide
Java Web Start: When you install Java Web Start, it checks for updates for the WebSM
remote client whenever it is invoked and download updates automatically. If you choose
to use Java Web Start, it must be installed on the remote client system before installing
the WebSM Remote Client.
For example, if you choose the Java Web Start option from the HMCs
remote_client.html page, a new page appears. Choose Linux or Windows as your
operating system. This is the operating system running on your client system. You need
to download an executable file. Run this file. Then return to the browser window and
click the Remote Client link to install the WebSM remote client. Again, you need to
download an executable file and run it.

V3.1.0.1
Instructor Guide

Purpose Describe how to install the WebSM client on remote workstations to provide
access to the HMC interface.
Details Both of these installation options are obtained on the
http://hmchost.domain/remote_client.html installation page. With Java Web Start installed,
whenever the user invokes the WebSM client, it looks for a newer version on the HMC. If a
newer one is found, Java Web Start automatically installs it.
Transition Statement The next page shows the login window when you run the
WebSM client.
Instructor Guide
Remote HMC Login Using WebSM Client
Windows WebSM icon
Type HMCs
name and press
Enter
Wait for
handshake
process to finish
Log in
Figure 2-22. Remote HMC Login Using WebSM Client AU079.1
Notes:
Remote login procedure using the WebSM client

If you wish to use the WebSM client to remotely access an HMC, you need to load the
WebSM client on your workstation. This installs an icon on your desktop for Windows
which can be double-clicked to execute. On AIX and Linux systems, you need to run the
wsm command.
WebSM windows
When you start WebSM on a Microsoft Windows system, two windows open. One
window displays commands that are being executed in the background. Do not close
this window. You do not need to view any information in this window unless you are
troubleshooting an error. Simply minimize the window and forget it is there.
The second window that opens is the login screen shown in the visual above. Enter the
HMCs hostname or IP address and press Enter. Wait for a few moments for the

V3.1.0.1
Instructor Guide
Uempty handshaking communication to finish. If the HMC is found, you may log in. If WebSM
cannot find the HMC, you receive an error message.
Once you successfully log in, the HMC interface appears.
Exiting WebSM
To exit the WebSM window, click the X in the upper right corner of the HMC interface
window or use the Console -> Exit menu option.
Instructor Guide
Instructor Notes:
Purpose Describe the process of bringing up WebSM and logging in.
Details Describe both the process of logging in from the physical HMC and from
WebSM. Once WebSM comes up, it looks like the window on the physical HMC.
Mention that there is a second window that appears when you run WebSM on Microsoft
Windows systems. It is a control window for WebSM and can be ignored. Dont close it; it
will close when you close the WebSM window. The proper way to close the WebSM
window is to click the X in the upper right corner or use Console -> Exit on the menu bar.
Transition Statement Next, we see how to execute HMC command-line commands
remotely.

V3.1.0.1
Instructor Guide
Uempty
Using HMC Commands Remotely
Install SSH if necessary on client
Two ways to run commands using SSH
Single HMC command (you will be prompted for password)
$ ssh -l hscroot hmchost hmccommand
Log in to the HMC and execute commands
$ ssh -l hscroot hmchost
hscroot@hmchost's password:
Last login:Tue Jun 3 14:48:37 2005 from
lpar16.ibm.com
$ chsysstate r sys m msname o off
Figure 2-23. Using HMC Commands Remotely AU079.1
Notes:
HMC command line options

The visual above shows how to use SSH from a remote command line, such as a Linux
or AIX 5L shell. To run HMC commands remotely, you can either send one command to
the HMC as shown in the first example, or login to the restricted shell using SSH and
run any number of commands. Exit out of the SSH shell when youre done. SSH
encrypts network communications for security.
On Microsoft Windows computers, there may be an application, such as the open
source PuTTY program, which provides SSH operations. PuTTY can be downloaded
from the http://www.chiark.greenend.org.uk/~sgtatham/putty/ Web site. When using
PuTTY for SSH communications, be sure to click the SSH button on the login screen
because telnet to the HMC is not allowed.
Instructor Guide
Instructor Notes:
Purpose Describe how to use SSH.
Details The students use the HMC commands extensively in the exercise for this unit
and in future exercises.
This visual shows how to login using SSH from a Linux or an AIX 5L shell. On a Microsoft
Windows computer, it is likely that there is an application, such as PuTTY, which allows
SSH access.
Transition Statement Lets look at some HMC command examples.

V3.1.0.1
Instructor Guide
Uempty
HMC Commands
HMC provides restricted shell
echo $PATH shows available directories
Example operations which are not allowed
cd, pipe, redirection, su
Commands have --help option and man pages
Example commands:
Show processor usage by partition
$ lshwres -m msname -r proc --level lpar \
F lpar_name,run_procs --header
LPAR1,0
LPAR2,1
LPAR3,0
Reboot the HMC immediately

$ hmcshutdown t now -r
Figure 2-24. HMC Commands AU079.1
Notes:
HMC commands
Once youve logged in you can execute the echo $PATH command to see which
directories are available to you in the HMCs restricted shell. You can only run the
commands in these directories and the shell commands are restricted as well.
List each of the directories listed in the echo $PATH output to see a listing of the
commands that are available. For usage information, run the commands with the
--help option or access the man pages. For example, man hmcshutdown displays the
manual page for that command. Often the man page shows more information than the
--help information.
Instructor Guide
Instructor Notes:
Purpose Introduce HMC commands.
Details HMC commands are mentioned as appropriate throughout this course. This
page illustrates how commands are executed.
Mention that if you leave the -r off of the hmcshutdown command that is shown on the
visual, the HMC shuts down without rebooting. Ask the students: What would happen if you
did this command remotely without the -r option? Answer: The HMC shuts down, and
because you are remote, you are not able to boot it again. Someone local to the HMC has
to boot it.
Transition Statement Now, lets do some checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint
1. When might an HMC need to be configured as a DHCP server?
_________________________________________
2. How is the HMC connected to its managed system?
_________________________________________
3. In what ways can the HMC functions be accessed remotely?
_________________________________________
4. Besides the firewall options, what are the two remote access
options that can be enabled or disabled on the HMC?
_________________________________________
5. (True or False) The HMC can be used as a fully functional Linux
system.
Figure 2-25. Checkpoint AU079.1
Notes:
Instructor Guide
Instructor Notes:
Purpose Discuss the checkpoint questions for this unit.
Details A Checkpoint Solution is given below:
Checkpoint Solutions
This is appropriate when the HMC is on a private network
and there is no other DHCP server.
The connection uses Ethernet.
SSH, WebSM client, from another HMC
Remote virtual console, SSH access
system.
Transition Statement Its time for an exercise.

V3.1.0.1
Instructor Guide
Uempty
Exercise: HMC Configuration
Exercise 2
Figure 2-26. Exercise: HMC Configuration AU079.1
Notes:
Instructor Guide
Instructor Notes:
Purpose Transition to the exercise for this unit.
Details
Transition Statement Lets review some of the key points from this unit.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
The Hardware Management Console (HMC) is a key network
component in an IBM System p5 environment.
The Guided Setup Wizard application provides an easy way to
complete initial configuration of the HMC.
A number of screens are used for configuration of HMC network
parameters.
HMC functions can be accessed remotely from another HMC, from
a WebSM client, or from an SSH connection.
You can enable or disable remote command execution using SSH
and/or remote virtual console support. By default, both are
disabled.
Notes:
Instructor Guide
Instructor Notes:
Purpose Review some of the key points from this unit.
Details
Transition Statement Lets move on to the next unit.

V3.1.0.1
Instructor Guide
Uempty Unit 3. Configuring TCP/IP

This unit covers the configuration of TCP/IP. It describes the files that
are used by TCP/IP and the commands that can be used to gather
information about your configuration.

Configure TCP/IP
Test and review TCP/IP configuration with selected AIX and
TCP/IP commands
Start and stop TCP/IP services

Accountability:
Exercises
Copyright IBM Corp. 1997, 2006 Unit 3. Configuring TCP/IP 3-1

Instructor Guide
Unit Objectives
After completing this unit, students should be able to:
Configure TCP/IP
Test and review TCP/IP configuration with selected AIX and TCP/IP
commands
Start and stop TCP/IP services
Notes:

V3.1.0.1
Instructor Guide

Purpose Review the objectives for this unit.
Details In this unit the emphasis is on configuring TCP/IP. Students are shown how to
use SMIT to configure it and then the files and commands that are used by SMIT. Students
are also introduced to several commands that can be used to verify the configuration.
Transition Statement Let's begin our discussion by looking at the software support that
comes with AIX.

Instructor Guide
TCP/IP Software Support

Base operating system must be installed
bos.net is the network package which will install
Asynchronous Terminal Emulator (bos.net.ate)
PPP (bos.net.ppp)
CacheFS (bos.net.nfs.cachefs)
IP Security (bos.net.ipsec.rte)
NCS (bos.net.ncs)
NFS Client (bos.net.nfs.client)
NFS Development Toolkit (bos.net.nfs.adt)
NFS Server (bos.net.nfs.server)
NIS Client (bos.net.nis.client)
NIS Server (bos.net.nis.server)
TCP/IP Application Toolkit (bos.net.tcp.adt)
TCP/IP Client Support (bos.net.tcp.client)
TCP/IP Server (bos.net.tcp.server)
TCP/IP SMIT Support (bos.net.tcp.smit)
UNIX to UNIX copy program (bos.net.uucp)
Figure 3-2. TCP/IP Software Support AU079.1
Notes:
In AIX the TCP/IP network utilities are broken up into their component parts (such as NFS,
NIS) and further divided into client and server pieces. This was done to provide only the
code needed to perform specific functions. If a system is never a server, then the server
code is simply taking up valuable disk space that could be used for data or applications. To
install the appropriate filesets use SMIT:
# smit
Software Installation and Maintenance
Install and Update Software
Install
Input device / directory for software
SOFTWARE to install

V3.1.0.1
Instructor Guide

Purpose Describe what software needs to be installed to support TCP/IP.
Details Introduce software requirements for TCP/IP. This course does not use IP
security, Network Computing Services (NCS), toolkits and uucp (also referred to as BNU -
basic network utilities). Students should have a basic understanding of bos system
administration issues like capacity planning, storage management and performance.
Additional Information To see what is already installed on a system, use the following
command:
$ lslpp -l (for a complete listing)
$ lslpp -l | grep bos.net (to list all the network related filesets)
Transition Statement Let's look at an overview of the customization steps for TCP/IP.

Instructor Guide
TCP/IP Customization Steps

Define/configure adapters
Define/configure network interfaces
Set the hostid and hostname
Define name resolution information
Define routing information
Enable server services (daemons)
Figure 3-3. TCP/IP Customization Steps AU079.1
Notes:
To do this:
- Use SMIT fast path smit tcpip
(ODM database is used)
or
- Configure by editing text files and shell scripts

(ODM not used)

V3.1.0.1
Instructor Guide

Purpose Provide a summary of the steps involved in customizing TCP/IP.
Details This foil is placed here to provide a quick overview of TCP/IP customization
steps. Each item is discussed further so be careful not to go into detail on any of them yet.
Routing is covered in two completely separate units. The one item to emphasize is the fact
that either SMIT or editing of text files can be used, but they shouldn't be mixed. SMIT is
the preferred method because it updates the configuration database (ODM) and all the key
steps can be done by filling out one screen, the TCP/IP Minimum Configuration and
Startup screen.
Transition Statement Let's start at the top of the list, define adapters, and work our way
down.

Instructor Guide
Configuring Adapters
Most adapters are automatically detected and defined during
system startup.
Use the SMIT Devices menu, Communications submenu for:
Ethernet Adapter
TokenRing Adapter
Fibre Channel
FDDI Adapter
ATM Adapter
Etherchannel (IEEE 802.3 ad Link Aggregation)
VLAN
Figure 3-4. Configuring Adapters AU079.1
Notes:
Install the adapters and cabling for your network. Adapter cards in a pSeries are
automatically detected and configured during system startup, so normally you would only
need to change adapter characteristics if the defaults are not appropriate. Use the SMIT
fast path smit commodev menus (or the chdev command) if you need to change the
default attributes.

V3.1.0.1
Instructor Guide

Purpose To describe how adapters are configured on the RISC System/6000.
Details Use smit commodev menus to alter defaults.
Additional Information Refer to SG24-2581 for details.
Transition Statement The next step is to select the appropriate network interface.

Instructor Guide
Network Interfaces
Each network adapter has an associated network interface
Adapter Interface Description

Prefix Prefix
ent en Ethernet
et IEEE 802.3
tok tr Token-Ring
sx25a xs X.25
tty sl Serial Line Internet Protocol (SLIP)
tty pp Point-to-Point Protocol (PPP)
ops so Serial Optical
atm at Asynchronous Transfer Mode
fddi fi FDDI
-- lo Loopback
css css SP Switch
vi Virtual IP Address
Figure 3-5. Network Interfaces AU079.1
Notes:
When each adapter or port is added, a logical device is created in the ODM such as:
Ethernet adapters are ent0, ent1 and so forth
Token-Ring adapters are tok0, tok1, and so forth
A corresponding network interface in the kernel allows TCP/IP to use an adapter. For
auto-detectable adapters, such as Token-Ring and Ethernet, the network interface is
created at the same time as the adapter device. For manually added devices, the network
interface must be manually created.
The loopback is a special interface which is defined so that a host can send messages to
itself for diagnostic purposes. Data sent to this interface never appears on a network, it is
just sent back up through the software layers.
Network interfaces are represented by logical devices. They are given the interface device
names shown in the chart.

V3.1.0.1
Instructor Guide
Uempty TCP/IP support in AIX is provided by a kernel extension called inet0. A kernel extension is
a separate entity from the kernel but runs in the kernel address space. inet0 provides the
IP,TCP,UDP functions.
Configuration information for inet0 is stored in the ODM. The standard device management
commands (chdev, and so forth) can be used to set the attributes of inet0, and this can
also be done through the SMIT TCP/IP menus.

Instructor Guide
Instructor Notes:
Purpose Provide information on the supported network interfaces under AIX.
Details Most of the information needed for this visual is in the student notes.
Transition Statement You may have noticed that the Ethernet network interface comes
in two flavors. Ethernet Version 2 and IEEE 802.3. Let's see where the difference lies
between these two.

V3.1.0.1
Instructor Guide
Uempty
Ethernet Network Interface
Standard Ethernet Version 2 (en0)
DA SA TYPE DATA
SA=Source Address
DA=Destination Address
TYPE=TCP/IP, DECnet, XNS
IEEE 802.3 (et0)
DA SA LENGTH DATA
Figure 3-6. Ethernet Network Interface AU079.1
Notes:
The Ethernet adapters on the RISC System/6000 can be configured to support either
Ethernet Version 2 or IEEE802.3 network interface driver software. The difference between
the two lies in the header information.
The Ethernet V2 type field defines the higher-layer protocol that is used within the data
field. It is a two-byte field that is administered by Xerox. Type examples might be 0800 hex
for the IP of TCP/IP, 0600 hex for XNS, and 6003 hex for DECnet.
The IEEE 802.3 length field is the length of the data field that follows. With IEEE 802.3, the
designation of the higher-level protocol is done by the 802.2 Logical Link Control.
Because of this difference either a network is configured as IEEE 802.3 or Ethernet Version
2. A workstation configured as Ethernet Version 2 cannot communicate with one configured
as IEEE 802.3 and vice versa.

Instructor Guide
Instructor Notes:
Purpose Identify the difference between Ethernet Version 2 and IEEE 802.3.
Details When configuring an Ethernet adapter for AIX, you have to choose between
Version 2 and 802.3. Which do you choose? Choose the one appropriate for your
installation.
The only difference between Ethernet Version 2 and IEEE 802.3 is in the data packet. The
Ethernet Version 2 packet contains a two-byte field for the type of protocol (as stated in the
student notes). The IEEE 802.3 uses the two-byte field for the length of the data packet.
This difference is enough so the two protocols don't understand each other's data. Both
Ethernet Version 2 and IEEE 802.3 frames can coexist on the same physical media but
require different device drivers. Data sent across an IEEE 802.3 interface cannot be read
by an Ethernet Version 2 interface and vice versa.
Discussion Items Does anybody have 802.3 (not Version 2) in their installation?
Why?
Additional Information It is possible to support both IEEE 802.3 and standard Ethernet
on the same physical adapter using two separate IP addresses.
Transition Statement How do the network interfaces get configured?

V3.1.0.1
Instructor Guide
Uempty
Defining and Configuring Network Interfaces
pSeries
ODM
inet0 e
inet0 n
0
AIX
Most interfaces are already defined during automatic system

configuration
Use SMIT Minimum Configuration and Startup dialog to configure
the first interface - smit mktcpip
Use SMIT Network Interfaces menu Further Configuration to
change interfaces or add additional interfaces (Multi-homed) -
smit chinet
To manually configure interfaces, use ifconfig
Figure 3-7. Defining and Configuring Network Interfaces AU079.1
Notes:
Some interfaces are defined automatically during system configuration.
When you run the SMIT Minimum Configuration and Startup dialog you are asked to
select a defined interface. When you run the dialog, that interface is brought up.
Use the SMIT Network Interfaces menu to define new interfaces or change the
characteristics of existing interfaces.
The mkdev/chdev commands can be used to update the information in the ODM that
describes network interfaces. Changes made take effect immediately and are permanent.
The ifconfig command can be used to configure an interface. We cover this in more detail
further on.

Instructor Guide
Instructor Notes:
Purpose Show students what can be used to configure network interfaces.
Details In the following two visuals we will be showing students two of the ways of
customizing an interface listed here - through SMIT Minimum Configuration And Startup
and through the use of the ifconfig command.
Additional Information Use the visual to contrast the differences between the methods
of configuring TCP/IP on whether you are using the ODM.
Discussion Item You may want to discuss the possible problems with ODM when using
two methods at one time. (This issue should be reinforced at some time to avoid major
problems later.)
Transition Statement Let's take a look at the SMIT method first.

V3.1.0.1
Instructor Guide
Uempty
Minimum Configuration and Startup
# smit mktcpip
Minimum Configuration & Startup
To delete existing configuration data, please use further

Configuration menus
Type or select values in entry fields

Press Enter AFTER making all desired changes.
[Entry Fields]
* HOSTNAME [ ]
* Internet ADDRESS (dotted decimal) [ ]
Network MASK (dotted decimal) [ ]
* Network INTERFACE en0
NAMESERVER [ ]
Internet ADDRESS (dotted decimal) [ ]
DOMAIN Name [ ]
Default Gateway Address [ ]
(dotted decimal or symbolic name)
cost [ ]
Do Active Dead Gateway Detection [ ]
Your CABLE Type N/A +
START no +
F1=Help F2=Refresh F3=Cancel F4=List

F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do
Figure 3-8. Minimum Configuration and Startup AU079.1
Notes:
Configuring TCP/IP on a system with one network adapter is as easy as filling out this
SMIT menu. The steps on the following pages show the manual steps of TCP/IP
configuration. Keep in mind that SMIT is doing all these steps for you behind the scenes.
If your system has more than one network adapter card, the TCP/IP Further
Configuration SMIT menu would be used to configure those cards.
The minimum information that is required to start TCP/IP is the hostname, one interface
and the Internet address. If subnetting is used then the subnet mask should be specified.

Instructor Guide
Instructor Notes:
Purpose Show how simple TCP/IP configuration is when using SMIT.
Details Explain that configuring TCP/IP on the RISC System/6000 is as easy as filling
out this menu. Further explain that we will go through the command line method of
configuration so the students understand exactly what SMIT is doing for them behind the
scenes. If they are going to install TCP/IP in an open environment, the steps as listed in the
lecture can apply to most other systems that do not have a systems management interface
tool.
Later in the lecture and in the routing lecture, it is mentioned that some systems will have
more than one network adapter connecting the system to more than one network. This is
done in the case of routers. The Minimum Configuration menu can be used for the first
adapter card configured, but the Further Configuration menu would be used to configure
all other adapter cards in the system. There is not a view of the Further Configuration
menu. They have a chance to see it during lab.
You may want to come back to this foil after covering ifconfig, hostname, and /etc/hosts
to show all that this menu does to configure TCP/IP. Keep this page handy.
Additional Information Further configuration should be used for anything else other
than a basic configuration to get the system functional on the network. The logic goes as
follows: 1) Everything that Minimum Configuration does can be done by Further
Configuration. You are not required to use the minimum configuration screen at all. It
does, though, provide a handy shortcut for getting the system up on the network quickly; 2)
Further Configuration must be used to configure additional adapters. Only one adapter
should be configured using minimum configuration.
Note: When using minimum configuration screen, the /etc/hosts file is updated. If used
again, could cause problems with name resolution!
Default AIX-style configuration uses the data in the ODM database and uses the file
/etc/rc.net to define, load, and configure a corresponding interface.
For those who are familiar with other UNIXes, BSD-style configuration uses the traditional
ifconfig command and the file /etc/rc.bsdnet to configure the corresponding interface.
To change from AIX to BSD style, use smit setbootup_option.
By selecting BSD, the system updates the ODM database, /etc/objrepos/Config_Rules,
to have the cfgmgr execute /etc/rc.bsdnet at startup instead of /etc/rc.net.
Transition Statement Let's take a look at the command that can be used for configuring
an interface or check or change configuration once an interface is configured.

V3.1.0.1
Instructor Guide
Uempty
Further Configuration
# smit chinet
Change/Show an IEEE 802.3 Network Interface
Type or select values in entry fields.

[Entry Fields]
Network Interface Name et1

INTERNET ADDRESS (dotted decimal) [ ]
Network MASK (hexadecimal or dotted decimal) [ ]
Current STATE down +
Use Address Resolution Protocol (ARP)? yes +
BROADCAST ADDRESS (dotted decimal) [ ]
Interface Specific Network Options
('NULL' will unset the option)
rfc1323 [ ]
tcp_mssdflt [ ]
tcp_nodelay [ ]
tcp_recvspace [ ]
tcp_sendspace [ ]
Apply change to DATABASE only no
Esc+1=Help Esc+2=Refresh Esc+3=Cancel Esc+4=List

Esc+5=Reset Esc+6=Command Esc+7=Edit Esc+8=Image
Esc+9=Shell Esc+0=Exit Enter=Do
Figure 3-9. Further Configuration AU079.1
Notes:
The Further configuration SMIT menu allows configuration of more than one network
adapter.
Interface Specific Network Options include:
rfc1323 - enable large packets for high performance
tcp_mssdeflt - maximum segment size
tcp_nodelay - pacing message flow
tcp_recvspace - socket buffer size for receiving data
tcp_sendspace - socket buffer size for sending data

Instructor Guide
Instructor Notes:
Purpose Explain the further configuration of network adapters.
Details These options are set using the ISNO field under the no (network options)
command.
rfc1323 - Enables TCP enhancements as specified by RFC 1323, TCP Extensions for High
Performance. rfc1323 is a connect type tunable. Setting it overrides the system-wide
rfc1323 set by the no command.
tcp_mssdflt - The default maximum segment size used in communicating with remote
networks. tcp_mssdflt is a connect type tunable. Setting it overrides the system-wide
tcp_mssdflt set by the no command. Use this option only if path MTU discovery is not
enabled or path MTU discovery fails to discover a path MTU. You can specify a value from
0 to (PMTU -52) or 64K-1. The default value is 512.
tcp_nodelay - If tcp_nodelay is enabled (set to 1) and the send buffer size is less than or
equal to the maximum segment size (ATM and SP switches can have 645 MTUs), the
applications, data will be sent immediately and the application must wait for an ACK before
sending another packet (this prevents TCP streaming and could reduce throughput). To
remove this option from the interface and delete it from the ODM, type NULL in this field.
tcp_recvspace - The system default socket buffer size for receiving data. This affects the
window size used by TCP. tcp_recvspace is a connect type tunable. Setting it overrides the
system-wide tcp_recvspace set by the no command. Setting the socket buffer size to 16KB
(16,384) improves performance over standard Ethernet and Token-Ring networks. The
default is a value of 4096. A value of 16,384 is set automatically by the rc.net file or the
rc.bsdnet file (if Berkeley-style configuration is issued). Lower bandwidth networks, such as
Serial Line Internet Protocol (SLIP), or higher bandwidth networks, such as Serial Optical
Link, should have different optimum buffer sizes. The optimum buffer size is the product of
the media bandwidth and the average round-trip time of a packet. You must specify a
socket buffer size less than or equal to the setting of the sb_max attribute.
tcp_sendspace - The system default socket buffer size for sending data. This affects the
window size used by TCP. tcp_sendspace is a connect type tunable. Setting it overrides
the system-wide tcp_sendspace set by the no command. Setting the socket buffer size to
16KB (16,384) improves performance over standard Ethernet and Token-Ring networks.
The default is a value of 4096. A value of 16,384 is set automatically by the rc.net file or the
rc.bsdnet file (if Berkeley-style configuration is issued). Lower bandwidth networks, such as
Serial Line Internet (SLIP), or higher bandwidth networks, such as Serial Optical Link,
should have different optimum buffer sizes. The optimum buffer size is the product of the
medial bandwidth and the average round-trip time of a packet:
optimum_window=bandwidth * average_round_trip_time. You must specify a socket
buffer size less than or equal to the setting of the sb_max attribute.
Transition Statement Now, lets look at the ifconfig command.

V3.1.0.1
Instructor Guide
Uempty
ifconfig Command
# ifconfig en0 inet 10.19.98.1 netmask 255.255.255.0 up
A B C D E
A: interface => en, et, tr, xs, sl, lo, op, ca
B: address family => inet, xns
C: address => Ip address for adapter or hostname
D: parameter + value metric number mtu value
network mask
E: parameters
alias delete debug
allcast detach -debug
-allcast down up
arp hwloop
-arp -hwloop
Figure 3-10. ifconfig Command AU079.1
Notes:
The ifconfig command configures or displays network interface parameters for a network
using TCP/IP.
If a machine has more than one adapter card that is used for TCP/IP, like the router, then
the ifconfig command needs to be executed for each adapter.
The 0x in the netmask indicates a hex value.
Xerox Network Systems, xns, is a transport protocol that was developed by Xerox.
To display, simply enter ifconfig<interface>. While any user can query the status of a
network interface using ifconfig, only a user who has root authority can modify the
configuration of the interface.
The D parameters require a value. The E parameters do not.

Instructor Guide
Instructor Notes:
Purpose Explain the ifconfig command.
Details The ifconfig command is the TCP/IP standard way of configuring and
displaying information of network adapter cards for LANs.
Explain the ifconfig command parameters shown in the example. For the other parameter
values under D, explain a couple of the more frequently used ones like delete, detach,
down and up. Caution students about playing with the mtu parameter. The ifconfig
command in the following format DOES NOT display the mtu value, it sets it to 0.
ifconfig tr0 mtu
Following are some of the parameter values and their use:
alias Establishes an additional network address for the interface. When
changing network numbers, this is useful for accepting packets
addressed to the old interface.
allcast Sets the Token-Ring interface to broadcast to all rings on the
network.
-allcast Confines the Token-Ring interface to broadcast only to the local ring.
arp Enables the ifconfig command to use the Address Resolution
Protocol in mapping between network-level addresses and link-level
addresses. This flag is in effect by default.
-arp Disables the use of the Address Resolution Protocol.
debug Enables driver-dependent debug code.
-debug Disables driver-dependent debug code.
delete Removes the specified network address. This is used when an alias
is incorrectly specified or when it is no longer needed.
detach Removes an interface from the network interface list. If the last
interface is detached, the network interface driver code is unloaded.
down Marks an interface as inactive (down), which keeps the system from
trying to transmit messages through that interface. If possible, the
ifconfig command also resets the interface to disable reception of
messages. Routes that use the interface, however, are not
automatically disabled.
hwloop Enables hardware loopback. The hardware loopback specifies that
locally addressed packets handled by an interface should be sent
out using the associated adapter.
-hwloop Disables hardware loopback. The hardware loopback specifies that
locally addressed packets handled by an interface should be sent
out using the associated adaptor.

V3.1.0.1
Instructor Guide
Uempty metric Number Sets the routing metric of the interface to the value specified by the
Number variable. The default is 0 (zero). The routing metric is used
by the routing protocol (the routed daemon). Higher metrics have
the effect of making a route less favorable. Metrics are counted as
addition hops to the destination network or host.
mtu Value Sets the maximum IP packet size for this system. The Value
variable can be any number from 60 through 65535, depending on
the network interface.
netmask Mask Specifies how much of the address to reserve for subdividing
networks into subnetworks. This parameter can be used only with an
address family of inet.
The Mask variable includes both the network part of the local
address and the subnet part, which is taken from the host field of the
address. The mask can be specified as a single hexadecimal
number beginning with 0x, in standard Internet dotted decimal
notation, or beginning with a name or alias that is listed in the
/etc/networks file.
up Marks an interface as active (up). This parameter is used
automatically when setting the first address for an interface. It can
also be used to enable an interface after an ifconfig down
command.
Additional Information The ifconfig command is very useful in seeing the values and
status of an interface. For example:
en1:
flags=e080863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GR
OUPRT,64BIT>
inet 10.1.1.3 netmask 0xffffff00 broadcast 10.1.1.255
Flags from ifconfig output:
ALLCAST The token ring interface broadcasts to all rings on the network.
BROADCAST The adapter supports broadcast messages.
MULTICAST The adapter supports multicast messages.
DEBUG Adapter-dependent debug is enabled.
SIMPLEX The adapter will not receive its own broadcast.
HWLOOP The adaptor supports hardware loopback (IP normally does the
loopback)
NOARP The interface does not do ARP translation.
NOECHO The adapter associated with the interface does not do local echo.
NOTRAILERS The interface does not append trailers to frames

Instructor Guide
RUNNING The interface is up and running.

UP The interface is up. It must also be running to be usable.
Display of the ifconfig command include -a, -d, -m, -u flags for displaying interface
information. The -a flag can be used instead of an interface name, displaying information
about all interfaces on the system. The -d displays interfaces that are down, while -u
displays up interfaces. If the -m flag is passed before an interface name, ifconfig will
display all the supported media for the specified interface.
Transition Statement Lets have a look how to identify systems with host names.

V3.1.0.1
Instructor Guide
Uempty
Host Name
Used by some applications to identify or authenticate your system
Hostname set when TCP/IP is configured using SMIT by running
the hostname command
To display the hostname:

# hostname
aixserv
To change the hostname until next system reboot:
# hostname sys1
# hostname
sys1
Use SMIT for permanent change or
# chdev -l inet0 -a hostname=sys1
Figure 3-11. Host Name AU079.1
Notes:
The hostname is used by applications to find out the name of your system for
authentication purposes and to obtain your Internet address.
The hostname can be displayed using the command: hostname
The hostname is stored in the inet0 kernel extension. To change this permanently use
SMIT or: chdev -l inet0 -a hostname=hostname.

Instructor Guide
Instructor Notes:
Purpose Explain the hostname and hostid commands and why they are used.
Details Only users with root authority can set the host name. Students often get this
confused with the symbolic name assigned to each network interface. There can only be
one hostname, but because there can be several network interfaces on a system, there
can be several symbolic names (often referred to as host name - thus the confusion.) By
convention, the first network interface configured is considered the primary network
interface and is given the same symbolic name as the hostname. Try to get students to see
this distinction.
Additional Information: The usr/sbin/hostid command displays the identifier (either a
unique hostname or a numeric argument) of the current host as a hexadecimal number.
This numeric value is expected to be unique across all hosts and is commonly set to the
address of the host specified by the InternetAddress or HostName parameter.
Transition Statement The next step is to assign symbolic names to all the other hosts
and network interfaces to which you wish to communicate. That is done with the /etc/hosts
file.

V3.1.0.1
Instructor Guide
Uempty
/etc/hosts
# The format of the file is:
# Internet Address Hostname # Comments
# Items are separated by any number of blanks and tabs.
# A '#' indicates the beginning of a comment; characters up to the
# end of the line are interpreted by routines which search
# this file. Blank lines are allowed.
# Internet Address Hostname # Comments

127.0.0.1 loopback localhost
192.9.200.1 host1 timeserver
192.9.200.2 host2
192.9.200.3 host3
192.9.200.4 host4 # router
Figure 3-12. /etc/hosts AU079.1
Notes:
Host names (symbolic network interface names) and their IP addresses are associated
with each other by entries in the /etc/hosts file.
Entries should be included in /etc/hosts for (1) loopback, (2) the local machine, and (3) any
other hosts known to the system. Typically, /etc/hosts is kept consistent among all
machines.
Aliases can be created in this file by entering them after the host name. Each alias is
separated by a space. Aliases cannot exceed 255 characters and each entry must be
contained on one line.

Instructor Guide
When you add the local machine via Minimum Configuration and Startup, the system
automatically updates /etc/hosts with the local machine entry. To add the other hosts:
# smit mkhostent
*INTERNET ADDRESS (dotted decimal) [ ]
*HOST NAME [ ]
ALIAS(ES) (if any - separated by blank space) [ ]
COMMENT (if any - for the host entry) [ ]
This method of name resolution is called flat name resolution. Networks that use
/etc/hosts for doing name resolution are called flat networks.

V3.1.0.1
Instructor Guide

Purpose Explain the role of /etc/hosts.
Details /etc/hosts lists all the systems to which you want to connect. Those systems, in
turn, must have your system's host name and IP address.
The syntax of the file is IP address, host name, alias names for a system, and a comment
line that can be used to provide any information about a particular system. Comments must
be preceded by a #.
Additional Information The first entry of this file should be 127.0.0.1 loopback
localhost followed by local machine and then any additional hosts. Later in this course,
DNS will be presented and contrast with a flat network (/etc/hosts file).
Discussion Items Go back to the Minimum Configuration and Startup menu at the
beginning of the unit. Fill in the values used by the ifconfig and hostname commands.
Explain that this one SMIT menu executes both ifconfig and hostname and automatically
enters the information for this system in the /etc/hosts file.
If two systems have the same host name, which are accessed? The first one in the list as
the file is searched sequentially. No two systems should have the same host name.
Transition Statement Let's now look at the file from which TCP/IP server services are
enabled.

Instructor Guide
Starting Daemons
The /etc/rc.tcpip file run at system startup can start the following
TCP/IP daemons:
- syslogd Logs error messages

- portmap Port lookup facility
- inetd Super daemon
- named Domain nameserver
- Ipd Print server
- routed or gated Dynamic routing
- sendmail Mail
- timed, xntpd Time daemons
- rwhod Remote uptime and users
- snmpd, dpid2 SNMP daemons
- dhcpcd, dhcprd, dhcpsd DHCP daemons
- autoconf6, ndpd-host IPv6 daemons
- mrouted Multicast routing
Figure 3-13. Starting Daemons AU079.1
Notes:
/etc/rc.tcpip assumes interfaces are brought up by /etc/rc.net. This shell script starts the
TCP/IP daemons.
All these daemons can be started or stopped using the subsystem commands of the
system resource controller. They are stopsrc, startsrc or refresh.
System Resource Controller (SRC) is a tool designed to aid a system administrator in
controlling daemons. It allows you to start, stop, trace, list, and refresh daemons. It also
gives you the ability to group them.
SMIT provides a way to start up some of the daemons listed above through the fastpath
smit otherserv. Select the daemons you want to start. When you select a daemon, SMIT
gives you the choice to start the daemon now, at next system restart, or both. When you
select at next system restart or both, the system uncomments the appropriate line in
/etc/rc.tcpip.

V3.1.0.1
Instructor Guide

Purpose Explain the role of /etc/rc.tcpip
Details This file starts the daemons which provide the TCP/IP services.
The common daemons that are started by this file are:
syslogd - the daemon which performs error and event logging.
portmap - activated if port monitoring is required.
inetd - the super server that starts other services such as telnet, ftp, talk, and so forth,
on request.
named - activated only on a host that provides the nameserver function in a domain
network.
lpd - activated only on a host that is a printserver.
Routed or gated only one of these daemons should be activated and only on a host that
needs to receive or broadcast routing information. Only use routed if you just want RIP
and do not want to support SNMP, otherwise use gated.
sendmail - activated for remote mail
timed - activated only on a host that is a time server.
rwhod - the daemon which monitors remote system uptime and users. Running this
daemon can add significant load to the network.
Other TCP/IP daemons are added to the /etc/rc.tcpip script by software applications.
Daemons can be started or stopped using SRC, SMIT, or from the command line.
This is the first time that SRC is introduced. There is no topic on SRC. Take a moment to
explain it here. Cover what is in the student notes in the process. Use your own method of
information or what is listed under Additional Information
Additional Information SRC is a subsystem controller that facilitates the management
and control of complex subsystems. SRC provides a single set of commands to start, stop,
trace, list, and refresh the status of a subsystem. A subsystem is a program or set of
related programs designed as a unit to perform related functions. A subserver, or daemon,
is a process that belongs to and is controlled by a subsystem.
# lssrc -g tcpip lists all the daemons or subservers in the subsystem group TCP/IP.
Transition Statement The inetd daemon is a special daemon that manages other
subservers. Let's see how this works.

Instructor Guide
/etc/inetd.conf
## Internet server configuration database
##
ftp stream tcp6 nowait root /usr/sbin/ftpd ftpd
telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd
shell stream tcp6 nowait root /usr/sbin/rshd rshd
kshell stream tcp nowait root /usr/sbin/kvshd rshd
login stream tcp6 nowait root /usr/sbin/rlogind rlogind
klogin stream tcp nowait root /usr/krlogind rlogind
exec stream tcp6 nowait root /usr/sbin/rexecd rexecd
#comsat dgram udp wait root /usr/sbin/comsat comsat
#uucp stream tcp nowait root /usr/sbin/uucpd uucpd
#bootps dgram udp wait root /usr/sbin/bootpd bootpd /etc/bootptab
##
## Finger, systat and netstat give out user information which may be
## valuable to potential "system crackers." Many sites choose to disable
## some or all of these services to improve security.
##
#finger stream tcp nowait nobody /usr/sbin/fingerd fingerd
#systat stream tcp nowait nobody /usr/bin/ps ps -ef
#netstat stream tcp nowait nobody /usr/bin/netstat netstat -f inet
##tftp dgram udp6 wait nobody /usr/sbin/tftpd tftpd -n
#talk dgram udp wait root /usr/sbin/talkd talkd
ntalk dgram udp wait root /usr/sbin/talkd talkd
Figure 3-14. /etc/inetd.conf AU079.1
Notes:
This is not a listing of the complete file.
The inetd daemon is started at boot time from /etc/rc.tcpip. When it is started, inetd reads
its configuration from the /etc/inetd.conf file. This file contains the names of the services
that inetd listens for requests and starts as needed to handle these requests.
Socket Type: stream is for TCP and dgram is for UDP.
Wait/Nowait: wait is for dgram and nowait is for stream. It determines whether the inetd
daemon waits for a datagram server to release the socket before continuing to listen at the
socket.
User: specifies the user name that the inetd daemon should use to start the server.

V3.1.0.1
Instructor Guide

Purpose Explain the configuring of inetd networking services.
Details Role of inetd--super daemon that provides all the services, but multiple
daemons do not have to be running in preparation to handle requests.
You can add or delete services by editing the file or by using SMIT.
Discussion Items Provide the background information listed below and use the board
to draw a diagram of what's happening. Stop and ask questions along the way. This
background will give insight to inetd's power and efficiency.
How inetd came to be:
sysA wants to establish an ftp (you learn more about this file transfer program later in the
class) session with sysB to transfer some files over the network. sysB needs to have an
ftpd daemon running to connect to sysA's request (remember our discussion about ports
and sockets in the previous lecture).
Now sysC decides it wants to ftp to sysB as well. sysC also needs an ftpd daemon on
sysB to connect to.
Two systems cannot use the same ftpd at the same time. An option is to start multiple ftpd
daemon processes on sysB guessing at how many systems on the network might want to
establish an ftp session at the same time. This is not very efficient, as your system is
limited to the number of processes it can run.
sysA sysC
ftp ftp
\ /
\ /
ftpd
ftpd
sysB
Take another approach by letting the inetd daemon start and stop the number of processes
that are necessary:
sysA sysB
ftp------>inetd
|
<---ftpd
sysA dynamically assigns a port (example port 2498) for the source port on sysA and
sends a request to connect to port 21 on sysB. sysB starts up an ftpd with a unique PID
and PPID pointing back to the inetd process. The source port (2498) destination port (21)
pair uniquely identifies this network connection in conjunction with the source and
destination IP address.

Instructor Guide
sysC sysB
ftp--------->inetd
|
<-----ftpd
sysC dynamically assigns a port (for example port 2499) for the source port on sysC to
connect to and sends a request to connect to port 21 on sysB. inetd starts another ftpd
process on sysB and the source port (2499) destination port (21) pair uniquely identifies the
network connection.
Transition Statement Now that we have TCP/IP completely configured, let's see what
happens the next time the system is booted.

V3.1.0.1
Instructor Guide
Uempty
TCP/IP Startup Flow
system ODM
/etc/objrepos/Config_Rules
powered .
on .
.
/etc/rc.net selected
. daemons started
cfgmgr .
. syslogd
lpd
routed or gated
/etc/inittab sendmail
run-time . portmap
Init . inetd
. .
rctcpip:/etc/rc.tcpip .
.
. .
system .
ready or
login
Figure 3-15. TCP/IP Startup Flow AU079.1
Notes:
When the system starts up, it reads out of the ODM whether to use rc.net (AIX default
network configuration file) to initialize the network interfaces and set up routing.
An entry in the /etc/inittab file is made at installation time to execute the /etc/rc.tcpip shell
script at system startup. The various uncommented daemons are started. The system is
now ready to accept communication requests from various applications.

Instructor Guide
Instructor Notes:
Purpose Describe the facilities involved in initializing TCP/IP on system startup.
Details When the system starts up, it reads out of the ODM whether to use rc.net or
rc.bsdnet to initialize the interfaces and route table.
Next, init reads inittab and executes rc.tcpip which starts the necessary daemons
involved.
Additional Information /etc/rc.bsdnet is used to manually set up the TCP/IP facilities
as is done with BSD UNIX and other UNIX operating systems.
Transition Statement How do we know our configuration was done right? By testing it!

V3.1.0.1
Instructor Guide
Uempty
Verifying Network Interfaces
Example: # netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

en0 1500 link#2 8.0.5a.ba.d2.62 376607 0 194339 0 0
en0 1500 10.180.108 sys7.ibm.com 376607 0 194339 0 0
lo0 16896 link#1 23198 0 23259 0 0
lo0 16896 127 localhost 23198 0 23259 0 0
lo0 16896 ::1 23198 0 23259 0 0
Example: # ifconfig -a
en0: flags=e080863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 10.180.108.84 netmask 0xfffffc00 broadcast 10.180.111.255
lo0: flags=e08084b<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
Figure 3-16. Verifying Network Interfaces AU079.1
Notes:
The netstat command is used to display active sockets for each protocol, routing table
information, or contents of a network data structure.
The -i option shows the state of configured interfaces. This display format provides a table
of cumulative statistics for: errors, collisions, and packets transferred. It provides the
interface name, number, and address as well as the maximum transmission units (MTUs).
The address field of the first entry for each interface provides the hardware address of the
adapter.
In contrast to netstat -i, ifconfig -a displays interface attributes (for example, Up or Down),
the network mask in Hex and the broadcast address for the network

Instructor Guide
Instructor Notes:
Purpose Introduce the student to netstat -i and how it shows interface traffic and
configuration information.
Details netstat -i lists interfaces and traffic on those interfaces
The entry for the actual interface is important. The Ierrors (input errors) and the Oerrors
(output errors) are important. If either is high (over 100), it could mean a saturated network
or a bad cable between the adapter and the network. We see this again in more detail in
the troubleshooting section.
The address ::1 is the IPv6 loopback address. The link# entries indicate the interfaces'
numbers and give their MAC addresses.
Additional Information The collisions column is not used in AIX and thus in
meaningless. Refer to previous information for ifconfig.
Transition Statement netstat/ifconfig provide information about the interface. The
ping command is used to test if communications between systems are working.

V3.1.0.1
Instructor Guide
Uempty
Verifying Network Connectivity
Purpose: Indicates if a remote host can be reached
Example: # ping 10.19.98.1
PING (10.19.98.1): 56 data bytes

64 bytes from 10.19.98.1: icmp_seq=0 ttl=255 time=2 ms
<ctrl-c>
--- 10.19.98.1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2/2/2 ms
Figure 3-17. Verifying Network Connectivity AU079.1
Notes:
The ping command sends an ICMP ECHO_REQUEST to obtain an ICMP
ECHO_RESPONSE from a host or router. If the host is operational and on the network, it
responds to the echo.
The default is to continuously send echo requests until an interrupt is received with <ctrl-c>,
but there is an option (-c) to specify the number of packets sent. The ping command sends
one datagram per second and prints one line of output for every response received. It
calculates round trip times and packet loss statistics, and displays a brief summary upon
completion.
Because of the load continuous echo requests can place on the system, repeated requests
should be used primarily for problem isolation.
The ping command is useful for:
Determining status of networks and hosts
Tracking and isolating hardware and software problems
Testing, measuring, and managing networks

Instructor Guide
Instructor Notes:
Purpose Explain how the ping command helps test and debug networks.
Details ping - protocol internet groper
How it works: sends packet and is echoed back
Successful return means successful configuration of both systems.
Can be used with host names as well.
It is a very simple command but provides very valuable insight into the network and is
useful for beginning problem determination.
We spend more time on ping and some of its options in the troubleshooting topic later in
the week.
Additional Information The TTL is different for other operating systems. All UNIX
systems use a TTL of 255, but operating systems like VM or DOS may use a different
value.
Transition Statement The next thing you might want to do is test name resolution to be
sure it is working properly. The host command can be used to do this.

V3.1.0.1
Instructor Guide
Uempty
Verifying Name Resolution
Purpose: Resolves a host name into an Internet
address or vice versa
Example: # host sys3

host sys3 is 10.19.98.3
or
# host 10.19.98.3
host sys3 is 10.19.98.3
Figure 3-18. Verifying Name Resolution AU079.1
Notes:
The host command returns a host name and IP address.
The host command searches through the /etc/hosts file and finds the first match of the
parameter specified with the command. If any aliases are associated with the parameter,
they too will be displayed.
When using the host command to verify name and address resolution, be sure that host
<system name> and host <ip address> return consistent information.

Instructor Guide
Instructor Notes:
Purpose Explain the use of the host command.
Details Tests the name resolution method of the system by searching the /etc/hosts
file. Good way to check name resolution and reverse name resolution.
Additional Information DNS is covered later in the week. Try to defer questions on
nameservers for later. Realize the nslookup command can do name resolution, but only
use DNS. This could cause problems when using nslookup for researching names/IP
addresses on a flat network.
Transition Statement One other item you may wish to check on is address resolution.
The arp command can be used to do this.

V3.1.0.1
Instructor Guide
Uempty
Verifying Address Resolution
Purpose: Display and modify address resolution
Example: # arp -a
rntsns.ibm.com (10.180.108.5) at 0:50:4:d1:2a:a2 [ethernet] stored in bucket 2

us9.ibm.com (10.180.108.32) at 0:4:ac:de:2b:12 [ethernet] stored in bucket 4
printstev.ibm.com (10.180.108.90) at 0:6:29:5:50:56 [ethernet] stored in bucket 12
lntw1019.ibm.com (10.180.109.10) at 0:4:ac:38:cd:f1 [ethernet] stored in bucket 13
us7.ibm.com (10.180.108.17) at 8:0:5a:fc:df:36 [ethernet] stored in bucket 14
lntw1064.ibm.com (10.180.110.80) at 0:50:da:72:e1:42 [ethernet] stored in bucket 14
us2.ibm.com (10.180.108.119) at 8:0:5a:93:b2:c6 [ethernet] stored in bucket 16
bucket: 0 contains: 0 entries
............etc........................
There are 7 entries in the arp table.
Figure 3-19. Verifying Address Resolution AU079.1
Notes:
Dynamic entries are added during the course of normal IP traffic on a physical network.
Infrequently used mappings added in this fashion have a short lifetime in the ARP table.
After 20 minutes (by default) without reference to the entry, it is then purged from the table.
Entries that are never answered are purged from the table after three minutes.
Permanent entries are loaded into the ARP table once at boot time and are useful if a host
must communicate with a node that cannot respond to an ARP request during some part of
its startup procedure (for example, diskless).

Instructor Guide
Instructor Notes:
Purpose Discuss the output of the arp command.
Details The arp table shows the names, IP addresses, and physical addresses of
systems that have been recently contacted. This is the internet-to-adapter address
translation table used by the Address Resolution Protocol (ARP).
-a displays all the current ARP entries.
-d deletes any entry. You must have root authority to execute arp. It may be necessary to
delete entries. For example, when a system's Ethernet card is changed because it went
bad, the ARP table's physical address no longer agrees. If it hasn't been 20 minutes since
trying to access the system it may not have been purged for you.
-n suppresses name resolution in the arp cache.
For entries like Xstation and diskless, a permanent entry is listed because these systems
can't respond to an ARP request at certain times during system startup.
The default time-out for an entry in the arp cache can be changed using the no command.
Additional Information Gratuitous ARP provides the following two features:
If the hardware address for an IP Address changes, all other hosts on the cable that has
an ARP entry with the old hardware address update their entry with the new hardware
address
When assigning an IP Address to an interface, it is possible to detect if another host is
already configured with the same IP Address
Transition Statement Now you have the system communicating, let's see what
services we are offering to the world.

V3.1.0.1
Instructor Guide
Uempty
Verifying Open Ports
Purpose: Display Open TCP/IP Application Ports
Example: # netstat -a -f inet
Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:www *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 *:printer *:* LISTEN
tcp 0 0 *:auth *:* LISTEN
tcp 0 0 *:finger *:* LISTEN
tcp 0 0 *:exec *:* LISTEN
tcp 0 0 *:login *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
Figure 3-20. Verifying Open Ports AU079.1
Notes: The last thing you might want to verify is what services you are offering to the
outside world. Remember: Every server service you are running requires a specific,
well-known port.
The netstat -a -f inet command lists all open UDP and TCP ports, both the server ports
(which are in the LISTEN state), and any client connections to or from any port (which are
in the ESTABLISHED state).
The above example shows a subset of open TCP ports.

Instructor Guide
Instructor Notes:
Purpose Cover the netstat -a -f inet command.
Details
Additional Information Explain that listing open ports is important as they are often
used as a point of attack from hackers.
Transition Statement That's it. Let's do the checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint
1. What is a good first command to use to test if two hosts are
talking to each other on a network?
2. What command can you use to test for proper name resolution,
both name to address and address to name?
3. What command displays what is in your arp cache?
4. What command shows the network status including input and
output packets transmitted on a network interface?
5. What files need to be set up correctly in order for any user to have
access to telnet services?
Notes:

Instructor Guide
Instructor Notes:
Purpose Present the checkpoint questions.
Details
1. What is a good first command to use to test if two hosts are talking
to each other on a network? ping
both name to address and address to name? host
3. What command displays what is in your arp cache? arp -a
output packets transmitted on a network interface? netstat -i
access to telnet services? /etc/services,/etc/inetd.conf and
/etc/rc.tcpip
Transition Statement Lets move onto the exercise.

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Exercise 3
Figure 3-22. Exercise AU079.1
Notes:

Instructor Guide
Instructor Notes:
Details
Transition Statement Lets review some of the key points we covered in this unit.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
Only one SMIT screen is required to configure TCP/IP - Minimum
Configuration and Startup
Several files are used by TCP/IP - /etc/rc.net, /etc/rc.tcpip,
/etc/services, /etc/inetd.conf, /etc/hosts
ifconfig, hostname, ping, netstat, arp, and host are commands
used in configuring or testing TCP/IP
TCP/IP services can be controlled using the System Resource
Manager commands
Notes:

Instructor Guide
Instructor Notes:
Purpose Review some of the key points covered in this unit.
Details
Transition Statement Thats the end of this unit.

V3.1.0.1
Instructor Guide
Uempty Unit 4. Configuring Virtual Ethernet

This unit discusses AIX 5L support for the virtual Ethernet adapters, a
feature of the POWER5-based server family. We introduce the
concept of virtual I/O and then focus on how to configure and use
virtual Ethernet adapters. We will also discuss IEEE 802.1Q, the
virtual LAN (VLAN) standard: how it is used with virtual Ethernet
adapters and AIX 5L support for VLAN.

Discuss IEEE 802.1Q (VLAN) concepts and terminology
Discuss AIX 5L support for VLAN
Describe basic virtual I/O features available on POWER5-based
servers
Describe the functions of the virtual hypervisor Ethernet switch
Configure and use a virtual Ethernet adapter

Accountability:
Checkpoint
Machine exercises
References
IBM Training course:
AU73 Logical Partitioning (LPAR) on POWER5 pSeries
Systems
http://www-03.ibm.com/servers/aix/whitepapers/aix_vn.pdf
Virtual Networking on AIX 5L (whitepaper)
http://www.redbooks.ibm.com/
Advanced POWER Virtualization on
IBM Eserver p5 Servers:
Introduction and Basic Configuration
Copyright IBM Corp. 1997, 2006 Unit 4. Configuring Virtual Ethernet 4-1
Instructor Guide
Architecture and Performance Considerations

V3.1.0.1
Instructor Guide
Uempty
Unit Objectives
Discuss IEEE 802.1Q (VLAN) concepts and terminology
Discuss AIX 5L support for VLAN
Describe basic virtual I/O features available on POWER5-based
servers
Describe the functions of the virtual hypervisor Ethernet switch
Configure and use a virtual Ethernet adapter
Notes:
Instructor Guide
Instructor Notes:
Purpose Students are introduced to the protocols involved in implementing virtual
Ethernet, or VLAN, and how to configure VLAN connections between partitions on the
same managed system.
Details We start with an introduction to IEEE 802.1Q, which could be using a physical
switch or the hypervisor switch. Then we discuss AIX support for 802.1Q. Next, we
introduce virtual I/O. Once weve laid that ground work, we then discuss virtual Ethernet
and explain how 802.1Q is used with virtual Ethernet.
Transition Statement Well start with a general discussion of IEEE 802.1Q.

V3.1.0.1
Instructor Guide
Uempty
IEEE 802.1Q VLAN (1 of 2)
VLAN is a method to logically segment a physical network
Layer 2 connectivity restricted to members of the same VLAN
VID = VLAN ID - Identifies a VLAN

PVID = Port VLAN ID - Default VID of a port
H1 H2 H3 H4
VLAN VLAN VLAN VLAN
Aware Unaware Unaware Aware
host host host host
ent1
ent1 ent2
ent0 ent0
ent0 ent0
Trunk
S1 S2
PVID 1
Tagged Untagged VID 20 Untagged Tagged
PVID 1 PVID 10 PVID 20 PVID 1
VID 10, 20 VID 20
Figure 4-2. IEEE 802.1Q VLAN (1 of 2) AU079.1
Notes:
Introduction
Virtual Local Area Network (VLAN) is described by the IEEE 802.1Q standard. VLAN is
a method to logically segment a physical network such that layer 2 connectivity is
restricted to members that belong to the same VLAN. This separation is achieved by
tagging Ethernet packets with their VLAN membership information and then restricting
delivery to members of that VLAN.
In the visual shown above, Ethernet Switches S1 and S2 share VLAN 20 through
tagged trunk ports. Hosts H1, H2 share network VLAN 10. Hosts H1, H3 and H4 share
network VLAN 20.
Instructor Guide
Instructor Notes:
Purpose Introduce IEEE 802.1Q virtual LAN.
Details The virtual Ethernet on POWER5 systems is based on an implementation of
IEEE 802.1Q VLAN. We introduce it here as a background technology before explaining
how virtual Ethernet is implemented on the IBM system p5 systems.
Define what it means to be VLAN aware.
The example in the visual shows that H1 has two VLAN ports labeled ent1 and ent2 and
they use the physical device ent0. On H4, ent1 is a VLAN device using the physical device
ent0.
Explain the difference between a VID and a PVID. The PVID is the default VID used for
untagged packets.
Explain that hosts on a particular VLAN recognize the packets for that VLAN.
The switches in this example must be VLAN aware.
Transition Statement Lets examine the terminology used when describing VLAN
configurations.

V3.1.0.1
Instructor Guide
Uempty
IEEE 802.1Q VLAN (2 of 2)
Method:
Outgoing packets:
VLAN aware host: Packets are tagged with VID by host
VLAN unaware host: Packets are tagged with the PVID by the switch
Incoming packets:
Switch strips the PVID from packets before sending to the host
adapter (VLAN unaware host is protected from tagged packets - which
it won't understand)
If VIDs are associated with the switch port, they remain in the packet
when sent to the host (VLAN aware host will handle these)
Recommendation:
Single network per adapter use untagged port and PVID
Multiple networks per adapter use VID
AIX support:
AIX supports both VLAN aware and unaware adapters
Normal Ethernet adapters are VLAN unaware.
VLAN logical device - which is VLAN aware.
The VLAN device is a logical device that sits on top of a base adapter.
Figure 4-3. IEEE 802.1Q VLAN (2 of 2) AU079.1
Notes:
IEEE 802.1Q Ethernet packets

The VLAN tag information is referred to as a VLAN ID (VID). To implement 802.1Q,
each Ethernet packet is tagged with the VID. That is an additional field is added to the
Ethernet header. This is the VLAN ID, which identifies the VLAN for this packet.
Terminology
Ports on a switch are configured as being members of the VLAN designated by the VID
for that port. The default VID for a port is referred to as the Port VID (PVID).
Method
The VID can be added to an Ethernet packet either by a VLAN aware host or by the
switch in the case of VLAN unaware hosts. Therefore, ports on an Ethernet switch have
Instructor Guide
to be configured with information indicating whether the host connected is VLAN aware
or unaware.
For VLAN unaware hosts, a port is set up as untagged and the switch will tag all
packets entering through that port with the Port VLAN ID (PVID). It also untags all
packets exiting that port before delivery to the VLAN unaware host. A port used to
connect VLAN unaware hosts is called an untagged port, and it can only be a member
of a single VLAN identified by its PVID.
Hosts that are VLAN aware can insert and remove their own tags and can be members
of more than one VLAN. These hosts are typically attached to ports that do not remove
the tags before delivering the packets to the host, but inserts the PVID tag when an
untagged packet enters the port. A port only allows packets that are untagged or tagged
with the tag of one of the VLANs the port belongs to.
These VLAN rules are in addition to the regular MAC address based forwarding rules
followed by a switch. Therefore, a packet with a broadcast or multicast destination MAC
also gets delivered to member ports that belong to the VLAN that is identified by the
tags in the packet. This mechanism ensures the logical separation of physical network
based on membership in a VLAN.
Recommendation
In general, configuration is simpler when ports are untagged and only the PVID is
configured because the attached hosts do not have to be VLAN aware and they do not
require any VLAN configuration.
However, this scenario has the limitation that a host can access only a single network
using a single adapter. Additional VIDs can be used when multiple networks are being
accessed through a single Ethernet adapter.
There are several reasons you might want to access multiple networks through one
adapter:
- Physical limitation on the number of adapters or switch ports
- You might want different types of traffic to use different Quality of Server (QoS)
rules. You can use VLANs to separate the different types of traffic and then define
QoS rules for each network.
AIX support
AIX supports both VLAN aware and VLAN unaware adapters.
- VLAN unaware
Normal Ethernet adapters are VLAN unaware.
- VLAN aware
AIX provides VAN support by implementing VLAN logical devices. You can configure
multiple VLAN devices on a single system. Each VLAN device constitutes an

V3.1.0.1
Instructor Guide
Uempty additional Ethernet adapter instance and is associated with a base Ethernet adapter.
Each VLAN device is assigned a VLAN ID and can be configured with an IP
address. An example is shown on the next page.
Instructor Guide
Instructor Notes:
Purpose Describe how packets are tagged when on a VLAN.
Details Untagged packets use the PVID. A VLAN aware host uses its assigned VLAN.
Transition Statement Lets look at a simple VLAN scenario to illustrate these concepts.

V3.1.0.1
Instructor Guide
Uempty
Simple VLAN Scenario
HOST 1 HOST 2 HOST 3
en1
10.4.10.100
ent1 (VLAN) en0 en0 en0 en1

VID 10 10.0.1.100 10.0.1.101 10.0.1.102 10.4.10.102
ent0 ent0 ent0 ent1
PVID = 1 Ethernet PVID = 1 PVID = 1 PVID = 10

VID = 10
Switch
VLAN 1
VLAN 10
Figure 4-4. Simple VLAN Scenario AU079.1
Notes:
Example
In the example shown in the visual above, there are two VLANs in use. HOST1, HOST2
and HOST3 are connected together on VLAN 1.
VLAN 1
HOST2 and HOST3 access VLAN 1 using Ethernet adapters (ent0) that are VAN
unaware. The switch ports are configured with a PVID of 1, and no additional VLAN IDs.
HOST1 accesses VLAN 1 with a Ethernet adapter (ent0) that is also VLAN unaware
and is connected to a port with a PVID of 1. The interface en0 is configured on this
device. Packets sent out on the interface en0 will be tagged with VLAN ID 1.
Instructor Guide
VLAN 10
HOST1 and HOST3 are also connected to VLAN 10. HOST3 accesses this VLAN using
an Ethernet adapter (ent1) that is VLAN unaware and is connected to a switch port
configured with a PVID of 10, and no additional VLAN IDs. HOST3 has configured the
interface en1 for this device.
HOST1 accesses VLAN 10 using a VLAN device (ent1) that is associated with the
Ethernet adapter ent0. The switch port connected to Ethernet adapter ent0 is
configured with a PVID of 1, but is also configured with a VLAN ID of 10. The VLAN
device ent1 is configured with a VLAN Tag ID of 10. The interface en1 is configured on
the VLAN device. This allows HOST1 to access VLAN 10.

V3.1.0.1
Instructor Guide

Purpose Show a simple implementation of VLAN access.
Details The visual shows how a VLAN device is required to be associated to a Ethernet
adapter if you wish to use the adapter to access multiple VLAN IDs. We are laying the
ground work for an understanding of VLAN with virtual Ethernet adapters. So far, we are
discussing VLAN in general. VLAN could be used with physical adapters connected to a
physical switch OR it could be used with virtual Ethernet adapters connected to the
hypervisor Ethernet switch - which we will discuss in a few pages.
Compare how HOST1 and HOST3 access both VLANs. HOST3 uses two Ethernet
adapters, however HOST1 uses a single adapter that has a VLAN device associated with it
to provide the interface (en1) that is used to access VLAN 10.
Transition Statement Lets take a look at how you would create a VLAN device in AIX.
Instructor Guide
Adding VLAN Access (1 of 2)

Configure VLAN adapters in AIX
smitty addvlan
Select VLAN base adapter
Enter VLAN ID
Add A VLAN

[Entry Fields]
VLAN Base Adapter ent0
* VLAN Tag ID [] #

Figure 4-5. Adding VLAN Access (1 of 2) AU079.1
Notes:
Adding the VLAN device

The easiest way to add a VLAN device is using the smit command, with the addvlan
fastpath. This starts the dialog shown in the visual above. The menu allows you to
select the adapter that the VLAN device is associated with, and also specifies the VLAN
Tag ID that will be added to packets that are sent out on the interface configured on the
VLAN device. Once you have made appropriate selections, press the Enter key. This
creates the VLAN device (entN), and its associated interfaces (enN and etN).

V3.1.0.1
Instructor Guide

Purpose Show how to configure a VLAN device.
Details Add one VLAN device for each VLAN ID. The next visual shows the results
when you list the devices in AIX 5L.
Transition Statement How does a VLAN device show up under AIX?
Instructor Guide
Adding VLAN Access (2 of 2)

Adding VLAN access adds VLAN device to system
VLAN device appears as Ethernet adapter (entN) with associated enN
and etN interfaces
Configure interfaces as desired for access to VLAN
# lsdev -C | grep '^e'
en0 Available 03-08 Standard Ethernet Network Interface
en1 Defined Standard Ethernet Network Interface
en2 Defined Standard Ethernet Network Interface
ent0 Available 03-08 10/100 Mbps Ethernet PCI Adapter II (1410ff01)
ent1 Available Virtual I/O Ethernet Adapter (l-lan)
ent2 Available VLAN
et0 Defined 03-08 IEEE 802.3 Ethernet Network Interface
et1 Defined IEEE 802.3 Ethernet Network Interface
et2 Defined IEEE 802.3 Ethernet Network Interface
# lsattr -El ent2

base_adapter ent0 VLAN Base Adapter True
vlan_tag_id 10 VLAN Tag ID True
Figure 4-6. Adding VLAN Access (2 of 2) AU079.1
Notes:
VLAN device
The VLAN device appears as an Ethernet device (ent2 in the visual above), with an
associated pair of interfaces (en2 and et2 in the visual above). The interfaces can be
configured just like the ones on a regular physical Ethernet adapter.
Note that the VLAN device is associated with a base device (ent0 in this example).
All packets leaving the machine on the configured interface are tagged with the VLAN
ID.

V3.1.0.1
Instructor Guide

Purpose Show how a VLAN device appears to AIX.
Details The example shows only one VLAN device. You have to add one VLAN device
to a virtual adapter for each VLAN ID that it wishes to access.
Transition Statement Now that weve introduced VLAN concepts, lets take a look at
virtual Ethernet. Well start by discussing virtual I/O in general and then focus in on virtual
Ethernet.
Instructor Guide
What is Virtual I/O?

Sharing physical resources (adapters) between partitions
Virtual I/O is available on IBM System p5 systems
Terminology:
Virtual SCSI
Virtual SCSI client
Virtual SCSI server (has the physical backing storage)
Virtual Networking
Virtual Ethernet adapter
Shared Ethernet adapter
Figure 4-7. What is Virtual I/O? AU079.1
Notes:
Introduction
Virtual I/O is the term used to describe the ability to share physical I/O resources
between partitions. The physical resources being shared are adapter cards located in
PCI-X slots of the managed system.
Terminology
Virtual I/O has its own set of terminology to describe the major components.
Virtual networking
This unit discusses creating and using virtual Ethernet adapters. Shared Ethernet
adapters are discussed in a later unit.
Virtual SCSI is not discussed in this class.

V3.1.0.1
Instructor Guide

Purpose Describe in high-level terms what virtual I/O is all about, and introduce some of
the terminology that we will be using.
Details We describe the terms introduced here throughout the remainder of this unit.
Transition Statement Why would we want to virtualize I/O?
Instructor Guide
Why Virtualize I/O?

Driven by cost and partitioning
Cost
Virtual I/O allows multiple partitions to share expensive I/O resources
Examples:
One partition may not need an entire 36GB disk
One partition may not need all the bandwidth of a Gigabit Ethernet adapter
Partitioning
Hardware supports more partitions than PCI slots
Slots become limiting factor
Minimum partition requirements
1 slot for boot disk (typically SCSI or Fibre Channel)
1 slot for Ethernet adapter
POWER5 Architecture supports up to 254 partitions
Figure 4-8. Why Virtualize I/O? AU079.1
Notes:
Introduction
Why would we want to virtualize I/O? The requirement is being driven primarily by
partitioning capabilities. The POWER5 systems are capable of being configured with
many more partitions than the previous POWER4 systems. The POWER5 architecture
supports up to 254 partitions. With large numbers of processors being supported, and
each processor capable of supporting up to ten Micro-Partitions, a system can soon run
out of available adapter slots.
Each partition that is created has a minimum requirement of two adapter slots. One slot
is required for use to connect to a boot device of some form (typically either SCSI or
Fibre Channel disk drives), and a second slot is required for an Ethernet adapter for
network access. A network adapter may or may not be required for users to access the
partition, however it is required for the HMC to communicate with the partition for
DLPAR and serviceable event functions.

V3.1.0.1
Instructor Guide
Uempty With this minimum two-adapter requirement, the number of slots on a machine would
be a limiting factor in the number of partitions that could be run concurrently, unless the
I/O subsystem could be virtualized to some degree.
Limitation example
As an example, the p5-570 system supports up to 16 POWER5 processors. If
configured with the Advanced POWER Virtualization feature, this system is capable of
running up to 160 partitions concurrently. However, the machine supports a maximum
of 160 PCI-X adapter slots, so with a two slots per partition minimum, the maximum
number of partitions that could be created without the use of virtual I/O would be 80.
Instructor Guide
Instructor Notes:
Purpose Explain the drivers for virtualizing the I/O capabilities.
Details Current systems support up to 160 Micro-Partitions running concurrently. Future
systems support up to the 254 partition limit.
Transition Statement What are some of the benefits of virtual I/O?

V3.1.0.1
Instructor Guide
Uempty
Benefits of Virtualized I/O
Partitions can be created without requiring additional physical I/O
resources
Economical I/O model
Efficient utilization of resources through sharing
Facilitates server consolidation
Allows client attachment to previously unsupported storage
solutions
Figure 4-9. Benefits of Virtualized I/O AU079.1
Notes:
Introduction
The main benefits of virtualized I/O are:
- Partitions can be created without requiring additional physical I/O resources. The
new partitions can be configured to use virtualized I/O resources, which allows them
to be configured in a timely manner, since no physical reconfiguration of the system
(that is, moving adapter cards and cables) is required.
- Virtualized I/O allows an economical I/O model, since it allows multiple partitions to
share common resources. For example, multiple partitions can share a single
physical adapter. Without virtualized I/O, each partition would require its own
adapter, even if the full capacity of the adapter was not being utilized.
- The use of virtualized I/O facilitates server consolidation. It permits multiple client
partitions to reside on a single machine, and make efficient use of shared resources.
Instructor Guide
- The use of virtualized I/O may permit partitions to use (through a virtualized I/O
interface) a type of physical device that is not supported for native connection to the
partition. For example, a client partition would be able to make use of a virtual SCSI
disk that was being provided by the Virtual I/O Server partition, even if the physical
device attached to the server partition is not supported by the operating system
running in the client partition.

V3.1.0.1
Instructor Guide

Purpose Describe the main benefits of virtualized I/O.
Details Discuss the importance of having virtualized I/O to support large numbers of
partitions.
Transition Statement Now that weve introduced virtual I/O, lets look at virtual
Ethernet. Well start with the big picture of virtual Ethernet.
Instructor Guide
IBM System p5 Virtual Ethernet Overview

Enables inter-partition communication without the need for physical
network adapters assigned to each partition
Adapters are virtual and if communication is only between partitions
on same managed system, no physical Ethernet adapter is needed
Logical partitions can have virtual Ethernet adapters, physical
Ethernet adapters or a mix of both
Requires a POWER5 system and HMC for configuration
Does not require the purchase of any additional features or software
such as the Advanced POWER Virtualization Feature
Figure 4-10. IBM System p5 VIrtual Ethernet Overview AU079.1
Notes:
Introduction
Virtual Ethernet enables inter-partition communication without the need for physical
network adapters assigned to each partition. This technology enables IP-based
communication between logical partitions on the same system using a VLAN capable
software switch (POWER Hypervisor) in POWER5 systems. Due to the number of
partitions possible on many systems being greater than the number of I/O slots, virtual
Ethernet is a convenient and cost saving option to enable partitions within a single system
to communicate with one another through a virtual Ethernet LAN.
The virtual Ethernet interfaces may be configured with both IPv4 and IPv6 protocols.
No additional purchase required

The virtual Ethernet capability is not part of the Advanced POWER Virtualization feature.
Virtual Ethernet is different from shared Ethernet adapter in that, there is no connection to a

V3.1.0.1
Instructor Guide
Uempty physical Ethernet adapter which connects to a physical Ethernet network. To use virtual
Ethernet to connect to a physical Ethernet adapter which connects to a physical Ethernet
network, you must configure a shared Ethernet adapter. This will be discussed in a later
unit.
Instructor Guide
Instructor Notes:
Purpose Describe virtual Ethernet in an LPAR environment.
Details Describe the basics of virtual Ethernet. Remind the students that there is no
extra software to install to make this work and you do not need a Virtual I/O Server.
Transition Statement Lets look at a conceptual diagram.

V3.1.0.1
Instructor Guide
Uempty
Virtual Ethernet
Allows partitions to communicate without using a physical Ethernet
adapter
4 2 6 6 CPUs
CPUs CPUs CPUs
I/O Server
Partition
Linux AIX5.3 AIX5.3
AIX 5.3
AIX 5.3
AIX 5.3
Linux
Linux
Virtual I/O paths
POWER Hypervisor
I/O I/O I/O I/O
Storage Network Storage Network Storage Network Storage Network
Figure 4-11. Virtual Ethernet AU079.1
Notes:
Introduction
Virtual Ethernet technology is supported on AIX 5L V5.3 on POWER5 hardware. This
technology enables IP-based communication between logical partitions on the same
system using a VLAN capable software switch in POWER5 systems.
Virtual and physical adapters

Logical partitions can use either physical Thornier adapters or virtual Ethernet adapters
or a mix of both.
Instructor Guide
Instructor Notes:
Purpose Introduce virtual Ethernet on POWER5 systems.
Details The visual shows the VLAN connections between partitions within a single
managed system. The POWER Hypervisor is the switch for these VLANs. The visual
shows a simplified picture with one to one connections. In reality, VLANs can have many
hosts and each partition can belong to many VLANs.
Also note that LPARs can use both physical and Virtual adapters.
Transition Statement Lets look at some of the underlying technologies that are used to
implement virtual Ethernet.

V3.1.0.1
Instructor Guide
Uempty
p5 Hypervisor Ethernet Switch
Software Ethernet switch implementation
Consistent with IEEE 802.1Q
Up to 4094 networks (VLAN IDs)
PVID tag for untagged packets
Copies packets between partitions
Included with all IBM System p5 systems
Does not require Advanced POWER Virtualization feature
Figure 4-12. p5 Hypervisor Ethernet Switch AU079.1
Notes:
Introduction
POWER5 hardware supports inter-LPAR communication using virtual networking. The
POWER Hypervisor on POWER5 systems supports virtual Ethernet adapters that are
connected to an IEEE 802.1Q (VLAN) style virtual Ethernet switch. Using this switch
function, partitions can communicate with each other by using virtual Ethernet adapters
and assigning VIDs (VLAN ID) that enable them to share a common logical network.
The switch supports up to 4094 VLAN IDs.
The virtual Ethernet adapters are created and the VID assignments are performed
using the Hardware Management Console (HMC). The system allows virtual Ethernet
adapters to be configured with a PVID, that will be used to tag untagged packets.
The POWER Hypervisor transmits packets by copying the packet directly from the
memory of the sender partition to the receive buffers of the receiver partition without
any intermediate buffering of the packet.
Instructor Guide
The POWER Hypervisor Ethernet switch function is included as standard in all

POWER5 systems. It does not require the purchase of the Advanced POWER
Virtualization feature.

V3.1.0.1
Instructor Guide

Purpose Describe the features of the POWER Hypervisor Ethernet switch.
Details When using virtual Ethernet on an IBM System p5 system, the Hypervisor acts
as the Ethernet switch.
The configuration of virtual Ethernet on IBM system p5 systems does not require you to
activate the Advanced POWER Virtualization feature.
Additional Information The hypervisor switch also supports Etherchannel. It is
supported only in backup adapter mode to enables the clients to re-direct traffic to another
VIOS in case of failure. See Unit 7 for more detail on this.
Transition Statement How does a partition use a virtual Ethernet connection? Virtual
Ethernet adapters.
Instructor Guide
Virtual Ethernet Adapters

Virtual Ethernet adapters are required to access the Hypervisor
Ethernet switch
Created in partition virtual slots using HMC
HMC generates MAC address
Local bit to prevent conflict with physical Ethernet
Based on machine serial number for uniqueness
Access to 21 VLAN (VID) networks per adapter
Packets copied between partitions
LPAR1 LPAR2 LPAR3 LPAR4 LPAR5
VLAN 100 VLAN 200
VLAN 300
POWER Hypervisor (switch)
Figure 4-13. Virtual Ethernet Adapters AU079.1
Notes:
Introduction
A partition needs to use virtual Ethernet adapters to communicate with the Hypervisor
Ethernet switch. The virtual Ethernet adapters are created and the VID assignments are
performed using the Hardware Management Console (HMC). The system allows virtual
Ethernet adapters to be configured with a PVID, that will be used to tag untagged
packets.
By default, a partition may have up to 10 virtual adapter slots. Two of these slots are
used by default for virtual serial adapters, which are used to implement the virtual
console facility. The number of virtual adapters in a partition may be increased as
needed up to 256.

V3.1.0.1
Instructor Guide
Uempty MAC Address

The HMC generates a locally administered Ethernet MAC address for the virtual
Ethernet adapters so that these addresses do not conflict with physical Ethernet
adapter MAC addresses. To ensure uniqueness among the virtual Ethernet adapters,
the address generation is based on the system serial number, LPAR ID and adapter ID.
VLAN Access
Besides a PVID, the number of additional VID values that can be assigned per virtual
Ethernet adapter is 20 which implies that each virtual Ethernet adapter can be used to
access 21 networks.
Packet Delivery
The packets are transmitted by copying them directly from the memory of the sending
partition to the receive buffers of the receiving partition without any intermediate
buffering of the packet.
Instructor Guide
Instructor Notes:
Purpose Introduce the concept of virtual Ethernet adapters.
Details You must create a virtual Ethernet adapter for each VLAN used by a partition.
Each virtual adapter that you create can connect to up to 20 VLANs. The next visual shows
how to create a virtual Ethernet adapter.
Transition Statement So, how do we create a virtual Ethernet adapter?

V3.1.0.1
Instructor Guide
Uempty
Creating a Virtual Ethernet Adapter (1 of 4)
Figure 4-14. Creating a Virtual Ethernet Adapter (1 of 4) AU079.1
Notes:
Introduction
virtual Ethernet adapters are created by using the HMC. The Virtual I/O tab of the
partition profile dialog box is used to create virtual adapters of differing types. By
default, a partition may have up to 10 virtual adapters. This number can be changed to
any value from 2 to 65536, but it requires the partition to be reactivated before the new
value is used.
The higher the maximum number is, the more memory the managed system reserves
to manage the virtual adapters, so specify only the number of virtual adapters you are
likely to use.
Modify the Partition Profile

To create a virtual Ethernet adapter, use the Server Management application on the
HMC. Highlight the partition profile that you wish to modify, right-click, and select
Instructor Guide
Properties from the pop-up menu. This starts the Profile Properties dialog. Select the
Virtual I/O tab to create a virtual Ethernet adapter. Once the tab is visible, select the
Ethernet radio-button on the Create Adapters panel, and then click the (Create...)
button.

V3.1.0.1
Instructor Guide

Purpose Describe the first step in configuring a virtual Ethernet adapter.
Details The students may not be familiar with the procedure to modify a partition profile.
Describe how you access the Virtual I/O tab, look at the maximum number of virtual
adapters to make sure you can create more, choose which type of adapter you wish to
create, then click on the Create button.
Describe how all of the virtual adapters that you create (Ethernet or SCSI) will appear in the
white area and can be deleted by selecting them and clicking the Delete button. Their
configuration can be modified by selecting the adapter and clicking the Properties button.
The next page shows the pop-up when you select Ethernet adapter and click the Create
button.
Additional Information This visual and then next two visuals show screens from HMC
4.5. In HMC 5, the screens for virtual I/O change. See Figure 4-19., Multiple VLANs on a
Virtual Ethernet Adapter on page 49 for an example. You should probably discuss this
change with the students and let them know which version of HMC they are using in the
exercises. The exercise instructions cover both 4.5 and 5.X. In any case, the screens are
pretty easy to understand once you know the concepts, so students should have no
problems.
Transition Statement Lets look at the configuration of the virtual Ethernet adapter
itself.
Instructor Guide
Notes:
Adapter properties
The adapter is created in the lowest numbered available virtual slot. The number can be
changed if desired, within the limits of the maximum number available for the partition.
You should enter the Port Virtual LAN ID that is used for this adapter. This is the ID of
the virtual LAN that you want the adapter to connect to. By default, each adapter can
connect to a single VLAN.
Once you have entered the PVID value, click the OK button to add the adapter.
The IEEE 802.1Q setting allows the adapter to be configured to access multiple VLANs.
The Trunk adapter setting should not be used for virtual Ethernet adapters in client
partitions. This setting is only for use by special virtual Ethernet adapters owned by the
Virtual I/O server partition.

V3.1.0.1
Instructor Guide

Purpose Describe how to configure the slot number and PVID of the virtual Ethernet
adapter.
Details For now, we cover how to configure a simple setup, where the virtual adapter
connects to only one VLAN. Later in the unit we cover the use of multiple VLANs, since this
requires extra steps when configuring the interface at the AIX operating system level.
Transition Statement Lets look at the virtual I/O adapters summary once weve
created the adapter.
Instructor Guide
Notes:
Introduction
Once the adapter has been created, it shows up in the Virtual I/O panel of the partition
profile. The adapter information shows the virtual slot the adapter is in, the type of the
adapter, and whether it is required or not. If the Required setting is checked, the virtual
adapter cannot be removed from the partition using a DLPAR remove operation. By
default, newly created adapters are not marked as Required.
Click the OK button once you have added the desired virtual adapters.

V3.1.0.1
Instructor Guide

Purpose Show the virtual I/O panel after the creation of a new adapter.
Details A virtual adapter listed in a partition profile is always present when the partition
is activated. The Required checkbox setting indicates if the adapter may be removed from
the partition by a DLPAR operation.
Transition Statement Lets examine what the adapter looks like to AIX.
Instructor Guide

Activate the partition using the modified profile
Adapter is visible to partition
# lsdev -Cc adapter

ent0 Available 03-08 10/100 Mbps Ethernet PCI Adapter II
ide0 Available 01-08 ATA/IDE Controller Device
sisscsia1 Available 05-08 PCI-X Dual Channel Ultra320 SCSI Adapter
vsa0 Available LPAR Virtual Serial Adapter
Interfaces available for configuration

Virtual interfaces do not have an AIX location code
+------------------------------------------------------------------------+
| Available Network Interfaces |
| |
| Move cursor to desired item and press Enter. |
| |
| en0 03-08 Standard Ethernet Network Interface |
| en1 Standard Ethernet Network Interface |
| et0 03-08 IEEE 802.3 Ethernet Network Interface |
| et1 IEEE 802.3 Ethernet Network Interface |
| |
| Esc+1=Help Esc+2=Refresh Esc+3=Cancel |
| Esc+8=Image Esc+0=Exit Enter=Do |
| /=Find n=Find Next |
+------------------------------------------------------------------------+
Notes:
Introduction
Once the virtual Ethernet adapter has been added, you should activate the partition
using the newly modified profile. The virtual Ethernet adapter is listed as an available
boot device if you enter the SMS menus.
AIX detects the presence of the newly added virtual Ethernet adapters, and adds
appropriate ODM device entries, for example ent1 as shown in the visual above. Since
the newly added device is an Ethernet adapter, the configure method for the adapter
also defines associated network interfaces, for example, en1 and et1 as shown in the
visual above.
Note that the virtual adapter instance and associated interfaces do not have AIX
location codes, since they are virtual devices.

V3.1.0.1
Instructor Guide

Purpose Illustrate how an AIX partition labels a virtual Ethernet adapter.
Details This visual shows how the adapter is viewed in AIX 5L.
The visual mentions that you must reactivate the partition. If you added the virtual adapter
dynamically, you can run cfgmgr and avoid having to reactivate the partition.
In the example in the visual, you would run smit tcpip and configure the en1 interface.
Transition Statement Lets look at some of the limitations and features of the virtual
Ethernet adapter implementation on AIX 5L V5.3.
Instructor Guide
AIX Virtual Ethernet

Up to 256 virtual Ethernet adapters per partition
Support for large MTUs (65280) on AIX
Supports both IPv4 and IPv6
Virtual Ethernet adapter with only a PVID is configured just like
physical Ethernet adapter
Virtual Ethernet adapter with multiple VIDs:
Configure a VLAN adapter for each additional VID
Figure 4-18. AIX Virtual Ethernet AU079.1
Notes:
AIX virtual Ethernet

Although a partition may have up to 65536 virtual adapter slots, the AIX 5L V5.3 virtual
Ethernet device driver is limited to controlling 256 virtual Ethernet devices. The virtual
Ethernet device driver supports large Maximum Transfer Units (MTU) of up to 65280
bytes. The virtual Ethernet interfaces may be configured with both IPv4 and IPv6
protocols.
A virtual Ethernet adapter configured with a single PVID acts just like a regular physical
Ethernet device. There are two interfaces, enX and etX, (Standard Ethernet and
IEEE802.3 respectively) available for each virtual Ethernet device entX.
A virtual Ethernet adapter that is connected to a VLAN that uses multiple VLAN IDs
must also be configured with one VLAN device per VLAN ID. A VLAN device appears to
be an additional Ethernet device (entN), with an associated pair of interfaces, enN and
etN. The VLAN device is associated with the virtual Ethernet device which is connected

V3.1.0.1
Instructor Guide
Uempty to the VLAN. The VLAN device is configured with the VLAN ID (tag) that is added to all
packets that are sent on the interface configured on the VLAN device (enN or etN).
Instructor Guide
Instructor Notes:
Purpose Describe limit on the number of virtual Ethernet adapters in a single partition.
Also introduce the concept of a VLAN device, which is used to access a VLAN which used
multiple VLAN IDs.
Details This visual lists more information about VLAN devices.
The use of virtual Ethernet adapters may affect system performance since it is a little more
CPU-intensive than using physical adapter cards. Physical adapter cards off load some of
the CPU work.
The speed of the virtual Ethernet communications varies from 1 Gbps to 3 Gbps depending
on the maximum transmission unit (MTU) size. The largest MTU size will result in the
fastest speed.
Transition Statement Lets look at how we configure a virtual Ethernet adapter to
access multiple VLANs.

V3.1.0.1
Instructor Guide
Uempty
Multiple VLANs on a Virtual Ethernet Adapter
1. Add VLAN information to virtual Ethernet adapter in HMC profile
2. Add VLAN adapters in AIX using virtual adapter as the base adapter
smitty addvlan
Figure 4-19. Multiple VLANs on a Virtual Ethernet Adapter AU079.1
Notes:
Add multiple VLANs to virtual adapter in HMC

A virtual Ethernet adapter must be configured appropriately to be able to access
multiple VLANs. Open the partition properties dialog window, and select the Virtual I/O
tab. Select the Ethernet adapter you wish to modify, and click the (Properties...) button.
This brings up the virtual Ethernet adapter Properties window, as shown in the visual
above.
In order to access multiple VLANs, the adapter must be configured as an IEEE 802.1Q
compatible adapter. Select the checkbox for this property. You can then add additional
VLAN IDs one at a time, up to a maximum of twenty. This allows a single virtual
Ethernet adapter to access 21 different Virtual LANs.
Once you have modified the adapter, click the OK button. This returns you to the
partition profile dialog. You should then click the OK button on that dialog. The
modifications to the adapter are not effective until the partition is reactivated.
Instructor Guide
Add VLAN devices in AIX using the virtual adapter as the base adapter
Once we have configured the virtual adapter for multiple VLANs, we then need to add
and configure one or more VLAN devices in AIX. See Adding VLAN Access (1 of 2) on
page 14 for details.

V3.1.0.1
Instructor Guide

Purpose Show how to configure a virtual Ethernet adapter to access multiple VLANs.
Details The visual shows what you would do if, after you set up one VLAN, you wish to
add additional VLANs. You need to check the IEEE 802.1 Q compatible adapter box and
then enter the VLAN IDs in the box. Then you need to add additional VLANs in AIX, which
was discussed earlier in Adding VLAN Access (1 of 2) on page 14.
Additional Information This visual shows an HMC 5.2 WebSM screen. As mentioned
in the instructor notes for Figure 4-14., Creating a Virtual Ethernet Adapter (1 of 4) on
page 37, the screens for virtual I/O changed in HMC 5.1 and later. You should probably
discuss with students. The exercises are written to cover both HMC 4.5 and 5.X screens.
Transition Statement Finally, lets look at a VLAN scenario using virtual Ethernet
adapters. This is essentially the same as using VLAN with physical adapters.
Instructor Guide
Virtual Ethernet VLAN Scenario
LPAR 1 LPAR 2 LPAR 3
en1
10.4.10.100
ent1 (VLAN) en0 en0 en0 en1

VID 10 10.0.1.100 10.0.1.101 10.0.1.102 10.4.10.102
ent0 (VETH) ent0 (VETH) ent0 (VETH) ent1(VETH)
PVID = 1 Hypervisor PVID = 1 PVID = 1 PVID = 10

VID = 10 Switch
VLAN 1
VLAN 10
Figure 4-20. Virtual Ethernet VLAN Scenario AU079.1
Notes:
Example
This example is basically the same as Simple VLAN Scenario on page 11. Except
here we are using virtual adapters and the hypervisor switch, instead of physical
adapters and a physical switch.

V3.1.0.1
Instructor Guide

Purpose Show a simple implementation of VLAN access.
Details The visual shows how a VLAN device is required to be associated to a virtual
Ethernet adapter if the adapter is configured to access multiple VLAN IDs. Compare how
LPAR1 and LPAR3 access both VLANs. LPAR3 uses two virtual Ethernet adapters,
however LPAR1 uses a single virtual adapter that has a VLAN device associated with it to
provide the interface (en1) that is used to access VLAN 10.
Additional Information Remind students that inter-partition virtual Ethernet access is
included with all POWER5 systems. We will discuss shared Ethernet adapters (SEA) in a
later unit. SEA requires the Virtual I/O Server, which is a part of the Advanced POWER
Hypervisor feature, which as available at additional cost.
Transition Statement That is the end of the VLAN topic. There are some Checkpoint
questions to review some of the concepts.
Instructor Guide
Checkpoint
1. T/F: To use Virtual Ethernet, you must order the Advanced
POWER Hypervisor feature.
2. T/F: AIX 5L 5.2 can be configured with Virtual Ethernet.
3. T/F: Virtual Ethernet supports both IPv4 and IPv6 environments.
4. T/F: When listing devices with lsdev it is easy to see which are
physical Ethernet devices, which are virtual and which are VLAN
devices.
5. The PVID for a virtual Ethernet adapter is configured in the
_____________.
6. To use multiple VIDs with a virtual Ethernet adapter, the VIDs must
be defined in the _____________________ and in the
_________ in AIX.
7. Associate the term with its definition:
__ IEEE 802.1Q A. Identifies a virtual LAN
__ VID B. Virtual LAN standard
__ PVID C. Default VID associated with a switch port
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
POWER Hypervisor feature. False.
2. T/F: AIX 5L 5.2 can be configured with Virtual Ethernet. False.
True.
devices. True.
HMC partition profile.
be defined in the HMC partition profile and in the
VLAN adapter in AIX.
_B_ IEEE 802.1Q A. Identifies a virtual LAN
_A_ VID B. Virtual LAN standard
_C_ PVID C. Default VID associated with a switch port
Transition Statement
Instructor Guide
Exercise:
Configuring
Virtual
Ethernet
Figure 4-22. 21 Exercise AU079.1
Notes:

V3.1.0.1
Instructor Guide

Purpose Introduce the exercise.
Details
Transition Statement Lets summarize.
Instructor Guide
Unit Summary
IEEE 802.1Q (VLAN) provides for network traffic isolation at layer two within an
Ethernet switch
Additional VLAN ID (VID) field added to Ethernet packets identifies the VLAN
Port VID (PVID) is default VID for a switch port
Untagged packets from host are tagged with this VID
Tagged packets to a VLAN unaware host have the PVID tag stripped
Additional VIDs can be assigned to a switch port (for VLAN aware hosts)
AIX 5L supports 801.1Q (VLAN) through the creation of VLAN adapters:
VLAN adapter is associated with a base adapter
Base adapter can be a physical or a virtual Ethernet adapter
One VLAN ID per VLAN adapter; multiple VIDs can be supported by using
multiple VLAN adapters
The hypervisor in POWER5-based systems implements a virtual Ethernet switch
and supports virtual Ethernet adapters for communications between LPARs
The hypervisor switch copies packets directly from sending LPAR memory to
receiving LPAR memory, which provides for very fast transfers
Virtual Ethernet adapters are created in the partition profile in the HMC
Once reactivated, AIX 5L V5.3 detects these virtual adapters
Network interfaces are configured on virtual Ethernet adapters, just like a
physical adapter
The hypervisor switch supports 802.1Q
A PVID must be assigned when the virtual Ethernet adapter is created in the HMC
Additional VIDs can be associated with the virtual Ethernet adapter
Notes:

V3.1.0.1
Instructor Guide

Purpose Unit summary.
Details
Transition Statement Thats all folks.
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 5. Routing

This unit describes routing and how it works in AIX.

Describe the concept of routing
Explain the IP routing algorithm
List the types of routes in the route table
Configure static routes

Accountability:
Exercises
References
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp :
AIX 5L Version 5.3 System Management Guide:
http://www.redbooks.ibm.com/ :
AIX 5L Differences Guide
Version 5.3 Edition
Copyright IBM Corp. 1997, 2006 Unit 5. Routing 5-1

Instructor Guide
Unit Objectives
Describe the concept of routing

Explain the IP routing algorithm
List the types of routes in the route table
Configure static routes
Notes:

V3.1.0.1
Instructor Guide

Purpose To introduce routing concepts.
Details This unit is designed to introduce basic routing concepts and show students how
to configure static routes.
Additional Information One of the basic functions of IP is its ability to form connections
between different physical networks. The flexibility of IP creates a peer network with
systems defined as a host or gateway (router). The routing function is part of the IP layer,
but the primary function of a routing protocol is to exchange routing information with other
routers, and in this respect the protocols behave more like applications.
Transition Statement Let's begin our routing discussion by defining what it is and
discussing how it works.

Instructor Guide
Routing
Host A Host B
Application Host C acting Application

TCP as router/gateway TCP
IP IP Routing IP
Interface W Interface X Interface Y Interface Z
Network P Network Q
Figure 5-2. Routing AU079.1
Notes:
A route defines a path for sending packets through the Internet to an address on another
network. A route does not define the complete path, only the path from a host to a gateway
(router) that can then forward packets on to either the destination or to another gateway.
The term routing refers to the process of choosing a path over which to send packets, and
router refers to any computer making such a choice.
Routing is performed by the IP layer. IP routers are used to connect different networks. No
daemons are necessary to make routing occur on a host.
Message distance is usually expressed in the number of gateway hops or hop count (called
the metric).
The distance a message travels from originating host to destination host depends upon the
number of gateway hops it must make.
A host is zero hops from a network on which it is attached. It is one hop from a network that
can be reached by going through only one gateway.

V3.1.0.1
Instructor Guide

Purpose Explain the concept of routing.
Details Use the drawing to illustrate routing.
A route defines a path for sending packets through a network to an address on another
network.
Host A on network P wants to send information to Host B on network Q. Host C is acting as
the router. Host C has two interface cards, one connecting it to network P and the other to
network Q. Host A only knows about network P, so it can only send its messages to hosts
on network P. Because Host C has an interface on network P and Q, it can act as the
intermediary between Host A and B. Thus, messages destined for Host B are sent to Host
C, which routes the message from network P to network Q. A good example to use in real
life is flying somewhere. Very often you cannot get to the final desired destination without
being routed through different cities where you have to change planes.
Routing is performed at the Internet or IP layer.
Transition Statement Let's see what the specifications are for a system that functions
as a gateway.

Instructor Guide
Gateways for TCP/IP
Host C
if Routing if
Network P Network Q
x Table y
Attach two or more networks

Provide the routing function at the IP level
Determine the route of a packet by consulting a routing
table
Route packets according to the destination network
Have a network interface for each network with which
they communicate
Figure 5-3. Gateways for TCP/IP AU079.1
Notes:
Routers connect two or more networks and provide routing functions. The term gateway in
this context is used interchangeably with router.
Some routers route at the network interface level or the physical level.
Gateways route at the network level. Gateways receive IP datagrams from other gateways
for delivery to hosts on the local network and route IP datagrams from one network to
another. Gateways periodically verify their network connections through interface status
messages.
Gateways route packets according to the destination network. The destination network
then takes care of sending the packet to the destination host.

V3.1.0.1
Instructor Guide

Purpose Describe the characteristics of a gateway device.
Details Gateway and router are often used interchangeably. Most TCP/IP reading
materials refer to a gateway not a router. During this lecture, when you hear gateway think
of router as we discuss routing at the IP layer.
For a system to be a gateway, it must be running TCP/IP and have the five characteristics
as listed here.
Additional Information The routing done by IP, when it searches the routing table and
decides which interface to send a packet out, is a routing mechanism. This differs from
routing policy, which is a set of rules that decides which routes go into the routing table. IP
performs the routing mechanism while a routing daemon normally provides the routing
policy.
Transition Statement There are several types of routers and an order in which they are
searched. Let's see what they are.

Instructor Guide
Routing Implementation
10.19.99.17
subnet mask sys1
sys17
255.255.255.0 10.19.98.1
subnet mask
10.19.99.20 10.19.99.11 sys5
sys11 255.255.255.0
Internet sys20
sys11e 10.19.98.5
sys20e
152.64.10.1 10.19.98.11
sys13 sys10
10.19.99.13 10.19.98.10
destination deliver via

address gateway
Host Route 10.19.99.20 10.19.99.17 Direct Route
Network Route 10.19.99/24 10.19.99.17
10.19.98.10 10.19.99.11 Indirect Route
10.19.98/8 10.19.99.11
Default Route default 10.19.99.20
Figure 5-4. Routing Implementation AU079.1
Notes:
A route does not define the complete path. It defines only the path segment from one host
to a gateway that can forward packets to a destination, or from one gateway to another.
Routes are defined in the kernel routing table. Each routing table entry has two
components; destination address (where you want to end up) and gateway address (where
the packet gets sent on its way to its final destination).
TCP/IP searches the route table for a best fit match in the following order:
A host route defines a route to a specific host through a gateway. The routing IP
algorithm still sees a host address as a network; it is simply a perfect match.
A network route defines a route to any of the hosts on a specific network through a
gateway.
A default route defines a gateway to use when a host or network route to a destination
is not otherwise defined.
Hosts should not forward IP datagrams unless specifically configured as a router. Most
BSD-derived implementations (AIX) include a kernel variable called ipforwarding, which

V3.1.0.1
Instructor Guide
Uempty is used to control this behavior. The no command is used to view or change the value of
ipforwarding.
no -o ipforwarding
ipforwarding=0 (do not forward)
ipforwarding=1 (do forward)
To change it: no -o ipforwarding=value ,
where value is 0 or 1.

Instructor Guide
Instructor Notes:
Purpose Explain host, network, and default routes and demonstrate how a router works
using the networks in the foil.
Details Using the drawing, explain each type of route table entry. The route table
resides on sys17.
In evaluating the route table, priority is host entries, network entries, and then finally default
entry.
The first one is a host route. This means I can only talk to this particular host on the
specified network. Typically, host routes are not used. In this case, it is defining the IP
address for Host G.
The second entry is a network route. It is a direct route because sys17 is physically
connected to that network.
The third example is a default route. If it's not for my network, pass it to the router. Maybe
the router knows how to pass it on to get it to the final destination.
There can be multiple entries. The router takes the first match.
Additional Information If there is no default route and no match exists for a destination,
an error is returned to the application. This message is Cannot reach destination network.
Transition Statement We've only seen the destination or the where to go part of a
route. There needs to be information on how to get there, like a roadmap.
Discussion Items
How many networks are there? 3
Which hosts are routers? sys11, sys20
When are the direct route entries put in the routing table?
At configuration of the network adapter.
What host is the indirect route pointing to? sys11
What is the difference between the indirect route and the default route? If destination is
not one of the three networks listed, pass it on to sys20 and hope it can pass it on using
information stored in its routing table.
Transition Statement Since routing is done on every system in a network, let's see
what IP goes through to decide where to send a message.

V3.1.0.1
Instructor Guide
Uempty
IP Routing Algorithm
Consults
routing table
Y
Is it for me? Keep it Local Host
N
Is it for my Y Send using

network? arp table
Direct Attached Network Host
N
Do I have a Y Send to
Remote Host
specific
route?
router
Do I have a Y Send to Route to Default Gateway

default
route?
router
N
No route
to host
Figure 5-5. IP Routing Algorithm AU079.1
Notes:
Both hosts and gateways participate in IP routing. When an application program on a host
attempts to communicate with another host, one or more IP datagrams are generated. The
host must decide to which IP address the datagrams should go. This address may be to a
host on the same network or to another network.
Three types of routing table entries can be seen. They are:
Direct This occurs when both the source and destination hosts are on the same
physical network. The packets can be sent directly from the source to the destination.
Indirect This occurs when the source and destination hosts are on different physical
networks. The only way to reach the host is through one or more IP gateways. The
address of the first of these gateways (the first hop) is the only information needed by
the source host.
Default This is to be used if the destination IP network address is not found in the
direct or indirect entries.
The IP routing mechanism only considers the IP network address part of the destination
address.

Instructor Guide
Instructor Notes:
Purpose Show students how IP routes.
Details Every system has to process outgoing IP datagrams through the IP routing
algorithm. This algorithm decides:
On which physical adapter the datagram is sent.
Whether the destination host is on the local network or not. If it is, it is sent to the
physical address of the destination host. If it isn't, the datagram is sent to the physical
address of the gateway.
The base algorithm is needed on all IP hosts and is sufficient to handle the base gateway
function. Incoming datagrams are also checked to see if the local host is the IP destination
host.
Because both hosts and gateways route datagrams, both have routing tables. Whenever a
host or gateway needs to transmit a datagram, it consults the routing table to decide where
to send the datagram.
The routing table always points to gateways that can be reached across a single physical
network. Thus, all gateways listed in a host's or gateway's routing table must lie on a
network to which it is directly connected.
Routing within the same network is called direct routing.
Routing that requires the services of a gateway to transfer datagrams from one network to
another is called indirect routing.
Routing in which the destination IP network is not specifically found is called the default
route. It is the route an IP datagram goes if its destination network is not listed in the routing
table.
Explain the routing algorithm by discussing each decision box. These steps are followed by
every router with each address comparing it to the entries in the route table.
Discussion Items
How many parts make up an IP address?
Two - host and network
During routing, are both parts analyzed?
No - just the network part
Transition Statement To see what routers are in the kernel's routing table, use the
netstat -rn command.

V3.1.0.1
Instructor Guide
Uempty
Viewing the Routing Table: netstat -rn
Output:
# netstat -rn
Routing tables
Destination Gateway Flags Refs Use If PMTU Exp Groups
Route Tree for Protocol Family 2 (Internet):

default 10.19.98.11 UG 0 0 tr0 - -
10.19.98/24 10.19.98.1
. U 3 16567 tr0 - -
127/8 127.0.0.1 U 0 949 lo0 - -
Route Tree for Protocol Family 24 (Internet v6):

::1 ::1 UH 0 0 lo0 16896 -
Figure 5-6. Viewing the Routing Table: netstat -rn . AU079.1
Notes:
The routing table displayed indicates the available routes and their statuses. This example
is for sys1 (10.19.98.1). sys11 (10.19.98.11) is the router that is used for the default route.
The routing table format indicates:
- Destination
Address of destination (host or network). If the destination is a network, the subnet
mask is indicated by /XX, where XX is the number of bits in the network portion of
the address.
- Gateway
Address of the next hop gateway.
- Flags
U=up
H=route is to a host
G=route is to a gateway
(See the man page for complete list of flags.)

Instructor Guide
- Refs
The current number of active users for the route.
- Use
A count of the number of packets sent using that route
- If
The network interface used for the route.
- PMTU
Gives the Path Maximum Transmission Unit for the route. Prior to AIX 5L V5.3,
PMTU values are kept in the routing table. Starting in AIX 5L V5.3, PMTU values are
kept in a separate PMTU table and are not displayed with netstat -r.
- Exp
Displays the time (in minutes) remaining before the route expires (for cloned routes
and ICMP redirect routes).
- groups
Provides a list of group IDs associated with that route.
Protocol Family 2 is IPv4; Family 24 is IPv6. The IPv6 entry shown is the IPv6 loopback
address.
The -r flag shows routing statistics.
The -n flag displays the network address as an IP address. When this flag is not used, the
addresses are displayed symbolically (example sys1).

V3.1.0.1
Instructor Guide

Purpose Explain how the netstat -rn command displays the routing table.
Details Explain that the first part of the output relates to subnet masking, which is not
referred to by the end user. Skip to the middle portion of the output and concentrate on this
information as explained in the student notes.
The default output of netstat -r shows host names rather than IP addresses. The -n flag
is used to change that output to display IP addresses instead. When using netstat -rn, if
an IP address cannot be resolved to a host name, the IP address will be displayed.
Additional Information The command netstat -r is explained later in the unit on
Troubleshooting. For the time being ...
The number after the / is the number of bits in the mask for the destination.
/ 8 is the notation for IPv4 netmask 255.0.0.0
And so forth
The entry in IPv6 table (: : 1) is the IPv6 loopback address.
AIX supports control of routing by group ID:
Groups is a list of the groups permitted to use this route. root and the group system are
permitted to use any route.
By default, all groups can use all routes.
You can manage which groups can use a route by using the -allowgroup/-denygroup
flags to the route command.
You can set group IDs for each network interface. If ipforwarding is turned on, this
allows you to control which routes can be used based on which interface the packet
came from. That is if you add group ID 5 to en0, packets coming in on en0 can only use
routes that allow GID 5.
- ifconfig enX group Z will add a GID to an interface. -group removes a GID.
- Use ndb with the ifnet subcommand to display GIDs associated with an interface.
- In the output of ifconfig: GROUPRT stands for Group Routing.
PMTU stands for Path Maximum Transmission Unit. Hosts are able to dynamically
configure the MTU to be used. Note that this is done per route table entry, on a host per
host basis if needed.
Exp stands for the time, in minutes, remaining before route expires.
Transition Statement There are three ways routes can be established. Let's see what
they are.

Instructor Guide
Establishing Routes
Explicit
or
Dynam
t Static ic
Implici
Routing Table
Hosts
Networks
Default
Figure 5-7. Establishing Routes AU079.1
Notes:
Kernel routing table

Routes are defined in the kernel routing table, which can hold up to 32 route definitions.
These route definitions include information on networks reachable from the local host,
gateways that can be used to reach remote networks, and the hop count (or distance
metric) to those networks.
Implicit routes
The implicit method is performed when you configure an interface.
Explicit routes
Explicit routes are added by the network administrator.

V3.1.0.1
Instructor Guide
Uempty Dynamic routes

Dynamic routes are created by ICMP redirect messages in a static routing environment.
ICMP sends redirect messages when a better route to a host is noted. ICMP redirects
are only generated by routers and are intended only for use by hosts.
Additional dynamic routes are established when new a new Path Maximum
Transmission Unit (PMTU) is discovered. These are called cloned routes. The purpose
of cloned routes is to provide a way to identify a maximum transmission unit for a
specific route or path (path MTU).
Cloned routes expires after a period of inactivity.
Starting in AIX 5L V5.3, PMTU information is no longer stored in the kernel routing
table. Instead it is stored in a separate PMTU table in the kernel. Thus cloned routes are
not longer created in AIX 5L V5.3. These issues will be discussed in the Network
Control unit.

Instructor Guide
Instructor Notes:
Purpose Outline how route entries are created.
Details An implicit entry is added for each interface that is configured in the system.
These are added automatically when you do TCP/IP configuration.
Explicit routes are added for remote hosts and networks. We show how to add them using
static routes shortly.
ICMP sends re-direct messages to alter routing information in the routing table. ICMP
redirects are covered shortly.
Additional Information PMTU is active by default. RFC 1191 provides the mechanism
to discover the PTMU. Several parameters under the no command are:
udp_pmtu_discover (turns on pmtu discover for UDP)
tcp_pmtu_discover (turns on pmtu discover for UDP)
route_expire (Specifies whether unused routes created by cloning, or created and
modified by redirects expire. There is no cloning in AIX 5L V53.)
pmtu_default_age (Specifies the default amount of time (in minutes) before the path
MTU value for UDP paths is checked for a lower value.)
pmtu_expire (Specifies the default amount of time (in minutes) before which the
unused path MTU entries are deleted.)
pmtu_rediscover_interval (Specifies the default amount of time (in minutes) before
the path MTU value for UDP and TCP paths are checked for a higher value.)
Transition Statement Let's look at some of the characteristics of static routing.

V3.1.0.1
Instructor Guide
Uempty
Static Routing
Manually updated
Practical in small, stable networks
route command
Configured through SMIT
No daemons are involved
Figure 5-8. Static Routing AU079.1
Notes:
With static routing, the routing table is maintained manually with the route command or
through SMIT.

Instructor Guide
Instructor Notes:
Purpose Describe the characteristics of static routing.
Details Static routing is a good method to use to show how routing works. Since it is
only practical in small, stable networks, few people use only static routing. In the next
visual, we take students through the steps of configuring static routes.
You can enter routing table entries from the command line. Keep in mind that they are only
in memory. At reboot, the route table entries are not available. This is a good method to use
to test routes.
The route command can be used either from the command line or via SMIT. Setting up
routing using SMIT stores the routing table information in the ODM. At system restart, the
routing tables are built using the ODM information.
There are no daemons to start or stop for static routing. The routing algorithm is built into
the IP layer of the protocol stack.
Transition Statement To get a better understanding of how routing works, let's look at
how to configure static routing using SMIT.

V3.1.0.1
Instructor Guide
Uempty
Configuring Routing through SMIT
# smitty mkroute
Add Static Route

[Entry Fields]
Destination TYPE net +
*DESTINATION Address [10.19.99.0]
*Default GATEWAY Address [10.19.98.3]
Cost [0]
Network MASK (hexadecimal or dotted decimal) [255.255.255.0] #
Network Interface []
Enable Active Dead Gateway Detection? no +
Is this a Local (Interface) Route? no +
Policy (for Multipath Routing Only) Default (Global) +
Weight (for Weighted Multipath Routing Policy) [1] #
Apply change to DATABASE only no +

Figure 5-9. Configuring Routing through SMIT AU079.1
Notes:
SMIT path
The following is the full path to get to this screen:
# smitty
Communications Applications and Services
TCP/IP
Further Configuration
Static Routes
Add Static Route
Fields
The fields in the Add Static Route panel are:
- destination TYPE
specifies whether this destination is a network or a host.

Instructor Guide
- DESTINATION address
specifies the IP address of the destination host or network. Can be specified as
either a dotted decimal number or symbolic name.
- Default GATEWAY address
specifies the IP address of the gateway. Can be specified as either a dotted decimal
number or symbolic name.
- COST
used to set priority of routes going to same destination. We will discuss this further
when we discuss multi-path routing in the Network Control unit.
- Network MASK
If subnet masking is being used, specifies the correct subnet mask.
- Network Interface
specifies which interface that the route should go through. Needed if you have
multiple interfaces connected to the same subnet.
- Enable Active Dead Gateway Detection?
We will discuss this further when we discuss multi-path routing in the Network
Control unit.
- Is this a Local (Interface) Route?
Normally, interface or implicit routes are created when you configure the interface.
This field allows you to do this manually.
- Policy (for Multipath Routing Only)
Control unit.
- Weight (for Weighted Multipath Routing Policy)
Control unit.
- Apply change to DATABASE only
specifies if both kernel and ODM should be changed:
no changes both the ODM and the kernel routing table in memory.
yes changes the ODM only.

V3.1.0.1
Instructor Guide

Purpose To show students how to configure static routes using SMIT.
Details Configuring static routes through SMIT adds them to the ODM database. If you
add routes through SMIT be sure to delete them through SMIT or they will show up again
after a reboot.
Transition Statement Let's now look at how to add routes using the route command.

Instructor Guide
route Command
# route command family flag dest netmask gateway
command
add
flush (or -f)
delete
change
monitor
family (optional)
-inet
-xns
flag (optional)
-net
-host
destination
symbolic name or numeric address
netmask (optional)
network mask
gateway
symbolic name or numeric address
Figure 5-10. route Command AU079.1
Notes:
The route command allows you to make manual entries into the network routing tables.
These entries are good only until the next system reboot.
-inet is the default family. -xns stands for Xerox Network System.
The route command distinguishes between routes to hosts and routes to networks by
interpreting the network address of the destination address. The optional keywords -net
and -host force the destination to be interpreted as a network or host respectively.
The route command does not update ODM. Thus, if you want entries to be permanent,
use SMIT. If you don't want to use SMIT, you can add route statements to the /etc/rc.net
file, but SMIT is the recommended method.
Select to list, add, remove, or flush. When you add or remove a route, you are required to
enter a destination address and gateway address. SMIT updates the ODM database.

V3.1.0.1
Instructor Guide

Purpose Explain the route command syntax.
Details Outline five components of the command. Examples are covered on the next
page. Although -net and -host are optional, leaving that argument out of the command
may provide unexpected results as the system tries to interpret the IP address as a
network or host address. Routing problems are most difficult to find when -host or -net
was not specified.
Emphasize again that using the route command from the command line does not update
ODM. It is better to use SMIT if the routes need to be permanent.
Transition Statement Let's look at a few example route statements before we use the
command to set up routes in a sample network.

Instructor Guide
route Command Examples
1. # route add 10.19.98.1 10.19.99.11
2. # route add 0 10.19.99.11
3. # route add -net 10.19.99/22 10.19.98.11
4. # route -f
5. # route delete 0 10.19.99.11
6. # route add -net default sys11

Figure 5-11. route Command Examples AU079.1
Notes:
1. This example establishes a host route for the destination host 10.19.98.1.
2. This example establishes a default route. The value 0 for the destination parameter
means that any packets sent to destinations not previously defined and not on a directly
connected network go through the default gateway. The value 0 really stands for the
dotted decimal value 0.0.0.0, which means any network or host.
3. This example adds a network route to the routing table with subnetmask
255.255.252.0.
4. This example clear the routing table of all routes except those created implicitly. The
term often used is flush the routing table. Also, route flush does the same thing.
5. This example deletes only the default route that was set in Step 2.
6. This example establishes a default route. Notice that you can use the word default just
like 0. Also, you can use a symbolic name instead of an IP address, as long as that
symbolic name can be resolved from /etc/hosts. What gets stored in the kernel's
routing table is the IP address.
All the above examples assume a subnet mask of 255.255.255.0 was applied.

V3.1.0.1
Instructor Guide

Purpose Reinforce route command with examples.
Details Demonstrate route add, delete, and flush using the route commands on the
visual and in the student notes.
Discussion Items:
Use the following questions to help students pick out commands:
Which example shows adding a route to the 10.19.99 network? 3
Which example shows adding a host entry? 1
Which example shows adding a default route? 2, 6
Which example shows deleting a default route? 5
Which example deletes all explicit and default route entries? 4
Transition Statement Now let's take a simple network scenario and set up the routes
for the system.

Instructor Guide
Routing Example
135.9.19.5
sys1 sys8
sys5
5.10.10.1 201.64.23.8
sys2 135.9.19.4 135.9.19.6 sys9

sys4 sys6
5.10.10.2 sys4e sys6e 201.64.23.9
5.10.10.4 201.64.23.6
sys3 sys7 sys10

5.10.10.3 135.9.19.7 201.64.23.10
subnet mask = Subnet Mask = 255.255.0.0 subnet mask =

255.0.0.0 255.255.255.0
Figure 5-12. Routing Example AU079.1
Notes:
What needs to be done in order for all machines in the above diagram to communicate with
each other?

V3.1.0.1
Instructor Guide

Purpose Practical routing example.
Details This is a review of routing.
Introduce topology by asking: How many networks? Where are the routers? Any subnet
masking? What are the network IDs? Take a look at one network at a time.
Using the drawing, first lay out the routing table entries to make all the hosts communicate.
Note that there is more than one solution. You can use all default route entries; or you can
use explicit network entries; or you could use explicit host entries; or you can use a
combination. Discuss the trade-offs of different route entries.
One master router is simple to administer, maybe simpler for users but less efficient for
135.9 network. Two routers are more efficient and straight forward.
Build sample route tables for sys3, sys9, sys4, sys6, and sys5, or have the students pick
the machines and help you build the entries.
sys1, sys2, and sys3 would need the following route commands issued:
# route add -net 135.9.0.0 5.10.10.4
# route add -net 201.64.23.0 5.10.10.4
- or -
# route add 0 5.10.10.4 -Default Route (optional)
sys5 and sys7 would need the following route commands issued:
# route add -net 5.0.0.0 135.9.19.4
# route add -net 201.64.23.0 135.9.19.6
sys8, sys9, and sys10 would need the following route commands issued:
# route add -net 5.0.0.0 201.64.23.6
# route add -net 135.9.0.0 201.64.23.6
- or -
# route add default 201.64.23.6 -Default Route (optional)
sys4 and sys6 would need the following route commands issued:
sys 4 (confirm ipforwarding=1)
# no -o ipforwarding
# route add -net 201.64.23.0 135.9.19.6
sys 6 (confirm ipforwarding=1)
# no -o ipforwarding
# route add -net 5.0.0.0 135.9.19.4
Also, student could create loop with default entries if they are not careful.
Discussion Items If you sat down at a system and tried to determine how many
interface cards it had and what networks you can get to, what commands would you use?

Instructor Guide
netstat -r to view the route tables

netstat -i to view the network interface configuration
ifconfig to view subnet masks so you can identify the network portion of the IP
addresses.
Transition Statement Next, lets look at ICMP redirects.

V3.1.0.1
Instructor Guide
Uempty
ICMP Redirects
sys5
1. IP
datagram
destination
sys8
3. ICMP redirect
4. future IP datagrams
2. IP
sys4 datagram sys6
sys4e sys6e
sys8
Figure 5-13. ICMP Redirects AU079.1
Notes:
When there is a better choice of a router for sending messages through than the one the IP
datagram was originally sent to, an ICMP redirect error message is generated, which
updates the sending host's routing tables. The process goes like this:
1. An IP datagram is sent from sys5 with a destination of sys8. sys5's routing table shows
sys4 as the router.
2. sys4 checks its routing table and sees there is a closer router to sys8's network. It
sends on the IP datagram to sys8.
3. Then sys4 sends an ICMP redirect message to sys5, which updates its routing table.
4. Future IP datagrams destined for sys8 goes to the new router.
The options ipsendredirects and ipignoreredirects network options are used to
control how AIX handles ICMP redirects. These options can be set with the no command.

Instructor Guide
Instructor Notes:
Purpose Describe how a routing table may be updated automatically without any of the
dynamic daemons running.
Details ICMP sends redirect messages when a better route to a host is noted.
ICMP redirects are only generated by routers and are intended only for use by hosts.
The network options that control ICMP redirects are:
ipsendredirects - a value of 1 causes AIX to send them; a value of 0 suppresses them.
ipignoreredirects - a value of 1 causes AIX to ignore and not process them; a value of 0
allows AIX to receive redirects and update its routing tables accordingly.
Additional Information The router performs the following checks to see if there is a
need for a redirect:
The other router to which the redirect references must be on the same physical
network.
The route it uses must not have been created or modified by a redirect.
The route it uses must not be the default route.
The kernel must be configured to send redirects. This can be checked with the no
command. Look for ipsendredirects set to true.
Before the host updates its routing table, it checks the following:
The new route must be on a directly connected network.
The redirect must have come from the router currently configured for that destination.
The route being modified is an indirect route.
Routers should send only host redirects, not network ones because subnetting makes it
difficult to specify when a network redirect can be used, and some hosts are configured to
accept all redirects as host redirects in case the router sends the wrong type.
Transition Statement There are two simple commands that can be used to report the
route a datagram takes to its destination. They are ping -R and traceroute. Let's look at
ping -R first.

V3.1.0.1
Instructor Guide
Uempty
ping -R
Shows end-to-end connectivity
Shows outbound connections
Example:
# ping -R -c 3 labster
PING labster.beaverton.ibm.com: (9.47.87.20): 56 data bytes
RR: bvr-fb-11-fe0-3.beaverton.ibm.com (9.47.87.1)
labster.beaverton.ibm.com (9.47.87.20)
bvr-fb-11-fe0-4.beaverton.ibm.com (9.47.88.1)
laurel171.beaverton.ibm.com (9.47.88.171)
64 bytes from 9.47.87.20: icmp_seq=1 ttl=254 time=1 ms (same route)
64 bytes from 9.47.87.20: icmp_seq=2 ttl=254 time=1 ms (same route)
----labster.beaverton.ibm.com PING Statistics----

Figure 5-14. ping -R . AU079.1
Notes:
The -R option on the ping command includes a RECORD_ROUTE option in the ICMP
ECHO_REQUEST packet. Thus, it displays the route buffer on the returned packets.

Instructor Guide
Instructor Notes:
Purpose Show how ping -R works.
Details Refer to the visual of the complex routing example to go over the output. Show
students how in routes specified in the ping -R output the outbound connections of the
gateway both going to the destination and returning are shown. Point out that the route a
packet takes could change, in which case a new route listing would be shown.
Additional Information The IP header is only large enough to handle nine routes. Also,
hosts or gateways may ignore this option.
Transition Statement ping -R shows you the full round trip route of a datagram;
however, it only works if the route is complete in both directions. traceroute can be used
to find the break in connectivity. Let's look further at traceroute.

V3.1.0.1
Instructor Guide
Uempty
traceroute
Discovers the various gateways on the path

Shows inbound connections
Example:
# traceroute sys10
traceroute to sys10 (201.64.23.10) from sys1e

(5.10.10.1)
30 hops max
outgoing mtu=1500
1 sys4e (5.10.10.4) 2 ms 2 ms 1ms

2 sys6 (135.9.19.6) 3 ms 3 ms 3ms
3 sys10 (201.64.23.10) 5 ms 5 ms 5ms
Figure 5-15. traceroute . AU079.1
Notes:
traceroute works by sending UDP packets toward an unused UDP port along the path to
a destination. Note that it introduces additional load into the network, and therefore should
be used sparingly.

Instructor Guide
Instructor Notes:
Purpose Show how traceroute works.
Details The traceroute command works by sending regular IP packets toward the
destination, progressively increasing the ttl field. When the first packet is sent, it has a ttl of
1. The first gateway on the path will receive it and decrease the ttl to 0. It then discards the
packet and sends back a ttl expired ICMP message. The source address of this message
identifies the gateway. The next message is sent with a ttl of 2. The first gateway passes it
on after decrementing the ttl, and the next gateway, after decrementing the ttl, sends an
ICMP error message back that identifies the second gateway, and so on. Three probes are
sent each time. This continues until the final destination is reached or the point where
connectivity is broken is identified.
Additional Information The three times displayed for each entry are the round-trip
times for the probe packets. If no response is received for a probe, then its time is shown
as "*".
Transition Statement Before the exercise, let's do a few checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint
1. There are three types of routing table entries: direct, indirect, and
default. Which type occurs when the source and destination hosts
are on different physical networks and the destination is
specifically designated?
a. direct
b. indirect
c. default
2. When a network interface is configured, a route is created in the
route table. What is the term associated with the creation of this
route?
a. dynamic
b. implicit
c. static (or explicit)
3. T/F: The route -f (or route flush) command deletes ALL routes.
Notes:

Instructor Guide
Instructor Notes:
Purpose Review.
Details
a. direct
b. indirect
c. default
route?
a. dynamic
b. implicit
False. It flushes all routes except ones created implicitly.
Transition Statement Exercise.

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Static
Routing
Notes:

Instructor Guide
Instructor Notes:
Purpose Introduce exercise.
Details
Transition Statement Lets summarize this unit.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
Routing is performed by the IP layer of TCP/IP. The IP routing
algorithm analyzes direct, indirect, and default routes
Routing tables are built from implicit, explicit/static or dynamic
entries
IP searches the route table by host routes, network routes, and
finally default routes
Static routes are created manually
Notes:

Instructor Guide
Instructor Notes:
Purpose Summary.
Details
Transition Statement End of this unit.

V3.1.0.1
Instructor Guide
Uempty Unit 6. Dynamic Routing

This unit introduces the concept of dynamic routing and associated
terminology. Routing Information Protocol (RIP) and Open Shortest
Path (OSPF) are discussed using the routed and gated daemons.

Describe the concept of dynamic routing
Define an autonomous system
Discuss routing protocols for interior and exterior gateways
Configure the routed and gated daemons

Accountability:
Exercises
Copyright IBM Corp. 1997, 2006 Unit 6. Dynamic Routing 6-1

Instructor Guide
Unit Objectives
Describe the concept of dynamic routing
Define an autonomous system
Discuss the routing protocols for interior and exterior gateways
Configure the routed and gated daemons
Notes:

V3.1.0.1
Instructor Guide

Purpose Introduce basic concepts of dynamic routing.
Details In this unit we only scratch the surface of dynamic routing. We present some
terminology definitions and introduce basic concepts of distance vector and link state
protocols. Keep this discussion as high level as possible or you quickly run out of time and
probably confuse students who may, by this time, be somewhat saturated with all the
information they have been getting.
Transition Statement Let's begin our discussion with an overview of what dynamic
routing is.

Instructor Guide
Dynamic Routing
daemon routing daemon

protocols
Gateway Gateway
AIX provides two daemons: routed and gated

Daemons operate in active and passive mode
Protocols supported include: RIP, RIP v2, OSPF and
BGP
Interior and exterior gateways
Figure 6-2. Dynamic Routing AU079.1
Notes:
Routing daemons can operate in either the passive or active mode depending upon the
options used when starting the daemons or within the configuration file.
In active mode, the routing daemon both broadcasts routing information about its local
network to routers and hosts as well as receives routing information from hosts and routers.
In passive mode the routing daemon simply receives routing information from hosts and
gateways and updates its own routing table. They do not pass on their own routing
information.
There are two daemons used in dynamic routing, the routed and gated daemons. The
gated daemon is by far the more complex as it supports several routing protocols
simultaneously, the Routing Information Protocol (RIP), Exterior Gateway Protocol (EGP),
Border Gateway Protocol (BGP), the Local-Network protocol (HELLO), and Open Shortest
Path First (OSPF).
The routed daemon only supports RIP and only version 1 of the protocol. The gated
daemon supports RIP versions 1 and 2.

V3.1.0.1
Instructor Guide
Uempty The terms interior and exterior gateways relate to whether the gateways are a part of an
autonomous system or between autonomous systems.

Instructor Guide
Instructor Notes:
Purpose Provide an overview of what dynamic routing is.
Details Unlike static routing, which needs no daemons to function, dynamic routing uses
daemons. They are the routed and gated daemons. Only one or the other should be
started on a system, not both. If both are started you get unpredictable results. The routed
daemon supports only RIP. The gated daemon supports several protocols simultaneously.
(Refer to student notes for a list of them).
The daemons can be configured in either active or passive mode. Normally, gateways are
configured in active mode so they can send their network information to other gateways as
well as receive it. Hosts are generally configured in passive mode to only receive
information needed to update their routing tables. This helps reduce network traffic.
Additional Information Although it is not mentioned in the chart gated also supports
the obsolete Exterior Gateway Protocol (EGP) and also supports the rarely used HELLO
protocol.
In this unit we discuss how to use the routed and gated daemons for RIP. We also briefly
discuss OSPF, but do not cover BGP, EGP, or HELLO.
Transition Statement Let's take a closer look at what an autonomous system is so we
can gain a better understanding of the difference between interior and exterior gateways.

V3.1.0.1
Instructor Guide
Uempty
Autonomous Systems
Local
Net 2 Autonomous
System
Interior Exterior
Gateway Gateway
Local
Exterior
Net 1 Gateway Autonomous
System
Interior
Gateway
Exterior
Gateway
Local
Net 3
Autonomous
System
Figure 6-3. Autonomous Systems AU079.1
Notes:
An autonomous system is a group of networks and gateways for which one administrative
authority has responsibility. An example of an autonomous system would be the group of
networks and gateways administered by IBM or MIT.
Gateways are interior neighbors if they reside on the same autonomous system and
exterior neighbors if they reside on different autonomous systems.
Interior gateways communicate with each other using the RIP, HELLO, or OSPF protocol.
Exterior gateways use the BGP protocol.
Each exterior gateway does not communicate with every other exterior gateway. Instead,
the exterior gateway acquires a set of neighbors with which it communicates. The
neighboring gateways have other exterior gateway neighbors. Thus, the exterior gateways'
routing tables are updated and routing information shared among the exterior gateways.
The routing information is sent in a pair of network ID and distance information, the metric,
which reflects the cost of reaching the specified network. Each gateway broadcasts the

Instructor Guide
networks it can reach and the cost associated with reaching them. This applies to both
interior as well as exterior gateways.

V3.1.0.1
Instructor Guide

Purpose Define an autonomous system and the gateways associated with it.
Details An autonomous system is a group of networks administered by one authority,
such as a company. Gateways within an autonomous system are called interior gateways
and gateways between autonomous systems are exterior gateways.
All gateways use protocols to communicate with each other.
HELLO is one of the interior gateway protocols. It calculates the shortest path to other
networks by determining the path that has the least delay time.
RIP is another one of the interior gateway protocols. It also calculates the shortest path to
other networks not by delay time but by hop count. When using the gated daemon, the hop
count generated by RIP is converted into time delays by gated.
OSPF is an interior gateway protocol. It can use a combination of several criteria to
calculate lowest cost including delay time and hop count.
BGP is an exterior gateway protocol. Autonomous system gateways use BGP to provide
access information to their neighbors. BGP does not calculate the shortest path to other
networks. It simply indicates whether a network is reachable.
BGP allows an exterior gateway to ask another exterior gateway to exchange access
information and continually checks to ensure its neighbors are responding.
We work solely with the protocols used by interior gateways, specifically RIP and OSPF. Be
sure to point out to students this is a very high-level discussion of dynamic routing. It is
meant to be an introduction to get students started.
Transition Statement Let's start our look at dynamic routing by discussing one of the
first of the protocols developed to do dynamic routing in autonomous systems, RIP.

Instructor Guide
Routing Information Protocol (RIP)
host1 host2
RIP RIP
passive passive
gate1 gate2 1 hop

RIP RIP
active active
1 hop
to other gateways
Figure 6-4. Routing Information Protocol (RIP) AU079.1
Notes:
RIP is a very simple protocol of the distance vector family which uses a shortest path
algorithm to determine the best route to a destination. This distance is measured in a
metric called hops which is usually the number of gateways through which a packet must
travel before it reaches its destination network.
The routing daemon dynamically builds the routing table based on information received
from updates provided by the RIP protocol.
Participating hosts and gateways run in either active or passive mode. Active gateways
advertise and update their routes. Passive gateways listen and update their routes but do
not send out updates. Usually, gateways run RIP in active mode and hosts in passive
mode.
Distance vector protocols calculate the lowest-cost path based solely on the distance from
one location to another. Things like line speed or line reliability are not considered at all.
Thus, a slow-speed link, such as a 9600 baud serial line, that goes through fewer gateways
than a T1 connection will be used. Since all routes considered to be higher-cost routes are

V3.1.0.1
Instructor Guide
Uempty deleted, as long as the slower link is still closer to its destination than the high-speed link,
the high-speed link never shows up in the routing table for use by IP.
The most commonly used distance vector protocol is RIP and it is limited to 15 hops or
gateways. If a route to a destination needs more than 15 gateways to get there, it is
considered to be an infinite distance away and is shown to be unreachable.

Instructor Guide
Instructor Notes:
Purpose Provide a high-level description of the Routing Information Protocol.
Details When routed is started, it issues a request for routing updates and listens for
responses to its request. When a system configured to supply RIP information hears the
request, it sends a packet with information from its routing table. This packet includes the
destination address (networks or hosts) from the routing table and the metric associated
with each (measured in hops). In addition to issuing updates in response to requests,
packets are sent periodically to keep routing information current, usually every 30 seconds.
When a RIP update is received, routed takes the information and updates the routing
table. If the destination in the update does not exist in the local table, a new entry is added.
If the update relates to an existing entry, the new route is added only if it has a lower cost.
RIP specifies that once a gateway learns a route, it must keep that route until it learns of a
better one, one with a lower cost. The cost is calculated by adding the cost of reaching the
gateway that sent the update (usually 1) to the metric provided in the RIP update. If this
value is less than what is currently there, the new route will be added and the old
discarded.
RIP also deletes routes from the table. This can happen if the cost of a route to a
destination exceeds 15; 15 is the total number of hops RIP travels, also referred to as
infinity. Routes are also deleted if a gateway doesn't send updates for a specified period of
time, usually 180 seconds.
Additional Information Distance vector protocols are easy to implement. However,
when routes change rapidly, for example a new connection appears or an old one fails, the
computation may not stabilize because information is passed slowly from one gateway to
another. Until stabilization, known as convergence, occurs, some gateways may have
incorrect routing information. Also, the algorithm doesn't take into account the speed, type,
or reliability of a link and thus could end up setting up routes through slower-speed links if
its hop count is less than that of higher-speed links.
There are two routing tables when dynamic routing is active. There is a kernel routing table
and a daemon routing table. Routing decisions are made based on the information in the
kernel routing table. The daemon routing table is used to collect routes from the other
routing daemons running in the network. Using the information in the daemon routing table
and comparing it to that which is in the kernel routing table, the daemon makes its
decisions as to which is the least costly route and, if necessary, updates the kernel routing
table. The kernel routing table is seen with the netstat -R. command. The routed routing
table can be viewed with the lssrc -l -s routed command and the gated routing table can
be viewed by doing a kill -2 <pid of gated> which dumps its data to
/var/tmp/gated_dump.
RIP is a UDP-based protocol. Each host that uses RIP has a routing process that sends
and receives datagrams on UDP port number 520. Possible problems with RIP include
routing loops, long time to convergence, and bouncing.
Transition Statement Let's look at how RIP updates work.

V3.1.0.1
Instructor Guide
Uempty
How RIP Updates Work
H1 R1 R2 H2
net1 net2 net3
IMPLICITLY STEP 1 STEP 2
H1 net 1 net 2 via R1 net 3 via R1

net 1 All routes
R1 net 3 via R2
net 2 discovered
net 2 All routes
R2 net 1 via R1
net 3 discovered
H2 net 3 net 2 via R2 net 1 via R2
Convergence !!
Figure 6-5. How RIP Updates Work AU079.1
Notes:
The above diagram shows three networks with two routers between them and hosts on
each of the end networks. Before RIP is activated each host / router implicitly knows about
each network they are part of. When RIP first gets turned on in this scenario, the first
network each host receives routing information on is Net2, the one that is one hop away
form them. As RIP continues to broadcast its neighbor's routing information in the next
steps, H1 finds out about Net3 and H2 finds out about Net1. At this point all routing tables
have been updated so all networks are reachable. Thus, the network is now stable or has
come to convergence. The process of sending out routing information and updating routing
tables to come into a stable environment is called coming to convergence. Until this
happens, some hosts may not be able to reach some networks.

Instructor Guide
Instructor Notes:
Purpose Provide a simple description of how RIP updates occur.
Details Go through the two steps outlined with your students. Obviously, this can get
much more complex with more networks and networks with more than one path to them.
Transition Statement Now that we've seen the basic mechanisms of RIP, let's look at
some of the more important details.

V3.1.0.1
Instructor Guide
Uempty
RIP Features
Metric is only hop count
Maximum hop count 15 hops
Suitable for small/medium internetworks
Routers broadcast updates on UDP
Send message on startup to solicit routing tables
Advertise tables every 30 seconds
Send triggered updates for topology changes
Figure 6-6. RIP Features AU079.1
Notes:
In RIP, the distance metric is normally the number of hops to the destination network.
However, you can also set the distance across some networks to more than one, as a way
of indicating they are less preferable. In any case, the maximum distance to any destination
is 15, since 16 is used as the value for infinity (that is, unreachable).
RIP routers send updates to each other using UDP, sending and receiving updates on port
520. When a router joins the network, it broadcasts a message requesting that all
neighbors send their routing tables. Thereafter, the router advertises its tables to all
neighbors once every 30 seconds. Also, when an update is received indicating a change to
network topology, a router sends it immediately (after a small random delay) in order to
ensure the news is propagated quickly.
Because of the hop count limitation, inflexible metrics and frequent updates, RIP is suitable
only for small or medium internet works.

Instructor Guide
Instructor Notes:
Purpose Explain some of the more important features of RIP.
Details Systems (routers and hosts) carry out the RIP protocol as follows:
Each system determines the networks to which it is directly connected. In UNIX
systems, this is based on the interfaces configured with the ifconfig command. This set
of directly connected networks forms the initial set of destinations that the system will
advertise via RIP.
Additional destinations may also be defined by the system administrator. For example,
there may be some destinations (external to the internetwork in which RIP is being run)
that are reachable via static routes. Or the system may be the default gateway for the
internetwork. These additional destinations can be included in RIP advertisements. In
AIX, for example, routed reads these additional destinations from the file
/etc/gateways.
When the system starts, it sends a RIP request message to port 520 on the broadcast
address for each network to which it is directly connected. (On point-to-point links, the
request is simply sent to the system on the other side of the link.) The system uses the
information received in response to update its routing tables.
The system them gratuitously broadcasts its routing tables every 30 seconds to all
systems on directly connected networks. It also receives updates from those systems,
which it uses to update its routing tables.
RIP systems also send triggered updates when they learn that a route has changed. To
avoid flooding the internetwork with simultaneous updates, systems wait for a period of
time before sending them. In particular, they wait a random amount of time, between 1
and 15 seconds. If other changes occur in the meantime, they are all included in the
same update. Additional changes cause a further waiting period before sending the
update, a random amount of time between 1 and 5 seconds. Also, triggered updates
may be suppressed if a regular update would be sent before the waiting period has
expired.
Additional Information Refer to RFC 1058 RIP (Historic).
Transition Statement In many networks there are multiple links, each with different
speed connections to them. Let's see what RIP does by default when it runs into different
speed links.

V3.1.0.1
Instructor Guide
Uempty
How RIP Handles Multiple
Paths to the Same Network
56 KB
A B
96
00 56 KB
T1 bp
s
C D
T1
A - D through C - 2 hops
A - D through B - 2 hops
A - D direct - 1 hop
Figure 6-7. How RIP Handles Multiple Paths to the Same Network AU079.1
Notes:
Even though both A-D through C and A-D through B would provide better performance,
because RIP calculates shortest path strictly on the basis of hop count, it would choose the
9600 bps line that is only 1 hop.

Instructor Guide
Instructor Notes:
Purpose Show students how RIP decides the shortest path to a destination.
Details This foil shows one of the drawbacks of RIP especially as implemented with the
routed daemon. By default, it chooses as the shortest path the one that is the fewest hops
away. With the gated daemon, a preference value can be set in the gated.conf file that
helps reduce the problems with this strictly distance philosophy.
Transition Statement We've seen some of the limitations of RIP. Now let's look at RIP
version 2, which enhances the protocol.

V3.1.0.1
Instructor Guide
Uempty
Configuring the routed Daemon
Identify known networks in the /etc/networks file (optional)
Identify any known gateways not directly connected to your
network in the /etc/gateways file (optional)
Uncomment the line in the /etc/rc.tcpip file that starts the
routed daemon adding any of the following options as
needed:
-s for active (gateway)
-q for passive (host)
-t for turning on tracing
-d for turning on debugging
-g for gateway
Run the script
-OR-
startsrc -s routed
Figure 6-8. Configuring the routed Daemon AU079.1
Notes:
In AIX the routed daemon is usually started under the control of the SRC. There is a line in
the /etc/rc.tcpip file that starts routed using the SRC if SRC is running. Thus, the routed
daemon can also be started at the command line using the following syntax:
startsrc -s routed -a -s (starts it in active mode)
startsrc -s routed -a -q (starts it in passive mode)
You can also use SMIT to start it but you are not able to provide any options.
Configuring the /etc/networks and /etc/gateways files are optional. The /etc/networks file
is used to identify known networks in the Internet to help in getting known routes
established more quickly. Its format is:
Name Network Number Aliases

Instructor Guide
The /etc/gateways file is used to set up routes to known gateways that are not directly
connected to your network and is also used to help get the routing table updated more
quickly. Its format is:
<destination> <name1> gateway <name2> metric <value> <type>
Where:
destination - keyword net or host
name1 - destination symbolic name or IP address
name2 - gateway symbolic name or IP address
value - hop count
type - active or passive
To specify a route to a host through a gateway host:
host sys2 gateway sys1 metric 1 passive

V3.1.0.1
Instructor Guide

Purpose Describe the steps necessary to start routed on a system.
Details The routed daemon is the daemon most commonly used to run simply RIP. If
other protocols are needed then gated should be run instead. Both routed and gated
should NOT be run at the same time.
Configuring routed is as simple as starting the daemon with the desired option to run it in
active or passive mode. When using the src commands, if you wish routed to run
automatically after the next system reboot, the appropriate lines in the /etc/rc.tcpip file
need to be uncommented.
If you will be running routed in a relatively large network, it is a good idea to provide
gateway configuration information in the /etc/gateways file. This helps routed set up the
routes to the other networks more quickly. A sample of this file is provided in the
/usr/samples/tcpip directory.
The /etc/networks file is provided for ease of reference to network names by cross
referencing the official network name to the network IP address. The official network name
is usually the domain name of the network. Since DNS won't be covered until later, don't
spend any time discussing network names. This file is used in conjunction with a network
management application.
Transition Statement Now, let's take a quick look at what has to be done to run RIP
with the gated daemon starting with a brief discussion of the gated.conf file.

Instructor Guide
RIP Version 2
Authentication - password sent in RIP messages
Route Tag - indicate internal versus external routes
Subnet Mask - provide subnet mask for destinations
Next Hop - allows advertisement of route via another router
Multicasting - multicast address (224.0.0.9) for RIP
Supported only by gated
Figure 6-9. RIP Version 2 AU079.1
Notes:
RFC 2453 describes RIP Version 2.
The new features of RIP V2 are:
Authentication - Allows a router to require a password or other authentication before
accepting updates from another router.
Route Tag - Allows router to add a tag value to advertised routes, indicating for example
that particular routes are external.
Subnet Mask - Allows RIP to work in variably subnetted environments.
Next Hop - Makes RIP more flexible when used in environment with multiple routing
protocols (for example OSPF and RIP).
Multicasting - Allows routers to multicast updates, which is more efficient than
broadcasting.

V3.1.0.1
Instructor Guide

Purpose Explain the new features introduced by RIP version 2.
Details RIP V2 is defined in a way that allows it to coexist with systems supporting
version 1. It uses the same basic RIP message format, but places some extra information
in the unused fields. Systems supporting only version 1 should discard these messages.
(The version 1 RFC specifies that if the version field is greater than one and any of the
must be zero fields are non-zero, then the message should be discarded. However, some
implementations do not adhere to this requirement).
The new features of RIP V2 are:
Authentication.
It is potentially dangerous for a router to accept RIP messages without some form of
authentication. For example, a hostile system could send fake routes, causing a
network outage. Thus, RIP V2 allows a system to send a password in RIP messages.
The password is sent in clear text and may be up to 16 octets in length.
Route Tag.
This allows routers to attach a tag value to routes they advertise. The main use
envisioned by the RFC is to allow routes discovered by means other than RIP (for
example, external routes learned via EGP or BGP) to be distinguishable from RIP
routes.
In version 1, there is no subnet mask sent in RIP messages, and therefore the algorithm
assumes that a common subnet mask is in use throughout the autonomous system. For
autonomous systems that use several subnet masks, RIP V1 can make it impossible for
routers to properly distinguish among subnetworks. RIP V2 includes the subnet mask
for a destination in the update messages advertising the destination. This makes RIP
V2 suitable for autonomous systems using multiple subnet masks.
Next Hop.
RIP V2 allows the next hop for a route to be included in update messages. This means
that a router may advertise destinations that can be reached by a router other than
itself. An example of where this would be useful is given below.
Multicasting.
Broadcasting RIP update messages, as is done in Version 1, means that systems not
participating in RIP (which generally are most hosts) must receive and discard RIP
updates. This wastes cycles on them. Version 2 allows RIP updates to be sent to the
multicast address 224.0.0.9 instead. Thus, only those systems interested in RIP
updates would listen on that address.
In AIX, gated supports RIP-2 while routed supports only RIP-1.

Instructor Guide
Additional Information RIPng for IPV6-RIPng is intended to allow routers to exchange

information for computing routes through IPV6 based network and are documented in
RFC2080. RIPng is a distance vector protocol and similar to RIP-2 IN IPV4. RIPng is UDP
based protocol and sends and receives datagram on UDP port number 521.
Transition Statement RIP can be run by either of two daemons, routed or gated. Let's
first take a look at how to configure routed.

V3.1.0.1
Instructor Guide
Uempty
/etc/gated.conf
Eight Statement Classes
1. Directive
2. Trace
3. Options
4. Interface
5. Definition
6. Protocol
7. Route
8. Control
Classes 1 and 2 can appear in any order in the configuration file
The rest must appear in the above order
Figure 6-10. /etc/gated.conf AU079.1
Notes:
This file is read by the gated daemon at initialization time. All the classes are optional. By
default, if gated is started without specifying any information in the file, the RIP protocol will
be turned on in broadcast mode (active). For configuring OSPF, at a minimum, information
in the protocol class must be provided.
These classes provide the following types of configuration information to gated:
directives These statements are acted upon immediately by the parser.
They are used to specify included files and the direction in
which they reside. Unlike other statements which terminate with
a semicolon, directive statements terminate with a new line
character.
trace Statements that control tracing options.
options Allows specification of some global options
interface Specify interface options.
definition Definition Statements

Instructor Guide
autonomous system
<autonomous system>; Sets the autonomous system. This option is required if
BGP and EGP are in use.
routerid
(host>; Sets the router identification for use by the BGP and
OSPF protocols. The default is the address of the first
interfaced encountered by gated.
Martians {
<martian list> }; Defines a list of martians addresses about which all
routing information is ignored.
protocol Enable or disable protocols and set protocol options.
route Define static routes.
control Define routes that are imported from routing peers and others
that are exported to these peers.
Statements within a class may be listed in any order.

V3.1.0.1
Instructor Guide

Purpose Introduce the format and content of the /etc/gated.conf file.
Details The system comes shipped with a copy of this file with everything commented
out. The format of the file as shipped shows all the statement options that can be provided
within each statement class. Basically, the only statements that are really needed are the
protocol statements. The rest are used to further define interfaces, preference values,
time-out values, and so forth. If the default settings for any protocol are sufficient then
much of this file can be left commented. In many environments when only a small portion of
this file is needed, a new /etc/gated.conf file is created including only that information
necessary to support the desired protocol/protocols in that environment.
All statements except directive statements end in a semi-colon. Directive statements end
with a newline character. Even if there is a comment character at the beginning of the rip
protocol statement, rip is turned on as the default.
If you do not wish to have rip running, you must uncomment the line and specify no or off to
turn it off. The brackets shown in the file denote optional items and are not a part of the
statement syntax, however, the curly braces are.
Additional Information Gated Version 6.0 provides gateway routing functions for the
following protocols:
RIP
RIPng (next Generation)
EGP (exterior)
BGP and BGP4+ (border)
Hello (Defense communication)
OSPF
IS-IS (Intermediate system)
ICMP/Routing Discovery Routing
SNMP (Simple Network Management)
Also, the gdc command provides operational interface for gated. The gdc command can
reliably determine the running state of gated and produces a reliable exit status when
errors occur, making it advantageous for use in shell scripts that manipulate gated.
Transition Statement Lets take a look at the gdc command used for controlling gated.

Instructor Guide
gdc Command
Purpose
Provides an operational user interface for gated
Syntax
gdc [ -q ] [ -n ] [ -c coresize ] [ -f filesize ] [ -m datasize ]

[ -s stacksize ] [ -t seconds ] Subcommands
Figure 6-11. gdc Command AU079.1
Notes:
The gdc command provides a user-oriented interface for the operation of the gated routing
daemon. It provides support for:
Starting and stopping the daemon
The delivery of signals to manipulate the daemon when it is operating
The maintenance and syntax checking of configuration files
For the production and removal of state dumps and core dumps
The gdc command can reliably determine gateds running state and produces a reliable
exit status when errors occur, making it advantageous for use in shell scripts which
manipulate tagged. Commands executed using gdc and, optionally, error messages
produced by the execution of those commands, are logged via the same syslogd facility
which gated itself uses, providing and audit trail of operations performed on the daemon.
The following subcommands provide support for starting and stopping gated, and for
determining its running state:

V3.1.0.1
Instructor Guide
Uempty running - Determine if gated is currently running. This is done by checking to see if gated
has a lock on the file containing its pid, if the pid in the file is sensible and if there is a
running process with that pid. Exits with zero status if gated is running, non-zero otherwise.
start - Start gated. The command returns an error if gated is already running. Otherwise it
executes the gated binary and waits for up to the delay interval (10 seconds by default, as
set with the -t option otherwise) until the newly started process obtains a lock on the pid file.
A non-zero exit status is returned if an error is detected while executing the binary, or if a
lock is not obtained on the pid file within the specified wait time.
stop - Stop gated, gracefully if possible, ungracefully if not. The command returns an error
(with non-zero exit status) if gated is not currently running. Otherwise it sends a terminate
signal to gated and waits for up to the delay interval (10 seconds by default, as specified
with the -t option otherwise) for the process to exit. Should gated fail to exit within the delay
interval it is then signaled again with a second terminate signal. Should gated fail to exit by
the end of the second delay interval, it is signalled for a third time with a kill signal. This
should force immediate termination unless something is very broken. The command
terminates with zero exit status when it detects that gated has terminated, non-zero
otherwise.
restart - If gated is running it is terminated via the same procedure as is used for the stop
command above. When the previous gated terminates, or if it was not running prior to
command execution, a new gated process is executed using the procedures described for
the start command above. A non-zero exit status is returned if any step in this procedure
appears to have failed.

Instructor Guide
Instructor Notes:
Purpose Introduce the gdc command used for operation of the gated routing daemon.
Details The gdc command provides reliable information about the running state of the
gated.
Flags
-n Runs without changing the kernel forwarding table. This is useful for testing, and when
operating as a route server that does no forwarding.
-q Runs quietly. With this flag informational messages which are normally printed to the
standard output are suppressed and error messages are logged with syslogd instead of
being printed to the standard error output. This is convenient when running gdc from a shell
script.
-t seconds Specifies the time in seconds that gdc waits for gated to complete certain
operations, in particular at termination and startup. By default this value is set to 10
seconds.
-c coresize Sets the maximum size of a core dump a gated started with gdc produces. This
is useful on systems where the default maximum core dump size is too small for gated to
produce a full core dump on errors.
-f filesize Sets the maximum file size a gated started with gdc will produce. Useful on
systems where the default maximum file dump size is too small for gated to produce a full
state dump when requested.
-m datasize Sets the maximum size of the data segment of gated started with gdc. Useful
on systems where the default data segment size is too smell for gated to run.
-s stacksize Sets the maximum size of stack of a gated started with gdc. Useful on
systems where the default maximum stack size is too small for gated to run.
Subcommands
The following subcommands cause signals to be delivered to gated for various purposes:
COREDUMP Sends an abort signal to gated, causing it to terminate with a core dump.
dump Signals gated to dump its current state into the file /var/tmp/gated_dump.
interface Signals gated to recheck the interface configuration. gated normally does this
periodically in any event, but the facility can be used to force the daemon to check interface
status immediately when changes are know to have occurred.
KILL Causes gated to terminate ungracefully.
reconfig Signals gated to reread its configuration file, reconfiguring its current state as
appropriate.
term Signals gated to terminate after shutting down all operating routing protocols
gracefully. Executing this command a second time causes gated to terminate even if some
protocols have not yet fully shut down.

V3.1.0.1
Instructor Guide
Uempty toggletrace Causes tracing to be suspended, and if gated is currently trading to a file,
closes the trace file. If gated tracing is currently suspended, this subcommand causes the
trace file to be reopened and tracing initiated. This is useful for moving trace files.
Additional Information The following subcommands perform operations related to
configuration files:
checkconf Check /etc/gated.conf for syntax errors. This is usefully done after changes to
the configuration file but before sending a reconfig signal to the currently running gated, to
ensure that there are no errors in the configuration which would cause the running gated to
terminate on reconfiguration. When this command is used, gdc issues an informational
message indicating whether there were parse errors or not, and if so saves the error output
in a file for inspection.
checknew Like checkconf except that the new configuration file,
/etc/gated.conf+, is checked instead.
newconf Move the /etc/gated.conf+ file into place as /etc/gated.conf, retaining the older
versions of the file as described above. gdc will decline to do anything when given this
command if the new configuration file doesn't exist or otherwise looks suspect.
backout Rotate the configuration files in the newer direction, in effect moving the old
configuration file to /etc/gated.conf. The command declines to perform the operation if
/etc/gated.conf- doesn't exist or is zero length, or if the operation would delete an existing,
non-zero length /etc/gated.conf+ file.
BACKOUT Perform a backout operation even if /etc/gated.conf+ exists and is of non-zero
length.
modeconf Set all configuration files to mode 664, owner root, group system.
createconf If /etc/gated.conf+ does not exist, create a zero length file with the file mode set
to 664, owner root, group system.
The following subcommands allow the removal of files created by the execution of some of
the commands above:
rmcore Removes any existing gated core dump file.
rmdump Removes any existing gated state dump file.
rmparse Removes the parse error file generated when a checkconf or checknew
command is executed and syntax errors are encountered in the configuration file being
checked.
Transition Statement Let's now see whats set up of RIP might look like in the
gated.conf file.

Instructor Guide
Configuring RIP Using the gated Daemon

Example of a Simple RIP Running in Quiet Mode:
traceoptions all ;
tracefile "/var/tmp/rip.quiet.trace" replace size 50k files 4 ;
rip yes {
nobroadcast ;
};
Example of a Simple RIP Supplier
# options nosend ;
rip yes {
broadcast ;
interface en3 noripout
trustedgateways 10.19.99.3 ;
};
Figure 6-12. Configuring RIP Using the gated Daemon AU079.1
Notes:
Although configuring the routed is much simpler than configuring the gated daemon, there
are some good reasons to use gated rather than routed. They are:
gated supports multiple routing protocols and in today's environment most networks are
using more than one routing protocol.
gated supports RIP2 protocol whereas routed only supports RIP1. The RIP2 protocol
can handle variable subnets, RIP1 does not.
The first example above configures gated to run RIP in quiet mode. It only listens to
packets no matter how many interfaces are configured. If it was required, RIP running in
quiet mode can be used to UNICAST RIP information to particular hosts / gateways on the
network by supplying the sourcegateways option, as shown below:

V3.1.0.1
Instructor Guide
Uempty rip yes {

nobroadcast;
sourcegateways 10.19.99.5;
}
It also shows an example of how to trace output. The way tracing is set up provides for the
creation of four files to be stored in the directory /var/tmp starting with rip.quiet.trace and
then numbered rip.quiet.trace.0, and so forth, to rotate the trace information. It allows for
the files to grow to about 50k before rotating to the next file.
The second example allows this system to supply (broadcast) RIP packets on all interfaces
except en3 and only listen to RIP packet update information coming from gateway
10.19.99.3. The option nosend is commented out and has no effect when gated is running.
However, if it were uncommented it would allow us to run RIP on a live network to test
interfaces without participating in the dynamic routing environment. The packet traces in
the gated log can be examined to verify the gated is functioning properly.

Instructor Guide
Instructor Notes:
Purpose Provide a sample of setting up RIP in both quiet and active mode using the
/etc/gated.conf file.
Details When using the /etc/gated.conf file if you do not specify the rip clause, the
default is for rip to be on. The protocol statement has the following options:
rip yes | no | off [ }
broadcast ;
nobroadcast ;
preference <preference> ;
defaultmetric <metric> ;
interface <interface_list> [noripin] [noripout]
[metricin <metric>] [metricout <metric>]
[version 1] | [version 2 [multicast | broadcast]] ;
trustedgateways <gateway_list> ;
sourcegateways <gateway_list> ;
traceoptions <traceoptions> ;
} ] ;
The broadcast option indicates this system is a supplier (active). The nobroadcast option
indicates it is running in quiet (passive) mode. The nocheckzero option specifies RIP
should not ensure that reserved fields in the RIP packets are zero.
If the version is specified as 1 or defaults to 1, RIP version 2 packets are never sent except
in response to a version 2 POLL packet.
Preference controls the choice of routes learned via this protocol.
The defaultmetric value defaults to the highest valid metric of 16 which signifies infinity
(lack of reachability).
The trustedgateways clause supplies a list of gateways providing valid routing information.
Routing packets from other gateways are ignored.
The default metricout is zero and the default metricin is the kernel interface metric plus 1
(the default RIP hop count).
Traceoptions can be set up outside of the protocol statement in the trace statements
section of the /etc/gated.conf file, as shown in the example, or within the protocol
statement itself.
Transition Statement With the tremendous expansion in networks, RIP's capabilities
have been stretched to its limit. Another protocol has been developed, OSPF. Let's take a
brief look at it.

V3.1.0.1
Instructor Guide
Uempty
Open Shortest Path First (OSPF)
Interior gateway protocol
Link state routing protocol
RT05
RT02 RT09 RT12
RT01 RT03 RT06 RT10 RT13

Path
RT04 RT14
RT07 RT11
RT08
All nodes have a copy of the network map
Figure 6-13. Opening Shortest Path First (OSPF) AU079.1
Notes:
Link state protocols are based on a distributed map concept. All nodes have a copy of the
network map. The map is actually represented by a database and updates are flooded to
the network nodes. The map updates must be secured.
In a link state protocol each router is responsible for determining the identity of its
neighbors. The router must construct a so-called link state package (LSP) which lists its
neighbors and the cost of the link to each. A link state packet is transmitted to all other
routers which then store the most recent LSP received from each router. Given this
information, it is possible to construct a link state packet database from which routes
through the network can be calculated. A link state packet database is what the above
graphic represents. The solid line arrow shows the shortest path from router 01 (RT01) to
RT12, RT13, and RT14 that it calculated on the basis of the information provided to it from
the other routers.
Autonomous systems using OSPF as their routing protocol consist of, at a minimum, a
backbone of neighboring OSPF gateways. In particularly large networks it may include one
or more areas in addition to the backbone.

Instructor Guide
Instructor Notes:
Purpose Introduce OSPF and link state protocol basic concepts.
Details OSPF is a link state protocol developed by the IETF for use in the Internet and is
the recommended protocol as a replacement for RIP.
An in-depth discussion of link state protocols in general and OSPF in particular is beyond
the scope of this class. OSPF is a fairly complex protocol and to understand it thoroughly
would take several days. However, students need to know of its existence and the basic
differences between it and the commonly-used RIP protocol. In this visual we provide a
high-level definition of what a link state protocol is and in the next its advantages over the
more traditional distance vector protocols such as RIP. The visual provides a graphical
representation of a path map stored on router01 (RT01). The solid line shows the shortest
path that is calculated to routes 12, 13 and 14 based on criteria provided during the router's
configuration and the information provided by the other routers.
Basically, a link state protocol is designed to use a database that completely maps the
routes within an autonomous system including the routes to exterior gateways for
communications outside of the autonomous system. Gateways send updates regularly to
neighboring gateways which compare the new map to the old, recalculating link costs and
updating their routing database. If a link has a lower cost than another to the same
destination, it becomes the preferred route but the information regarding the higher-cost
route does not get deleted. If two routes have the same cost then both routes are used to
share the workload across the links.
Broadcast, non-broadcast, and point-to-point networking technologies are supported. Also,
different metrics are supported and are converted to a common preference value. This
preference value can be specified by the network administrator so that a site can place a
greater or lesser importance on things like distance, throughput, or line reliability.
Additional Information To handle map update security, OSPF includes protections
against the problems of:
Failures in the synchronization process
Stale records kept in the database
Memory errors
Intentional corruption
It provides its protection against these through the implementation of:
Hop-by-hop acknowledgements during flooding
Database description packets transmitted using secure mechanisms
A timer so that records are removed from the database if a refresh packet doesn't arrive
in the expected timeframe
All records are protected by checksum procedures
Messages can be authenticated by the use of passwords
Transition Statement To handle extremely large networks OSPF uses a concept of a
backbone with multiple areas attached. Let's look at this a little bit closer.

V3.1.0.1
Instructor Guide
Uempty
OSPF Areas
A1 B1 C1
R1A R3AB R5CB R7C
B
A2 B2
a B6 C2
Area A Area C
c
k
R2A R4AB R6CB R8C
A3 b C3
o
B3 B5
n
e B4
R9B R10B
R11B
RIP v2
Network
Figure 6-14. OSPF Areas AU079.1
Notes:
This network contains three areas: A, backbone (area 0), and C.
Routers R1A, R2A from area A, R7C, R8C from area C and R9B, R10B from area
backbone are known as Intra-Area Routers. Intra-Area routers maintain a topology
database for their local area.
Routers R3AB, R4AB from area A and R5CB, R6CB from Area C are known as Area
Border Routers (ABR). These ABR routers summarize the information from the other areas
in order to limit the size of the link state database and the number of advertisements.
R11B from area backbone is an Autonomous System Border Router (ASBR) and is located
at the periphery of the OSPF internetwork. It functions as a gateway exchanging routing
information with other routing environments, in the example shown a RIP v2 network.
These routes become OSPF external routes. The ASBR advertises these external routes
by flooding them throughout the entire OSPF network.

Instructor Guide
Instructor Notes:
Purpose Show how a backbone and areas are set up in OSPF.
Details The size of the database, the duration of route computation, and volume of
messages increase substantially when the size of the network increases. In order to handle
very large networks, OSPF uses the concept of areas into which the network is divided with
the upper part called the backbone.
In order to pull the whole network together, some routers belong to several areas, typically
one lower-level area, and to the backbone area. These routers are called area-border
routers. One must exist in each area to connect the area to the backbone. They maintain a
link state database for each area to which they belong.
The area routers summarize the information. Thus, in our example, the database of area A
will contain:
The link state records corresponding to links A1, A2, and A3 sent by R1A, R2A, R3AB,
and R4AB
Summary records provided by R3AB and R4AB for the networks and subnets that are a
part of the backbone and Area C
Records sent by R9B and R10B and relayed by R3AB and R4AB.
Transition Statement Let's now see what a setup of OSPF might look like in the
gated.conf.file.

V3.1.0.1
Instructor Guide
Uempty
Configuring OSPF Using the gated Daemon
interfaces {
options scaninterval 60 ;
interface all passive ;
}
martians {
128.12.0.0
};
rip no;
ospf yes {
area 1.0.0.0 {
authtype none ;
networks {
10.19.98.0 mask 255.255.255.0 ;
10.19.99.0 mask 255.255.255.0 ;
};
};
backbone {
authtype simple ;
interface all {
authkey "password" ;
};
networks {
10.25.100.0 mask 255.255.0.0
};
};
};
Figure 6-15. Configuring OSPF Using the gated Daemon AU079.1
Notes:
The configuration specified by this file is as follows:
The interface statement specifies that all interfaces on this system are passive. Without
this option, grated assumes that an interface is down if no routing information has been
received recently.
- scaninterval 60 specifies how often the gated scans the interface list for changes in
seconds.
The martian statement defines a list of addresses to which all routing information will be
ignored,
The rip no statement disables RIP
The ospf yes enables OSPF and the gives several configuration options.
- Area option sets the area number for this system
- Authtype none specifies no authentication should be used for exchanging
information between OSPF routers
- Authtype simple specifies simple password authentication. The password is
specified in the authkey statement.
- Networks option specifies the networks that are part of the area

Instructor Guide
Instructor Notes:
Purpose Explain statements in the gated configuration file.
Details Refer to RFC 2328 for details of OSPF Version 2.
Transition Statement Now, let's take a look at a few checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (1 of 2)
1. T/F: The gated and routed daemons can be run at the same time.
2. The routed daemon supports the following protocols. (Choose all
that apply.)
a. OSPF
b. HELLO
c. RIP
d. EGP
3. The gated daemon supports the following routing protocols.
(Choose all that apply.)
a. BGP
b. RIP
c. OSPF
d. IP
4. T/F: Distance vector protocols measure cost via a metric called
hops.
5. T/F: OSPF is a distance vector protocol.
Notes:

Instructor Guide
Instructor Notes:
Purpose
Details
False. Unpredictable results occur if they are running on the same system at the
same time.
that apply.)
a. OSPF
b. HELLO
c. RIP - routed only supports RIP
d. EGP
a. BGP
b. RIP
c. OSPF
d. IP
hops. True.
5. T/F: OSPF is a distance vector protocol. False. OSPF is a link state
protocol.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (2 of 2)
6. The following characteristics describe a link state protocol. (Select
all that apply.)
a. Uses only a hop metric to determine cost
b. Maintains a database map of all links in the network
c. Provides for authorization of routers and update packets
7. T/F: The /etc/gated.conf file contains statements classes that are
read by the gated daemon on start-up.
8. What routing protocol does the gated daemon use by default?
(Select all that apply.)
a. RIP
b. RIP-2
c. OSPF
d. BGP
Notes:

Instructor Guide
Instructor Notes:
Purpose
Details
all that apply.)
read by the gated daemon on start-up. True.
a. RIP - RIP in broadcast mode/active/.
b. RIP-2
c. OSPF
d. BGP

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Notes:

Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
In active mode a host can send and receive routing information. In
passive mode it only receives it.
An autonomous system is a group of networks under one
administrative authority.
Interior gateways are routers within an autonomous system.
Exterior gateways are routers that connect autonomous systems
together.
RIP and OSPF are used on interior gateways and BPG on exterior
ones.
Notes:

Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty Unit 7. Shared Ethernet Adapter

This unit introduces the shared Ethernet adapter (SEA) that serves as
a layer 2 network bridge to securely transport network traffic from a
virtual Ethernet adapter to a real network adapter. Discussion includes
the Virtual I/O Server environment which is required for the shared
Ethernet adapter server.

Describe functions of the Virtual I/O Server
Configure Virtual I/O Server
Describe shared Ethernet adapter service
Configure shared Ethernet adapter
Describe Etherchannel support

Accountability:
Checkpoint
Machine exercises
References
IBM Training course:
AU73 Logical Partitioning (LPAR) on POWER5 pSeries
Systems
http://www-03.ibm.com/servers/aix/whitepapers/aix_vn.pdf
Virtual Networking on AIX 5L (whitepaper)
Introduction and Basic Configuration
Copyright IBM Corp. 1997, 2006 Unit 7. Shared Ethernet Adapter 7-1
Instructor Guide
Architecture and Performance Considerations
http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/index.jsp
-> Printable PDFs
-> Using the Virtual I/O Server
System p5 and i5, eServer p5 and i5 and OpenPower
Using the Virtual I/O Server
System p5, eServer p5 and i5 and OpenPower
Virtual I/O Server Commands Reference

V3.1.0.1
Instructor Guide
Uempty
Unit Objectives
Describe functions of the Virtual I/O Server
Configure Virtual I/O Server
Describe shared Ethernet adapter service
Configure shared Ethernet adapter
Describe Etherchannel support
Notes:
Instructor Guide
Instructor Notes:
Purpose Describe the objectives for the unit.
Details
Transition Statement In this unit, we will be discussing the shared Ethernet adapter
functionality that is available with the IBM System p5 family of servers. In order to use
shared Ethernet adapter, you must configure the Virtual I/O Server, so well start our
discussion with an overview of the Virtual I/O Server.

V3.1.0.1
Instructor Guide
Uempty
Virtual I/O Server Overview
Special partition that hosts virtual SCSI disk and shared Ethernet
adapter resources
Allows resources to be used by client partitions
4 2 6
6 CPUs
Virtual I/O CPUs CPUs CPUs
Server
Partition
Linux AIX5.3 AIX5.3
AIX 5.3
AIX 5.3
AIX 5.3
Linux
Linux
Virtual Ethernet
Disks Sharing
Virtual I/O paths

POWER Hypervisor
I/O I/O I/O I/O
Storage Network Storage Network Storage Network Storage Network
Hardware
Management
Console
(HMC)
LAN, WAN, ...
Figure 7-2. Virtual I/O Server Overview AU079.1
Notes:
Introduction
The Virtual I/O Server provides virtual storage and shared Ethernet capability to client
logical partitions on the system. It allows physical adapters on the Virtual I/O Server to
be shared by one or more client partitions. Virtual I/O Server partitions are not intended
to run applications or for general user logins. The Virtual I/O Server is installed in its
own partition.
Using the Virtual I/O Server facilitates the following functions:
- Sharing of physical resources between partitions on the system
- Creation of partitions without requiring additional physical I/O resources
- Creation of more partitions than I/O slots or physical devices with the ability for
partitions to have dedicated I/O, virtual I/O, or both
- Maximization of physical resource utilization on the system
Instructor Guide
The Virtual I/O Server supports client partitions running the following operating
systems:
- AIX 5L V5.3
- SUSE LINUX Enterprise Server 9 for POWER
- Red Hat Enterprise Linux AS for POWER Version 3

V3.1.0.1
Instructor Guide

Purpose Introduce the Virtual I/O Server.
Details Explain that the VIO Server is its own partition set up for the purpose of hosting
SCSI and shared Ethernet adapters to other partitions. The VLAN topic that we just
covered does not need the VIO Server partition or software.
Transition Statement Lets examine some of the details of the Virtual I/O Server
product.
Instructor Guide
Virtual I/O Server Details

Component of Advanced POWER Virtualization feature
Currently implemented as customized AIX-based appliance
Supplied on CD media as an AIX mksysb image
Simple Command Line Interface (CLI) supported
Can only be run in special Virtual I/O Server partitions
Up to four VIO Server partitions supported per system
Can use dedicated processors or shared processor pool
Must have physical I/O slots for storage and networking
Can be installed from HMC or by booting from CD
Figure 7-3. Virtual I/O Server Details AU079.1
Notes:
Details
The Virtual I/O Server is a component of the Advanced POWER Virtualization
chargeable feature. The product is supplied on CD-ROM media when the feature is
configured as part of machine order or upgrade.
Currently the Virtual I/O Server is implemented as a customized AIX partition, however
the interface to the system is abstracted using a secure shell-based Command Line
Interface (CLI).
The CD-ROM media contains a customized AIX mksysb image. Once installed on disk,
the image only boots in a special type of partition that provides the special Virtual I/O
Server environment.
The partition that is used for the Virtual I/O Server must be configured to contain
physical adapter slots, since the partition is used to host these resources and make

V3.1.0.1
Instructor Guide
Uempty them available for use by client partitions. The partition may be configured to use
dedicated processors, or processing capacity from the shared processor pool.
The Virtual I/O Server partition may be installed by activating the partition and booting
directly from the CD-ROM device. The partition may also be installed from the HMC.
Instructor Guide
Instructor Notes:
Purpose Cover some of the details of the Virtual I/O Server.
Details The VIO Server software comes with the IBM System p5 if the Advanced
POWER Virtualization feature is ordered with the system or if this feature comes standard
with the system. You must load the software in a partition and configure the devices.
Transition Statement Lets look at creating a partition for the Virtual I/O Server.

V3.1.0.1
Instructor Guide
Uempty
Configuring the Virtual I/O Server (1 of 2)
Perform initial login using special userid padmin
You are prompted to change password
Need to accept license for Virtual I/O Server product:
license accept
Use mktcpip command to configure networking (if not configured
during installation from HMC)
mktcpip hostname hostname inetaddr IPaddress \
-interface interface [ start ] [ netmask nmask ] \
[ -cabletype ctype ] [ -gateway gway ] \
[ -nsrvaddr NameServerAddr [ -nsrvdomain Domain ] ]
Figure 7-4. Configuring the Virtual I/O Server (1 of 2) AU079.1
Notes:
Introduction
Since the CLI is used to configure the Virtual I/O Server, the root user login is not used.
Instead, you should log in to the partition using the userid padmin. This is the login for
the Prime Administrator of the Virtual I/O Server partition.
The first time the padmin user logs in, you are prompted to change the password. Once
you have entered a new password, you will be logged in using the secure Korn shell.
The first task you should perform is to accept the license terms for the Virtual I/O Server
product. This is performed with the following command:
license -accept
If you do not accept the license terms, the remainder of the CLI will not function. If the
partition was installed from the HMC, then the network interface may still be configured
(depending on the options you selected when running the installios command).
Instructor Guide
If the network interface is not configured (for example, you installed the partition directly
from CD), then the next configuration task is to set the partition hostname and IP
address. This is performed using the mktcpip command as follows:
mktcpip hostname hostname inetaddr IPaddress -interface interface \
[ start ] [ netmask nmask ] [ -cabletype ctype ] [ -gateway gway ] \
[ -nsrvaddr NameServerAddr [ -nsrvdomain Domain ] ]

V3.1.0.1
Instructor Guide

Purpose Cover the initial steps used to configure the basic setup of the Virtual I/O
Server partition.
Details Once the VIO server software is installed, you must login, accept the software
license, and do basic network setup. This information is continued on the next visual.
Additional Information The current and next visual cover the basic setup of the Virtual
I/O Server partition itself. We detail later how to configure devices for use by client
partitions.
Transition Statement Once weve set the hostname, we should set the date and time.
Instructor Guide
Configuring the Virtual I/O Server (2 of 2)

Set date, time and time zone
Encapsulated date command cannot set date/time
Must use oem_setup_env command first
Provides access to root shell with access to underlying O/S
Can then use chtz command
Consider creating additional users with mkuser command
Much like HMC, different user types are supported:
Prime administrator (can only be one of this type padmin)
System administrator
Service Representative
Development Engineer
Figure 7-5. Configuring the Virtual I/O Server (2 of 2) AU079.1
Notes:
More configuration steps

Once weve configured the hostname and IP address of the partition, the next thing we
should do is configure the time and date, and the time zone setting.
The CLI currently does not encapsulate the AIX commands required to change the date
and time, or set the time zone. In order to correctly adjust these values, you should use
the oem_setup_env command. The main purpose of this command is to provide a root
shell for use when installing and configuring software for use with complex storage
solutions, for example, for adding device drivers for IBM TotalStorage Enterprise
Storage Server products. The oem_setup_env command allows the padmin user to get
a root shell, where you can use the SMIT command to configure the time, date, and
time zone setting.

V3.1.0.1
Instructor Guide

Purpose Cover more Virtual I/O Server configuration steps.
Details The oem_setup_env command is convenient to open up a standard AIX 5L V5.3
shell where AIX commands (such as smit) can be executed. Use exit to exit out of the
shell and return to the VIO server CLI.
Additional Information The developers of the Virtual I/O Server command didnt
design the interface to encapsulate the date or chtz commands for use by padmin. Maybe
they think that all Virtual I/O Server partitions will be in the Central US time zone?
Transition Statement Now that weve configured the Virtual I/O Server, lets look at
how we make devices available for use by client partitions. The first type well cover is the
shared Ethernet adapter.
Instructor Guide
Shared Ethernet Adapter Overview

Shared Ethernet adapter bridges external networks to internal VLANs
Forwards frames at OSI Layer 2 and is transparent to IP layer
Means partitions using virtual Ethernet can access outside world
Virtual Ethernet MAC address is visible to outside systems
Broadcast/Multicast, ARP, and NDP support
Handles physical/virtual MTU mismatch
Fragment IPv4 packets, or generate ICMP to aid PMTU discovery
Generate ICMPv6 for PMTU discovery for IPv6
Three components
Physical Ethernet adapter (or aggregation of several physical adapters)
Connection to the external network
One or more virtual Ethernet adapters
Connection to LPAR virtual Ethernet adapters
Shared Ethernet adapter
The bridge
Figure 7-6. Shared Ethernet Adapter Overview AU079.1
Notes:
Overview
Shared Ethernet adapter (SEA) technology (part of the optional Virtual I/O server
feature on POWER5 hardware) enables the logical partitions to communicate with other
systems outside the hardware unit without assigning physical Ethernet slots to the
logical partitions.
When there are not enough physical slots to allocate a physical network adapter to
each partition, network access using virtual Ethernet and shared Ethernet adapters in a
Virtual I/O server is preferable to IP forwarding as it does not complicate the IP network
topology.
A shared Ethernet adapter is a bridge between a physical Ethernet adapter or
aggregation of physical adapters and one or more virtual Ethernet adapters on the
Virtual I/O server. A SEA enables partitions on the virtual Ethernet to share access to
the physical Ethernet and communicate with standalone server and partitions on other
systems. The Shared Ethernet provides this access by connecting the internal

V3.1.0.1
Instructor Guide
Uempty Hypervisor VLANs with the VLANs on the external switches. This enables partitions on
POWER5 systems to share the IP subnet with stand alone systems and other
POWER5 partitions to allow for a more flexible network.
Link aggregation (also known as EtherChannel) is a network port aggregation
technology that allow several Ethernet adapters to be aggregated together to form a
single pseudo Ethernet device.
Bridge
As the Shared Ethernet processes packets at layer 2, the original MAC address and
VLAN tags of the packet are visible to other systems on the physical network.
MTU issues
The virtual Ethernet adapters can transmit packets with a size up to 65408 bytes.
Therefore, the maximum MTU for the corresponding interface can be up to 65394
(65390 with VLAN tagging). Since the shared Ethernet adapter can only forward
packets of a size up to the MTU of the physical Ethernet adapters, a lower MTU or
PMTU discovery should be used when the network is being extended using the Shared
Ethernet.
Most packets including broadcast (for example, ARP) or multicast (for example,
Network Discovery Packet (NDP)) packets that pass through the Shared Ethernet setup
are not modified. These packets retain their original MAC header and VLAN tag
information. When the MTU of the physical and virtual side do not match this can result
in the Shared Ethernet receiving packets that cannot be forwarded because of MTU
limitations. This situation is handled by processing the packets at the IP layer by either
doing IP fragmentation or reflecting ICMP errors (packet too big) to the source based on
the IP flags in the packet. In the case of IPv6, the packets ICMP errors are sent back to
the source as IPv6 allows fragmentation only at the source host. These ICMP errors
help the source host discover the PMTU and therefore handle future packets
appropriately.
Instructor Guide
Instructor Notes:
Purpose Introduce the shared Ethernet adapter device.
Details Now that the VIO Server software is installed and configured, we will configure a
shared Ethernet adapter (SEA). This visual describes the SEA device features.
Transition Statement Lets look at an example that illustrates the function of the shared
Ethernet adapter.

V3.1.0.1
Instructor Guide
Uempty
Shared Ethernet Adapter Example
Shared Ethernet is used to extend VLAN 100 and 200 using the
physical Ethernet in the VIO server
Standalone servers
LPAR 1, 2, 3
VIO Server
Shared
Ethernet
VLAN 100 VLAN 100

VLAN 200
VLAN 200
Ethernet Switch
Managed system
Figure 7-7. Shared Ethernet Adapter Example AU079.1
Notes:
Details
Shared Ethernet technology is used to extend VLAN 100 and 200 using the physical
Ethernet resources in the Virtual I/O server. The configuration could consist of one or
two physical Ethernet adapters in the Virtual I/O Server partition.
Instructor Guide
Instructor Notes:
Purpose Graphically illustrate the purpose of a shared Ethernet adapter.
Details This visual shows an example VIO Server partition with a physical Ethernet
adapter that connects to the network outside of the managed system. It is connected to
VLAN 100 and 200.
Transition Statement Lets look at how we configure a virtual Ethernet adapter for use
by the Virtual I/O Server to connect the interpartition network to the outside physical
network.

V3.1.0.1
Instructor Guide
Uempty
Adding External Access
Virtual Ethernet adapter to be used in a shared Ethernet adapter
must have Access external network attribute set
This attribute was called Trunk adapter prior to VIOS version 1.2
Causes virtual Ethernet to accept/deliver external packets
Access external network setting only for VIOS adapters
Only one Access external network adapter per VLAN
Figure 7-8. Adding External Access AU079.1Notes
Access external network

If you want the internal network to be connected to the external physical network, then
the virtual Ethernet adapter that is used by the Virtual I/O Server should have the
Access external network setting enabled. This setting is changed on the Virtual
Ethernet Adapter Properties dialog box.
The Access external network setting causes the virtual Ethernet adapter to operate in
a special mode so that it can deliver and accept external packets from the POWER5
internal switch to the external physical switches. The Access external network setting
should only be used for the virtual Ethernet adapters that are part of a shared Ethernet
setup in the Virtual I/O server. A virtual Ethernet adapter with this setting becomes the
virtual Ethernet trunk adapter for all the VLANs that it belongs to. Since there can only
be one virtual Ethernet adapter with the trunk setting per VLAN, any overlap of the
VLAN memberships should be avoided between the virtual Ethernet trunk adapters.
Instructor Guide
Instructor Notes:
Purpose Show how to configure the trunk adapter setting of a virtual Ethernet adapter.
Details This visual shows how to configure the virtual Ethernet adapter on the VIO
Server when it is used as a SEA. You must check the Access external network option.
Each VLAN can only have one designated trunk adapter. When you add additional VLANs
for this trunk adapter, this must be the only trunk adapter for all of those VLANs.
Transition Statement Lets look at how we then create the shared Ethernet adapter
itself.

V3.1.0.1
Instructor Guide
Uempty
Shared Ethernet Adapter Bridge (1 of 3)
ent0 ent1 (virtual)

(physical) PVID=100
ent2 (SEA)
PVID=100
Command to create shared Ethernet adapter:

$ mkvdev sea ent0 vadapter ent1 \
default ent1 defaultid 100
Creates device (ent2 in this case)

$ lsdev virtual
name status description
ent2 Available Shared Ethernet Adapter
Figure 7-9. Shared Ethernet Adapter Bridge (1 of 3) AU079.1
Notes:
Details
Shared Ethernet adapters (SEAs) are configured in the Virtual I/O server partition.
Setup of a SEA requires one or more physical Ethernet adapters assigned to the Virtual
I/O Server partition and one or more virtual Ethernet adapters with the Access external
network property defined using the HMC.
The physical side of the SEA is either a single Ethernet adapter or a link aggregation of
physical adapters. The link aggregation can also have an additional Ethernet adapter as
a backup in case of failures on the network.
Example
The visual above shows a simple shared Ethernet adapter scenario. The shared
Ethernet adapter ent2 uses physical adapter ent0 and virtual adapter ent1. The
physical adapter ent0 is connected to a physical Ethernet switch which does not have
Instructor Guide
to be VLAN capable because only PVID is being used in this setup. If the switch is
VLAN capable then the port that the physical adapter ent0 connects to should be set up
as an untagged port with PVID 100. The virtual adapter is created with PVID 100 and
the trunk adapter attribute using the HMC. The following Virtual I/O server command
will configure the Shared Ethernet and will effectively connect the LPARs using VLAN
100 to the physical network:
mkvdev sea ent0 vadapter ent1 default ent1 defaultid 100
Handling multiple VLANs

A single SEA setup can connect multiple VLAN networks to the external network.
The defaultid flag identifies the PVID for the SEA. That means that any outgoing
packets tagged with this VLAN ID will have the VLAN ID field stripped from the packet
before being sent to the external network.
The default flag identifies the default virtual adapter. That means that any incoming
untagged packets received from the physical side will be sent to the default adapter and
tagged with the PVID of the default adapter.
Configuration limits
A single SEA setup can have up to 16 virtual Ethernet trunk adapters, and each virtual
Ethernet trunk adapter can support up to 20 VLAN networks. Therefore, it is possible for
a single physical Ethernet to be shared between 320 internal VLAN. The number of
shared Ethernet adapters that can be set up in a Virtual I/O server partition is limited
only by the resource availability as there are no configuration limits.
The physical and virtual adapters that are part of a shared Ethernet adapter
configuration are for exclusive use of the SEA and therefore can not be configured with
IP addresses. The SEA itself can be configured with an IP address to provide network
connectivity to the Virtual I/O server. The configuration of an IP address for the SEA is
optional as it is not required for the device to perform the bridge function at layer 2.

V3.1.0.1
Instructor Guide

Purpose Give a simple example of configuring a shared Ethernet adapter.
Details Once you configure the SEA in the HMC application, you must use the mkvdev
command on the VIO server partition to configure the virtual device. In the example on the
visual, the command associates the SEA ent0 physical device with the virtual ent1 device
and creates the ent2 virtual device.
Additional Information Note that the shared Ethernet adapter does not have to be
configured with an IP address, since the bridge function is accomplished at layer 2.
Transition Statement Lets look at a more complex example involving multiple VLAN
IDs.
Instructor Guide

ent1 (virtual)
VID 200,300 ent0 PVID=2 VID 200
(physical)
ent2 (virtual)
PVID=3
VID 300
ent3 (SEA)
PVID=2
Command to create shared Ethernet adapter:

$ mkvdev sea ent0 vadapter ent1,ent2 \
default ent1 defaultid 2
Device listing:
$ lsdev virtual
Notes:
Multiple VLAN example

The shared Ethernet adapter ent3 uses physical adapter ent0 and virtual adapters ent1
and ent2. The physical adapter ent0 is connected to a physical Ethernet switch which is
VLAN capable and the port should be set up as a tagged port with PVID 2, VID 200 and
VID 300.
The virtual adapter ent1 is created with PVID 2 and VID 200 and the trunk attribute
using the HMC. The virtual adapter ent2 is created with PVID 3 and VID 300 and the
trunk attribute.
The Shared Ethernet can only provide PVID connectivity to one of the virtual adapters
and VLAN 2 was chosen as the default PVID in this example. The PVID 3 for virtual
adapter ent2 is used only because one cannot create a virtual adapter without a PVID
and any other unused PVID value could have been used here. The following Virtual I/O

V3.1.0.1
Instructor Guide
Uempty server command configures the Shared Ethernet and effectively connects the partitions
on VLAN 2, 200 and 300 to the physical network:
mkvdev sea ent0 vadapter ent1 ent2 default ent1 defaultid 2
Instructor Guide
Instructor Notes:
Purpose Show an example that uses multiple VLANs.
Details This example shows the same mkvdev command we saw in the last visual,
except this time we show the syntax when associating two virtual LANs to one SEA. This
creates the ent3 virtual adapter.
Transition Statement Lets look at using a link aggregate device with the shared
Ethernet adapter.

V3.1.0.1
Instructor Guide
Uempty
Switch with
ent0
support for ent3 ent2 (virtual)
link ent1 PVID=1
(aggregate)
aggregation
(physical)
ent4 (SEA)
PVID=1
Create link aggregation Ethernet adapter:

$ mkvdev lnagg ent0,ent1
Create shared Ethernet adapter:
$ mkvdev sea ent3 vadapter ent2 default ent2 defaultid 1
Device listing:
$ lsdev | grep ^ent
ent0 Available 10/100 Mbps Ethernet PCI Adapter II
ent1 Available 10/100 Mbps Ethernet PCI Adapter II
ent3 Available EtherChannel / IEEE 802.3ad Link Aggregation
Notes:
Link aggregation
A link aggregate pseudo Ethernet device can be used when configuring a shared
Ethernet adapter.
Link aggregation (also known as EtherChannel) is a network port aggregation
technology that allows several Ethernet adapters to be aggregated together to form a
single pseudo Ethernet device. For example, ent0 and ent1 can be aggregated to form
ent3; interface en3 would then be configured with an IP address. The system considers
these aggregated adapters as one adapter. Therefore, IP is configured over them as
over any Ethernet adapter. In addition, all adapters in the link aggregation are given the
same hardware (MAC) address, so they are treated by remote systems as if they were
one adapter. The main benefit of link aggregation is that they have the network
bandwidth of all of their adapters in a single network presence. If an adapter fails, the
packets are automatically sent on the next available adapter without disruption to
Instructor Guide
existing user connections. The adapter is automatically returned to service on the link
aggregation when it recovers.
Example
The visual above shows an example of using a link aggregate device in a shared
Ethernet configuration. The link aggregate device ent3 is created by combining ent0
and ent1 as follows:
mkvdev lnagg ent0,ent1
The ent3 device is then used when creating the shared Ethernet adapter:
mkvdev sea ent3 vadapter ent2 default ent2 defaultid 1

V3.1.0.1
Instructor Guide

Purpose Show an example of using link aggregation with the SEA.
Details The visual shows an example of using multiple physical devices (ent0 and ent1)
aggregated into the virtual device ent3.
The first mkvdev command on the visual shows how to aggregate the physical devices.
The last mkvdev command shows how you use the aggregate device (ent3 in this case)
instead of the physical device as shown on previous visuals. This command creates a
virtual adapter ent4.
Transition Statement Let's look at EtherChannel support in more detail.
Instructor Guide
What is Link Aggregation? (1 of 2)

Link aggregation groups several Ethernet links
Traffic is distributed across the links
When a link fails, traffic is redirected to remaining links with
minimal packet loss
Several different aggregation technologies
Etherchannel
Invented in early 1990s
Purchased by Cisco in 1994
Adaptec's Duralink trunking
Nortel MultiLink Trunking (MLT)
IEEE 802.3ad link aggregation standard
Figure 7-12. What is Link Aggregation? (1 of 2) AU079.1
Notes:
Link aggregation
Etherchannel is a trunking technology that allows grouping several Ethernet links and is
capable of load balancing traffic across those links. Traffic is distributed across the
links, providing higher performance and redundant parallel paths. When a link fails,
traffic is redirected to the remaining links within the channel without user intervention
and with minimal packet loss.
EtherChannel was invented in the early 1990s and bought by CISCO in 1994. Other
Popular trunking technologies exist: Adaptec's Duralink trunking and Nortel MultiLink
Trunking (MLT).
IEEE 802.3ad (Also known as Trunking or Link Aggregation) was finalized in 2000.

V3.1.0.1
Instructor Guide

Purpose Introduce link aggregation.
Details
Transition Statement Lets take a look at what AIX supports.
Instructor Guide
What is Link Aggregation? (2 of 2)

en5
10.9.19.91
ent1 08:00:5a:75:02:3d
ent5 10.9.19.91
ent2 02:60:80:e8:60:72 Ethernet
(link agg device) 08:00:5a:75:02:39
ent3 08:00:5a:d8:26:63 switch (from outside)
08:00:5a:75:02:39
ent4 08:00:5a:25:13:6e
Link aggregation device sends/receives across all the member adapters
Compatible switch is required
AIX 5L supports two types of link aggregation:
Etherchannel:
Cisco style link aggregation
Requires a Cisco switch
Manual configuration of switch
IEEE 802.3ad link aggregation standard (AIX 5L V5.2 and later)
Requires an 802.3ad compatible switch
Automatic switch configuration
VIOS supports both types
Load Balancing
Standard (based on hash of IP address or src/dst ports)
Round Robin
Failover
netif_backup mode (AIX V4.3 and AIX 5L V5.1 only)
Network Interface Backup (AIX 5L V5.2 and later)
Multiple Etherchannel Support
Dynamic Adapter Membership (AIX 5L V5.2 and later)
Figure 7-13. What is Link Aggregation? (2 of 2) AU079.1
Notes:
Link aggregation
AIX implements Cisco-style Etherchannel and IEEE 802.3ad. You can include up to
eight Ethernet ports in the aggregation.
The terms Fast Etherchannel and Gigabit Etherchannel (or GigaChannel) distinguish
the Etherchannels running at 100 Mbps and 1000 Mbps (one gigabit) port speeds,
respectively.
The ports dedicated to the Etherchannel and are generally expected to be configured
identically. (The same speed, duplex mode and, for Gigabit Ethernet, the same TCP/IP
MTU size.)
Note: Mixing adapters of different speeds in the same aggregation, even if one of them
is operating as the backup adapter, is not supported.

V3.1.0.1
Instructor Guide
Uempty Etherchannel versus IEEE 802.3ad

Both AIX and the Virtual I/O Server support two forms of link aggregation. Both forms of
link aggregation require a switch that also supports link aggregation.
- Etherchannel requires a Cisco switch and the switch must be manually configured to
support the aggregation.
- 802.3ad can be used on any 802.3ad compatible switch and the switch
configuration is usually automatic.
- Etherchannel supports both standard and round robin load balancing. 802.3ad only
supports the standard load balancing.
Load balancing
Load Balancing behavior is controlled by two SMIT selectable load balancing methods
for outgoing traffic.
- Round robin
In this mode the EtherChannel will rotate through the adapters, giving each adapter
one packet before repeating. The packets may be sent out in a slightly different
order than they were given to the EtherChannel, but it will make the best use of its
bandwidth. Round robin mode cannot be used with IEEE 802.3ad.
- Standard
In this mode the EtherChannel uses an algorithm to choose which adapter it will
send the packets out on. This mode will guarantee packets are sent out over the
EtherChannel in the order they were received, but it may not make full use of the
bandwidth.
You can configure the algorithm to select the outgoing adapter based on four
choices:
IP address (default)
(Uses the last byte of the IP address, or MAC address for non-IP packets.)
Source port of TCP/UDP packets (src_port)
(Uses the IP address for non-TCP/UDP packets.)
Destination port of TCP packets (dst_port)
Both source and destination ports (src_dst_port)
See the EtherChannel and IEEE 802.3ad Link Aggregation topic in the System
Management Guide: Communications and Networks manual for details about
selecting a distribution mode.
Instructor Guide
Failover
If a single adapter in a link aggregation device fails, the aggregation will continue to use
the remaining adapters.
To protect against failure of the switch that the aggregation device is connected to, it is
possible to configure a backup adapter. There are two ways to do this, which we will
discuss in a few pages.
Dynamic Adapter Membership

Beginning with AIX 5L V5.2 with 5200-03, Dynamic Adapter Membership functionality is
available. This functionality allows you to add or remove adapters from an
EtherChannel without having to disrupt any user connections. For example, you could
replace a failing adapter or add an adapter to provide additional bandwidth, all without
interrupting service.
Multiple Etherchannel support

AIX supports multiple Etherchannels (each up to eight adapters each) on a single
pSeries machine. This allows administrators to consider adapter failure when assigning
ports to the Etherchannels.

V3.1.0.1
Instructor Guide

Purpose Introduce students to Etherchannel support when running AIX server machine.
Details Etherchannel is a feature that allows several Ethernet adapters to be
aggregated into a single channel. The Etherchannel provides a scalable server-to-switch
bandwidth without having to use Gigabit Technology. Each Etherchannel has one IP
address, one MAC address, and appears to the upper-layer protocols to be a single
network interface. This allows for better network performance than a single adapter as the
throughput increases with each added adapter. Etherchannel requires the use of a Cisco
style switch that supports Etherchannel. Etherchannel is a trademark registered by Cisco
Systems and is generally called multi-port trunking or link aggregation.
Additional Information The Etherchannel operates at layer two below the protocol
stack. The Etherchannel is implemented as a kernel extension. It is a pseudo device that
attaches itself to the network services (of CDLI) like the other real Ethernet device drives.
When considering performance using Etherchannel, the following points should be kept in
mind when looking for improvement:
For client connected across a router connected switch, even for IP traffic, the
throughput would be limited by the router-to-switch connection even though the
server-to-switch throughout might show an improvement using Etherchannel.
A single FTP download to a client, for example, will not be complete in one fourth the
time when using Etherchannel with four adapters.
Even the server-to-switch throughput increase depends on how much parallelism the
protocol layer (including the interface layer) allows. If there is no parallel traffic in multiple
adapters, the throughput could be slower than of only one adapter was used instead of
Etherchannel. This is because the packet has to go through an additional layer (for
example, the Etherchannel driver) before the packet goes out the wire.
Transition Statement Now, let's take a look the network interface backup (NIB) function
available with link aggregation in AIX 5L V5.2 and later.
Instructor Guide
Network Interface Backup (NIB)

Available in Server Machine
AIX 5L V5.2
and later
One or more Backup
adapters in ent1 ent2 ent3 ent4 adapter
aggregation
Only one
adapter active
at a time ent6 Alternate, if all
Link status test Link connections on
Aggregation ent6 are down
used to detect Device
adapter failure
ping test used
to detect failure
of path Ethernet Ethernet
Automatic Switch Switch
failback can be
configured on
or off
Figure 7-14. Network Interface Backup (NIB) AU079.1
Notes:
Backup Ethernet adapter

AIX 5L V5.2 provides configuring a backup adapter to the link aggregation device. The
backup adapter's purpose is to take over the IP and MAC address of the link
aggregation device in the event of the failure of all adapters in the link aggregation
device. It is only possible to have one backup adapter configured per link aggregation
device.
All of the adapters in the aggregation should be connected to the same switch and the
backup adapter should be connected to a different switch.
Only one adapter at a time is active in the link aggregation device. Until takeover, the
backup adapter is idle.

V3.1.0.1
Instructor Guide
Uempty How it works

When operating in this mode, only one adapter is active at any given time. If the active
adapter fails, another adapter in the EtherChannel will be used for all traffic. If the
switch fails or all adapters fail, the backup adapter will be used.
The advantages over EtherChannel would be to handle switch and downstream failure.
By plugging into two different switches, the failure of one doesn't prevent the
connection. And, using the ping test allows a failure past the switch to be detected.
When operating in Network Interface Backup mode, it is not necessary to connect to
aggregation compatible switches.
Instructor Guide
Instructor Notes:
Purpose Introduce AIX 5L V5.2 EtherChannel Backup.
Details The process is as follows:
If all but one of the primary adapters fail, then no action is taken as the primary objective
is to keep the EtherChannel open.
If all primary adapters fail, the backup adapter is checked to see if it is functioning. If the
backup adapter is down, the primary adapters stay as the active channel. This is
because it is more likely that one of the EtherChannel adapters comes back up before
the single backup adapter.
If the backup adapter is up and all the primary adapters fail, then failover starts. All the
adapters in the EtherChannel are disabled, and take on the MAC and IP address of the
backup adapter. The backup adapter takes on the MAC and IP of the EtherChannel. All
adapters are then re-enabled.
Gratuitous ARPs are sent to ensure that the MAC associated with the EtherChannel
port is now mapped to the backup adapter port.
When at least one of the adapters in the EtherChannel becomes available, the MAC
and IP are swapped back to the EtherChannel following the same process as before.
Additional Information Prior to AIX 5L V5.2, there was another mode of operation
called netif_backup. The functionality of the backup adapter is used to emulate what used
to be network interface backup mode.
The netif_backup mode enabled the following:
Ability to connect every adapter to a different switch so that each can access all the
machines in the same network.
Failure could be detected by either noticing that the link status of an adapter is down or
optionally pinging a remote machine.
In 5.2, the backup adapter function is used to emulate the netif_backup mode and retains
the ping feature of the network interface backup mode.
Transition Statement Prior to AIX 5L V5.2, link aggregation was different.

V3.1.0.1
Instructor Guide
Uempty
Etherchannel Prior to AIX 5L V5.2
Must manually enable link Server
polling on the adapters before
Virtual Device Driver
creating the Etherchannel ent3
Automatic in AIX 5L V5.2 with
5200-03 and later A active backup
ent1 ent2
netif_backup mode
Single active adapter, single
backup adapter
Only available in AIX V4.3 Switch1 B Switch2
and AIX 5L V5.1
Failures at point A are
detected via link status Router
check 10.9.1.1
Failures at point B are
detected via a ping test to
10.9.1.1
Client
Figure 7-15. Etherchannel Prior to AIX 5L V5.2 AU079.1
Notes:
Link polling
Enable Link Polling on Ethernet Adapter prior to configuring the link aggregation device.
This step is needed to allow polling of adapters to detect changes to the link status and
inform the link aggregation device.
Note: This step is not needed:
- In AIX 5L V5.2 with 5200-03 and later; the link poller will be started automatically
- For Gigabit Ethernet Adapters
netif_backup mode
In the netif_backup mode, the aggregation only activates one adapter at a time. The
intention is the adapters are plugged into different Ethernet switches, each of which is
capable of getting at any other machine on the subnet/network. When a problem is
Instructor Guide
detected, either with the direct connection, or through the inability to ping a machine,
they deactivate the current adapter and activate a backup adapter.
The advantages over EtherChannel would be to handle switch and downstream failure.
By plugging into two different switches, the failure of one doesn't prevent the
connection. And, using the ping test to check downstream allows a failure past the
switch to be detected.
The disadvantage of using Network Interface Backup compared to EtherChannel is you
do not gain any improved bandwidth by aggregating the two physical adapters. Only
one of the adapters in the grouping can be used at a time, so the others sit idle unless a
failure occurs.

V3.1.0.1
Instructor Guide

Purpose Describe differences in EtherChannel prior to AIX 5L V 5.2.
Details Protection from a single point of failure over Ethernet. Protects against local link
failures and network path failures. Configuration via mode value in EtherChannel SMIT.
This function can help with high availability requirements.
Additional Information It is not a part of EtherChannel as generally understood in the
industry (there is no link aggregation with increased bandwidth). It was intended to be a
migration path from dual homed FDDI to Ethernet. Effectiveness depends on the physical
network design having a single point of failure. Failover is in 2-4 seconds without loss of
connections.
Transition Statement How do you configure a link aggregation device in AIX?
Instructor Guide
Add a Link Aggregation (AIX)

# smitty addethch1
Available Network Interfaces

Move cursor to desired item and press F7.
ONE OR MORE items can be selected.
Press Enter AFTER making all selections.
> ent0
> ent1
ent2
Add An EtherChannel / Link Aggregation

[Entry Fields]
EtherChannel / Link Aggregation Adapters ent0,ent1 +
Enable Alternate Address no +
Alternate Address [] +
Enable Gigabit Ethernet Jumbo Frames no +
Mode standard +
Hash Mode default +
Backup Adapter +
Automatically Recover to Main Channel yes +
Internet Address to Ping []
Number of Retries [] +#
Retry Timeout (sec) [] +#
Figure 7-16. Add a Link Aggregation (AIX) AU079.1
Notes:
Introduction
Use SMIT or the mkdev command to add an EtherChannel.
Configure adapters first

Mixing adapters of different speeds in the same aggregation, even if one of them is
operating as the backup adapter, is not supported.
Also, if your network is using jumbo frames (MTU=9000), you must enable jumbo
frames on your adapters before you create the link aggregation.
The adapters must be configured before the aggregation device is created.
Options
The options to configure a link aggregation device are:

V3.1.0.1
Instructor Guide
Uempty - EtherChannel / Link Aggregation Adapters -

The adapters that make up the EtherChannel. Selecting these adapters is required.
- Enable Alternate Address -
Select Yes if the EtherChannel uses the hardware address specified in the
Alternate EtherChannel address field. Select No if the EtherChannel uses the
hardware address of one of the adapters that make up the EtherChannel. By
default, the MAC address of the first adapter in the list is used.The default is No.
Selecting this field is optional.
- Alternate Address -
The hardware address that the EtherChannel will use. It must start with 0x to denote
that the address is expressed in hexadecimal. The 0x should be followed by exactly
12 characters that represent the 6 bytes of the address in hexadecimal. You can use
only valid hexadecimal characters (digits 0-9 and letters a-f or A-F). The letters can
be upper or lower case. The address cannot contain hyphens or dots. An example of
a valid address is: 0x0060957D8cD6. The default address is 0x000000000000,
which indicates that no alternate address is specified. Information in this field is
optional.
- Enable Gigabit Ethernet Jumbo Frames -
Select Yes to allow the EtherChannel to use jumbo frames. This allows the Ethernet
MTU to increase to 9000 bytes per frame instead of the default 1500 bytes. The
default is No. Changing the value of this field is optional.
- Mode -
The type of channel that is configured. The default mode is standard.
standard
Etherchannel using standard load balancing. The Etherchannel sends the
packets to the adapter based on a hash of the value selected in the Hash Mode
field.
round_robin
Etherchannel using round robin load balancing. The channel gives one packet to
each adapter before repeating the loop.
8023ad
IEEE 802.3ad link aggregation. 8023ad uses standard load balancing.
- Backup Adapter -
The adapter used as a backup if all the adapters in the EtherChannel fail. You can
select this adapter from the pop-up menu. Selecting a backup adapter is not
required.
- Internet Address to Ping -
The IP address that the EtherChannel should ping to verify that the network is up.
This is only valid when there is a backup adapter. An address of all zeros is ignored
and disables the sending of ping packets if a valid address was previously defined.
The default is to leave this field blank. Information in this field is optional.
Instructor Guide
- Number of Retries -
The number of lost ping packets before the EtherChannel switches adapters. This is
only valid when the channel has a backup adapter and the Internet Address to Ping
field contains a non-zero address. The range of valid values is 2 to 100 retries. The
default value is 3. Information in this field is optional.
- Retry Timeout -
Controls how often the EtherChannel sends out a ping packet to poll the current
adapter for link status. This is only valid when the EtherChannel has a backup
adapter defined and the Internet Address to Ping field contains a non-zero address.
Specify the time-out value in seconds. The range of valid values is 1 to 100
seconds. The default value is 1 second. Information in this field is optional.

V3.1.0.1
Instructor Guide

Purpose Cover the configuration options when using smit of adding an EtherChannel.
Details There are also changes to the SMIT screen for configuring EtherChannel. The
student notes list the options with brief definition.
Additional Information Jumbo Frames significantly improve throughput on Gigabit
Ethernet links, but it is essential that they're configured on the EtherChannel and all
underlying adapters. The goal is to avoid sending packets larger than the adapter is
configured to handle. Failure to properly configure will result in erratic behavior and
performance problems which are complicated by the load balancing and failover behavior
characteristics of the EtherChannel.
Transition Statement Now, lets look at configuring a link aggregation from the VIOS.
Instructor Guide
Add a Link Aggregation (VIOS)

$ mkvdev -lnagg TargetAdapter[,...] [-attr Attribute=Value [Attribute=Value ... ]]
Attributes:
mode standard (default), round_robin, 8023ad
hash_mode default (default), src_port, dst_port, src_dst_port
backup_adapter Optional. The name of the backup adapter. Default = yes.
auto_recovery Automatically Recover to Main Channel. Default
Optional. IP address the link aggregation device should ping to verify
netaddr the network is up. Only valid when there is a backup adapter and
when there is just one adapter in the link aggregation.
Default = 0 (disabled).
Optional. How often the link aggregation device should ping to verify
retry_time the network is up. Range = 1 to 100 seconds. Default = 1.
Only valid if netaddr does not = 0.
Optional. The number of lost ping packets before the link aggregation
device switches adapters.
num_retries
The range = 2 to 100 retries. Default = 3.
Only valid if netaddr does not = 0.
use_jumbo_frame Optional. To use this attribute, your switch must support jumbo
frames. Default = no.
Optional. yes enables you to specify a MAC address that you want
the link aggregation device to use.
use_alt_addr
If no, the link aggregation device will use the MAC address of the first
adapter. Default = no.
alt_addr If use_alt_addr is yes, the alternate MAC address.
Figure 7-17. Add a Link Aggregation (VIOS) AU079.1
Notes:
Adding a link aggregation device in the Virtual I/O Server

The visual shows the basic command and the attributes to control how your link
aggregation is configured. All of the aggregation features supported by AIX are also
supported on the Virtual I/O Server.
Configure adapters first

Mixing adapters of different speeds in the same aggregation, even if one of them is
operating as the backup adapter, is not supported.
Also, if your network is using jumbo frames (MTU=9000), you must enable jumbo
frames on your adapters before you create the link aggregation.
The adapters must be configured before the aggregation device is created.

V3.1.0.1
Instructor Guide

Purpose Discuss using the mkvdev command to create a link aggregation device on the
VIOS.
Details
Transition Statement Next a checkpoint quiz to review what weve discussed.
Instructor Guide
Checkpoint
The Virtual I/O Server is a special partition that hosts
___________________ and ___________________ resources.
Shared Ethernet adapters (SEAs) bridge
___________________ to ___________________.
T/F: The virtual adapter associated with a shared Ethernet adapter
connected to the external network must have trunk adapter
checked.
T/F: More than one VLAN can be bridged to the external network
using one SEA.
How many virtual Ethernet adapters marked as trunk adapters per
VLAN can you have?
T/F: The virtual I/O server connection to the external LAN can be an
aggregate of adapters.
Notes:

V3.1.0.1
Instructor Guide

Purpose Review.
Details
virtual SCSI disk and shared Ethernet adapter resources.
external networks to internal VLANs.
checked. True.
using one SEA. True.
VLAN can you have? One.
aggregate of adapters. True.
Transition Statement Lets do an exercise.
Instructor Guide
Exercise:
Shared
Ethernet
Adapter
Notes:

V3.1.0.1
Instructor Guide

Details
Transition Statement Lets summarize.
Instructor Guide
Unit Summary
The Virtual I/O Server is a dedicated partition that allows LPARs to
share I/O adapters
The shared Ethernet adapter bridges the external network to the
internal VLANs
Physical adapter (connection to external network)
One or more virtual adapters (connection to internal VLAN(s))
Shared Ethernet adapter (the bridge)
AIX and the VIOS support aggregation of Ethernet adapters
Etherchannel
802.3ad
Notes:

V3.1.0.1
Instructor Guide

Purpose Summary.
Details
Transition Statement End of unit.
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 8. Network Control

This unit introduces the students to some of the options available to
manage network services.

Discuss Virtual IP addressing
Describe multipath routing
Describe Path MTU Discovery
Explain Dead Gateway Detection
Configure network options

Accountability:
Exercises
References
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp
System Management Guide:
Copyright IBM Corp. 1997, 2006 Unit 8. Network Control 8-1

Instructor Guide
Unit Objectives
Discuss Virtual IP Addressing
Describe Multipath Routing
Describe Path MTU Discovery
Explain Dead Gateway Detection
Configure Network Options
Notes:

V3.1.0.1
Instructor Guide

Purpose Introduce objectives.
Details
Transition Statement Well start by discussing VIPA, the Virtual IP Address feature.

Instructor Guide
Virtual IP Address (VIPA)

Server
en0 Client1
10.1.1.2
Routers
vi0
10.10.10.2 destination gateway
en1 10.10.10.2 10.1.1.2
10.2.1.1
10.10.10.2 10.2.1.1 Client2
1. Outgoing packets are routed via 3. Replies will be directed to the VIPA address
member interfaces (en0 & en1) based 4. Clients and any routers must be configured with
on the destination and the routing table routes to the VIPA address
in the server gated (using OSPF) will advertise the VIPA
2. Source address will be set to the VIPA interface to neighboring routers and will update
address (vi0: 10.10.10.2) routers if an interface fails
Or you can configure routers manually and use
Dead Gateway Detection
Application availability issue
If one physical interface or network path fails, traffic is routed to the
other physical interface
VIPA interface can be brought up or down without affecting
physical interfaces
bos.net.tcp.client fileset
Figure 8-2. Virtual IP Address (VIPA) AU079.1
Notes:
AIX offers Virtual IP Addresses to overcome application availability problems. When a
network becomes inaccessible or the network interface fails, a different network interface
can be used by modifying the routing table. If the rerouting occurs fast enough, then the
TCP/IP sessions are not lost.
Virtual IP addresses can be configured with:
mkdev
smitty mkinetvi
The VIPA concept is similar to IP aliases except that the addresses are not associated with
a hardware interface. VIPA offers several advantages that IP aliases does not:
VIPA offers a virtual device that can be brought up and down independently without
affecting the physical interfaces
VIPA addresses can be changed while aliases can only be added or delete

V3.1.0.1
Instructor Guide

Purpose Introduce Virtual IP addresses.
Details A traditional IP address is associated with a specific network adapter. Virtual IP
address is supported by a network interface that is not associated with any particular
network adapter. The operating system interacts with a virtual interface through the
interface specific device special file. The VIPA system management tasks are supported by
appropriate changes and additions to the interface related high-level commands.
Access via the IP address of the real adapters
Individual interfaces are still accessible to other systems after VIPA is implemented.
However, using the real IP addresses for ping and telnet sessions sidesteps the VIPA
advantage of communicating independent of the physical adapters. VIPA hides physical
adapter failures from the outlying clients. Using the real addresses reintroduces the
dependency upon the physical adapters.
If the remote system contacts the VIPA system using the VIPA address or if an application
on the VIPA system initiates the communication to another system, the VIPA address is
used as the source IP address in the packet. However, if the remote system initiates the
session using the IP address of the real interface, that real IP address is the source IP
address in the responding packets. There is one exception. For applications that bind to a
particular IP interface, the outgoing packets carry the source address of the interface to
which they are bound.
VIPA and routing protocols
The gated daemon was modified for VIPA so that it would not add the interface route or
send advertisements over virtual interfaces. The OSPF protocol, supported by gated,
advertises the virtual interface to neighboring routers. The other hosts on the network are
able to talk to the VIPA host through the first-hop router.
Multiple VIPA addresses
Multiple virtual interfaces may be configured.
Multiple VIPA interfaces would be useful, for example, if network routers could give
preferential treatment to packets sent to or from certain VIPA addresses. Or, you might use
multiple VIPA interfaces if they were binding applications to a specific VIPA interface. For
example, to run multiple Web servers for multiple companies on a single machine, you
could configure the following:
vi0 200.1.1.1 www.companyA.com
vi1 200.1.1.2 www.companyB.com
vi2 200.1.1.3 www.companyC.com

Instructor Guide
VIPA on AIX 5.1

It was also not possible to specify a group of interfaces that use a particular VIPA in AIX
5.1. The first VIPA in the address list would get chosen as the default source address when
the application does not explicitly bind to an address.
Transition Statement Lets take a look at the smit screen to configure virtual IP.

V3.1.0.1
Instructor Guide
Uempty
Create Virtual IP Address
# smit mkinetvi
Add a Virtual IP Address Interface

[Entry Fields]
* INTERNET ADDRESS (dotted decimal) [10.10.10.2]
Network MASK (hexadecimal or dotted decimal) [255.255.255.0]
* Network Interface [vi0]
* ACTIVATE the Interface after Creating it? yes +
Network Interface(s) using this VIPA [en0,en1]
Figure 8-3. Create Virtual IP Address AU079.1
Notes:
Using SMIT
The Internet address of the network interface must be in dotted decimal form.
The network mask includes both the network part of the logical address and the subnet
part that is taken from the host field of the address.
Using mkdev
The mkdev command may be used to define the interface as follows
# mkdev -c if -s VI -t vi -s netaddr=1.1.1.1 \
-a netmask=255.255.255.0 -s vi0 -a state=up \
-a interface_names=en0,en1

Instructor Guide
Using ifconfig
Two new options vipa_iflist and -vipa_iflist have been added to the ifconfig
command (in AIX 5L V5.2).
Note: Remember that ifconfig only changes the current interface device in memory. If
you want to make the change permanent (update the ODM), you must use SMIT or
mkdev.
The ifconfig command can be invoked in one of the following ways using these
options:
- To configure a list of interfaces to use a particular VIPA:
# ifconfig vi0 1.1.1.1 vipa_iflist en0,en1
- To remove a list of interfaces that are configured to use VIPA:
# ifconfig vi0 1.1.1.1 -vipa_iflist en0,en1
Running the ifconfig vi0 command produces the following status:
# ifconfig vi0
vi0: flags=84000041<UP,RUNNING,64BIT>
inet 1.1.1.1 netmask 0xffffff00
iflist : en0 en1

V3.1.0.1
Instructor Guide

Purpose Explain how to create a VIPA.
Details SMIT, mkdev or ifconfig can be used to configure the VIPA. Point out the
difference in AIX 5L V5.1: in 5.1 there is no interface list.
Transition Statement Now that we have seen how applications can bind to a virtual
address, lets look at how AIX supports the use of multiple paths to the same destination.

Instructor Guide
Multipath Routing
Gateway
tr0
Host tr1 Destination
en0 Host
Gateway
Load balancing among Gateways

Load balancing among interfaces on same network
Alternate backup for failed paths
Traffic distribution is user configurable:
cost
mpr_policy
weight
Figure 8-4. Multipath Routing AU079.1
Notes:
Multipath routing
Multipath routing feature allows administrators to create multiple routes to the same
destination. The benefits of this feature are:
- Load balancing between two or more gateways
- Load balancing between two or more interfaces on the same network
- Alternate routes provide protection against an interface or router failure
Traffic distribution
When there are multiple routes to the same destination, AIX will choose a route based
on three user configurable attributes: cost, mpr_policy and weight. This allows the
administrator to control how the routes are used based on various factors, including:
cost, weight, utilization, IP address of destination, and random. Well start by looking at
the cost attribute.

V3.1.0.1
Instructor Guide

Purpose Introduce multipath routing support.
Details In the past, a new route could be added to the routing table only if it was
different from existing routes. The new route would have to be different by either
destination, netmask, or group ID. You could have two routing table entries that have the
same netmask, but each interface would be associated with a different destination network.
Or, you could have two routes for two different gateways with the same destination, but for
different netmasks. Lastly, you could differentiate for a unique route destination by using a
group ID list. These groups are comprised of AIX group IDs and they determine which
users have permission to access the route. Now, multipath routes no longer need to be
different. If several routes equally qualify, AIX uses round-robin to choose between them.
Additional Information In order to implement multipath routing, AIX allows you to
define a user-configurable cost attribute for each route and offers the option to associate a
particular interface with a given route. These enhancements are configurable by the
parameters -hopcount and -if of the route command.
Transition Statement Now, lets take a look at the cost attribute for each route.

Instructor Guide
Cost Attribute
cost=0 Gateway
tr0
Host Destination
en0 cost=0 Host
Gateway
Route cost metric (hopcount)

If costs are unequal
Higher cost routes will never be used
If costs are equal (and other attributes are set to defaults)
AIX will alternate (round robin) between the routes
Figure 8-5. Cost Attribute AU079.1
Notes:
The user-configurable cost of a route is specified as a positive integer value for the variable
associated with the hopcount parameter. The integer can be any number between 0 and
the maximum possible value of MAX_RT_COST, which is defined in the
/usr/include/net/route.h header file to be INT.MAX (2147483647).
The hopcount parameter in the past reflected the number of gateways in the route. Now,
however, the hopcount parameter refers historically to the number of gateways in the
route. However, the number an administrator can assign is not related to the actual
presence or absence of any real gateways in the network. The user-configurable cost
attributes sole purpose is to establish a metric, which is used to create a priority hierarchy
among entries in the routing table.
Use the netstat command with -C flag set to show routing table, including the
user-configurable and current cost of each route.

V3.1.0.1
Instructor Guide

Purpose Introduce the cost attribute.
Details If the routing table offers several alternative routes to the desired destination,
the operating system always chooses the route with the lowest distance metric as indicated
by the lowest value for the current cost.
Additional Information In the case where multiple matching routes have equal current
cost, a lookup mechanism chooses the most specific route. When both criteria are equal for
multiple routes, AIX round-robin selects between them.
Transition Statement Now, lets take a look at the netstat output that contains the cost
metric.

Instructor Guide
Displaying the User-configurable Cost
# netstat -C
Routing tables
Destination Gateway Flags Refs Use If Cost Config_Cost

default sys5e UG 0 302 et0 0 0
10.19.98/24 sys3e U 1 7101 et0 0 0
vi3 loopback UH 2 15926 lo0 0 0
127/8 loopback U 1 18805 lo0 0 0

::1 ::1 UH 0 0 lo0 0 0
Figure 8-6. Displaying the User-configurable Cost AU079.1
Notes:
The netstat -C command shows the routing tables, including the user-configured and
current costs of each route. The user-configured cost is set using the -hopcount flag to the
route command. The current cost may be different from the user-configured cost if dead
gateway detection has changed the cost of the route.

V3.1.0.1
Instructor Guide

Purpose Display cost metric that forms the basis for creating priority hierarchy among
entries in the routing table.
Details Explain what cost are with a specific route.
Additional Information The maximum possible value of max_rt_cost is 2147483647
as defined in /usr/include/net/route.h header file.
Transition Statement Now, lets take a look at the route command to change the cost
associated with a specific route.

Instructor Guide
Setting the Cost Attribute
Primary Route
tr0 cost=0
Host Gateway
pp0
Secondary Route
cost=25
# route add 192.168.1.2 192.168.1.1 -if pp0 -hopcount 25

Interface specific
Cost versus user configuration cost
PMTU issue (cloned routes)
Figure 8-7. Setting the Cost Attribute AU079.1
Notes:
Setting the cost

The cost attribute is set using the -hopcount flag, as shown in the visual. This is the
user-defined cost, which is shown as Config_Cost in the netstat -C output. The
current active cost of a route (Cost in netstat -C output) may be modified by Dead
Gateway Detection, which we will discuss in a few pages.
Adding a duplicate route on the same network

If you have multiple routes connected to the same network, you can differentiate them
by specifying the interface to be sued for each route. AIX provides the -if argument to
the route command for the purpose of associating an interface with a specific route.

V3.1.0.1
Instructor Guide

Purpose Explain the cost metric implementation and usage.
Details The user-defined cost on an individual interface allows for multipath routing. To
take full advantage, the PMTU needs to be disabled (on by default).
Additional Information PMTU discover is used to determine the largest packet that can
be sent over a particular network. Whenever packets go out, a separate host route is
cloned for the path. Cloned routes are created by copying the parent route and adding
specific information unique to the routes destination, including smallest MTU discovered in
the path to the host. A cloned route has the same cost and is more specific than the original
gateway. Thus, round-robin cycling is not used.
Transition Statement Now, after setting the user-configured cost, lets take a look at
netstat -C display.

Instructor Guide
Current Cost
# netstat -C
Routing tables
Destination Gateway Flags Refs Use If Cost Config_Cost

default sys5e UG 3 880 et0 0 0
10.19.98/24 sys3e U 3 1578 et0 0 0
vi3 loopback UH 1 22196 lo0 0 0
vi7 sys5e UGH 1 191 et0 25 25 =>
vi7 ppp7 UGH 1 367 pp0 25 25
127/8 loopback U 1 26159 lo0 0 0

::1 ::1 UH 0 0 lo0 0 0
Figure 8-8. Current Cost AU079.1
Notes:
The netstat -C command shows the routing table that includes current costs (Cost) and
user-defined cost (Config_Cost) of individual routes. When using Dead Gateway
Detection, these two costs may b e different.

V3.1.0.1
Instructor Guide

Purpose Display the current cost with netstat command.
Details The results of using the route command with the -if argument, along with the
-hopcount parameter are displayed. This sets up the system for using the dead gateway
detection function. Remember, with multipath routing PMTU must be turned off.
Transition Statement Now, lets take a look at some multipath routing enhancements.

Instructor Guide
Multipath Routing Policy (AIX 5L V5.2 and Later)

Route with lowest cost (hopcount) will always be used first
If multiple routes have the same cost, multipath routing policy is used
Policy is set globally via mpr_policy (no option)
Weighted Round Robin (1) This is the default.
Round robin, modified by user configured weights (per route attribute).
Higher weight routes are favored.
Random (2)
Weighted Random (3)
Random, modified by user configured weights. Higher weight routes are favored.
Lowest Utilization (4)
Route with lowest number of current connections will be used.
Hash-based (5)
Chooses a route using a hash-based algorithm of the destination IP address.
Or the policy can be set or modified using per route attributes
Use SMIT or the route command
Policy
Default (Use global policy set via mpr_policy)
Weighted RR (1)
Random (2)
Weighted Random (3)
Lowest Utilization (4)
Hash-based (4)
Weight
Cost
Figure 8-9. Multipath Routing Policy (AIX 5L V5.2 and Later) AU079.1
Notes:
Traffic distribution for multiple routes to the same destination

Traffic across multiple routes to the same destination is distributed according to three
factors: cost, routing policy and weight.
The cost attribute has highest priority. If costs are unequal, the lowest cost route will
always be used. If there are multiple routes with the lowest cost, then the routing policy
and weight are used.
Routing policy
The mpr_policy specifies the global routing policy used in conjunction with multipath
routing. The following routing policies are available:
1) Weighted Round Robin is based on user configured weights. If weights are
equal, this policy will be normal round robin (alternating between each of the

V3.1.0.1
Instructor Guide
Uempty routes). If weights are unequal, routes with higher weights will be used more
often.
2) Random selection is used.
3) Weighted Random chooses a route based on user-configured weights and a
randomization routine.
4) Lowest utilization determines route based on number of active connections.
5) Hash-based algorithm based on destination IP address.

Instructor Guide
Instructor Notes:
Purpose Introduce multipath routing policy, available in AIX 5L V5.2 and later.
Details There are six new items on the smit mkroute under policy options.
Transition Statement Next lets look at Path MTU Discovery. What is a path MTU?

V3.1.0.1
Instructor Guide
Uempty
What is Path MTU?
The Maximum Transmission Unit (MTU) is the largest size packet
that can be transmitted on a particular network
Different networks may have different MTU values
Path MTU is the smallest MTU of any network path between two
hosts
If a packet must be routed through a network with a smaller MTU
than its originating network, then it must be fragmented
Fragmenting packets at the router is inefficient
Packet fragmentation is unnecessary if packets are sent with a size
no larger than the Path MTU
The goal of Path MTU Discovery is to prevent IP packet
fragmentation at the router
Figure 8-10. What is Path MTU? AU079.1
Notes:
Maximum Transmission Unit (MTU)

The MTU of a network is the largest packet size for that network. For example, the MTU
for standard Ethernet is 1500 bytes and for gigabit Ethernet, its 9000 bytes.
For locally connected destination, the mtu attribute of the network interface is used by
the IP protocol to determine the size of outgoing packets.
Path MTU
For remote destinations, AIX supports a path MTU discovery algorithm as described in
RFC 1911. If a PMTU value exists for a route, the IP protocol will fragment the packet to
fit within the PMTU value before sending it. It is much more efficient to fragment the
packet at the sender than to have packets be fragmented by routers along the path to
the destination.

Instructor Guide
Instructor Notes:
Purpose Introduce path MTU.
Details
Transition Statement Path MTU Discovery can be enabled or disabled.

V3.1.0.1
Instructor Guide
Uempty
Enabling/Disabling Path MTU Discovery
There are five network options that control Path MTU Discovery
no -o udp_pmtu_discover=1
Enables Path MTU Discovery for enabled UDP applications
no -o tcp_pmtu_discover=1
Enables Path MTU Discovery for all TCP applications
no -o pmtu_default_age=10
Interval in minutes when Path MTU reductions are discovered
no -o pmtu_rediscover_interval=30
Interval in minutes when Path MTU increases are discovered.
no -o route_expire=1
Interval in minutes when unused cloned routes are deleted
(only applies to AIX 5L V5.2 and earlier)
Figure 8-11. Enabling/Disabling Path MTU Discovery AU079.1
Notes:
Using Path MTU Discovery

As shown in the visual, there are five no options which control Path MTU Discovery.
Note: Path MTU Discovery is enabled separately for TCP and UDP applications. Not all
UDP applications support this feature.

Instructor Guide
Instructor Notes:
Purpose Discuss how to configure Path MTU Discovery.
Details
Transition Statement Prior to AIX 5L V5.3, Path MTU Discovery had an impact on
multipath routing. Lets take a look.

V3.1.0.1
Instructor Guide
Uempty
Path MTU Discovery and Multipath Routing
AIX 5L V5.2 and earlier
With PMTU Discovery, the PMTU for each destination is stored in the routing table
A cloned host route is created to store the discovered PMTU
Cloned routes expire, if unused for route_expire minutes
Routing will always prefer the more specific cloned route over the network route
If you have multiple routes, the first route used is cloned and the second route will never be used
Turn off PMTU discovery if using multipath routing
# netstat -rn
Routing tables
Destination Gateway Flags Refs Use If PMTU Exp Groups
Route tree for Protocol Family 2 (Internet):
default 9.3.149.161 UGc 0 0 tr0 - -
9.3.149.33 9.3.149.161 UGHW 1 151 tr0 1492 - -
9.53.150.8 9.3.149.161 UGHW 2 685 tr0 1492 - -
AIX 5L V5.3 and later

PMTU values are stored in separate PMTU table
Cloned routes are not created
PMTU Discovery can remain enabled even if using multipath routing
# pmtu display
dst gw If pmtu refcnt redisc_t exp
-------------------------------------------------------------------------
9.76.205.76 9.47.88.1 en1 1500 1 11 0
9.47.56.70 9.47.88.1 en1 1500 2 28 0
127.0.0.1 127.0.0.1 lo0 16896 2 27 0
Figure 8-12. Path MTU Discovery and Multipath Routing AU079.1
Notes:
AIX 5L V5.2 and earlier

Prior to AIX 5L V5.3, PMTU information was stored in the routing table in kernel
memory. When a path mtu is discovered for a network route, a separate host route is
cloned for the path.
Because the cloned host route is always more specific than the original network route,
all traffic to that host will use the same gateway as long as cloned route exists and,
consequently, no cyclic multiplexing among different gateways would occur. To disable
the default action of cloning, use:
- # no -o udp_pmtu_discover=0
- # no -o tcp_pmtu_discover=0
This allows you to take full advantage of the multipath routing feature by preventing the
creation of the cloned host routes, and instead allows cyclic multiplexing between
equal-cost routes to the same network.

Instructor Guide
Note: In the netstat -r Flags column:

- c indicates a clonable route
Any time the system uses a clonable route, a specific cloned host route is created to
store PMTU information.
- W indicates a cloned route
Cloned routes will always be used first, since they are more specific than network
routes.
AIX 5L V5.3 and later

Beginning in AIX 5L V5.3, PMTU information is no longer stored in the routing table.
Instead, PMTU data is stored in a separate PMTU table in kernel memory. The PMTU
table can be viewed using the pmtu command.
This means that cloned routes are no longer created and you can use Path MTU
Discover with mutlipath routing.

V3.1.0.1
Instructor Guide

Purpose Discuss interaction between Path MTU Discovery and multipath routing prior
to AIX 5L V5.3 and changes made in 5.3.
Details
Transition Statement If you are using multipath routing, it would be useful if there was
a mechanism to detect a route failure. The Dead Gateway Detection feature is designed for
this purpose.

Instructor Guide
Dead Gateway Detection (DGD)
1 Status checked
(Gateway down)
Gateway
Host
Backup
2 Switch to backup
Gateway
Figure 8-13. Dead Gateway Detection (DGD) AU079.1
Notes:
The Dead Gateway Detection (DGD) feature implements the ability for hosts to detect a
dysfunctional gateway, and reroute network traffic to a backup gateway. DGD, along with
multipath routing, allows for multiple routes to the same destination, which can be used for
load-balancing and failures.
The DGD implementation addresses two distinct sets of customer requirements:
Requirement for minimal impact on network and system environment
Requirement for maximum availability of network services and connections
Passive DGD and Active DGD address two distinct sets of requirements. The passive DGD
addresses the need for minimal overhead while the active DGD ensures maximum
availability while imposing some additional workload on network segments and connected
systems. Passive DGD is enabled or disabled system-wide. It is disabled by default. Active
DGD is an attribute for a particular route and is enabled on a route by route basis.

V3.1.0.1
Instructor Guide

Purpose Introduce DGD feature.
Details DGD feature enables host systems to sense and isolate a dysfunctional
gateway and adjust the routing table to make use of an alternate gateway without the aid of
a running routing protocol program. DGD is generally most useful for hosts that use static
rather than dynamic routing.
Additional Information AIX implements DGD based on the requirements given in RFC
1122 and RFC 816. These RFCs require that pinging to discover the state of a gateway be
avoided or extremely limited. AIX active DGD is not fully compliant with RFCs as the ping is
performed for status update of a gateway.
Transition Statement Now, lets take a look at the two modes available under DGD
support. First, we look at passive mode and then active mode.

Instructor Guide
Passive DGD
1 TCP and ARP to
check status
Gateway
tr0
(Gateway down)
en0
Backup
2 Network traffic Gateway
sent to backup
Pro: Low overhead (does not add to network traffic)

Con: May take up to 20 minutes for a bad route to be discovered
Uses ARP and TCP
If a gateway does not respond to an ARP request, the current cost of all routes using
that gateway is raised to the maximum value.
If a TCP connection fails, the ARP entry for the gateway is removed. On the next use
of the route, an ARP request will be sent. If there is no response, the cost is raised.
Configured globally via the no command
passive_dgd - Enables passive DGD for entire system
dgd_packets_lost - Number of TCP packets lost before DGD removes ARP entry
dgd_retry_time - After dgd_retry_time minutes, cost is restored to Config_Cost
Figure 8-14. Passive DGD AU079.1
Notes:
Passive DGD takes action to use a backup route if a dysfunctional gateway has been
detected. Passive DGD depends on protocols that provide information about the state of
the relevant gateway. TCP and ARP provide the necessary feedback about the state of a
gateway.
If consecutive dgd_packets_lost TCP packets are lost, the ARP entry for the gateway in
use is deleted and the TCP connection tries the next-best route.
The next time the route is tried, an ARP request will be required. If a gateway does not
respond to the APR request, passive DGD raises the cost of all routes associated with this
gateway. If there is another route to the destination with a lower cost, it will be used. If this
is the only route to the destination, by definition it has the lowest cost and the route will still
be tried.

V3.1.0.1
Instructor Guide

Purpose Explain Passive DGD feature.
Details Passive DGD does not rely on the use of the ping command. Instead, it uses
TCP and ARP to get necessary feedback about the gateway. TCP identifies round-trip
traffic not getting through. It correctly detects the gateway in question is down if it is no
longer forwarding traffic. TCP indirectly initiates an ARP request by deleting the ARP cache
entry for the gateway. Next time any traffic is sent, the necessary status information is
provided to DGD for action.
Additional Information It is important to carefully choose the criteria for deciding that a
gateway is down. A failover to a backup gateway just because a single packet was lost in
the network must be avoided, but in case of an actual gateway failure, network availability
must be restored with as little delay as possible.
Transition Statement Now, lets take a look at the other mode of DGD, active.

Instructor Guide
Active DGD
1 Ping for status
Gateway
tr0
Host
pp0
Backup
2 Network traffic Gateway
sent to backup
Pro: Quickly detects a route that is down

Con: Adds to network traffic
Set on a per route basis
# route change default 10.19.99.5 -active_dgd
Pings gateway to check status
If gateway is down, raises cost and continues pinging
If ping succeeds to a down gateway, lowers cost to Config_Cost
Behavior configured globally via the no command
dgd_ping_time
How often to ping the gateway (in seconds)
dgd_packets_lost
How many packets must be lost before the cost is raised for all routes using this gateway
Figure 8-15. Active DGD AU079.1
Notes:
Passive DGD has low overhead and is recommended for use on any network that has
redundant routes. However, passive DGD is done on a best effort basis only. AIX offers a
second DGD mechanism called Active DGD. This option pings gateways periodically, and if
a gateway is found to be down, the routing table is changed to use alternate routes to
bypass the dysfunctional gateway.
The network option dgd_ping_time allows the administrator to configure the time interval
between the periodic ICMP message in seconds. dgd_packets_lost specifies how many
ping packets must be lost before DGD will raise the cost.
Active DGD is enabled on a per route basis using the -active_dgd flag to the route
command.
Active DGD detection is off by default. It is recommended to be used only on machines that
provide critical services and have high-availability requirements.
Since active DGD imposes some extra network traffic, network sizing and performance
issues have to receive careful consideration.

V3.1.0.1
Instructor Guide

Purpose Explain Active DGD feature.
Details Active DGD operates on a per-route basis, and it is turned on by the parameter
argument -active_dgd of the route command. The netstat -C command lists the routes
defined to the system, including their current and user-configurable cost. The A flag
indicates that the Active DGD for that particular route is turned on.
Additional Information The kernel keeps a list of all gateways that are subject to active
DGD. Each time dgd_ping_time seconds passes, all the gateways on the list are pinged. A
pseudo-random number is used to slightly randomize the ping times. If any gateway fails to
respond, they are pinged several times repeatedly with one second pauses between pings.
The total number of times they are pinged is determined by the dgd_packets_lost network
option. The network option dgd_packets_lost in passive DGD refers to the number of tcp
packets lost, whereas for active DGD, dgd_packets_lost specifically relates to packets
used in ICMP (ping) to some state of the gateways.
Transition Statement Lets check the status of active dead gateway detection.

Instructor Guide
Active DGD Status

# netstat -Cn
Routing tables
Destination Gateway Flags Wt Policy If Cost Config_Cost

default 9.47.88.1 UG 1 - en0 0 0
9.47.88.0 9.47.88.171 UHSb 1 - en0 0 0 =>
9.47.88/24 9.47.88.171 U 1 - en0 0 0
9.47.88.171 127.0.0.1 UGHS 1 - lo0 0 0
9.47.88.255 9.47.88.171 UHSb 1 - en0 0 0
10.0.2.0 10.0.2.4 UHSb 1 - en1 0 0 =>
10.0.2/24 10.0.2.4 U 1 - en1 0 0
10.0.2.4 127.0.0.1 UGHS 1 - lo0 0 0
10.0.2.255 10.0.2.4 UHSb 1 - en1 0 0
127/8 127.0.0.1 U 1 - lo0 0 0
192.168.20/24 9.47.88.1 UGA 1 RR en0 0 0 =>
192.168.20/24 10.0.2.1 UG 1 - en1 25 25
Figure 8-16. Active DGD Status AU079.1
Notes:
Active dead gateway detection operates on a per route basis. Use the netstat command
to display status: the A flag indicates that active DGD is enabled for that particular route.

V3.1.0.1
Instructor Guide

Purpose Display active dead gateway detection flag.
Details Using the route command with -active_dgd flag, the route is now monitored by
the ping command. If the interface detects a gateway not responding to ping (status check),
then the current cost of route is changed to max (not shown in the visual, but will try out in
lab).
Transition Statement In this unit, and in earlier units, we have mentioned the no
(network options) command. Lets take a more detailed look at the command and how it is
used.

Instructor Guide
Network Tunables (no Command)

Use no to set or display network tuning parameters (tunables)
Current value or reboot value or both
See no man page or no -h for details on tunables
Syntax
no [-p|-r] {-o Tunable[=Newvalue]}
no [-p|-r] {-d Tunable}
no [-p|-r] -D
no [-p|-r] -a
no -h Tunable
no -L [Tunable]
Flag Description
-p Permanent: makes the change to both current and reboot value
-r Reboot: makes the change on the next reboot
-o Displays or sets individual parameters. Without -p or -r, only current value is
shown or changed
-d Resets individual tunable to default value
-D Resets all tunables to default values
-a Displays all parameters
-h Displays help information for a tunable
-L Lists attributes of one or all tunables; includes:
current value, default value, value to be set at next reboot, minimum possible
value, maximum possible value, unit, type, and dependencies
Figure 8-17. Network Tunables (no Command) AU079.1
Notes:
Network tunables
The no command is used to configure a wide range of network tuning parameters.
These are often referred to as tunables.
The options to the no command allow you to set or display either the current value or
the reboot value for network tunables.
The -L flag is very useful; it shows the current and reboot values, as well as the
minimum and maximum and so forth.
What are all these tunables?

The no command allows you to set many different network tunables. In general, you
should not change a tunable if you do not know what it does.
There are several resources you can use to get more information about network
tunables:

V3.1.0.1
Instructor Guide
Uempty - The man page provides detailed descriptions of each tunable

- no -h
- AIX Info Center (http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp):
System Management Guide: Communications and Networks

Instructor Guide
Instructor Notes:
Purpose Provide an overview of the no command.
Details
Transition Statement AIX provides an number of features to manage your tunables.

V3.1.0.1
Instructor Guide
Uempty
Managing Tunables
AIX 5L V5.2 and later supports a common syntax for tuning
commands
no (network tuning)
vmo (memory tuning)
schedo (CPU tuning)
ioo (I/O tuning)
nfso (NFS tuning)
/etc/tunables contains two stanza files and a log file
nextboot
lastboot
lastboot.log
File control commands for tunables
tuncheck
tunrestore
tunsave
tundefault
Figure 8-18. Managing Tunables AU079.1
Notes:
Common syntax for AIX tuning commands

Beginning in AIX 5L V5.2, the AIX tuning commands share a common syntax.
/etc/tunables
This directory three files that are used with the tunable commands:
- /etc/tunables/nextboot
When you change a tunable value for the next boot, an entry is made in this file. At
boot time, tunrestore -R is run from /etc/inittab. All tunables that are not already
set to the value defined in the nextboot file are modified. Tunables not listed in the
nextboot file are forced to their default value. All actions, warnings and errors are
logged into /etc/tunables/lastboot.log.
- /etc/tunables/lastboot
This file contains a record of the tunables that were set during the last boot. It lists all

Instructor Guide
the tunables with numerical values. The values representing default values are
marked with the comment DEFAULT VALUE.
- /etc/tunables/lastboot.log
This file contains a record of all actions taken by tunrestore -R at boot time.
File control commands

AIX provides four commands to manage the files associated with the tunable
commands:
- tuncheck
The tuncheck command validates a tunable file. All tunables listed in the specified
file are checked for range and dependencies. If a problem is detected, a warning is
issued.
- tunrestore
The tunrestore command restores all tunable parameters values stored in a file.
tunrestore -R can only be called from inittab.
- tunsave
The tunsave command saves the current state of tunable parameters (in memory)
to a file.
- tundefault
The tundefault command launches all the tuning commands (ioo, vmo, schedo, no
and nfso) with the -D flag.
There are a few flags for each of these commands. See the man pages for details of
how to use these commands.

V3.1.0.1
Instructor Guide

Purpose Summarize how to manage tunables in AIX 5L V5.2 and later.
Details
Transition Statement Now, lets take a quick look at Quality of Service within AIX.

Instructor Guide
Quality of Service
Ne
ork
tw
or
tw
Bandwidth
k
Ne
Regulate traffic
Manage bandwidth
Policy based
Specify policy priority
Figure 8-19. Quality of Service AU079.1
Notes:
Quality of Service provides a method for regulating network traffic flows. The demand for
QOS arises from applications such as digital media or real-time applications and the need
to manage bandwidth resources for arbitrary administratively defined traffic classes.
Policy-based networking allows for a policy condition (character of a packet) to be met and
a corresponding action performed on that packet. A policy condition is defined by five
characteristics of a packet which include source IP address, source port number,
destination IP address, destination port, and protocol type (tcp or udp). A policy action
includes:
Token bucket parameters defining in-profile traffic
TOS byte value for in-profile traffic
From an administrators point of view, a policy is essentially configuration parameters to
regulate certain types of traffic flow.

V3.1.0.1
Instructor Guide

Purpose Introduce Quality of Service support.
Details Quality of Service is used to regulate network traffic flows. Overlapping policies
are supported with the capability to specify a priority for a given policy. If students are
interested and there is enough time then briefly describe a typical QoS example. The
information below will help!
Additional Information There are two core components for policy-based networking
function:
QoS kernel extension (/use/lib/drivers/qos) - This kernel extension enables QoS
support and provides QoS manager functionality.
Policy agent (/usr/sbin/policyd) - this agent is a user-level daemon that provides support
for policy management and interfaces with the QoS kernel extension. Policy rules may
be defined in the /etc/policyd.conf file or retrieved from a central network policy server
using LDAP.
##Sample policy file##
# Mark and shape ftp-data traffic on TCP source port 20.
ServiceCategories tcp_20_svc
{
MaxRate 81920 # kilobits
MaxTokenBucket 128 # kilobits
OutgoingTOS 00011101 # binary
FlowServiceType Guaranteed
}
ServicePolicyRules tcp_20_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
SourcePortRange 20-20
DestinationPortRange 0-0 # Any dst port
ServiceReference tcp_20_svc
}
#End##
IPv6 Support
QoS for AIX 5.2 only supports IPv4. IPv6 is not supported.

Instructor Guide
Controlling the Policy Daemon

You can control the policy daemon by using the system resource controller (SRC). For
example, the command:
startsrc -s policyd -a "-i 60"
starts the policy agent with a refresh interval of 60 seconds.
The command
stopsrc -s policyd
stops the policy daemon.
Transition Statement Now, lets take a look at some checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint
1. T/F: No configuration of the clients or routers is needed to use a
VIPA in the server.
2. T/F: Multipath routing allows administrators to no longer have to
have a different destination, netmask, or group ID on a route
definition.
3. T/F: PMTU Discovery is used to determine the largest packet that
can be sent over a particular network.
4. T/F: You need to enable PMTU to take full advantage of multipath
routing feature.
5. T/F: Dead Gateway Detection, along with multipath routing allows
for multiple routes to the same destination which can be used for
load-balancing and failover.
Notes:

Instructor Guide
Instructor Notes:
Purpose Review.
Details
VIPA in the server. False. Clients need return routes to the
VIPA address. If there are intervening routers, they will need
routes as well.
definition. True.
can be sent over a particular network. True.
routing feature. False. In AIX 5L V 5.2 and earlier, you need to
disable PMTU discovery to stop the cloning of routes.
In AIX 5L V5.3, PMTU discovery has no effect on multipath
routing.
load-balancing and failover. True.
Transition Statement Exercise is next.

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Configuring
Network
Options
Notes:

Instructor Guide
Instructor Notes:
Details
Transition Statement Finally, lets summarize what we discussed in this unit.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
Virtual IP provides connection protection
Multipath routing allows more than one route to same destination
Load balancing
Availability
PMTU Discovery prevents fragmentation at the routers
Dead Gateway Detection will detect router failure and raise the cost
of any route that is down
Passive Dead Gateway Detection for minimal overhead
Active Dead Gate Detection for maximum availability
Quality of Service to regulate traffic
Notes:

Instructor Guide
Instructor Notes:
Purpose Summarize.
Details
Transition Statement Thats all for this unit.

V3.1.0.1
Instructor Guide
Uempty Unit 9. Domain Name System

This unit introduces the Domain Name System (DNS). It describes the
concept of the Domain Name System and the configuration of a name
server, and a client participating in a domain environment.

Describe domain name concepts and terminology
List the types of name servers
Configure a name server and client
Identify files used with DNS
Start the BIND daemon
Use commands to query domain name servers

Accountability:
Exercises
Copyright IBM Corp. 1997, 2006 Unit 9. Domain Name System 9-1
Instructor Guide
Unit Objectives
Describe domain name concepts and terminology
List the types of name servers
Configure a name server and a client
Identify files used with DNS
Start the BIND daemon
Use commands to query domain name servers
Notes:

V3.1.0.1
Instructor Guide

Purpose Introduce DNS.
Details First we discuss name serving and its history in the Internet.
Then we discuss the main concepts of DNS.
Next, we go into the specifics of configuring.
Transition Statement Let's start with concepts and terminology.
Instructor Guide
Name Resolution
Name
Internet Resolution
Hostname
Address
Use Use Use

Use Name NIS LDAP
/etc/hosts Server Server Server
Flat Network Domain Name NIS Environment LDAP Environment
Figure 9-2. Name Resolution AU079.1
Notes:
Systems use different methods for mapping host names to IP addresses. The method
depends upon the environment in which a system is going to participate.
Flat Network
- This method provides name resolution through the file /etc/hosts and works well in
small stable environments
NIS Server (Network Information System)
- This method provides a centralized server for administration of configuration and
other files within a LAN environment.
LDAP Server (Lightweight Directory Access Protocol)
- IBM secure way directory is an LDAP directory that provides client access to an
LDAP server.

V3.1.0.1
Instructor Guide

Purpose Discuss the three methods of name resolution.
Details Don't confuse domain in DNS with domain in NIS. With NIS, your lookup for data
map information was limited to the NIS domain you belonged to. In other words, if your NIS
domain name was accounting, the search was limited to the /var/yp/accounting data
maps. As you learn, DNS can navigate its own domain space to perform name resolution,
but DNS can also navigate information in other DNS domain databases.
Hosts in a DNS structure are related logically, often by geography or organization, not by
network, address, or hardware type. You might have twenty hosts, each on a different
network or different countries, all in the same DNS domain.
NIS domains are bound geographically since NIS broadcasts stay on the local network,
unless the NIS master server is also a router connecting two physical networks.
/etc/hosts is another method of name resolution. Using this method involves keeping the
/etc/hosts files updated and current on all hosts. There is a lot of administrative overhead
involved.
Additional Information NIS provides centralized control as well as automated
distribution of data maps. NIS can be used in conjunction with DNS or as an alternative.
Lightweight Directory Access Protocol (LDAP) is available under AIX. IBM SecureWay
directory is an LDAP directory that runs as a stand-alone daemon. It is based on a
client/server model that provides client access to an LDAP server.
Transition Statement Let's describe and introduce DNS.
Instructor Guide
Domain Name System

Created due to growth of the Internet and designed for large
networks
System that allows Name and IP lookups in a tree like database
structure
Hierarchical
Root domain . (dot)
Top level domains (TLDs)
Generic (gTLDs) such as com, org, net
Country code (ccTLDs) such as nl, au, uk
Subdomains
Nodenames are specified as FQDNs
Decentralized
Every domain implements its own tables and servers
Every domain can do its own delegation of subdomain
Figure 9-3. Domain Name System AU079.1
Notes:
To accommodate a large, expanding set of names in a network, it became necessary to
decentralize naming. This is what occurred as the internet grew.
The purpose of the Domain Name System is to create a system that allows lookups in a
tree-like database. These lookups are mostly (but not only) finding an IP address that
belongs to a node (a hostname) in the Domain Name System. A hostname in this respect is
always a Fully Qualified Domain Name (FQDN).
The DNS system knows a hierarchical structure:
The root node is the dot domain. This dot is the origin of all domains. It is comparable
with the root of a UNIX filesystem.
Below the root node you find a number of Top Level Domains (TLDs). These can further
be distinguished in Generic Top Level Domains (gTLD), such as com, org and net, and
Country Code Top Level Domains (ccTLDs), such as nl (for the Netherlands), au (for
Australia) and uk (for the United Kingdom).

V3.1.0.1
Instructor Guide
Uempty Below a Top Level Domain an organization can apply for a subdomain. The application
criteria and procedure for this varies from TLD to TLD. When an application has been
granted, then that organization becomes the owner of a domain, and can use it to store
information about its own hosts and (possibly) other subdomains.
Furthermore, the DNS system is decentralized. This means that there is no central
database which holds all the information, but organizations all keep their own databases on
their own servers. Through special so-called glue records, these databases all point to
each other, making global lookups possible.
Instructor Guide
Instructor Notes:
Purpose Introduce the DNS system.
Details
Additional Information The structure of the root domain, the gTLDs and ccTLDs is
managed by the IANA (http://www.iana.org). Management of the gTLDs is delegated by the
IANA to the internic (http://www.internic.net), and management of every ccTLD is
delegated by the IANA to a registrar for that country. The complete list of ccTLDs and the
registrars for each can be found at http://www.iana.org/cctld/cctld-whois.htm.
It is very illustrative to show the students these pages, test for the existence of various
domains, and look up the WHOIS information for some domains.
Transition Statement Let's look at an example.

V3.1.0.1
Instructor Guide
Uempty
Internet Domain Name Structure
The root domain
gTLDs
com org net nl au uk ccTLDs
ibm Zone of Authority

ibm.com domain
sf dc ny
Zone of
Authority
ny.ibm.com
sys1
The FQDN of this node is
domain
sys1.ny.ibm.com.
Figure 9-4. Internet Domain Name Structure AU079.1
Notes:
The visual shows an example of a possible DNS structure. The root domain is on top, with
the gTLDs and the ccTLDs right below it. There is one subdomain, ibm.com, which in itself
has another subdomain, ny.ibm.com. Furthermore, three hosts are shown, sf.ibm.com,
dc.ibm.com and sys1.ny.ibm.com.
A domain is a group of systems under the same administrative control. In the Domain
Name System, DNS, this is called a Zone of Authority. In reality, a Zone of Authority
specifies authoritative control of zone files for that domain.
Note that when we are talking about Fully Qualified Domain Names, the final dot should be
included. So the FQDN of sys1 is sys1.ny.ibm.com. and not sys1.ny.ibm.com.
Instructor Guide
Instructor Notes:
Purpose Discuss the DNS hierarchy.
Details
Transition Statement This hierarchy can be considered the key to our database. Now
let's look at the data itself.

V3.1.0.1
Instructor Guide
Uempty
Resource Records
Data (for instance, an IP address) is associated with a host using
Resource Records
The RR identifies the sort of data that is stored
Common RRs for hosts:
A (Address): The IP address of a host
PTR (Pointer): The hostname of a host
CNAME (Canonical Name): An alias name for a host
HINFO (Host Info): Information about a host
Common RRs for domains:
NS (Name Server): The nameserver of the domain
MX (Mail Exchanger): The mail server of the domain
SOA (Start of Authority): Information regarding the authoritative
name server
Figure 9-5. Resource Records AU079.1
Notes:
The hierarchical structure as shown in the previous visual can be thought of as the key to
the database. With an FQDN we can find the record for a specific host. The next thing we
need to retrieve is the data that is stored about this host. This is done through a series of
resource records.
Each resource record stores something about each host or domain. What is stored,
depends on the resource record type. There are several resource records possible. Some
are typically only used for a host, and others are typically only used for a domain. But there
is no general rule in this respect. In fact, the DNS system doesn't even know the difference
between a host or a domain.
Common RRs for a host include:
A (Address) This RR gives the IP address of a host.
PTR (Pointer) This gives the FQDN of a host.
CNAME (Common Name)This is used to define aliases. The CNAME is stored with the
alias and lists the official name of a node.
Instructor Guide
HINFO (Host Information)This gives information about the host itself, such as hardware,
operating system, administrative contact and so on.1
Common RRs for a domain include:
NS (Name Server) This identifies a name server for this node.
MX (Mail Exchanger) This identifies the mail server for this node.
SOA (Start of Authority) This indicates that a node and all nodes below it are managed by
an authoritative name server. It identifies the organizations gives some timing parameters
for the domain. These parameters have to do with how long entries may be cached and
how often slave name servers ndc.eed to check for updates, for instance.
1 For security reasons, this RR is rarely used any more.

V3.1.0.1
Instructor Guide

Purpose Discuss the concept of resource records
Details
Transition Statement Let's see how DNS lookups work
Instructor Guide
DNS Lookups
sys1 # host www.bbc.co.uk
com org net ie au uk
co
ibm
bbc
sf dc ny www
Ans is 150.10.10.10
A 150.10.10.10
sys1
Figure 9-6. DNS Lookups AU079.1
Notes:
The visual shows the result of the command host www.bbc.co.uk, executed on host sys1.
In the example, ten DNS queries and responses are performed:
1. The first query is a so-called recursive query from sys1 for the IP address of
www.bbc.co.uk to the DNS server of the ny.ibm.com domain. The IP address of this
name server is known to sys1 (it is configured in its /etc/resolv.conf file).
A recursive query in this respect means I want the answer to this question. This
means that the answer that sys1 expects is the IP address of www.bbc.co.uk
2. The second query is a so-called iterative query from the name server of ny to one of the
root nameservers. Again, the query is for the IP address www.bbc.co.uk.
An iterative query, in contrast to a recursive query, means I want your help in
answering this question. This means that the ny nameserver is happy with any help
that the other party can give.
The third packet is a reply from the root nameserver, and identifies the nameserver of the
uk domain.

V3.1.0.1
Instructor Guide
Uempty 3. The fourth packet is again an iterative query from the ny name server to the uk
nameserver.
4. The fifth packet is a reply from the uk nameserver, and identifies the nameserver of the
co.uk domain.
5. The sixth packet is again an interactive query from the ny name server to the co.uk
nameserver.
6. The seventh packet is a reply from the co.uk nameserver, and identifies the nameserver
of the bbc.co.uk domain.
7. The eighth packet is again an interactive query from the ny name server to the
bbc.co.uk nameserver.
8. The bbc.co.uk nameservers are authoritative for the bbc.co.uk domain. This means that
they have the database which describes all nodes in the bbc.co.uk domain, including
the www.bbc.co.uk node. So the answer that these nameservers can reply (in packet
number seven) is the IP address for the www.bbc.co.uk host.
9. The ny nameserver now knows the IP address of the www.bbc.co.uk host, and returns
this to sys1 (in the tenth packet).
Apart from the procedure to look up a hostname, this also illustrates the benefit of having a
combination of iterative and recursive queries:
Having a combination of clients doing recursive queries and name servers doing iterative
queries turns out to be the most efficient scheme.
Instructor Guide
Instructor Notes:
Purpose Discuss the DNS lookup procedure
Details If students have problems understanding the concepts of iterative and recursive
queries, that's OK. That knowledge is not needed in the rest of the unit.
Transition Statement We've seen that we can search the database for a hostname,
and then retrieve the IP address that belongs to this hostname. But we can do the same
thing the other way around as well. But obviously it is impossible to search every
nameserver on the planet to see who accidentally has a certain IP address. So they
created a handy trick for that.

V3.1.0.1
Instructor Guide
Uempty
DNS Reverse Lookups
sys1 # host 150.10.10.10
com org uk arpa
co in-addr
ibm
10
bbc
10
sf dc ny www
A 150.10.10.10 10
sys1 150
PTR www.bbc.co.uk.
Figure 9-7. DNS Reverse Lookups AU079.1
Notes:
IP address to Hostname lookups would, if nothing else was arranged, require you to go to
every DNS server on the Internet, and see if the IP address was somehow in its tables.
Obviously this is completely impossible. Yet we can do reverse DNS lookups. This is done
by using an ingenious trick, which involves a special in-addr.arpa domain. The visual
illustrates how this works.
Suppose someone wants to do a reverse DNS lookup for the IP address 150.10.10.10. The
first step then is to convert this IP address to its corresponding DNS name, which is
10.10.10.150.in-addr.arpa. This may look strange at first, but remember that IP addresses
become more specific when going from left to right, and that hostnames become more
specific when reading from right to left. To fit IP address in a hostname-based scheme, we
have to reverse the order.
Just as before, the name servers are then queried for this node. Only this time it's not the A
record (IP address) we're looking for, but the PTR (FQDN) record.
In all but a few cases, the organization that manages the name-to-IP domain also manages
the IP-to-name domain.
Instructor Guide
Note: It is extremely important that reverse DNS lookups are configured correctly. Almost
all services on the Internet can (and about half of the services actually will) perform a
reverse DNS lookup to retrieve the hostname of a client. This hostname is then used for
authorization and logging. If the reverse DNS lookup fails, chances are that the client is
simply not allowed to use the service, or only after a long time-out.
The host/nslookup and dig commands allow you to check whether regular and reverse
DNS lookups match.

V3.1.0.1
Instructor Guide

Purpose Discuss reverse DNS lookups
Details
Transition Statement Let's look at the various types of nameservers that you may want
to configure.
Instructor Guide
Types of Name Servers

Primary MASTER Name Server
Are authoritative for a domain
Service all client requests
Cache lookups
Secondary SLAVE Name Server
Are authoritative for a domain
Cache lookups
Retrieve data from a master nameserver in a zone transfer
Caching-Only Name Server
Are Non authoritative
Have no data for a domain
Cache lookups
Figure 9-8. Types of Name Servers AU079.1
Notes:
A master nameserver is a nameserver which is authoritative for a domain or multiple
domains (most likely the domain itself and the associated reverse DNS domains). This is
the server where the administrator makes changes to the DNS tables. The master
nameserver can serve requests from clients and other name servers, both recursive and
iterative. When it needs to perform a lookup for another domain and it receives answers, it
caches these answers for later reference.
A slave nameserver is also authoritative for a domain, but retrieves this data in a so-called
zone transfer from a master nameserver.2 It also can serve requests from clients and other
nameservers, and can cache data from other domains.
A caching-only nameserver does not have its own data and is not authoritative for a
domain. It just performs iterative queries for clients. All results obtained are cached
however, making it a useful thing to have in a small network which does not warrant its own
slave nameserver, but is connected to the outside world through a slow link.
2 In more complex environments, slave nameservers can also retrieve the data from other secondaries.

V3.1.0.1
Instructor Guide

Purpose Introduce primary, secondary, and caching-only name servers.
Details In general, a name server stores information about a domain. The primary name
server gets its information from itself. It configures and stores the DNS database for its
domain. The primary loads domain information from disk. There is normally only one
primary for each domain.
A slave name server downloads database information from a primary. When a slave server
starts up, it contacts the master name server for the data transfer. A secondary uses the
data transferred from the primary name server. The secondary assures it has current
information by periodically requesting the transfer of the information from the primary.
A caching-only name server is not authoritative for any one domain. Its only function is to
lookup data inside and outside domains. If a primary or secondary cannot answer a
request, it can be configured to send the request to a caching-only name server, which in
turn sends the query to other name servers. Once an answer is received back, the
caching-only name server caches the answer and then sends it to the requesting name
server. When the answer is sent back to the primary or secondary name server, they too
cache the answer so they have it should another request come in. What makes a
caching-only name server unique is this is the ONLY technique it uses to build domain
database information. As the cache grows to include the most requested information by the
DNS clients, a caching-only name server becomes useful. A caching-only name server
never has complete information for a domain. It just has what is cached. A caching-only
name server, unlike a secondary, avoids the overhead of doing zone transfers.
Additional Information Slave servers are able to zone transfer from primary master or
other slave servers. Slave servers also have the ability to perform primary master duties
acting as authoritative answer for that zone of authority. Refer to RFC 2136 for current DNS
update information (addendum to RFC 1035/consistent with RFC 1996).
Transition Statement ......And forwarders......
Instructor Guide
Forwarded Name Server

Forwarder Name Server
Are Non authoritative
Used in environments isolated from the Internet
Firewalled networks
Networks with unregistered IP address
Root
Internal Network Authoritative

Server
Query?
Authoritative
Server
FIREWALL
Client Answer!
DNS Server
Forwarder
Figure 9-9. Forwarded Name Server AU079.1
Notes:
Forwarder name servers handle off-site DNS queries for other servers in a network. When
a local server is directed to use a forwarder, it begins by looking in its own data base files
and its own cache for the information, and if it can't answer the query, hands off to the
forwarder with a recursive query. The local server is given a list of one or more forwarders,
to be queried in a defined order.
When a forwarder is queried, it goes outside the network, querying the root and other
authoritative servers as usual. If an answer is obtained, it is returned to the local server. If
none of the forwarders return an answer, the local server proceeds to contact the
authoritative servers itself.
In firewalled networks, forwarder name servers are often used. Local servers (inside the
firewall) are usually prevented from contacting outside servers and cannot perform iterative
queries to the root and other authoritative servers. Instead, a name server is run on the
firewall, having full access to the Internet. Local servers then forward their queries to the
server on the firewall.

V3.1.0.1
Instructor Guide
Uempty Alternatively, the forwarder may run outside the firewall, and internal servers are permitted
to contact it (but no other external servers). In still another variant, the forwarder may be
inside the firewall, and have the distinction of being the only internal name server that is
allowed external contact.
Another situation where forwarders are useful is in private networks where most of the
systems use unregistered IP addresses. In this case, a registered address is obtained for
the forwarder server, allowing it to communicate with the Internet. Other name servers use
unregistered addresses, and perform all queries to the Internet via the forwarder.
Instructor Guide
Instructor Notes:
Purpose Explain how forwarder name servers work and describe there role.
Details The way the local server knows which forwarders to query, and in which order, is
by consulting the forwarders directive in the named.boot or named.conf file.
It is also possible to configure applications to contact forwarder servers directly, eliminating
the role of the local server. However, in some cases, a forwarder is necessary or at least
desirable. For example, access from clients to the forwarder may be restricted. Or, the
forwarder may be at another location (one that has Internet access) and response time is
improved by having a local, caching name server.
To make a server a slave, place the directive options forward-only in its boot file. (Note that
in earlier versions of BIND, the directive slave had the same effect, but is now deprecated.)
Slave servers would be used especially when Internet access is impossible, since this
eliminates long hangs while the local servers attempt to contact the root servers.
Transition Statement Lets determine how we belong to a flat or domain name
environment.

V3.1.0.1
Instructor Guide
Uempty
Domain or Flat Network?
No /etc/ Yes
resolv.conf
exist?
FLAT DOMAIN
NETWORK NETWORK
Figure 9-10. Domain or Flat Network? AU079.1
Notes:
TCP/IP offers name resolution methods for two network types:
Flat network
Domain network
The existence of /etc/resolv.conf determines how a system resolves hostnames and IP
addresses within a domain or flat network.
If /etc/resolv.conf exists, then use resolver algorithm.
If /etc/resolv.conf does not exist, then use /etc/hosts file.
Instructor Guide
Instructor Notes:
Purpose Discuss the role of /etc/resolv.conf.
Details If /etc/resolv/conf exists, then the system uses name resolution hierarchy for
resolving. If /etc/resolv.conf does not exist, then the system will use the /etc/hosts file for
resolving. Also, note that syntax is unforgiving.
Additional Information Five main directives for usage in the resolv.conf file:
domain
search
nameserver
sortlist
options
Transition Statement Let's take a look at the default order assigned to resolving
names.

V3.1.0.1
Instructor Guide
Uempty
Name Resolution
Default
DNS, NIS which is authoritative, local
Overriding the Default name resolution
Option 1
Create /etc/netsvc.conf
Options include bind, ldap, nis, local
Example host=bind,local,nis
Option 2
Set NSORDER environment variable
NSORDER=nis=auth,bind,local
Figure 9-11. Name Resolution AU079.1
Notes:
Default Name resolution specifies:
If DNS is running then check DNS servers for answer as specified in /etc/resolv.conf file
If DNS is not running or does not return the answer then check to see if NIS is running.
NIS is deemed authoritative. If NIS is running and does not return the answer then
name resolution fails. If NIS is not running then finally the local /etc/host file is checked.
The default Name resolution can be overwritten in two ways:
Create /etc/netsvc.conf. To specify host ordering within this file, use the host attribute
followed by the name of the resource to use. The resources listed depends on what
name resolution processes are running on the network.
Create an environment variable NSORDER. NSORDER overrides any name resolution
specified in /etc/netsvc.conf file.
Instructor Guide
Instructor Notes:
Purpose Compare default name resolution hierarchy when all name resolution methods
are available.
Details When a process receives a symbolic host name and needs to resolve it into an
address, it calls a resolver routine. Resolver routines attempt to resolve names using the
default order BIND/DNS, NIS, /etc/hosts.
Cover the student notes for flow through the hierarchy.
The point to stress is if NIS is running, /etc/hosts NEVER accessed. NIS name resolution
is considered authoritative over the /etc/hosts file.
Transition Statement Now lets see how we can configure a DNS domain.

V3.1.0.1
Instructor Guide
Uempty
Planning a Domain Network
Determine systems in domain
Determine domain name
Choose primary name server
Choose secondary name servers
Remaining systems are clients
Figure 9-12. Planning a Domain Network AU079.1
Notes:
Determine which hosts need to communicate with each other
Register domain name with InterNIC
Centrally located nameserver in each network or subnet
Backup server ability
Resolvers
Instructor Guide
Instructor Notes:
Purpose Discuss the planning process for DNS.
Details There are at least five steps that need to be planned before DNS configuration
begins.
1. Determine the hosts that are in a domain (logically not physically or geographically).
Determine this by which hosts need to communicate with each other.
2. Choose a domain name that is unique to the Internet, and decide where you fit within
the domain hierarchy. Even if you are not connecting to the Internet today, it is advised
that you register with the InterNIC to avoid having to reconfigure your system in the
future.
3. A good rule of thumb for selecting a name server:
- Have a name server for each network or subnet. This removes the router as a single
point of failure.
- A file server is a good choice, especially if serving diskless hosts.
- Select large, fast, time-sharing systems that are properly situated on the network
(not located behind a slow serial connection).
4. Select at least two secondary servers to also remove the name server as a single point
of failure.
5. All remaining systems selected from Step 1 are DNS clients (resolvers).
Additional Information It is also suggested that syslogd is started so errors can be
logged in syslog.conf.
Transition Statement Let's briefly cover DNS offerings in AIX then deal with a scenario
that will be used throughout the rest of this unit.

V3.1.0.1
Instructor Guide
Uempty
BIND Version Support in AIX
BIND 8
Uses Control file /etc/named.conf
Actual version is 8.1.2
Default
BIND 9 latest version
Also uses Control file /etc/named.conf
Actual version is 9.2.0
Figure 9-13. BIND Version Support in AIX AU079.1
Notes:
Each version of BIND has its own configuration requirements and they are different. The
version of BIND you choose also affects which mode of security you can use. For more
information, refer to Communication and Networks section of the System Management
guide.
The following are a summary of new functions provided with BIND 8:
Secure dynamic DNS updates
BIND 8 offers the secured RFC 2136 update protocol. The secure update protocol is
implemented by IP-based Access Control lists.
Notify
Implements the RFC 1996 Notify process. This is a method by which the primary DNS
server can indicate to its secondary name servers that zone data has been updated.
This decreases the time periods in which a secondary DNS server has data out of sync.
Instructor Guide
File conversion utility

Extends the configuration file conversion utility to support IBM functional additions to
previous BIND releases. This involves mapping the dynamic keywords of previous
named.boot files to a functional equivalent in the named.conf configuration file.
The following are a summary of new functions provided with BIND 9:
Incremental Zone Transfers
BIND 9 implements the RFC 1995 Incremental Zone Transfer protocol and is on by
default. This protocol defines a method through which secondary DNS servers can
update their existing zone data to incorporate all the cumulative changes to the primary
zone since the last transfer. This protocol supersedes the performance of ordinary zone
transfers by limiting the amount of network traffic between primary and secondary DNS
server and the subsequent computation time in incorporating an entire new zone. The
protocol ensures that incremental zone transfers can be sent to indicate changes from
both dynamic updates and from zones changed on a disk (those reincorporated through
a refresh signal or server restart).
DNS Security enhancements
TSIG
BIND 9 primarily supports TSIG for server-to-server communication. This includes zone
transfer, notify, and recursive query messages. TSIG is also useful for dynamic
updates. A primary server for a dynamic zone should use access control to control
updates, but IP-based access control is insufficient.
By using key base encryption rather than the current method of access control lists,
TSIG can be used to restrict who can update to the dynamic zones. Unlike the Access
Control List (ACL) method of dynamic updates, the TSIG key can be distributed to other
updaters without having to modify the configuration files on the name server, which
means there is no need for the name server to reread the configuration files.
SIG
BIND 9 partially supports DNSSEC SIG transaction signatures as specified in RFC
2535. SIG uses public and private keys to authenticate messages. SIG records allow
administers to sign their zone data, thereby stating that it is authentic. SIG requires
OpenSSL 0.9.5a or newer to be installed.
Improved DNS Tools
DIG
Domain Internet Groper (DIG) is used a a replacement for nslookup. DIG example is
shown later in this UNIT.
RNDC and RNDC-CONFGEN
Tools to control the nameserver. Allows administrators to stop, reload, get statistics of
the nameserver, and dump the database remotely. Require editing the named.conf for

V3.1.0.1
Instructor Guide
Uempty RNDC access and creating and rndc.conf file which can be generated automatically by
using the rndc-confgen utility.
CHECKCONF and CHECKZONE
Are recommended tools but not yet supported at the time of writing. Used to check for
syntax errors in configuration and zone files. Can be downloaded from
http://www.isc.org.
IP version 6
BIND 9 fully supports all currently defined forms of IP version 6 named to address and
address to name lookups.
Instructor Guide
Instructor Notes:
Purpose Describe DNS offerings in AIX
Details Point out that BIND 8 is default DNS version on AIX.
Transition Statement Now lets go through a DNS example scenario.

V3.1.0.1
Instructor Guide
Uempty
Scenario - Domain Name Structure
(root)
com
ibm
sys99.ibm.com
dc
sys1 - Primary
Name Server
10.19.98.1 sys6 - Secondary
sys4 Name Server
10.19.98.2 10.19.98.3 10.19.98.4 10.19.99.6
sys2 sys3 10.19.99.4
sys4e 10.19.99.5
sys5
Figure 9-14. Scenario - Domain Name Structure AU079.1
Notes:
Domain characteristics:
One domain dc.ibm.com
Two physical networks 10.19.98 and 10.19.99
One primary name server 10.19.98.1
One secondary name server 10.19.99.6
Primary and secondary name servers configured with a cache file pointing to the name
server sys99.ibm.com on the higher-level domain ibm.com on network 10.19.93.
Note that the DNS standards require at least two name servers for every zone. In this
scenario, we have left out the backup for sys99.ibm.com for simplicity.
Instructor Guide
Instructor Notes:
Purpose Introduce the scenario that is used during this unit.
Details It is assumed that we have registered with the appropriate authorities for our
domain and network address. Our subdomain is dc, and it fits structurally under the ibm.
subdomain and the com top-level domain. All hosts are in the dc.ibm.com domain and are
named sys1 through sys6.
Notice there are two physical networks, and all the hosts on both networks are included
under the zone of authority for the primary and secondary name servers. sys1 is the
primary name server, and sys6 is the secondary name server. sys6 has been selected
because it is a separate network removing the router as a single point of failure for
resolving names.
There is NO caching-only name server in this scenario, but both the primary and secondary
name servers are configured with a cache file that points to the name server in the
ibm.com domain, sys99.ibm.com, should they not be able to answer a query from a
client. This means that if sys99 can resolve the query, the primary and/or the secondary
caches the resolution, thus allowing it to answer any further queries for the same host from
its cache.
Transition Statement Let's start the configuration process of the primary name server.

V3.1.0.1
Instructor Guide
Uempty
Setting Up the Primary Name Server
Create named control file
Create name zone file
Create IP zone files
Create local IP zone file
Create cache file
Create /etc/resolv.conf
Start named daemon
Figure 9-15. Setting Up the Primary Name Server AU079.1
Notes:
All zone files are created using a Standard Resource Record format. These standards are
explained as we look at each file.
The named daemon must be started after all the files are created.
Named8 (version 8 of BIND) is started by default and uses the /etc/named.conf control file
to configure the domain.
Instructor Guide
Instructor Notes:
Purpose Introduce the steps for setting up the primary name server.
Details Use this list to guide the students through all the details of the upcoming pages.
Each file listed here is covered in detail on the following pages. Briefly, we cover the overall
purpose of each.
1. The named control file is the pointer file to the DNS database.
2, 3, 4. The name zone file, IP zone file, and local IP zone file are the actual files that
contain the database information.
5. The cache file contains a list of name servers which are queried to obtain name
resolution information outside the domain.
6. The /etc/resolv.conf file identifies this host as the primary name server and directs it to
use its own database information.
7. named is the daemon process that makes it all work. It listens for requests, responds to
those requests, and maintains the name server database
Transition Statement Let's start with Step 1, creating the named control file for BIND 4

V3.1.0.1
Instructor Guide
Uempty
/etc/named.conf
# cat /etc/named.conf
options { directory "/etc"; };
zone "dc.ibm.com" {
type master; file "named.dc";
};
zone "98.19.10.in-addr.arpa" {
type master; file "named.revip98";
};
type master; file "named.revip99";
};
type master; file "named.local";
};
zone "." {
type hint; file "named.ca";
};
Figure 9-16. /etc/named.conf AU079.1
Notes:
The /etc/named.conf file is read by the named daemon when it starts. It specifies the
location of all data which the daemon uses to create the initial name server database.
The directory entry tells the named daemon that all file names listed in this file are stored
in the /etc directory.
The primary entry indicates the domain for which this local named daemon is the primary
name server, and the file from which to get the data describing the domain.
The domain name for the reverse mapping must always end with in-addr.arpa. The octets
of the IP addresses must be reversed when forming a domain name, because IP
addresses have the most significant octets first, while domain names have the least
significant octets first. There should be a file for each physical network.
The . (period) in the domain field of the cache record means any domain not explicitly
listed elsewhere. A cache file allows a host in the default domain to communicate with
hosts outside the domain.
Instructor Guide
Instructor Notes:
Purpose Explain the use and contents of the named.conf file on the primary name
server.
Details The named.conf control file is read by the named daemon when it starts. It
specifies the location of the database files. The name, named.conf, is used by convention
on most platforms.
Additional Information The loopback address simplified network applications by
allowing the local host to be addressed in the same manner as a remote host. The
loopback address simplifies software by allowing common code to be used for
communicating with local or remote processes. It also reduces network traffic, because the
local host address is associated with a loopback device that loops data back to the host
before it is written out to a network. Because every system uses the loopback to send
datagrams to itself, this entry is in every host's routing table.
The presence of the cache file says name resolution can be done somewhere else and the
response sent back to this name server. This primary name server then caches the
response in memory, allowing it to reuse the answer should an identical request be made
by a client again.
Newer BIND enhancement no longer require the domain statement in the named.conf as
domain comes from hostname or out of /etc/resolv.conf file.
Discussion Items There are no requirements to store files in the /etc directory. A better
choice could be a separate directory/subdirectory or even a separate file system with a
different volume group.
Transition Statement Now that the named.conf file is built, let's look at some helpful
scripts to assist in building the information for the zone file.

V3.1.0.1
Instructor Guide
Uempty
Scripts to Build Zone Files
IBM provides awk scripts
/usr/samples/tcpip/hosts.awk
/usr/samples/tcpip/addrs.awk
Run on /etc/hosts file
Produce name and IP zone files
Use to create initial zone files
Figure 9-17. Scripts to Build Zone Files AU079.1
Notes:
IBM provides awk scripts that read the system's /etc/hosts file and generate the
appropriate zone file.
These awk scripts are not meant to provide a perfect zone file for your situation. It provides
a beginning. Once the file is created, additional records or changes can be made by the
editor of your choice.
Execute the commands as follows:
# cd /usr/samples/tcpip
# ./hosts.awk /etc/hosts > /etc/named.dc
# ./addrs.awk /etc/hosts > /etc/named.revip98
# ./addrs.awk /etc/hosts > /etc/named.revip99
Instructor Guide
Instructor Notes:
Purpose Discuss the purpose and advantage of using awk scripts to create the
database information.
Details The zone files that need to be built are named.dc, named.revip98, and
named.revip99. They must be built using Standard Resource Record format. Once you
see the format, you are thankful that IBM supplies awk scrips to do this for you.
The awk scripts read the /etc/hosts file to build the files. The hosts.awk script will build the
name-to-IP database for the named.dc file. The addrs.awk script builds the reverse IP
files, named.revip98 and named.revip99.
Additional Information If DNS is being set up in a heterogeneous environment, the
zone files are usually created on a RISC System/6000 using these scripts, then transferred
to the appropriate platform for use.
Transition Statement Let's look at an example zone file.

V3.1.0.1
Instructor Guide
Uempty
Name Zone File
# pg /etc/named.dc
; name server data file

; also see /etc/named.boot
; NAME TTL CLASS TYPE RDATA
;
; setting default domain to "dc.ibm.com"
;
@ IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.(
200321031200 ; Serial
3600 ; Refresh
300 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL
IN NS sys1
IN NS sys6
sys1 IN A 10.19.98.1
sys2 IN A 10.19.98.2
sys3 IN A 10.19.98.3
sys4 IN A 10.19.98.4
sys4e IN A 10.19.99.4
sys5 IN A 10.19.99.5
sys6 IN A 10.19.99.6
localhost IN A 127.0.0.1
loopback IN CNAME localhost
Figure 9-18. Name Zone File AU079.1
Notes:
The name field varies depending on the type. It can specify a domain, a zone of authority,
the name of a host, the alias of a host, and so forth. It must begin in column 1. If this field is
left blank, the name defaults to the value of the previous resource record.
The TTL field is Time to Live. This is specified in seconds. A value of 9999999 means no
time-out. If not specified, it defaults to the SOA record's minimum entry.
The class field is the address class of the record. There are two valid entries: IN for
Internet and ANY for all other address classes.
The type field is the type of resource record. Some valid types are: SOA - Start of
Authority, NS - Name Server, A - Address, HINFO - Host Information, CNAME - Canonical,
and MX - Mail Exchanger.
The rdata field contains specifics for the particular record type.
Instructor Guide
Special Characters:
; indicates a comment.
. if used in the name field, a freestanding dot indicates current domain.
@ if used in the name field, a freestanding at sign indicates current origin.
() parentheses are used to continue data across more than one line.
SOA (Start of Authority) Record:
Name of host where data files reside, and the e-mail address of the user responsible for
keeping the data file current.
Serial - version number of this data file. This number should be incremented each time
there is change to the data. The secondary checks this value to see if it needs to download
information again. The serial number can be given as a normal integer or it can include a
dot as shown in the chart. In that case, the number to the left of the dot is multiplied by
10,000 and added to the number to the right.
Refresh - time interval that secondary checks for data change. 3600 seconds is one hour.
Retry - time interval secondary waits after failure to reach primary for a refresh. 300
seconds is five minutes.
Expire - upper time limit used by secondary to flush data after continued failure to contact
the primary. 3600000 seconds is approximately 42 days.
Minimum - is the minimum time to live used as the default. This overrides individual entries
if those entries are lower.
The hosts.awk script does not build a perfect zone file. This file was edited to add the full
domain name of the primary server in the SOA record. Also, the name, sys1, had to be
added in the rdata field for the NS type entry.

V3.1.0.1
Instructor Guide

Purpose Explain the name zone file syntax.
Details This named.dc zone file was created with the hosts.awk script and the
/etc/hosts file. (Take a minute to refer the students back to the named.boot file. Explain
how the first primary statement points to this file.) You now get a look at what is meant by
Standard Resource Record format. There are five fields of information in a standard
resource record: name, ttl, class, type, and rdata.
Any object listed in the name field is affected by this resource record. We have two entries,
@ and a list of host names. The @ sign is a special character that says use the current
domain name. In the named.boot file, we said the domain name was dc.ibm.com. The
domain is the origin of all the data in this file. The origin is appended to all names in the
database file not ending with a dot. The other objects in the list are the host names that
were taken from the /etc/hosts file. The ;s are for comments, just like the #s in AIX files.
The second field, ttl (time-to-live), defines the length of time, in seconds, that the
information from this standard resource record should remain in cache. 9999999 is the
default for forever. If there is no value, the default becomes the value of the Minimum ttl
field in the start of authority record.
The third field is class, which defines the address class of the resource records. The
Internet address class is referred to with IN. All resource records used by the Internet have
IN in this field.
The type field indicates the type of data for the record. We see four types listed here; SOA,
NS, A, CNAME. SOA is for start of authority, which indicates that the name server listed in
the rdata field is the best source of information for the data in this domain. Our name
server, sys1, is authoritative for the domain dc.ibm.com. The SOA record is required in
the file. SOA information is kept in memory for faster access.
The entry for root.sys1.dc.ibm.com is the e-mail address of the person in charge of the
data. The line ends with an open parenthesis, which allows the information for the rdata to
continue across multiple lines. Let's continue discussing the rest of the record data for the
type SOA. Most of the information for the SOA is used by the secondary name server.
Serial is used by the secondary name server to determine if the zone file has been updated
since the last time the secondary pulled the zone file information from the primary name
server. If the secondary's serial number is lower than the primary name server's serial
number, the secondary's zone data is out of date. The secondary then requests a zone
transfer. Changing this serial number is a manual process. As the system administrator
updates this file to add or delete host information, the serial number must be incremented.
Refresh tells the secondary how often to check the serial number on the primary. 3600
seconds is one hour. A low refresh value keeps the primary and secondary in sync. The
number should be based on how often the database is updated. Setting it higher reduces
the load on the network.
Retry is used by the secondary if it fails to communicate with the primary name server after
the refresh period. 300 seconds is every 5 minutes.
Instructor Guide
Expires is used by the secondary when it fails to contact (or retry) the primary name server.
In this case 3,600,000 seconds is 42 days. This means that if the secondary cannot contact
the primary after this time, it stops giving out data. The data is assumed to be so old that it
is no longer accurate.
Minimum is the time to live which is 86,400 seconds or one day. This is the default ttl
should one not be defined in the ttl field.
The SOA is ended with the close parenthesis.
Let's take a look at the other entries in the type field along with the rdata field.
NS specifies that this entry is for the name server and the rdata specifies the name of the
name server.
The A denotes an address record. These records convert host names to IP addresses.
sys1, under the name field, is the name of the host whose address is in the rdata field.
Look down to the entry for localhost. The type field is CNAME. localhost is considered an
alias name found in the /etc/hosts file. CNAME stands for canonical name. CNAME
provides the alternate host name that may be used by a user or an application.
Point out the two lines that must be edited after running the hosts.awk script. It is covered
in the student notes. Explain that other vendor platforms don't supply scripts making this
file tedious to set up.
Additional Information The maximum length of the number in the ttl field is 8 positions.
There can only be one SOA in the file.
The serial number can be incremented as a whole number or a decimal.
If your name server is BIND 4.9.4 or newer, you have to pay extra attention to how your
hosts are named. Starting with 4.9.4, BIND checks hostnames in conformance for RFC952.
If a host doesn't conform, BIND considers the zone to have a syntax error. Also, note that
underscore characters are not allowed in host names.
Transition Statement Let's now look at a zone file created by the addrs.awk script
used for reverse name resolution.

V3.1.0.1
Instructor Guide
Uempty
IP Zone File
# pg /etc/named.revip98
; NAME TTL CLASS TYPE RDATA

; setting default domain to . . . dc.ibm.com
@ 9999999 IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.(
200321031200 ; Serial
3600 ; Refresh
300 ; Retry
3600000 ; Expire
9999999 IN NS sys1.dc.ibm.com.
9999999 IN NS sys6.dc.ibm.com.
1 9999999 IN PTR sys1.dc.ibm.com.
Figure 9-19. IP Zone File AU079.1
Notes:
Names in DNS are set up in a hierarchy. To resolve an address, the system traces the
hierarchy, contacting a server for each subdomain in the name. Since this structure is
based on name, there is no easy way to translate a host address back into its host name.
The in-addr.arpa record domain was created to allow reverse translation. This domain
uses the address of a host to point to the name and data for that host.
The four octets of a host number are reversed to make the transversal left to right, similar
to the domain name.
Valid resource record types are: SOA - Start of Authority, NS - Name Server, and PTR -
domain name pointer.
There should be one reverse hosts data file per network.
Instructor Guide
Note: Since some systems are on network 9.19.98 and others on 9.19.99, this file will have
to be created twice, once for each network. Since both files are built from the /etc/hosts
file, which contains entries for both networks, each file has to be edited to delete hosts on
the other network and to delete the network octets from the IP address in column one,
leaving just the host octet.

V3.1.0.1
Instructor Guide

Purpose Explain how to set up reverse IP resolution.
Details The IP zone file provides reverse IP resolution (host names to IP addresses).
Refer back to the named.conf file to see how this file is pointed to. In the named.conf file,
there are two primary statements for the two domain names for reverse resolution,
98.19.10.in-addr.arpa and 99.19.10.in-addr.arpa, each pointing to their own file. In our
example, we are looking at the named.revip98 file. A second one would be created for
named.revip99, as well.
This file was created by the /usr/samples/tcpip/addrs.awk and the /etc/hosts file. Just
like the named.dc file, this file is set up in Standard Resource Record format. It has the
same five fields of information and the same SOA record.
Notice that the name field is the host octet. Looking back at the named.conf file, for each
host name in this file, the 98.19.10 domain name is appended to create the full IP address.
Using the addrs.awk script means that you have to edit this file to delete out the 10.19.98
network portion of the address. The addrs.awk script pulls in the entire IP address.
What is new in this file is the PTR resource record type in the type field. The PTR records
provide address-to-name conversion. The host name in the rdata field is fully qualified to
prevent it from being relative to the current domain.
Notice that the fully qualified domain name in the rdata field ends with a .(dot). This dot
represents the root domain at the top of the hierarchy. This means that the default domain
name, dc.ibm.com, is NOT appended to this name.
Transition Statement Let's discuss the last zone file to be created.
Instructor Guide
Local IP Zone File
# pg /etc/named.local
@ IN NS sys1.dc.ibm.com.
1 IN PTR localhost.
Figure 9-20. Local IP Zone File AU079.1
Notes:
The local IP zone file contains the local loopback address for the network 127.0.0.1.
Valid resource record types are: SOA - Start of Authority, NS - Name Server, and PTR -
domain name pointer.
The SOA record is not required in the local IP zone file. It is required in the name zone file
and IP zone file. The presence of the @ sign indicates the current domain.

V3.1.0.1
Instructor Guide

Purpose Discuss the contents and syntax of the local.ip zone file.
Details This file is used to locally resolve the loopback address, 127.0.0.1 into the name
localhost. It is the zone file for the reverse 0.0.127.in-addr.arpa entry is indicated in the
named.conf file. All systems use 127.0.0.1 as their loopback address.
The file is so small that it can be created using an editor. This file can contain the same
SOA record as the other files, or a shortcut is to use the @ in the first field. The @ notation
is most often used if the domain name is the same as the origin (set in the named.conf
file).
The first line declares the domain to be dc.ibm.com. It is an Internet class, a name server
type, with the rdata being the fully qualified domain name of the name server (ending with a
dot).
The second line is the IP to host name mapping with 0.0.1 being the host name of the
localhost on network 127, but in /etc/named.boot for this zone file, we asked for
0.0.127.in-addr.arpa to be added to the file entries. It is an Internet class, a PTR type, and
the rdata being the fully qualified domain name, also ending with a .(dot). (Refer the
students back to the entry in named.conf for 0.0.127.in-addr.arpa.)
Additional Information With the reverse mapping file, the biggest error made is leaving
off the ending dot.
Note that the SOA and NS records can be left out of the local IP zone file. Doing so,
however, causes a message to be written to the syslog.
Transition Statement Let's discuss the last file, named.ca.
Instructor Guide
Cache File
# pg /etc/named.ca
. 99999999 IN NS sys99.ibm.com.
sys99.ibm.com. 99999999 IN A 10.19.93.99
- OR -
. 99999999 IN NS a.root-servers.net.
a.root-servers.net. 99999999 IN A 198.41.0.4
. 99999999 IN NS b.root-servers.net.
b.root-servers.net. 99999999 IN A 128.9.0.107
. 99999999 IN NS c.root-servers.net.
c.root-servers.net. 99999999 IN A 192.33.4.12
; and so forth
Figure 9-21. Cache File AU079.1
Notes:
The cache file has exactly the same layout as the files we've discussed before. It basically
describes the characteristics of the root (dot) domain.
The only difference is that we are not authoritative for this domain, so we cannot specify a
SOA record. And we do not know (or at least, we're not supposed to know) any IP
addresses in this domain. The only thing we are supposed to know is the name and, more
importantly, the IP address of the nameservers which serve this domain. So these are the
only entries listed in this file.
Now, there are two possibilities here:
The first possibility is that you are a nameserver on an intranet, with no direct outside
connection. In this case, you list an upstream DNS server as the name server for the
root domain. Which one is really not important, as long as they are able to resolve your
queries.

V3.1.0.1
Instructor Guide
Uempty The second possibility is that you are a nameserver on the Internet. In this case, you
should list the root nameservers of the Internet themselves. This list can be obtained on
the Web and added to your files. In addition to this, BIND automatically contacts one of
these nameservers when BIND is started, and retrieves the current list of all root
nameserver. It then uses this information instead.
Instructor Guide
Instructor Notes:
Purpose Describe the content and syntax of the cache file.
Details Refer the students to the named.conf file. The last statement is a cache
statement which points to the cache file. The cache file points to a higher-level domain
server that could be used to find an answer to a query that cannot be resolved in the
primary name server database. Create this file using an editor. The same five fields exist.
There is no reason to have an SOA record. The dot in the first field says use the default
domain. Next, the higher-level name server is listed, sys99.ibm.com. Think of our hierarchy
(dc.ibm.com). If a name cannot be resolved locally, contact the higher-level domain name
server, sys99.ibm.com. The second line is an address record that resolves the host name
to an IP address. Notice the existence of the dots which represents that this is a fully
qualified domain name.
sys99.ibm.com is a name server. If it has the answer to the query, the answer will be
passed back to the primary name server, sys1.dc.ibm.com. sys1.dc.ibm.com will cache
this answer. If the same query is made again, sys1 will have the answer in its cache and
will not have to query the higher-level authority, sys99.ibm.com. All name servers cache
for efficiency. This does not make it a caching-only name server.
Transition Statement There are no more zone files to build, but there are a few
remaining steps.

V3.1.0.1
Instructor Guide
Uempty
Final Primary Name Server Setup Steps
Change the host name to the fully qualified domain name
# smit hostname
# vi /etc/rc.tcpip
Uncomment line to start named
# startsrc -s named
Figure 9-22. Final Primary Name Server Setup Steps AU079.1
Notes:
There are many services or applications that determine your domain name by checking
your system's host name. Use SMIT to change the host name so it gets set upon reboot.
/etc/resolv.conf must exist to tell the system it is operating in a domain environment. For
our example, the following works:
nameserver 0.0.0.0
domain dc.ibm.com
nameserver 10.19.99.6
The /etc/rc.tcpip file must be updated so that named will be started at system reboot. The
SRC is then used to start the named daemon. Both these steps can be accomplished
using smit.
# smit stnamed
Select the BOTH option from the Start Using the named subsystem menu.
Instructor Guide
Instructor Notes:
Purpose Describe the final steps in configuring the primary name server after the
database has been created.
Details These steps remain in the primary name server configuration. An example for
our scenario is given in the student notes. It is also possible to have an empty
/etc/resolv.conf on a name server, but the preferred method is to have a nameserver
directive indicating the loopback address and a domain directive indicating the domain the
name server belongs to. Note that if an empty /etc/resolv.conf is to be used, it must be
zero length, that is, created with a command such as > /etc/resolv.conf.
Next, be sure the named daemon is uncommented in the /etc/rc.tcpip file. This ensures at
the next system restart, named gets started automatically. Start named using SRC or
SMIT. If you use SMIT, SMIT uncomments the entry in /etc/rc.tcpip automatically.
It is important to set the system's hostname (without trailing dot) when using sendmail.
Failure to do so will cause sendmail to reject messages for the local host.
Transition Statement Note: This is a good time to break and allow everyone to perform
the first section of the exercise Setting Up the Primary Name Server. This allows all the
DNS information just presented to sink in before continuing on with configuration of the
secondary name server and the clients. If you choose to do this, introduce the exercise,
assign the designated primary name server and the designated secondary name server.
The team that volunteers as the secondary name server must observe and assist another
team. They get their chance to perform their configuration during the second section of this
exercise.
Let's take a look at creating the secondary.

V3.1.0.1
Instructor Guide
Uempty
Setting Up the Secondary Name Server
Create named control file
Create local IP zone file
Create cache file
Start named daemon
Figure 9-23. Setting Up the Secondary Name Server AU079.1
Notes:
The named daemon must be started after all the files are created.
The /etc/resolv.conf file should be similar to that on a primary name server. Here, an
appropriate /etc/resolv.conf would be:
nameserver 0.0.0.0
domain dc.ibm.com
You can use multiple nameserver directives to direct name resolution process to check
another name server if the local DNS is down.
Instructor Guide
Instructor Notes:
Purpose Identify the five steps in creating a secondary name server.
Details The difference between the primary name server and the secondary name
server is where they get their information. The primary reads its own files; the secondary
downloads information from the primary via a zone transfer.
The advantage of the secondary name server is no maintenance of files. All the
maintenance is done on the primary name server (which will be covered later).
The disadvantage of the secondary is it does not resync the information instantly when the
serial number is changed in the SOA on the primary name server.
The named control file, local IP zone file, and cache file must be created on the secondary.
They are not part of the zone transfer. The secondary must have an /etc/resolv.conf file
and the named daemon started.
Additional Information A secondary name server starts a child process to perform a
zone transfer, allowing it to keep answering queries while zone data is being transferred
from the primary name server.
The secondary name server is not limited to loading the information from a primary name
server. It can get its information from another secondary.
Transition Statement Let's start by looking at the contents of the named.conf file for
the secondary name server.

V3.1.0.1
Instructor Guide
Uempty
Secondary named Control File
# pg /etc/named.conf
# cat /etc/named.conf
options { directory "/etc";};
zone "dc.ibm.com"{
type slave; file "named.dc"; masters {10.19.98.4;};
};
zone "98.19.10.in-addr.arpa"{
type slave; file "named.revip98"; masters {10.19.98.4;};
};
};
zone "." {
};
Figure 9-24. Secondary named Control File AU079.1
Notes:
The secondary entry indicates the domain for which this local named daemon is the
secondary name server. It retrieves the domain information from the IP address specified
and stores the information it receives in the file specified. This file is the backup file for the
primary name server.
Whenever a new copy of the domain information is received from one of the primary
servers, the named daemon updates the backup file for that primary server.
When the named daemon is first started, the secondary downloads information from the
primary. The secondary queries the primary name server at regular intervals based on the
SOA record's refresh parameter.
The IP address of the primary name server must be indicated before the file name so the
secondary name server knows which system is the primary name server. The backup files
are optional. By default, the database information is downloaded from the primary name
server to the memory of the secondary name server. Should the secondary have to reboot,
it uses the backup files if they exist, rather than requesting another download from the
primary causing unnecessary network traffic.
Instructor Guide
Instructor Notes:
Purpose Explain named.boot on the secondary name server.
Details The name of the file, /etc/named.conf, and the directory and domain entries are
identical with those on the primary name server.
Secondary line entries are used (not primary line entries) as this is the secondary name
server. The first secondary line entry reference dc.ibm.com as its domain. Before the file
name, in this statement, add the IP address of the primary name server. In our example, it
was 10.19.98.1. This statement tells the name server that it is secondary for the zone
dc.ibm.com, and that it should check the version of this zone on the name server
10.19.98.1. The secondary name server keeps a backup copy of this data, if a backup file
name is included with this entry. This backup file is not required, but if there is one, the
secondary reads it upon restart rather than cause a network load by transferring the rdata
from the primary. It later checks with the primary name server to see if it has a more recent
copy. It also makes the secondary more robust. If the primary is down, when the secondary
starts up, it can load the data from its own backup files. It allows the secondary to still
function as a server for the domain.
Enter a secondary line entry for each of the in-addr.arpa domains, again including the IP
address of the primary name server.
The cache entry is the same as the one we discussed in the primary configuration.
Additional Information You can have up to 10 IP addresses in the third field, name
server IP address. The secondary tries each IP address until it makes a hit. If the IP
address is that of a secondary name server, it can get its information from another
secondary rather than a primary.
Transition Statement Since a copy of the database from the primary is downloaded to
the secondary, there is no reason to run the awk scripts, as no zone files have to be
created. However, the local file for loopback must be created.

V3.1.0.1
Instructor Guide
Uempty
Local IP Zone File
# pg /etc/named.local
@ IN SOA sys6.dc.ibm.com. root.sys6.dc.ibm.com. (

1.0 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
IN NS sys6.dc.ibm.com.
1 IN PTR localhost.
Figure 9-25. Local IP Zone File AU079.1
Notes:
Notice this looks the same as what was entered on the primary name server with the
exception of indicating itself in the SOA and NS records. The SOA is optional.
The file's content, structure, and purpose are the same as on the primary name server.
Instructor Guide
Instructor Notes:
Purpose Explain the purpose and contents of the secondary name server's local IP
zone file.
Details This file serves the same purpose and has the same syntax as the local IP zone
file for the primary name server with one exception. The NS record points to itself as the
name server, rather than pointing to the primary name server. It is used to locally resolve its
own loopback address.
Transition Statement As a reminder, let's look at the contents of the cache file, which
must also be created in the secondary name server.

V3.1.0.1
Instructor Guide
Uempty
Cache File
# pg /etc/named.ca
. 99999999 IN NS sys99.ibm.com.
sys99.ibm.com. 99999999 IN A 10.19.93.99
- OR -
. 99999999 IN NS a.root-servers.net.
a.root-servers.net. 99999999 IN A 198.41.0.4
. 99999999 IN NS b.root-servers.net.
b.root-servers.net. 99999999 IN A 128.9.0.107
. 99999999 IN NS c.root-servers.net.
c.root-servers.net. 99999999 IN A 192.33.4.12
; and so forth
Figure 9-26. Cache File AU079.1
Notes:
This file is exactly the same as the /etc/named.ca file created on the primary name server.
Instructor Guide
Instructor Notes:
Purpose Discuss the purpose and syntax of the cache file on the secondary name
server.
Details Once again, this file is just like the named.ca file configured on the primary
name server. If you refer back to the secondary's named.boot file, the cache statement
points to this file, which points to a higher-level authority name server should the query to
the secondary not be resolved. It can be the same as indicated in this example, or it could
point to a different name server in a higher-level domain.
Transition Statement Let's look at the final steps of configuring a secondary name
server.

V3.1.0.1
Instructor Guide
Uempty
Final Secondary Name Server Setup Steps
# smit hostname
# vi /etc/rc.tcpip
Uncomment line to start named
# startsrc -s named
The name and reverse lookup zone files are downloaded from the
Primary Server
Figure 9-27. Final Secondary Name Server Setup Steps AU079.1
Notes:
The final steps are the same as well, with one minor difference: the order of the DNS
servers in the /etc/resolv.conf file.
The DNS servers in the /etc/resolv.conf file are checked in the order as they appear in this
file, so it is a good idea to list the nearest name server (the local one) first.
Instructor Guide
Instructor Notes:
Purpose Discuss the final steps for configuring the secondary name server.
Details The secondary needs an /etc/resolv.conf file and the named daemon started.
They are the same steps as the primary name server.
Transition Statement Let's further discuss caching-only name server

V3.1.0.1
Instructor Guide
Uempty
Caching-Only Name Server
Do not have their own data
Only caching
Useful if you need more DNS servers but want to avoid the
overhead of downloading zone data to secondary servers.
# pg /etc/named.conf
directory /etc
zone "0.0.127.in -addr.arpa" {

};
zone "." {
};
Figure 9-28. Caching-Only Name Server AU079.1
Notes:
A caching-only nameserver does not have its own data, it only performs caching. This is
really useful if you need more DNS servers in your zone, for instance because you have a
large number of clients on a lot of networks with a slow connection to the backbone. You
could configure slave nameservers on each of those networks, but this requires you to do
regular zone transfers over those slow lines. A better approach might be to configure
caching-only nameservers on each network. This has the benefit of caching, but not the
disadvantage of the zone transfers.
Since a caching-only nameserver has no data of its own, the only two files required are the
file describing the local IP zone and the cache file.
Instructor Guide
Instructor Notes:
Purpose Explain the purpose of caching-only name n servers and how to configure
them.
Details Caching only name servers are not authoritative for any domains (except for
0.0.127.in-addr.arpa). The name does not imply that the primary and secondary name
servers do not cache, they do. This means that the only function this server performs is
looking up data and caching them. A caching-only server's real value comes after it builds
up its cache, by saving overhead of zone transfers.
Transition Statement Now let's look at setting up the client.

V3.1.0.1
Instructor Guide
Uempty
Setting Up the Client
domain dc.ibm.com
Figure 9-29. Setting Up the Client AU079.1
Notes:
On the client, the /etc/resolv.conf contains the default domain name for the system and
the name servers it uses for name resolution
The domain name is the domain in which this host resides.
The client can list anywhere from one to a maximum of three name servers in this file.
Once an active name server is found, the search through this list stops.
Although this is not addressed in this lecture, the /etc/hosts file on the clients should
contain at least an entry for themselves. The ifconfig command fails only if the localhost
name and IP address do not appear in /etc/hosts. It is a good idea to leave at least those
two entries in the /etc/hosts file on the client. By the time the startup sequence reaches the
route command, the network interface is up, and the host uses the name server to map to
IP address. Since a host has no default route until route is executed, the only name server
it can reach is local on the network. Better to hard code the IP address of the default route
into the startup file. This ensures that your host's networking starts correctly.
Instructor Guide
Instructor Notes:
Purpose Describe the configuration of a DNS client.
Details It is very simple to configure a DNS client. Simply create the /etc/resolv.conf
file. The client's file must point to the name servers (you can list up to three) and domain to
use for name resolution.
As a rule of thumb, you should configure DNS clients to use the closest name server
available. Closest is the one on the local network or subnet. At a minimum, there must be a
domain statement which identifies the default domain for the client. Next you must have at
least one name server entry which points to the IP address of a name server for the
domain.
In this example, two name servers are listed: the primary and the secondary. If the primary
name server, sys1, is down, the secondary doesn't have a way to know that sys1 is down.
The client has to do this checking. If the primary cannot be reached, the client goes to the
secondary name server. Up to three name servers can be listed. The list is searched
sequentially. Once a name server responds, the search stops, even if the query could not
be resolved.
Additional Information The name server must be listed using the IP address. A host
name does not work.
Domain directives overrides the host name. Since the resolver doesn't report errors, you
have to be sure the syntax is correct. Domain starts in column one, followed by white
space, then default domain name (no trailing dot). No trailing spaces are allowed after the
domain name. It causes your default domain to be set to a name plus spaces.
A third way to set the domain name is with the LOCALDOMAIN environment variable. You
can set it on a per user basis. If you have a huge system with people form all over the world
logged in, each user may do some of their work in a different company subdomain. Set the
variable in the profile file.
If there is only one name server configured, the resolver queries that name server with a
time-out of 5 seconds. The time-out is the length of time the resolver will wait for a
response from the name server before sending another query. If resolver encounters an
error that indicates the name server is down, unreachable, or times out, it doubles the
time-out and query the name server again. The errors that could cause that are:
Receipt of an ICMP port unreachable message which means no name server is
listening on the port
Receipt of ICMP host unreachable or network unreachable, which means that queries
cannot be sent to the destination IP.
If resolvers receive an error each time it sends a query, for a total of four errors, it falls back
to using its /etc/hosts table. These are errors not time-outs. It could take up to 75 seconds.
If it gets a time-out on a query, the resolver returns an answer and doesn't fall back to
/etc/hosts.

V3.1.0.1
Instructor Guide
Uempty With more than one name server configured, it is different. The resolver starts by querying
the first name server in the list with a time-out of 5 seconds, just like a single name server
scenario. If the resolver times out or receives an error, it falls back to the next name server
using the same time-out. If it queries all the name servers, it updates the time-out and
cycles through again.
An alternative to the domain directive is the search directive. This allows explicit
specification of the list of domains to append during lookups.
Transition Statement Now, lets see how we can convert to BIND9.
Instructor Guide
Conversion to BIND 9
BIND 9 is a complete new rewrite
Stop named daemon
Relink named and nsupdate
cd /usr/sbin
ln -fs /usr/sbin/named9 /usr/sbin/named
ln -fs /usr/sbin/nsupdate9 /usr/sbin/nsupdate
Changes maybe required to /etc/named.conf
Not all BIND 8 keywords are supported
Dynamic update security has changed
Figure 9-30. Conversion to BIND 9 AU079.1
Notes:
BIND 8 although offering more functionality and increased security than its BIND 4
counterpart, is still essentially developed using the same code base. BIND 9 is a complete
new rewrite.
Depending on how exactly the BIND 8 server was configured changes may be required
after an update to BIND 9 as some features have been included and removed.
Note: In the previous foil, BIND 8 /etc/named.conf. The example shown would require no
change under BIND 9.

V3.1.0.1
Instructor Guide

Purpose Explain how to convert a BIND 8installation to BIND 9.
Details
Transition Statement Now lets see how we can manage the named.
Instructor Guide
Controlling the named Daemon

To start the daemon:
startsrc -s named
To stop the daemon:
stopsrc -s named
To reread database after changes:
refresh -s named
To dump the active database:
kill -2 <pid_named>
Figure 9-31. Controlling the named Daemon AU079.1
Notes:
named can be stopped and started using SRC or SMIT.
An important function of named is it reads the database files and puts a copy in memory for
use. Should you have to add, delete, or revise an entry in the database, you must invoke
named to reread the database and refresh what is in memory. This is done using the
refresh -s named command.
Remember, once the database files have been created on the primary name server using
the awk scripts, the awk scripts are not used again. Revisions are made directly to the
database files. Also remember to change the serial number so the named daemon on the
secondary knows when to do a zone transfer.
named is also used to dump a copy of what is in memory to a file. This file can then be
used to ensure that the zone files are correct. You must know the PID of named. Use it with
the kill -2 command to dump a copy to the default file /var/tmp/named_dump.db.
kill -2 sends a SIGINT signal to named, causing named to take a snapshot of what is in
memory and dump to the default file.

V3.1.0.1
Instructor Guide

Purpose Discuss managing the named daemon.
Details Cover the student notes.
Additional Information The PID of named can be found by issuing the ps command or
from displaying the contents of the /etc/named.pid file. named writes its process ID in this
file during startup. One way to refresh named is with the command:
kill -l 'cat /etc/named.pid'
A similar command can be used to stop named. However, the use of the SRC or SMIT is
the preferred method.
Transition Statement Let's take a look at the contents of a dump file.
Instructor Guide
Active Database Dump Example

; Dumped at Mon Sep 27 09:39:51
; ---- Cache and data ----
$ORIGIN 0.0.127.in-addr.arpa.
1 IN PTR localhost.dc.ibm.com.
1 IN PTR sys1.dc.ibm.com.
4 IN PTR sys4e.dc.ibm.com.
$ORIGIN dc.ibm.com.
sys4e 9999999 IN A 10.19.99.4
sys1 9999999 IN A 10.19.98.1
sys2 9999999 IN A 10.19.98.2
sys3 9999999 IN A 10.19.98.3
sys4 9999999 IN A 10.19.98.4
sys5 9999999 IN A 10.19.98.5
$ORIGIN ibm.com.
sys99 604436 IN A 10.19.93.99
Figure 9-32. Active Database Dump Example AU079.1
Notes:
To take a snapshot of the name server's active database which is in memory, use
kill -2 <pid_named>. This dump is located in the file /var/tmp/named_dump.db.
$ORIGIN is the originating domain zone file.
The above example is a partial listing of the contents of the file.

V3.1.0.1
Instructor Guide

Purpose Discuss contents of the named_dump.db file.
Details The dump of the zone file configuration from memory can give you information
about the configuration of those files. Things to look for are correct or incorrect root server
names and missing or incorrect addresses for any of the name servers. $ORIGIN lists the
domain name.
Transition Statement The database information changes as your network grows or
shrinks. Let's take a look at how to add a host to the DNS zone files.
Instructor Guide
Adding a Static Host to the Domain

Update name zone file
Add host entry A record
Add any optional records that is, CNAME
Increase serial value in SOA record
Update IP zone file
Add IP address entry PTR record for each interface
Increase serial value in SOA record
Refresh named
Figure 9-33. Adding a Static Host to the Domain AU079.1
Notes:
To remove a host, update the above files by deleting the host instead of adding the host.
Remember to refresh named.

V3.1.0.1
Instructor Guide

Purpose Explain how to revise the zone files once they are created.
Details Update the zone files using an editor. Be careful to follow the exact syntax of a
similar entry. Most important, increment the serial number so the secondary name server
will invoke a transfer of an updated copy of the zone file.
Also, refresh named to get an updated copy in memory.
Transition Statement There is a nice tool that helps you query the name server
database to see what is stored.
Instructor Guide
nslookup
Queries domain name servers
Responds similarly to the host command
Two modes:
Interactive
Noninteractive
Troubleshooting tool
Figure 9-34. nslookup AU079.1
Notes:
nslookup only talks to one name server at a time.
nslookup only uses DNS. It does not use NIS or /etc/hosts.
The nslookup command can be used to troubleshoot name server problems.

V3.1.0.1
Instructor Guide

Purpose Define nslookup.
Details nslookup is a DNS program that can be used as a debugging tool or can be
used in place of the host command. nslookup directly queries a name server. It is helpful
in determining:
if a name server is running
if it is properly configured
query IP or name of a host
Queries can be noninteractive or interactive. We take a look at both. As stated in the
student notes, nslookup uses DNS only.
Transition Statement Let's take a look at a noninteractive query using nslookup.
Instructor Guide
Noninteractive Queries
$ nslookup sys3
Server: sys1.dc.ibm.com
Address: 10.19.98.1
Name: sys3.dc.ibm.com
Address: 10.19.98.3
$ nslookup -querytype=ANY dc.ibm.com

Address: 10.19.98.1
dc.ibm.com origin = sys1.dc.ibm.com
mail addr = root.sys1.dc.ibm.com
serial = 10001, refresh = 3600, retry = 300, expire = 3600000, min =
86400
dc.ibm.com nameserver = sys1.dc.ibm.com
sys1.dc.ibm.com inet address = 10.19.98.1
Figure 9-35. Noninteractive Queries AU079.1
Notes:
If you only want to look up one piece of data, use the noninteractive form of nslookup. It
returns the name server that was queried followed by the domain name and IP address of
the host you are querying.
The option -querytype=ANY returns all Start of Authority (SOA) information available for
your domain.
If you execute nslookup from the name server, the server address is displayed as 0.0.0.0,
meaning this host.

V3.1.0.1
Instructor Guide

Purpose Describe a noninteractive query.
Details You can invoke a noninteractive query by executing the nslookup command
followed by the name or IP address of a DNS host. This returns the name server queried
and the name and IP address of the query.
This example assumes the nslookup sys3 command was executed from a DNS client.
If you see a server address returned of 0.0.0.0, it means that you are executing nslookup
from the name server and the address of the local name server was not specified in
/etc/resolv.conf.
The second example uses the option -querytype=ANY dc.ibm.com, which return all SOA
information about the domain.
Transition Statement Let's now look at an interactive query using nslookup.
Instructor Guide
Interactive Queries
$ nslookup
Default Server: sys1.dc.ibm.com
Address: 10.19.98.1
> sys3
Address: 10.19.98.1
Address: 10.19.98.3
> ls dc.ibm.com >> filea
[ sys1.dc.ibm.com ]
Received 11 records
> ls -t any dc.ibm.com
[ sys1.dc.ibm.com ]
dc.ibm.com SOA sys1.dc.ibm.com root.sys1.dc.ibm.com. (10001
3600 300 3600000 86400)
dc.ibm.com. NS sys1.dc.ibm.com
sys1 A 10.19.98.1
sys2 A 10.19.98.2
.
.
>exit
Figure 9-36. Interactive Queries AU079.1
Notes:
An interactive session allows you to repeatedly query information without leaving the
nslookup program. The > is the interactive input symbol to continue.
ls lists the information available for the domain specified, optionally creating or appending
the output to the file specified (example, filea as shown above).
ls -t any is similar to the noninteractive -querytype=ANY option.
exit terminates the nslookup program.
nslookup has many options. Refer to the system documentation for further details.

V3.1.0.1
Instructor Guide

Purpose Describe an interactive query using nslookup.
Details To invoke an interactive query, simply execute nslookup without any
arguments. It returns the name and IP address of the name server being used and returns
the continuation prompt >. At the > prompt, type the host name you want to query. It returns
its name and IP address.
By default, nslookup queries for address records. The next query requests a zone file
transfer. It displays the contents of the zone file for the domain listed. Most zone files are
lengthy; therefore, append the output to a file and look at it later.
The next example shows the option -t any used with ls. -t is for type, and any requests
records for this domain.
exit is used to quit nslookup.
Transition Statement The nslookup program can be used in debug mode to get a
closer view of queries and responses.
Instructor Guide
Debugging with nslookup

$ nslookup
Default Server: sys1.dc.ibm.com
Address: 10.19.98.1
> set d2
> sys3
Address: 10.19.98.1
__________
SendRequest(), len 33
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, auth.records = 0, additional = 0
QUESTIONS:
sys3.dc.ibm.com, type = A, class = IN
__________
Got Answer (49 bytes)
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, auth.answer, want recursion, recursion avail.
questions = 1, answers = 1, auth.records = 0, additional = 0
QUESTIONS:
sys3.dc.ibm.com, type = A, class = IN
ANSWERS:
__> sys3.dc.ibm.com
type = A, class = IN, ttl = 4, dlen = 1073741824
internet address = 10.19.98.3
ttl = 9999999
___________
Address: 10.19.98.3
> set nodebug Copyright IBM Corporation 2006
Figure 9-37. Debugging with nslookup AU079.1
Notes:
set changes the information that affects the lookup.
By turning on debug, you are asking the nslookup program to show you the queries it
sends out and the responses it receives.
The text between the dashed lines is the query and response packets.
There are two levels of debug:
1. debug, which displays only the queries received
2. d2, which displays the queries sent out and the queries received
Turn debug off with the nod2 or the nodebug options. If you use nod2, the queries are still
in debug mode. Use nodebug to turn debug mode completely off.

V3.1.0.1
Instructor Guide
Uempty If you use nslookup regularly and use the same set of options most of the time, the
.nslookuprc file can be used to set your nslookup options. When nslookup starts, it looks,
by default, for this file in your home directory. The nslookup run command can contain any
valid set command, one per line. This file is useful if you want to change the nslookup
time-out or set your search lists to something other than your host's default search list.
Instructor Guide
Instructor Notes:
Purpose Discuss debugging with nslookup.
Details
Transition Statement nslookup - time is up. Lets see its replacement with BIND 9 - dig.

V3.1.0.1
Instructor Guide
Uempty
dig Queries
Domain Information Groper
BIND 9 Replacement for nslookup. DIG is non-interactive.
$ dig @sys1.dc.ibm.com dc.ibm.com ns

; <<>> DiG 9.1.3 <<>> @sys1.dc.ibm.com dc.ibm.com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59957
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:2
;; QUESTION SECTION:
;dc.ibm.com. IN NS
;; ANSWER SECTION:
dc.ibm.com. 86400 IN NS sys1.dc.ibm.com.
dc.ibm.com. 86400 IN NS sys6.dc.ibm.com.
;; ADDITIONAL SECTION:
sys1.dc.ibm.com. 86400 IN A 10.19.98.1
sys6.dc.ibm.com. 86400 IN A 10.19.99.6
;; Query time: 3 msec

;; SERVER: 10.19.98.1#53(sys1.dc.ibm.com)
;; WHEN: Mon Jun 10 13:48:21
;; MSG SIZE rcvf: 78
Figure 9-38. dig Queries AU079.1
Notes:
Dig, short for Domain Information Groper is a flexible tool for interrogating DNS name
servers. It performs DNS lookups and displays the answers that are returned from the
name server(s) that were queried.
A typical invocation of dig looks like:
dig @server name type
where:
server is the name or IP address of the name server to query. If no
server argument is given, dig consults /etc/resolv.conf and
queries the name servers listed there.
name is the name of the resource record to be looked up. If no name
is given, then dig will try a lookup of . (dot).
type indicates what type of query is required -- ANY, A, MX, SOA
and so forth. If no type argument is supplied, dig performs a
lookup for an A record.
Instructor Guide
Instructor Notes:
Purpose Discuss dig.
Details
Transition Statement Lets do the checkpoint questions and start the lab.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (1 of 3)
1. The TTL of the Standard Resource Records for the name server
zone files is specified in:
a. Minutes
b. Hours
c. Days
d. Seconds
2. There are many special characters to be used in the DNS zone

files. Which one of the following characters is used for continuing
lines?
a. ;
b. @
c. #
d. ()
3. The IP octets are given in reverse order for IP addresses in the

in-addr.arpa zone file because:
a. It must be traversed left to right, similar to the domain name with the highest level of
hierarchy indicated last.
b. It is the reverse translation of IP address to domain name.
c. The host portion of the IP address is evaluated first.
Notes:
Instructor Guide
Instructor Notes:
Purpose Present the first of three groups of checkpoint questions.
Details
a. Minutes
b. Hours
c. Days
d. Seconds

lines?
a. ;
b. @
c. #
d. ()

a. It must be traversed left to right, similar to the domain name with the highest level
of hierarchy indicated last.
Transition Statement Lets look at the next group of checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (2 of 3)
4. T/F: The named daemon must be running on every machine
participating in the domain environment.
5. When the system administrator wants to see the active name
server database, a file must be created which contains a dump of
the active database. This is done with the command kill -2
<pid_named>. The result of that dump file is located in:
a. /etc/tmp/named_dump.db
b. /var/tmp/named_dump.db
c. /tmp/named_dump.db
d. /var/lpp/tmp/named_dump.db
6. T/F: The zone files contain information regarding the nameserver's
zone of authority for both host to IP address name resolution and
IP address to host name resolution.
Notes:
Instructor Guide
Instructor Notes:
Purpose Present the second of three groups of checkpoint questions.
Details
participating in the domain environment. False. named only runs
on the name servers.
IP address to host name resolution. True.
Transition Statement Lets look at the last group of checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (3 of 3)
7. Match the following:
a. cache ____ Zone file defines the host to IP address name resolution.
b. name ____ Zone file defines the IP address to host name resolution.
c. local IP ____ Zone file defines the local IP address resolution.
d. IP ____ File defines where to send requests for resolution of names not
contained in nameserver database.
8. What is the name of the file that tells the system whether to run in
a flat network or a domain network?
9. T/F: On the client, the /etc/resolv.conf contains the default domain
name for the system and the name servers it uses for the name
resolution.
10. T/F: The named can be started automatically with a command
line entry in the inetd.conf file.
Notes:
Instructor Guide
Instructor Notes:
Purpose Present the third of three groups of checkpoint questions.
Details
Answers: b, d, c, a.
a flat network or a domain network? /etc/resolv.conf
resolution. True.
line entry in the inetd.conf file. False.
Transition Statement Lets move on to the exercise.

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Exercise 9
Notes:
Instructor Guide
Instructor Notes:
Details
Transition Statement Lets review some of the key points covered in this unit.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
The name server provides a distributed database that other systems
query to perform name resolution
The named daemon runs on the name servers
/etc/resolv.conf defines domain and name servers on clients
nslookup / dig queries name servers for information
Notes:
Instructor Guide
Instructor Notes:
Purpose Review some of the key points covered in this unit.
Details
Transition Statement Thats the end of this unit.

V3.1.0.1
Instructor Guide
Uempty Unit 10. Dynamic Host Configuration Protocol

This unit introduces the DHCP protocol. It describes the purpose and
operation of the DHCP protocol within the TCP/IP environment.
Configuration of DHCP server, client and relay agent on AIX, along
with Dynamic DNS update capabilities, are discussed.

Discuss DHCP functions and features
Configure DHCP network
Explain Dynamic DHCP / DNS update

Accountability:
Checkpoint Exercises
Machine Exercises
Copyright IBM Corp. 1997, 2006 Unit 10. Dynamic Host Configuration Protocol 10-1
Instructor Guide
Unit Objectives
Discuss the DHCP functions and features
Configure DHCP network
Explain Dynamic DHCP / DNS updates
Notes:

V3.1.0.1
Instructor Guide

Purpose Introduce the objectives to be covered in the Dynamic Host Configuration
Protocol lecture.
Details This unit covers DHCP and DDNS - how they are used by a server to provide IP
addresses and other configuration information to client systems. There is a lab to allow the
students to configure a DHCP client and server. The DHCP address given to the client
updates the DNS server.
Transition Statement Introduce Static and Dynamic host configurations.
Instructor Guide
Host Configuration
Static
smit mktcpip - configuration stored on disk
Requires one address for every machine
Typically used for servers
Dynamic
IP configuration assigned by server
Requires one IP address for every active machine
Does not require any local configuration
Typically used for clients
Figure 10-2. Host Configuration AU079.1
Notes:
Every host in an IP network needs to be configured with several parameters, including the
IP address, the subnetmask, the default router, the IP addresses of DNS servers, and so
forth. There are basically two ways of supplying these parameters to the host.
When a site uses static configuration, all parameters are configured on the local system
and stored on some sort of local medium. In most cases this is the local hard disk.
With static configuration, every host on a network needs its own IP address, even when the
system is off, or not connected to the network at all. Think for instance about the situation
where your company has a thousand mobile workers, each with its own laptop, who can
hook up to any network in any of your ten buildings throughout the country. Since you never
know when someone is logged in where, you need to reserve 10.000 IP addresses, one
thousand for each network, even if a network has only ten connections available. This is a
tremendous waste of IP addresses, not considering the user who will need to do some
local configuration every time he connects to another network.
When a site uses dynamic addressing, no configuration is stored locally. Instead, when the
system boots up, it requests the local configuration from a server. And when the system

V3.1.0.1
Instructor Guide
Uempty shuts down, it also notifies the server that the configuration is no longer needed and can be
reused. This limits the number of IP addresses that need to be reserved, since only the
systems that are actually in use on a network need an IP address for this network. And it
saves the user from doing a lot of local configuration.
Instructor Guide
Instructor Notes:
Purpose Discuss static and dynamic host configuration.
Details
Transition Statement Let's look at the protocols that are used for dynamic
configuration.

V3.1.0.1
Instructor Guide
Uempty
Dynamic Host Configuration
BOOTP Protocol
IP address statically linked to MAC address
May also provide information such as subnet mask, boot file,
name server, and so forth
Uses UDP - routable
DHCP Protocol
Downwards compatible with BOOTP
IP address dynamically assigned from pool
Many IP options available (address, subnet mask, DNS, routers,
...)
Adds the following features
Dynamic IP address allocation
Host-specific configuration parameters
DHCP server stored key-value entry or client
Figure 10-3. Dynamic Host Configuration AU079.1
Notes:
Bootp protocol has the following characteristics. DHCP supports the following types of IP
address allocation.
Dynamic allocation - host is assigned an address for a fixed time lease or until the host
relinquishes it.
Automatic allocation - host is assigned a permanent IP address.
Manual allocation - host is assigned an address by the network administrator.
The configuration parameter options allow DHCP servers to provide persistent storage of
network parameters for network clients. The server stores key-value entry for each client.
This key is a unique identifier of the client.
It is an application level protocol, which runs on top of UDP. This makes it easier to write
server and client applications and ensures that the packets are routable. You therefore
do not have to configure a bootp server on each and every network.
It uses a very flexible packet format which allows you to configure the client with a
variety of IP configuration items, and also has a large number of vendor extensions
Instructor Guide
defined, which allows vendors of certain hardware to configure that hardware with
special configuration options.
Bootp does not allow the inclusion of a lease time, so reusing IP addresses is not possible.
The most recent protocol to be used is the Dynamic Host Configuration Protocol
(DHCP). It is downwards compatible with Bootp, so Bootp clients can boot off a DHCP
server and vice versa. But it extends Bootp to include a lease time, which ensures that
after a certain amount of time the IP address is free to be assigned to another system.

V3.1.0.1
Instructor Guide

Purpose Discuss three generations of configuration protocols.
Details
Transition Statement Now, lets take a look at Bootp concepts.
Instructor Guide
BOOTP
1 Broadcast 2 Forward
bootrequest bootrequest
LAN LAN
4 Forward 3 bootreply
Diskless system bootreply
BOOTP BOOTP
relay server
Runs on UDP
Server provides client IP address, boot name file
May also provide vendor-specific information such as subnet mask,
name servers
Supports cross-gateway booting with relay agents
Figure 10-4. BOOTP AU079.1
Notes:
The BOOTstrap Protocol (BOOTP), defined in RFC 951, is an IP/UDP bootstrap protocol
which allows a client to obtain its own IP address, the name of a boot file and
vendor-specific information from a BOOTP server. This information is manually
pre-configured by the administrator in the server database.
BOOTP transmits the configuration information via UDP (User Datagram Protocol)
datagrams encapsulated in IP datagrams. This allows the client to contact a server across
a gateway, on another network. The BOOTP server listens on the well-known port 67 for
BOOTREQUESTS and responds with BOOTREPLIES sent to port 68 on the client.
BOOTP solves the problem of how to use IP before the diskless system knows its own IP
address or the address of the server by having the client broadcast its request on the local
network. The server may reply to the client by broadcasting or by unicasting. In the case of
unicasting, the server must prime its own ARP cache since the client is not able to respond
to an ARP query until it has its IP address.
BOOTP request and replies contain a vendor-specific area. As well as allowing hardware
vendors to transmit machine-specific information, this area can be used by the server to

V3.1.0.1
Instructor Guide
Uempty provide the client with its subnet mask, hostname, domain name, default IP routers, name
servers and other information.
Some physical networks cannot provide a BOOTP server. For instance, in a network
comprised completely of diskless hosts and routers, none may be able to run a BOOTP
server. On some networks it is possible but not desirable to run such a server. For instance,
a network administrator may wish to avoid maintaining a server on each of many small
networks. In this situation a centralized BOOTP server is preferable. Finally, a network
which has its own BOOTP server may still need a backup server on another network to
ensure reliability.
All these situations can be managed using BOOTPs cross-gateway booting function. To
implement this optional feature of BOOTP, a router or host is configured with a list of
networks or servers to which it will forward BOOTP requests. Such a router is then known
as a BOOTP relay agent.
The relay agent listens on well-known port 67 (just like a BOOTP server), and when it picks
up a BOOTREQUEST, it fills in the gateway IP address field with its own IP address,
increments the hopcount field, and forwards the request. Normally, it forwards the request
directly to a particular BOOTP server. It is also possible that it forwards it to another relay or
even that it rebroadcasts the request.
Instructor Guide
Instructor Notes:
Purpose
Details
Relay
Client Agent Server
Begins
initialization
BOOTREQUEST;
broadcast on Forwards request to
255.255.255.255 BOOTP server
BOOTREQUEST;
determines
configuration
BOOTREPLY
Broadcast/unicast
BOOTREPLY to
client
BOOTREPLY
Initialization
complete
Transition Statement Thats all for bootp; now lets take a look at Leasing an IP
Address.

V3.1.0.1
Instructor Guide
Uempty
Leasing an IP Address
In DHCP negotiation, the client agrees on a lease time with the
server
Before the lease time is over, the client has to:
Abandon the lease
Renew the lease
All lease times are expressed as offset from now in seconds
Prevents against problems when clocks are out of sync
Figure 10-5. Leasing an IP Address AU079.1
Notes:
When the client boots up, it starts a brief negotiation with the server. As part of this
negotiation, a lease time is agreed. This is the period of time in which the client may use
the IP address and other configuration items that were assigned.
Before the agreed lease time is over, the client needs to do one of two things:
It may abandon the lease, essentially telling the server that it no longer needs the IP
address, and that the server can reuse it immediately.
It may renew the lease. This requires a new, even shorter negotiation phase with the
server to extend the lease time. In all but a few cases, the server will renew a lease
without a problem.
In all DHCP packets, the lease time and related timings are always expressed in seconds,
as an offset from the current time. This prevents against problems when clocks on different
systems are not synchronized. It is, however, a good idea to synchronize the clocks.
Instructor Guide
Instructor Notes:
Purpose Discuss lease times.
Details The lease time is specified in the /etc/dhcpcd.chf file.1
Transition Statement Let's see how a client obtains a lease.
1
ISPs who offer cable modem or ADSL service sometimes force clients to abandon the lease and acquire a new lease for another IP
address. This prevents people from having a permanent, static IP addresses and thus from building servers

V3.1.0.1
Instructor Guide
Uempty
DHCP Client-Server Interactions
DHCP Relay DHCP Server

1. DHCPDISCOVER
2. DHCPOFFERs
3. DHCPREQUEST
4. DHCPACK
DHCP Client
DHCP Server
Figure 10-6. DHCP Client-Server Interactions AU079.1
Notes:
The visual shows the exchange of packets that enable a client to obtain a lease on an IP
address.
1. The client broadcasts a DHCPDISCOVER message on its local subnet. This message
is received by all DHCP servers and DHCP relays on the network.
A DHCP relay relays the message as a unicast message to one or more DHCP servers.
DHCP relay code is typically included in a routers, saving you from having to put a
DHCP server or other special system on each network.
2. All servers check their local configuration to see if they have any IP addresses for that
network that may be used by this client. Each server that wants to offer a lease does
this by sending a DHCPOFFER containing the IP address, other configuration
parameters and the maximum lease time for this IP address.
3. The client receives all offers and selects one (typically, but not necessarily, the one with
the longest maximum lease time), and sends a DHCPREQUEST to that server to
confirm the lease.
Instructor Guide
4. The server receives the DHCPREQUEST, stores the client's configuration details and
sends a DHCPACK message to the client.
Servers don't commit the IP address for the client until they receive the DHCPREQUEST
packet. It may therefore happen that a server sends multiple DHCPOFFERs to multiple
clients with the same IP address. The first client that actually claims the IP address (with a
DHCPREQUEST) is confirmed with the DHCPACK, and other clients are reneged with a
DHCPNACK message. The client may therefore only use an IP address after it has
received the DHCPACK
The following steps are not shown in the figure but are part of the DHCP client initialization
process.
1. If the client is satisfied with the parameters, it proceeds to the next stage of initialization.
If not, it may send a DHCPDECLINE and begin the process again.
2. If the client wants to renew its lease prior to expiration, it must contact the server with a
DHCPREQUEST at a preset time the default is halfway through the lease period.
3. If the server responds with a DHCPACK renewing the lease, the client can continue
operation. If the server fails to respond, the client broadcasts the request, hoping to
contact the server if it has been moved to a different subnet. If this strategy fails, the
client must start the initialization process again from the beginning.
If the client wants to relinquish its lease for a graceful shutdown, it may optionally send the
server a DHCPRELEASE message.

V3.1.0.1
Instructor Guide

Purpose To take the students through a typical sequence of DHCP client-server
interactions.
Details The student notes contain a basic overview of the protocol exchange between
client and server. In order to answer questions that may arise, a more detailed version is
given here.
DHCP Client Server Interaction

1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. The
message may include options suggesting values for network address and lease
duration. A client may for instance include the IP address it had obtained earlier, in
order to try to obtain the same IP address again.
2. Servers may respond with a DHCPOFFER message that includes an available network
address and other configuration parameters. Servers need not reserve the offered
address pending client response, though the protocol works more effectively if they do.
The server may unicast the message if possible, or may broadcast on the client's
subnet using 255.255.255.255,
If the client receives no DHCPOFFER messages, it times out and retransmits the
DHCPDISCOVER message. The client may choose to wait for multiple responses
before moving to the next step.
3. Once the client receives one or more DHCPOFFER messages, it selects one server,
based on the configuration parameters offered. For instance, it may choose the offer
with the longest lease, or the one that gives the most information needed for optimal
functioning of this particular client.
4. The client broadcasts or unicasts a DHCPREQUEST message. The message must
include the server identifier option to indicate which server has been chosen
(particularly important when a broadcast is done), and may also include other options
specifying desired configuration values.
5. The servers receive the DHCPREQUEST messages, and those not chosen use the
message as notification that their offer has been declined. The chosen server commits
the binding for the client to persistent storage, and responds with a DHCPACK
message containing the configuration parameters.
If the chosen server is unable to satisfy the DHCPREQUEST message (for example, it
has allocated the address elsewhere in the interim since the DHCPOFFER message
was sent) the specification states the server should respond with a DHCPNAK
message.
6. The client receives the DHCPACK message containing its configuration parameters. It
is recommended that it make an ARP check to ensure the address is not in use
elsewhere prior to accepting the offer. If there is a problem with the assigned
parameters, the client sends a DHCPDECLINE message and restarts the configuration
Instructor Guide
process. Likewise, if a DHCPNAK message is received, the client restarts. If neither a

DHCPACK nor DHCPNAK message is received, the client times out and retransmits
DHCPREQUEST.
7. If the client detects no problem with the parameters in the DHCPACK message, it notes
the duration of the address lease and proceeds to the next phase of its bootup.
This basic transaction format is curtailed under some circumstances. For instance, if a
client remembers a previously allocated address, which has not yet expired, and wishes
to reuse it, the client begins with a DHCPREQUEST rather than a DHCPDISCOVER
message.
Transition Statement Let's look at the procedure to renew a lease.

V3.1.0.1
Instructor Guide
Uempty
DHCP Renewal
TI (0.5* Client Server
duration of Renewing State
lease)
DHCPREQUEST [commits
(unicast) configuration]
DHCPACK or
[ignores
request]
T2
(0.875* [Rebinding State]
duration of [commits
lease) DHCPREQUEST
configuration]
(broadcast)
or
Lease [ignores
[Init State]
Expires request]
DHCPDISCOVER
Graceful shutdown
Discards lease
DHCPRELEASE
Figure 10-7. DHCP Renewal AU079.1
Notes:
This diagram illustrates the renewal of a lease.
1. After half the lease period (usually called T1) the client contacts the server with a
unicast DHCPREQUEST, requesting a renewal of the lease. If the server is still
available and willing, it sends a DHCPACK back to the client, confirming the renewal of
the lease. The timers will now be reset and the lease period countdown starts again.
2. If the server does not react to the unicast DHCPREQUEST, the client waits until T2,
which is about 0.875th of the lease period. It then does a broadcast DHCPREQUEST.
This broadcast still contains the ID of the DHCP server, but this broadcast might be
picked up by a DHCP relay agent, so that it reaches the server even if the server has
been placed on another subnet.
If the client still has no confirmation from the server by the time the lease expires, it starts a
DHCPDISCOVER sequence again to get another IP address from another server. Plus,
since the lease has expired, it sends a DHCPRELEASE to the previous server. But this
DHCPRELEASE probably gets lost since the server has not been responding anyway.
Instructor Guide
Instructor Notes:
Purpose Show the students the renewal procedure.
1. The client must contact the server prior to lease expiration if it wishes to renew its
address lease. The protocol specifies two significant time periods for lease renewal, T1,
for which the default is halfway through the lease period, and T2, for which the default is
0.875 times the lease period. Implementations can define these timings differently.
At T1 a client that wishes to renew its lease unicasts a DHCPREQUEST to the server
which issued its lease. If the server responds with a DHCPACK renewing the lease, the
client is rebound and continues operations.
2. If the server fails to respond before T2, the client send another DHCPREQUEST
message, but this time to the broadcast address. This enables the server to process its
existing leases if it has been moved to another network. Again, if an ACK message is
received, the client is rebound and continues operations.
3. If the client fails to get a response from a server before the lease expiry, the client must
enter initialization state and start the process from the beginning with a
DHCPDISCOVER, as described in the previous chart.
4. If the client wishes to relinquish its address for a graceful shutdown, it may send a
DHCPRELEASE message. This is an optional part of the protocol. If the server receives
no message from the client before lease expiration, it assumes the client no longer
needs the address and may then reassign it.
Transition Statement Now that we've looked at the DHCP protocol exchange, let's see
the types of information we can provide to the clients.

V3.1.0.1
Instructor Guide
Uempty
Selected DHCP Options
Subnet mask (1)
Time offset (2)
Router (3)
Time server (4)
Domain name server (6)
LPR server (9)
Hostname (12)
Domain name (15)
IP forwarding enable/disable (19)
Interface MTU (26)
Static routes (33)
Figure 10-8. Selected DHCP Options AU079.1
Notes:
This chart lists some of the more interesting options defined in RFC 1533, 2132 that a
DHCP server can send to a client. The last option, static routes, allows the server to
provide a list of static routes that the client installs into its IP forwarding table. For a
complete listing of available options within AIX, refer to /etc/options.file.
Instructor Guide
Instructor Notes:
Purpose To give the students an understanding of the kinds of information a DHCP
server can provide to a client.
Details Discuss the DHCP options available. The visual shows a partial listing. Cover
domain name server, domain name, hostname, and default router definitions as these will
be used for the implementation example.
Additional Information For a more complete list of the DHCP options, see
/etc/options.file.
Transition Statement Now that we've covered the DHCP protocol, let's look at an
example.

V3.1.0.1
Instructor Guide
Uempty
DHCP AIX Implementation Example
DHCP
Clients Router
10.1.1.1
10.1.1.0
10.1.2.0 10.1.2.1
10.1.2.2 10.1.1.2
10.1.3.1
AIX
10.1.3.0 AIX Router DHCP
Server
Server provides IP address, subnet mask, default router,

nameserver address, domain name
Figure 10-9. DHCP AIX Implementation Example AU079.1
Notes:
Now let's look at Example Company's network, where the administrator plans to implement
DHCP on AIX systems. This network is made up of three LANs connected by two routers,
one of which is an AIX system. Each LAN has a number of AIX hosts. Example Company's
network administrator wants the hosts on each LAN to be configured with IP address,
subnet mask, default router, the address of a name server, and the domain name for the
network.
The administrator has decided to run a DHCP server on LAN 10.1.1.0 and use a BOOTP
relay to forward requests from clients on the other two LANs. A BOOTP relay agent placed
on the AIX system routing between LANs 10.1.2.0 and 10.1.3.0 pick up packets originating
in those networks and forward them to the server located on LAN 10.1.1.0.
The administrator has decided to choose DHCP's automatic allocation facility, as opposed
to manual or dynamic allocation. He has enough IP addresses to go around, and hosts will
not be entering and leaving the network frequently, so there is no need for dynamic
allocation and short lease times. None of the clients in this network are well-known hosts
(such as print servers), so the administrator doesn't need to reserve specific addresses for
Instructor Guide
any of them. Therefore, it doesn't matter what IP address they have, and neither manual
allocation nor host specification is necessary.

V3.1.0.1
Instructor Guide

Purpose To introduce a DHCP implementation example.
Details Introduce the Example Company's network as a basis for configuring DHCP.
The configuration file will contain definitions for IP address, subnet mask, default router,
name server, and domain names. These parameters are given out by the DHCP server -
10.1.1.2. Network 10.1.2.0 and 10.1.3.0 clients need relay agents to forward DHCP
messages to the server.
Transition Statement First let's look at the /etc/dhcpsd.cnf file.
Instructor Guide
Configure a DHCP Server on AIX

# cat /etc/dhcpsd.cnf
logItem SYSERR
logItem OBJERR
logItem PROTERR
logItem WARNING
numLogFiles 6
logFileSize 100
logFileName /usr/tmp/dhcpserver.log
leaseTimeDefault 1 year
leaseExpireInterval 1 day
Figure 10-10. Configure a DHCP Server on AIX AU079.1
Notes:
The administrator has decided to run a DHCP server on LAN 10.1.1.0 and use a BOOTP
relay to forward requests from clients on the other two LANs. A BOOTP relay agent placed
on the AIX system routing between LANs 10.1.2.0 and 10.1.3.0 will pick up packets
originating in those networks and forward them to the server located on LAN 10.1.1.0.
We will look at each of these steps
The AIX DHCP configuration file defines configuration information for the DHCP server
program, dhcpsd. The configuration file used for the Example Company network is shown
above and in the next chart. DHCP on AIX also supports a dhcpsconf command which
brings up an X-windows graphical user interface, which allows the network administrator to
read, save, and modify files, and also allows him to start, stop and retrieve statistics from a
running server.
Once the configuration file is in place, the server daemon is started by the following
command: startsrc -s dhcpsd. The -f flag on dhcpsd specifies the configuration file to be
used; default is the /etc/dhcpsd.cnf file.

V3.1.0.1
Instructor Guide
Uempty The server maintains a database of which addresses it has distributed to which hosts;
these are kept in the files /etc/dhcps.ar and /etc/dhcps.cr.
The DHCP server daemon uses the same port that is used by the BOOTP server daemon,
so both cannot be run simultaneously.
The effect of the configuration file is:
Addresses are assigned to clients with the very long lease period of one year. The
server checks leases every day. In our example network, we have plenty of addresses
so we're not worried about their reuse.
All clients are given 10.1.1.3 as their name server, and example-company.com as
their domain name.
All clients are given 255.255.255.0 as their subnet mask.
All clients in subnet 10.1.1.0 are given an address in the range 10.1.1.10 to 10.1.1.254.
(We're reserving the lowest addresses in the subnet for permanent addresses not to be
administered by DHCP.)
Instructor Guide
Instructor Notes:
Purpose Identify dhcp options with /etc/dhcpsd.cnf file.
Details This file contains directives. Cover each directive within the configuration file.
Point out the importance of log files when having problems.
Configuration File Entries:
Many configuration file elements such as network or class can use one or more of the
DHCP options defined in RFC 1534. However, global options affecting the entire file can
also be specified. Non-global options must always be contained within a pair of curly
braces following a network subnet, class or client statement.
numLogFiles, logFileSize, logFileName, logItem: These four statements define the
number, maximum size, name and options for log files. Log file options include SYSERR
(system error); OBJERR (object error, between objects in the daemon); EVENT (event
occurred in the process); TRACE (code flow for debugging).
leaseTimeDefault: Specifies the default lease duration for leases issued by this server.
The amount of time is specified as a decimal number, with units ranging from years to
seconds. Default duration is one hour. Takes effect in the absence of more specific
information defined in the network, subnet, class or client fields.
leaseExpireInterval: Specifies the time interval at which the lease expiration condition is
examined; default is one minute.
Transition Statement /etc/dhcpsd.cnf continues.

V3.1.0.1
Instructor Guide
Uempty
/etc/dhcpsd.cnf
network 10.0.0.0 24
{
option 1 255.255.255.0 # Subnet mask
option 6 10.1.1.3 # Name server
option 15 example-company.com. # Domain
subnet 10.1.1.0 10.1.1.10-10.1.1.254
{
option 3 10.1.1.1 # Default router
}
subnet 10.1.2.0 10.1.2.10-10.1.2.254
{
}
subnet 10.1.3.0 10.1.3.10-10.1.3.254
{
}
}
Figure 10-11. /etc/dhcpsd.cnf AU079.1
Notes:
This chart continues the discussion of AIX DHCP configuration files begun in the preceding
chart.
network: Specifies the dotted decimal notation address for a network administered by this
server. Optionally, the address can be followed by the subnet mask, or a range of
addresses administered by this server. Options particular to the network can also be
specified within curly braces following the network statement. (Note that the subnet mask
may either be specified in the traditional notation, for example, 255.255.255.0, or as the
number of bits in the mask, for example, 24. The latter method is used in the example.)
subnet: Specifies a subnet administered by this server, optionally followed by a range of
addresses in this subnet which are to be administered. As with the network statement,
options for the subnet may be specified within curly braces following the subnet statement.
class: Specifies the ASCII string name of a class. A class can be used to designate
particular types of systems, for example a print server or a Windows client. When the
DHCP client sends requests to the server, it may include its class name in order to cause
the server to provide particular types of options. The class may be further defined by a
Instructor Guide
range of addresses that are given to clients which request the class. Options particular to
the class can also be specified following the statement in curly braces.
client: Specifies elements particular to a client. Elements which can be defined include id
type (one of the RFC 1340 hardware types, or 0 for a string); id value (hardware address
for the RFC 1340 hardware ID types or a character string for id type 0); and address.
Options particular to this client can also be specified, as with network, subnet and class. If
manual allocation is used for a client, a specific address is entered for the client in this field.
In our example, our administrator does not provide specific client address information, so
the server allocates an address from its pool of available addresses.
The client statement can be used to configure BOOTP clients, by including three
BOOTP-specific options: code sa (server address for BOOTP client); code bf (bootfile for
the BOOTP client; and code hd (home directory containing clients bootfile). In addition, an
infinite lease time must be specified (with option 51 set to 0xffffffff).
supportBOOTP: Specifies whether server should support BOOTP clients.
supportunlistedClients: Specifies whether the server should support requests from
clients which are not configured with their own individual client statements. Absence of this
statement defaults to support of unlisted clients.
updateDNS: String-defining command to use to update the DNS PTR IP address to
name-mapping for IP addresses assigned by this server.
removeDNS: String-defining command to use to remove the DNS PTR IP address to
name-mapping for IP addresses assigned by this server. Called when DHCP release is
received.

V3.1.0.1
Instructor Guide

Purpose To explain how to configure a DHCP server and start the dhcpsd daemon.
Details This file contains directives that can be specified by server administrator to
configure the server and enforce policies. Cover each directive on the visual.
Additional Information The student notes reference DNS update and DNS remove
directives. Depending on your audience, you may introduce/discuss Dynamic DNS support
within DHCP.
Transition Statement Now let's look at the /etc/dhcpcd.ini file to configure client.
Instructor Guide
Configuring a DHCP Client

# cat /etc/dhcpcd.ini
numLogFiles 4
logFileSize 100
logFileName /usr/tmp/dhcpcd.log
logItem SYSERR
interface en0
Figure 10-12. Configuring a DHCP Client AU079.1
Notes:
The dhcpcd configuration file contains entries for logging information, requested options,
interfaces to configure, and other options as described in notes within the file. The
configuration file used by clients in Example Company's network is shown above.
The dhcpcd daemon is normally started by the /etc/rc.tcpip file that runs at boot time; this
is commented out by default. There are SMIT options to enable the DHCP client.
The client can be started by the following command: startsrc -s dhcpcd. This command
takes three possible flags. The -f flag specifies the configuration file to be used; default is
/etc/dhcpcd.ini. The -t flag specifies the number of seconds the daemon waits before
placing itself in the background, allowing a machine to continue booting if a DHCP server
cannot be found. The -i flag tells the daemon to run in Inform mode, allowing a client to
retrieve configuration information from a server without getting an address.

V3.1.0.1
Instructor Guide

Purpose To explain how to configure and start the dhcpcd daemon on AIX.
Details This file contains directives that can be specified by client administrator to
configure the client cover options in file. Also, you can edit file directly or use SMIT. Use
DHCP for TCP/IP configuration and startup screen.
Note: Entries used in the Example Company configuration file are in italics.
numLogFiles, logFileSize, logFileName, and logItem are as described in the server
configuration chart.
interface: Specifies the interface on which to configure DHCP. Multiple entries are allowed.
The entry any tells the DHCP client to configure the first interface it finds and completes
successfully. Options can be specified for each interface by using the option statement in
curly braces following the interface statement.
clientid: Specifies the client ID to use in all communication with the server. The default is
MAC (client MAC address), but if HOSTNAME is specified, the client's host name is used.
sniffer: Specifies a string in quotes, indicating a program to execute to detect hardware
failure/recovery for an interface.
option: Specifies one or more options to be requested by this client. If outside curly braces,
the options apply to all interfaces.
vendor: Specifies special syntax for vendor extensions, if any.
reject: Takes one or more codes for options, specifies that if these are returned by a server
they should be rejected.
otherOptions: Specifies how all options not specifically requested or rejected should be
handled; default is to accept them.
updateDNS: A command string to execute to cause the DNS server to be updated with the
new IP address for a given name.
Transition Statement Finally, let's look at how to configure a BOOTP/DHCP relay
agent on AIX.
Instructor Guide
Configuring a DHCP/BOOTP Relay Agent

# cat /etc/dhcprd.cnf
numLogFiles 6
logFileSize 100
logFileName /usr/tmp/dhcpserver.log
logItem SYSERR
server 10.1.1.2
Figure 10-13. Configuring a DHCP/BOOTP Relay Agent AU079.1
Notes:
The dhcprd configuration file contains logging and server address entries for the relay
agent daemon. The dhcprd configuration file used for Example Company's BOOTP relay
agent is shown above.
The relay daemon can be started by the command: startsrc -s dhcprd.
numLogFiles, logFileSize, logFileName, and logItem: these four statements define
number, maximum size, name and options for log files.
server: specifies the IP address of a server to which the relay agent should forward
BOOTP or DHCP datagrams. Multiple servers may be specified; all receive each
datagram.

V3.1.0.1
Instructor Guide

Purpose To explain how to implement a DHCP/BOOTP relay agent on an AIX system.
Details This file contains directives that can be specified by administrator to configure
relay agents. Explain that in our example, the two routers need to be defined as relay
agents to forward DHCP traffic to the DHCP server at 10.1.1.2.
Transition Statement Lets now tie up DHCP and DNS.
Instructor Guide
Dynamic DNS Update

Every dynamic IP address needs a DNS entry
Name and reverse lookups!
Solution Dynamic DNS
Allows add, modify and delete updates to resource records
Issues!! Securing the updates.......
DHCP Server owns the IP address - and therefore updates the DNS
PTR record in the reverse zone file
Client owns the hostname - and updates the DNS A record in the
name zone file
Dynamic DNS is supported in BIND 4 / 8 and 9.
By default all zones are static
Figure 10-14. Dynamic DNS Update AU079.1
Notes:
Networking and the explosive growth of the internet has led to IP address assignment to
become much more dynamic. Most client hosts get their addresses and network specific
information via DHCP. In order for a client to communicate with a server via telnet the client
host initiating the connection must be able to resolve the servers name into an IP address.
If both hosts use DNS for name resolution and the server was given an IP address via
DHCP the telnet operation would not be possible. The solution is to introduce DDNS as
introduced in RFC 2136.
In the DDNS process the DHCP server owns the IP address which it allocates to the DHCP
client and therefore is responsible for updating the DNS PTR reverse zone record.
Typically in most situations, the DHCP client owns its hostname and is responsible for
updating the DNS A zone record. However, the DHCP server or client can also update
BOTH A and PTR records. This is known as DDNS proxy behavior.

V3.1.0.1
Instructor Guide

Purpose Introduce DDNS
Details
Transition Statement Lets take at look at DDNS update scripts.
Instructor Guide
DDNS Update Scripts

/usr/sbin/nsupdate - command that allows dynamic updates
Must be symbolically linked to one of the following scripts
/usr/sbin/nsupdate8 is used to implement RFC 2136 update method
(BIND 8 / BIND 9)
Update controlled by access control lists
/usr/sbin/nsupdate9 is used to implement TSIG / SIG update
method (BIND 9)
Transaction Signatures
DNSSEC Signatures (SIG)
Figure 10-15. DDNS Update Scripts AU079.1
Notes:
nsupdate8 implements RFC 2136 dynamic update mechanism. RFC 2136 updates are
controlled by access control lists.
nsupdate9 implements TSIG and DNSSEC SIG updates which are only applicable with
BIND 9 on AIX.

V3.1.0.1
Instructor Guide
Uempty TSIG uses shared key encryption for server to server communication. This includes
zone transfer, notify, recursive queries and dynamic update.
DNSSEC SIG uses public / private key cryptography as specified in RFC 2535 to
authenticate messages. SIG records allow administrators to sign their zone data,
thereby stating that it is authentic.
Instructor Guide
Instructor Notes:
Purpose Introduce nsupdate as the DDNS mechanism.
Details Briefly describe the nsupdate offerings in AIX for DDNS update
Additional Information Delving into the specific update mechanisms and security
implications is far beyond the realm of this course.
Transition Statement Lets have a look at an example.

V3.1.0.1
Instructor Guide
Uempty
DDNS Example
# head /etc/named.conf
options {
directory "/etc";
notify yes; // Inform Slave servers upon zone changes
allow_transfer { // only allow zone transfer to slave server 10.19.99.6
10.19.99.6;
};
};
acl can_query { 10.19.98/24; }; // allow only 10.19.98/24 network to nslookup
acl can_update { 10.19.98.0/24; 10.19.99.0/24; }; // allow the dhcp server and clients to update us
zone "dc.ibm.com" {
type master;
file "named.dc.ibm.com";
allow-update { can_update; };
allow-query { can_query; };
};
# tail /etc/dhcpsd.cnf
updateDNS "/usr/sbin/dhcpaction8 '%s' '%s' '%s' '%s' PTR NONIM >>/tmp/updns.out 2>&1 "
removeDNS "/usr/sbin/dhcpremove8 '%s' PTR NONIM >>/tmp/rmdns.out 2>&1 "
# tail /etc/dhcpcd.ini
interface en0
{
option 12 "sys50"
}
updateDNS "/usr/sbin/dhcpaction8 '%s' '%s' '%s' '%s' A NONIM >> /tmp/updns.out 2>&1 "
Figure 10-16. DDNS Example AU079.1
Notes:
The above example shows a snapshot of a DNS server, DHCP server and DHCP client
configuration files which has been modified to implement DDNS using update mechanism
RFC 2136 with BIND 8.
DNS Server Control file /etc/named.conf
The global option statement specifies:
notify yes statement. This indicates that the secondary slave DNS servers are
automatically notified of any DNS zone changes immediately.
allow_transfer statement specifies that zone transfers are only allowed with machine
10.19.99.6.
Two Access Control Lists are defined:
can_query: defines a list of hosts (All hosts on 10.19.98.0/24 Network) which can query
the DNS server.
can_update: defines a hosts (All hosts on 10.19.98.0/24 and 10.19.99.0/24 Networks)
which can update the name zone for domain dc.ibm.com
Instructor Guide
DHCP Server configuration file /etc/dhcpsd.cnf

updateDNS script which is executed when the server send a DHCPACK to update the
reverse PTR record
removeDNS script which is executed when a client sends a DHCP release
DHCP Client configuration file /etc/dhcpcd.ini
interface statement indicates the hostname to be assigned to interface en0 is sys50.
This allows the DHCP client to indicate to the DNS server its hostname.
updateDNS script which is executed when the server send a DHCPACK to update A
record.

V3.1.0.1
Instructor Guide

Purpose To introduce a DDNS example.
Details Go through the relevant files indicated on the foil and point out there relevance
to DDNS.
Transition Statement dhcpaction and dhcpremove are wrapper scripts for the
nsupdate utility - lets have a closer look.
Instructor Guide
DDNS Wrapper Scripts

dhcpaction / dhcpremove are wrapper scripts for the nsupdate utility
BIND 8 / 9 - RFC 2136
Wrapper /usr/sbin/dhcpaction8 /usr/sbin/dhcpremove8
Update /usr/sbin/nsupdate8
BIND 9 - TSIG / SIG
Wrapper /usr/sbin/dhcpaction9 /usr/sbin/dhcpremove9
Update /usr/sbin/nsupdate9
Figure 10-17. DDNS Wrapper Scripts AU079.1
Notes:
The nsupdate utility is not called directly but via wrapper scripts as shown in the previous
example. The wrapper scripts must supply four attributes (%s) to the nsupdate executable:
The first %s specifies the hostname
The second %s specifies the domain name
The third %s specifies the IP address
The forth %s specifies the lease time
The two remaining parameters indicate the policy record to update (A / PTR / BOTH /
NONE) and whether NIM should be updated.
Details on NIM and DHCP interaction can be found in the AIX TCP/IP communication
guide.

V3.1.0.1
Instructor Guide

Purpose Introduce DDNS wrapper scripts
Details
Transition Statement Now, let's look at some checkpoint questions before the
summary and lab exercise.
Instructor Guide
Checkpoint
1. T/F: In AIX, all Hosts should get their IP address via DHCP.
2. A ____________ forwards DHCP/BOOTP packets to another
network.
3. DHCP supports persistent storage of network parameters for
clients. This information is sent to the client in the
______________________ field of the DHCP packet.
4. T/F: A DHCP server can only allocate dynamic addresses to a
client.
5. Put the following DHCP messages in the correct order:
a. DHCPACK
b. DHCPREQUEST
c. DHCPRELEASE
d. DHCPDISCOVER
e. DHCPOFFER
6. T/F: In AIX, DDNS update is only supported when using BIND 9.
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
1. T/F: In AIX, all Hosts should get their IP address via DHCP. False.
network. DHCP/BOOTP relay agent
______________________ field of the DHCP packet. options.
client. False.
a. DHCPACK
b. DHCPREQUEST
c. DHCPRELEASE
d. DHCPDISCOVER
e. DHCPOFFER
Answer: d, e, b, a, c

False.
Instructor Guide
Exercise:
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
Instructor Guide
Unit Summary
DHCP protocol
Designed for dynamic environment, based on and compatible with
BOOTP
Adds dynamic address allocation, host-specific configuration
parameters
AIX DHCP daemons are dhcpsd, dhcpcd and dhcprd
Dynamic DNS is the process of updating DNS zone records without
the need for manual intervention. This is particularly useful in a
DHCP environment
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 11. Problem Determination

This unit describes debugging tips, problem areas of hardware and
software, and diagnostic commands and tools available for
understanding problem areas in networking.

Describe debugging alternatives
Document network and system configuration
Use tools to diagnose TCP/IP problems

Accountability:
Exercises
Copyright IBM Corp. 1997, 2006 Unit 11. Problem Determination 11-1
Instructor Guide
Unit Objectives
Describe debugging alternatives
Document network and system configuration
Use tools to diagnose TCP/IP problems
Notes:

V3.1.0.1
Instructor Guide

Purpose Set the students' expectation level for the lecture.
Details Three general topics in this module:
Debugging methodology
Documenting system and network configuration
Debugging tools
Discuss the level of detail for this lecture. Each of the lectures could last for a day. In fact,
classes exist on these topics. Our focus is to identify some of the issues and commands
involved with networking.
Everything is intended to be taught at an introductory level. The flow of the unit is to first
discuss the importance of having a problem resolution methodology in place which needs
to include a picture of the network topology and information on system configuration. All
this should be documented when the systems and network are running smoothly. The first
set of commands that are covered are those that can be used to document the system. The
next set can be used to aid in debugging. The unit ends with a brief review of what steps to
take to isolate the problem of two systems unable to communicate with each other.
Transition Statement Let's begin our discussion of using a debugging methodology.
Instructor Guide
Debugging Networks
Work from a picture
Use a methodology
What are your assumptions?
Figure 11-2. Debugging Networks AU079.1
Notes:
Diagram the network topology so you can clearly identify the components involved. Collect
such information as IP addresses and network masks.
Be methodical in solving the problem. Work through the protocols from bottom to top,
hardware to networking, to application. Identify what works and what specifically will not.
Many times the problem can be identified when you examine your assumptions. What has
changed? What used to work or works now? What values are tables really set to?
Eliminate variables one by one.
Try to answer some basic questions to help identify the scope and nature of the problems.
These questions include:
Is it just this machine?
Is it intermittent or continuous?
Is it just this subnet or several subnets connected to a router?
Is it all services or just one service, for example NFS?

V3.1.0.1
Instructor Guide
Uempty Was the network changed in any way?

Was this machine changed in any way?
Was it working before?
Are the gateways operating?
Instructor Guide
Instructor Notes:
Purpose Discuss general strategies at debugging networks.
Details This page can actually be the point of discussion for many minutes. It is a
collection of hints and common sense advice--some learned the hard way.
Spend some time discussing the value of using a picture in debugging a network. Using a
picture allows you to identify the topology involved. In addition, it helps to correctly identify
the components involved-- both hardware, software, IP address, and so forth. Finally,
working with a picture can help eliminate confusion between the end-user/problem
reporter, and the net-administrator/problem solver. Any stories can be helpful--like the
bridge testers that were putting an experimental bridge on two Ethernet segments.
Unfortunately they had some confusion on the segments and connected both interfaces to
the same segment. Better example--not realizing bridges and routers are in the topology
between client and server.
It is important to be methodical in debugging a problem. The reason is to be efficient. Most
of us want to wing it and just quickly solve it. Example: guessing a number between 1 and
1000. Sporadic guessing can take forever.
Possible methodologies:
a) What is the most embarrassing/obvious cause of error? Machine off, cable
disconnected, bad cable, connector. Something just changed. PC just added and there
are now broadcast storms.
b) What can you check and correct the easiest or quickest? ping can tell you quickly
if you have basic connectivity to the box.
c) Climb protocol stack from the bottom when debugging. Can I do Xwindow, if my
cable is broken? My NFS mounts always fail as long as my routing table is in error.
Assumptions: Where do you assume most network problems occur? Hardware failure,
software bugs, configuration. My experience is that most problems are not software
bugs but configuration errors. Your assumptions point you to where you put your
attention, and if the problem is not discovered quickly, where you may want to look next
at your assumptions.
You deal with two basic problems--set up or maintenance.
With maintenance you are trying to find out what has changed. Example: End-user
report, Nothing has changed, but now it does not work. But we assume a deterministic
system --Given A,B,C, then D will always occur. On networks, tracking change is
difficult because sometimes you do not control all the pieces or even track all the pieces
at the same time. We have seen in the exercises that one of the biggest challenges is
keeping in sync with other systems.
The key is to use common sense coupled with a methodical approach to isolating the
problem.

V3.1.0.1
Instructor Guide
Uempty Discussion Items How helpful were the drawings of the exercise topology in doing the
labs this week?
If I can reach all of the systems on my network but not on another, where might the problem
lie? Check the routing tables.
What if all the systems on an Ethernet segment suddenly stop being able to communicate?
Check the cabling.
What should I look for if I can telnet to a system using the IP address but not the host
name? Check name resolution (either /etc/hosts, NIS, DNS, or LDAP).
Transition Statement A very helpful methodology already mentioned is to use the
TCP/IP layers, and starting at the bottom, work your way up until the problem has been
isolated. Let's quickly review how the data flows.
Instructor Guide
TCP/IP Data Flow
Send Receive
Application Write Buffer Read Buffer
Transport Socket Send Socket Receive

Buffer Buffer
Network MTU Compliance IP Input Queue
Network Interface Transmit Queue Receive Queue
Physical Transport Medium
Figure 11-3. TCP/IP Data Flow AU079.1
Notes:
The standard debugging approach is to start at the lowest layer, the one everything else
depends on, and work your way up testing and checking as you go. ping is a good
command to begin the test of connectivity.

V3.1.0.1
Instructor Guide

Purpose Describe the approach of starting with the physical layer and working your way
up to the application level.
Details You may wish to begin this discussion with a brief review of how the data flows
from application to application. The diagram is created from a slightly different perspective
than the one used in the concept unit. From this perspective, data is written from the
application to a write buffer. System memory is used for this. If the message is small it is
then copied to a socket send buffer (either TCP or UDP depending on what the application
requested). The port number of the sending application is included here along with the port
number of the receiving application which was requested by the sending application. TCP
segments the data stream and adds its control information and passes it to IP. IP adds its
information including the correct IP source and destination addresses, checks the arp table
and puts it in the transmit queue of the network interface. It then gets taken from the
transmit queue and put on the wire after the appropriate network interface control
information is added.
The destination machine receives the message from the transport medium and puts it in
the receive queue. Once the network interface has completed its check it passes to the IP
input queue where IP puts the datastream back together if it had to be fragmented at the
sending side (UDP transport protocol doesn't break up large datastreams, IP has to do
this). When complete, the datastream is copied to the socket receive buffer and the
application notified. The data is then put in the application read buffer. All the buffer and the
IP input queue use system memory, a potentially limited resource. The transmit and
receive queues use memory on the adapters. There are many places along the way where
a message can be delayed or lost. That is why it is a good idea to use this layered
approach to isolating a problem starting from what every other layer depends on, the
hardware layer.
Transition Statement Before going into the individual commands that can be used to
isolate network related problems, let's look at a roadmap of what role these commands
play in the problem determination process.
Instructor Guide
Overview of Troubleshooting Commands
UNIX
AIX
TCP/IP
Specific
lscfg, lsdev,
Document
lsattr
System
snap
lsattr ifconfig
Document
lsdev no
Network
snap
ping, ifconfig
iptrace arp
Problem
errpt netstat
Determination
pmtu traceroute
no
Tuning chdev
ifconfig
Figure 11-4. Overview of Troubleshooting Commands AU079.1
Notes:
The above table shows the various commands we cover in this unit. Some are available
only on AIX systems, others are available across UNIX systems running TCP/IP.

V3.1.0.1
Instructor Guide

Purpose Provide an overview of what commands we will cover and for what purpose
they can be used.
Details Since the unit tends to be a collection of commands students often lose sight of
the big picture what we are trying to accomplish with these commands. This overview
can be used to put the various commands into perspective of how they can be used. The
discussion starts with how to document the system using the lscfg, lsdev, lsattr, ifconfig
and no commands. Then we move into the commands that help in problem determination
and isolation. Since some of these commands can aid in several areas be sure to mention
those already covered, like ifconfig and no, in the appropriate places. There is only one
foil for each command, except netstat which we show a foil for each of several options, so
feel free to refer back to previously covered commands when you are discussing the new
area such as problem determination and tuning.
Transition Statement In order to begin problem determination at the hardware layer, a
good picture of the hardware in the network and its configuration when it is working is
important to have. Let's look at some commands to help capture this information.
Instructor Guide
List System Configuration Information

# lscfg
INSTALLED RESOURCE LIST
+ sys0 00-00 System Object
+ sysplanar0 System Planar
+ pci0 P1 PCI Bus
+ isa0 P1 ISA Bus
+ hdisk0 P1/Z1-A4 16-Bit SCSI Disk Drive
+ ent0 P1/E1 Ethernet PCI Adapter
# lscfg -l ent0 -v
DEVICE LOCATION DESCRIPTION
ent0 P1/E1 IBM 10/100 Mbps Ethernet PCI Adapter
Network Address . . . . . . . . . . . . . . . . . . . . . 004AC179D7S

Displayable Message . . . . . . . . . . . . . . . . . . . PCI Ethernet Adapter
Device Specific (YL). . . . . . . . . . . . . . . . . . . P\/E1
Figure 11-5. List System Configuration Information AU079.1
Notes:
lscfg without any parameters lists the name, location, and brief description of each device
that your system knows about.
lscfg -v -l ent0 displays vital product data for a particular device.

V3.1.0.1
Instructor Guide

Purpose Introduce the use of the lscfg command.
Details lscfg can quickly show all the devices, especially network adapters, installed in
the system. You do not even have to remember any parameters. It is an AIX-unique
command. Example, do I have one or two network cards? What slots are they in?
-v displays vital product data found in the customized VPD object class.
Additional Information A plus or minus in front of a device indicates that the device has
either been added (+) or deleted (-) from the Diagnostic Test List. An * indicates diagnostic
support is not available.
Transition Statement A similar command that shows devices and their locations is
lsdev. This command can show not only configured devices but also ones that can be
configured (predefined). Let's see how this command works.
Instructor Guide
List Device Information

# lsdev -C -c if
en2 Defined IP-08 Standard Ethernet Network Interface
et0 Available 10-60 IEEE 802.3 Ethernet Network Interface
et1 Available 10-90 IEEE 802.3 Ethernet Network Interface
et2 Available IP-08 IEEE 802.3 Ethernet Network Interface
lo0 Available Network Interface Loopback
# lsdev -C -c adapter
ent0 Available 10-60 IBM 10/100 Mbps Ethernet PCI2 Adapter
ent1 Available 10-90 10/100 Mbps Ethernet PCI Adapter II
ent2 Available IP-08 IBM 10/100/1000 Base-T Ethernet PCI Adapter
fda0 Available 01-P1 Standard I/O Diskette Adapter
ppa0 Available 01-R1 CHRP IEEE 1284 (ECP) Parallel Port Adapter
sa0 Available 01-S1 Standard I/O Serial Port
sa1 Available 01-S2 Standard I/O Serial Port
scsi0 Available 10-80 Wide/Fast-20 SCSI I/O Controller
Figure 11-6. List Device Information AU079.1
Notes:
These two displays simply show how you can use the Isdev command to list out the
interfaces and adapters configured on your system. Our interest in these displays is with
the network interfaces and adapters.
The -C flag lists information about a device that is in the Customized Devices Object Class.
The default information that is displayed is name, status, location, and description. The
Isdev command used with the -P option shows devices that can be configured.
The -c <class> flag specifies a device class name. This flag can be used to restrict output
to devices in a specified class, such as adapter, disk, printer, and so forth.

V3.1.0.1
Instructor Guide

Purpose Introduce the use of the Isdev command.
Details Isdev shows which adapters are configured (AVAILABLE) and which are not
(DEFINED).
Explain the difference between ent0 and en0 or et0 (adapter versus protocol interface).
Also, discuss how the numbers correlate between adapter and interface.
Some times cfgmgr marks a card as missing if cards are moved around.
Additional Information The -H option used with the Isdev command is useful because
it provides headings over the columns. The command: Isdev -P if will show all the
predefined network interfaces, those that can be used.
Transition Statement A useful command for more specific information on a particular
device or network interface is the Isattr command.
Instructor Guide
List Device Attributes

# lsattr -E -H -I en0
attribute value description user_settable
alias4 value IPv4 Alias including Subnet Mask True

alias6 IPv6 Alias including Prefix Length True
arp on Address Resolution Protocol (ARP) True
authority Authorized Users True
broadcast Broadcast Address True
mtu 1500 Maximum IP Packet Size for this Device True
netaddr 10.19.98.1 Internet Address True
netaddr6 255.255.255.0 IPv6 Internet Address True
netmask Subnet Mask True
prefixlen Prefix Length for IPv6 Internet Address True
remmtu 576 Maximum IP Packet Size for Remote Networks True
rfc1323 Enable/Disable TCP RFC/323 Window Scaling True
security none Security Level True
state up Current Interface Status True
tcp_mssdflt Set TCP Maximum Segment Size True
tcp_nodelay Enable/Disable TCP_NODELAY Option True
tcp_recvspace Set Socket Buffer Space for Receiving True
tcp_sendspace Set Socket Buffer Space for Sending True
Change MTU: # chdev -l en0 -a mtu="2000"
Figure 11-7. List Device Attributes AU079.1
Notes:
The Isattr command displays information about the attributes of a given device or kind of
device, as well as some of the possible values for a device on the system.
This example shows how the Isattr command can be used for checking on the LAN
adapters. The -E flag is used to display effective values (valid only for customized devices
specified with the -l flag). The -l <name> specifies the device logical name in the
Customized Device Object Class whose attribute names or attribute values are to be
displayed.

V3.1.0.1
Instructor Guide

Purpose Introduce the use of Isattr.
Details Isattr is the AIX command for showing how a device or network interface is
configured. ifconfig is more universal but shows a little bit different information.
The -E option shows the effective values. The -l option displays the device logical name.
Additional Information To change these attributes, use the chdev command.
Transition Statement The information provided by the Isattr command for netaddr,
state, trailers, netmasks, and broadcast can also be displayed with the ifconfig command.
Let's take a look at its format.
Instructor Guide
Network Interface Parameters Display

# ifconfig en0
en0: flags=4e080863,80<UP, BROADCAST, RUNNING, SIMPLEX,
MULTICAST, GROUPRT, 64BIT, PSEG, CHAIN>
inet 10.19.98.1 netmask 0xffffff00 broadcast 10.19.98.255
# ifconfig pp0
pp0: flags=e080031<UP, POINTTOPOINT, NOTRAILERS,
RUNNING, GROUPRT,64BIT>
inet 192.168.1.1 --> 192.168.1.2 netmask 0xfffff00
# ifconfig lo0
lo0: flags=e08084b<UP, BROADCAST, LOOPBACK, RUNNING,
SIMPLEX, MULTICAST, GROUPRT, 64BIT>
inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
inet6 :: I/O
tcp_sendspace 131072 tcp_rcvspace 131072 rfc1323
Figure 11-8. Network Interface Parameters Display AU079.1
Notes:
The ifconfig command configures or displays network interface parameters for a network
that uses TCP/IP.
UP and RUNNING is good. Running means that the kernel resources and buffers have
been assigned. An adapter can be UP but not RUNNING.
Check that the netmask is set correctly and is consistent with all hosts on the network. The
0x on netmask indicates the values that follow are in hex.
MULTICAST shows that this interface is able to participate in a multicast session.

V3.1.0.1
Instructor Guide

Purpose Discuss the output of the ifconfig command.
Details ifconfig can be used to configure TCP/IP interfaces from the command line.
Once configured, using ifconfig with an interface name displays the state of the interface.
It is a common UNIX command unlike the three previously covered commands which are
AIX only.
Cover the student notes for the output and how to evaluate it.
The subnet mask is shown in hex. ffffff00 equals 255.255.255.0.
Any user can use the ifconfig command to query an interface, however, only root or a
member of the system group can use ifconfig to modify the configuration of the interfaces.
Additional Information Current interface layer support for hotplug network adapters
has eliminated the upper bound for the ifsize for Ethernet. With the introduction of
virtualization technologies, the amount of interface layer structure needed has increased.
See help on no-h ifsize command.
Transition Statement Now that you have a pretty good picture of your system
configuration, lets see how we can gather and capture system and network configuration
information using the snap command.
Instructor Guide
snap Command
Gathers system configuration information
Compresses information into pax file
Requires root authority to use
# snap -c -i -n -t -o /dev/rmt0
Will capture :
Device VDP information
All NFS information
All TCP/IP information
And compress the output to tape device rmt0
Figure 11-9. snap Command AU079.1
Notes:
The snap command gathers system configuration information and compresses the
information into a pax file. The file can then be downloaded to disk or tape, or transmitted to
a remote system.
Use the snap -o /dev/rfd0 command to copy the compressed image to diskette. Use the
snap -o /dev/rmt0 command to copy the image to tape.
Approximately 8 MB of temporary disk space is required to collect all system information,
including contents of the error log. If you do not gather all system information with the snap
-a command, less disk space may be required (depending on the options selected).
The snap command checks for available space in the /tmp/ibmsupt directory, the default
directory for snap command output. You can write the output to another directory by using
the -d flag. If there is not enough space to hold the snap command output, you must
expand the file system.
Each execution of the snap command appends information to previously created files. Use
the -r flag to remove previously gathered and saved information.

V3.1.0.1
Instructor Guide

Purpose Introduce the snap command to document the system and network
configuration.
Details The snap command has the following flags available:
-a Gathers all system configuration information. This option requires
approximately 8MB of temporary disk space.
-A Gathers asynchronous (TTY) information.
-c Creates a compressed pax image (snap.pax.Z file) of all files in the
/tmp/ibmsupt directory tree or other named output directory.
Note: Information not gathered with this option should be copied to the snap directory tree
before using the -c flag. If a test case is needed to demonstrate the system problem, copy
the test case to the /tmp/ibmsupt/testcase directory before compressing the pax file.
-d Dir Identifies the optional snap command output directory
(/tmp/ibmsupt is the default).
-i Gathers installation debug vital product data (VPD) information.
-n Gathers Network File System (NFS) information.
-N Suppresses the check for free space.
-o OutputDevice Copies the compressed image onto diskette or tape.
-r Removes snap command output from the /tmp/ibmsupt directory.
-t Gathers Transmission Control Protocol/Internet Protocol (TCP/IP) information.
-w Gathers WLM information
Additional Information See commands reference manual for all flags available.
Transition Statement A useful command to use to view and tune network options in
effect on your system is the no command. Let's see what information it provides.
Instructor Guide
Display Network Options

# no -a
thewall = 131052 extendednetstats = 0
sockthresh = 85 somaxconn = 1024
sb_max = 1048576 rto_low = 1
tcp_sendspace = 16384 rto_high = 64
tcp_recvspace = 16384 rto_limit = 7
udp_sendspace = 9216 rto_length = 13
udp_recvspace = 42080 inet_stack_size = 16
bcastping = 0 arptab_bsiz = 7
rfc1323 = 0 arptab_nb = 25
pmtu_default_age = 10 arpt_killc = 20
pmtu_rediscover_interval = 30 subnetsarelocal = 1
udp_pmtu_discover = 1 maxttl = 255
tcp_pmtu_discover = 1 ipfragttl = 60
directed_broadcast = 0 ipsendredirects = 1
ipignoreredirects = 0 ipforwarding = 0
ipsrcroutesend = 1 udp_ttl = 30
ipsrcrouterecv = 0 tcp_ttl = 60
ipsrcrouteforward = 1 ipqmaxlen = 100
Figure 11-10. Display Network Options AU079.1
Notes:
The no command sets or displays current network options in the kernel depending on the
option used. When making changes, this command only operates on the current running
system and must be run again after each startup or after the network has been configured.
To make changes permanent, they must be included in the /etc/rc.net file.
Warning: Be careful when you use this command. The no command performs no range
checking; therefore, it accepts all values for the variables. If used incorrectly, the no
command can cause your system to become inoperable.
The -a option prints a list of all configurable options and their current values. The -o option
followed by option=New Value changes the value of the specified option.
no -d option sets the option variable back to its default state.

V3.1.0.1
Instructor Guide

Purpose Describe the use of the no command to configure and display the kernel's
network options.
Details The no command is useful to document current network settings as well as aid
in problem determination and tuning.
Most of AIX is designed so that tuning is not necessary by the system
administrator--especially compared to other UNIX operating systems. The network is an
exception, because networking varies so much from system to system in its impact on
system resources.
The important values at this point to focus on are the wall and ipforwarding.
Some call no a patch program because it allows you to look into the kernel and vary
values. Refer to Appendix E, Summary of no options on page E-1 for a summary of no
options.
Transition Statement Now, let's look at the ping command to isolating network
problems.
Instructor Guide
Test Network Connectivity

# ping -c 5 sys1
PING (10.19.98.1): 56 data bytes

--- sys1 ping statistics ------------------------------------------------

Figure 11-11. Test Network Connectivity AU079.1
Notes:
The ping command sends one datagram per second and prints one line of output for every
response received. It calculates round trip times and packet loss statistics, and displays a
brief summary upon completion.
Because of the load continuous echo requests can place on the system, repeated requests
should be used primarily for problem isolation.
The gap between packet 2 and packet 4 is exceptionally long. This can be caused by a bad
or improper termination on an Ethernet network. On token-ring this would indicate that not
all devices are set to the same token-ring speed.

V3.1.0.1
Instructor Guide
Uempty ping options that may be useful:

-c Specifies the number of requests to be sent
-f Floods output packets as fast as they come back or one
hundred times per second. This tests the capability of the
network to handle a lot of traffic in a short period of time.
Note: Use with caution as this can be very hard on a network.
Only the root user can use this option
-I Indicates the interface specified by a.b.c.d. is to be used for
multicasts
-R Turns on the record route option which displays the route buffer
on returned packets.
-s packetsize Specifies the number of data bytes to be sent. The default is 56.
The largest is 8184 which, when the eight bytes of the ICMP
header data is added to it, makes a total number of bytes sent
of 8192.
-d Start socket-level debugging
Instructor Guide
Instructor Notes:
Purpose Identify the different information the ping command can give you as to what is
occurring on the LAN.
Details One of the difficulties of network debugging is not being able to see what is
occurring on the wire/network. ping gives a surprising amount of information. Review how
it is simply forming a packet every second that is passed to the target and echoed back.
Issuing the ping command verifies that the bottom half of the protocol stack is correctly
configured for both machines, and that the network is intact in between. This is commonly
used to start debugging.
Each packet is sequenced. The output can show the reliability of the network--are packets
being lost? Once the command is ended, it shows the number of packets lost. Lost packets
can be bad cabling.
Become familiar with what is a normal response time, when pinging other devices, so that
you can determine abnormal conditions.
The statistics on minimum, average, and maximum response time are significant. Ideal is
to have little spread between minimum and maximum times. In addition, the average is
best when close to the minimum.
Additional Information Error messages returned from ping can also be a valuable
source of information when first beginning to isolate a problem. For example the message:
ping: host name xxx not found
could indicate a potential problem with name resolution.
The message
ping: sendto: A route to the remote host is not available
indicates the routing table doesn't know where to send the packet in order to reach its
destination. Use netstat -r to check the routing table.
The message
ping: sendto: A message for a socket data transfer is too long
could indicate a problem with the mtu size. Use netstat -i to check the interface statistics.
Even when the response you get is no message such as
ping sandbox1 (9.19.110.1)&colon 56 data bytes
this still can be helpful. What this tells you is that name resolution is working, the system
found a route on which to send the packet, however the packet is either hung up on an
intermediate router or the destination machine is not responding properly (turned off,
doesn't have a route back, and so forth). The problem most likely does not exist on the
sending machine but on the receiving machine or somewhere in-between.

V3.1.0.1
Instructor Guide
Uempty Transition Statement If network performance within a particular LAN segment is slow
then it may be useful to send down a number of datagrams down the wire to a particular
host and receive back performance statistics. Spray can be used to do this.
Instructor Guide
Test Network Performance

# spray sys1 -c 5000 -l 1500 -d 1
sending 5000 packets of length 1502 to

sys1 ...
159 packets (3.180%) dropped by sys1

754 packets/second, 1133741 bytes/second
Figure 11-12. Test Network Performance AU079.1
Notes:
Spray sends a specified number of packets to a host and reports performance statistics.
The spray command uses the Remote Procedure Call (RPC) protocol to send a one-way
stream of packets to the host you specify. As RPC is at a higher level then ICMP it provides
a more accurate picture of overhead than using ping. This command reports how many
packets were received and at what transfer rate. The Host parameter can be either a name
or an Internet address. The host only responds if the sprayd daemon is running.
A normal TCP/IP host should be able to handle spray with a delay of 1 ms without dropping
any packets. If the host does drop packets then the receive queue on the adapter could be
too small, the host is too slow or too loaded or there are problems on networks/gateways in
between systems.

V3.1.0.1
Instructor Guide
Uempty Options are:

-c Count Specifies the number of packets to send.
-d Delay Specifies the time, in microseconds, the system pauses between sending
each packet. The default is 0.
-i Uses the Internet Control Message Protocol (ICMP) echo packets rather than
the RPC protocol. Since ICMP echoes automatically, it creates a two-way
stream. You must be root user to use this option.
-l Length Specifies the number of bytes in the packet that holds the RPC call
message. The default value of the Length parameter is 86 bytes, the size of the
RPC and UDP headers.
Instructor Guide
Instructor Notes:
Purpose Discuss spray command.
Details
Additional Information The data in the packet is encoded using eXternal Data
Representation (XDR). Since XDR deals only with 32-bit quantities, the spray command
rounds smaller values up to the nearest possible value.
Transition Statement Lets see how we check for potential problems with address
resolution.
When experiencing connectivity problems, it is a good idea to check for potential problems
with address resolution. The arp command is used for this.

V3.1.0.1
Instructor Guide
Uempty
Check Address Resolution
# arp -a
sys2 (10.19.98.2) at 8:0:20:1:9f:4a (published)
sys5 (10.19.98.5) at (incomplete)
sys3 (10.19.98.3) at 10:0:5a:a8:3a:1f [token ring]
? (10.19.98.1) at (incomplete)
Figure 11-13. Check Address Resolution AU079.1
Notes:
Dynamic entries are added on the fly during the course of normal IP traffic on a physical
network. Infrequently used mappings added in this fashion have a short lifetime in the ARP
table. After 20 minutes without reference to the entry, it is then purged from the table. The
default value of 20 minutes can be changed by using the no command.
Published entries in the ARP table are entries that turn that host into an ARP server.
Normally, a host replies only to requests for its own IP address, but if it has published
entries, then it replies for multiple IP addresses for which it has a published entry.
The incomplete entry indicates a host did not respond to an ARP request. Incomplete
entries are deleted after three minutes.
Instructor Guide
Instructor Notes:
Purpose Discuss the use of the arp -a command.
Details arp -a shows the systems on the LAN that have been recently contacted.
Incomplete entries show hosts that did not respond to the arp request.
Hosts publishing the entry answer for another host. This is used for a system that cannot
respond to arp or is isolated from broadcast packets by a piece of network partitioning
hardware that filters out broadcasts. For an entry to be marked published it has to be added
via either the arp -s or arp -f commands. arp -s creates an arp entry from parameters
provided on the command line. The format is:
arp -s Type HostName AdapterAddress [Route] [temp] [pub]
Where Type specifies the type of hardware address, that is, ether for Ethernet, 802.3 for
802.3, fddi for Fiber Distributed Data Interface, and 802.5 for token-ring; HostName
specifies the remote host; AdapterAddress specifies the hardware address; Route
specifies the token-ring or FDDI route as defined in the header; temp indicates it is a
temporary entry; and pub specifies it is to be a published entry.
Discussion Items For a network with lots of non-AIX devices, sometimes it is intriguing
to do a ping net_id (9.19.98.0) to see who responds. Then dump the arp cache. Another
situation that can be interesting to diagnose is where multiple machines are configured with
the same IP address. Gratuitous ARP support provides a logging of misconfiguration
messages in the system log. The ifconfig command does not fail when duplicate addresses
are in use in the network, both system administrators can identify the problem by looking at
the error log and finding an entry of AIXIF_ARP_DUP_ADDR.
Additional Information Some entries may show a ? for the host name. The IP and
hardware addresses were received, but the system cannot do reverse name resolution on
it; for example, IP address to name translation.
Transition Statement A common source of problems encountered in the network deals
with name resolution. Let's start by looking at DNS since that is the required method for
name resolution in the Internet.

V3.1.0.1
Instructor Guide
Uempty
Isolating Name Resolution Problems with DNS
Should No Yes
/etc/resolv.conf Does it? Remove it
exist?
Yes No
No
Does it? Create it
Yes
Check for valid

No nameserver
Does it contain
DNS pointer? addresses and update
file
Yes
Is named No
running? Start it
Is entry valid?
Yes
No
Check database
Update entries
Figure 11-14. Isolating Name Resolution Problems with DNS AU079.1
The first step is to check for the existence of the /etc/resolv.conf file. A quick way to do
this is with the ls -l /etc/resolv.conf command. If this system was not meant to be a part of
a DNS environment, this file should be removed if it exists. If it exists and it shouldn't, all
network services are impacted waiting on DNS to time out before a name gets resolved by
some other method, either NIS or /etc/hosts.
If this file should exist but it does not, create it. The file should only be empty if this system
is a name server. If it is not, the file should contain the IP addresses of nearby name
servers.
If the system is supposed to be a name server, the named daemon should be running. Use
lssrc -s named to see if it is running and startsrc -s named to start it if it is not running.
If name resolution is still not working, check the setup of the /etc/named.boot file and look
at the active database by issuing the command kill -2 <PID of named>. A useful command
for isolating and debugging DNS name resolution problems is nslookup.
Instructor Guide
Instructor Notes:
Purpose Review potential problems when using DNS as a name server.
Details Name resolution problems can masquerade as many other problems due to the
messages and symptoms shown. For example, in remote printing you may get a message
of permission denied when a client system tries to establish connections to the server. The
authentication file lists a host name, however, what gets passed to the server over the
network is the IP address which then has to be resolved to a host name and then a match
sought in the authentication file. If the match is not exact, you get the permission denied
message. Also, slow response on a telnet or ftp session may simply be a DNS lookup
timing out due to an improperly configured /etc/resolv.conf file.
Additional Information Other useful techniques include:
Using the -d option of named to increase the information written to the syslog.
Issuing the kill -2 to named to cause it to dump its virtual memory zone information.
Using nslookup to query name servers.
Transition Statement A very useful tool in doing problem determination is the netstat
command. Let's take a look at a few of the uses of netstat. Starting with:
Memory
Transport Layer
IP Layer
Network Interface Layer

V3.1.0.1
Instructor Guide
Uempty
Display Network Memory Usage
# netstat -m
27 mbufs in use:
16 mbuf cluster pages in use
70 Kbytes allocated to mbufs
0 requests for mbufs denied
0 calls to protocol drain routines
0 sockets not created because sockthread was
reached
Kernel malloc statistics:
******* CPU 0 *******

By size inuse calls failed free hiwat freed
32 226 10860 0 158 640 0
64 108 2324 0 20 320 0
128 114 11066 0 46 160 0
256 169 8515049 0 311 384 0
512 174 68321 0 42 40 23
1024 58 237731 0 66 100 0
2048 0 51319 0 32 100 0
4096 3 68707 0 20 120 0
8192 0 36101 0 10 10 2
16384 1 19227 0 24 24 687
32768 1 1 0 0 511 0
Figure 11-15. Display Network Memory Usage AU079.1
Notes:
The kernel allocates memory from the network memory buffer pool, commonly called the
mbuf pool, to be used as buffers by the networking subsystem. The size of the mbuf is a
tunable parameter and is changed using thewall option of the no command.
Note: By default, the top portion of this display is not shown. To display, you have to enable
the extended statistics option under the no command: no -o extendednetstats=1.
Instructor Guide
Instructor Notes:
Purpose To show where to look for memory problems with the netstat -m command.
Details The output on this visual is by no means complete. It only shows the first part of
the output which holds the information regarding memory denied. This is the most critical
piece of information. The rest of the output lists kernel malloc statistics which has less
information for students at this stage of the game.
Additional Information The kernel maintains usage statistics for the buffers allocated
from the network memory buffer pool. The information contains details of the number of
buffers of each size, and for each size, information on the number of buffers in use and the
number of failed requests. In addition to maintaining information indexed by buffer size, the
kernel also maintains information indexed by the purpose the buffer is being used for.
The extendednetstats network variable, which is altered using no command, determines
whether the by-type statistical information should be collected by the kernel (default=0 is
off).
Transition Statement Lets see how we can use netstat to display UDP transport layer
statistics

V3.1.0.1
Instructor Guide
Uempty
Display Transport UDP Statistics
netstat -p udp
udp:
5142064 datagrams received
0 incomplete headers
0 bad data length fields
0 bad checksums
10 dropped due to no socket
593 broadcast/multicast datagrams dropped due to no socket
0 socket buffer overflows
5141461 delivered
4111970 datagrams output
Figure 11-16. Display Transport UDP Statistics AU079.1
Notes:
The value for packets dropped due to no socket indicates that a node sent data to a socket
on the receiving node that was never opened. Or, this value could indicate that another
node sent a packet but the process was killed, which also closes the socket. If this value is
high, investigate the way the application is handling sockets.
The value for socket buffer overflows could indicate that the udp receive socket buffer is not
large enough for all the traffic using the buffer.
Instructor Guide
Instructor Notes:
Purpose Discuss the UDP statistics provided by the netstat -p udp command.
Details
Additional Information The line socket buffer overflows used to be labeled dropped
due to full socket buffers
Transition Statement Now that weve examined UDP transport statistics, lets move on
to examining the TCP transport.

V3.1.0.1
Instructor Guide
Uempty
Display Transport TCP Statistics
netstat -p tcp
tcp:
38417 packets sent
21769 data packets (986484 bytes) 0 discarded for bad header offset fields
0 data packets (0 bytes) retransmitted 0 connection request
9223 ack-only packets (900 delayed) 3533 connection requests
0 URG only packets 350 connection accepts
0 window probe packets 3876 connections established (including accepts)
150 window update packets 4720 connections closed (including 3 drops)
7275 control packets 7 embryonic connections dropped
34594 packets received 27099 segments updated rtt (of 27110 attempts)
23612 acks (for 990606 bytes) 0 resends due to path MTU discovery
3017 duplicate acks 0 path MTU discovery terminations due to
0 acks for unsent data 16 retransmit timeout
19406 packets (1988808 bytes) received in-sequence 16 retransmit timeout
578 completely duplicate packets (568 bytes) 0 connections dropped by rexmit timeout
0 packets with some dup. data (0 bytes duped) 0 persist timeouts
2520 out-of-order packets (0 bytes) 568 keepalive timeouts
53 packets (0 bytes) of data after window 568 keepalive probes sent
0 window probes 0 connections dropped by keepalive
Figure 11-17. Display Transport TCP Statistics AU079.1
Notes:
For the TCP statistics, compare the number of packets sent to the number of data packets
retransmitted. If the number of packets retransmitted is over 10-15% of the total packets
sent, TCP is timing out indicating that network traffic may be too high for
acknowledgements (ACKs) to return before a time-out. A bottleneck on the receiving node
or general network problems can also cause TCP retransmissions. TCP retransmissions
increase network traffic, further adding to any network performance problems.
Also, compare the number of packets received with the number of completely duplicate
packets. If TCP on a sending node times out before an ACK is received from the receiving
node, it retransmits the packet. Duplicate packets occur when the receiving node
eventually receives all the retransmitted packets. If the number of duplicate packets
exceeds 10-15%, the problem may again be too much network traffic or a bottleneck at the
receiving node. Duplicate packets increase network traffic.
The value for retransmit time-outs occurs when TCP sends a packet but does not receive
an ACK in time. It then resends the packet again. This value is incremented for any
Instructor Guide
subsequent retransmittals. These continuous retransmittals drive CPU utilization higher,

and if the receiving node does not receive the packet, it eventually is dropped.

V3.1.0.1
Instructor Guide

Purpose Discuss TCP statistics obtained from the netstat -p tcp command.
Details You may also wish to note the out-of-order packets. This can occur when
packets are taking different routes in the network to get from source node to destination
node. Either multiple routes exist for packets to take or the routes available for packets are
changing rapidly (if using dynamic routing). This does not necessarily indicate a problem as
TCP reorders the packets as it receives them (UDP does not know about order. When
using UDP, it is up to the application to put all received packets in order).
Transition Statement Problems quite often occur due to incorrect routing table entries.
Lets review netstat -rn.
Instructor Guide
Display Routing Table

# netstat -rn
Routing tables
Destination Gateway Flags Refs Use if PMTU Exp Groups

default 10.19.98.1 UG 2 1931 tr1 - -
10.19.98/24 10.19.98.2 U 2 1931 tr1 - -
10.19.11.44 127.0.0.1 UH 0 2 lo0
127/8 127.0.0.1 U 0 184lo0 - -

::1 ::1 UH 0 0 lo0 16896 -
Figure 11-18. Display Routing Table AU079.1
Notes:
The netstat -r command displays the kernel routing table. It shows the destination, either
network or host, the gateway used in forwarding packets, and the status of the route as
indicated by the Flags column. Flags are:
A Active Dead Gateway Detection

U Up
H Route is to a host rather than a network
G Route is to a gateway
D Route was created dynamically by a redirect
M Route was modified by a redirect
L The link-level address is present in the route
entry
c Access to this route creates a cloned route
W The route was cloned

V3.1.0.1
Instructor Guide
Uempty 1 Protocol specific routing flag # 1

2 Protocol specific routing flag # 2
3 Protocol specific routing flag # 3
b The route represents a broadcast address
c Has a binding cache entry
l The route represents a local address
m The route represents a multicast address
p Pinned route
r Host or net unreachable
s Manually added
u Route usable
The Refs column shows the current number of active uses of the route.
The Use column gives a count of the number of packets sent using that route.
The Interface column identifies the network interface being used for the specified route.
The PMTU give the Path Maximum Transfer Unit. AIX 5.3 does not display PMTU value.
The Groups column provides a list of group IDs associated with that route
Instructor Guide
Instructor Notes:
Purpose Review the output of the netstat -rn command.
Details The netstat -r command shows the routes listed in the kernel routing table. With
the addition of the -n option, the routes are shown by the IP address. If the -n option is not
used, the IP address is resolved to a host name, if possible. If there is a problem with name
resolution the output could look right but in reality the wrong IP address is being
referenced. Thus, it is usually a good idea to include the -n option when using this
command in troubleshooting problems.
The Refs column shows the current number of active uses for the route.
Connection-oriented protocols hold onto a single route for the duration of the connection
whereas connectionless protocols obtain a route each time they send something, even to
the same destination. Thus, depending on the type of network activity on a system, this
number could fluctuate or stay relatively constant.
Additional Information The netstat -c shows the routing table including the
user-configured and current costs of each route. The netstat -rs shows routing statistics.
Transition Statement The routing table shows the PMTU which is not supported in AIX
5.3. Lets take a look at the pmtu command.

V3.1.0.1
Instructor Guide
Uempty
Display pmtu Table
pmtu command
# pmtu display
dst gw If pmtu refent redisc_t exp

-------------------------------------------------------
192.168.1.2 127.0.0.1 lo0 16896 22 19 0
10.19.99.2 127.0.0.1 lo0 16896 52 27 0
10.19.98.5 10.19.99.11 en0 1500 32 13 0
192.168.6.1 10.19.99.11 en0 1500 12 3 0
127.0.0.1 127.0.0.1 lo0 16896 2 27 0
syntax
pmtu [-inet6] display/[delete [-dst destination] [-gw gateway] ]
Figure 11-19. Display pmtu Table AU079.1
Notes:
The PMTU command is available to display and delete path MTU discovery related
information. The command can be used to display the Path MTU table. By default IPU4
entries are displayed.
A pmtu entry gets added into the PMTU table when a route add occurs with an MTU value.
A network option, pmtu.expire, is provided to expire unused pmtu entries. The default
value of pmtu.expire is 10 minutes.
The reference count signifies the number of current TCP and UDP applications using this
pmtu entries.
The redisc_t entry signifies the amount of time that is elapsed since the last PMTU
discovery attempt. The PMTU is rediscovered after every pmtu_rediscover_interval
minutes. The default value is 30 minutes.
Instructor Guide
Instructor Notes:
Purpose Introduces the pmtu command.
Details The pmtu command displays and deletes Path MTU discovery information.
Additional Information This command enables a root user to delete a pmtu entry with
the pmtu delete command. The delete can be based on destination, gateway, or both.
Transition Statement Next, lets look at another option using the netstat command to
display the network interface information.

V3.1.0.1
Instructor Guide
Uempty
Display Network Interface Information
# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

lo0 16896 Link#1 1780 0 1800 0 0
lo0 16896 127 127.0.0.1 1780 0 1800 0 0
lo0 16896 ::1 1780 0 1800 0 0
en1 1492 link#2 2.60.8c.2f.b5.a5 1768 0 1861 0 0
en1 1492 9.19.109 9.19.109.4 1768 0 1861 0 0
tr1 1492 link#3 10.0.5a.a8.3a.1f 75039 0 8854 0 0
tr1 1492 9.19.112 9.19.112.7 75039 0 8854 0 0
vi0 0 link#4 0 0 0 0 0
vi0 0 10.19.10 10.19.10.44 0 0 0 0 0
Figure 11-20. Display Network Interface Information AU079.1
Notes:
The interface display format provides a table of cumulative statistics for input and output
errors and collisions as well as total packets transferred. It also shows the interface name
(if name resolution is being used) and address along with the network address and
hardware address of the related adapter. Another important value listed on this report is the
maximum transmission unit (mtu) for the interface. This is the largest size packet this
interface will handle.
Note: The collision count for Ethernet is not supported under AIX.
If the Oerrs column is greater than 1% of Opkts, the send queue size for that interface may
need to be increased. If Ierrs is greater than 1% of Ipkts, then memory may be a problem.
The transmit queue size can be changed via SMIT or the chdev command. The MTU size
can be changed by the ifconfig or chdev commands or through SMIT.
Instructor Guide
Instructor Notes:
Purpose Describe the use of netstat -i.
Details Input errors (lerrs) can be caused by:
malformed packets (damaged by electrical problems)
bad checksums (may indicate a host has a network interface problem and is sending
corrupted packets, or cable is damaged)
insufficient buffer space in device driver.
Output errors (Oerrs) can be caused by:
a fault in the local host connection to the network
prolonged collisions
These errors should be investigated.
When operating through a bridge, the default value of 1500 for Ethernet mtu should be
changed to 1492. The maximum mtu size for 4 mbps token-ring is 4096, for 16 mbps it is
17,792, and for Ethernet it is 1500 bytes.
To change the transmit queue through SMIT you need to change the communication
device (adapter) itself. The fastpath is SMIT chgtok.
The chdev command syntax is:
chdev -l <adpter_name> -a xmt_que_size = <new value>
Additional Information Many of the netstat commands we cover have counters that
are cumulative. There is an option that resets these counters for better analysis. That
option is the -Z option, with:
-Zc Clearing the network buffer cache statistics
-Zi Clearing the interface statistics
-Zm Clearing memory statistics
-Zs To clear protocol statistics. To clear statistics for a specific
protocol, use -p <protocol>. For example, to clear TCP
statistics, enter netstat -Zs -p tcp.
Another useful option to netstat is -a which produces a list of active connections and open
ports.
Transition Statement netstat can be used to monitor activity over time on a specific
interface.

V3.1.0.1
Instructor Guide
Uempty
Monitor State of an Interface
# netstat -I tr1 2
input (tr1) output input (Total) output

packets errs packets errs colls packets errs packets errs colls
75048 0 2818 0 0 795963 0 11855 0 0
1 0 0 0 0 6 0 0 0 0
0 0 0 0 0 7 0 0 0 0
0 0 0 0 0 4 0 0 0 0
0 0 0 0 0 5 0 0 0 0
0 0 0 0 0 9 0 0 0 0
0 0 0 0 0 3 0 0 0 0
0 0 0 0 0 7 0 0 0 0
0 0 0 0 0 6 0 0 0 0
0 0 0 0 0 4 0 0 0 0
Figure 11-21. Monitor State of an Interface AU079.1
Notes:
The netstat -I <network interface> <interval> displays the state of the configured
interface as it is being monitored for traffic across that interface. The interval variable
displays how frequently to display the information. It shows both input and output traffic
along with errors and collisions.
Instructor Guide
Instructor Notes:
Purpose To show how to use netstat to monitor network traffic on an interface.
Details The output information is similar to that provided by netstat -i however netstat
-I shows a summary of statistics for all interfaces on a system, whereas netstat -I shows
the activity as it is occurring on a specific interface.
Transition Statement netstat can also be used to show device driver statistics.

V3.1.0.1
Instructor Guide
Uempty
Display Device Driver Statistics
# netstat -v
TOKEN-RING STATISTICS (tok1) :

Device Type: Token-Ring High-Performance Adapter (8fc8)
Hardware Address: 10:00:5a:a8:3a:1f
Elapsed Time: 7 days 22 hours 56 minutes 6 seconds
Transmit Statistics: Receive Statistics:
Packets: 2817 Packets: 75045

Bytes: 2702128 Bytes: 7077104
Interrupts: 2784 Interrupts: 75038
Transmit Errors: 0 Receive Errors: 0
Packets Dropped: 0 Packets Dropped: 0
Max Packets on S/W Transmit Queue: 10 Bad Packets: 0
S/W Transmit Queue Overflow: 0
Current S/W+H/W Transmit Queue Length: 0
Figure 11-22. Display Device Driver Statistics AU079.1
Notes:
The output from netstat -v shows the statistics about each device driver being used.
The important information that can be obtained from this command is if there is any value in
the S/W Transmit Queue Overflow which would indicate a need for a larger transmit queue
size. To increase the transmit queue use SMIT on the chdev command. Before making the
change be sure to bring down the interface. This can be done with the ifconfig <interface>
down command. Once the change has been made, bring it back up.
The output shown above is only a portion of the output generated with this command.
To change the transmit queue size, use:
SMIT
>Devices
>Communications
>Adapter
>Change/Show Characteristics
Instructor Guide
Instructor Notes:
Purpose Show the use of netstat to see device driver statistics.
Details The device driver has buffers built into it to handle bursts of network traffic.
These buffers are used to queue up transmit and receive requests on the network waiting
for handling by IP (on the receive side) and the device (on the transmit side). If you have
more traffic than the buffers can handle, packets will get dropped. The size of the transmit
queue is configurable. If the Max Packets on S/W Transmit Queue gets close to the
configured size, you may need to increase the number of queues.
Values in the Transmit Errors and Receive Errors fields could indicate a hardware problem.
Looking further at the General Statistics (not shown on the visual) can give some indication
if the problem is hardware related on this machine or on the network (Line Errors).
Additional Information It is also possible to get the same information with the entstat,
tokstat, fddistat and atmstat commands.
Transition Statement Lets see netstat -D which shows the packet count through the
communication subsystem.

V3.1.0.1
Instructor Guide
Uempty
Display Dropped Packets
# netstat -D
Source lpkts Opkts ldrops Odrops
ent_dev0 0 0 0 0
tok_dev0 36356 252 0 0
Device Total 36356 252 0 0
ent_dd0 0 0 0 0
tok_dd0 36356 252 0 0
Drivers Total 36356 252 0 0

.
.
.
Figure 11-23. Display Dropped Packets AU079.1
Notes:
The -D option of netstat displays the number of packets received (Ipkts), transmitted
(Opkts) and dropped (Idrops, Odrops) in the communications subsystem.
The important information seen here are the dropped packets particularly with the device
drivers (dd). If packets are being dropped at the device driver you may want to increase the
queue size on the device driver.
Instructor Guide
Instructor Notes:
Purpose Show important information from the netstat -D command.
Details The output from netstat -D includes more than what is shown. The important
area of discussion is dropped packets on the device driver. Other information included in
the output of this command relates to transmitted, received, and dropped packets for the
daemons, protocols, network interface and NFS. Whenever a value does not apply an N/A
is listed in the output.
Transition Statement If you are still unable to isolate the problem using the previously
covered commands, a trace of network activity may be needed. The iptrace daemon can
be used to do this.

V3.1.0.1
Instructor Guide
Uempty
Trace Packets with the iptrace Daemon
Records Internet packets received from configured interfaces
Can be started as a command or under control of SRC
Can be stopped either with the kill or stopsrc command
Binary output sent to logfile specified at startup
ipreport command used to format the trace file for viewing
Figure 11-24. Trace Packets with the iptrace Daemon AU079.1
Notes:
The iptrace daemon records Internet packets received from configured interfaces. The
options provide a filter so the daemon only traces those packets meeting the filtering
criteria.
Packets are traced only between the local host on which the iptrace daemon is invoked
and the remote hosts unless promiscuous mode is specified.
Output is logged to the file named with the command. The ipreport command is then used
to format the file for review.
Instructor Guide
Instructor Notes:
Purpose Discuss the use of iptrace to trace network traffic.
Details Sometimes the only way to determine what is happening on a network is to run
a trace. In addition, this is a valuable way to view how protocols work together.
The trace captures a lot of information as trace captures traffic coming in and going out a
particular port. It does not capture all traffic on the network unless promiscuous mode is
specified.
The trace logs the collected information into the file specified when starting the trace. This
file grows rapidly. Because of this, you want to specify as many parameters as possible to
prevent the capture of unwanted information.
Additional Information Packet Capture library provides a high-level user interface to
the BPF (Berkeley Packet Filter) packet capture facility. The AIX Packet Capture Library is
implemented as part of the libcap library, version 0.4 from LBNL (Lawrence Berkeley
National Laboratory). The Packet Capture Library user-level subroutines interface with the
existing BPF Kernel extensions to all users access for reading unprocessed network traffic.
By using the 24 subroutines of this library, user can write their own network monitoring
tools.
Transition Statement iptrace has a variety of parameters that can be used to filter out
unwanted information in order to focus on a specific activity. Let's see what some of these
are.

V3.1.0.1
Instructor Guide
Uempty
iptrace Examples
# iptrace -b -d sys4 -s sys3 /tmp/telnet.trace
# startsrc -s iptrace -a "-i en0 /home/team01/iptrace.log"
# iptrace -e /tmp/iptrace.log
Figure 11-25. iptrace Examples AU079.1
Notes:
The trace facility can be started by either executing iptrace as a command or by starting
the daemon using startsrc -s iptrace. In order to stop iptrace, if it was started as a
command then use the kill command. If it was started as a daemon use stopsrc -s
iptrace.
The first example starts iptrace as a command and says to trace all activity destined to
interface sys4 from interface sys3 in both directions and put the output in
/tmp/telnet.trace. The second example says to trace all activity on the en0 interface
placing the output in /home/team01/iptrace.log.
The third example starts iptrace in promiscuous mode. This allows the iptrace daemon to
record all packets on the attached network. The -d option records packets headed for the
destination host; -s records packets coming from the source network interface; and the -b
indicates to record traffic in both directions, coming and going.
Instructor Guide
Additional options that can be used include:

-a do not include ARP packets
-i specifies an interface
-P specifies a protocol like TCP or IP
-p specifies a port like telnet or ftp (or a port number can be used)
-e specifies to trace packets in promiscuous mode (all traffic on the network the
interface can see

V3.1.0.1
Instructor Guide

Purpose Show examples of using the options with iptrace to specify what information is
needed.
Additional Information When gathering information about a problem it is always good
to check the system error log to see if any error against the facilities you are using have
been logged. A complete discussion of error logging is outside the scope of this course.
However, if students ask, the error information can be accessed via the SMIT fastpath smit
errpt or the command: errpt -a.
Promiscuous mode tracing works only if the network adapter supports it. Most Ethernet
cards do but many Token-Ring cards do not.
Transition Statement All the data captured in the world does no good if it can't be read.
The ipreport command is used to convert the binary information captured by iptrace into
human readable form. Let's see how this works.
Instructor Guide
View a Trace Report

# ipreport -n -s /tmp/telnet.trace > /tmp/report1
# pg /tmp/report1
Packet Number 25
TOK: ====( 66 bytes transmitted on interface tr1 )==== 12:59:09.031174400
TOK: 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 0, frame control field = 40
TOK: [ src = 10:00:5a:a8:3a:1f, dst = 10:00:5a:c9:38:3d]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: < SRC = 10.19.109.4 >
IP: < DST = 10.19.111.2 >
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=15770, ip_off=0
IP: ip_ttl=60, ip_sum=5306, ip_p = 6 (TCP)
TCP: <source port=1064, destination port=23(telnet) >
TCP: th_seq=987b2601, th_ack=0
TCP: th_off=6, flags<SYN>
TCP: th_win=16384, th_sum=a746, th_urp=0
TCP: 00000000 020405ac l. . . .
Figure 11-26. View a Trace Report AU079.1
Notes:
Stop the trace using the system resource controller if startsrc was used or use the kill
command if trace was started by command line.
ipreport generates a trace report from a specified trace file originally created by the
iptrace daemon into human-readable form. The iptrace daemon must be stopped before
the ipreport command can be executed.
There are several options that can be used with ipreport. The more commonly used are:
-n Show the packet number at the top of the packet output.
-s Show the protocol to which the information relates at the beginning of each line
of output
-e Generate the report in EBCDIC format. (The default is ASCII.)

V3.1.0.1
Instructor Guide

Purpose Discuss the formatting of the trace collected by iptrace.
Details The iptrace daemon must be stopped before the ipreport command can be
successfully run. ipreport reads the binary packet information and formats it based on the
options supplied with the command.
Tell your students that the key to reading this information is to be able to focus on the
valuable information and ignore the rest. Some hints that may help:
If using Xwindows, make a large window on the screen to see the whole packet on one
screen.
Notice the packet number and whether it is coming in or going out the interface.
Notice which interface is involved.
Look for the hardware and IP addresses involved along with the source and target to
see who is involved in the conversation represented by the packet.
Look to see what the packet is doing, either by the protocol and port involved or what is
shown in the data field. It helps to know what was being executed across the network
during the trace to correlate it to the activity seen in the formatted packet.
The visual shows an example of a single packet. It is very helpful to students to go over
some of the more critical information provided in this packet. If you have a data projector
connected to a terminal in the classroom, you may wish to do a brief iptrace session for
arp or ping and then show the output of ipreport on the screen.
If you use the packet shown on the previous page be sure to point out:
The src and dst hardware address shown under the TOK protocol
The SRC and DST IP addresses shown under the IP protocol
The ip_ttl of 60 seconds in the IP protocol
The source port and destination port in the TCP protocol
The th_seq number, flags, and th_win in the TCP protocol
This packet shows the beginning of a telnet session where the source is attempting to set
up a TCP connection with the destination by sending the SYN.
This packet has no readable data in it as it is the beginning of the three-way handshake to
start a telnet session.
Transition Statement To see how to use some of these tools, let's take a look at what
steps you might take to isolate a communication problem.
Instructor Guide
Sample Problem Scenario
135.9.19.5
sys1 sys8
sys5
5.10.10.1 201.64.23.8
sys2 135.9.19.4 135.9.19.6 sys9

sys4 sys6
5.10.10.2 sys4e sys6e 201.64.23.9
5.10.10.4 201.64.23.6
sys3 sys7 sys10

5.10.10.3 135.9.19.7 201.64.23.10
Subnet Mask = Subnet Mask = 255.255.0.0
255.0.0.0 subnet mask =
255.255.255.0
Figure 11-27. Sample Problem Scenario AU079.1
Notes:
Let's assume that sys5 can telnet to sys8 on network 201.64.23 but not to sys10.
The ping test of the host name sys10 came back with the following message:
ping: host name sys10 NOT FOUND
The ping test of the IP address for sys10, 201.64.23.10 resulted in:
PING 201.64.23.10 (201.64.23.10): 56 data bytes
The result of the netstat -rn command on sys5 showed the following:
Route Tree for Protocol Family 2:
default 135.9.19.4 UG 2 3450 tr0
201.64.23 135.9.19.6 UG 2 2794 tr0
135.9 135.9.19.5 U 2 2759 tr0

V3.1.0.1
Instructor Guide
Uempty The result of the netstat -rn command on sys10 showed the following:
Route Tree for Protocol Family 2:
135.9.19.4 201.64.23.6 UGH 0 0 tr0
201.64.23 201.64.23.10 U 0 0 tr0
/etc/resolv.conf does not exist on either system. However, a review of the /etc/hosts file
on sys5 shows no entry for sys10. A review of the /etc/hosts file on sys10 shows an entry
for sys5.
Given the above information, where do you think the problems lie?
Instructor Guide
Instructor Notes:
Purpose To provide a simple problem scenario so students can see how some of the
commands can be used to isolate a problem.
Details The visual shows three networks with two routers. The problem and the results
of several commands are outlined in the student notes. Step through the output of these
commands with the students soliciting their comments along the way as to what they think
the problem is. In reality, there are two problems. One is the fact that sys10 is not in the
/etc/hosts file on sys5. The other is the way routing is set up on sys10. Ask students what
was it that really got in the way of completing a telnet session. Was it the routing or name
resolution? It really is the routing.
Transition Statement Let's review some items with the checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (1 of 2)
1. Name the two commands that can be used on AIX to display the
characteristics of a network interface.
2. Which command below lists configuration information for a
Token-Ring network adapter on the RS/6000 including the vital
product data?
a. lsdev -C -c tok0
b. lscfg
c. lscfg -v -l tok0
d. lsattr -E -l tok0
3. Which two commands below are the most commonly used and most
useful commands for doing problem determination on a network?
a. arp and host
b. ping and nfsstat
c. ping and netstat
d. spray and no
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details
characteristics of a network interface. lsattr, ifconfig
product data?
a. lsdev -C -c tok0
b. lscfg
c. lscfg -v -l tok0
3. Which two commands below are the most commonly used and
most useful commands for doing problem determination on a
network?
a. arp and host
b. ping and nfsstat
c. ping and netstat
d. spray and no

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (2 of 2)
4. If you want to monitor network traffic across an interface, what
command would you use?
a. netstat -s
b. netstat -i
c. netstat -l
d. netstat -m
5. How do you find out the token-ring speed for tok0?

a. lsattr -E -l tok0
b. lsdev -C -c adapter
c. ifconfig tok0
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details
a. netstat -s
b. netstat -i
c. netstat -l
d. netstat -m

c. ifconfig tok0

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
When debugging a network it is always a good idea to work from a
picture of the network.
A good methodology to use for problem determination is to work
with the layering model of TCP/IP from the bottom up.
Commands that can be used to document the system and network
include lsdev, lscfg, lsattr, ifconfig, ping -R, no, snap.
Commands that are useful to diagnose TCP/IP problems are: ping,
netstat, iptrace.
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty Unit 12. NFS Concepts

This unit introduces the Network File System (NFS) program. It
describes the concepts, terminology, and purpose of NFS.

Define NFS terminology and concepts
Describe the principles of mounting file systems
Identify the NFS daemons and their roles
Describe NFS authentication

Accountability:
Copyright IBM Corp. 1997, 2006 Unit 12. NFS Concepts 12-1
Instructor Guide
Unit Objectives
Define NFS terminology and concepts
Describe the principles of mounting file systems
Identify the NFS daemons and their roles
Describe NFS authentication
Notes:

V3.1.0.1
Instructor Guide

Purpose Introduce NFS concepts
Details In this unit NFS terminology and concepts will be introduced. This should
provide a good foundation for the next unit, Configuring NFS.
Transition Statement Let's begin our discussion by reviewing how users can get
access to data on a different system in a network.
Instructor Guide
Sharing Data on a Network
sys1 sys2
sys3
Data
Figure 12-2. Sharing Data on a Network AU079.1
Notes:
On a TCP/IP network, data can be shared as follows:
Log in remotely with rlogin, telnet and rsh
Transfer files with ftp and rcp
Remote execution with rexec and rsh
Concern in sharing sys3's data with others on the network:
Wasted disk space from transferring copies of files
Keeping all copies of transferred files current
Unnecessary network traffic from transferring large files
Maintaining security on multiple physical copies of files

V3.1.0.1
Instructor Guide

Purpose Describe how data can be shared on a network given what has been covered
so far and list the problems that can arise.
Details We know that we can share data on a TCP/IP network with remote login using
rlogin, telnet, and rsh; transfer files with ftp and rcp and do remote execution with rexec
and rsh.
This works fine but it is not the most efficient way to share data between hosts. If sys3 has
data that sys1 and sys2 need access to, using the TCP/IP commands waste disk space by
remotely copying files from sys3 to one of the other hosts, making it difficult to keep all the
copies current and causing unnecessary network traffic especially if you are transferring
large files.
A mechanism to share one copy of the data across the network would be a better answer.
This allows sys1 and sys2 to have minimal disk space, thus saving money on additional
disks, ensures that only one copy of the file exists, that the file is up to date, and can add
an additional layer of security for sensitive data.
Transition Statement One of the earliest products to be developed that allowed sharing
of files across the network was NFS.
Instructor Guide
Network File Systems (NFS)

File sharing between heterogeneous systems in a TCP/IP network
Transparent access to remote files and directories
Uses client/server technology
NFS Version 4 supported
NFC Client uses version 3 by default
Figure 12-3. Network File System (NFS) AU079.1
Notes:
Network File System (NFS) is a facility for sharing files in a heterogeneous environment of
machines, operating systems, and networks.
NFS is supported over TCP/IP on Local Area Networks. Although NFS functions over any
TCP/IP network, it requires the speed of local area networks to perform file sharing with
acceptable performance.
Sharing is accomplished by building a view of a remote file system, then reading or writing
across the network to the files. Only one copy of a file exists on the NFS network, thus
maximizing file storage availability.
The NFS function is built into the kernel of the operating system so it is transparent to
applications and users.
NFS provides a Client/Server relationship where the server stores files and provides
administration services and the client requests these services.
AIX supports NFS Version 4 as well as NFS Version 2 and 3 protocols.

V3.1.0.1
Instructor Guide
Uempty One or more systems can be configured to provide a range of server functions for a range
of client systems. A system can play both the client and server role with other systems,
providing some services and requesting others.
Instructor Guide
Instructor Notes:
Purpose Define Network File System (NFS).
Details NFS is a distributed file system that allows users to access files and directories
located on remote systems, and treats those files and directories as if they were local. It is
shipped as part of the bos.net package.
NFS was developed by Sun Micro Systems in 1984, and has become the de facto
standard. It has become so popular not only for its efficiency in file sharing but also
because it runs on over 100 different hardware platforms.
AIX NFS also provides enhanced server support for PC-NFS. This is provided by a
daemon called pcnfsd which allows for authentication and print spooling in addition to the
standard NFS function of remote file access.
Additional Information There are two other distributed file systems that were
developed after NFS. They are the Andrew File System (AFS) and the Distributed File
System (DFS). With the spread of the use of NFS it was recognized that there were
problems with large scale management and security. AFS was developed to help address
some of those problems. It implements client side caching, volume management and
Kerberos for authentication of access. It is not, however, a general operating environment
that helps a customer manage a set of applications, systems, and data. DFS in conjunction
with the Distributed Computing Environment (DCE) was developed to address the general
environment of distributed computing. DFS is an extension of AFS that uses the unified
services provided by DCE.
Open Network Computing (ONC +) technology licensed from SunSoft is included under
AIX to meet customer requirements. Included functional components are:
NFS Version 3
NIS+
CacheFS
TIRPC
AutoFS
NFS Version 3 was introduced in AIX 4.2.1, Cache FS was introduced in AIX 4.3.0, Auto
FS was included in AIX 4.3.1, and NIS+ was introduced in AIX 4.3.3.
Cache FS is a local disk cache mechanism for NFS clients. It provides the ability for a NFS
client to cache file system data on its local disk, thereby avoiding network and NFS server
activities. CacheFS increases the clients per server ratio, improving performance for clients
particularly on slow links.
Auto FS provides automatic mounting of NFS file systems. This subject will be discussed
later in this course.
Transition Statement Lets take closer look at NFS V4.

V3.1.0.1
Instructor Guide
Uempty
NFS Version 4
Described in RFC 3530
General security services supported
ACL support
Only TCP supported
Figure 12-4. NFS Version 4 AU079.1
Notes:
NFS Version 4 is supported on AIX as described in RFL 3530. The following features are
included:
Security - NFS V4 can be configured with RPCSEC_GSS to provide stronger security
for the protocol. RPCSEC_GSS is based on the functionality of GSS-API. This allows
for support of multiple security mechanisms without the requirement of adding new RPC
authentication flavors.
ACL Support - NFS V4 defines an ACL model, data types, and provides RPC
operations for passing Access Control List (ACL) specifications between the server and
client. The NFS V2 and NFS V3 are not changed to support any new ACL functionality.
The RPC operations for file locking has been moved into the main NFS protocol. The
Network Lock Manager (NLM) and status monitor in NFS version 2 and 3 are required
to run version 4. However, the rpc.statd and rpc.lockd are required to support NFC V2
and V3 for file locking.
Instructor Guide
Instructor Notes:
Purpose Describe new features in NFS v4.
Details Refer to RFC 3530.
Transition Statement Now, lets position functions with the OSI model.

V3.1.0.1
Instructor Guide
Uempty
NFS Networking Protocols
Application NFS
Presentation XDR
Session RPC Library
Transport TCP or UDP
Network IP
Data Link Ethernet, Token Ring
Physical Ethernet, Token Ring
Figure 12-5. NFS Networking Protocols AU079.1
Notes:
NFS is implemented using RPC and XDR. They provide a level of abstraction between the
application code (for example, NFS protocol) and the underlying network (TCP/IP). By
using RPC and XDR, NFS has been easier to implement on UNIX, non-UNIX operating
systems, and OEM-vendor machines.
RPC and XDR provide an Application Programming Interface (API) to TCP/IP making it
easier to write TCP/IP applications. Their rough position in the OSI reference model is
illustrated above.
eXternal Data Representation (XDR)
Describes protocols in a machine in a system independent way
Provides a data representation standard
Provides data description language
Provides a C language package
Instructor Guide
Remote Procedure Call (RPC)

Provides a mechanism whereby one process (caller) can have another process (server)
execute a procedure call, as if the caller was local to the system.
Simplifies protocol definition, implementation, and maintenance
Provides transparent access to underlying transport for network services
Provides standard message formats for use in specifying higher level protocols
Provides function call semantics for local or remote interprocess communication
Provides a standard I/O library for interprocess communications
RPCs can use either User Datagram Protocol (UDP) or Transmission Control Protocol
(TCP) as the transport protocol for carrying the message data between communicating
programs. TCP transport is used by default.

V3.1.0.1
Instructor Guide

Purpose Describe NFS networking protocols and where it fits in the seven-layer OSI
model.
Details This shows how NFS fits into the OSI protocol model. The model consists of
seven protocol layers stacked on top of each other. Data coming into a machine is passed
from the lowest-level protocol to the highest, and data sent to other hosts moves down the
protocol stack.
The physical and data link layers define a machine's network interface. From the software's
perspective the network interface defines how Ethernet or Token Ring device drivers get
packets from or to the network. The physical layer describes the way data is transmitted on
the network. The data link layer defines how the streams of bits are put together into
manageable chunks.
The network layer defines how packets get between hosts on the network (from point A to
point B). IP moves packets from above to the data link and is also responsible for routing.
The transport layer has two major jobs. First, it subdivides user size data buffers into
network datagrams, and second, it enforces the transmission control such as
reliable/connected with TCP or connectionless with UDP. NFS works mostly on the UDP
transport layer. UDP maintains no state information since it is connectionless, so it is ideal
for repeated or short operations such as RPC. It is up to the application built upon UDP to
determine that a packet was lost and to resend it if necessary. NFS is built mostly on top of
UDP because of its speed and statelessness. While the performance advantages of a fast
protocol are obvious, the stateless nature of UDP is very important. Without state
information in either the client or the server, crash recovery is simple.
The session layer uses something called RPC (remote procedure calls). RPC allows one
program (the client) to ask another program (the server) to do a piece of work for it. RPCs
provide a mechanism for one host (the client) to make a procedure call to another host (the
server) that appears to be part of the local process, but is really executed on another
system on the network. RPC bundles up the arguments passed to the procedure in a
packet. The RPC client creates a session by contacting the server and sends the packet to
the server to execute. On the server the packet is disassembled, the server executes the
result, packages the result, if any, and sends it back to the client in an RPC packet. Using
UDP forces the RPC request to contain enough context information for its execution
independent of any other RPC request since UDP packets may arrive in any order at all.
The presentation layer uses XDR which provides a means for machine-independent
transfer of data. It automatically translates between one machine's internal data format and
another's. This is required in a heterogeneous LAN environment to unify the difference in
data representation.
Additional Information TCP maintains a stateful transmission as it keeps track of
packet delivery and order. Maintaining this information for each connection makes TCP a
stateful protocol. There are many other network services like telnet and ftp that are
referred to as Internet or ARPA services. They are generally based on TCP protocol and
Instructor Guide
are connection-oriented whereby the client establishes a connection to a server and data is
then exchanged in the form of a well-ordered byte stream. There is no need for RPC or
XDR services since the data is byte-oriented and the service defines its own protocols for
handling the data stream. The telnet service has its own protocol for querying the server
about an end of line, terminal type, and so forth. RPC servers are not required to be
connectionless. They can be run over TCP. This is used whenever a large amount of data
needs to be transferred.
RPCs don't use inetd. RPC servers are started at system startup time. There is one server
process for the RPC service and it executes remote requests from all clients one at a time.
There may be many clients of the RPC service, but their requests intermingle in the RPC
server queue and are processed in the order in which they are received. When an RPC call
is made, the client may specify a time-out period in which this call must be completed. If the
server is overloaded or has crashed, or if the request is lost on its way to the server, the
remote call may not be executed before the time-out period expires. This action varies by
application. Some resend RPC calls while others may wait for another server.
Transition Statement RPCs can use either UDP or TCP as the transport protocol. NFS
mostly uses UDP because of its stateless nature. Let's see why this is important.

V3.1.0.1
Instructor Guide
Uempty
Stateless
The NFS protocol is stateless:
Server does not remember anything about transactions
Client is not notified when server is down
No system recovery procedures
NFS Version 4 is stateful
Figure 12-6. Stateless AU079.1
Notes:
NFS uses a stateless protocol. Each remote procedure call contains all of the information
necessary to complete the call and the server does not keep track of any past requests.
Clients must maintain all of this information. They are not notified if the server is down. This
avoids complex crash recovery. A packet is just sent again until the packet gets through.
The connection between client and server is now stateful in NFS V4 while previous
versions of NFS are stateless.
Instructor Guide
Instructor Notes:
Purpose Discuss why UDP was chosen as the transport protocol.
Details The NFS protocol was designed to be stateless to make NFS crash recovery
simple. Statelessness in this context means that the server need not maintain protocol
state information about clients to function correctly. The server does not keep any
information about client requests after they have been performed. Each single transaction
is complete and self-contained or atomic. The parameters to each procedure call contain
all of the information necessary to complete the call.
For example, the server does not maintain any data for a write request by a client. When
the write operation is complete, the data is transmitted from the server to the client. The
server does not need to keep any information about the write requests. This operation is
stateless because the client provides all the information necessary to the server to
complete the write operation.
The stateless protocol is important because crash recovery is implicitly defined within it.
Neither the client nor the server performs any NFS-related crash recovery procedures.
Only when a file operation is attempted does the client realize that the server is
unavailable. At this point the client can decide to retry (the default) or return an error to the
application. When the client retries, the application just waits until the server is available
again. The client doesn't know the difference between a slow server and a server that has
recovered from a crash. If the client crashes, the server has no knowledge of redundant
client requests; so there is no recovery on the server, and the client just starts sending
requests when it recovers from the crash.
The stateless implementation has disadvantages because the server cannot detect if more
than one client is accessing the same data at the same time. This could possibly lead to
data corruption. Most applications (especially databases) require file locking to be available
to protect against this possible corruption.
The Network Lock Manager extension to NFS provides a more stateful environment where
the server and client are in constant communication. The server knows what files the client
has locked. If the server goes down the client can restore those locks.
Transition Statement Let's look at how NFS works.

V3.1.0.1
Instructor Guide
Uempty
Exporting Server File Systems
NFS SERVER
sys3
exporting
/home/files
Exporting = Lists the directories on the NFS

server that clients can access
Figure 12-7. Exporting Server File Systems AU079.1
Notes:
NFS servers export file systems or directories to NFS clients. Thus, the server can control
which areas of its disks are accessible to clients.
Exporting a directory makes the directory available for use by other NFS client hosts on the
network.
Access to exported directories can be restricted to specific clients. (This is discussed in
detail in the next unit).
Instructor Guide
Instructor Notes:
Purpose Define the term export/exporting.
Details To be a server and to make certain resources like file systems and directories
available to the other systems on the network, the NFS server must export what it is
making available. In this example /home/files is being made available. When a directory
on a server is to be made available to remote systems, it must be listed in a file called
/etc/exports. In this file, the server can identify which remote clients will have access to the
directory. Restrictions can also be placed on the level of access remote users have, such
as read/write or read only. This is discussed in greater detail in the next unit.
Transition Statement When a client needs to access a remote directory it needs to
mount it just like it would a local file system. Let's briefly review the concept of mounting.

V3.1.0.1
Instructor Guide
Uempty
Local Mounting
hd4
/ (root)
home sbin lib lpp usr bin dev tftpboot var mnt etc tmp
hd1 hd2 hd9var hd3

/ / / /
bin lib lpp share sbin spool adm tmp
$ mount
node mounted mounted over vfs date options

/dev/hd4 / jfs May 01 03:32 rw,log=/dev/hd8
/dev/hd9var /var jfs May 01 03:32 rw,log=/dev/hd8
/dev/hd2 /usr jfs May 01 03:32 rw,log=/dev/hd8
/dev/hd3 /tmp jfs May 01 03:32 rw,log=/dev/hd8
/dev/hd1 /home jfs May 01 03:33 rw,log=/dev/hd8
Figure 12-8. Local Mounting AU079.1
Notes:
Mount points are locations within a directory tree through which a host accesses mounted
file systems, thus creating the file tree.
Any directory can serve as a mount point.
The mounted column shows what was mounted and the mounted over column shows what
local path is used to access the mount.
Instructor Guide
Instructor Notes:
Purpose Review the concepts of mounting local file systems.
Details When you mount a file system from a local disk onto a mount point, you mount
the entire file system starting at its root. For example, with two file systems, root and usr,
you mount the /usr file system on the /usr directory of the root file system, and you access
it starting from root /usr through the /usr directory. This file system is really one logical but
five physical file systems all connected via directory mount points.
For local mounts the mount table shows the file tree hierarchy as it is connected via mount
point directories.
Transition Statement Standard AIX allows you to mount and unmount only local file
systems. With NFS you can mount remote file systems in the same way.

V3.1.0.1
Instructor Guide
Uempty
Remote Mounting
NFS
Client
/home
/mntpt
sys1
file1 file2
/home
NFS /files
sys3 Exported
Server file1 file2
Figure 12-9. Remote Mounting AU079.1
Notes:
The client can use the mount command with NFS to build a view of a remote file system
located on a server. The mount request is always issued from the client.
The server's exported directory /home/files is being mounted on the client's local mount
point directory /home/mntpt.
If there are directories below the exported directory, they automatically get exported as
well.
However, the export is not valid across file system boundaries - that is, any file systems
below an exported directory are not themselves exported.
Instructor Guide
Instructor Notes:
Purpose Describe the concept of remote mounting.
Details Clients access files on a server by mounting the server's exported files,
directories, or file systems. NFS clients mount directories from NFS servers as if they were
local file systems. Issuing the mount command from the NFS client logically binds the client
to the server. Here the mount command mounts the NFS server's exported /home/files
directory to the NFS client's local mount point directory /home/mntpt. The syntax of the
mount command includes the server node name, a colon and the desired directory. We
cover this in more detail during implementation.
When a client mounts a server directory, it does NOT make a copy of the directory; rather,
the mounting process uses a series of RPCs to enable the client to access directories on a
server's disk.
The kernel builds a mount table which lists all mounted file systems and remote directories.
Every time a file is accessed in the system, the kernel refers to this table to find out where
the data resides and what mechanism to use to access it. This is all transparent to
application programs.
Transition Statement Let's see how the output of the mount command looks after
mounting a remote directory.

V3.1.0.1
Instructor Guide
Uempty
mount Table
# mount

/dev/hd4 / jfs Jun 11 10:56 rw,log=/dev/hd8
/dev/hd9var /var jfs Jun 11 10:56 rw,log=/dev/hd8
/dev/hd2 /usr jfs Jun 11 10:56 rw,log=/dev/hd8
/dev/hd3 /tmp jfs Jun 11 10:56 rw,log=/dev/hd8
/dev/hd1 /home jfs Jun 11 10:56 rw,log=/dev/hd8
sys3 /home/files /home/mntpt nfs3 Jun 11 11:20 rw
Figure 12-10. mount Table AU079.1
Notes:
The host name in the node column is the name of the server.
mounted is the server's exported directory where the data physically resides.
mounted over is the client's local mount point to which the server's exported directory gets
mounted to allow users to access the remote data.
vfs states that the virtual file system type for the remote mount is nfs rather than jfs.
date is the date mounted.
options are the attributes with which the file system was mounted.
Instructor Guide
Instructor Notes:
Purpose Review the mount table with local and remote mounts.
Details Take a look at the mount table. Assuming the mount was successful, we will see
the node column filled in with the NFS server's name. The mounted directory is the server's
exported directory /home/files, which was mounted over the client's local mount point
/home/mntpt. The VFS is NFS, date is the date and time it was mounted, and any options
associated with the mount are listed. Do not cover any options during the lecture. They are
covered in another unit.
Additional Information If the version of the NFS protocol being used is 3 (rather than
2), then the mount command output shows 'nfs3' instead of simply 'nfs'.
Transition Statement Another feature available to enhance performance with NFS is
the CacheFS on the client.

V3.1.0.1
Instructor Guide
Uempty
CacheFS
Server
Back
File
System
Network
Client
Cached
File
System
Figure 12-11. CacheFS AU079.1
Notes:
CacheFS is a local disk cache mechanism for NFS clients. It provides the ability for an NFS
client to cache file system data on its local disk, thereby avoiding use of the network and
NFS server when the data is accessed and is not in physical memory.
CacheFS provides the ability to cache one file system on another.
CacheFS is contained in the bos.net.cachefs fileset, which is not automatically installed
when installing AIX.
CacheFS allows 64-bit operations with files larger than 2 GB.
Instructor Guide
Instructor Notes:
Purpose Describe the purpose and function of CacheFS. This optional function within
NFS client provides increased performance.
Details After creating a CacheFS file system on a client system, the system
administrator specifies which file systems are to be mounted in the cache. When a user on
that client attempts to access files that are part of the back file system, those files are
placed in the cache. Note that the cache does not get filled until a user requests access to
a file or files. Therefore, the initial request to access a file is at normal NFS speeds, but
subsequent accesses to the same file are at local JFS file system speeds.
Additional Information It is important to remember that CacheFS is intended to be
used as a mechanism for reducing network and server workload. Because the remote file
system data is held locally on the client and consistency is only checked at intervals, it
means that the data on the server could change, and the client would be unaware of this for
a period of time. You should, therefore, only use it for read-only or read mostly, file systems
where files systems content does not change rapidly.
Transition Statement Let's take a closer look at what is meant by virtual file system
(VFS) and why this is important.

V3.1.0.1
Instructor Guide
Uempty
Virtual File Systems
Method used to hide underlying storage media from

application and user
Client Server
System Calls
vnode/vfs vnode/vfs
AIX disk NFS client NFS server AIX disk

filesystem routines routines filesystem
disk RPC/XDR RPC/XDR disk
UDP/IP network UDP/IP
Figure 12-12. Virtual File Systems AU079.1
Notes:
AIX uses a structure called a virtual file system (VFS) to define a hardware-independent
mechanism for addressing different types of file systems. This is done inside the kernel so
that applications using the open, close, and so forth, system calls to access files do not
need to be modified.
This VFS structure provides a set of well-known operations that interact with underlying file
systems and objects. These operations define a consistent interface to multiple file
systems, remote or local. This consistent interface allows the user to view the directory tree
as a single entity. It also allows the logical file system code in the kernel to operate without
regard to the type of file system being accessed.
The NFS Server performance is enhanced with the implementation of a vnode cache in the
JFS component of the kernel. The cache enables the NFS Server code to translate a NFS
file handle to a local vnode structure more efficiently.
Instructor Guide
Instructor Notes:
Purpose Describe what the VFS is and what its function is.
Details When a mount is performed (local or remote) a virtual file system structure is
created in kernel memory. When a file is opened, a virtual inode (vnode) structure is
created for that file. A vnode is a file address that contains the inode address that contains
the inode number (local or remote) and a pointer to the structure for the mounted virtual
system in which it resides.
When a process opens a file, the kernel looks in the mount table to determine which file
system the file resides upon and its type. Then the appropriate kernel routines for that
particular virtual file system type run to process the request and generate the vnode
structure for that file.
For a local request the virtual file system is a disk file system and the disk device driver
reads or writes data.
For a remote file system the virtual file system is NFS and a RPC request sent to the
server.
AIX supports four virtual file system types:
jfs (Journaled File System in a Logical Volume)-local
cdrfs (CD-ROM File System)-local
nfs (Network File System)-remote
dfs (DCE Distributed File System)-remote
Additional Information With NFS accesses, the file accessed must be a local file on
the server. The NFS server routines cannot make available to clients, files that the server
has remotely mounted.
Transition Statement Let's now take a look at the daemons and their roles in the
process of accessing remote file systems.

V3.1.0.1
Instructor Guide
Uempty
NFS Daemons
Client
Activity Client Server
mount RPC call portmap
rpc.mountd
open/read biod nfsd

close/write
fcntl() rpc.statd rpc.statd

rpc.lockd rpc.lockd
version 4 nfsrgyd nfsrgyd

client gssd gssd
Figure 12-13. NFS Daemons AU079.1
Notes:
Configuring NFS on clients and servers involves starting daemons that handle the NFS
RPC protocol.
NFS client daemons consist of biod, rpc.statd, and rpc.lockd.
NFS server daemons consist of rpc.mountd, nfsd, rpc.statd, and rpc.lockd.
When an RPC server program initializes, it registers its services with the portmap daemon.
In NFS Version 4, the statd and lockd are replaced in main code of the protocol.
The nfsrgyd daemon provides a name translation services for NFS servers and clients. The
nfsrgyd daemon should be up and running for servers and client using NFS V4 or
RPCSEC-GSS. ggssd daemon, provided under General Security Services allows NFS V4
to use various security method such as kerberos 5.
Instructor Guide
Instructor Notes:
Purpose Introduce the NFS client and server daemons.
Details Use this visual simply as a quick overview of the daemons and their role as
either a client or server daemon. Each daemon is covered in more detail on succeeding
visuals. Each NFS client and NFS server starts their appropriate set of NFS daemons. NFS
daemons handle the NFS RPC protocol.
NFS client daemons are biod, rpc.statd, and rpc.lockd. NFS server daemons are
rpc.mountd, nfsd, rpc.statd, and rpc.lockd. Additionally, all systems start the TCP/IP
daemon portmap.
Transition Statement The first daemon we need to consider in detail is the portmap
daemon because it maintains a listing of the other daemons and how to communicate with
them.

V3.1.0.1
Instructor Guide
Uempty
portmap Daemon
The portmap daemon must run on all systems running

RPC Servers
Client Server
RPC request (mount) Portmap

100005 1 udp
program version protocol port service
100001 2 udp 1026 rstatd
100001 3 udp 1026 rstatd
100002 1 udp 1028 rusersd
100003 2 udp 2049 nfsd
100005 1 udp 795 mountd
100005 1 tcp 797 mountd
Figure 12-14. portmap Daemon AU079.1
Notes:
portmap is a network service that provides clients with a standard way of looking up a port
number associated with a specific program.
When services on a server come up, they register with the portmap daemon as an
available service. portmap then maintains a table of program-to-port pairs. It includes a
program number, version number, protocol to be used, port number and service name.
When the client tries to make a request of the server, it first contacts the portmap daemon
to see where the server resides. The portmap daemon listens on a well-known port so the
client can easily contact it. The portmap daemon responds to the client with the port of the
service that the client is requesting. The client, upon receipt of the port number, is able to
make all its future requests directly to the application.
It is started in /etc/rc.tcpip before inetd and the RPC servers. Thus, when the RPC
servers start they can register with portmap.
Instructor Guide
Instructor Notes:
Purpose Describe the purpose and function of the portmap daemon.
Details Instead of using preassigned ports and the inetd daemon, NFS programs or
RPC services are given program numbers. The file /etc/rpc contains a list of RPC services
and their program numbers. RPC services must still use UDP port numbers, so the
mapping of RPC program numbers to port numbers is handled by the portmap daemon.
When an NFS server is started, the portmap daemon is started from /etc/rc.tcpip. All RPC
programs register with the portmap and be assigned a dynamic port number. An NFS
client contacts the portmap daemon on the server to determine the port number used by
that RPC service. Once the client gets the port number, all subsequent calls by the client
are directed to that port. The port number is cached in memory on the client.
Additional Information The portmap listens on the well-known port of 111. RPC
services cannot afford the overhead of using inetd. The standard inetd services (telnet,
ftp, and so forth) are meant to be used for long periods of connection. RPCs are short in
duration by nature. To find out what RPC services are registered with portmap use the
rpcinfo -p command.
Transition Statement The first request a client would make to portmap would be for
the mountd daemon so it could mount an NFS file system. Let's see how this process
works.

V3.1.0.1
Instructor Guide
Uempty
mountd
Client
Server
mount request portmap (port 111)
1 call to portmap
returns mountd port # 2
rpc.mountd
3 mount request 4
kernel /etc/xtab
OK - passes file handle 5
Figure 12-15. mountd AU079.1
Notes:
mountd is a server daemon and an RPC that answers a client's request to mount a
server's exported file system or directory. The mountd daemon finds out which file system
is available by reading the /etc/xtab file.
The mount process takes place as shown in the diagram:
1. Client mount makes call to server's portmap daemon to find the port number assigned
to the rpc.mountd daemon.
2. portmap passes the port number to the client.
3. Client mount then contacts the server rpc.mountd daemon directly and passes the
name of the desired directory.
4. The server rpc.mountd checks /etc/xtab (built by exportfs -a a command which reads
/etc/exports) to verify availability and permissions on the requested directory.
5. If all is verified, the server rpc.mountd gets a file handle (pointer to file system
directory) for the exported directory and passes it back to the client's kernel.
Instructor Guide
Instructor Notes:
Purpose Describe the purpose and function of the mountd daemon.
Details The mountd daemon is a server-only daemon that answers a client request to
mount a server's exported file system or directory. The mountd daemon reads the
/etc/xtab file to ensure that this client has mount permission, and that the directory is
exported. As shown here, the client issues the mount request and makes a call to the
portmap daemon to find the port that rpc.mountd is waiting on. The portmap returns the
port number. The mount request is now sent to the mountd daemon which reads the
/etc/xtab file, and if the system has permission and the directory is exported, passes a file
handle to the client. The file handle is a point to the actual rpc.mountd directory on the
server.
Transition Statement Once the file system is mounted, the client is ready to make
read/write requests. The daemon that aids in this activity is biod.

V3.1.0.1
Instructor Guide
Uempty
biod (Block I/O Daemon)
biod
read-ahead write-behind
cache
Figure 12-16. biod (Block I/O Daemon) AU079.1
Notes:
The biod daemon improves NFS performance by filling or emptying the buffer cache on
behalf of the NFS client. The daemon provides read-ahead and write-behind function,
bringing data over in chunks (NFS V2 - 8k max, 32k default on NFS V3).
The biod function is performed by kernel threads. These threads are created and destroyed
dynamically. The maximum number of biod threads can be controlled by:
#mount -o biods=n
where n is the number of threads specified. The default is four biod threads per mount
point.
Instructor Guide
Instructor Notes:
Purpose Describe the purpose and function of the biod daemons.
Details biod stands for block input output daemon. biods improve NFS performance by
filling and emptying the buffer cache on behalf of the NFS clients. When a process reads
from an NFS mounted file, it performs the RPC read itself. To prefetch data for the buffer
cache, the kernel has the biod daemon send more RPC read requests to the server, as if
the reading process had requested this data. When a client writes to the file, the data is put
in a buffer cache. After a complete buffer is filled, the operating system writes out the data
in cache (usually 8 Kb). The size of this buffer is configurable at mount time.
Additional Information On the client, any read or write request on a single file system
may, by default, consume up to six biod daemons doing read-ahead (four threads in AIX
NFS Version 3) or write-behind. On clients with multiple file systems mounted over NFS
and multiple users or multiple processes accessing the file systems, it is clear that having
more that six biod daemons may significantly improve performance. Current
implementations allow multiple daemons specified per mount point rather than per client,
giving a fines granularity in being able to control the client-driven load that can be
generated against a particular server. The question that is always asked it How many
daemons should I run? Unfortunately, there is no common agreed or formula for this.
Many references will warn against running too many daemons since having them all
undergo a context switch in order to check the socket to see if there is any work consuming
a lot of CPU. In AIX, this does not matter since SIX NFS employs a wake-up one
mechanism rather than waking up all daemons on a socket.
Current release has defaults of four kbiod threads per mount point for NFS version 3 and
six threads per version 2 mount. The threads are dynamically created and destroyed
according to demands generated against the mount point by the client.
Server daemons are likewise implemented as threads that are created and destroyed
dynamically according to the maximum number that is configured on the server and client
demand for service. The maximum number of threads can be specified either on the
command line at nfsd start time or via the nfso command take place immediately with no
other action required. Since the server only uses as many threads as it can keep busy, you
might increase the thread maximum if a server is primarily doing NFS work.
Transition Statement When a biod daemon on the client makes a read/write request to
a server, a daemon on the server side has to be available to handle that request. That
daemon is nfsd. Let's see how nfsd handles client requests.

V3.1.0.1
Instructor Guide
Uempty
nfsd
Client Server
nfsd
nfsd
file request
nfsd
nfsd
nfsd
nfsd
1
nfsd Threads
2
kernel nfsd
kernel
Figure 12-17. nfsd . AU079.1
Notes:
nfsd is a server daemon that handles client requests for file system operations.
Each nfsd handles one request at a time. When an nfsd is done passing a request to the
kernel, it is free to accept another. This way a server is always able to accept a new nfs
request as long as there is at least one nfsd running.
Threads are dynamically created and are limited by the number specified in the startup file
/etc/rc.nfs or nfso settings.
Instructor Guide
Instructor Notes:
Purpose Describe the purpose and function of the nfsd daemons.
Details Once the directory is mounted, when a client kernel does a file operation, it
sends the NFS RPC information to the NFS server where it is read by one of the nfsd
daemons to process the file request. The nfsd knows how a directory is exported from the
information sent to the server's kernel by the exportfs command. (This command is
covered in the next unit.) These nfsd daemons allow the client to access the directory
according to the permissions.
Additional Information The ps -eaf command can be useful in showing the utilization
of nfsd/biod during a measured period of time.
Transition Statement Let's now take a look at how NFS handles file and directory
authentication when clients make file access requests of servers.

V3.1.0.1
Instructor Guide
Uempty
How NFS Shared Files Are Protected
Mount read-only
UNIX Authorization
Access Control Lists (ACL)
Secure RPC
Lock Manager
RPCSEC - GSS
Figure 12-18. How NFS Shared Files Are Protected AU079.1
Notes:
When the file system is mounted, it could be mounted as a read-only file system. Thus,
even if files have write permission enabled, the access is restricted to simply read only.
ACLs are used to augment the standard AIX permissions.
Secure RPC encrypts the UID and GID (not the data) to stop user impersonation.
Network Lock Manager provides advisory file or record locking via the system calls fcntl()
or lockf().
RPCSEC-GSS option is available to support NFS Version 4 and NFS Version 3. Although
NFS V4 can be configured without RPCSEC-GSS, it is highly recommended.
Instructor Guide
Instructor Notes:
Purpose Discuss shared file protection
Details With the use of shared file systems and directories across a network comes the
question of security. There are many ways to protect a server's exported file systems and
directories. On the visual we have listed six of them.
Transition Statement Let's take a closer look at how standard UNIX authentication
works with files mounted as read/write.

V3.1.0.1
Instructor Guide
Uempty
UNIX Authorization - User
CLIENT
/home
/etc/passwd /mntpt
team01 208, 1...
sys1 team02 209, 1...
team03 210, 2...
file1 file2
RPC request
UID GID
vi /home/mntpt/file1
ls -l /home/files
rwxrw---208, 1 file1
sys3 /etc/passwd
team04 208, 1...
SERVER
Figure 12-19. UNIX Authorization - Users AU079.1
Notes:
Servers and clients exchange the UID and GID of the users trying to access remote files.
Conflicts can arise if the /etc/passwd files are not the same on the servers and the clients.
In the above example, sys1 had mounted /home/files from sys3 and mounted it over
sys1s local mount point directory /home/mntpt.
Example 1 - team01 would like to vi file1. In the RPC request the UID is 208 and GID is
1. team01 has the permissions of rwx (the owner) for file1 on sys3. If team01 does an
ls -l on file1, team01 shows as the owner. If team04 does an
ls -l on file1, team04 is shown as the owner.
1. team02 has the permission of rw (the group) for file1 on sys3.
2. team03 has no permissions for file1 on sys3.
Instructor Guide
In an NFS network, all users should have a unique UID to avoid gaining access to files they
should not have access to. As in team01 and team04's case, sharing the same UID
unknowingly can cause confusion to owners if they are not aware of each other or the NFS
mount. If they have to be concerned with these things then NFS is no longer transparent.
NIS, which we cover shortly, is often used to overcome this problem.

V3.1.0.1
Instructor Guide

Purpose Describe UNIX authentication for users.
Details Once a file system has been remotely mounted, individual file I/O requests are
performed using the NFS protocol. Individual file I/O requests are authenticated by the UID
and GID number of the users on the client. This is passed to the server which will perform
standard permission checks.
Go over the three examples in the student notes. Base each discussion on the UID and
GID as it is passed over the network from the client to the server. Explain that the 208 on
the server is for example purposes. What really shows with the ls -l command is the user
name, but for the sake of this discussion we are showing the UID and GID.
Adding NFS to an existing network can be a lot of up front work as UIDs should be
reassigned so no two people share the same one. As in the case of team01 and team04, if
they do not know about each other and about the NFS mount to /home/files, team04 may
wonder how the new files got created in this directory and may delete them. In turn,
team01 may do the same if team01 owns the file but team01 never created them. When
either team01 or team04 does an ls -l command, their UID is resolved to the name that
appears with that UID in their host's /etc/passwd file. This is why team01 and team04 will
each see their own name when executing ls.
Should there be no UID of 208 in the server's /etc/passwd file, then no name resolution
can take place, and the owner of the file is listed as 208 (providing that user has permission
as group or others to write to that mounted directory).
Another more basic issue that is very important is the permissions on directories. As the
systems administrator, for all exported directories on a server, you must set the correct
permissions on directories and files for user access and in turn set the correct permissions
to keep people out of any files or subdirectories from the mounted file system or directory.
Additional Information On non-UNIX servers the authentication is performed
differently depending on the operating system. Usually, the user must login to the server
before remote mounts can take place.
On non-UNIX clients, access is usually granted without authentication but the client only
gives the user nobody permission to files. Usually a client can log in to the server to gain
extra permission.
Transition Statement The mapping of the root user is different. Let's see how NFS
handles that.
Instructor Guide
UNIX Authentication - Root

CLIENT
/home
/etc/passwd /mntpt
root:!:0:0
sys1
file1 file2
RPC request
UID GID
vi /home/mntpt/file1
ls -l /home/files
sys3 /etc/passwd
nobody:!:-2:-2::/home/nobody:/usr/bin/ksh
SERVER
Figure 12-20. UNIX Authentication - Root AU079.1
Notes:
The root user ID maps onto the /etc/passwd entry of nobody for NFS remote mounts.
This is done to protect the server from security issues that might be breached by the user
with root authority on a client.
Example 1 - root would like to vi file1.
In root's RPC request the UID of 0 but gets mapped to 4294867294 (-2) at the server.
root has no permission for file1 on sys3.
The user nobody owns no files or directories and therefore always has permissions
equivalent to the others category of users.

V3.1.0.1
Instructor Guide

Purpose Describe UNIX authentication for root.
Details The UID of 0, as it gets sent across the network, gets mapped to the UID of
nobody which is 4294867294 (or -2) for obvious security reasons. You wouldn't want every
root user on your network to have full access to every server system.
There are ways to allow a root user on a client to have root authority on a server's
exported directories and file systems as well as a way to completely block access to a
client root user. This is done when the directory or file system is exported. We'll discuss
how to do this in the next unit.
Transition Statement Let's see how ACls are handled.
Instructor Guide
ACL Support in NFS

Access Control Lists are supported between AIX NFS clients and
servers
Implemented with a separate RPC protocol
Figure 12-21. ACL Support in NFS AU079.1
Notes:
The ACL support for AIX NFS clients and servers is implemented as a separate RPC which
defines the get and put procedures for ACLs.
The nfsd daemon handles ACL procedure requests. The client uses the extended RPC
program to obtain the ACL information.
The ACL support is built as a separate function which makes no changes to the NFS
protocol specification.

V3.1.0.1
Instructor Guide

Purpose Describe how NFS provides ACL support between AIX systems.
Details The support for ACLs is provided by RPC program 200006. This program
defines the get and put procedures for ACL. For those NFS servers that do not support
ACLs, the NFS client behaves as if the file it is trying to access is on a CD-ROM file
system. (CD-ROM doesn't support AIX ACLs.) The user does not see a difference in
behaviors if the server doesn't support ACLs unless, of course, the user is specifically
trying to use ACL functionality.
Additional Information Since the default is noacl it has to be manually added either
when issuing the mount command as follows: mount -o acl <args> or by changing the
/etc/filesystems entry. It cannot be specified at file system creation. You may wish to
mention this during the implementation unit.
Transition Statement Let's look at another method of protection NFS can provide files,
locking.
Instructor Guide
NFS File Locking

NFS supports System V file locking as requested by applications
using fcntl(), and lockf() library routines
Uses a separate RPC protocol and two daemons, rpc.lockd and
rpc.statd
Implemented on both the client and server
File locking is stateful
Advisory locking only is supported
Figure 12-22. NFS File Locking AU079.1
Notes:
NFS network locking supports System V record and file locking.
Advisory locking is supported. There is no support for enforced locking.
By record locking, it is meant that an application can be written to lock a type range of a file
rather than the entire file. A lock over the entire extent of the file is a file lock; whereas, a
lock over an arbitrary byte range is called a record lock.
System V locking operations are separated from the NFS protocol and handled by an RPC
lock daemon and a status monitor daemon that creates and verifies information on the
state of the lock.
Always start the rpc.statd before the rpc.lockd when starting and stopping through SRC.
If you do not anticipate using locking, both daemons can be commented out by adding a #
sign in front of each line entry for each daemon in the /etc/rc.nfs file. This prevents them
from automatically starting each time the system is rebooted.

V3.1.0.1
Instructor Guide

Purpose Describe NFS file locking
Details File locking allows one process to gain exclusive access to a file referred to as
file locking or to a part of the file referred to as record locking. It advises other processes
requiring access to the file to wait for the lock to be released. UNIX locks come in two
flavors, BSD and System V. BSD flock() system call exists for local files only, while the
more general System V locks are implemented through fcntl() and lockf() library routines
which use fcntl().
This is advisory not enforced locking, meaning if a program is an ill-behaved program, it
does not pay any attention to the locking messages it receives and will go ahead and
access the file.
An example of an ill-behaved program is vi. vi ignores all messages about locking.
Additional Information The locking support is implemented using the rpc.lockd and
rpc.statd daemons. These two work together to implement stateful locking along with
crash recovery in the event of a client or server failure. The locking information must be
recovered because the locking information kept on the server is not stored in the file
system. When an NFS client or local process obtains a lock, the information is stored in the
NFS server's kernel. If the NFS server fails, the locking information is lost and must be
recovered in order for client applications who depend on the locks to maintain correct
information.
Transition Statement Let's see how a file lock request is handled.
Instructor Guide
NFS File Lock Request

Client
Server
Application Lock
requests
8 /responses
NETWORK
Lock 5 RPC 3
request Lock Lock
1 Manager lockd lockd Manager
2
Lock
Remote operations
files 4
6 6
7
Status
messages
Kernel Kernel
Status RPC Status

Monitor statd statd Monitor
Figure 12-23. NFS File Lock Request AU079.1
Notes:
1. Application does fcntl() lock request.
2. Client kernel sends lock RPC request to its lockd.
3. Lock requests for an NFS mounted file is forwarded by the client lockd to the server
lockd.
4. Server lockd makes a call to the kernel to see if the lock can be granted or denied.
5. Server lockd returns a reply to the client lockd.
6. If the lock is granted, the server lockd asks the status monitor statd to begin monitoring
the client. The client lockd in turn asks its status monitor statd to start monitoring the
server. The file locking daemons and the status daemons keep two directories with lock
reminders in them. Those directories are /etc/sm and /etc/sm.bak.
7. Client lockd returns lock RPC reply to kernel.
8. Kernel returns from fctnl() call.
The rpc.lockd and rpc.statd daemons are network-service daemons, which means they
run at the user level. However, both daemons are essential to the kernel's ability to provide
fundamental network services, and are therefore run on all network machines that use
NFS.

V3.1.0.1
Instructor Guide

Purpose Outline the flow of a lock.
Details Go through the flow of events as listed in the student notes.
NFS is considered stateless, meaning that the clients and servers do not keep track of any
information about what the other side is doing. NFS is stateless, but locking is stateful. The
statds keep track of the state of each other through the use of directories and files /etc/sm,
/etc/sm.bak, and /etc/state.
The rpc.statd daemon is used to maintain state information about NFS servers and clients.
It implements a simple protocol to accept monitoring requests from the rpc.lockd daemon
and to notify monitored hosts in the event the system fails. Because of the interaction
between these two daemons, the rpc.statd should always be started before the rpc.lockd
is started.
The rpc.statd uses the directory /etc/sm to store its state information. It creates a file for
each system that it is supposed to monitor. The file name is the name of the host. The
/etc/sm.bak directory is used to keep track of those hosts not yet notified of server
recovery after the last failure.
Additional Information The following lock recovery information is provided to aid in
handling student questions that may arise regarding lock recovery in the event of failure.
Since locking is built into the application it is really outside the scope of this class. We
provide the high-level information on locking so students are aware of it but there is little a
network administrator can do to implement locking. If you don't seem to have much interest
in locking, continue to the checkpoint questions and summary. If you have interested
students you can do the following board work or simply use the diagram provided on this
visual.
Instructor Guide
NFS File Lock Request

Client
Server
Application Lock
requests
8 /responses
NETWORK
Lock 5 RPC 3
request Lock Lock
1 Manager lockd lockd Manager
2
Lock
Remote operations
files 4
6 6
7
Status
messages
Kernel Kernel
Status RPC Status

Monitor statd statd Monitor
1. rpc.statd reads the host name entries from the /etc/sm.bak file (list of all hosts that it
was monitoring) which was copied from /etc/sm on system reboot.
2. rpc.statd notifies all of the listed systems (including the local rpc.lockd)
Note: When the rpc.lockd starts on the server it is in a grace period which allows
clients to reclaim their locks which by default, is 45 seconds.
3. rpc.statd on the client notifies the rpc.lockd on the client of the server's failure and
recovery.
4. rpc.lockd on the client sends a reclaim lock request to obtain the lock it previously
held for the application
5. rpc.lockd on the server calls to the kernel to obtain the lock request.
6. rpc.lockd on the server responds to the client's rpc.lockd with the success of the
reclaim lock request
When the lock daemon is started the grace period and retransmission time-out variables
can be set to something other than the default. To change the grace period:
/usr/etc/rpc.lockd -g <seconds>

V3.1.0.1
Instructor Guide
Uempty To change the interval between retransmitting lock requests to the remote server from the
default of 15 seconds:
/usr/etc/rpc.lockd -t <seconds>
If a client goes down, the server will be notified, however its lock manager will wait until
contact is resumed before taking action. During this time messages will be sent to the
console indicating client failure. The message is:
rpc.statd cannot talk to statd at client xyz
When the client returns and it is clear that it has been rebooted rather than a temporary
loss of a network connection, the server releases any locks held for that client since any
applications that were running need to restart from scratch and reissue lock requests. If the
client is down for awhile, then you need to manually intervene to clean things up by issuing
the following commands:
# stopsrc -s statd
# cd /etc/sm.bak
# ls
# rm <client name>
# startsrc -s statd
Lock Recovery for Server Failure:

Sequences that occurs after an NFS server
fails and recovers
Client Server
rpc.statd 2 rpc.statd 1
Application
/etc/sm.bak
3 2
Kernel
5
6
rpc.lockd rpc.lockd
lock request
4
Instructor Guide
1. rpc.statd reads the host name entries from the /etc/sm file (list of all hosts that it was
monitoring
2. rpc.statd contacts rpc.statd on servers to notify of the clients failure and it also
contacts the local rpc.lockd to notify of the rpc.statd's failure
3. rpc.statd on the server contacts the local rpc.lockd and notifies it of the client's failure
4. rpc.lockd on the server calls into the kernel and releases all locks that the failed client
held
Transition Statement Let's do a bit of a review by going through some checkpoint
questions.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (1 of 2)
1. T/F: A host can be an NFS server and NFS Client simultaneously.
2. T/F: An NFS mount request is always issued by the NFS client.
3. What server daemon handles client requests for file system
operations?
4. What daemon runs on the client which provides block input/output
operations in order to perform read-ahead, write-behind requests?
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details
True.
True.
operations? nfsd.
biod.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint (2 of 2)
5. What daemons are started on both the client and server systems
used to handle file and record locking?
6. What command is used to see which file systems are currently
mounted?
7. What daemon provides a lookup function on port numbers
associated with a specific program that a user needs to access?
8. T/F: The cacheFS is implemented on the NFS server.
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details
used to handle file and record locking? statd and lockd.
mounted? mount.
portmap.
8. T/F: The cacheFS is implemented on the NFS server. False.

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
NFS clients access network remote files by remotely mounting an
NFS server's exported file systems, directories, or files
The NFS server daemons are portmap, mountd, nfsd, statd, and
lockd
The NFS client daemons are portmap, biod, statd, and lockd
The cacheFS allows caching of files or file systems on a client
NFS authentication includes support for read-only file systems,
Standard UNIX Authorization, AIX Access Control Lists, Secure
RPC, and file and record locking on application request
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty Unit 13. Configuring NFS

This unit introduces the configuration process when implementing
NFS. It discusses the daemons and files that are required on the
server and client. Also covered is the NFS manual mount command
and some basic NFS commands.

Configure an NFS server
Configure an NFS client
Invoke a manual and predefined mount
Stop and start NFS

Accountability:
Exercises
Copyright IBM Corp. 1997, 2006 Unit 13. Configuring NFS 13-1
Instructor Guide
Unit Objectives
Configure an NFS server
Configure an NFS client
Invoke a manual and predefined mount
Stop and start NFS
Notes:

V3.1.0.1
Instructor Guide

Purpose Review unit objectives.
Details This unit covers the steps necessary to configure a server and a client in an
NFS environment.
Transition Statement Let us begin our discussion by looking at the prerequisites for
configuring NFS.
Instructor Guide
Prerequisite Conditions for Implementing NFS

Install and configure TCP/IP
Install NFS
Decide which systems on the network will be NFS servers and/or
NFS clients
Decide which directories are made available to which hosts
Figure 13-2. Prerequisite Conditions for Implementing NFS AU079.1
Notes:
Planning the NFS servers and clients should be done as a paper-planning strategy before
actual configuration is started.
When setting up the network you should consider:
Available disk space - You may have a large server with a large amount of disk space
free or lots of small systems with a little free space each.
Desired availability of data - The clients are dependent on the servers for their files so
the servers should be available as much as possible.
Security - If somebody breaks into the server, all of the clients are affected. Also,
remember the UID and GID for each NFS user on each system should be the same.
Complexity of administration - If every machine is a server and a client it will be very
complex to administer the machines
Network load and performance - Don't put a gateway between a server and its clients
Whether the systems are powerful enough to be both servers and clients.

V3.1.0.1
Instructor Guide

Purpose Cover prerequisites for implementing NFS.
Details To implement NFS, TCP/IP has to be up and running. NFS must be installed on
your system. Paper planning consists of assigning systems to be NFS servers, clients, or
both.
The student notes provide some excellent items that need to be considered during this
planning process.
The AIX package that provides NFS support is bos.net.nfs. The filesets include
bos.net.nfs.adt, bos.net.nfs.cachefs, bos.net.nfs.client and bos.net.nfs.server.
Transition Statement Several methods can be used to implement NFS. Let's see what
they are.
Instructor Guide
Implementation Methods
NFS can be implemented using any of the following:
SMIT configuration
Command line
Flat file configuration
Combination of SMIT and flat file configuration
Only root can configure NFS
Figure 13-3. Implementation Methods AU079.1
Notes:
SMIT is the recommended way to configure NFS. It is important to know what SMIT is
doing for you; therefore, the NFS lectures are presented using the flat file configuration.
The SMIT method is listed in the notes.
NFS does not rely on ODM; therefore, the configuration process is up to the system
administrator.
If SMIT is selected as the method of choice, the menus and dialogs that pertain to NFS can
be reached through the Communications Applications and Services selection in the
main menu of SMIT.

V3.1.0.1
Instructor Guide

Purpose Discuss the four methods of implementation.
Details There are many ways to implement NFS. It can be done via SMIT, from the
command line, flat file configuration, or a combination of all three. Only root can configure
NFS.
Transition Statement No matter which method you choose to use, they all require
taking basic steps.
Instructor Guide
Configuring the Server

Identify what to export
Start portmap and server daemons
Add NFS to system startup
Figure 13-4. Configuring the Server AU079.1
Notes:
Make sure that the portmap daemon is running. The portmap daemon is started in the
same place as TCP/IP daemons, the /etc/rc.tcpip file. The portmap entry appears before
the inetd daemon in this file and must be started before the inetd daemon in order to
function properly. It also must be started before any NFS daemons because the NFS RPC
services of NFS all register with the portmap when they are started.
A server can export either directories, file systems, or files. The network administrator has
to identify each structure to be exported to the server.
The NFS server daemon is nfsd. The administrator configures multiple daemons according
to the expected peak load. There is not a one to one relationship between nfsds and
exported directories or file systems.
NFS can be started under SMIT or from the command line. If NFS is started through SMIT
or through the use of the mknfs command, the portmap daemon is started and all the
other necessary daemons to support either the client or server side of NFS. What
determines whether server or client daemons are started is the existence of the file that
lists the exported directories, /etc/exports.

V3.1.0.1
Instructor Guide

Purpose List the three steps of an NFS server configuration.
Details The steps in configuring an NFS server consist of exporting the file systems or
directories that are available for NFS client use, starting the appropriate NFS server
daemons, and adding the NFS startup script to /etc/inittab.
Depending on your method of NFS implementation, many of these steps are automatically
done for you.
It is critical the portmap daemon gets started before the NFS daemons. If it doesn't, the
daemons won't be able to register with portmap and clients won't be able to connect to the
server. If configuration is done through SMIT or with the mknfs command, this is done in
the proper order. If the manual method is chosen, then it is critical to do this in the right
sequence.
Transition Statement What determines whether a system is functioning as a server is
the existence of the /etc/exports file. Let's see how to create it using SMIT.
Instructor Guide
Identify What to Export

# smit mknfsexp
Add a Directory to Exports List

[Entry Fields]
* Pathname of directory to export [] /
Anonymous UID [-2]
Public filesystem? no +
* Export directory now, system restart or both both +
Pathname of alternate Exports file []
Allow access by NFS versions [] +
External name of directory (NFS V4 Access Only) [ ]
* Security method [sys, krb5p, krb5;, krb5, > +
* Mode to export directory read-write +
Hostname list. If exported read-mostly []
Host + netgroups allowed client access []
Host allowed root access []
Security method
[MORE . . . 19]

Figure 13-5. Identify What to Export AU079.1
Notes:
The full path in SMIT to get to this screen is:
# smit
Communications, Applications and Services
NFS
Network File System (NFS)
Add a Directory to Exports List
This screen allows the following information to be provided:
Full pathname of exported directory
Whether the file system is read/write, read only or read mostly
A list of hosts that is allowed access to the exported directory
What roots access from the client is
If the directory was exported read-mostly, what clients are allowed read/write access
Whether secure NFS should be used
Whether the directory should be exported now, at system restart, or at both times
Whether an alternate exports file (other than /etc/exports) is used

V3.1.0.1
Instructor Guide

Purpose Show students how to export directories using SMIT.
Details When using SMIT the /etc/exports file (or the alternate file if one is specified) is
created. This screen would have to be filled in for every directory path that needs to be
exported. Also, SMIT runs the exportfs -a command after each time the screen is
executed.
Additional Information Netgroups:
The /etc/netgroup file defines network-wide groups. This file is used for checking
permissions when doing remote mounts, remote logins, and remote shells. For remote
mounts, the information in the netgroup file is used to classify machines. For remote logins
and remote shells, the file is used to classify users. Each line of the netgroup file defines a
group and is formatted as follows:
Groupname Member1 Member2 ...
where Member is either another group name or consists of three entries as follows:
hostname, username, domainname
Any of these three fields can be empty, in which case it signifies a wild card. The universal
( , , ) field defines a group to which everyone belongs.
Field names that begin with something other than a letter, digit or underscore (such as -)
work in precisely the opposite fashion. For example, consider the following entries:
justmachines (analytica,-,ibm)
justpeople (-,babbage,ibm)
The machine analytical belongs to the group justmachines in the domain ibm, but no users
belong to it. Similarly, the user babbage belongs to the group justpeople in the domain ibm,
but no machines belong to it.
A gateway machine should be listed under all possible host names by which it may be
recognized:
wan (gateway , , ) (gateway-ebb , , )
The domainname field refers to the domain n in which the triple is valid, not the name
containing the trusted host.
Examples
The following is an excerpt from a netgroup file:
machines (venus, -, star)
people (-, bob, star)
In this example, the machine named venus belongs to the group machines in the star
domain. Similarly, the user bob belongs to the group people in the star domain.
Transition Statement Since the /etc/exports file is created by SMIT, let's take a look at
its format and some sample entries.
Instructor Guide
The /etc/exports File
# cat /etc/exports
/usr/games
/usr/man -ro
/home/files -access=sys1,anon=-1
/budgets -root=sys2:sys3,access=sys2:sys3:sys4,
rw=sys2:sys3
Figure 13-6. The /etc/exports File AU079.1
Notes:
/etc/exports file lists all directories that a server makes available to its clients. Only
exported directories, file systems, or files can be mounted by clients. /etc/rc.nfs, upon
restart, checks for the existence of this file. If the file exists then this system is deemed a
server and the appropriate server daemons are started.
A server can only export its own file systems and directories.
The following are some examples:
/usr/games - Any client on the network can mount this directory.
/usr/man - All clients have read-only access to this directory.
/home/files - Only sys1 has access permission to this directory. anon=-1 disables root
from having access even as the user nobody.
/budgets - The root user IDs on sys2 and sys3 have access as root to this directory.
Access permissions are granted to sys2, sys3, and sys4 with only sys2 and sys3
having read-write access and leaving sys4 with read-only.

V3.1.0.1
Instructor Guide

Purpose Describe the contents of the /etc/exports file.
Details No clients can access files on an NFS server unless the directory containing the
file is exported by the server. The term exporting means making this directory available for
clients to mount and use. This file can be built by using vi or by SMIT. The syntax is very
strict. Go through the four directory examples shown on the visual.
/usr/games is open to the entire network. When nothing follows the entry, the
permissions on the directory are read/write for all systems.
/usr/man directory is being exported as read-only; therefore, no one will be able to write
to this directory. This is one way to keep only one copy of the man pages on the network
and allow everyone to share them.
/home/files is accessible by sys1 only. If there were five systems in this network, the
other four would not have permission to mount this directory. anon=-1 disables root
from accessing a file even as the user nobody. The UID of 0 will be completely ignored,
and root from sys1 will not be permitted on this system.
/budgets portrays that if the UID of 0 comes across the network and wants to use the
/budgets directory, only root on sys2 and sys3 is allowed to access the files as root.
All other root users are mapped to nobody Access is being given to sys2, sys3, and
sys4. Putting the two attributes together, if root on sys4 tries to use /budget, root on
sys4 is mapped to nobody. Read/write for sys2 and sys3 says that they have the
default permission of read/write for this directory, but this also means that sys4, the
other system allowed access, has read-only permission.
Additional Information There are a few restrictions on the structure of this file. You can
have only one entry per directory and you cannot export two directories that are in the
same file system if one is either the parent or subdirectory of the other.
Transition Statement Once this file is created it has to be in a form the kernel can
understand. The exportfs command does this.
Instructor Guide
exportfs Command
/etc/rc.nfs
/etc/exports
1 read
#... /home/files
#...
exportfs -a
2 reply
3 create
/etc/xtab
# exportfs
/home/files
Figure 13-7. exportfs Command AU079.1
Notes:
Control of how a server exports its directories can be done at system restart or as needed
with the exportfs command and its options.
exportfs -a command exports all items listed in the /etc/exports file and automatically
copies the entries to the /etc/xtab file. /etc/xtab file entries are used by the system and
always reflect what is currently exported. This leaves the /etc/exports file available for
updating at any time. exportfs with no options shows you what is currently in /etc/xtab
NOT /etc/exports. root can execute exportfs from the command line using any of the
following options to change what is exported from /etc/xtab:
-a rereads the /etc/exports file and copies all entries to /etc/xtab
-v prints the name of each directory as it is exported or unexported
-u unexports the directories you specify
-i exports directories from the command line that are not found in the
/etc/exports file or ignore the options in the /etc/exports/file
-o specifies optional characteristics for the directory being exported
Note: When SMIT is used to create the /etc/exports file, this command is executed
automatically.

V3.1.0.1
Instructor Guide

Purpose Explain the use of the exportfs command.
Details exportfs can be run at system startup from the /etc/rc.nfs file, as shown in this
example, or it can be done from the command line using the same command of exportfs
-a. This command reads the /etc/exports file and takes the contents and copies it into a file
called /etc/xtab. The kernel reads the /etc/xtab file. This is an advantage as it allows the
system administrator to revise the /etc/exports file during normal hours and issue the
command to change what is exported on the fly.
Issuing the exportfs command by itself shows what is currently exported and being read
by the kernel. This means that you cannot cat out the /etc/exports file and get an accurate
version of what is currently exported, since that information is stored in and read from
/etc/xtab.
Additional Information The exportfs command is not run when using the system
resource controller. This might result in a difference of what is in /etc/exports file and what
the kernel is using.
Transition Statement The next step is to start the nfs daemons. These are started
through the /etc/rc.nfs file.
Instructor Guide
/etc/rc.nfs
# pg /etc/rc.nfs
dspmsg cmdnfs.cat -s 8 1 "starting nfs services:\n"
if [ -x /usr/sbin/biod ]; then
start biod /usr/sbin/biod 8
fi
#
# If nfs daemon is executable and /etc/exports, become nfs server.
#
if [ -x /usr/sbin/nfsd -a -f /etc/exports ]; then
> /etc/xtab
/usr/sbin/exportfs -a
start nfsd /usr/sbin/nfsd 8
start rpc.mountd /usr/sbin/rpc.mountd
fi
#
# start up status monitor and locking daemon if present
#
if [ -x /usr/sbin/rpc.statd ]; then
start rpc.statd /usr/sbin/rpc.statd
fi
if [ -x /usr/sbin/rpc.lockd ]; then
start rpc.lockd /usr/sbin/rpc.lockd
fi
Figure 13-8. /etc/rc.nfs AU079.1
Notes:
NFS daemons are executed from the /etc/rc.nfs file. (This is not a complete listing of the
file.)
SMIT method to start the daemons (which updates the file):
# smit
NFS
Configure NFS on This System
Start NFS (Fastpath: #smit mknfs)
/usr/sbin/biod is automatically uncommented when starting NFS through SMIT; therefore,
NFS servers automatically are configured as NFS clients. If this server NEVER becomes
an NFS client, you may comment out the line associated with the biods so the daemons are
not started.

V3.1.0.1
Instructor Guide
Uempty To activate /etc/rc.nfs manually, use one of the following methods:

# /etc/rc.nfs
Reboot the system.
Once NFS is executed it can be brought down by issuing the following commands:
# /etc/nfs.clean
or
# stopsrc -g nfs
Instructor Guide
Instructor Notes:
Purpose Explain the startup flow of NFS from the /etc/rc.nfs file.
Details This is a sample of the NFS code as it is found in the /etc/rc.nfs startup script.
Let's take a look at how the code is executed. First the system starts the biod daemons. By
default the system assumes that this system is also an NFS client as well as a server. If you
know that this is a dedicated server, you may want to comment out these three lines. Next,
it is determined if this system is going to be the NFS server. It looks to see if the nsfd
daemons are executable, then it checks to see if the /etc/exports file exists. Since our
/etc/exports file does exist, it zeroes out the /etc/xtab file, run the exportfs -a command
which copies the contents of /etc/exports into /etc/xtab. It then starts the nfsd daemons
and the mountd daemon along with the locking daemons, statd and lockd.
Additional Information Although the number of nfsd and biod daemons is specified in
rc.nfs, this is overridden by parameters stored in the ODM. When the number of daemons
is changed using SMIT or with the chnfs command, the number is stored in the ODM using
the chssys command. When the daemons are started, they are passed the number from
the ODM as an argument specifying how many copies should run. See the chnfs script
and the documentation for the chssys command for more details.
Transition Statement The final step is to include the startup of NFS in the system
startup process so the server is available any time the system reboots.

V3.1.0.1
Instructor Guide
Uempty
/etc/inittab
# mkitab "rcnfs:2:wait:/etc/rc.nfs > /dev/console 2>&1"
init:2:initdefault:
brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 # Phase 3 of system boot
powerfail::powerfail:/etc/rc.powerfail 2>&1 | alog tboot > /dev/console # Power
rc:2:wait:/etc/rc 2>&1 | alog tboot > /dev/console # MultiUser checks
fbcheck:2:wait:/usr/sbin/fbcheck 2>&1 | alog tboot > /dev/console # run /etc/fi
srcmstr:2:respawn:/usr/sbin/srcmstr # System Resource Controller
rctcpip:2:wait:/etc/rc.tcpip > /dev/console 2>&1 # Start TCP/IP daemons
rcnfs:2:wait:/etc/rc.nfs > /dev/console 2>&1 # Start NFS Daemons
rchttpd:2:wait:/etc/rc.httpd > /dev/console 2>&1 # Start HTTP daemon
cron:2:respawn:/usr/sbin/cron
piobe:2:wait:/usr/lib/lpd/pio/etc/pioinit >/dev/null 2>&1 # pb cleanup
cons:0123456789:respawn:/usr/sbin/getty /dev/console
qdaemon:2:wait:/usr/bin/startsrc sqdaemon
writesrv:2:wait:/usr/bin/startsrc swritesrv
uprintfd:2:respawn:/usr/sbin/uprintfd
logsymp:2:once:/usr/lib/ras/logsymptom # for system dumps
diagd:2:once:/usr/lpp/diagnostics/bin/diagd >/dev/console 2>&1
Figure 13-9. /etc/inittab AU079.1
Notes:
This step is done for you if you start NFS via SMIT selecting the start at next system reboot
at both options as follows:
# smit
NFS
Start NFS (Fastpath: #smit mknfs)
Use the mkitab command to enter the line into the /etc/inittab file. This command places
the rcnfs entry at the end of the file. The -: Identifier flag can be used to insert the new
record within the initialization table. Make sure the rcnfs entry is placed after the rctcpip
entry. Use the chitab command to change a record in the /etc/inittab.
Instructor Guide
Instructor Notes:
Purpose Identify the nfs entry in /etc/inttab.
Details When configuring NFS via SMIT, the NFS line entry is added automatically if you
request to start at next system reboot or both so NFS is started at each system restart. It
is not necessary to reboot the system to execute this command as you can execute the
/etc/rc.nfs file directly.
The mkitab command adds a record to the /etc/inittab file. The /etc/inittab file supplies
information for the init command to dispatch general processes. It is advisable not to
directly edit the /etc/inittab file but use SMIT or the mkitab command instead because it is
sensitive to stray characters or blank lines and it is critical for the proper reboot of the
system.
Transition Statement Let's look at the flow of activities that occur when a system is
rebooted.

V3.1.0.1
Instructor Guide
Uempty
Activating an NFS Server
ODM
System
Powered
on Config_Rules
.
.
.
/etc/rc.net
.
.
.
cfgmgr portmap
inetd
/etc/inittab
.
.
.
run-time rctcpip:/etc/rc.tcpip
init rcnfs:/etc/rc.nfs /etc/rc.nfs
.
.
.
System biod exportfs -a nfsd mountd statd lockd

Ready
for login
/etc/xtab
Figure 13-10. Activating an NFS Server AU079.1
Notes:
The cfgmgr calls /etc/rc.net during the second phase of configuration during a system
restart. Next /etc/inittab kicks off /etc/rc.tcpip followed by /etc/rc.nfs. From this point on,
/etc/rc.nfs executes all the appropriate daemons for the server.
By default, the two locking daemons, locked and statd, are started along with the biod and
nfsd. Also, the mountd is started to handle requests and the exportfs command is run
creating the /etc/xtab file.
Instructor Guide
Instructor Notes:
Purpose Show the startup of an NFS server.
Details This is a diagram of a system restart.
By default, eight biods will be started before the /etc/exports file is checked. If you
absolutely do not want this server to be a client, the lines supporting the biods in the file
/etc/rc.nfs should be commented out. This may cause problems. If in the future you want
this server to be a client, you must remember to uncomment these lines to get the biods
started on every system restart. Also the locking daemons, statd and lockd, are started.
Transition Statement That's all there is to configuring an NFS server. Let's now turn
our attention to configuring an NFS client.

V3.1.0.1
Instructor Guide
Uempty
Client Configuration Steps
The tasks that must be performed to configure each system
designated as an NFS client are:
Use the mkdir command to establish the local mount points
Start the NFS client daemons
Mount the desired directories
Figure 13-11. Client Configuration Steps AU079.1
Notes:
The above steps are discussed in detail on the following pages.
The prerequisite conditions are the same for an NFS client as they are for an NFS server.
They are:
Install and configure TCP/IP
Install NFS
Instructor Guide
Instructor Notes:
Purpose Identify the steps in configuring an NFS client.
Details There are three steps to configure an NFS client. You must use mkdir to
establish the empty mount point directories, start the client daemons, and issue the mount
command to invoke an NFS mount.
Transition Statement Let's look at the first step, create the local mount points.

V3.1.0.1
Instructor Guide
Uempty
Create Local Mount Points
Create the local mount points for the NFS file systems:
mkdir dirname
For example:
# mkdir /home/mntpt
Figure 13-12. Create Local Mount Points AU079.1
Notes:
For NFS to complete a mount successfully, a directory that acts as the mount point for an
NFS mount must be present. This directory should be empty. It acts as the placeholder for
the NFS mount that is to occur.
The local mount point can be created like any other directory using the mkdir command.
There are no special attributes needed for this directory.
If the directory mount point is not empty and an NFS mount takes place using this mount
point, its local files and subdirectories are hidden until the NFS mount is ended.
Instructor Guide
Instructor Notes:
Purpose Review the concept of a mount point.
Details NFS provides the ability to access directories and files that reside on a remote
system through the NFS mount process. (The location within a directory tree through which
a client accesses remote directories are called mount points.) Mount points are empty
directories that can be created using the mkdir command. If the mount point directories are
not empty and an NFS mount takes place, all files located in that mount point will be hidden
and will not be accessible until the NFS mount is ended. They are sometimes referred to as
stubs or stub point directories.
Transition Statement The next step is to start the necessary client daemons.

V3.1.0.1
Instructor Guide
Uempty
Start NFS Client Daemons
# smit mknfs
Start NFS
[Entry Fields]
* START NFS now, on system restart or both
Figure 13-13. Start NFS Client Daemons AU079.1
Notes:
The client daemons can either be started through SMIT as shown above or by
uncommenting the appropriate lines in the /etc/rc.tcpip and /etc/rc.nfs files and then
running the scripts as described earlier for starting server daemons. The daemons that
need to be started are:
portmap biod rpc.statd rpc.lockd
biod
rpc.statd
rpc.lockd
Instructor Guide
Instructor Notes:
Purpose Show the procedure that can be used to start the client daemons.
Details The procedure choices are the same for both the client and server. SMIT, the
high-level commands, or manually editing and running the scripts can be used with equal
effectiveness.
Transition Statement The next step is to mount the exported directory. There are
several ways to do this. The first way we discuss is manually.

V3.1.0.1
Instructor Guide
Uempty
Manual Remote Mount
# mount sys3:/home/files /home/mntpt
sys1 sys3
/ /
home home
mntpt files
file 1
file 2
NFS Client NFS Server

Mount Point Exported Directory
Figure 13-14. Manual Remote Mount AU079.1
Notes:
Manual mounts (explicit) require, as a minimum, the server's host name, absolute path
name of the remote directory and the path name of the local directory mount point. Only
root or a member of the system group can issue the mount command for mounting a file
system.
Client configuration with the above example:
Daemons required to be active - biod
Default remote file system - NFS (as listed in the /etc/vfs file)
Local mount point established with mkdir - /home/mntpt
Client issues the manual mount command - # mount sys3:/home/files /home/mntpt
If nfs is not designated as the default remote file system in the /etc/vfs file then the
mount command from the command line would use the -v nfs option as follows:
# mount -v nfs sys3:/home/files /home/mntpt
Instructor Guide
It is recommended, and required if you are using locking, to have the portmap daemon
active on the client to handle requests from any NFS networking command issued from
another host.
Server configuration
- Proper directories and/or file systems exported in /etc/exports - /home/files
- Daemons required to be active - portmap, inetd, nfsd, rpc.mountd.

V3.1.0.1
Instructor Guide

Purpose Describe the syntax of the mount command.
Details Using the manual mount command explicitly requires that the user provide all
the information on the command line to mount the proper directory. At a minimum, the user
must provide the server's host name, associated pathname of the remote directory, and the
pathname of the local directory that is to be used as the mount point. All other options used
by NFS can be specified on the command line.
When NFS is installed the system adds an entry in the /etc/vfs file for the default remote
file system. If this doesn't occur, then the file could be edited manually by uncommenting
the following line and including nfs as the second parameter:
%defaultvfs jfs nfs
If this is not done, you can still mount an NFS file system by using the -v nfs option with the
mount command as shown in the student notes.
Transition Statement Now, let's look at cacheFS option.
Instructor Guide
Manual cacheFS Mount

Create the local cache
Mount the back file in the cache
Server Client
Back Cached
File File
System System
Figure 13-15. Manual cacheFS Mount AU079.1
Notes:
To ensure that the cached directories are kept up to date, cacheFS periodically checks the
consistency of files stored in the cache. To check consistency, cacheFS compares the
current modification time to the previous modification. If the modification times are different,
all data and attributes for the directory or file are purged from the cache, and new data and
attributes are retrieved from the back file system.
When a user requests an operation on a directory or file, cacheFS checks if it is time to
verify consistency. If so, cacheFS obtains the modification time from the back file system
and performs the comparison.

V3.1.0.1
Instructor Guide

Purpose Describe the two steps involved in setting up a cached file system.
Details 1) Create the local cache. Command line input or smit can be used to create the
local cache. 2) Specify and mount the file system to be cached. Also, cover the consistency
check described in the student notes.
Additional Information Optionally, when the server has a very large file system to be
served out, a dedicated JFS can be used to store the local cache on the client.
Transition Statement Now, let's take a look at the cfsadmin and mount commands
that are used to activate caching.
Instructor Guide
cfsadmin Command
# cfsadmin -c -o <parameters><cache-directory>
Example: # cfsadmin -c /cachefs
# mount -V cachefs -o backfstype = nfs,cachedir =\

/<cache-directory> remhost <remote-directory>\
<local-mount-point>
Example: # mount -V cachefs -o backfstype=nfs,\

cachedir=/cachefs/cachedir sysY:/home/cachedir\
/cachefs/cachedir
Figure 13-16. cfsadmin Command AU079.1
Notes:
The cfsadmin command provides the ability to:
Create and delete cached file systems
List cache contents and statistics
Change cacheFS response parameters
The following cfsadmin options are available:
-c Creates a cache under directory specified by cache-directory. The directory
must not exist prior to cache creation.
-d Removes file systems specified by cached and releases its resources or
removes all file systems if all is specified.
-l List file systems stored in the specified cache with their statistics.
-s Requests a consistency check on the specified file system, or all file
systems, if all is specified.

V3.1.0.1
Instructor Guide
Uempty -u Updates resource parameters of the specified cache directory. Note that
parameter values can only be increased; decreasing requires cache
removal and recreation.
-o cacheFS resource parameters.
The resource parameters are:
maxblocks=n Maximum amount of storage. Default=90%.
minblocks=n Minimum amount of storage. Default=0%.
threshblocks=n Percentage of total blocks. Default=85%.
maxfiles=n Maximum number of files allowed. Default=90%.
minfiles=n Minimum number of files allowed. Default=0%.
threadfiles=n Percentage of total inode. default=85%
maxfilesize=n Largest file size (megabytes). Default=3.
Instructor Guide
Instructor Notes:
Purpose Describe the usage of the cfsadmin command. The execution of this
command is needed to invoke the mount command for mounting of NFS file.
Details When creating cache using the cfsadmin command, you can specify resource
parameters to override the defaults as described in the student notes. The cache directory
is the name of the directory where the cache should be created. Although the cache is
referred to as a cache file system, it is not a file system in the true sense. It is a cache
directory that resides on a normal JFS. For this reason, if you are creating a large cache file
system, it is advisable to create a dedicated JFS to be used for this purpose. This is
because the cache file system is created with parameters that indicate the percentage of
underlying file system it is allowed to use.
Additional Information The fsck_cachefs command checks the integrity of cached file
systems. By default, it corrects any cacheFS problems it finds. Unlike the standard fsck
command there is no restrictive mode.
Transition Statement You may wonder when a manual mount should be used since
only root or a member of the system group are permitted to use the command.

V3.1.0.1
Instructor Guide
Uempty
Why Do Manual Mounts?
For occasional or unplanned mounts
For security or tight control of NFS file systems
For system administration purposes
If server is not available at system startup, mounts can be done
manually when the server becomes available
Figure 13-17. Why Do Manual Mounts? AU079.1
Notes:
Manual mounts are explicit mounts and are invoked using the mount command from the
command line.
Using the mount command explicitly requires that the user provide all the information on
the command line to mount the file system. You must be root or a member of the system
group to perform a manual mount.
The syntax of the manual mount command is:
# mount server_name:/exported_directory /local_mount_point
# mount sys3:/home/files /home/mntpt
Manual mounts should not be used when remote file systems are needed by client systems
for their normal operations.
Instructor Guide
Instructor Notes:
Purpose Describe the characteristics of a manual mount.
Details The mount and umount commands explicitly mount and unmount a file system
or directory. The mount command is useful for directories that are accessed for only a
short amount of time. It requires the server to be available, and the server must be
exporting the stated directory. File systems accessed through mount commands stay
mounted until a system reboot, unless you unmount them with the umount command. If
the system is restarted, the mount will no longer be in effect unless a predefined mount was
defined in the /etc/filesystems file.
Transition Statement Another way clients can mount NFS file systems is with
predefined mounts. Let's see what these are.

V3.1.0.1
Instructor Guide
Uempty
Predefined Mounts
Predefined NFS mounts are:
Mounts that are usually required for proper operation of a client
Automatic at system startup
Defined in /etc/filesystems
Multiple mounts can be invoked simultaneously
Figure 13-18. Predefined Mounts AU079.1
Notes:
Predefined mounts are referred to as implicit mounts. They are probably the most common
way to perform NFS mounts.
It is possible to invoke a predefined mount from the command line rather than invoke it
through /etc/rc.nfs. Use the mount command and the local_mount_point name. The mount
command uses the local_mount_point to locate the corresponding stanza in the
/etc/filesystems file. This stanza is then used to supply the needed information to
complete the mount.
Predefined mounts are achieved by adding the appropriate entry to the /etc/filesystems
file and are invoked at a system restart.
Instructor Guide
Instructor Notes:
Purpose Describe the characteristics of a predefined mount.
Details Predefined mounts are useful for creating a long-lived NFS environment of
remote mounts. Predefined NFS mounts refer to the remote directories that are mounted
upon system restart. Predefined mounts can also be invoked via the command line as
mentioned in your student notes.
Transition Statement Let's see how to create a predefined mount using SMIT.

V3.1.0.1
Instructor Guide
Uempty
Creating Predefined Mounts
# smit mknfsmnt
Add a File System for Mounting

[TOP] [Entry Fields]

* PATHNAME of mount point [] /
* PATHNAME of remote directory []
* HOST where remote directory resides []
Mount type NAME []
* Use SECURE mount option? no +
* MOUNT now, add entry to /etc/filesystems or both? now +
* /etc/filesystems entry will mount the directory no +
on system RESTART.
* MODE for this NFS file system read-write +
* ATTEMPT mount in foreground or background background +
NUMBER of times to attempt mount [] #
Buffer SIZE for read [] #
Buffer SIZE for writes [] #
NFS TIMEOUT. In tenths of a second [] #
NFS version for this NFS filesystem any +
Transport protocol to use any +
Internet port NUMBER for server [] #
[MORE...22]

Figure 13-19. Creating Predefined Mounts AU079.1
Notes:
The full SMIT path to get to the above screen is:
# smit
Communications, Applications and Services
NFS
Add a File System for Mounting
This SMIT path can be use for creating an NFS file system for both an entry in the
/etc/filesystems file or simply for a one-time mount. Thus, it can be used in place of the
mount command previously shown when the field for mount is specified as now.
When this field is specified to add the entry to the /etc/filesystems file, that file gets
updated with the information provided in this screen.
Note: This visual does not show the entire screen.
Instructor Guide
Instructor Notes:
Purpose Show the SMIT screen that creates a predefined file system.
Details As indicated in the notes, this screen can be used to set up a manual mount or a
predefined mount simply by the way the question: MOUNT now, add entry to
/etc/filesystems or both? is answered.
Transition Statement Since the use of SMIT adds entries to the /etc/filesystems file,
let's take a look at how this file is set up.

V3.1.0.1
Instructor Guide
Uempty
The /etc/filesystems File
# cat /etc/filesystems
/home/fred/jobs:
dev = "/u/judy/jobs"
mount = true
vfs = nfs
nodename = sys2
option = soft, bg
/home/mntpt:
dev = "/home/files"
mount = false
vfs = nfs
nodename = sys3
option = bg, hard, intr
account = false
Figure 13-20. The /etc/filesystems File AU079.1
Notes:
Using the SMIT method described previously, you have the choice of having the file system
mounted immediately, at system restart, or both. Adding an entry to /etc/filesystems
manually means that you must either invoke the predefined mount from the command line
or do a system restart. To remove an entry, use an editor or SMIT.
The attributes required are:
dev = specifies the path name of the remote file system being mounted
vfs = specifies that the virtual file system being mounted is an NFS file system
nodename = specifies the host system on which the remote file system resides
mount = choices are true, false, automatic. If you use true, be sure mount options are
for a background mount, otherwise the client may hang on system restart if the server is
down.
options = optional attributes you can assign to the mount. These will be defined on the
next page.
account = used by the dodisk command to determine the file systems to be processed
by the accounting system. The value is true or false.
Instructor Guide
Instructor Notes:
Purpose Describe the use of /etc/filesystems and /etc/rc.nfs files with predefined
mounts.
Details To have mounting take place automatically at system startup, use the
/etc/filesystems file to describe each NFS local mount point you have created and where
the server data is coming from. Information included in a remote mount file system stanza
is the same information required for a manual mount. The name of the stanza in this
example is /home/mntpt, which is the name of the client local mount point. It must end with
a colon or this entire stanza is not read upon system startup. The attributes must be
indented and there must be spaces around the = signs. The dev attribute is used to
describe the full path name of the exported file system or directory on the server that needs
to be mounted to the client's local mount point. Nodename is the host name of the remote
server. VFS specifies that this stanza is an NFS remote mount rather than a local mount.
By default, when the /etc/filesystems file is created, the mount = false attribute is used.
This means that the NFS remote mount must be invoked from another startup file like
/etc/rc.nfs. You can change this value to true, however either way it is done to avoid a
potential hang if a client is restarted when a server is down, the background mount option
needs to be set.
Additional Information Another way to set up a predefined mount is to specify the file
system in the /etc/filesystems file and set the mount= attribute to false. Then, add a mount
statement for the nfs file system at the end of the /etc/rc.nfs script. If you do this make sure
the bg option (background mount) is set up or a hang could occur as well.
There is an undocumented attribute with the /etc/filesystems file that can be used with
NFS file systems. It is the free attribute that takes a value of rue or false. If set to true
commands that provide file system information, such as the df command, do not hang if an
NFS file system operation is put into the background due to problems encountered with
contacting the server.
Transition Statement The /etc/filesystem file provides for many mount options to be
specified. Let's look at what some of them are.

V3.1.0.1
Instructor Guide
Uempty
Options Attributes
Option Function Default

bg Mount attempted in background if first attempt fails
fg All mount attempts done in foreground Yes
soft Repeated RPC calls eventually timeout
hard RPC calls try indefinitely until server responds Yes
intr Allows KB interrupts to halt hard attempts
retry=# Set the number of times to try the mount 1000

Number of times to repeat an RPC request before
retrans=# 3
returning timeout error on soft mounts
timeo Varies RPC timeout period in tenths of second 7
ro Mounts read-only
rw Mounts read-write Yes
ver=<version> Choose NFS protocol version (2 or 3) 3
proto=<protocol> Choose transport protocol (TCP or UDP) TCP
biod=n Sets maximum number of threads 4
Figure 13-21. Options Attributes AU079.1
Notes:
bg, fg - Specifies whether the mount should be attempted in the background or the
foreground if the first mount attempt fails.
hard, soft - Determines whether the client continues indefinitely (hard) or time out (soft)
if the server is not reachable.
intr - Allows a mount defined as hard to be interrupted by using any of the keyboard
interrupt keys. This is very nice to have available if the server or the network is down
and you restart a client.
retrans, timeo - retrans specifies the number of times to repeat an RPC request before
returning a time-out error on a soft mount. The timeo parameter varies the RPC
time-out period and is given in tenths of a second.
retry - Determines the number of soft mount attempts before timing out.
ver - Selects the version of the NFS protocol to use. The default is the highest level (2
or 3) available on both client and server.
proto - Selects the transport protocol to use, UDP or TCP. The default is TCP.
biods - Controls the number of threads per mount point. The default is four Kbio (biod)
threads per mount point.
Instructor Guide
Instructor Notes:
Purpose List the most frequently used options for mounting a remote file system or
directory.
Details This is a limited list of some of the more popular options that can be defined with
a predefined NFS mount. See the Commands Reference Manual for a complete list of the
options and how they are used.
When a client cannot mount a server during the allotted RPC execution time, it tries the
RPC operation up to the count specified by the retry option. If bg option was used, mount
starts another process that continues mount retries in the background. This frees up the
system to allow the mount command to attempt the next mount operation or have other
commands run. If bg is not specified, mount blocks or waits for the remote file server to
recover or until the mount retry count has been reached. Use of bg mounts allows your
network to recover more gracefully from widespread problems such as power failures.
Hard/soft determines how a client behaves when the server is overloaded and can't
respond, or when it is not reachable. By default, file systems mounted hard means that an
RPC call that times out is retried indefinitely until a response is received from a server.
A hard mount side affect is the mount waits or hangs until the RPC call can complete.
Using intr and hard allows users to interrupt system calls that are waiting on a crashed
server.
Soft mounts with repeated RPC call failures eventually cause the NFS operation to fail as
well. Soft shouldn't be used on a file system that is write intensive. NFS only guarantees
consistency of data after a server crash if the NFS file system was hard mounted. System
calls referring to soft-mounted file systems look like failing disks and return errors.
Sometimes the error is just ignored.
A file system or directory can be mounted read-only or read-write. A good example of
read-only might be the man pages or a bulletin board.
The timeo option deals with how long a client waits for a response from a server before
timing out and retransmitting the request. The retrans option specifies how many times the
client will retransmit after a time-out before returning an error on a soft-mounted filesystem.
If it is a hard-mounted file system it will retry indefinitely.
The proto option allows the transport protocol for NFS to be selected in AIX 4.2.1 and later.
By default, TCP will be used if the server supports it.
Additional Information When two servers are clients of each other, the bg option must
be used in at least one of the server's /etc/filesystems file. When both servers boot at the
same time (due to power failure as an example) one usually tries to mount the other's file
systems before they have been exported and before NFS has been started. If both servers
are fg only, there is a deadlock as they wait for each other. When both servers finally
complete booting, the bg mount completes successfully. If some events cause client and
server to reboot at the same time and the client can't complete the mount before the retry
count is exhausted, the client won't mount even when the server comes back up. Many

V3.1.0.1
Instructor Guide
Uempty have to manually remount. Once the retry limit has been reached, the not responding
message appears.
Transition Statement Let's see how the type = attribute works on a predefined mount.
Instructor Guide
Predefined Mounts
Invoked From Command Line
/etc/filesystems
/home/mntpt:
# mount /home/mntpt dev = "/home/files"
nodename = sys3
vfs = nfs
# mount -t budget mount = false
/report:
dev = "/home/finance"
nodename = sys2
vfs = nfs
type = budget
mount = false
/status:
dev = "/home/monthly"
nodename = sys4
vfs = nfs
type = budget
mount = false
Figure 13-22. Predefined Mounts Invoked From Command Line AU079.1
Notes:
The type attributes used in /etc/filesystems gives you an option of performing multiple
mounts that are defined under a command type. The command mount -t budget could
also be added to the /etc/rc.nfs file so these mounts occur at system startup.
The mount all command can be used from the command line but it only reads and mounts
stanzas marked mount = true from /etc/filesystems.

V3.1.0.1
Instructor Guide

Purpose Describe other methods of invoking a predefined mount.
Details Predefined mounts can be invoked from the command line by either specifying
the local_mount_point directory name or by the -t <typename> option. Both cause the
/etc/filesystems file to be read and scanned by a match to the options used with the
mount command.
The -t option looks at all stanzas in the /etc/filesystems file for the type= attribute. All file
systems with an attribute type = budget, in this example, are mounted. It is a way to
perform multiple mounts with one command. This option can be helpful when working with
multiple file systems or directories that are related. For example, when working on all
budget reports on the 30th of each month, they all can be mounted or unmounted using the
mount or umount -t budget commands.
There may be times when you have added information to the /etc/filesystems file, and you
do not want to restart the system to get any predefined mounts. Predefined mounts can be
activated from the command line. One advantage of using SMIT to add file systems to
/etc/filesystems is it gives you the option of performing the mount automatically, at system
restart, or both.
Transition Statement Let's look at the flow of activities that occur when a system
configured as an NFS client is rebooted.
Instructor Guide
Activating an NFS Client
ODM
System
Powered
on Config_Rules
.
.
.
/etc/rc.net
.
.
.
cfgmgr portmap
inetd
/etc/inittab
.
.
.
run-time rctcpip:/etc/rc.tcpip
init rcnfs:/etc/rc.nfs /etc/rc.nfs
.
.
.
System biod rpc.statd rpc.lockd

Ready
for login
Figure 13-23. Activating an NFS Client AU079.1
Notes:
When the system executes /etc/inittab, /etc/rc.nfs is called which starts the NFS client
daemon biod.
Note that portmap and inetd should also be active on an NFS client in order to have the
NFS client participate in requests from general NFS networking commands.

V3.1.0.1
Instructor Guide

Purpose Show the startup of an NFS client.
Details As with the server, /etc/rc.net will configure the network. TCP/IP starts from
/etc/rc.tcpip which is executed from /etc/inittab before the NFS file /etc/rc.nfs is called to
execute. Note that this drawing shows the portmap and inetd daemons active on this NFS
client. There are some general NFS networking commands that talk to corresponding NFS
networking commands that need to be registered with all portmaps in order to participate in
the information requested from the commands. They are discussed later. The only
daemons needed are the six biods and by default the rpc.statd and rpc.lockd locking
daemons.
Transition Statement There are several commands that can be used to manage NFS
daemons. They are the SRC commands.
Instructor Guide
Using SRC to Manage NFS Daemons
Daemons and their subsystems

File Path Subsystem Name Group Name
/usr/sbin/nfsd nfsd nfs

/usr/sbin/biod biod nfs
/usr/sbin/rpc.lockd rpc.lockd nfs
/usr/sbin/rpc.statd rpc.statd nfs
usr/sbin/rpc.mountd rpc.mountd nfs
/usr/sbin/portmap portmap portmap
Figure 13-24. Using SRC to Manage NFS Daemons AU079.1
Notes:
All NFS daemons have been placed under the control of SRC. They can be managed from
the command line to temporarily stop, start, or simply list the daemons using the
commands stopsrc, startsrc, Issrc, and their appropriate flags. Examples might include:
# stopsrc -s mountd stops just the rpc.mountd
# startsrc -s mountd starts the rpc.mountd
# stopsrc -g nfs will stop all the nfs daemons listed under the group name of nfs This
will stop NFS by bringing down all its daemons.
# Issrc -g nfs will list all the active and inactive daemons from the nfs group
Refer to the Commands Reference Guide for other flags that can be used with these
commands.

V3.1.0.1
Instructor Guide

Purpose Explain the role of SRC and NFS.
Details Most daemons are controlled by SRC and should be managed through SRC.
The correct subsystem name or subsystem group must be used with the commands. You
should become familiar with those that do and do not belong to a group. For instance,
portmap does not belong to the nfs group even though it is used to map nfs programs to
ports. The daemons that are started and stopped by inetd are not controlled by SRC; they
are under the control of inetd and the /etc/inetd.conf file.
The examples in the student notes show some of the commands being used. In the first
example the -s flag is being used. This example stops all currently active instances of the
subsystem rpc.mountd. The second example starts the specified subsystem. The third
example shows the -g option being used. -g specifies a group of subsystems to be
stopped.
The last example gives the status of a subsystem group nfs and lists the active and
inactive daemons.
Transition Statement Another way to manage NFS is using the mknfs and rmnfs
commands.
Instructor Guide
Stopping and Starting NFS

# mknfs
Adds rcnfs entry to /etc/inittab
/etc/rc.nfs is executed at next system restart
starts portmap
# rmnfs
rcnfs entry is removed from /etc/inittab
stops all running nfs daemons
Figure 13-25. Stopping and Starting NFS AU079.1
Notes:
NFS can be started and stopped using SMIT as follows:
# smit
NFS
Start NFS (Fastpath: # smit chnfs)
Stop NFS (Fastpath: # smit chnfs)
rmnfs changes the current configuration of the system so that the /etc/rc.nfs file is not
executed on system restart. By removing the entry in the /etc/inittab file, rmnfs also
stops all NFS and NIS daemons and the portmap daemon. Be cautious in the use of
this command. Two additional options can be used:
- -I does not stop any currently running system daemons, but removes the entry from
the /etc/inittab file that starts the NFS daemons on system restart.

V3.1.0.1
Instructor Guide
Uempty - -N immediately stops the NFS daemons, but it does NOT remove the entry from the
/etc/inittab file, thus allowing NFS to restart upon a system restart.
mknfs command configures the system to run the NFS daemons and adds an entry to
the inittab file so that the /etc/rc.nfs file is executed on system restart.
Instructor Guide
Instructor Notes:
Purpose Define the ways to stop, start and change NFS daemons using high-level
commands.
Details Stopping NFS using rmnfs from the command line or using SMIT, as shown,
changes the current configuration of the system so that the /etc/rc.nfs file is not executed
on system restart. In addition, you can direct the command to stop the daemons that are
currently running.
Starting NFS using mknfs configures the system to run the NFS daemons. This command
adds an entry to the /etc/inittab file so that the /etc/rc.nfs file is executed on system
restart. It also starts the portmap daemon if it isn't already running.
The number of nfsd daemons and/or biod daemons can be altered using the chnfs
command with the -n and -b options respectively. The chnfs command does this by
changing the objects in the SRC database. There are different options that can be used so
that changes take place at different times. No options indicate it takes place immediately.
(-B is the default, which temporarily stops the daemons, modifies SRC to reflect the new
number, and restarts the daemons.)
Additional Information The -I option used with chnfs restarts the number of daemons
specified at next system restart.
The -N option used with chnfs temporarily stops the daemons and restarts the number of
daemons indicated.
Transition Statement Sometimes a file system that is currently mounted needs to be
unmounted. There are several ways to do this.

V3.1.0.1
Instructor Guide
Uempty
Unmounting Remote Mounts
# umount allr
# umount /home/mntpt
# umount -n sys3
# umount -t budget
# smit umount
File system must not be in use: fuser
Figure 13-26. Unmounting Remote Mounts AU079.1
Notes:
Only root or a member of the system group can unmount a file system.
umount allr unmounts all remotely mounted file systems by checking what is mounted
as nfs in the vfs= attribute in the /etc/filesystems file.
umount /u/mntpt unmounts the specified local mount point.
umount -n sys3 unmounts all remote mounts made from the /etc/filesystems file with
nodename = sys3.
umount -t budget unmounts all stanzas in /etc/filesystems that contain the
type=budget attribute.
smit umount takes you to a menu that will allow you to specify the mount to be
unmounted by allr, name or node or by a group to be unmounted as specified with the
type attribute.
You cannot use the umount command with a device that is in use. A device is in use if
any file is open or if a user's current directory is on that device. You get the message A
Instructor Guide
device is already mounted or cannot be unmounted. Use the fuser command to find
the process using the device.
Note: umount or unmount can be used interchangeably even on the SMIT fastpath.

V3.1.0.1
Instructor Guide

Purpose Discuss ways of unmounting remote file systems.
Details There are many ways to unmount a remotely-mounted file system. umount allr
umounts all mounts that are currently mounted; umount local_dir unmounts just that one
remotely mounted directory; umount -n unmount all remotely mounted directories from the
named system; umount -t unmounts all those that were mounted with the -t (type) option.
You cannot use the umount command with a device that is in use.
Transition Statement Let's do a quick review by doing some checkpoint questions.
Instructor Guide
Checkpoint
1. What software must be installed and running on an NFS client or
server before beginning NFS configuration?
2. What other software needs to be installed?
3. What file needs to be created on an NFS server that lists the files,
directories, or file systems that are available for mounting from
clients?
4. Once the above-referenced file is created, what command must be
executed so the kernel can use this information?
5. What two daemons listed in /etc/rc.tcpip need to be up and running
for NFS to work properly?
6. What file contains the startup script for NFS?
7. In order for NFS to get started automatically after a reboot, what
file needs to be edited to add a reference to the /etc/rc.nfs file?
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
server before beginning NFS configuration? TCP/IP.
2. What other software needs to be installed? NFS.
clients? /etc/exports.
executed so the kernel can use this information? exportfs -a.
for NFS to work properly? portmap and inetd.
6. What file contains the startup script for NFS? /etc/rc.nfs.
/etc/inittab.
Instructor Guide
Exercise:
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
Instructor Guide
Unit Summary
The TCP/IP portmap daemon must be active before NFS is started
NFS can be configured using SMIT, editing files, or a combination of
both methods
The NFS server file /etc/exports makes file systems or directories
available to NFS clients
NFS client mount point directories must exist before a remote mount
can be executed
NFS can be stopped and started using the rmnfs and mknfs
commands
Notes:

V3.1.0.1
Instructor Guide

Purpose
Details
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 14. Automounter and NFS Commands

This unit introduces students to the automounter facility, which
provides automatic mounting of NFS file systems.

Describe automatic mounting of file systems
Create automount map files
Execute automount command
Execute NFS commands

Accountability:
Exercises
Copyright IBM Corp. 1997, 2006 Unit 14. Automounter and NFS Commands 14-1
Instructor Guide
Unit Objectives
Describe automatic mounting of file systems
Create automount map files
Execute NFS commands
Notes:

V3.1.0.1
Instructor Guide

Purpose List the objectives for this unit.
Details This unit introduces students to automatic mounting of file systems using the
autofs kernel extension.
Transition Statement Let's begin our discussion by defining what the automounter
does.
Instructor Guide
Automounter Overview
Used for automatic and transparent mounting and unmounting of
NFS File systems
Based on AutoFS facility
Uses automounter map files to find the mount directories and mount
arguments
Map can be text files or NIS maps
automount command
automountd daemon
Client-side server
Figure 14-2. Automounter Overview AU079.1
Notes:
The autofs monitors specified directory mount points and when a file I/O operation is
requested to that mount point, requests automountd to mount directory within autofs.
Automount command is used to propagate the automatic mount information to the autofs
kernel extension and start automountd daemon. After a period of inactivity, five minutes by
default, the autofs attempt to unmount any mounted directories under its control.

V3.1.0.1
Instructor Guide

Purpose Describe what the automounter does.
Details The automounter automatically and transparently mounts an NFS file system
whenever a file or directory in that file system is opened. It then monitors attempts to
access file systems that are referenced in an automounter map file. When a file is
accessed, the automounter mounts the appropriate NFS directory as specified in the
automounter map file.
Additional Information For NFS read-only file systems, the automounter finds the
nearest server to the client to handle the mount request. This occurs only at the initial
mount. Once mounted, additional accesses to the directory do not invoke a new search for
the nearest server, even if the one it is currently accessing goes down. This may help
balance the workload for read-only NFS servers.
Transition Statement Let's take a look at some of the advantages the automounter
provides NFS.
Instructor Guide
Automounter Benefits
Reduces system administration of /etc/filesystems file particularly if
NIS maps are used
No premounting of directories not currently needed thus reducing
possibility of client hang due to down server
Distributes client workload for NFS read-only file systems
Provides method for single-system image for clients
Figure 14-3. Automounter Benefits AU079.1
Notes:
Using the automounter, you neither have to keep the /etc/filesystems file up to date with
NFS stanzas nor do you have to keep file systems mounted that are not being used.

V3.1.0.1
Instructor Guide

Purpose Describe the benefits of using automounter.
Details In large NFS environments, it may be difficult to keep the /etc/filesystems file
on every machine up to date. Doing so means creating ahead of time all local mount point
directories that are referenced in /etc/filesystems. In addition, having all possible remote
file systems a client needs statically mounted at all times can produce a large mount table
which can impact performance on lookup operations.
File systems mounted upon reference mean someone without root authority is actually
performing the mount by opening a file that is being monitored by the autofs daemon. As
we learned before, only root or a member of the system group can issue the actual mount
command from the command line. The autofs provides a method of allowing users to
automatically perform a mount when needed.
Additional Information AutoFS
Automatic Mounting of a File System Using AutoFS
AutoFS relies on the use of the automount command to propagate the automatic mount
configuration information to the AutoFS kernel extension and start the automountd
daemon. Through this configuration propagation, the extension automatically and
transparently mounts file systems whenever a file or a directory within that file system is
opened. The extension informs the autmountd daemon of mount and unmount requests,
and the autmountd daemon actually performs the requested service.
Transition Statement Let's take a look at the automounter map files.
Instructor Guide
Automount Indirect Map File

Syntax :
RELATIVE PATH
local dir point [mount options] nfs server:remote dir point
# cat /etc/auto.indirect
inventory sys3:/books
subscription sys4:/magazine
review sys9:/article
Local Subdirectory Server Exported

directory
Figure 14-4. Automount Indirect Map File AU079.1
Notes:
The automounter Indirect local map will contain: 1) name of the client subdirectory mount
point, 2) server name, 3) full path name of the server's exported directory, and 4) optional
mount options.
The directories inventory, subscription and review do not have to exist on the client.
The name /etc/auto.indirect is arbitrary. Any name can be used but it must be created and
stored in the /etc directory. For simple system administration, use the word auto followed
by a name that describes the contents of the map. Grouping automounter maps by a
naming convention makes it easier to keep updated. automount local maps cannot be
created using SMIT.
Indirect map files are used for mounting NFS exported directories to local mount points
which cannot already exit. In this example the local mounts points are created within
/publishing directory. /publishing cannot already be an existing mount point.

V3.1.0.1
Instructor Guide

Purpose Describe the contents of an indirect automounter map.
Details This is an example of an indirect automounter map which provides all the
information needed for the automounter to create the RPC mount request. This map
contains a key which is the name of the subdirectory mount point on the client, followed by
the server name, a colon, and the server's exported file system for use by this client. Notice
that the key is the subdirectory. The parent directory is issued with the automount
command when the automounter is started. Mount options can also be provided for each
entry. The syntax for an automounter map is:
Key [-mount options] location
where key for an indirect map is a simple name representing a subdirectory and for a direct
map a full path name, and location is the server: <server exported directory>.
Additional Information To set up multiple read-only servers allowing automounter to
balance the load, simply list all possible servers in the map using the \ (back slash) as a
continuation line character. If more than one server:directory pair is listed in an
automounter map, the automounter pings all servers using the null procedure of NFS
servers. The first server in the list to respond is selected by the automounter as the server.
Transition Statement Let's now take a look at a map entry for an direct map.
Instructor Guide
Automount Direct Map File

Syntax
ABSOLUTE PATH
local dir point [mount options] nfs server:remote dir point
# cat /etc/auto.direct
/usr/man -ro sys3:/usr/man

/home sys4:/home
Local Subdirectory Server Exported

directory
Figure 14-5. Automount Direct Map File AU079.1
Notes:
Direct maps are useful for directories that are under higher-level directories, such as /usr,
that cannot be used as an automounter indirect mount point. For example, building an
indirect map for /usr/man that uses /usr as a mount point would cover up files in /usr/bin.
mount-point is full absolute name of a directory.
map-name is the map autofs uses to find directions to locations, or mount information.
mount-options is optional, comma separated list of options that apply to the mounting of
the entries specified in map-name unless the entries in map-name list other entries.

V3.1.0.1
Instructor Guide

Purpose Introduce Direct Maps files
Details
Transition Statement Let's now take a look at a map entry for the master map.
Instructor Guide
Automount Master Map File

Syntax :
local dir point map file [mount options]

Example
# cat /etc/auto_master
/publishing /etc/auto.indirect -ro

/- /etc/auto.direct
Figure 14-6. Automount Master Map File AU079.1
Notes:
Prior to AIX 5L release the automount command could mount indirect and direct maps
independently, for example: automount -m /publishing /etc/auto.direct.
However, AIX 5L requires all map files to be referenced from within file /etc/auto_master.
This filename is not optional.
The syntax for the master map file is local directory mount point, followed by the map name
and any optional mount options. /- for direct maps is a way of saying no mount point is
needed to be reference as it is implicitly stated from within the direct map file itself.

V3.1.0.1
Instructor Guide

Purpose Describe the use of the master map.
Details The auto-master map associates a directory with a map. It is a master list
specifying all the maps that autofs should know about.
Transition Statement Now we know how to set up the maps, let's see how to get the
automounter started.
Instructor Guide
automount Command
Creates the mount point
Example: # mkdir /publishing
Loads autofs kernel extension
Read the master map
Passes information from master map to autofs
Starts automountd if not started already
Terminates
Syntax /usr/sbin/automount -v -t -i
AutoFS maintains internal table
Figure 14-7. automount Command AU079.1
Notes:
The automount command is used as an administration tool for autofs.
-v Displays on standard output status
-i Interval - specifies an interval, in seconds, that autofs directory lives
-t Duration, specifies a duration, in seconds, that an autofs unmount thread
sleeps before it starts to work again.
SMIT method:
# smit
NFS
Configure NFS
Start automount (Fastpath: # smit mkautomnt)
Only root can issue the automount command. Unlike the mount command, automount
cannot be invoked by a user in the system group.
/publishing is the client local parent directory to the actual mount point of the subdirectory
listed in the map.

V3.1.0.1
Instructor Guide

Purpose To show how to invoke the automount command.
Details Only root can issue the automount command. This can be done from the
command line or from SMIT as shown in the notes.
Additional Information Point out that the automount command has CHANGED in AIX
5L.
For additional information see - Network File System (NFS) Overview for System
Management in AIX 5L Version 5.2 System Management Guide: Communications and
Networks.
Transition Statement Once the automounter has been started, what does the mount
information look like?
Instructor Guide
Automounter Started
# automount -v
automount /publishing mounted
# mount

/dev/hd4 / jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd2 /usr jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd9var /var jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd3 /tmp jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd1 /home jfs 12 Oct 07:43 rw,log=/dev/hd8
/etc/auto.indirect /publishing autofs 13 Oct 03:56 ro,ignore
Figure 14-8. Automounter Started AU079.1
Notes:
Nothing is mounted at this point. The autofs daemon has been started and is waiting for a
user to reference the mount point the daemon is listening for which is /publishing. Once
accessed, autofs will have automountd handle the initial mount request.

V3.1.0.1
Instructor Guide

Purpose Discuss the mount table options when automounter is started.
Details Point out to the students that the file system type in the last entry is autofs and
remind them that the automount command is just a front-end to AutoFS.
Transition Statement The automounter daemon is now ready to handle user requests.
Let's see how a user invokes the remote mount.
Instructor Guide
Invoking the Remote Mount

$ cd /publishing/inventory
$ Is
heidi
moby
hamlet
sys1 - Client sys3 - Server
/ /
etc publishing books
auto.pub
heidi
inventory moby
hamlet
Figure 14-9. Invoking the Remote Mount AU079.1
Notes:
When a user references /publishing/inventory that user should have automatic access to
all files from the sys3 /books exported directory.
The automatic mount happens when the user changes directory to /publishing/inventory,
at which time the kernel notifies the automountd daemon that the remote file system is
required. Access to a file within /publishing/inventory would have the same effect.

V3.1.0.1
Instructor Guide

Purpose Explain how to invoke a remote mount with automounter.
Details When a user references /publishing/inventory, the automountd daemon is
notified by the kernel and performs the automatic mount. This is a normal NFS mount with
the difference that it is being done automatically. The NFS server is not aware that it
happens to be automatic. The mount is done exactly as we would expect, with the remote
directory /books being mounted over the local directory /publishing/inventory.
Transition Statement Now that something has been remotely mounted, what does the
mount table look like?
Instructor Guide
Remote Mount Table Entry

# mount
/dev/hd4 / jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd2 /usr jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd9var /var jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd3 /tmp jfs 12 Oct 07:42 rw,log=/dev/hd8
/dev/hd1 /home jfs 12 Oct 07:43 rw,log=/dev/hd8
/etc/auto.pub /publishing autofs 13 Oct 03:56 rw,ignore
sys3 sys3:/books /publishing/inventory nfs 13 Oct 04:20 ro
Figure 14-10. Remote Mount Table Entry AU079.1
Notes:
Looking at the mount table, we see that the original /publishing parent mount point entry
exists and now an entry for the server directory /books exists as well.
The node column shows the server name of sys3. The mounted over column shows that
the remote directory has been mounted over the local mount point, /publishing/inventory.

V3.1.0.1
Instructor Guide

Purpose Describe the contents of the mount table once an automountd has taken
place.
Details Notice the reference to the automountd daemon process is still listed.
Additionally, information about the actual NFS remote mount now appears showing that the
node is sys3, which has /books mounted over /publishing/inventory.
Transition Statement There are several useful commands provided with NFS. Lets
see what they are.
Instructor Guide
NFS Commands
Command Description Daemon
showmount Displays what clients have rpc.mountd
mounted
rpcinfo Displays what portmap has listed portmap
on Remote command execution rexd
rup Displays host uptime information rstatd
rusers Shows remote users rusersd
rwall Sends message to network users rwalld
spray Sends a stream of packets sprayd
nfsstat Displays status of NFS and RPC calls
nfs4cl NFS V4 statistics and properties properties
Figure 14-11. NFS Commands AU079.1
Notes:
The above daemons, with the exception of rpc.mountd and portmap are found in the
/etc/inetd.conf file and need to be uncommented and registered with the portmap
daemon. This should be done on both the NFS clients and servers. If you use SMIT to start
NFS, this step is done automatically for you.
showmount displays a list of all clients that have mounted remote file systems.
rpcinfo queries portmap daemon for information on services registered with portmap.
on executes commands on remote hosts.
rup shows the status of remote hosts on the local network.
rusers reports a list of users logged in to the remote machine.
rwall sends messages to all users on the network.
spray sends a specified number of packets to a host.
nfsstat displays statistical information about NFS and RPC calls
nfs4cl displays or modifies current NFS V4 statistics and properties.
Further information on these commands can be found in the Commands Reference
manuals.

V3.1.0.1
Instructor Guide

Purpose Describe the use of NFS commands.
Details This is a list of the NFS commands that gather network information. To have the
client participate in the results of many of these commands, they must have the supported
daemons from the /etc/inetd.conf file registered with their own portmap daemon. This is
why the portmap daemon must be active on clients as well as on the server.
If students wish more information on these commands and how they work encourage them
to experiment and to look in the Commands Reference manual. We cover the showmount
and rpcinfo commands in more detail in the next couple of visuals. If students experiment
with up, rusers, rwall, and on during the exercise they get a good idea of how they work.
Additional Information If students wish more information on spray or nfsstat take the
discussion off-line as a detailed discussion of these commands is beyond the limited scope
of this class. The following information should be helpful if such a discussion should arise.
spray command
spray host -c count -l length -d delay
The only required parameter is the host name. 1162 and 86 are the default count and
length.
The spray program can provide a rough test of the capacity of the network interface. spray
floods a target host with fixed length packets by making a remote procedure call to the
sprayd daemon on the remote host. After the last packet is sent, the sprayd daemon on
the remote host is queried for a count of received packets. The count is compared to the
number of packets sent. From this, the percentage of dropped packets is determined
between the client and the server. This gives the client an idea how many packets and
bytes per second the server is capable of processing.
The network interface speed depends not only on CPU speed, but also on the network
interface and bus hardware on the system. If a client CPU speed is faster than the server's,
the client can easily outpace a server. This means the client system would be forced to
retransmit requests. This furthers burden the server since it will have to handle duplicate
requests. When a fast NFS client has a slow NFS server, the NFS mount parameter may
require tuning.
The -d option specifies the time, in microseconds, the system pauses between sending
each packet. The default is zero. If the client system sprays a slow server system, a large
number of packets are dropped. By using the -d option, even a one-microsecond delay
between the packets allows the slow server to keep pace and receive all packets. You
cannot get NFS to insert delays, but this test with delays can indicate the location of the
bottleneck. Once the bottleneck is identified, the NFS parameters may be tuned.
ping -f sys8 also tests a network interface but not as exhaustively as spray.
Instructor Guide
nfsstat command
nfsstat can give you an insight into performance problems. It is limited, however, because
server statistics are collected for all clients, and client statistics are collected for all servers.
It does not separate the distribution of called from each client or server.
# nfsstat -s
Server rpc:
calls badcalls nullrecv badlen xdrcall

11 0 0 0 0
Server nfs:
calls badcalls
7 0
null getattr setattr lookup

0 0% 2 28% 0 0% 1 14%
nfsstat -s identifies a variety of important statistics for the server. The first line shows a
compilation of total RPC calls. From the total number of RPC calls, the badcalls report the
number of calls rejected. Calls are rejected because of authentication failures and if root
operations are attempted on the server by an unauthorized client. If bad calls are greater
than 0 the server is rejecting RPC requests. By default, eight nfsd daemons are started on
a server. Whenever the nfsd daemon is scheduled to run but doesn't find a packet on the
NFS server queue, the nullrecv field gets incremented by one. The server may be running
an excessive number of nfsd daemons.
badlen refers to an empty or truncated RPC packet. The packet could have been damaged
by a network problem.
xdrcall refers to an XDR header that may have been damaged. This is rare, but can happen
more often if the network is a WAN rather than a LAN.
The NFS statistics show the number of NFS calls made to the server. Each of the call types
(null, getattr, setattr, and so forth) relate to an NFS RPC service procedure. As an example,
the null procedure is used in every RPC program ensuring that the network is operational.
It acts similar to ping. rpcinfo calls the null procedure to check the reachability of the RPC
server programs. It also is used with the automount retry activities. If the automounter is
retrying mounts too frequently this value may be high and you may wish to lengthen the
time-out on automount.
NFS clients cache file attributes such as modification time and owner to avoid repeated
calls to the NFS server for this information. Once the getattr call has been completed, the
information is cached for repeated use. Repeated attribute changes by writes are easily
taken care of by the client. The attributes get written back to the server using the setattr

V3.1.0.1
Instructor Guide
Uempty call. Attribute changes are written out when the cache's lifetime expires. Attribute changes
are written out at the end of the maximum period to avoid having the client and server
views of the files vary too greatly. Attribute caching can be disabled using the noac option
with the mount command. When many clients have attribute caching disabled, the server's
getattr increases significantly.
The lookup statistic displays the percentage of lookups that failed. Lookups are also
affected by a directory attribute cache time-out. If there are multiple clients creating and
using the same server directory, you want them all to see the most current listing of the files
in that directory when they execute ls. For example, if clientA creates fileA, and clientB
does an ls file*, clientB may get back an error No such file or directory. In this case, the
shell (because of the *) tries to read the directory entries to perform the file name matching
before it passes it to ls. Since the directory entries are cached on clientA, in this example, it
is possible that clientB does not see the newly created file until clientA's directory cache is
flushed. A high lookup percentage would indicate that if the directory cache were reduced,
more lookups by all clients may be more successful on the first attempt. Use the actime
option with the mount command to change the directory cache time-out.
# nfsstat -c
Client rpc :
calls badcalls retrans badxid timeout
3392 0 4 0 4
Client nfs:
calls badcalls nclget nclsleep
3355 0 3355 0
null getattr setattr lookup read

0 0% 37 1% 16 0% 65 1% 16 0%
.
.
Client RPC statistics indicate how successful the client is in communicating with the server.
Client NFS statistics consist of information about calls made to all servers.
Looking at the RPC statistics shows unsuccessful attempts in trying to send NFS requests
to a server. Just like the server statistics we just covered, calls is the number of calls made
to all NFS servers.
badcalls indicates RPC failures due to time-outs (if a server does not respond within a
time-out period) and interrupts (if a file system mount is interrupted with the intr option).
This differs from the badcalls as shown under the NFS statistics, which indicate
authentication errors.
retrans indicates the number of retransmissions because no response was received for the
server. If there is poor server response time, retrans has a high number.
Instructor Guide
To understand badxid, you have to know something about NFS requests. An XID is
assigned to each NFS request. That same XID is assigned if the request has to be
retransmitted. An NFS client may have multiple NFS requests out to several servers. When
a response is received from a server, the client matches the XID in the response to the
RPC call request. It could happen that the client retransmitted just when the slow server
responded; thus, the retransmission crossed the response. Therefore, when the response
to the second request is sent back to the client, there is no XID to match. The badxid count
is incremented, badxid indicates if a server is receiving some transmitted requests, but is
so slow in replying that no match is found for the XID that was originally assigned to the
request.
Looking at the NFS statistics, calls and bad calls indicate the number of calls and rejected
calls made to the servers.
The nclget and nclsleep attributes deal with file handles. When an NFS client sends a
mount request, the mountd on the server determines if that client has permissions to the
exported directory. If so, mountd sends the client's kernel a file handle. The file handle
becomes a pointer for the kernel to maintain the server connection information. Once the
mount takes place, the client performs read/write operations. The biod sends the file
handle to the server where the file is read by an nfsd daemon. NFS servers and clients
identify files through a variable-length file handle. When clients look up files by pathname
(one component at a time) they are given a file handle for the directory containing the file
and for the file itself. A file handle is transparent to the client, but the server must be able to
translate the file handle to a file. The nclget indicates how many times the client had to
request a new client handle for an NFS call. nclsleep indicates the number of times an NFS
call was blocked because no client handle was available. nclsleep should be zero as client
handles should be allocated on demand. Client handles can be increased in the param.c
file.
Transition Statement Many of these daemons are under control of inetd. Let's take a
look at how they are configured in the /etc/inetd.conf file.

V3.1.0.1
Instructor Guide
Uempty
/etc/inetd.conf
# vi /etc/inetd.conf
rexd sunrpc_tcp tcp wait root /user/etc/rpc_rexd rexd 100017 1

rstatd sunrpc_udp udp wait root /usr/etc/rpc.rstatd rstatd 100001 1-3
rusersd sunrpc_udp udp wait root /usr/etc/rpc.rusersd ruserd 100002 1-2
rwalld sunrpc_udp udp wait root /usr/etc/rpc.rwalld rwalld 100008 1
sprayd sunrpc_udp udp wait root /usr/etc/rpc.sprayd sprayd 100012 1
pcnfsd sunrpc_udp udp wait root /etc/rpc.pcnfsd pcnfsd 150001 1
Figure 14-12. /etc/inetd.conf AU079.1
Notes:
SMIT Method:
# smit
NFS
Start NFS (Fastpath: &numsign smit mknfs)
Uncomment the above NFS daemons. Those daemons answer requests for their
respective NFS commands. This should be done on both the clients and the servers so
everyone can participate in issuing and responding to the commands.
If this step is done AFTER NFS has already been started, you must be sure to register
these daemons with the portmap daemon. Do the following to have the inetd daemon
reread its /etc/inetd.conf file and register the programs with portmap.
# refresh -s inetd
This step is done for you if you start NFS via SMIT.
Instructor Guide
Instructor Notes:
Purpose Explain the role the /etc/inetd.conf. file plays with NFS.
Details There are six NFS daemons located in /etc/inetd.conf. They get registered by
inetd with the portmap daemon at system startup. The others that get registered are found
in the /etc/rc.nfs script file. /etc/inetd.conf lists the service name, socket type, protocol to
use, program number, and other information.
Transition Statement It is very helpful to know what file systems are been exported by
a server or what clients have mounted to exported file systems. The showmount
command can provide that information.

V3.1.0.1
Instructor Guide
Uempty
What a Server Is Exporting
# showmount -e sys4
export list for sys4:

/home/records -access=sys3,sys5
/budgets (everyone)
# showmount -a sys4
sys3:/home/records
sys7:/budgets
Figure 14-13. What a Server Is Exporting AU079.1
Notes:
The showmount command provides information about a server's mount information or
what a server has exported.
The -e option lists what is currently exported by a specific server.
The -a option lists the client name and directory path name that has been remotely
mounted.
Because showmount talks to the rpc.mountd daemon, it is possible to view lists on
network servers. The rpc.mountd daemon stores this information in the /etc/rmtab file.
Instructor Guide
Instructor Notes:
Purpose Describe the use of the showmount command.
Details The showmount command communicates with the rpc.mountd daemon on the
local or a remote server. When rpc.mountd accepts a mount request from a client, it
places the directory name and client hostname in /etc/rmtab. Entries in /etc/rmtab remain
until the client unmounts the remote mount.
The -e option interrogates the contents of the /etc/xtab file on the target base.
The -a option displays a list of all remote directories mounted by a host.
Discussion Items How do I know what files have been exported? A mistake is to look in
the /etc/exports file. Using the exportfs command on a server will display the contents of
the /etc/xtab file. Simply displaying the contents of /etc/exports file may not be an
accurate view of what is currently exported. exportfs is for local use. The showmount
command is used to view what a remote or local server currently has exported.
Transition Statement How can you tell if a particular version of a server has registered
with portmap? The rpcinfo command can provide that information.

V3.1.0.1
Instructor Guide
Uempty
rpcinfo
rpcinfo -p sys4
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 604 mountd
rpcinfo -u sys4 nfs 2
program 100003 version 2 ready and waiting
rpcinfo -b autofs 1
10.19.98.4 sys4
10.19.98.5 sys5
Figure 14-14. rpcinfo AU079.1
Notes:
rpcinfo queries the remote portmap daemon.
rpcinfo can be used to detect and debug failures such as:
Dead or hung servers caused by improper configuration or a failed daemon
Bogus or renegade RPC servers
Broadcast-related problems
If the portmap daemon on the remote host has failed, this command times out.
The -u option makes a call to the specific program and version number on a specific host
using UDP and reports whether the program is ready and waiting for requests.
The -b option makes an RPC broadcast of the specified program and version number and
reports all hosts that respond.
Instructor Guide
Instructor Notes:
Purpose Describe the purpose and function of rpcinfo.
Details The rpcinfo command makes an RPC call to an RPC server and reports the
status of the RPC service (example, ready and waiting, available, and so forth.)
rpcinfo can provide considerable help in the diagnosis of RPC problems by displaying
what services are registered with a host and are ready and waiting to be used. It can be
used as a test of connectivity verifying that the remote system is capable of accepting and
replying to an RPC request.
The -p option queries the portmap daemon on the specified host for all registered RPC
services. The output displays the program and version number, the protocols supported,
the IP port used by the RPC server, and the name of the RPC service. If the portmap
daemon on the remote system is not reachable for whatever reason, rpcinfo times out and
reports the error. This is a good first step in diagnosing the problem.
The -u option used along with a specified hostname, RPC program and version number,
gives the status of the RPC service. This may be used if the NFS client is trying to mount a
file system or directory from an NFS server. The mount is successful, but any attempt to
use the remote file hangs. The -u tells rpcinfo to use the UDP protocol. A -t option
specifies the TCP protocol to be used.
The -b option does an RPC broadcast of the specified program and version using the UDP
protocol, and reports all hosts that respond. This shows all systems on the local network
that are running a certain version of the specific RPC service.
Transition Statement Before we summarize, let's look at some checkpoint exercises.

V3.1.0.1
Instructor Guide
Uempty
Checkpoint
1. T/F: The automounter local map contains three pieces of
information:
a. Name of the client subdirectory mount point
b. Server name
c. Path name of the server's exported directory
2. T/F: The command you can use to get NFS statistics is netstat.
3. T/F: AutoFS is a server-side service that allows for automatic and
transparent mounting and unmounting of NFS file systems.
4. T/F: The rup command requires rexd daemon to be running.
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details
information:
b. Server name
True.
False. The command is nfsstat.
transparent mounting and unmounting of NFS file systems. False.
4. T/F: The rup command requires rexd daemon to be running. False.
The rstatd needs to be running.

V3.1.0.1
Instructor Guide
Uempty
Exercise:
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
Automatic mounting of file systems is performed using automount
command, AutoFS facility, and automountd
Automount map files are used to locate mapping for directories
The master map associates a directory with a map file
NFS has many subserver commands
Notes:
Instructor Guide
Instructor Notes:
Purpose
Details

V3.1.0.1
Instructor Guide
Uempty Appendix A. Checkpoint and Activity Solutions

Unit 1 (Activity)
Optional Activity: Subnet Masks - Solution

There can be 1022 subnetworks and 62 hosts per network.

A subnet mask of 255.255.248.0 is needed.

The network address is 201.100.23.192. The broadcast

address is 201.100.23.223. The first host on the network
would use the address 201.100.23.193.
Copyright IBM Corp. 1997, 2006 Appendix A. Checkpoint and Activity Solutions A-1
Instructor Guide
Unit 1 (1 of 4)
on the network.
communications.
a. Bridge
b. Repeater
c. Router
A-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
Uempty Unit 1 (2 of 4)
adapter?
a. 16
b. 32
c. 48
d. 64
a. 16
b. 32
c. 48
d. 64
Network address and local host address
Instructor Guide
Unit 1 (3 of 4)
by periods.
This is the loopback address used by a system to send
messages to itself.
255 (all bits on)
ability only.
13. Why are port numbers included in UDP and TCP headers?
Port numbers distinguish between multiple processes
running on the same host. Server side ports (and the
transport layer protocol in use) also identify the network
service associated with the connection.

V3.1.0.1
Instructor Guide
An ICMP message is not generated because the datagram
was delivered by IP to UDP. Once it reaches its destination,
IP has no knowledge of what is done with the datagram.
The statement is false. IP is a connectionless protocol.
Instructor Guide
Unit 2
This is appropriate when the HMC is on a private network
and there is no other DHCP server.
The connection uses Ethernet.
SSH, WebSM client, from another HMC
Remote virtual console, SSH access
system.

V3.1.0.1
Instructor Guide
Uempty Unit 3
1. What is a good first command to use to test if two hosts are talking
to each other on a network? ping
both name to address and address to name? host
3. What command displays what is in your arp cache? arp -a
output packets transmitted on a network interface? netstat -i
access to telnet services? /etc/services,/etc/inetd.conf and
/etc/rc.tcpip
Instructor Guide
Unit 4
POWER Hypervisor feature. False.
2. T/F: AIX 5L 5.2 can be configured with Virtual Ethernet. False.
True.
devices. True.
HMC partition profile.
be defined in the HMC partition profile and in the
VLAN adapter in AIX.
_B_ IEEE 802.1Q A. Identifies a virtual LAN
_A_ VID B. Virtual LAN standard
_C_ PVID C. Default VID associated with a switch port

V3.1.0.1
Instructor Guide
Uempty Unit 5
a. direct
b. indirect
c. default
route?
a. dynamic
b. implicit
False. It flushes all routes except ones created implicitly.
Instructor Guide
Unit 6 (1 of 2)
False. Unpredictable results occur if they are running on the same system at the
same time.
that apply.)
a. OSPF
b. HELLO
c. RIP - routed only supports RIP
d. EGP
a. BGP
b. RIP
c. OSPF
d. IP
hops. True.
5. T/F: OSPF is a distance vector protocol. False. OSPF is a link state
protocol.

V3.1.0.1
Instructor Guide
all that apply.)
read by the gated daemon on start-up. True.
a. RIP - RIP in broadcast mode/active/.
b. RIP-2
c. OSPF
d. BGP
Instructor Guide
Unit 7
virtual SCSI disk and shared Ethernet adapter resources.
external networks to internal VLANs.
checked. True.
using one SEA. True.
VLAN can you have? One.
aggregate of adapters. True.

V3.1.0.1
Instructor Guide
Uempty Unit 8
VIPA in the server. False. Clients need return routes to the
VIPA address. If there are intervening routers, they will need
routes as well.
definition. True.
can be sent over a particular network. True.
routing feature. False. In AIX 5L V 5.2 and earlier, you need to
disable PMTU discovery to stop the cloning of routes.
In AIX 5L V5.3, PMTU discovery has no effect on multipath
routing.
load-balancing and failover. True.
Instructor Guide
Unit 9 (1 of 3)
a. Minutes
b. Hours
c. Days
d. Seconds

lines?
a. ;
b. @
c. #
d. ()

a. It must be traversed left to right, similar to the domain name with the highest level
of hierarchy indicated last.

V3.1.0.1
Instructor Guide
participating in the domain environment. False. named only runs
on the name servers.
IP address to host name resolution. True.
Instructor Guide
Unit 9 (3 of 3)
Answers: b, d, c, a.
a flat network or a domain network? /etc/resolv.conf
resolution. True.
line entry in the inetd.conf file. False.

V3.1.0.1
Instructor Guide
Uempty Unit 10
1. T/F: In AIX, all Hosts should get their IP address via DHCP. False.
network. DHCP/BOOTP relay agent
______________________ field of the DHCP packet. options.
client. False.
a. DHCPACK
b. DHCPREQUEST
c. DHCPRELEASE
d. DHCPDISCOVER
e. DHCPOFFER
Answer: d, e, b, a, c

False.
Instructor Guide
Unit 11 (1 of 2)
characteristics of a network interface. lsattr, ifconfig
product data?
a. lsdev -C -c tok0
b. lscfg
c. lscfg -v -l tok0
3. Which two commands below are the most commonly used and
most useful commands for doing problem determination on a
network?
a. arp and host
b. ping and nfsstat
c. ping and netstat
d. spray and no

V3.1.0.1
Instructor Guide
a. netstat -s
b. netstat -i
c. netstat -l
d. netstat -m

c. ifconfig tok0
Instructor Guide
Unit 12 (1 of 2)
True.
True.
operations? nfsd.
biod.

V3.1.0.1
Instructor Guide
used to handle file and record locking? statd and lockd.
mounted? mount.
portmap.
8. T/F: The cacheFS is implemented on the NFS server. False.
Instructor Guide
Unit 13
server before beginning NFS configuration? TCP/IP.
2. What other software needs to be installed? NFS.
clients? /etc/exports.
executed so the kernel can use this information? exportfs -a.
for NFS to work properly? portmap and inetd.
6. What file contains the startup script for NFS? /etc/rc.nfs.
/etc/inittab.

V3.1.0.1
Instructor Guide
Uempty Unit 14
information:
b. Server name
True.
False. The command is nfsstat.
transparent mounting and unmounting of NFS file systems. False.
4. T/F: The rup command requires rexd daemon to be running. False.
The rstatd needs to be running.
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Appendix B. Command Summary
Startup, Logoff and Shutdown

<Ctrl>d (exit) log off the system (or the current shell).
shutdown shuts down the system by disabling all processes. If in single
user mode, may want to use -F option for fast shutdown. -r
option will reboot system. Requires user to be root.
Directories
mkdir make directory
cd change directory. Default is $HOME directory.
rmdir remove a directory (beware of files starting with .)
rm remove file; -r option removes directory & all files &
subdirectories recursively.
pwd print working directory
ls list files
-a (all)
-l (long)
-d (directory information)
-r (reverse alphabetic)
-t (time changed)
-C (multi column format)
-R (recursively)
-F (places / after each directory name & * after each exec file)
Files - Basic
cat list files contents (concatenate).
Can open a new file with redirection, for example, cat > newfile.
Use <Ctrl>d to end input.
chmod change permission mode for files or directories.
chmod =+- files or directories
(r,w,x = permissions and u, g, o, a = who)
can use + or - to grant or revoke specific permissions.
can also use numerics, 4 = read, 2 = write, 1 = execute.
Copyright IBM Corp. 1997, 2006 Appendix B. Command Summary B-1

Instructor Guide
can sum them, first is user, next is group, last is other.

for example, chmod 746 file1 is user = rwx, group = r, other
= rw.
chown change owner of a files, for example, chown owner file
chgrp change group of a files
cp copy file
del delete files with prompting (rm for no prompting)
mv move and rename file
pg list files contents by screen (page)
h (help) q (quit),
<cr> (next pg) f (skip 1 page),
l (next line) d (next 1/2 page)
$ (last page) p (previous file),
n (next file) . (redisplay current page)
. Current Directory
.. Parent Directory
/string (find string forward),?string (find string backward),
-# (move backward # pages), +# (move forward # pages)
rm remove (delete) files (-r option removes directory and all files
and subdirectories)
head print first several lines of a file
tail print last several lines of a file
wc report the number of lines (-l), words (-w), characters (-c) in a
files. No options gives lines, words, and characters.
su switch user
id displays your user ID environment as it is currently set
tty displays the device that is currently active. Very useful for
Xwindows where there are several pts devices that can be
created. It's nice to know which one you have active. who am i
will do the same.
B-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
Uempty Files - Advanced

awk programmable text editor / report write
banner display banner (can redirect to another terminal 'nn' with
'>/dev/ttynn')
cal calendar (cal month year)
cut cut out specific fields from each line of a file
diff differences between two files
find find files anywhere on disks. Specify location by path (will
search all subdirectories under specified directory).
-name fl (file names matching fl criteria)
-user ul (files owned by user ul)
-size +n (or -n) (files larger (or smaller) than n blocks)
-mtime +x (-x) (files modified more (less) than x days ago)
-perm num (files whose access permissions match num)
-exec (execute a command with results of find command)
-ok (execute a cmd interactively with results of find command)
-o (logical or)
-print (display results. Usually included)
find syntax: find path expression action
for example, find / -name *.txt -print
or find / -name *.txt -exec li -l {} \;
(executes li -l where names found are substituted for {}) ;
indicates end of command to be executed and \ removes usual
interpretation as command continuation character)
grep search for pattern, for example, grep pattern files. Pattern can
include regular expressions.
-c (count lines with matches, but don't list)
-l (list files with matches, but don't list)
-n (list line numbers with lines)
-v (find files without pattern)
expression metacharacters
[ ] matches any one character inside.
with a - in [ ] will match a range of characters.
[ matches BOL when [ begins the pattern.
$ matches EOL when $ ends the pattern.
. matches any single character. (same as ? in shell).

Instructor Guide
* matches 0 or more occurrences of preceding character.

(Note: .* is the same as * in the shell).
sed stream (text) editor. Used with editing flat files.
sort sort and merge files
-r (reverse order); -u (keep only unique lines)
Editors
ed line editor
vi screen editor
INed LPP editor
emacs screen editor +
Shells, Redirection and Pipelining

< (read) redirect standard input, for example, command < file reads
input for command from file.
> (write) redirect standard output, for example, command > file writes
output for command to file overwriting contents of file.
>> (append) redirect standard output, for example, command >> file
appends output for command to the end of file.
2> redirect standard error (to append standard error to a file, use
command 2>> file) combined redirection examples:
command < infile > outfile 2> errfile
command >> appendfile 2>> errfile < infile
; command terminator used to string commands on single line
| pipe information from one command to the next command. For
example, ls | cpio -o > /dev/fd0 passes the results of the ls
command to the cpio command.
\ continuation character to continue command on a new line.
Prompted with > for command continuation.
tee reads standard input and sends standard output to both
standard output and a file. For example, ls | tee ls.save | sort
results in ls output going to ls.save and piped to sort command.

V3.1.0.1
Instructor Guide
Uempty Metacharacters
* any number of characters (0 or more)
? any single character
[abc] [ [ any character from the list
[a-c] [ ] match any character from the list range
! not any of the following characters (for example, leftbox !abc
right box)
; command terminator used to string commands on a single line
& command preceding & to be run in background mode
# comment character
\ removes special meaning (no interpretation) of the following
character
removes special meaning (no interpretation) of character in
quotes
" interprets only $, backquote, and \ characters between the
quotes.
` used to set variable to results of a command for example,
now=`date` sets the value of now to current results of the date
command.
$ preceding variable name indicates the value of the variable.
Physical and Logical Storage

chfs changes file system attributes such as mount point,
permissions, and size
compress reduces the size of the specified file using the adaptive LZ
algorithm
crfs creates a file system within a previously created logical volume
extendlv extends the size of a logical volume
extendvg extends a volume group by adding a physical volume
fsck checks for file system consistency, and allows interactive repair
of file systems
fuser lists the process numbers of local processes that use the files
specified
lsattr lists the attributes of the devices known to the system

Instructor Guide
lscfg gives detailed information about the RISC System/6000

hardware configuration
lsdev lists the devices known to the system
lsfs displays characteristics of the specified file system such as
mount points, permissions, and file system size
lslv shows you information about a logical volume
lspv shows you information about a physical volume in a volume
group
lsvg shows you information about the volume groups in your system
migratepv used to move physical partitions from one physical volume to
another
mkdev configures a device
mkfs makes a new file system on the specified device
mklv creates a logical volume
mkvg creates a volume group
mount instructs the operating system to make the specified file system
available for use from the specified point
quotaon starts the disk quota monitor
rmdev removes a device
rmlv removes logical volumes from a volume group
rmlvcopy removes copies from a logical volume
umount unmounts a file system from its mount point
uncompress restores files compressed by the compress command to their
original size
unmount exactly the same function as the umount command
varyoffvg deactivates a volume group so that it cannot be accessed
varyonvg activates a volume group so that it can be accessed
Variables
= set a variable (for example, d=day sets the value of d to
day). Can also set the variable to the results of a command by
the ` character for example, now=`date` sets the value of now to
the current result of the date command.
HOME home directory

V3.1.0.1
Instructor Guide
Uempty PATH path to be checked

SHELL shell to be used
TERM terminal being used
PS1 primary prompt characters, usually $ or #
PS2 secondary prompt characters, usually >
$? return code of the last command executed
set displays current local variable settings
export exports variable so that they are inherited by child processes
env displays inherited variables
echo echo a message (for example, echo HI or echo $d).
Can turn off carriage returns with \c at the end of the message.
Can print a blank line with \n at the end of the message.
Tapes and Diskettes

dd reads a file in, converts the data (if required), and copies the file
out
fdformat formats diskettes or read/write optical media disks
flcopy copies information to and from diskettes
format AIX command to format a diskette
backup backs up individual files.
-i reads file names form standard input
-v list files as backed up;
for example, backup -iv -f/dev/rmto file1, file2
-u backup file system at specified level;
for example, backup -level -u filesystem
Can pipe list of files to be backed up into command.
for example, find . -print | backup -ivf/dev/rmt0 where
you are in directory to be backed up.
mksysb creates an installable image of the root volume group
restore restores commands from backup
-x restores files created with backup -i
-v list files as restore
-T list files stored of tape or diskette
-r restores filesystem created with backup -level -u;
for example, restore -xv -f/dev/rmt0

Instructor Guide
cpio copies to and from an I/O device. Destroys all data previously
on tape or diskette. For input, must be able to place files in the
same relative (or absolute) path name as when copied out (can
determine path names with -it option). For input, if file exists,
compares last modification date and keeps most recent (can
override with -u option).
-o (output) -i (input),
-t (table of contents) -v (verbose),
-d (create needed directory for relative path names)
-u (unconditional to override last modification date)
for example, cpio -o > /dev/fd0
file1
file2
<Ctrl-d>
or cpio -iv file1 < /dev/fd0
tapechk performs simple consistency checking for streaming tape drives
tcopy copies information from one tape device to another
tctl sends commands to a streaming tape device
tar alternative utility to backup and restore files
pax alternative utility to cpio and tar commands
Transmitting
mail send and receive mail. With userid sends mail to userid.
Without userid, displays your mail. When processing your mail,
at the ? prompt for each mail item, you can:
d - delete s - append
. q - quit enter - skip
m - forward
mailx upgrade of mail
uucp copy file to other UNIX systems (UNIX to UNIX copy)
uuto/uupick send and retrieve files to public directoryon)
uux execute on remote system (UNIX to UNIX execute)
System Administration
df display filesystem usage
installp install program

V3.1.0.1
Instructor Guide
Uempty kill (pid) kill batch process with id or (pid) (find using ps);
kill -9 (PID) will absolutely kill process
mount associate logical volume to a directory;
for example, mount device directory
ps -ef shows process status (ps -ef)
umount disassociate filesystem from directory
smit system management interface tool
Miscellaneous
banner displays banner
date displays current date and time
newgrp change active groups
nice assigns lower priority to following command
(for example, nice ps -f)
passwd modifies current password
sleep n sleep for n seconds
stty show and or set terminal settings
touch create a zero length files
xinit initiate X-Windows
wall sends message to all logged#in users.
who list users currently logged in (who am i identifies this user)
man,info displays manual pages
System Files
/etc/group list of groups
/etc/motd message of the day, displayed at login.
/etc/passwd list of users and signon information. Password shown as !. Can
prevent password checking by editing to remove !.
/etc/profile system wide user profile executed at login. Can override
variables by resetting in the user's .profile file.
/etc/security directory not accessible to normal users
/etc/security/environ user environment settings
/etc/security/group group attributes

Instructor Guide
/etc/security/limits user limits

/etc/security/login.cfg login settings
/etc/security/passwd user passwords
/etc/security/user user attributes, password restrictions
Shell Programming Summary
Variables
var=string set variable to equal string. (NO SPACES).
Spaces must be enclosed by double quotes.
Special characters in string must be enclosed by single quotes
to prevent substitution.
Piping (|), redirection (<, >, >>), and & symbols are not
interpreted.
$var gives value of var in a compound
echo displays value of var, for example, echo $var
HOME = home directory of user
MAIL = mail file mane
PS1 = primary prompt characters, usually $ or #
PS2 = secondary prompt characters, usually >
PATH = search path
TERM = terminal type being used
export exports variables to the environment
env displays environment variables settings
${var:-string} gives value of var in a command. If var is null, uses 'string'
instead.
$1 $2 $3... positional parameters for variable passed into the shell script
$* used for all arguments passed into shell script
$# number of arguments passed into shell script
$0 name of shell script
$$ process id (pid)
$? last return code from a command

V3.1.0.1
Instructor Guide
Uempty Commands
# comment designator
&& logical-and. Run command following && only if command
preceding && succeeds (return code = 0).
|| logical-or. Run command following || only if command
preceding || fails (return code < > 0).
exit n used to pass return code nl from shell script. Passed as
variable $? to parent shell
expr arithmetic expressions
Syntax: expr expression1 operator expression2
operators: + - \* (multiply) / (divide) % (remainder)
for loop for n (or: for variable in $*); for example,:
do
command
done
if-then-else if test expression
then command
elif test expression
then command
else
then command
fi
read read from standard input
shift shifts arguments 1-9 one position to the left and decrements
number of arguments
test used for conditional test, has two formats.
if test expression (for example, if test $# -eq 2)
if expression
(for example, if $# -eq 2 ") (spaces req'd)
integer operators:
-eq (=) -lt (<) -le (=<)
-ne (<>) -gt (>) -ge (=>)
string operators:
= != (not eq.) -z (zero length)
file status (for example, -opt file1)
-f (ordinary file)
-r (readable by this process)
-w (writable by this process)
-x (executable by this process)
-s (non#zero length)

Instructor Guide
while loop while test expression

do
command
done
Miscellaneous
sh execute shell script in the sh shell
-x (execute step by step - used for debugging shell scripts)
vi Editor
Entering vi
vi file edits the file named file
vi file file2 edit files consecutively (via :n)
.exrc file that contains the vi profile
wm=nn sets wrap margin to nn
Can enter a file other than at first line by adding + (last line), +n
(line n), or +/pattern (first occurrence of pattern).
vi -r lists saved files
vi -r file recover file named file from crash
:n next file in stack
:set all show all options
:set nu display line numbers (off when set nonu)
.:set list display control characters in file
:set wm=n set wrap margin to n
:set showmode sets display of INPUT when in input mode
Read, Write, Exit

.:w write buffer contents
:w file2 write buffer contents to file2
:w >> file2 write buffer contents to end of file2
:q quit editing session
:q! quit editing session and discard any changes

V3.1.0.1
Instructor Guide
Uempty :r file2 read file2 contents into buffer following current cursor
:r! com read results of shell command com following current cursor
:! exit shell command (filter through command)
:wq or ZZ write and quit edit session
Units of Measure
h, l character left, character right
k or <Ctrl>p move cursor to character above cursor
j or <Ctrl>n move cursor to character below cursor
w, b word right, word left
^, $ beginning, end of current line
<CR> or + beginning of next line
- beginning of previous line
G last line of buffer
Cursor Movements
Can precede cursor movement commands (including cursor arrow) with number of times to
repeat, for example, 9--> moves right 9 characters.
0 move to first character in line
$ move to last character in line
^ move to first nonblank character in line
fx move right to character x
Fx move left to character x
tx move right to character preceding character x
Tx move left to character preceding character x
; find next occurrence of x in same direction
, find next occurrence of x in opposite direction
w tab word (nw = n tab word) (punctuation is a word)
W tab word (nw = n tab word) (ignore punctuation)
b backtab word (punctuation is a word)
B backtab word (ignore punctuation)
e tab to ending char. of next word (punctuation is a word)

Instructor Guide
E tab to ending char. of next word (ignore punctuation)

( move to beginning of current sentence
) move to beginning of next sentence
{ move to beginning of current paragraph
} move to beginning of next paragraph
H move to first line on screen
M move to middle line on screen
L move to last line on screen
<Ctrl>f scroll forward 1 screen (3 lines overlap)
<Ctrl>d scroll forward 1/2 screen
<Ctrl>b scroll backward 1 screen (0 line overlap)
<Ctrl>u scroll backward 1/2 screen
G go to last line in file
nG go to line n
<Ctrl>g display current line number
Search and Replace

/pattern search forward for pattern
?pattern search backward for pattern
n repeat find in the same direction
N repeat find in the opposite direction
Adding Text
a add text after the cursor (end with <esc>)
A add text at end of current line (end with <esc>)
i add text before the cursor (end with <esc>)
I add text before first nonblank char in current line
o add line following current line
O add line before current line
<esc> return to command mode

V3.1.0.1
Instructor Guide
Uempty Deleting Text

<Ctrl>w undo entry of current word
@ kill the insert on this line
x delete current character
dw delete to end of current word (observe punctuation)
dW delete to end of current word (ignore punctuation)
dd delete current line
d erase to end of line (same as d$)
d) delete current sentence
d} delete current paragraph
dG delete current line through end-of buffer
d^ delete to the beginning of line
u undo last change command
U restore current line to original state before modification
Replacing Text
ra replace current character with a
R replace all characters overtyped until <esc> is entered
s delete current character and append test until <esc>.
s/s1/s2 replace s1 with s2 (in the same line only)
S delete all characters in the line and append text
cc replace all characters in the line (same as S)
ncx delete n text objects of type x; w, b = words,) = sentences, } =
paragraphs, $ = end-of-line,^ = beginning of line) and enter
append mode
C replace all characters from cursor to end-of-line.
Moving Text
p paste last text deleted after cursor (xp transposes two
characters)
P paste last text deleted before cursor

Instructor Guide
nYx yank n text objects of type x (w, b = words,) = sentences, } =

paragraphs, $ = end-of-line, and no x indicates lines. Can then
paste them with p command. Yank ? does not delete the
original.
"ayy can use named registers for moving, copying, cut/paste with
ayy for register a (use registers a-z). Can then paste them with
ap command.
Miscellaneous
. repeat last command
J join current line w/next line

V3.1.0.1
Instructor Guide
Uempty Appendix C. Bibliography

Albitz, Paul & Liu, Cricket (1997) DNS and BIND, O'Reilly & Associates
Callaghan, Brent (2000) NFS Illustrated, Addison-Wesley
Cheswick, William & Bellovin, Steven (1994) Firewalls and Internet Security: Repelling the
Wily Hacker. Addison-Wesley Publishing Company
Comer, Douglas E. (1995) Internetworking with TCP/IP, Vol.1: Principles, Protocols, and
Architecture, 3d ed., Prentice Hall
Cooper, Frederick et al. (1995) Implementing Internet Security, New Riders Publishing
Denning, Peter J., ed. (1990) Computers Under Attack: Intruders, Worms, and Viruses,
ACM Press
Ellis, Jim, Fraser, Barbara & Pesante, Linda (September 1994) 'Keeping Internet Intruders
Away,' UNIX Review 12, 9:35-44.
Garfinkel, Simson & Spafford, Gene (1996) Practical UNIX and Internet Security, O'Reilly &
Associates
Halabi, Bassam (1997) Internet Routing Architectures Cisco Press
Hunt, Craig (1998) TCP/IP Network Administration, O'Reilly & Associates
Huitema, Christian (1995) Routing in the Internet Prentice Hall
Kaufman, Charlie, Perlman, Radia & Speciner, Mike (1995) Network Security: Private
Communication in a Public World, PTR Prentice-Hall
Kercheval, Barry (1999), A Guide to Dynamic TCP/IP Network Configuration, Prentice Hall
Morris, R.T. & Thompson, K. (November 1979) 'Password Security: a Case History,'
Communications of the ACM 22, 11:594-597
Murphy, Eamon, Hayes, Steve, & Enders, Matthias (1995) TCP/IP Tutorial and Technical
Overview Prentice Hall
Nemeth, Evi; Snyder, Garth & Seebass, Scott (1995) UNIX System Administration
Handbook, 2nd ed., Prentice Hall
Siyan, Karanjit & Hare, Chris (1996) Internet Firewalls and Network Security, New Riders
Publishing
Stern, Hal (1991) Managing NFS and NIS O'Reilly & Associates
Stevens, W. Richard (1994) TCP/IP Illustrated, Vol.1: The Protocols, Addison-Wesley
Publishing Company
Stoll, Clifford (1989) The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer
Espionage, Doubleday
Copyright IBM Corp. 1997, 2006 Appendix C. Bibliography C-1

Instructor Guide
C-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
Uempty Appendix D. TCP/IP and NFS/NIS Commands and

Files
This appendix lists various AIX commands, daemons and files that are used by TCP/IP,
NFS and NIS. It is not a complete reference but does include many files described in the
manuals.
Some commands and files may be part of the Base Operating System rather than actually
belonging to the TCP/IP or NFS optional programs but their use is TCP/IP or NFS specific.
TCP/IP Commands
arp Display or change the Address Resolution Protocol tables
ate Invoke AIX Asynchronous Terminal Emulator
cu Invoke call UNIX terminal emulator
f Display user information (same as finger)
finger Display user information
ftp Use the FTP protocol to transfer a file
gettable Get NIC format host tables from a host
host Display internet address or hostname of a specified host
hostent Manipulate host entries
hostid Set or display the internet of a host
hostname Show and set the hostname
htable Convert NIC format hosts tables to /etc/hosts, /etc/networks,
and /etc/gateways
ifconfig Configure network interface
ipreport Generate a packet trace report
mkhosts Generate hosts table
mktcpip Configure and start initial TCP/IP configuration
named-xfer Used by named when acting as secondary name server to
obtain database
netstat Show network statistics
no Configure TCP/IP kernel network options
ping Send an ICMP packet to determine if a host is reachable
rcp Remote copy command
Copyright IBM Corp. 1997, 2006 Appendix D. TCP/IP and NFS/NIS Commands and Files D-1
Instructor Guide
rdist Maintain identical copies of files on remote hosts

rembak Remote printer backend program
remsh Execute commands on a remote host (same as rsh)
rexec Execute a command on a remote host
rlogin Login to a remote UNIX host
route Manipulate routing table
rsh Execute commands on a remote host (same as remsh)
ruptime Show status information on remote hosts
ruser Manipulate foreign host access files
rwho Show status information for users on remote hosts
securetcpip Enable TCP/IP security features
setclock Set date and time for a host
slattach Attach a serial line as a network interface
snmpinfo Requests or modifies values of MIB variables managed by
snmpd
talk Hold conversation with user on remote system
telnet Use TELNET protocol to login to a remote system (same as tn)
tftp Use TFTP protocol to transfer a file
timedc Control timed daemon
tn Same as telnet
tn3270 Use TELNET protocol to login to a remote System/370 system
utftp Use TFTP protocol to transfer a file
whois Internet directory service
TCP/IP Daemons
fingerd Provides remote user information
ftpd Provides server function for File Transfer Protocol (FTP)
gated Dynamic routing for RIP, EGP, HELLO, BGP and SNMP
protocols
inetd Provides internet service management
iptrace Trace internet packets
lpd Provides remote print service
D-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
Uempty named Provides server function for the Domain Name protocol
pppattachd Implements PPP protocol - one daemon per connection runs on
each AIX system
pppcontrold Manages PPP subsystem
rexecd Provides server function for the rexec command
rlogind Provides server function for the rlogin command
routed Dynamic routing for RIP protocol
rshd Provides server function for the rwho and ruptime commands
rwhod Provides server function for the rwho and ruptime commands
snmpd Simple Network Management Protocol Agent
syslogd Reads and logs system messages
talkd Provides server function for the talk command
telnetd Provides server function for the TELNET protocol
tftpd Provides server function for Trivial File Transfer Protocol
(TFTP)
timed Provides the time server function
TCP/IP Files
Note: All files are in the /etc directory unless otherwise noted
addrs.awk Shell script to convert /etc/hosts to domain data (in
/usr/samples/tcpip)
anon.ftp Shell script to set up anonymous ftp (in /usr/samples/tcpip)
ate.def Profile for ATE terminal emulator
chap-secrets (in /etc/ppp) Contains secrets (passwords) for use by PPP's
CHAP authentication
ftpusers List of users not authorized for use by remote ftp clients
gated.conf Configuration file for gated
gateways Configuration file for routed
hosts Mapping of IP addresses to host names
hosts.awk Shell script to convert /etc/hosts to domain data (in
/usr/samples/tcpip)
hosts.equiv List of hosts authorized for Berkeley remote operations
hosts.lpd List of hosts authorized for remote printing
Instructor Guide
inetd.conf List of subservers for inetd

map3270 Defines default keyboard mapping for telnet in 3270 mode
mib.defs Defines the MIB variables for the snmpinfo command
named.boot Initialization information for named
.netrc Specifies automatic login information for ftp and rexec (File
created in user's $HOME directory.)
networks Lists network name information sometimes used by routed
pap_secrets (in /etc/ppp) Contains secrets (passwords) for use by PPP's
authentication
protocols Defines internet protocol
README Hints and tips for TCP/IP (in /usr/samples/tcpip)
rc.net Shell script for network configuration
rc.tcpip Shell script to start TCP/IP daemons
resolv.conf Used by domain name resolver to locate name server
.rhosts Specifies remote users authorized by Berkeley remote
operations (File created in user's $HOME directory.)
rwho Directory where rwhod stores info about other systems (in
/usr/spool)
services Defines the sockets and protocols used for internet services
snmpd.conf Specifies configuration parameters for the snmpd agent
snmpd.peers Snmpd configuration for SMUX peers
tcp.clean Shell script that brings down TCP/IP daemons and interfaces
telnet.conf Terminal type mappings for telnet
tftpaccess.ctl Specifies files/directories tfpd will allow clients to access
3270.keys Describes default keyboard mapping and color for telnet in
3270 mode
NFS/NIS Commands
domainname Display or set the NIS domain name
exportfs Export or unexport directories for NFS
makedbm Make an NIS map
mkalias Convert NIS mail.aliases map to mail.byaddr map
mknfs Configures NFS

V3.1.0.1
Instructor Guide
Uempty mrgpwd Merges the /etc/passwd and /etc/security/passwd files for NIS
nfso Configures NFS kernel network options
nfsstat Displays NFS status information
on Executes commands on a remote machine
rmnfs Deconfigures and stops NFS
rpcgen Generate C code to implement RPC protocol
rpcinfo Reports the status of RPC servers
rup Reports status of remote hosts
rusers Reports users logged on to remote machines
rwall Sends messages to all users on a network
showmount Shows clients that have NFS filesystems mounted
spray Sends packets to a host to test network bandwidth and server
capability
ypcat Displays an NIS map
ypinit Sets up NIS maps on an NIS server
ypmatch Displays the value of a key within a map
yppasswd Changes the NIS password
yppoll Displays the NIS map order number (version stamp)
yppush Pushes maps to NIS slave servers
ypset Directs a client to a specific server
ypwhich Identifies the master server for maps
ypxfr Transfers a map from the NIS master server to a slave server
NFS/NIS Daemons
automount Automatically mounts NFS filesystems
biod NFS client block I/O daemon
nfsd NFS server request handler
portmap Maps RPC program numbers to port numbers
rpc.lockd Processes file locking requests via RPC
rpc.mountd Processes remote mount requests via RPC
rpc.pcnfsd Provides support for PC-NFS clients
rpc.rexd Handles requests for remote execution of command via RPC
Instructor Guide
rpc.rstatd Returns performance status via RPC

rpc.rusersd Handles requests from ruser command
rpc.rwalld Handles requests from rwall command
rpc.sprayd Receives packets sent by the spray command
rpc.statd Provides remote status information
rpc.yppasswdd Handles requests from yppasswd command
ypbind Provides NIS client function
ypserv Provides NIS server function
NFS/NIS Files
Note: All files are in the /etc directory unless otherwise noted.
exportfs Lists directories that can be exported to NFS clients
Makefile Makefile for NIS maps (in /etc/yp)
netgroup Lists groups of users on the network
nfs.clean Shell script that brings down NFS daemons
rc.nfs Shell script to start NFS and NIS daemons
rpc Contains database information for RPC programs
updaters Makefile for updating NIS maps (in /var/yp)
xtab Lists directories that are currently exported to NFS clients
ypxfr_1perday Sample script for running ypxfr on slave server through cron
once a day (in /usr/etc/yp)
ypxfr_1perhour Sample script for running ypxfr on slaver server through cron
once an hour (in /usr/etc/yp)
ypxfr_2perday Sample script for running ypxfr on slave server through cron
twice a day (in /usr/etc/yp)

V3.1.0.1
Instructor Guide
AP Appendix E. Summary of the no Command

no Command
Purpose
Manages network tuning parameters.
Syntax
no [ -p | -r ] { -o Tunable[=NewValue] }
no [ -p | -r ] {-d Tunable }
no [ -p | -r ] { -D }
no [ -p | -r ] -a
no -?
no -h [ Tunable ]
no -L [ Tunable ]
no -x [ Tunable ]
Note:
Multiple flags -o, -d, -x, and -L are allowed.
Description
Use the no command to configure network tuning parameters. The no command sets or
displays current or next boot values for network tuning parameters. This command can
also make permanent changes or defer changes until the next reboot. Whether the
command sets or displays a parameter is determined by the accompanying flag. The -o
flag performs both actions. It can either display the value of a parameter or set a new value
for a parameter. When the no command is used to modify a network option it logs a
message to the syslog using the LOG_KERN facility. For a more information on how the
network parameters interact with each other, refer to the AIX 5L Version 5.2 System
Management Guide: Communications and Networks.
Attention: Be careful when you use this command. If used incorrectly, the no command
can cause your system to become inoperable.
Copyright IBM Corp. 1997, 2006 Appendix E. Summary of the no Command E-1
Instructor Guide
Flags
-a Displays current, reboot (when used in conjunction with -r) or

permanent (when used in conjunction with -p) value for all tunable
parameters, one per line in pairs Tunable = Value. For the
permanent options, a value only displays for a parameter if its
reboot and current values are equal. Otherwise NONE displays as
the value.
-d Tunable Resets Tunable its to default value. If Tunable needs to be

changed (that is it is currently not set to its default value) and it is
of type Bosboot or Reboot, or if it is of type Incremental and has
been changed from its default value, and -r is not used in
combination, it is not changed but a warning displays instead.
-D Resets all tunables to their default value. If a tunable needing to

be changed are of type Bosboot or Reboot, or if they are of type
Incremental and have been changed from their default value, and
neither -p nor -r are used in combination, they will not be changed
but a warning displayed instead.
-h [Tuna- Displays help about Tunable parameter if one is specified.

ble] Otherwise, displays the no command usage statement.
-L [Tuna- Lists the characteristics of one or all Tunables, one per line, using
ble] the following format:
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
General Network Parameters
--------------------------------------------------------------------------------
sockthresh 85 85 85 0 100 %_of_thewall D
--------------------------------------------------------------------------------
fasttimo 200 200 200 50 200 millisecond D
--------------------------------------------------------------------------------
inet_stack_size 16 16 16 1 kbyte R
--------------------------------------------------------------------------------
...
where:
CUR = current value
DEF = default value
BOOT = reboot value
MIN = minimal value
MAX = maximum value
UNIT = tunable unit of measure
TYPE = parameter type: D (for Dynamic), S (for Static), R for Reboot),
B (for Bosboot), M (for Mount), I (for Incremental) and C (for Connect)
DEPENDENCIES = list of dependent tunable parameters, one per line
E-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

V3.1.0.1
Instructor Guide
AP -o Tun- Displays the value or sets the Tunable to NewValue. If a tunable

able [= needs to be changed (the specified value is different than current
NewValue] value), and is of type Bosboot or Reboot, or if it is of type
Incremental and its current value is bigger than the specified
value, and -r is not used in combination, it is not changed, but a
warning displays instead.
When -r is used in combination without a new value, the nextboot
value for Tunable is displayed. When -p is used in combination
without a new value, a value displays only if the current and next
boot values for tunable are the same Otherwise NONE displays as
the value.
-p Makes changes apply to both current and reboot values when

used in combination with -o, -d or -D, that is turns on updating of
the /etc/tunables/nextboot file in addition to the updating of the
current value. These combinations cannot be used on Reboot and
Bosboot type parameters because their current value can't be
changed.
When used with -a or -o without specifying a new value, values
displays only if the current and next boot values for a parameter
are the same. Otherwise NONE displays as the value.
-r Makes changes apply to reboot values when used in combination

with -o, -d or -D, that is it turns on the updating of the
/etc/tunables/nextboot file. If any parameter of type Bosboot is
changed, the user is prompted to run bosboot. When used with -a
or -o without specifying a new value, next boot values for tunables
display instead of the current values.
-x [Tun- Lists characteristics of one or all tunables, one per line, using the
able] following (spreadsheet) format:
tunable,current,default,reboot,min,max,unit,type,{dtunable }
where:
current = current value
default = default value
reboot = reboot value
min = minimal value
max = maximum value
unit = tunable unit of measure
type = parameter type: D (for Dynamic), S (for Static), R (for
Reboot), B (for Bosboot),
M (for Mount), I (for Incremental) and C (for Connect)
dtunable = space separated list of dependent tunable parameters
-? Displays the usage of the no command.
Instructor Guide
Any change (with -o, -d, or -D) to a parameter of type Mount results in a message
displaying to warn the user that the change is only effective for future mountings.
Any change (with -o, -d or -D flags) to a parameter of type Connect results in inetd being
restarted, and a message displaying to warn the user that the change is only effective for
future socket connections.
Any attempt to change (with -o, -d, or -D) a parameter of type Bosboot or Reboot without -r,
results in an error message.
Any attempt to change (with -o, -d, or -D but without -r) the current value of a parameter of
type Incremental with a new value smaller than the current value, results in an error
message.
Tunable Parameters Type

All the tunable parameters manipulated by the tuning commands (no, nfso, vmo, ioo, and
schedo) have been classified into these categories:
Dynamic If the parameter can be changed at any time
Static If the parameter can never be changed
Reboot If the parameter can only be changed during reboot
Bosboot If the parameter can only be changed by running bosboot and

rebooting the machine
Mount If changes to the parameter are only effective for future file
systems or directory mounts
Incre-
If the parameter can only be incremented, except at boot time
mental
Connect If changes to the parameter are only effective for future socket
connections
For parameters of type Bosboot, whenever a change is performed, the tuning commands
automatically prompt the user to ask if they want to execute the bosboot command. For
parameters of type Connect, the tuning commands automatically restart the inetd daemon.
Note that the current set of parameters managed by the no command only includes
Reboot, Static, Dynamic, Incremental, and Connect types.
Compatibility Mode
When running in pre 5.2 compatibility mode (controlled by the pre520tune attribute of
sys0, refer to Tuning Enhancements for AIX 5.2 in the AIX 5L Version 5.2 Performance
Management Guide), reboot values for parameters, except those of type Bosboot, are not
really meaningful because in this mode they are not applied at boot time.
In pre 5.2 compatibility mode, setting reboot values to tuning parameters continues to be

V3.1.0.1
Instructor Guide
AP achieved by imbedding calls to tuning commands in scripts called during the boot
sequence. Parameters of type Reboot can therefore be set without the -r flag, so that
existing scripts continue to work.
This mode is automatically turned ON when a machine is MIGRATED to AIX 5L Version
5.2. For complete installations, it is turned OFF and the reboot values for parameters are
set by applying the content of the /etc/tunables/nextboot file during the reboot sequence.
Only in that mode are the -r and -p flags fully functional. Refer to Kernel Tuning in the AIX
5L Version 5.2 Performance Tools Guide and Reference for details.
Instructor Guide
Network Tunable Parameters
arpqsize Purpose:
Specifies the maximum number of packets
to queue while waiting for ARP responses.
Values:
Default: 12
Range: 1 to MAXSHORT
Type: Dynamic
Diagnosis:
N/A
Tuning
This parameter is supported by Ethernet,
802.3, Token-Ring and FDDI interfaces.
The arpqsize value is increased to a mini-
mum value of 12 when path MTU discov-
ery is enabled. The value does not
automatically decrease if path MTU dis-
covery is subsequently disabled. This
parameter applies to AIX 4.1.5, AIX 4.2.1
and later
Refer To:
Managing Tunable SP Parameters
arpt_killc Purpose:
Specifies the time in minutes before a
Complete ARP entry is deleted.
Values:
Default: 20
Type: Dynamic
Diagnosis:
N/A
Tuning
To reduce ARP activity in a stable net-
work, you can increase arpt_killc.
Refer To:
SP System-Specific Tuning Recommen-
dations

V3.1.0.1
Instructor Guide
AP
arptab_bsiz Purpose:
Specifies Address Resolution Protocol
(ARP) table bucket size.
Values:
Default: 7
Type: Reboot
Diagnosis:
netstat -p arp shows the number of ARP
packets sent and the number of ARP
entries purged from the ARP table. If large
number of entries are being purged, the
ARP table size should be increased. Use
arp -a to show the ARP table hashing dis-
tribution.
Tuning
N/A
Refer To:
dations
Instructor Guide
arptab_nb Purpose:
Specifies the number of ARP table buck-
ets.
Values:
Default: 73
Type: Reboot
Diagnosis:
netstat -p arp shows the number of ARP
packets sent and the number of ARP
entries purged from the ARP table. If large
number of entries are being purged, the
ARP table size should be increased. Use
arp -a to show the ARP table hashing dis-
tribution.
Tuning
Increase this value for systems that have
a large number of clients or servers. The
default provides for 73 x 7 = 511 ARP
entries, but assumes an even hash distri-
bution.
Refer To:
dations
bcastping Purpose:
Allows response to ICMP echo packets to
the broadcast address.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
clean_partial_conns Purpose:
Specifies whether SYN (synchronizes the
sequence number) attacks are being
avoided.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
This option should be turned on for serv-
ers that need to protect against network
attacks. If on, randomly removes partial
connections to make room for new
non-attack connections.
Instructor Guide
delayack Purpose:
Delays acknowledgements (ACK) for cer-
tain TCP packets and attempts to piggy-
back them with the next packet sent
instead.
Values:
Default: 0
Range: 0 to 3
Type: Dynamic
Diagnosis:
N/A
Tuning
This action is only performed for connec-
tions whose destination port is specified in
the list of the delayackports parameter.
This can be used to increase performance
when communicating with an HTTP server
by reducing the total number of packets
sent. The parameter can have one of four
values:
0 No delays; normal operation
1 Delay the ACK for the server's SYN (Synchro-
nizes the sequence numbers)
2 Delay the ACK for the server's FIN (Sender
has reached the end of its byte stream)
3 Delay both the ACKs for the SYN and FIN.

V3.1.0.1
Instructor Guide
AP
delayackports Purpose:
Specifies the list of destination ports for
which the operation defined by the delay-
ack port option is performed.
Values:
Default: {}
Range: List of port numbers (maximum 10)
Type: Dynamic
Diagnosis:
N/A
Tuning
The parameter takes a list of up to ten
ports, separated by commas and enclosed
in curly braces. For example:
no -o delayackports={80,30080}
To clear the list, set the option to {}.
dgd_packets_lost Purpose:
Specifies how many consecutive packets
must be lost before Dead Gateway Detec-
tion decides that a gateway is down.
Values:
Default: 3
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
dgd_ping_time Purpose:
Specifies how many seconds should pass
between pings of a gateway by Active
Dead Gateway Detection.
Values:
Default: 5
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
dgd_retry_time Purpose:
Specifies how many minutes a route's cost
should remain raised when it has been
raised by Passive Dead Gateway Detec-
tion. After this many minutes pass, the
route's cost is restored to its user-config-
ured value.
Values:
Default: 5
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
directed_broadcast Purpose:
Specifies whether to allow a directed
broadcast to a gateway.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The value of 1 allows packets to be
directed to a gateway to be broadcast on a
network on the other side of the gateway.
extendednetstats Purpose:
Enables more extensive statistics for net-
work memory services.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Reboot
Diagnosis:
N/A
Tuning
The default for this parameter is 0, for off,
because these extra statistics cause a
reduction in system performance on SMP
systems.
Instructor Guide
fasttimo Purpose:
Allows you to set the millisecond delay for
the TCP fast time-out timer. This time-out
controls how often the system scans the
TCP control blocks to send delayed
acknowledgments.
Values:
Default: 200
Range: 50 to 200 milliseconds
Type: Dynamic
Diagnosis:
N/A
Tuning
Reducing this timer value may improve
performance with some non-IBM systems.
However, this may also result in slightly
increased system utilization.
icmp6_errmsg_rate Purpose:
Specifies the upper limit for the number of
ICMP v6 error messages that can be sent
per second. This prevents excessive
bandwidth being used by ICMP v6 error
messages.
Values:
Default: 10 msg/sec
Range: 1 to 255
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
icmpaddressmask Purpose:
Specifies whether the system responds to
an ICMP address mask request.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
If the default value 0 is set, the network
silently ignores any ICMP address mask
request that it receives.
ie5_old_multicast_mapping Purpose:
Specifies IP multicasts on Token-Ring
should be mapped to the broadcast
address rather than a functional address
when value 1 is used.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
ifsize Purpose:
Specifies the maximum number of net-
work interface structures per interface of a
single type (for example, Ethernet).
Values:
Default: 256
Range: 8 to 1024
Type: Reboot
Diagnosis:
N/A
Tuning
The ifsize needs to be large on machines
that support hotplug adapters and on
DLPAR configurations because adapters
can be added on the fly and the static
interface tables must be large enough to
accept the worst case number of adapters
that may be added for this system or parti-
tion.
Refer To:
Managing Tunable SP Parameters

V3.1.0.1
Instructor Guide
AP
inet_stack_size Purpose:
Specifies size of inet interrupt stack table
in kilobytes.
Values:
Default: 16
Type: Reboot
Diagnosis:
N/A
Tuning
This is needed if you were running with
unoptimized debug kernel or the netinet
kernel extension. This is different from the
pin more stack code (which is not config-
urable) because this is on interrupt. This
parameter only needs to be changed if
there is a system panic due to interrupt
stack overflow.
ipforwarding Purpose:
Specifies whether the kernel should for-
ward packets.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
Set this parameter to 1, if the system is
acting as an IP router.
Refer To:
traceroute command
Instructor Guide
ipfragttl Purpose:
Specifies the time to live for IP fragments
in half-seconds.
Values:
Default: 60
Range: 60 to 255
Type: Dynamic
Diagnosis:
Fragments dropped after time-out (netstat
-p ip).
Tuning
If value of IP: fragments dropped after
time-out is nonzero, increasing ipfragttl
may reduce retransmissions.
Refer To:
IP Layer
ipignoreredirects Purpose:
Specifies whether to process redirects that
are received.
Values:
Default: 0 (does redirects)
Range: 0 or 1 (1 ignores redirects)
Type: Dynamic
Diagnosis:
N/A
Tuning
This option only applies to AIX 4.2.1 or
later.

V3.1.0.1
Instructor Guide
AP
ipqmaxlen Purpose:
Specifies the number of received packets
that can be queued on the IP protocol
input queue.
Values:
Default: 100
Range: 100 to MAXINT
Type: Reboot
Diagnosis:
Examine ipintrq overflows (netstat -s) or
use crash to access IP input queue over-
flow counter.
Tuning
Increase size if system is using a lot of
loopback sessions. Most operating system
network drives call IP directly and do not
use the IP queue. On these devices
increasing ipqmaxlen has no effect.
Refer To:
IP Layer and IP Protocol Performance
Tuning Recommendations
ipsendredirects Purpose:
Specifies whether the kernel should send
redirect signals.
Values:
Default: 1 (send redirects)
Range: 0 (do not send redirects) or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
This is a configuration decision with per-
formance consequences.
Instructor Guide
ipsrcrouteforward Purpose:
Specifies whether the system forwards
source-routed packets.
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The default value of 1 allows the forward-
ing of source-routed packets. A value of 0
causes all source-routed packets that are
not at their destinations to be discarded.
This parameter only applies to AIX 4.2.1
or later.
ipsrcrouterecv Purpose:
Specifies whether the system accepts
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The default value of 0 causes all
source-routed packets destined for this
system to be discarded. A value of 1
allows source-routed packets to be
received. This parameter only applies to
AIX 4.2.1 or later.

V3.1.0.1
Instructor Guide
AP
ipsrcroutesend Purpose:
Specifies whether applications can send
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The default value of 1 allows
source-routed packets to be sent. A value
of 0 causes setsockopt() to return an error
if an application attempts to set the source
routing option, and removes any source
routing options from outgoing packets.
or later.
ip6_defttl Purpose:
Specifies the default hop count that is
used for Internet Protocol Version 6 (IPv6)
packets if no other hop count is specified.
Values:
Default: 64
Range: 1 to 255
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
ip6_prune Purpose:
Specifies how often to check the IPv6
routing table for expired routes in seconds.
Values:
Default: 1
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
ip6forwarding Purpose:
Specifies whether the kernel should for-
ward IPv6 packets.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The default value of 0 prevents forwarding
of IPv6 packets when they are not for the
local systems. A value of 1 enables for-
warding.

V3.1.0.1
Instructor Guide
AP
ip6srcrouteforward Purpose:
Specifies whether the system forwards
source-routed IPv6 packets.
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The default value of 1 allows the forward-
ing of source-routed packets. A value of 0
causes all source-routed packets that are
not at their destinations to be discarded.
llsleep_timeout Purpose:
Specifies time-out value in seconds for link
local time-outs (used when
multi_homed=1)
Values:
Default: 3
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
main_if6 Purpose:
Specifies the interface to use for link local
addresses. This is only used by
autoconf6 to set up initial routes.
Values:
Default: 0
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
main_site6 Purpose:
Specifies the interface to use for site local
address routing. This is only used if
multi_homed is set to 3
Values:
Default: 0
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
maxnip6q Purpose:
Specifies the maximum number of IPv6
packet-reassembly queues.
Values:
Default: 20
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
maxttl Purpose:
Specifies the time to live for Routing Infor-
mation Protocol (RIP) packets in seconds.
Values:
Default: 255
Range: 1 to 255
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
multi_homed Purpose:
Specifies the level of multihomed IPv6
host support.
Values:
Default: 1
Range: 0 to 3
Type: Dynamic
Diagnosis:
N/A
Tuning
This is only performed for connections
whose destination port is specified in the
list of the delayackports parameter. This
can be used to increase performance
when communicating with an HTTP
server. The parameter can have one of
four values:
0 - Indicates the original functionality in AIX 4.3.
1 - Indicates that link local addresses are
resolved by querying each interface for the
link local address.
2 - Indicates that link local addresses are only
examined for the interface defined by
main_if6.
3 - Indicates that link local addresses are only
examined for the interface defined by
main_if6, and site local addresses are only
routed for the main_site6 interface.
Instructor Guide
nbc_limit Purpose:
Specifies the total maximum amount of
memory that can be used for the Network
Buffer Cache (NBC) in Kbytes.
Values:
Default: derived from thewall
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
When the cache grows to this limit, the
least-used caches are flushed out of
cache to make room for the new ones.
or later. NBC is only used by the
send_file() API and some Web servers
that use the get engine in the kernel.
nbc_max_cache Purpose:
Specifies the maximum size of the cache
object allowed in the Network Buffer
Cache (NBC) in bytes.
Values:
Default: 131072 (128K) if nbc_limit is not zero,
otherwise 0
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
Data object bigger than this size is not be
put in the NBC. This parameter only
applies to AIX 4.3.2 or later. NBC is only
used by the send_file() API and some
Web servers that use the get engine in the
kernel.

V3.1.0.1
Instructor Guide
AP
nbc_min_cache Purpose:
Specifies the minimum size of the cache
object allowed in the Network Buffer
Cache (NBC) in bytes.
Values:
Default: 1 byte if nbc_limit is not zero, other-
wise 0
Range: 1 to 131072 (128K)
Type: Dynamic
Diagnosis:
N/A
Tuning
Data object smaller than this size is not be
put in the NBC. This parameter only
applies to Version 4.3.2 or later. NBC is
only used by the send_file() API and
some Web servers that use the get engine
in the kernel
Instructor Guide
nbc_ofile_hashsz Purpose:
Specifies the size of the hash table (num-
ber of slots) used for hashing cache
objects in the Network Buffer Cache. This
hash table size applies to only opened file
entries, that is, entries that cache files
from the filesystem. Since this attribute
resizes the hash table size and affects the
hashing of all existing entries, it can only
be modified when the Network Buffer
Cache is empty. If the Network Buffer
Cache is not empty, this option will return
an error.
Values:
Default: 12841
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning:
Hash table sizes are generally chosen to
be prime as this results in a more even
distribution of hash table entries.

V3.1.0.1
Instructor Guide
AP
nbc_pseg Purpose:
(AIX 4.3.3 and later) Specifies the maximum number of private
segments that can be created for the Net-
work Buffer Cache (NBC).
Values:
Default: 0
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
When this option is set to a nonzero value,
data objects with size between the size
specified in nbc_max_cache and the seg-
ment size (256 MB) are cached in a pri-
vate segment. Data objects bigger than
the segment size are not cached at all.
When this many private segments exist in
NBC, cache data in private segments may
be flushed for new cache data so the num-
ber of private segments does not exceed
the limit. When this option is set to 0, all
cache in private segments are flushed.
Instructor Guide
nbc_pseg_limit Purpose:
(AIX 4.3.3 and later) Specifies the maximum total cached data
size (KB) allowed in private segments in
the Network Buffer Cache (NBC).
Values:
Default: 131072
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
Because data cached in private segments
will be pinned by the Network Buffer
Cache, this option provides a control on
the amount of pinned memory used for
Network Buffer Cache in addition to the
network buffers in global segments. When
this limit is met, cache data in private seg-
ments may be flushed for new cache data
so the total pinned memory size does not
exceed the limit. When this option is set to
0, all cache in private segments are
flushed.
ndpqsize Purpose:
Specifies the number of packets to hold
waiting on completion of a Neighbor Dis-
covery Protocol (NDP) entry (used by
MTU Path Discovery).
Values:
Default: 50
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
ndpt_down Purpose:
Specifies the time, in half-seconds, to hold
down a Neighbor Discovery Protocol
(NDP) entry. This network option is obso-
lete in AIX 5.2 and later versions.
Values:
Default: 3 (1.5 seconds)
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
ndpt_keep Purpose:
Specifies the time, in half seconds, to
keep a Neighbor Discovery Protocol
(NDP) entry.
Values:
Default: 120 (60 seconds)
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
ndp_mmaxtries Purpose:
Specifies the maximum number of Multi-
cast NDP packets to send.
Values:
Default: 3
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
ndpt_probe Purpose:
Specifies the time, in half-seconds, to
delay before sending the first Neighbor
Discovery Protocol (NDP) probe.
Values:
Default: 5 (2.5 seconds)
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
ndpt_reachable Purpose:
Specifies the time, in half-seconds, to test
if a Neighbor Discovery Protocol (NDP)
entry is still valid.
Values:
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
ndpt_retrans Purpose:
Specifies the time, in half-seconds, to wait
before retransmitting a Neighbor Discov-
ery Protocol (NDP) request.
Values:
Default: 1 (half a second)
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
ndpt_umaxtries Purpose:
Specifies the maximum number of Unicast
NDP packets to send.
Values:
Default: 3
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
net_malloc_police Purpose:
Specifies the size of the net_malloc and
net_free trace buffers.
Values:
Default: 0
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
If the value of this variable is non-zero, all
net_malloc and net_free buffers will be
traced in a kernel buffer and by system
trace hook HKWD_NET_MALLOC. Addi-
tional error-checking will also be enabled.
This includes checks for freeing a free
buffer, alignment, and buffer overwrite.
Enable this parameter only when investi-
gating some network problem, because
performance is affected negatively when
turned on. The default value is zero (polic-
ing off). Values of net_malloc_police
larger than 1024 allocate that many items
in the kernel buffer for tracing.
Instructor Guide
nonlocsrcroute Purpose:
Tells the Internet Protocol that strictly
source-routed packets may be addressed
to hosts outside the local network.
Values:
Default: 0
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
A default value of 0 disallows addressing
to outside hosts. The value of 1 allows
packets to be addressed to outside hosts.
Loosely source-routed packets are not
affected by this parameter. This is a con-
figuration decision with minimal perfor-
mance consequences.
passive_dgd Purpose:
Specifies whether Passive Dead Gateway
Detection is enabled. A value of 0 turns it
off, and a value of 1 enables it for all gate-
ways in use.
Values:
Default: 0
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
pmtu_default_age Purpose:
Specifies the default amount of time (in
minutes) before the path MTU value for
UDP paths is checked for a lower value.
Values:
Default: 10
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of zero allows no aging. The
default value is 10 minutes. The
pmtu_default_age value can be overrid-
den by UDP applications. This parameter
only applies to AIX 4.2.1 or later.
pmtu_rediscover_interval Purpose:
Specifies the default amount of time (in
minutes) before the path MTU value for
UDP and TCP paths are checked for a
higher value.
Values:
Default: 30
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of 0 allows no path MTU rediscov-
ery. The default value is 30 minutes. This
parameter only applies to AIX 4.2.1 or
later.
Instructor Guide
rfc1122addrchk Purpose:
Performs address validation as specified
by RFC1122 (Requirements for Internet
Hosts-Communication Layers).
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
The default value of 0 does not perform
address validation. A value of 1 performs
address validation.

V3.1.0.1
Instructor Guide
AP
rfc1323 Purpose:
Enables window scaling and timestamps
as specified by RFC 1323 (TCP Exten-
sions for High Performance). Window
scaling allows the TCP window sizes
(tcp_recvspace and tcp_sendspace) to
be larger than 64 KB (65536) and is typi-
cally used for large MTU networks.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Connect
Diagnosis:
N/A
Tuning
The default value of 0 disables the RFC
enhancements on a systemwide scale. A
value of 1 specifies that all TCP connec-
tions attempt to negotiate the RFC
enhancements. The SOCKETS applica-
tion can override the default behavior on
individual TCP connections, using the set-
sockopt subroutine. Make changes
before attempting to set tcp_sendspace
and tcp_recvspace to more than 64 KB.
Refer to:
TCP Socket Buffer Tuning
Instructor Guide
rfc2414 Purpose:
Enables the increasing of TCP's initial win-
dow as described in RFC 2414. When it is
on, the initial window depends on the set-
ting of the tunable tcp_init_window.
Values:
Default: 0 (off)
Range: 0 or 1 (on)
Type: Connect
Diagnosis:
N/A
Tuning
N/A
route_expire Purpose:
Specifies whether unused routes created
by cloning, or created and modified by
redirects expire.
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of 1 allows route expiration, which
is the default. Negative values are not
allowed for this option.
Refer to:
Tuning TCP Maximum Segment Size

V3.1.0.1
Instructor Guide
AP
routerevalidate Purpose:
Specifies that each connection's cached
route should be revalidated each time a
new route is added to the routing table.
This ensures that applications that keep
the same connection open for long periods
of time (for example, NFS) use the correct
route after routing-table changes occur.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
If there is communication loss between
HACMP nodes or between NFS client and
server, routes may have been changed
but the values in the cache are being
used.
Tuning
The default value of 0 does not revalidate
the cached routes. Turning on this option
may cause some performance degrada-
tion. Value should be set to 1 for HACMP.
rto_high Purpose:
Specifies the TCP Retransmit time-out
high value used in calculating factors and
the maximum retransmittals allowable
used in TCP data segment retransmittals.
Values:
Default: 64
Range: 2 to MAXINT
Type: Reboot
Diagnosis:
N/A
Tuning
The rto_high parameter is the high factor.
Instructor Guide
rto_length Purpose:
length value used in calculating factors
and the maximum retransmittals allowable
Values:
Default: 13
Range: 1 to 64
Type: Reboot
Diagnosis:
N/A
Tuning
The rto_length parameter is the total
number of time segments.
rto_limit Purpose:
limit value used in calculating factors and
the maximum retransmittals allowable
Values:
Default: 7
Range: 1 to 64
Type: Reboot
Diagnosis:
N/A
Tuning
The rto_limit parameter is the number of
time segments from rto_low to rto_high.

V3.1.0.1
Instructor Guide
AP
rto_low Purpose:
Specifies the TCP Retransmit time-out low
value used in calculating factors and the
maximum retransmittals allowable used in
TCP data segment retransmittals.
Values:
Default: 1
Range: 1 to 63
Type: Reboot
Diagnosis:
N/A
Tuning
The rto_low parameter is the low factor.
sack Purpose:
(AIX 4.3.3 and later) Specifies if Selective Acknowledgment is
on.
Values:
Default: 0 (off)
Range: 0 or 1
Type: Connect
Diagnosis:
N/A
Tuning
Normal TCP has to retransmit all packets
after a dropped packet. With large window
sizes, this can result in lost performance if
many packets are dropped. Selective Ack
enables code to selectively retransmit the
lost packets. If there are a lot of retrans-
mits of fragments and the receive buffer
sizes are large, then it might be beneficial
to turn this parameter on. This is a TCP
negotiated option, so it must be supported
on both endpoints before it is used.
Instructor Guide
sb_max Purpose:
Specifies the maximum buffer size allowed
for a TCP and UDP socket. Limits set-
sockopt, udp_sendspace,
udp_recvspace, tcp_sendspace, and
tcp_recvspace.
Values:
Default: 1048576 bytes
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
Increase size, preferably to multiple of
4096. Should be approximately two to four
times the largest socket buffer limit.
Refer to:
TCP Socket Buffer Tuning and Tuning
Other Layers to Improve NFS Perfor-
mance
send_file_duration Purpose:
Specifies the cache validation duration for
all the file objects that the send_file sys-
tem call accessed in the Network Buffer
Cache (in seconds).
Values:
Default: 300 (5 minutes)
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of 0 means that the cache is vali-
dated for every access. This parameter
only applies to AIX 4.3.2 or later.

V3.1.0.1
Instructor Guide
AP
site6_index Purpose:
Specifies the maximum interface number
for site local routing.
Values:
Default: 0
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
sockthresh Purpose:
Specifies the maximum amount of network
memory that can be allocated for sockets.
Used to prevent new sockets or TCP con-
nections from exhausting all MBUF mem-
ory and reserve the remaining memory for
the existing sockets or TCP connections.
Values:
Default: 85 percent
Range: 0 to 100
Type: Dynamic
Diagnosis:
N/A
Tuning
When the total amount of memory allo-
cated by the net_malloc subroutine
reaches this threshold, the socket and
socketpair system calls fail with an error
of ENOBUFS. Incoming connection
requests are silently discarded. Existing
sockets can continue to use additional
memory. The sockthresh parameter repre-
sents a percentage of the thewall parame-
ter, with possible values of 1 to 100 and a
default of 85.
Refer to:
Socket Layer
Instructor Guide
sodebug Purpose:
Specifies whether the newly created sock-
ets have SO_DEBUG flag on.
Values:
Default: 0 (no)
Range: 0 or 1 (yes)
Type: Connect
Diagnosis:
N/A
Tuning
N/A
somaxconn Purpose:
Specifies the maximum listen backlog.
Values:
Default: 1024 connections
Type: Connect
Diagnosis:
N/A
Tuning
Increase this parameter on busy Web
servers to handle peak connection rates.

V3.1.0.1
Instructor Guide
AP
subnetsarelocal Purpose:
Specifies whether all subnets that match
the subnet mask are to be considered
local for purposes of establishing, for
example, the TCP maximum segment
size.
Values:
Default: 1 (yes)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
This parameter is used by the
in_localaddress subroutine. The default
value of 1 specifies that addresses that
match the local network mask are local. If
the value is 0, only addresses matching
the local subnetwork are local. This is a
configuration decision with performance
consequences. If the subnets do not all
have the same MTU, fragmentation at
bridges may degrade performance. If the
subnets do have the same MTU, and sub-
netsarelocal is 0, TCP sessions may use
an unnecessarily small MSS.
Refer to:
Instructor Guide
tcp_bad_port_limit Purpose:
Specifies the number of TCP packets to a
port with no socket that can be received in
a 500 millisecond period before TCP stops
sending resets in response to such pack-
ets. When it is set as its default value 0,
resets will always be sent when TCP
packets are received for a bad port num-
ber.
Values:
Default: 0
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
tcp_ecn Purpose:
Enables TCP level support for Explicit
Congestion Notification as described in
RFC 2481. Default is off (0). Turning it on
(1) makes all connections negotiate ECN
capability with the peer. For this feature to
work you need support from the peer TCP
and also IP level ECN support from the
routers in the path.
Values:
Default: 0 (off)
Range: 0 or 1 (on)
Type: Connect
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
tcp_ephemeral_high Purpose:
Specifies the largest port number to allo-
cate for TCP ephemeral ports.
Values:
Default: 65535
Range: 32769 to 65535
Type: Dynamic
Diagnosis:
N/A
Tuning
The number of ephemeral sockets is
determined by tcp_ephemeral_high
minus tcp_ephemeral_low. For maximum
number of ephemeral sockets, set
tcp_ephemeral_high to 65535 and
tcp_ephemeral_low to 1024.
Refer to:
Socket Layer
tcp_ephemeral_low Purpose:
Specifies the smallest port number to allo-
cate for TCP ephemeral ports.
Values:
Default: 32768
Range: 1024 to 65534
Type: Dynamic
Diagnosis:
N/A
Tuning
The number of ephemeral sockets is
determined by tcp_ephemeral_high
minus tcp_ephemeral_low. For maxi-
mum number of ephemeral sockets, set
tcp_ephemeral_high to 65535 and
tcp_ephemeral_low to 1024.
Refer to:
Socket Layer
Instructor Guide
tcp_finwait2 Purpose:
Specifies the length of time to wait in the
FIN_WAIT2 state before closing the con-
nection, measured in half seconds.
Values:
Default: 1200 half-seconds
(600 seconds or 10 minutes)
Range: 0 to USHORTMAX
Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
tcp_init_window Purpose:
This value is used only when rfc2414 is
turned on (ignored otherwise). If rfc2414 is
on and this value is zero, then the initial
window computation is done according to
rfc2414. If this value is non-zero, the ini-
tial(congestion) window is initialized a
number of maximum sized segments
equal to tcp_init_window.
Values:
Default: 0
Type: Connect
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
tcp_inpcb_hashtab_siz Purpose:
Specifies the size of the inpcb hash table
for TCP connections. This table holds the
inpcbs required for connection manage-
ment and is implemented as a table of
hash chains. A large table means that the
linked hash chains are small and lower the
traversal time on average, but the memory
footprint is larger.
Values:
Default: 24999
Range:1 to 999999
Type: Reboot
Diagnosis:
N/A
Tuning:
This option impacts performance and
should be used with extreme caution.
Please consult a performance analyst in
case the value needs to be changed. The
execution environment could have an
influence on the value. It is strongly
encouraged to maintain the sys-
tem-defined defaults, because they tend
to execute optimally in most environ-
ments.
tcp_keepcnt Purpose:
Represents the number of keepalive
probes that could be sent before terminat-
ing the connection.
Values:
Default: 8
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
Instructor Guide
tcp_keepidle Purpose:
Specifies the length of time to keep an idle
TCP connection active, measured in
half-seconds.
Values:
Default: 14400 (2 hours)
Range: 1 to MAXINT
Type: Connect
Diagnosis:
N/A
Tuning
This is a configuration decision with mini-
mal performance consequences. No
change is recommended.
tcp_keepinit Purpose:
Sets the initial time-out value for a TCP
connection in half-seconds.
Values:
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
tcp_keepintvl Purpose:
Specifies the interval, measured in
half-seconds, between packets sent to
validate the TCP connection.
Values:
Type: Connect
Diagnosis:
N/A
Tuning
This is a configuration decision with mini-
mal performance consequences. No
change is recommended. If the interval
were shortened significantly, processing
and bandwidth costs might become signifi-
cant.
tcp_limited_transmit Purpose:
Enables the feature that enhances TCP's
loss recovery as described in the RFC
3042.
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
tcp_maxburst Purpose:
Specifies the number of back-to-back
packets that TCP can send before pausing
to allow those packets to be forwarded to
their destination. This can be useful if rout-
ers are unable to handle large bursts of
TCP packets and are dropping some of
them. A value of 0 means no limitation for
back-to-back packets before pausing.
Values:
Default: 0
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
tcp_mssdflt Purpose:
Default maximum segment size used in
communicating with remote networks.
Values:
Default: 512 bytes
Range: 1 to 1448
Type: Connect
Diagnosis:
N/A
Tuning
For AIX 4.2.1 or later, tcp_mssdflt is only
used if path MTU discovery is not enabled
or path MTU discovery fails to discover a
path MTU. Limiting data to (MTU - 52)
bytes ensures that, where possible, only
full packets are sent.
Refer to:

V3.1.0.1
Instructor Guide
AP
tcp_nagle_limit Purpose:
This is the Nagle Algorithm threshold in
bytes which can be used to disable Nagle.
Values:
Default: 65535 - maximum size of IP packet
Range: 0 to 65535
Type: Dynamic
Diagnosis:
N/A
Tuning
The default (65535 - the maximum size of
IP packet) is Nagle turned on. To disable
Nagle, set this value to 0 or 1. TCP dis-
ables Nagle for data segments larger than
or equal to this threshold value.
tcp_ndebug Purpose:
Specifies the number of tcp_debug struc-
tures.
Values:
Default: 100
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
tcp_newreno Purpose:
Enables the modification to TCP's Fast
Recovery algorithm as described in RFC
2582. This fixes the limitation of TCP's
Fast Retransmit algorithm to recover fast
from dropped packets when multiple pack-
ets in a window are dropped. sack also
achieves the same thing but sack needs
support from both ends of the TCP con-
nection; the NewReno modification is only
on the sender side.
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
tcp_nodelayack Purpose:
Turning this parameter on causes TCP to
send immediate acknowledgement (Ack)
packets to the sender. When
tcp_nodelayack is off, TCP delays send-
ing Ack packets by up to 200ms. This
allows the Ack to be piggy-backed onto a
response and minimizes system over-
head.
Values:
Default: 0(off)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
This option can be used to overcome bugs
in other implementations of the TCP nagle
algorithm. Setting this option to 1 causes
slightly more system overhead, but can
result in much higher performance for net-
work transfers if the sender is waiting on
the receiver's acknowledgement.
Instructor Guide
tcp_pmtu_discover Purpose:
Enables or disables path MTU discovery
for TCP applications.
Values:
Default: 1 (0 before AIX 4.3.3)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of 0 disables path MTU discovery
for TCP applications, while a value of 1
enables it. This parameter only applies to
AIX 4.2.1 or later.
Refer to:

V3.1.0.1
Instructor Guide
AP
tcp_recvspace Purpose:
Specifies the system default socket buffer
size for receiving data. This affects the
window size used by TCP.
Values:
Range: 4096 to 1048576
Type: Connect
Diagnosis:
N/A
Tuning
Setting the socket buffer size to 16 KB
(16,384) improves performance over stan-
dard Ethernet and Token-Ring networks.
Lower bandwidth networks, such as Serial
Line Internet Protocol (SLIP), or higher
bandwidth networks, such as Serial Opti-
cal Link, should have different optimum
buffer sizes. The optimum buffer size is
the product of the media bandwidth and
the average round-trip time of a packet.
For high speed networks, like gigabit
Ethernet or ATM 622, a value of 65536
should be used for the minimum size for
best performance.
The tcp_recvspace parameter must
specify a socket buffer size less than or
equal to the setting of the sb_max param-
eter. The ISNO options for each interface
also override this global setting. For val-
ues larger than 65536, you must enable
rfc1323 (rfc1323=1) to enable TCP win-
dow scaling.
Refer to:
Instructor Guide
tcp_sendspace Purpose:
Specifies the system default socket buffer
size for sending data.
Values:
Range: 4096 to 1048576
Type: Connect
Diagnosis:
N/A
Tuning
This affects the window size used by TCP.
Setting the socket buffer size to 16 KB
(16,384) improves performance over stan-
dard Ethernet and Token-Ring networks.
Lower bandwidth networks, such as Serial
Line Internet Protocol (SLIP), or higher
bandwidth networks, such as Serial Opti-
cal Link, should have different optimum
buffer sizes. The optimum buffer size is
the product of the media bandwidth and
the average round-trip time of a packet:
optimum_window=bandwidth *
average_round_trip_time
For high speed networks, like gigabit

Ethernet or ATM 622, a value of 65536
should be used for the minimum size for
best performance.
The tcp_sendspace parameter must
eter. The ISNO options for each interface
will also override this global setting. For
values larger than 65536, you must enable
rfc1323 (rfc1323=1) to enable TCP win-
dow scaling.
Refer to:

V3.1.0.1
Instructor Guide
AP
tcp_timewait Purpose:
The tcp_timewait option is used to config-
ure how long connections are kept in the
timewait state in 15-second intervals.
Values:
Default: 1
Range: 1 to 5
Type: Dynamic
Diagnosis:
N/A
Tuning
Increasing this value degrades perfor-
mance of Web servers or applications that
open and close a lot of TCP connections.
tcp_ttl Purpose:
Specifies the time to live for TCP packets.
Values:
Default: 60 ticks (100 ticks per minute)
Range: 1 to 255
Type: Connect
Diagnosis:
netstat -s
Tuning
If the system is experiencing TCP
time-outs, increasing tcp_ttl may reduce
retransmissions.
Instructor Guide
thewall Purpose:
Specifies the maximum amount of mem-
ory, in kilobytes, that is allocated to the
memory pool.
Values:
Default: AIX 5.1 and later:
1/2 of RAM or 64 GB (whichever is
smaller) for 64-bit kernel
1/2 of RAM or 1 GB (whichever is
smaller) for 32-bit kernel
Range: N/A
Type: Static
Diagnosis:
N/A
Tuning
Not settable from AIX 5.1 and later.
Refer to:
Tuning mbuf Pool Performance
udp_bad_port_limit Purpose:
Specifies the number of UDP packets to a
port with no socket that can be received in
a 500 millisecond period before UDP
stops sending ICMP errors in response to
such packets. If set to 0, ICMP errors will
always be sent when UDP packets are
received for a bad port number. If greater
than 0, it specifies the number of packets
to be received before UDP stops sending
ICMP errors.
Values:
Default: 0
Range: 0 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A

V3.1.0.1
Instructor Guide
AP
udp_ephemeral_high Purpose:
Specifies the largest port number to allo-
cate for UDP ephemeral ports.
Values:
Default: 65535
Range: 32769 to 65535
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Refer to:
Socket Layer
udp_ephemeral_low Purpose:
Specifies the smallest port number to allo-
cate for UDP ephemeral ports.
Values:
Default: 32768
Range: 1 to 65534
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Refer to:
Socket Layer
Instructor Guide
udp_inpcb_hashtab_siz Purpose:
Specifies the size of the inpcb hash table
for UDP connections. This table holds the
inpcbs required for connection manage-
ment and is implemented as a table of
hash chains. A large table means that the
linked hash chains are small and lower the
traversal time on average, but the memory
footprint is larger.
Values:
Default: 24999
Range: 1 to 83000
Type: Reboot
Diagnosis:
N/A
Tuning:
This option impacts performance and
should be used with extreme caution.
Please consult a performance analyst in
case the value needs to be changed. The
execution environment could have an
influence on the value. It is strongly
encouraged to maintain the sys-
tem-defined defaults because they tend to
execute optimally in most environments.

V3.1.0.1
Instructor Guide
AP
udp_pmtu_discover Purpose:
Enables or disables path MTU discovery
for UDP applications.
Values:
Default: 1 (0 before AIX 4.3.3)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
UDP applications must be specifically writ-
ten to use path MTU discovery. A value of
0 disables the feature, while a value of 1
enables it. The default value is 0. This
parameter only applies to AIX 4.2.1 or
later.
udp_recvspace Purpose:
Specifies the system default socket-buffer
size for receiving UDP data.
Values:
Range: 4096 to 1048576
Type: Connect
Diagnosis:
Nonzero n in netstat -s report of udp: n
socket buffer overflows
Tuning
The udp_recvspace parameter must
eter. Increase size, preferably to multiple
of 4096.
Refer to:
UDP Socket Buffer Tuning
Instructor Guide
udp_sendspace Purpose:
Specifies the system default socket-buffer
size for sending UDP data.
Values:
Default: 9216 bytes
Range: 4096 to 1048576
Type: Connect
Diagnosis:
N/A
Tuning
The udp_sendspace parameter must
eter. Increase size, preferably to multiple
of 4096.
Refer to:
UDP Socket Buffer Tuning
udp_ttl Purpose:
Specifies the time to live for UDP packets.
Values:
Default: 30 second
Range: 1 to 255
Type: Connect
Diagnosis:
N/A
Tuning
N/A
udpcksum Purpose:
Allows UDP checksum to be turned on/off.
Values:
Default: 1
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of 0 turns it off; while a value of 1
turns it on.

V3.1.0.1
Instructor Guide
AP
use_isno Purpose:
(AIX 4.3.3 and later) Allows per interface tuning options.
Values:
Default: 1 (on)
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
A value of 1 means it is on, 0 is off. If the
TCP tunable parameters per interface
(tunable through SMIT or the chdev com-
mand) have been set, they override the
TCP global values if use_isno is set to 1.
Application can still override all of these
with the setsockopt subroutine.
Refer to:
Interface-Specific Network Options (ISNO)
Instructor Guide
Streams Tunable Parameters
lowthresh Purpose:
Specifies the maximum number of bytes that can be allo-
cated using the allocb call for the BPRI_LO priority.
Values:
Default: 90 (percent of thewall)
Range: 0 to 100
Type: Dynamic
Diagnosis:
N/A
Tuning
When the total amount of memory allocated by the
net_malloc call reaches this threshold, then the allocb
request for the BPRI_LO priority returns 0. The
lowthresh parameter represents a percentage of the
thewall parameter, and you can set its value from 0 to
100.
medthresh Purpose:
Specifies the maximum number of bytes that can be allo-
cated using the allocb() call for the BPRI_MED priority.
Values:
Default: 95 (percent of thewall)
Range: 0 to 100
Type: Dynamic
Diagnosis:
N/A
Tuning
When the total amount of memory allocated by the
net_malloc call reaches this threshold, then the allocb
request for the BPRI_MED priority returns 0. The
medthresh parameter represents a percentage of the
thewall parameter, and you can set its value from 0 to
100.

V3.1.0.1
Instructor Guide
AP
nstrpush Purpose:
Specifies the maximum number (should be at least 8) of
modules that you can push onto a single stream.
Values:
Default: 8
Type: Reboot
Diagnosis:
N/A
Tuning
N/A
psebufcalls Purpose:
Specifies the maximum number of bufcalls to allocate by
streams.
Values:
Default: 20
Range: 20 to MAXINT
Type: Incremental
Diagnosis:
N/A
Tuning
The stream subsystem allocates certain number of bufcall
structures at initialization. When the allocb call fails, the
user can register their requests for the bufcall call. You
cannot lower this value until the system reboots, at which
time it returns to its default value.
psecache Purpose:
Controls the number of stream buffers.
Values:
Default: 1
Range: 0 or 1
Type: Dynamic
Diagnosis:
N/A
Tuning
N/A
Instructor Guide
pseintrstack Purpose:
Specifies the maximum size of the interrupt stack allowed
by streams while running in the offlevel.
Values:
Default: 0x3000 (decimal 12288)
Range: 12288 to MAXINT
Type: Reboot
Diagnosis:
N/A
Tuning
When a process running other than INTBASE level enters
into a stream, it occasionally encounters a stack overflow
problem because the interrupt stack size is too small. Set-
ting this parameter correctly reduces the chances of stack
overflow problems.
psetimers Purpose:
Specifies the maximum number of timers to allocate by
streams.
Values:
Default: 20
Range: 20 to MAXINT
Type: Incremental
Diagnosis:
N/A
Tuning
The stream subsystem allocates a certain number of
timer structures at initialization, so that the streams driver
or module can register their time-out calls. You cannot
lower this value until the system reboots, at which time it
returns to its default value.

V3.1.0.1
Instructor Guide
AP
strctlsz Purpose:
Specifies the maximum number of bytes of information
that a single system call can pass to a stream to place
into the control part of a message (in an M_PROTO or
M_PCPROTO block).
Values:
Default: 1024
Type: Dynamic
Diagnosis:
N/A
Tuning
A putmsg call with a control part exceeding this size will
fail with ERANGE.
strmsgsz Purpose:
Specifies the maximum number of bytes of information
that a single system call can pass to a stream to place
into the data part of a message (in M_DATA blocks).
Values:
Default: 0
Type: Dynamic
Diagnosis:
N/A
Tuning
Any write call exceeding this size is broken into multiple
messages. A putmsg call with a data part exceeding this
size will fail with ERANGE.
Instructor Guide
strthresh Purpose:
Specifies the maximum number of bytes that streams are
normally allowed to allocate, expressed as a percentage
of thewall.
Values:
Default: 85% of thewall
Range: 0 to 100
Type: Dynamic
Diagnosis:
N/A
Tuning
When the threshold is exceeded, it does not allow users
without the appropriate privilege to open streams, push
modules, or write to streams devices, and returns
ENOSR. The threshold applies only to output side and
does not affect data coming into the system (for example,
the console continues to work correctly). A value of zero
means that there is no threshold. The strthresh parame-
ter represents a percentage of the thewall parameter,
and you can set its value from 0 to 100. The thewall
parameter indicates the maximum number of bytes that
can be allocated by streams and sockets using the
net_malloc call.
Refer to:
Tuning Network Memory

V3.1.0.1
Instructor Guide
AP
strturncnt Purpose:
Specifies the maximum number of requests handled by
the current running thread for Module- or Elsewhere-level
streams synchronization.
Values:
Default: 15
Range: 1 to MAXINT
Type: Dynamic
Diagnosis:
N/A
Tuning
With Module-level synchronization, only one thread can
run in the module at any time, and all other threads which
try to acquire the same module enqueue their requests
and exit. After the current running thread completes its
work, it dequeues all the previously enqueued requests
one by one and invokes them. If there is a large number
of requests enqueued in the list, then the current running
thread has to serve everyone and will always be busy
serving others and starves itself. To avoid this situation
the current running thread serves only the strturncnt num-
ber of threads, following that, a separate kernel thread
wakes up and invokes all the pending requests.
Examples
1. To display the maximum size of the mbuf pool, type:
no -o thewall
2. To reset the time to live for UDP packets its default size, type:
no -d udp_ttl
3. To change the default socket buffer sizes on your system, type:

no -r -o tcp_sendspace=32768
no -r -o udp_recvspace=32768
5. To use a machine as an internet work router over TCP/IP networks, type:

no -o ipforwarding=1
6. To list the current and reboot value, range, unit, type and dependencies of all tun-
ables parameters managed by the no command, type:
no -L
Instructor Guide
7. To display help information on udp_ephemeral_high, type:

no -h udp_ephemeral_high
8. To permanently turn off ip6srcrouteforward, type:

no -p -o ip6srcrouteforward=0
9. To list the reboot values for all Network tuning parameters, type:
no -r -a
10. To list (spreadsheet format) the current and reboot value, range, unit, type and
dependencies of all tunables parameters managed by the no command, type:
no -x
Related Information
The ifconfig command, the inetd command, the vmo command, the ioo command, the
schedo command, the tunsave command, the tunchange command, the tunrestore
command, the tuncheck command, the tundefault command.
The setsockopt subroutine.
Network Overview for System Management in AIX 5L Version 5.2 System Management
Guide: Communications and Networks.
TCP/IP Addressing, TCP/IP Protocols, and TCP/IP Routing, Internet Protocol (IP),
Transmission Control Protocol (TCP), Internet Application-Level Protocols, and User
Datagram Protocol (UDP) in AIX 5L Version 5.2 System Management Guide:
Communications and Networks.
Monitoring and Tuning Communications I/O Use in AIX 5L Version 5.2 Performance
Management Guide.
Path MTU Discovery in AIX 5L Version 5.2 System Management Guide: Communications
and Networks.
Kernel Tuning in AIX 5L Version 5.2 Performance Tools Guide and Reference.
Tuning Enhancements for AIX 5.2 in the AIX 5L Version 5.2 Performance Management
Guide.

Instructor Guide
Glossary
A B
Acknowledgement A response sent by a receiver Baseband Characteristic of any network technology
to indicate successful reception of information. like Ethernet that uses a single carrier frequency
Acknowledgements may be implemented at any and requires all stations attached to the network to
level including the physical level (using voltage on participate in every transmission. See broadband.
one or more wires to coordinate transfer), at the link Baud Literally, the number of times per second the
level (to indicate successful transmission across a signal can change on a transmission line.
single hardware link), or at higher levels (for Commonly, the transmission line uses only two
example, to allow an application program at the final signal states (for example, two voltages), making the
destination to respond to an application program at baud rate equal to the number of bits per second
the source). that can be transferred. The underlying transmission
Address Mask A bit mask used to select bits from technique may use some of the bandwidth, so it may
an Internet address for subnet addressing. The not be the case that users experience data transfers
mask is 32 bits long and selects the network portion at the line's specified bit rate. For example, because
of the Internet address and one or more bits of the asynchronous lines require 10 bit-times to send an
local portion. 8-bit character, a 9600 bps asynchronous
Address Resolution Conversion of an Internet transmission line can only send 960 characters per
address into a corresponding physical address. second.
Depending on the underlying network, resolution BBN (Bolt, Beranek, and Newman, Incorporated)
may require broadcasting on a local network. See The Cambridge, MA company responsible for
ARP. development, operation, and monitoring of the
ANSI (American National Standards Institute) A ARPANET and, later, Internet core gateway system.
group that defines U.S. standards for the information CSNET Coordination and Information Center (CIC),
processing industry. ANSI participates in defining and NSFnet Network Service Center (NNSC). BBN
network protocol standards. works on DARPA research contracts and has
contributed much to the Internet.
Archie A server that builds an index of file and
directory names that are located on public Best-effort Delivery Characteristic of network
anonymous FTP servers on the Internet. technologies that do not provide reliability at link
levels. Best-effort delivery systems work well with
ARP (Address Resolution Protocol) The Internet the Internet because the Internet protocols assume
protocol used to dynamically bind a high level that the underlying network provides unreliable
Internet Address to a low level physical hardware connectionless delivery. The combination of Internet
address. ARP is only across a single physical protocols IP and UDP provides best-effort delivery
network and is limited to networks that support service to application programs.
hardware broadcast.
Big endian A format for storage or transmission of
ARPA (Advanced Projects Research Agency) binary data in which the most-significant byte (bit)
Former name of DARPA, the government agency comes first. The TCP/IP standard network byte
that funded the ARPANET and, later, the DARPA order is big endian. Also see little endian.
Internet. The group within ARPA with responsibility
for the ARPANET was IPTO (Information Processing BISYNC (Binary SYNchronous Communication)
Techniques Office), later ISTO (Information Systems An early, low level protocol developed by IBM and
Technology Office). Located at 1400 Wilson Blvd, used to transmit data across a synchronous
Arlington, VA. communication link. Unlike most modern link level
protocols, BISYNC is byte-oriented, meaning that it
ARPANET A pioneering long haul network funded uses special characters to mark the beginning and
by ARPA (later DARPA) and built by BBN. It served end of frames. BISYNC is often called BSC,
from 1969 through 1990 as the basis for early especially in commercial products.
networking research as well as a central backbone
during development of the Internet. The ARPANET BITNET (Because It's Time NETwork) A low-cost,
consisted of individual packet switch nodes low-speed network started at City University of New
interconnected by leased lines. Also see PSN, York, that eventually connected to over 200
Internet. universities before it was merged with CSNET to
produce CREN. BITNET attached to EARN in
Authority Zone A part of the domain name Europe. The technology consists of (mostly IBM)
hierarchy for which a single name server is the mainframe computers interconnected by 9600 bps
authority. leased lines. The fundamental paradigm is remote
Autonomous System Internet terminology for a job entry: one machine sends a set of card images
collection of gateways (routers), that fall under one which the receiver treats as a remote job to be
administrative entity and cooperate using a common executed. When the job runs, it produces a new set
Interior Gateway Protocol (IGP). of card images and sends them on to the next site,
where they are treated as a remote job. BITNET
Copyright IBM Corp. 1997, 2006 Glossary X-1

Instructor Guide
provides services like electronic mail by building a of the packet by recomputing the checksum and
remote job that invokes the mailer router program. comparing to the value sent. Many Internet protocols
At each node, the mailer examines the message, use a 16-bit checksum computed with one's
chooses a route, and encapsulates the message in complement arithmetic with all integer fields in the
a new job that it sends over the chosen route. packet stored in network byte order.
bps (bits per second) A measure of the rate of data Client-server The model of interaction in a
transmission. distributed system in which a program at one site
Bridge A computer that connects two or more sends a request to a program at another site and
networks and forwards packets among them. awaits a response. The requesting program is called
Usually, bridges operate at the physical network a client; the program satisfying the request is called
level. For example, an Ethernet bridge connects two the server. It is usually easier to build client software
physical Ethernet cables and forwards from one than server software.
cable to the other exactly those packets that are not CMOT (CMip/cmis Over Tcp) The use of ISO
local. Bridges differ from repeaters because bridges CMIP/CMIS network management protocols to
store and forward complete packets while repeaters manage gateways in a TCP/IP internet. CMOT is a
forward electrical signals. They differ from IP co-recommended standard with SNMP. Also see
gateways or IP routers because they use physical MIB and SNMP.
addresses instead of IP addresses. Connection The path between two protocol
Broadband Characteristic of any network modules that provides reliable stream delivery
technology that multiplexes multiple, independent service. In a TCP/IP Internet, a connection extends
network carriers onto a single cable (usually using from a TCP module on one machine to a TCP
frequency division multiplexing). For example, a module on the other.
single 100 mbps broadband cable can be divided Connectionless Service Characteristic of the
into ten 1 0 mbps carriers, with each treated as an packet delivery service offered by most hardware
independent Ethernet. The advantage of broadband and by the Internet Protocol (IP). The
is less cable; the disadvantage is higher cost for connectionless service treats each packet or
equipment at connections. See baseband. An datagram as a separate entity that contains the
analog signalling technique used in IEEE Token Bus source and destination address. Usually,
LANs. Analog techniques allow a single medium to connectionless services can drop packets or deliver
be used for several information signals at once just them out of sequence.
as, for example, in cable TV systems.
Core Gateway One of a set of gateways operated
Broadcast A packet delivery system that delivers a by the Internet Network Operations Center (INOC)
copy of a given packet to all hosts that attach to it is at BBN. Gateways in the core system exchange
said to broadcast the packet. Broadcast may be routing updates periodically to ensure that their
implemented with hardware (for example, as in routing tables remain consistent. The core forms a
Ethernet) or with software (for example, as in central part of Internet routing in that all groups must
Cypress). advertise paths to their networks to core gateways
BSC (Binary Synchronous Communication) See using the Exterior Gateway Protocol.
BISYNC. Bus A linear topology for a local area CREN (Consortium for Research and Education
network wiring scheme. Network) The name of the organization that
resulted when BITNET and CSNET merged.
C CSMA (Carrier Sense Multiple Access) A
characteristic of network hardware that operates by
CITT (Consultative Committee on International allowing multiple stations to contend for access to a
Telephony and Telegraphy) An international transmission medium by listening to see if it is idle.
organization that sets standards for interconnection
of telephone equipment. It defined the standards for CSMA/CD (Carrier Sense Multiple Access with
X.25 network protocols (Note: in Europe, PTTs offer Collision Detection) A characteristic of network
both voice telephone services and X.25 network hardware that uses CSMA access combined with a
services). mechanism that allows the hardware to detect when
two stations simultaneously attempt transmission.
Channel A path for electrical transmission. Ethernet is an example of a well-known network
Baseband systems provide a single channel on a based on CSMA/CD technology. The technique
physical medium. Broadband systems provide used by Ethernet stations to control access to their
multiple channels (by use of frequency division) on a shared communication channel. They listen before
physical medium. transmitting (and refrain from using the channel if it's
Checksum A small, integer value computed from a already in use), and listen during transmission (to
sequence of octets by treating them as integers and determine whether their own signal is being
computing the sum. A checksum is used to detect corrupted by somebody else's). If such a collision is
errors that result when the sequence of octets is detected, the station will stop its transmission and
transmitted from one machine to another. Typically, attempt it again sometime later.
protocol software computes a checksum and CSNET (Computer Science NETwork) A network
appends it to a packet when transmitting. Upon that offered mail delivery service using dialup
reception, the protocol software verifies the contents telephone, as well as Internet connectivity using
X-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

Instructor Guide
X25NET and Cypress. CSNET offered other addresses. DNS also supports separate mappings
services like a registry of members and an Internet between mail destinations and IP addresses.
domain name server for member institutions that Domain In the Internet, a part of the DNS naming
could not run their own. Initially funded by the hierarchy. Syntactically, a domain name consists of
National Science Foundation, CSNET became a sequence of names (labels) separated by periods
self-sufficient before it merged with BITNET to form (dots).
CREN. Dotted Decimal Notation The syntactic
representation for a 32-bit integer that consists of
four 8-bit numbers written in base 10 with periods
D (dots) separating them. Many Internet application
DARPA (Defense Advanced Projects Research programs accept dotted decimal notation in place of
Agency) Formerly called ARPA. The government destination machine names.
agency that funded research and experimentation DTE (Data Terminal Equipment) Term X.25
with the ARPANET and, later, the DARPA Internet. protocol standards apply to computers and/or
The group within DARPA responsible for the terminals to distinguish them from the packet
ARPANET is ISTO (Information Systems switching network to which they connect. Also see
Techniques Office), formerly IPTO (Information DCE.
Processing Techniques Office). Located at 1400
Wilson Blvd, Arlington, VA. Datagram See IP
datagram. E
DCA (Defense Communication Agency) The EARN (European Academic Research Network)
government agency responsible for installation of A network using BITNET technology to connect
Defense Data Network (for example, ARPANET and universities and research labs in Europe. EARN
MILNET) lines and PSNs. DCA writes contracts for interconnects with BITNET in the U.S. and allows
operation of the DDN and pays for network services. electronic mail transfer as well as remote job entry.
DCE (Data Communications Equipment) Term EGP (Exterior Gateway Protocol) The protocol
X.25 protocol standards apply to switching used by a gateway in one autonomous system to
equipment that forms a packet switched network to advertise the Internet addresses of networks in that
distinguish it from the computers or terminals that autonomous system to a gateway in another
connect to the network. Also see DTE. autonomous system. Every autonomous system
DDCMP (Digital Data Communication Message must use EGP to advertise network reachability to
Protocol) The link-level protocol Digital Equipment the core gateway system.
Corporation uses in their network products. DDCMP EIA (Electronics Industry Association) A
operates over serial lines, delimits frames by a standards organization for the electronics industry.
special character, and includes checksums at the Known for RS232C and RS422 standards that
link level. It is relevant to the Internet because the specify the electrical characteristics of
original NSFNET used DDCMP over its backbone interconnections between terminals and computers
lines. or between two computers.
DDN (Defense Data Network) Used loosely to refer Email A convenient, fast, and inexpensive method
to the MILNET, ARPANET, and the TCP/IP protocols of sending and receiving messages across a
they use. More literally, it is the MILNET and network to any Internet user.
associated parts of the connected Internet that
connect military installations. Encapsulation The technique used by layered
protocols in which a lower-level protocol accepts a
Demultiplex To separate from a common input into message from a higher-level protocol and places it
several outputs. Demultiplexing occurs at many in the data portion of the low-level frame.
levels. Hardware demultiplexes signals from a Encapsulation often means that packets traveling
transmission line based on time or carrier frequency across a physical network have a sequence of
to allow multiple, simultaneous transmissions across headers in which the first header comes from the
a single physical cable. Internet protocol software physical network frame, the next from the Internet
demultiplexes incoming datagrams, sending each to Protocol, the next from the transport protocol, and
the appropriate high-level protocol module or so on.
application program.
Epoch Date A point in history chosen as the date
Directed broadcast address An IP address that from which time is measured. The Internet uses
specifies all hosts on a specific network. A single January 1, 1900, Universal Time (formerly called
copy of a directed broadcast is routed to the Greenwich Mean Time) as its epoch date.
specified network where it is broadcast to all Throughout the Internet, when programs exchange
machines on that network. date or time of day they express time as the number
DNS (Domain Naming System) The online of seconds past the epoch date.
distributed database system used to map Ethernet A popular local area network technology
human-readable machine names into IP addresses. invented at the Xerox Corporation Palo Alto
DNS servers throughout the connected Internet Research Center. An Ethernet itself is a passive
implement a hierarchical namespace that allows coaxial cable; the interconnections contain all active
sites freedom in assigning machine names and components. Ethernet is a best-effort delivery

Instructor Guide
system that uses CSMA/CD technology. Xerox refer to the objects that physical networks transmit,
Corporation, Digital Equipment Corporation, and even if the network does not use traditional framing.
Intel Corporation developed and published the (X.25 networks use the term to specifically refer to
standard for 10 Mbps Ethernet. Originally, the the format of data transferred between a host and a
coaxial cable specified for Ethernet was a 1/2 inch packet switch.)
diameter heavily shielded cable. However, many FTP (File Transfer Protocol) The Internet
office environments now use a lighter coaxial cable standard, high level protocol for transferring files
sometimes called thinnet or cheapernet. It is also from one machine to another. Usually implemented
possible to run Ethernet over shielded twisted pair as application level programs, FTP uses the
cable. A baseband, CSMA/CD local area network TELNET and TCP protocols. The server side
which allows up to 1,024 stations to send frames to requires a client to supply a login identifier and
one another with digital signalling rates of 10 million password before it will honor requests.
bits per second.
Fuzzball Term applied to both a piece of gateway
software and the Digital Equipment Corporation
F LSI-11 computer on which it runs. NSFnet uses
fuzzballs as packet switches on its backbone
FDDI (Fiber Distribution Data Interface) An network.
emerging standard for a network technology based
on fiber optics that has been established by the FYI (For Your Information) A subset of the RFCs
American National Standards Institute (ANSI). FDDI that are not technical standards or descriptions of
specifies a 100 mbps data rate using 1300 protocols. FYIs convey general information about
nanometer light wavelength and limits networks to topics related to TCP/IP or the connected Internet.
approximately 200 km in length, with repeaters
every 2 km or less. The access control mechanism
uses token-ring technology. G
File Server A process running on a computer that gated (GATEway Daemon) A program that runs
provides access to files on that computer to under 4.3 BSD UNIX on a gateway to allow the
programs running on remote machines. The term is gateway to collect information from within one
often loosely applied to computers that run file autonomous system using RIP, HELLO, or other
server programs. interior gateway protocols, and to advertise routes to
another autonomous system using the exterior
finger A command that shows user information on gateway protocol, EGP.
either a local system or other systems within a
network. Gateway A special purpose, dedicated computer
that attaches to two or more networks and routes
Flat Namespace Characteristic of any naming in packets from one to the other. In particular, an IP
which object names are selected from a single set of gateway routes IP datagrams among the networks
strings (for example, street names in a typical city). to which it connects. Gateways route packets to
Flat naming contrasts with hierarchical naming in other gateways until they can be delivered to the
which names are divided into subsections that final destination directly across one physical
correspond to the hierarchy of authority that network. The term is loosely applied to any machine
administers them (for example, telephone numbers that transfers information from one network to
that are divided into area code, exchange, and another, as in mail gateway. Although the original
subscriber). literature used the term gateway, vendors often
Flow Control Control of the rate at which hosts or called them IP routers.
gateways inject packets into a network or internet, A device, or pair of devices, which interconnect two
usually to avoid congestion. Flow control or more networks or subnetworks enabling the
mechanisms can be implemented at various levels. passage of data from one (sub)network to another.
Simplistic schemes like ICMP source quench simply A gateway contains an IP module, a routing protocol
ask the sender to cease transmission until module and (for each connected subnetwork) a
congestion ends. More complex schemes vary the Subnetwork Protocol module (SNP). The routing
transmission rate continuously. protocol is used to coordinate with other gateways.
Fragment One of the pieces that results when an GGP (Gateway to Gateway Protocol) The protocol
Internet gateway divides an IP datagram into smaller core gateways use to exchange routing information,
pieces for transmission across a network that cannot GGP implements a distributed shortest path routing
handle the original datagram size. Fragments use computation. Under normal circumstances, all GGP
the same format as datagrams; fields in the IP participants will reach a steady state in which the
header declare whether a datagram is a fragment, routing information at all gateways agrees. GGP is
and if so, the offset of the fragment in the original now obsolete.
datagram. IP software at the receiving end must
reassemble fragments into complete datagrams. Gopher An Internet navigation tool that allows you
to search the Internet by selecting resources from a
Frame Literally, a packet as it is transmitted across menu on a public Gopher server.
a serial line. The term derives from character
oriented protocols that added special start-of-frame
and end-of-frame characters when transmitting
packets. We use the term throughout this book to

Instructor Guide
H case, Internet refers specifically to the connected

Internet and the TCP/IP protocols it uses.
Hardware Address The low-level addresses used
by physical networks. Each type of network Internet The collection of networks and gateways,
hardware has its own addressing scheme. For including the MILNET, and NSFNET, that use the
example, Ethernet uses 48-bit hardware addresses TCP/IP protocol suite and function as a single,
assigned by the vendor, while proNET-10 uses small cooperative virtual network. The Internet provides
integer hardware addresses assigned when a universal connectivity and three levels of network
connection to the network is installed. services: unreliable, connectionless packet delivery;
reliable, full duplex stream delivery; and application
HELLO The protocol used by a group of level services like electronic mail that build on the
cooperative, trusting packing switches to allow them first two. The Internet reaches many universities,
to discover minimal delay routes. It is important to government research labs, and military installations
the Internet primarily because fuzzballs on the and over a dozen countries.
NSFnet backbone use it.
Internet Address See IP address.
Hierarchical Routing Routing that is based on a
hierarchical addressing scheme. Most Internet InterNIC A group responsible for providing users
routing is based on a 2-level hierarchy in which an with information about TCP/IP and the connected
Internet address is divided into a network portion Internet. The InterNIC registers new users and
and a host portion. Gateways use only the network domains, assigns network numbers, and distributes
portion until the datagram reaches a gateway that RFCs and other documents related to TCP/IP.
can deliver it directly. Subnetting introduces IP (Internet Protocol) The Internet standard
additional levels of hierarchical routing. protocol that defines the Internet datagram as the
Hop Count A measure of distance between two unit of information passed across the Internet and
points in the Internet. A hop count of n means that n provides the basis for the Internet connectionless,
gateways separate the source and destination. best-effort packet delivery service. IP includes ICMP
control and error message protocol as an integral
Host Any computer system that connects to a part. The Internet protocol suite is often referred to
network, particularly a source or destination of as TCP/IP because IP is one of the two most
messages on a communications network. fundamental protocols.
IP Address The 32-bit address assigned to hosts
that want to participate in the Internet using TCP/IP.
I Internet addresses are the abstraction of physical
IAB (Internet Architecture Board) A group who set hardware addresses just as the Internet is an
policy and standards for TCP/IP and the connected abstraction of physical networks. Actually assigned
Internet. The IAB was reorganized in 1989, with to the interconnection of a host to a physical
technical people moved to research and engineering network, an Internet address consists of a network
subgroups. See IRTF and IETF. portion and a host portion. The partition makes
ICMP (Internet Control Message Protocol) An routing efficient.
integral part of the Internet Protocol (IP) that handles IP Datagram The basic unit of information passed
error and control messages. Specifically, gateways across the Internet. An IP datagram is to the Internet
and hosts use ICMP to send reports of problems as a hardware packet is to a physical network. It
about datagrams back to the original source that contains a source and destination address along
sent the datagram. ICMP also includes an echo with data.
request/reply used to test whether a destination is
ISO (International Standards Organization) An
reachable and responding. international body that drafts, discusses, proposes,
IGP (Interior Gateway Protocol) The generic term and specifies standards for network protocols. ISO
applied to any protocol user to propagate network is best known for its 7-layer reference model that
reachability and routing information within an describes the conceptual organization of protocols
autonomous system. Although there is no single and its slowly emerging suite of protocols for Open
standard IGP, RIP is among the most popular. System Interconnection. The OSI protocols most
inetd Provides Internet service management for a like the TCP/IP protocol suite are known as TP-4/IP.
network. It invokes other daemons, such as telnet ISO Reference Model The International Standards
and ftp, only when they are needed. Organization Reference Model for Open Systems
INOC (Internet Network Operations Center) A Interconnection A standard approach to network
subgroup of the NOC at BBN that monitors and design which introduces modularity by dividing the
controls the Internet core gateway system. The complex set of functions into more manageable,
INOC measures traffic flow, tests reachability, self-contained, functional layers, as follows:
monitors routing tables, and controls downloading of 1. Physical Layer the level at which
the new gateway software.
internet Physically, a collection of packet switching protocols provide the mechanical and
networks interconnected by gateways along with electrical means by which devices are
protocols that allow them to function logically as a
single, large, virtual network. When written in upper physically connected and data is
transmitted.

Instructor Guide
2. Data Link Layer the level at which Level 3 A reference to transport level
communication derived from the ISO 7-layer
information is moved reliably across the reference model. For TCP/IP internets, level 3 refers
physical link. to IP and the IP datagram format. Thus, a level 3
address is an IP address.
3. Network Layer the level at which Little Endian A format for storage or transmission of
connections between systems are binary data in which the least significant byte (bit)
comes first. See big endian.
established, maintained and terminated;
concerned with switching and routing
information.
M
Mail Bridge Used loosely to refer to any mail
4. Transport Layer the level at which gateway. Technically, a mail bridge screens mail
passing between two networks to ensure that it
end-to-end data integrity and quality of meets administrative constraints. In particular, mail
service are ensured. bridges between the ARPANET and MILNET do not
permit arbitrary mail flow.
5. Session Layer the level which Mail Exploder Part of an electronic mail system that
accepts a piece of mail and a list of addresses as
standardizes the tasks of setting up a input and sends a copy of the message to each
session and terminating it; coordinates address on the list. Most electronic mail systems
incorporate a mail exploder to allow users to define
interaction between end-application mailing lists locally.
processes. Mail Gateway A machine that connects to two or
more electronic mail systems (especially dissimilar
6. Presentation Layer the level at which mail systems on two different networks) and
the character set and data code are transfers mail messages among them. Mail
gateways usually capture an entire mail message,
specified as well as the way data is reformat it according to the rules of the destination
displayed on a screen or printer. mail system, and then forward the message. See
mail bridge.
7. Application Layer concerned with the MAN (Metropolitan Area Network) Any of several
new physical network technologies that operate at
higher level functions which provide high speeds (usually hundreds of megabits per
support to the application of system second) over distances sufficient for a metropolitan
area. See LAN and WAN.
activities.
mbps (Millions of Bits Per Second) A measure of
the rate of data transmission.
K MIB (Management Information Base) The set of
variables (database) that a gateway running CMOT
kbps (Kilo Bits Per Second) A measure of the rate or SNMP maintains. Managers can fetch or store
of data transmission. Also see mbps and baud. into these variables. MIB-II refers to an extended
management database that contains variables not
shared by both CMOT and SNMP. See also CMOT
L and SNMP.
LAN (Local Area Network) Any physical network MILNET (MILitary NETwork) Originally part of the
technology that operates at high speed (usually tens ARPANET, MILNET was partitioned in 1984 to make
of megabits per second through several gigabits per it possible for military installations to have reliable
second) over short distances (up to a few thousand network service while the ARPANET continued to be
meters). Examples include Ethernet and proNET-10. used for research. MILNET uses exactly the same
See MAN and WAN. A network connecting various hardware and protocol technology as ARPANET.
electronic devices in a localized geographical area Under normal circumstances, MILNET is part of the
such as a single office building or a campus. connected Internet.
Level 2 A reference to link level communication (for MTU (Maximum Transfer Unit) The largest amount
example, frame formats) or link level connections of data that can be transferred across a given
derived from the ISO 7-layer reference model. For physical network. For local area networks like the
long haul networks, level 2 refers to the Ethernet, the MTU is determined by the network
communication between a host computer and a standard. For long haul networks that use serial
network packet switch (for example, HDLC/LAPB). lines to interconnect packet switches, the MTU is
For local area networks, level 2 refers to physical determined by software.
frame format and addressing. Thus, a level 2
address is a physical frame address (for example, Multi-homed Host An Internet host with
an Ethernet address). connections to two or more physical networks.

Instructor Guide
Multi-homed hosts can function as gateways if their connected Internet. NSF has also funded individual
routing tables are assigned correct values for routes. researchers working in the network area as well as
Multicast A technique that allows copies of a single large projects spanning multiple institutions like
packet to be passed to a selected subset of all CSNET. NSFNET (National Science Foundation
possible destinations. Some hardware (for example, NETwork) Loosely used to describe collectively the
Ethernet) supports multicast by allowing a network cross country backbone, mid-level networks, and
interface to belong to one or more multicast groups. supercomputer consortia networks that have all
Broadcast is a special form of multicast in which the been started with NSF seed funds. In a narrow
subset of machines to receive a copy of a packet sense, NSFNET refers only to the backbone
consists of the entire set. IP supports an internet network.
multicast facility.
O
N OSF (Open Software Foundation) A consortium of
Name Resolution The process of mapping a name hardware manufacturers who attempt to set
into a corresponding address. The domain name common standards for open systems, including
system provides a mechanism for naming operating systems and networks. Emerging OSF
computers in which programs use remote name standards include the OSF/1 operating system,
servers to resolve machine names into IP addresses Distributed Computing Environment (DCE) and
for those machines. Distributed Management Environment (DME).
NetBIOS (Network Basic Input Output System) OSI (Open Systems Interconnect) A reference to
NetBIOS is the standard interface to networks on protocols, specifically ISO standards, for the
IBM PC and compatible personal computers. In a interconnection of cooperative computer systems.
TCP/IP internet, NetBIOS refers to a set of OSPF Open Shortest Path First. It is an interior
guidelines that describes how to map NetBIOS gateway protocol based on a link state protocol
operations into equivalent TCP/IP operations. For model and is currently a Proposed Standard for
example, one of the NetBIOS naming operations Internet routing in autonomous systems.
maps into domain name system interactions.
Network Byte Order The TCP/IP standard for
transmission of integers that specifies most P
significant byte appears first (big endian). Sending
machines are required to translate from the local Packet The unit of data sent across a packet
switching network. The term is used loosely. While
integer representation to network byte order, and
receiving machines are required to translate from some TCP/IP literature uses it to refer specifically to
network byte order to the local machine data sent across a physical network, other literature
views an entire Internet as a packet switching
representation.
network and describes IP datagrams as packets.
NFS (Network File System) A protocol developed
PAD (Packet Assembler Disassembler) A term
by SUN Microsystems that uses IP to allow a set of
cooperating computers to access each other's file used with X.25 networks that refers to a terminal
systems as if they were local. The key advantage of multiplexer device that forms a connection between
terminals and hosts across an X.25 network. A PAD
NFS over conventional file transfer protocols is that
NFS hides the differences between local and remote accepts characters from a conventional terminal and
files by placing them in the same name space. NFS sends them across an X.25 network; it accepts
packets from an X.25 network, extracts characters,
was designed for UNIX systems, but has been
implemented for many systems including personal and displays them on a terminal.
computers like the IBM PC and Apple MacIntosh. ping (Packet InterNet Groper) The name of a
NIS A distributed database system which allows the program used in the Internet to test reachability of
sharing of system information. Examples of system destinations by sending them an ICMP echo request
and waiting for a reply. The term has survived the
information that can be shared include the
/etc/passwd, /etc/group, /etc/hosts files. original program and is now used like a verb as in,
please ping host A to see if it is alive.
NOC (Network Operations Center) The
organization at BBN that monitors and controls Port See protocol port.
several networks that form part of the Internet, Protocol A formal description of message formats
including the ARPANET, MILNET, and at least one and the rules two or more machines must follow to
X.25 based network. exchange those messages. Protocols can describe
low level details of machine to machine interfaces
NREN (National Education and Research
Network) The planned successor to the connected (for example, the order in which the bits from a byte
Internet that provides high-speed access to scientific are set across a wire), or high-level exchanges
between application programs (for example, the way
and educational institutions.
in which two programs transfer a file across an
NSF (National Science Foundation) A government internet). Most protocols include both intuitive
agency that has funded the development of a cross descriptions of the expected interactions as well as
country backbone network as well as regional more formal specifications using finite state machine
networks designed to connect scientists to the models.

Instructor Guide
Protocol Port The abstraction that transport because many machines on the Internet support
protocols use to distinguish among multiple timesharing instead of batch job processing.
destinations within a given host computer. TCP/IP rlogin (Remote LOGIN) The service offered by
protocols identify ports using small positive integers. Berkeley 4.3 BSD UNIX systems that allows users
Usually, the operating system allows an application of one machine to connect to other UNIX systems
program to specify which port it wants to use. Some across an internet and interact as if their terminals
ports are reserved for standard services (for connected to the machines directly. Although rlogin
example, electronic mail). offers essentially the same service as TELNET, it is
PSN (Packet Switch Node) The name of an superior because the software passes information
ARPANET packet switch; PSNs were formerly called about the user's environment (for example, terminal
IMPs. PSNs were implemented with BBN C30 or type) to the remote machine.
BBN C300 mini-computers and execute packet Route In general, a route is the path that network
switch software under control of the Network traffic takes from its source to its destination. In a
Operation Center at BBN. Each PSN connected to TCP/IP internet, each IP datagram is routed
at least two other PSNs as well as from 1 to 16 host separately; the route a datagram follows may
computers. include many gateways and many physical
networks.
R routed (Route Daemon) A program that runs under
4.3BSD UNIX to propagate routes among machines
RARP (Reverse Address Resolution Protocol) on a local area network. It uses the RIP protocol.
The Internet protocol a diskless machine uses a Pronounced "route-d."
startup to find its Internet address. The machine
broadcasts a request that contains its physical Router Generically, any machine responsible for
hardware address and a server responds by making decisions about which of several paths
sending the machine its Internet address. RARP network traffic follows. At the lowest level, a physical
takes its name and the message format from network bridge is a router because it chooses
another Internet address resolution protocol, ARP. whether to pass packets from one physical wire to
another. Within a long-haul network, each individual
rcp Part of the Berkeley set of network commands. packet switch is a router because it chooses routes
Transfers files between a local and a remote host or for individual packets. In a TCP/IP internet, each IP
between two remote hosts. gateway is a router because it uses IP destination
Regional Net The original term applied to NSFNET addresses to choose routes.
mid-level networks. RS232 A standard by EIA that specifies the
Repeater A hardware device that copies electrical electrical characteristics of slow speed
signals from one Ethernet to another. Typically, sites interconnections between terminal and computers or
that have repeaters use them to connect a physical between two computers. The specification limits
Ethernet cable on each floor of a building to a speeds to 20 Kbps and distance to 500 feet, but
backbone cable. The chief disadvantage of a many manufacturers support speeds of 38.4 Kbps
repeater compared to a bridge is that it transfers and/or longer distances. Although the standard
electrical noise as well as packets. At most, two commonly used is RS232C, most people refer to it
repeaters can appear between any two machines as RS232.
connected to an Ethernet. rsh Part of the Berkeley set of network commands.
rexec Part of the Arpanet set of network commands. It executes the specified command at the remote
It executes commands one at a time on a remote host or logs into the remote host.
host.
RFC (Request For Comments) The name of a
series of notes that contain surveys, measurements, S
ideas, techniques, and observations, as well as SDLC (Synchronous Data Link Control) A
proposed and accepted TCP/IP protocols standards. predecessor of HDLC defined by IBM Corporation
RFCs are edited but not refereed. They are and used in their SNA network products.
available on-line from the Network Information Segment The unit of transfer sent from TCP on one
Centre. machine to TCP on another. Each segment contains
RIP (Routing Information Protocol) The protocol part of a stream of bytes being sent between the
used by Berkeley 4.3 BSD UNIX systems to machines as well as additional fields that identify the
exchange routing information among a (small) set of current position in the stream and contain a
computers. Usually, the participating machines all checksum to ensure validity of received data.
attach to a single local area network. Implemented Sliding Window Characteristic of those protocols
by the UNIX program routed, RIP derives from an that, when sending a stream of bytes, allow the
earlier protocol of the same name developed at sender to transmit up to n packets before an
Xerox. acknowledgement arrives. After the sender receives
RJE (Remote Job Entry) The service offered by an acknowledgement for the first outstanding
many networks that allows one to submit a (batch) packet, it slides the packet window along the stream
job from a remote site. Although the Internet has a and sends another. Values for n are usually on the
protocol for RJE service, it is not very popular order of 10.

Instructor Guide
SLIP Serial Line Interface Protocol is an inexpensive (shut down) one direction of flow across a TCP
TCP/IP point-to-point connection with each connection, leaving a one-way (simplex) connection.
connection considered a unique network. The entire protocol suite is often referred to as
SLIPLOGIN An inexpensive TCP/IP password TCP/IP because TCP and IP are the two most
protect point-to-point serial connection that is fundamental protocols.
activated upon a call-in or dial-in process. TELNET The TCP/IP standard protocol for remote
SMTP (Simple Mail Transfer Protocol) The terminal connection service. TELNET allows a user
TCP/IP standard protocol for transferring electronic at one site to interact with a remote timesharing
mail messages from one machine to another. SMTP system at another site as if the user's terminal
specifies how two mail systems interact and the connected directly to the remote machine. That is,
format of control messages they exchange to the user invokes a TELNET application program that
transfer mail. connects to a remote machine, prompts for a login id
and password, and then passes keystrokes from the
SNA (System Network Architecture) The name user's terminal to the remote machine and displays
applied to an architecture and a class of network output from the remote machine on the user's
products offered by IBM Corporation. SNA does not terminal.
interoperate with TCP/IP.
TFTP (Trivial File Transfer Protocol) The TCP/IP
SNMP (Simple Network Management Protocol) A standard protocol for file transfer with minimal
standard protocol used to monitor IP gateways and capability and minimal overhead. TFTP depends
the networks to which they attach. SNMP defines a only on the unreliable, connectionless datagram
set of variables that the gateway must keep and delivery service (UDP), so it can be used on
specifies that all operations on the gateway are a machines like diskless workstations that keep such
side effect of fetching or storing to the data software in ROM and use it to bootstrap themselves.
variables. Also see CMOT and MIB.
Token Bus A type of network technology in which
Socket The abstraction provided by Berkeley 4.3 permission to transmit is specifically passed from
BSD UNIX that allows a process to access the one station to another as a means for governing
Internet. A process opens a socket, specifies the shared access to the channel.
service desired (for example, reliable stream
delivery), binds the socket to a specific destination, Token Ring When used in the generic sense, a type
and then sends or receives data. of network technology that controls media access by
passing a distinguished packet, called a token, from
Source Route A route that is determined by the machine to machine. A computer can only transmit a
source. TCP/IP implements source routing by using packet when holding the token. When used in a
an option field in an IP datagram. The source fills in specific sense, it refers to the token ring network
a sequence of machines that the datagram must hardware produced by IBM.
visit along its trip to the destination. Each gateway
along the path honors source routing by following Topology A description of how stations on a
the list of machines to visit instead of following the network connect to a cable. Examples of specific
usual route to the destination. topologies include: Bus, Ring, Star and Tree. Two
kinds of topology include:
Subnet Address An extension of the IP addressing
scheme that allows a site to use a single IP network 1. Physical topology The configuration
address for multiple physical networks. Outside of of network nodes and links. Description
the site using subnet addressing, routing continues
as usual by dividing the destination address into a of the physical geometric arrangement
network portion and local portion. Gateways and of the links and nodes that make up a
hosts inside a site using subnet addressing interpret
the local portion of the address by dividing it into a network, as determined by their physical
physical network portion and host portion. connections.
T 2. Logical topology Description of the

Talk A command that provides for the ability to carry possible connections between network
on a conversation with another user either on the nodes, indicating which pairs of nodes
same system or different systems across a network.
are able to communicate, whether or not
TCP (Transmission Control Protocol) The TCP/IP
standard transport level protocol that provides the they have a direct physical connection.
reliable, full duplex, stream service on which many
application protocols depend. TCP allows a process TP-4/IP A term often given to the ISO protocol suite
on one machine to send a stream of data to a that closely resembles TCP/IP. Both TCP and ISO
process on another. It is connection-oriented in the TP-4 protocols provide reliable stream delivery
sense that before transmitting data, participants service using basically the same techniques of
must establish a connection. Software implementing positive acknowledgement and retransmission.
TCP usually resides in the operating system and Trailer Protocol A nonconventional method of
uses the IP protocol to transmit information across encapsulating IP datagrams for transmission across
the underlying internet. It is possible to terminate a local area network (for example, Ethernet). Trailer

Instructor Guide
protocols place the header at the end of the packet, Well-known Port Any of a set of protocol port
so the operating system can arrange to have the numbers preassigned for specific uses by transport
network hardware deposit incoming datagrams with level protocols (that is, TCP and UDP). Servers
the data area starting on a page boundary. The follow the well-known port assignments so clients
technique saves on the overhead of copying can locate them. Examples of well-known port
datagrams once they arrive. numbers include ports assigned to echo servers,
Transceiver A device that connects a host interface time servers, remote login (TELNET) servers, and
to local area network (for example, Ethernet). file transfer (FTP) servers.
Ethernet transceivers contain analog electronics that World Wide Web (WWW) An Internet navigation
apply signals to t he cable and sense collisions. tool that allows a user to browse a world-wide set of
TTL (Time To Live) A technique used in best-effort services and documents using hypertext. It is based
delivery systems to avoid endlessly looping packets. on hypertext documents whose structure links
For example, each IP datagram is assigned an pages of hypertext to other documents on other
integer time to live when it is created. IP gateways sites. The Web consists of the masses of linked
decrement the time to live field when they process a servers all over the world.
datagram and discard the datagram if the time to live
counter reaches zero.
X
X.25 The CCITT standard protocol for transport level
U network service. Originally designed to connect
UDP (User Datagram Protocol) The Internet terminals to computers, X.25 provides a reliable,
standard protocol that allows an application program stream transmission service that can support remote
on one machine to send a datagram to an login. The X25NET service offered by CSNET
application program on another machine. UDP uses demonstrates that it is possible to run TCP/IP
the Internet Protocol to deliver datagrams. protocols, IP in particular, over an X.25 network.
Conceptually, the important difference between UDP X.25 is most popular in Europe.
and IP is that UDP messages include a protocol port X25NET (X.25 NETwork) A service offered by
number, allowing the sender to distinguish among CSNET that passed IP traffic between a subscriber
multiple destinations (application programs) on the site and the Internet using X.25.
remote machine. In practice, UDP also includes a X.400 The CCITT protocol for electronic mail that is
checksum over the data being sent. expected to become widely accepted. The current
Universal Time The international standard time version is X.400(88) because it was defined in 1988.
reference that was formerly called Greenwich Mean Work is underway to make TCP/IP mail systems
Time. It is also called Coordinated Universal Time. interoperate with X.400.
UUCP (UNIX-to-UNIX Copy Program) An XDR (eXternal Data Representation) The standard
application program developed in the mid 1970s for for a machine independent data structure
version 7 UNIX that allows one UNIX timesharing representation developed by SUN Microsystems. To
system to copy files to or from another UNIX use XDR, a sender translates from the local
timesharing system over a single (usually dialup) machine representation to the standard external
link. Because UUCP is the basis for electronic mail representation and a receiver translates from the
transfer in UNIX, the term is often used loosely to external representation to the local machine
refer to UNIX mail transfer. representation.
XNS (Xerox Network Standard) The term used
collectively to refer to the suite of Internet protocols
V developed by researchers at Xerox Corporation.
Veronica A server that builds a database of Gopher Although similar in spirit to the TCP/IP protocols,
menus from all the Gopher servers referred to as XNS uses different packet formats and terminology.
Gopherspace. Xstation A high-function LAN-attached terminal
Virtual Circuit A network service enabling two end whose function is limited to the functions of an X
points to communicate as though via a physical Window server.
circuit; a logical transmission path. X-Window System A software system developed at
MIT for presenting and managing output on
bit-mapped displays. Each window consists of a
W rectangular region of the display that contains
WAIS Wide Area Information Servers know about textual or graphical output. X allows application
hundreds of databases that contain information of programs on a variety of computers to display output
general topics. in separate windows on a single display. X uses a
program called a window manager to allow the user
WAN (Wide Area Network) Any physical network to create, move, overlap, and destroy windows.
technology that spans large geographical distances.
Also called long-haul networks, WANs usually
operate at slower speeds and have significantly
higher delays than networks that operate over
shorter distances. See LAN and MAN.

Instructor Guide
Z
Zone of Authority Term used in the domain name
system to refer to the group of names for which a
given name server is an authority. Each zone must
be supplied by two name servers that have no
common point of failure.

Instructor Guide

V3.1.0.1
backpg
Back page

Au 079 Inst

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Au 079 Inst

Transféré par

Droits d'auteur :

Formats disponibles

V3.1.0.

Front cover

IBM Certified Course Material

June 2006 Edition

Instructor Course Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Course Presentation Material Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Unit 1. TCP/IP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Copyright IBM Corp. 1997, 2006 Contents iii

Optional Activity: Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-114

Unit 2. Hardware Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Unit 3. Configuring TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

iv AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

TOC Minimum Configuration and Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17

Unit 4. Configuring Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit 5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Copyright IBM Corp. 1997, 2006 Contents v

Viewing the Routing Table: netstat -rn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13

Unit 6. Dynamic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Unit 7. Shared Ethernet Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

vi AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

TOC What is Link Aggregation? (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34

Unit 8. Network Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Unit 9. Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Copyright IBM Corp. 1997, 2006 Contents vii

Setting Up the Primary Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-37

Unit 10. Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10-1

viii AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

TOC Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-46

Unit 11. Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Unit 12. NFS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Copyright IBM Corp. 1997, 2006 Contents ix

Unit 13. Configuring NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

x AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

TOC Unit 14. Automounter and NFS Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Appendix A. Checkpoint and Activity Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Appendix B. Command Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Appendix C. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

Appendix D. TCP/IP and NFS/NIS Commands and Files. . . . . . . . . . . . . . . . . . . . D-1

Appendix E. Summary of the no Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1

Copyright IBM Corp. 1997, 2006 Contents xi

xii AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

Copyright IBM Corp. 1997, 2006 Trademarks xiii

xiv AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

pref Instructor Course Overview

Copyright IBM Corp. 1997, 2006 Instructor Course Overview xv

xvi AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

pref Configure Virtual Ethernet connections on AIX

Copyright IBM Corp. 1997, 2006 Course Description xvii

xviii AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

pref Course Presentation Material Overview

xx AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

Uempty Unit 1. TCP/IP Concepts

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

Copyright IBM Corp. 1997, 2006 Unit 1. TCP/IP Concepts 1-1

Copyright IBM Corporation 2006

Figure 1-1. Unit Objectives AU079.1

1-2 AIX 5L TCP/IP I: Configuring Copyright IBM Corp. 1997, 2006

Uempty Instructor Notes:

Copyright IBM Corp. 1997, 2006 Unit 1. TCP/IP Concepts 1-3

Copyright IBM Corporation 2006