100% found this document useful (1 vote)

1K views

Solaris 10 Network Administration - Student Guide

Sun, the Sun logo, Solaris, Java, JumpStart, OpenBoot, Sun BluePrints, Sun Fire, and Sun StorEdge are trademarks or registered trademarks of Sun Microsystems, Inc. In the U.S. And other countries. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any.

Uploaded by

Ahmad Junaid

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

1K views

Solaris 10 Network Administration - Student Guide

Uploaded by

Ahmad Junaid

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 628

Network Administration for the

Solaris™ 10 Operating System

SA-300-S10

Student Guide

Sun Microsystems, Inc.

UBRM05-104
500 Eldorado Blvd.
Broomfield, CO 80021
U.S.A.
Revision A.1
March 9, 2005 2:48 pm
Copyright 2005 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved.

This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and
decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of
Sun and its licensors, if any.

Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.

Sun, Sun Microsystems, the Sun logo, Solaris, Java, JumpStart, OpenBoot, Sun BluePrints, Sun Fire, and Sun StorEdge are trademarks or
registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and
other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.

UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.

The OPEN LOOK and Sun Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges
the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry.
Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who
implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.

Federal Acquisitions: Commercial Software – Government Users Subject to Standard License Terms and Conditions

Export Laws. Products, Services, and technical data delivered by Sun may be subject to U.S. export controls or the trade laws of other
countries. You will comply with all such laws and obtain all licenses to export, re-export, or import as may be required after delivery to
You. You will not export or re-export to entities on the most current U.S. export exclusions lists or to any country subject to U.S. embargo
or terrorist controls as specified in the U.S. export laws. You will not use or provide Products, Services, or technical data for nuclear, missile,
or chemical biological weaponry end uses.

DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND
WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE
LEGALLY INVALID.

THIS MANUAL IS DESIGNED TO SUPPORT AN INSTRUCTOR-LED TRAINING (ILT) COURSE AND IS INTENDED TO BE
USED FOR REFERENCE PURPOSES IN CONJUNCTION WITH THE ILT COURSE. THE MANUAL IS NOT A STANDALONE
TRAINING TOOL. USE OF THE MANUAL FOR SELF-STUDY WITHOUT CLASS ATTENDANCE IS NOT RECOMMENDED.

Export Commodity Classification Number (ECCN) assigned: 12 December 2001

Please
Recycle
Copyright 2005 Sun Microsystems Inc. 4150 Network Circle, Santa Clara, California 95054, Etats-Unis. Tous droits réservés.

Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution,
et la décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit,
sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a.

Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié
par des fournisseurs de Sun.

Sun, Sun Microsystems, the Sun logo, Solaris, Java, JumpStart, OpenBoot, Sun BluePrints, Sun Fire, et Sun StorEdge sont des marques de
fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays.

Toutes les marques SPARC sont utilisées sous licence sont des marques de fabrique ou des marques déposées de SPARC International, Inc.
aux Etats-Unis et dans d’autres pays. Les produits portant les marques SPARC sont basés sur une architecture développée par Sun
Microsystems, Inc.

UNIX est une marques déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company, Ltd.

L’interfaces d’utilisation graphique OPEN LOOK et Sun™ a été développée par Sun Microsystems, Inc. pour ses utilisateurs et licenciés.
Sun reconnaît les efforts de pionniers de Xerox pour larecherche et le développement du concept des interfaces d’utilisation visuelle ou
graphique pour l’industrie de l’informatique. Sun détient une licence non exclusive de Xerox sur l’interface d’utilisation graphique Xerox,
cette licence couvrant également les licenciés de Sun qui mettent en place l’interface d’utilisation graphique OPEN LOOK et qui en outre
se conforment aux licences écrites de Sun.

Législation en matière dexportations. Les Produits, Services et données techniques livrés par Sun peuvent être soumis aux contrôles
américains sur les exportations, ou à la législation commerciale dautres pays. Nous nous conformerons à lensemble de ces textes et nous
obtiendrons toutes licences dexportation, de ré-exportation ou dimportation susceptibles dêtre requises après livraison à Vous. Vous
nexporterez, ni ne ré-exporterez en aucun cas à des entités figurant sur les listes américaines dinterdiction dexportation les plus courantes,
ni vers un quelconque pays soumis à embargo par les Etats-Unis, ou à des contrôles anti-terroristes, comme prévu par la législation
américaine en matière dexportations. Vous nutiliserez, ni ne fournirez les Produits, Services ou données techniques pour aucune utilisation
finale liée aux armes nucléaires, chimiques ou biologiques ou aux missiles.

LA DOCUMENTATION EST FOURNIE “EN L’ETAT” ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES
EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y
COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L’APTITUDE A UNE
UTILISATION PARTICULIERE OU A L’ABSENCE DE CONTREFAÇON.

CE MANUEL DE RÉFÉRENCE DOIT ÊTRE UTILISÉ DANS LE CADRE D’UN COURS DE FORMATION DIRIGÉ PAR UN
INSTRUCTEUR (ILT). IL NE S’AGIT PAS D’UN OUTIL DE FORMATION INDÉPENDANT. NOUS VOUS DÉCONSEILLONS DE
L’UTILISER DANS LE CADRE D’UNE AUTO-FORMATION.

Please
Recycle
Table of Contents
About This Course ............................................................Preface-xvii
Course Goals....................................................................... Preface-xvii
Course Map........................................................................ Preface-xviii
Topics Not Covered............................................................. Preface-xix
How Prepared Are You?...................................................... Preface-xx
Introductions ........................................................................ Preface-xxi
How to Use Course Materials ...........................................Preface-xxii
Conventions ........................................................................Preface-xxiii
Icons ............................................................................Preface-xxiii
Typographical Conventions ................................... Preface-xxiv
Additional Conventions........................................... Preface-xxv
Introducing the TCP/IP Model .........................................................1-1
Objectives ........................................................................................... 1-1
Introducing Network Model Fundamentals.................................. 1-2
Network Protocols .................................................................... 1-2
Network Model Concepts........................................................ 1-3
Introducing the Layers of the TCP/IP Model................................ 1-4
Network Interface Layer ......................................................... 1-5
Internet Layer ............................................................................ 1-6
Transport Layer......................................................................... 1-7
Application Layer ..................................................................... 1-8
Describing Basic Peer-to-Peer Communication,
Encapsulation, and Decapsulation ............................................. 1-10
Peer-to-Peer Communication ................................................ 1-10
Encapsulation and Decapsulation ........................................ 1-11
TCP/IP Protocols ............................................................................. 1-12
Exercise: Reviewing the TCP/IP Model ....................................... 1-16
Preparation............................................................................... 1-16
Tasks ......................................................................................... 1-16
Exercise Summary............................................................................ 1-18
Exercise Solutions ............................................................................ 1-19

vii
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing LANs and Their Components..................................... 2-1
Objectives ............................................................................................ 2-1
Introducing Network Topologies .................................................... 2-2
Bus Topologies .......................................................................... 2-2
Star Topologies ......................................................................... 2-3
Ring Topologies......................................................................... 2-4
VLAN Topologies .................................................................... 2-5
Introducing LAN Media ................................................................... 2-8
IEEE Identifiers.......................................................................... 2-8
IEEE 802.3 Types ....................................................................... 2-9
Introducing Network Devices........................................................ 2-12
Repeaters .................................................................................. 2-12
Hubs.......................................................................................... 2-12
Bridges ...................................................................................... 2-12
Switches.................................................................................... 2-12
Exercise: Reviewing LANs and Their Components ................... 2-14
Preparation............................................................................... 2-14
Tasks ......................................................................................... 2-14
Exercise Summary............................................................................ 2-16
Exercise Solutions ............................................................................ 2-17
Describing Ethernet Interfaces....................................................... 3-1
Objectives ........................................................................................... 3-1
Introducing Ethernet Concepts........................................................ 3-2
Major Ethernet Elements.......................................................... 3-2
CSMA/CD Access Method ..................................................... 3-2
Full-Duplex and Half-Duplex Mode...................................... 3-4
Ethernet Statistics...................................................................... 3-4
Introducing Ethernet Frames ........................................................... 3-6
Ethernet Addresses................................................................... 3-6
Setting a Local Ethernet Address........................................... 3-8
Ethernet-II Frame Analysis................................................... 3-10
Maximum Transmission Units............................................. 3-12
Ethernet Frame Errors ............................................................ 3-13
Using Network Utilities .................................................................. 3-14
Using the snoop Utility .......................................................... 3-14
Using the netstat Command ............................................. 3-17
Using the ndd Command ....................................................... 3-18
Exercise: Reviewing Ethernet Interfaces....................................... 3-21
Preparation............................................................................... 3-21
Tasks ......................................................................................... 3-21
Exercise Summary............................................................................ 3-25
Exercise Solutions ............................................................................ 3-26

viii Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Describing ARP and RARP..............................................................4-1
Objectives ........................................................................................... 4-1
Introducing ARP ................................................................................ 4-2
Purpose of ARP ......................................................................... 4-2
Operation of ARP...................................................................... 4-3
Introducing RARP.............................................................................. 4-9
Purpose of RARP....................................................................... 4-9
Operation of RARP ................................................................... 4-9
Exercise: Reviewing ARPs and RARPs......................................... 4-12
Preparation............................................................................... 4-12
Tasks ........................................................................................ 4-13
Exercise Summary............................................................................ 4-15
Exercise Solutions ............................................................................ 4-16
Configuring IP...................................................................................5-1
Objectives ............................................................................................ 5-1
Introducing the Internet Layer Protocols ....................................... 5-3
Purpose of IP.............................................................................. 5-3
Purpose of ICMP ....................................................................... 5-4
Introducing the IP Datagram ........................................................... 5-6
IP Datagram Header Fields ..................................................... 5-6
IP Datagram Payload................................................................ 5-8
Introducing IP Address Types ......................................................... 5-9
Unicast Addresses..................................................................... 5-9
Broadcast Addresses............................................................... 5-11
Multicast Addresses ............................................................... 5-11
Introducing Subnetting and VLSM ............................................... 5-12
Subnetting ................................................................................ 5-12
Netmasks.................................................................................. 5-13
Configuring the Netmask ..................................................... 5-16
The /etc/inet/netmasks File............................................. 5-17
VLSM ....................................................................................... 5-20
Introducing the Interface Configuration Files ............................. 5-22
The /etc/hostname.interface File.................................. 5-22
The /etc/inet/hosts File ................................................... 5-22
The /etc/nodename File........................................................ 5-23
Administering Logical Interfaces .................................................. 5-24
Introducing Logical Interfaces .............................................. 5-24
Configuring Logical Interfaces............................................. 5-26
Unconfiguring Logical Interfaces ......................................... 5-28
Exercise: Reviewing IP .................................................................... 5-29
Preparation............................................................................... 5-29
Task Summary......................................................................... 5-29
Tasks ........................................................................................ 5-30
Exercise Summary............................................................................ 5-32
Exercise Solutions ............................................................................ 5-33

ix
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing............................................. 6-1
Objectives ............................................................................................ 6-1
Increasing Network Availability ..................................................... 6-2
Limitations of Network Interfaces.......................................... 6-2
Configuring IP Network Multipathing........................................... 6-3
Introducing IPMP ..................................................................... 6-3
Probe-based IPMP Configuration........................................... 6-4
Configuring Probe-based IPMP by Using
Configuration Files ................................................................ 6-6
Configuring Probe-based IPMP on the
Command Line.................................................................... 6-12
Link-based IPMP Configuration.......................................... 6-20
Configuring Link-based IPMP by Using
Configuration
Files ....................................................................................... 6-21
Configuring a Singleton IPMP Group ................................. 6-26
Viewing IPMP Operation ..................................................... 6-28
Troubleshooting an IPMP Configuration........................... 6-30
Exercise: Configuring IPMP ........................................................... 6-32
Preparation............................................................................... 6-32
Tasks ........................................................................................ 6-34
Exercise Summary............................................................................ 6-39
Exercise Solutions ............................................................................ 6-40
Configuring Routing ........................................................................ 7-1
Objectives ............................................................................................ 7-1
Identifying the Fundamentals of Routing ...................................... 7-3
Purpose of Routing ................................................................... 7-3
Types of Routes ......................................................................... 7-4
Introducing the Routing Table......................................................... 7-6
Static Routes............................................................................... 7-6
Dynamic Routes ....................................................................... 7-7
Introducing Routing Protocol Types............................................... 7-8
Autonomous Systems............................................................... 7-8
Interior Gateway Protocols...................................................... 7-9
Exterior Gateway Protocols ................................................... 7-10
Working With the Routing Table .................................................. 7-12
Displaying the Routing Table ............................................... 7-12
Introducing Routing Table Information .............................. 7-13
Searching the Routing Table................................................. 7-14
Associating Names and Network Numbers ....................... 7-16
Configuring Static Routes............................................................... 7-18
Configuring Static Direct Routes .......................................... 7-18
Configuring the /etc/defaultrouter File ...................... 7-19
Configuring the /etc/gateways File ................................. 7-20
Configuring Static Routes on the Command Line ............ 7-21
Configuring Dynamic Routing ...................................................... 7-25

x Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
RIP Version 1 ........................................................................... 7-25
RIP Version 2 ........................................................................... 7-27
The in.routed Daemon ....................................................... 7-28
The RDISC Protocol ............................................................... 7-30
ICMP Redirects........................................................................ 7-31
Introducing CIDR ............................................................................ 7-33
Purpose of CIDR ..................................................................... 7-33
Operation of CIDR .................................................................. 7-33
Configuring Routing at Boot Time ................................................ 7-38
Initializing a Router ................................................................ 7-38
Configuring a Router Without Rebooting........................... 7-40
Initializing a Multihomed Host ............................................ 7-40
Initializing a Non-Router ....................................................... 7-41
Troubleshooting Routing................................................................ 7-42
Troubleshooting the Router Configuration......................... 7-42
Troubleshooting Network Names....................................... 7-44
Exercise: Reviewing Routing Configuration................................ 7-45
Preparation............................................................................... 7-45
Tasks ........................................................................................ 7-47
Exercise Summary............................................................................ 7-59
Exercise Solutions ............................................................................ 7-60
Configuring IPv6...............................................................................8-1
Objectives ............................................................................................ 8-1
Introducing IPv6 ................................................................................ 8-3
The Need for IPv6 ..................................................................... 8-3
Features of IPv6 ........................................................................ 8-4
Introducing IPv6 Addressing........................................................... 8-5
Address Types ........................................................................... 8-5
IPv6 Address Representation.................................................. 8-6
Format Prefixes.......................................................................... 8-6
Introducing IPv6 Autoconfiguration .............................................. 8-8
Stateful Autoconfiguration ...................................................... 8-8
Stateless Autoconfiguration .................................................... 8-8
Interface Identifier Calculation ............................................... 8-9
Duplicate Address Detection ................................................ 8-10
Introducing Unicast Address Types ............................................. 8-11
Link-Local Addresses ............................................................. 8-11
Site-Local Addresses............................................................... 8-12
Aggregatable Global-Unicast Addresses............................. 8-12
Prefix Notation ........................................................................ 8-13
Embedded IPv4 Addresses.................................................... 8-13
Unspecified Address Types................................................... 8-14
Loopback Address Types ...................................................... 8-14
Introducing Multicast Address Types .......................................... 8-15

xi
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Purpose of Multicast Addresses ........................................... 8-15
Scope Bits................................................................................. 8-16
ICMPv6 Group Membership................................................. 8-17
Enabling IPv6.................................................................................... 8-18
The in.ndpd Daemon on a Non-Router.............................. 8-18
Configuring IPv6 on Non-Routers ....................................... 8-19
Troubleshooting a Non-Router Configuration................... 8-22
The in.ndpd Daemon on the Router ................................... 8-23
IPv6 Routing Information Protocol ...................................... 8-23
Configuring an IPv6 Router ................................................. 8-24
Configuring an IPv6 6to4 Router.......................................... 8-30
Configuring a 6to4 Boundary Router.................................. 8-31
Troubleshooting a Router Configuration ............................ 8-33
Managing IPv6 ................................................................................. 8-35
Displaying the State of IPv6 Interfaces ................................ 8-35
Modifying the Configuration of an IPv6 Interface............. 8-35
Configuring Logical Interfaces.............................................. 8-36
Troubleshooting IPv6 Interfaces ........................................... 8-36
Displaying the IPv6 Routing Table ...................................... 8-36
Exercise 1: Configuring IPv6 .......................................................... 8-37
Preparation............................................................................... 8-37
Task 1 – Configuring IPv6 on the Local Subnet ................. 8-37
Task 2 – Configuring 6to4 Routing...................................... 8-39
Task 3 – Configuring IPv6 Across the Whole
Network................................................................................ 8-41
Exercise Summary............................................................................ 8-44
Exercise 1 Solutions ......................................................................... 8-45
Task 1 – Configuring IPv6 on the Local Subnet ................. 8-45
Task 2 – Configuring 6to4 Routing...................................... 8-48
Task 3 – Configuring IPv6 Across the Whole
Network................................................................................ 8-52
Configuring IPv6 Multipathing ..................................................... 8-58
Configuring IPMP Manually................................................. 8-58
Configuring IPMP at Boot Time .......................................... 8-68
Configure a Singleton IPMP Group in IPv6........................ 8-73
Exercise 2: Configuring IPv6 Multipathing.................................. 8-74
Preparation............................................................................... 8-74
Tasks ......................................................................................... 8-74
Exercise Summary............................................................................ 8-77
Exercise 2 Solutions ......................................................................... 8-78
Task Solutions.......................................................................... 8-78

xii Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Describing the Transport Layer ......................................................9-1
Objectives ............................................................................................ 9-1
Introducing Transport Layer Fundamentals ................................. 9-2
Protocol Characteristics............................................................ 9-2
Transport Protocols in TCP/IP .............................................. 9-8
Introducing UDP................................................................................ 9-9
Purpose of UDP......................................................................... 9-9
UDP Datagram Header ............................................................ 9-9
Introducing TCP............................................................................... 9-10
TCP Segment Header ............................................................. 9-10
Virtual Circuit Connection .................................................... 9-11
Full-Duplex Connection......................................................... 9-11
Unstructured Stream Orientation......................................... 9-11
Buffered Transfer .................................................................... 9-11
Introducing TCP Flow Control ...................................................... 9-12
Receiver-Side Window Advertisements.............................. 9-12
Sender-Side Congestion Window......................................... 9-12
TCP Large Window ................................................................ 9-13
Exercise: Describing the Transport Layer..................................... 9-14
Preparation............................................................................... 9-14
Tasks ......................................................................................... 9-14
Exercise Summary............................................................................ 9-15
Exercise Solutions ............................................................................ 9-16
Configuring DNS.............................................................................10-1
Objectives .......................................................................................... 10-1
Introducing DNS Basics .................................................................. 10-2
BIND ......................................................................................... 10-2
Top-Level Domains ................................................................ 10-2
Zones of Authority.................................................................. 10-4
Server Types ............................................................................ 10-4
Answer Types.......................................................................... 10-7
Name-Resolution Process ...................................................... 10-7
Resource Records .................................................................. 10-11
Configuring a DNS Server............................................................ 10-15
Gathering Information ......................................................... 10-15
Editing the BIND Configuration File ................................. 10-16
Editing the named.root File .............................................. 10-19
Editing the Forward Domain File...................................... 10-21
Editing the Reverse Domain File ....................................... 10-24
Editing the Reverse Loopback Domain File...................... 10-25
Configuring Dynamic Updates.......................................... 10-26
Configuring Security ........................................................... 10-27
Configuring Secondary DNS Servers................................ 10-29
Checking Configuration and Database Files.................... 10-31
Configuring DNS Clients.................................................... 10-32

xiii
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic
Utilities.......................................................................................... 10-33
Implementing named Logging............................................. 10-33
Examining the/var/adm/messages File........................... 10-35
Using the dig Utility ........................................................... 10-36
Dumping a Snapshot of the DNS Database by
Using the rndc Utility ...................................................... 10-39
Forcing the named Daemon to Reread the
Configuration and Changed Zone Files ......................... 10-44
Managing a DNS Server by Using the rndc
Utility .................................................................................. 10-45
Exercise: Configuring DNS.......................................................... 10-50
Preparation............................................................................. 10-50
Task Summary....................................................................... 10-51
Tasks ....................................................................................... 10-51
Exercise Summary.......................................................................... 10-57
Exercise Solutions .......................................................................... 10-58
Task Solutions........................................................................ 10-58
Configuring DHCP ......................................................................... 11-1
Objectives .......................................................................................... 11-1
Introducing the Fundamentals of DHCP ..................................... 11-2
Purpose of DHCP.................................................................... 11-2
DHCP Client Functions.......................................................... 11-3
DHCP Server Functions ......................................................... 11-4
Configuring a DHCP Server........................................................... 11-7
Configuring DHCP by Using Different Methods ............. 11-8
Performing Initial DHCP Server Configuration by
Using the dhcpmgr Utility.................................................. 11-9
Adding Addresses by Using the dhcpmgr Utility ............ 11-21
Using the dhcpconfig Command..................................... 11-28
Introducing DHCP Network Files...................................... 11-30
Using the pntadm Command .............................................. 11-31
Introducing the dhcptab Table........................................... 11-34
Configuring and Managing DHCP Clients................................ 11-39
Configuring a DHCP Client ................................................ 11-39
Troubleshooting a DHCP Server ................................................. 11-42
Troubleshooting DHCP Clients ................................................... 11-45
Exercise: Configuring a DHCP Server and Client..................... 11-46
Preparation............................................................................. 11-46
Task Summary...................................................................... 11-47
Task 1 – Configuring the DHCP Server............................. 11-47
Task 2 – Configuring the DHCP Client ............................ 11-48
Task 3 – Using the snoop Utility to View DHCP
Client-Server Interaction................................................... 11-48
Exercise Summary.......................................................................... 11-50
Exercise Solutions .......................................................................... 11-51
Task 1 – Configuring the DHCP Server............................. 11-51

xiv Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Task 2 – Configuring the DHCP Client ............................. 11-69
Task 3 – Using the snoop Utility to View DHCP
Client-Server Interaction................................................... 11-70
Configuring NTP .............................................................................12-1
Objectives .......................................................................................... 12-1
Identifying NTP Basics.................................................................... 12-2
How Computers Keep Time.................................................. 12-2
Uses of NTP ............................................................................ 12-3
NTP Terms ............................................................................... 12-3
Configuring an NTP Server............................................................ 12-5
Using an Undisciplined Local Clock.................................... 12-7
Using External NTP Reference Servers................................ 12-9
Managing Daemons.............................................................. 12-10
Determining NTP Peers ...................................................... 12-12
Configuring an NTP Client .......................................................... 12-13
Establishing Basic Configuration........................................ 12-13
Starting the NTP Client Daemon ........................................ 12-13
Stopping the NTP Client Daemon...................................... 12-14
Troubleshooting NTP .................................................................... 12-15
Viewing Messages................................................................. 12-15
Using the snoop Utility ....................................................... 12-16
Exercise: Configuring NTP ........................................................... 12-17
Preparation............................................................................. 12-17
Task Summary....................................................................... 12-17
Tasks ...................................................................................... 12-18
Exercise Summary.......................................................................... 12-21
Exercise Solutions .......................................................................... 12-22
Task Solutions........................................................................ 12-22
Configuring the Solaris™ IP Filter Firewall..................................13-1
Objectives .......................................................................................... 13-1
Identifying Firewall Basics ............................................................. 13-2
Configuring the Behavior of the Solaris IP Filter
Firewall ........................................................................................... 13-3
Enabling Packet Filtering With the Solaris IP Filter
Firewall .................................................................................. 13-3
Configuring the Solaris IP Filter Firewall Actions ............. 13-5
Configuring Packet Direction................................................ 13-6
Configuring Filter Rules......................................................... 13-7
Configuring Specific Matching ............................................. 13-8
Changing and Updating the Solaris IP Filter
Firewall Configuration ...................................................... 13-14
Viewing the Solaris IP Filter Firewall
Configuration ..................................................................... 13-15
Configuring Logging in the Solaris IP
Filter Firewall...................................................................... 13-16

xv
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Configuring the Solaris IP Filter Firewall .................. 13-19
Preparation............................................................................. 13-19
Task Summary....................................................................... 13-19
Task 1 – Configuring Firewall Rules ................................. 13-20
Task 2 – Disabling Services................................................. 13-26
Exercise Summary.......................................................................... 13-31
Exercise Solutions .......................................................................... 13-32
Task 1 Solutions..................................................................... 13-32
Task 2 Solutions..................................................................... 13-41
Bibliography ................................................................. Bibliography-1
Sun Microsystems Publications ................................. Bibliography-1
Books.............................................................................. Bibliography-2
Online References ........................................................ Bibliography-3
RFCs ............................................................................... Bibliography-4
Glossary/Acronyms ............................................................Glossary-1
Index.................................................................................................. 1-1

xvi Network Administration for the Solaris™ 10 Operating System

About This Course

Course Goals
Upon completion of this course, you should be able to:
● Configure the Network Interface layer
● Configure the network (Internet and Transport layers)
● Configure and manage network applications

Preface-xvii
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Course Map

Course Map
The course map enables you to see what you have accomplished and
where you are going in reference to the instructional goals.

Configuring the Network Interface Layer

Introducing the Introducing LANs Describing Describing

TCP/IP and Their Ethernet ARP and
Model Components Interfaces RARP

Configuring the Network

Configuring IP
Configuring Configuring
Network
IP Routing
Multipathing

Describing
Configuring the Transport
IPv6 Layer

Configuring and Managing Network Applications

Configuring the
Configuring Configuring Configuring Solaris™ IP
DNS DHCP NTP Filter Firewall

Preface-xviii Network Administration for the Solaris™ 10 Operating System

Topics Not Covered

This course does not cover the following topics. Many of these topics are
covered in other courses offered by Sun Educational Services:
● Solaris™ Operating System (Solaris OS) system administration –
Covered in SA-200-S10: Intermediate System Administration for the
Solaris™ 10 Operating System and SA-202-S10: Advanced System
Administration for the Solaris™ 10 Operating System
● Server storage administration – Covered in ES-222: Solaris™ Volume
Manager Administration and ES-310: Volume Manager With Sun
StorEdge™
● Network Information Services Plus (NIS+) – Covered in
SA-385: NIS+ Administration
● Solaris OS tuning – Covered in SA-400: Solaris™ Systems Performance
Management
● Network Troubleshooting - Covered in IN-425: TCP/IP Network
Troubleshooting in the Solaris™ OS

Refer to the Sun Educational Services catalog for specific information and
registration.

About This Course Preface-xix

How Prepared Are You?

To be sure you are prepared to take this course, can you answer yes to the
following questions?
● Can you perform basic host operations, such as startup and
shutdown, to initialize certain network configuration changes?
● Can you manipulate startup and shutdown scripts to configure
networks?
● Can you set up user accounts when configuring network services for
system users?
● Can you locate and install network software packages required to set
up various network services?

Preface-xx Network Administration for the Solaris™ 10 Operating System

Introductions
Now that you have been introduced to the course, introduce yourself to
the other students and the instructor, addressing the following items:
● Name
● Company affiliation
● Title, function, and job responsibility
● Experience related to topics presented in this course
● Reasons for enrolling in this course
● Expectations for this course

About This Course Preface-xxi

How to Use Course Materials

To enable you to succeed in this course, these course materials employ a
learning module that is composed of the following components:
● Objectives – You should be able to accomplish the objectives after
completing a portion of instructional content. Objectives support
goals and can support other higher-level objectives.
● Lecture – The instructor will present information specific to the
objective of the module. This information will help you learn the
knowledge and skills necessary to succeed with the activities.
● Activities – The activities take on various forms, such as an exercise,
self-check, discussion, and demonstration. Activities are used to
facilitate mastery of an objective.
● Visual aids – The instructor might use several visual aids to convey a
concept, such as a process, in a visual form. Visual aids commonly
contain graphics, animation, and video.

Note – Many system administration tasks for the Solaris OS can be

accomplished in more than one way. The methods presented in the
courseware reflect recommended practices used by Sun Educational
Services.

Preface-xxii Network Administration for the Solaris™ 10 Operating System

Conventions
The following conventions are used in this course to represent various
training elements and alternative learning resources.

Icons

Discussion – Indicates a small-group or class discussion on the current

topic is recommended at this time.
!
?

Note – Indicates additional information that can help students but is not
crucial to their understanding of the concept being described. Students
should be able to understand the concept or complete the task without
this information. Examples of notational information include keyword
shortcuts and minor system adjustments.

Caution – Indicates that there is a risk of personal injury from a

nonelectrical hazard, or risk of irreversible damage to data, software, or
the operating system. A caution indicates that the possibility of a hazard
(as opposed to certainty) might happen, depending on the action of the
user.

About This Course Preface-xxiii

Typographical Conventions
Courier is used for the names of commands, files, directories, user
names, host names, programming code, and on-screen computer output;
for example:
Use the ls -al command to list all files.
host1# cd /home

Courier bold is used for characters and numbers that you type; for
example:
To list the files in this directory, type the following:
# ls

Courier italics is used for variables and command-line placeholders

that are replaced with a real name or value; for example:
To delete a file, use the rm filename command.

Courier italic bold is used to represent variables whose values are to

be entered by the student as part of an activity; for example:
Type chmod a+rwx filename to grant read, write, and execute
rights for filename.

Palatino italics is used for book titles, new words or terms, or words that
you want to emphasize; for example:
Read Chapter 6 in the User’s Guide.
These are called class options.

Preface-xxiv Network Administration for the Solaris™ 10 Operating System

Additional Conventions
Java™ programming language examples use the following additional
conventions:
● Method names are not followed with parentheses unless a formal or
actual parameter list is shown; for example:
“The doIt method...” refers to any method called doIt.
“The doIt() method...” refers to a method called doIt that takes
no arguments.
● Line breaks occur only where there are separations (commas),
conjunctions (operators), or white space in the code. Broken code is
indented four spaces under the starting code.
● If a command used in the Solaris OS is different from a command
used in the Microsoft Windows platform, both commands are
shown; for example:
If working in the Solaris OS
$ cd $SERVER_ROOT/bin
If working in Microsoft Windows
C:\> cd %SERVER_ROOT%\bin

About This Course Preface-xxv

Introducing the TCP/IP Model

Objectives
This module describes the fundamentals of the Transmission Control
Protocol/Internet Protocol (TCP/IP) model, including network protocols
and concepts. This module also describes the layers of the TCP/IP model,
including the Network Interface, Internet, Transport, and Application
layers. In addition, this module describes basic peer-to-peer
communication and some common TCP/IP protocols.

Upon completion of this module, you should be able to:

● Describe network model fundamentals
● Describe the layers of the TCP/IP model
● Describe basic peer-to-peer communication and related protocols
● Identify TCP/IP protocols

The course map in Figure 1-1 shows how this module fits into the current
instructional goal.

Configuring the Network Interface Layer

Introducing the Introducing LANs Describing Describing

TCP/IP and Their Ethernet ARP and
Model Components Interfaces RARP

Figure 1-1 Course Map

1-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Network Model Fundamentals

Introducing Network Model Fundamentals

The fundamentals required to understand computer networking are the
network model, the functions of the layers, and the protocols that govern
data transfer between two or more systems.

Network Protocols
Computer networks use protocols to communicate. Protocols define the
procedures to be followed by the systems involved in the communication
process. A data communication protocol is a set of rules that must be
followed for two electronic devices to communicate with each other.
These rules describe:
● Syntax – Data format and coding
● Semantics – Control information and error handling
● Timing – Speed matching and sequencing

Functions of Protocols

A protocol defines how systems can communicate and facilitates

communication between software, firmware, and other devices in data
transfer.

Each protocol provides a function essential for data communication. Each

software module that implements a protocol can be developed and
updated independently of other modules, as long as the interface between
the modules remains constant.

Many protocols provide and support data communication. Many

protocols are used so that communication can be broken into smaller,
manageable processes. They form a communication architecture, also
known as a protocol stack. The TCP/IP model is a protocol stack used by
the Solaris OS for data communication.

1-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Network Model Fundamentals

The features of a protocol stack are:

● Each layer has a specific purpose and exists on both the source and
destination hosts.
● Each layer communicates with its peer layer on another host in a
given process of communication.
● Each layer on a host acts independently of other layers on the same
machine but is synchronous with the same layer on other hosts.

Network Model Concepts

A networking model refers to a common structure that enables
communication between two or more systems.

Networking models consist of layers. You can think of layers as a series of

steps or functions that must be sequentially completed for communication
to occur between two systems.

The following mapping helps you to understand the network model:

● Model = structure
● Layer = functions
● Protocol = rules

Advantages of Using a Layered Model

Some of the advantages of a layered model are that it:

● Separates the complexity of networking into many functions or
layers
● Enables you to introduce changes or new features in one layer
without having to change the other layers
● Provides a standard to follow, enabling inter-operability between
software and hardware vendors
● Simplifies troubleshooting

Introducing the TCP/IP Model 1-3

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Layers of the TCP/IP Model

Introducing the Layers of the TCP/IP Model

Table 1-1 shows the four layers of the TCP/IP model. The TCP/IP model
is a four-layered structure resting on a common hardware platform. The
TCP/IP model was developed by the United States Department of
Defense (DOD) in the 1970s. It has standards that are defined and
described in Request for Comment (RFC) documents.

Table 1-1 TCP/IP Network Model

TCP/IP Layer Description

Application ● Consists of user-accessed application programs

and network services
● Defines how cooperating networks represent
data
Transport ● Manages the transfer of data by using
acknowledged and unacknowledged transport
protocols
● Manages the connections between cooperating
applications
Internet ● Manages data addressing and delivery between
networks
● Fragments data for the Network Interface layer
Network ● Manages the delivery of data across the physical
Interface network
● Provides error detection and packet framing

RFCs are a frame of reference for describing the protocol architecture and
functions specific to the TCP/IP protocol stack. For a complete listing of
RFCs, visit http://www.ietf.org/rfc.html.

1-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Layers of the TCP/IP Model

Network Interface Layer

Figure 1-2 shows the position of the Network Interface layer in the
TCP/IP network model. The primary functions of this layer are:
● Managing the delivery of data across the physical network
● Detecting errors
● Framing packets

TCP/IP Layers

Application Layer

Transport Layer

Internet Layer

Packet
data unit Network Interface Layer

Hardware Layer

Figure 1-2 TCP/IP Network Interface Layer

The Network Interface layer services the Internet layer by providing

communication between nodes on the same network. This layer defines
how bits are assembled into manageable units of data. A packet data unit
(PDU) is a structured series of bits with a well-defined beginning and a
well-defined end. Figure 1-3 shows a specific type of PDU known as an
Ethernet frame, where the bits are divided into fields containing
information labels, such as preamble, destination and source hardware
address, frame length or type, data, and cyclic redundancy check (CRC).

Preamble Destination Source Type Data CRC

Address Address

Figure 1-3 Structure of a Frame

Introducing the TCP/IP Model 1-5

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Layers of the TCP/IP Model

Examples of Network Interface layer protocols are:

● Institute of Electrical and Electronics Engineers (IEEE) 802.3 –
Ethernet standards
● IEEE 802.4 – Token bus standards
● IEEE 802.5 – Token ring standards
● IEEE 802.11 – Wireless network standards

Internet Layer
The Internet layer attempts to ensure that messages reach their
destination system using the most efficient route. Figure 1-4 shows the
position of the Internet layer in the TCP/IP network model. The primary
functions of the Internet layer are:
● Routing data between networks
● Fragmenting and reassembly of data

TCP/IP Layers

Application Layer

Transport Layer

Datagram Internet Layer

Network Interface Layer

Hardware Layer

Figure 1-4 TCP/IP Internet Layer

1-6 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Layers of the TCP/IP Model

Using routing information, the Internet layer determines the next directly
accessible node in the path to a packet’s destination. This node is either
the destination itself if the destination is on the local network, or the next
gateway node in the route if the destination is on another network. The
Internet layer uses the Internet Protocol (IP) and Internet Control Message
Protocol (ICMP). IP is responsible for fragmenting and routing data, and
ICMP assists routing and performs error detection and other network
management tasks. IP encapsulates data in datagrams, which in turn are
encapsulated inside Network Interface layer PDUs.

Transport Layer
The Transport layer manages the transfer of application data between
communicating hosts. It also controls the flow of data and defines the
transport quality of the data transmission. Figure 1-5 shows the position
of the Transport layer in the TCP/IP network model.

TCP/IP Layers

Application Layer
Segment
or Transport Layer

datagram
Internet Layer

Network Interface Layer

Hardware Layer

Figure 1-5 TCP/IP Transport Layer

The mechanisms used by the Transport layer to determine whether data

has been correctly delivered are:
● Acknowledgement responses
● Sequencing
● Flow control

Introducing the TCP/IP Model 1-7

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Layers of the TCP/IP Model

The Transport layer facilitates end-to-end data transfer. It supports

multiple operations simultaneously. Two Transport layer protocols are
found in the Solaris OS TCP/IP stack: the Transmission Control Protocol
(TCP) and the User Datagram Protocol (UDP). TCP uses packets called
segments, and UDP uses packets called datagrams. Both TCP segments and
UDP datagrams are encapsulated in Internet layer datagrams for
transmission to the next node.

The Transport layer facilitates two types of communication:

● Connection-oriented (TCP) – A connection must be established at the
Transport layer of both systems before the application can transmit
any data.
● Connectionless (UDP) – Systems do not need to establish a
connection with the recipient prior to data exchange.

TCP is a more reliable form of data exchange than UDP.

Application Layer
The top layer of the TCP/IP stack is the Application layer. Figure 1-6
shows the position of the Application layer in the TCP/IP network model.

TCP/IP Layers

Stream Layer 4
or Application Layer

Message
Layer 3
Transport Layer

Layer 2
Internet Layer

Layer 1
Network Interface Layer

Hardware Layer

Figure 1-6 TCP/IP Application Layer

1-8 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Layers of the TCP/IP Model

The Application layer includes all of the protocols that use Transport layer
protocols to deliver data to the Internet layer. There are many application
protocols, and new protocols are frequently included in the Solaris OS
TCP/IP stack.

Some common TCP/IP applications or protocols include:

● Telnet Protocol
● File Transfer Protocol (FTP)
● Simple Network Management Protocol (SNMP)
● Simple Mail Transfer Protocol (SMTP)
● Dynamic Host Configuration Protocol (DHCP)
● Domain Name System (DNS)
● Network Information Service (NIS)
● Network File System (NFS)
● Secure shell (SSH)

The Application layer handles the details of the particular application.

The primary functions of this layer are:
● Formatting data – Data is formatted based on a computer’s
architecture. For example, alphanumeric characters are represented
by using American Standard Code for Information Interchange
(ASCII) on a UNIX® host, and Extended Binary Coded Decimal
Interchange Code (EBCDIC) on an IBM mainframe computer.
Protocols operating at this layer of the model encapsulate packets
into streams or messages.
● Presenting data – If end users specify how they want their data
presented to them, the Application layer makes sure that it reaches
the end users in this format. A common syntax ensures compatibility
between various end-user applications and machines. The
Application layer also provides translations between locally
represented data and data used for transfer between end systems.
● Transporting data – The Application layer stipulates a transfer
syntax, which represents a coding agreement for the data to be
formatted and transferred. Remote procedure call (RPC) libraries
enable high-level language programs to make procedure calls to
other machines on a network. Application layer protocols, such as
NIS and NFS, use RPC for session management between clients and
servers.

Introducing the TCP/IP Model 1-9

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Describing Basic Peer-to-Peer Communication, Encapsulation, and Decapsulation

Describing Basic Peer-to-Peer Communication,

Encapsulation, and Decapsulation
In the TCP/IP model, adjacent layers in the model interact with each
other, and the corresponding layers at either end are also considered to
interact with each other.

Peer-to-Peer Communication
Peer-to-peer communication occurs when one layer on a system
communicates with a corresponding layer on another system. Figure 1-7
illustrates the peer-to-peer communications between the layers at either
end of a network interaction. For example, the Application layer on the
source system interacts with the Application layer on the destination
system.

Source System Destination System

Application X Application Y

Encapsulation Decapsulation
Application Message
Message or
or
Application
Layer User Data
Stream
Stream
User Data
Layer

Transport Layer TH A-PDU

Segment
Segment or
or TH A-PDU Transport Layer
Datagram
Datagram

Internet Layer IH T-PDU Datagram

Datagram IH T-PDU Internet Layer

Network Network
Interface Layer NH I-PDU NT Frame
Frame NH I-PDU NT
Interface Layer

Hardware Layer Signal Hardware Layer

Communication Path
Physical Transmission Medium

TH = Transport Header IH = Internet Header NH = Network Header NT = Network Trailer

Figure 1-7 Peer-to-Peer Communication

1-10 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Describing Basic Peer-to-Peer Communication, Encapsulation, and Decapsulation

Encapsulation and Decapsulation

Data passed down through each layer on the sender is encapsulated.
During encapsulation:
● Header information is added at each layer before the data is passed
down to the next layer. The header information helps the destination
system to direct the data to the appropriate protocol.
● At the final layer, trailer information is also added.

Figure 1-7 on page 1-10 shows data encapsulation occurring on the source
system.

Data arriving at a destination system is decapsulated. During

decapsulation:
● Data travels up through the layers.
● Headers and trailers are removed at each layer before the data is
passed up to the next layer.

Figure 1-7 on page 1-10 shows data decapsulation occurring on the

destination system.

Introducing the TCP/IP Model 1-11

TCP/IP Protocols
The following tables describe briefly the common TCP/IP protocols.

Table 1-2 shows a list of Network Interface layer protocols, their

corresponding RFCs, and a short description of each protocol.

Table 1-2 Some TCP/IP Network Interface Layer Protocol Descriptions

RFC Protocol Description

1055 SLIP Serial Line Internet Protocol compresses IP datagrams on serial

lines.
1661 PPP Point-to-Point Protocol transmits datagrams over serial,
point-to-point links.

1-12 Network Administration for the Solaris™ 10 Operating System

Table 1-3 shows a list of Internet layer protocols, their corresponding

RFCs, and a short description of each protocol.

Table 1-3 Some TCP/IP Internet Layer Protocol Descriptions

RFC Protocol Description

826 ARP Address Resolution Protocol defines the method used to map a
32-bit IP address to a 48-bit Ethernet address.
903 RARP Reverse Address Resolution Protocol defines the method used to
map a 48-bit Ethernet address to a 32-bit IP address.
791, 950, IP Internet Protocol determines the path that a datagram must take,
919, 922 based on the destination host’s IP address.
792 ICMP Internet Control Message Protocol communicates error messages
and other controls within IP datagrams.
2401, IPSec- • Internet Protocol Security Architecture
2406, related
2402, RFCs • Encapsulating Security Payload (ESP)
2407, • IP authentication header
2408
• Internet IP security domain of interpretation for the Internet
Security Association and Key Management Protocol (ISAKMP)

Table 1-4 shows a list of Transport layer protocols, their corresponding

RFCs, and a short description of each protocol.

Table 1-4 Some TCP/IP Transport Layer Protocol Descriptions

RFC Protocol Description

793 TCP Transmission Control Protocol is a connection-oriented protocol

that provides the full-duplex, stream service on which many
application protocols depend.
768 UDP User Datagram Protocol is a connectionless protocol that provides
non-acknowledged datagrams delivered over reliable networks.

Introducing the TCP/IP Model 1-13

Table 1-5 shows a list of some Application layer protocols, their

corresponding RFCs, and a short description of each protocol.

Table 1-5 Some TCP/IP Application Layer Protocol Descriptions

RFC Protocol Description

1034, 1035 DNS Domain Name System is a text-based, distributed

database for domain names, host names, and IP
addresses. Domain names index a hierarchical tree
of names and ultimately identify hosts and
domains.
959 FTP File Transfer Protocol is used to transfer files
between systems.
854, 855 Telnet Telnet Protocol enables terminals and
terminal-oriented processes to communicate on a
network by using TCP/IP.
1258, 1280 Remote login The rlogin command enables users to log in to
remote hosts.
2131 DHCP Dynamic Host Configuration Protocol is
responsible for automatically assigning IP
addresses in an organization’s network.
2821 SMTP Simple Mail Transfer Protocol transfers electronic
mail (email) messages from one machine to another.
1157 SNMP Simple Network Management Protocol enables
system administrators to monitor and control
network devices.
1939 POP3 Post Office Protocol, version 3, enables users to
access their email box across a wide area network
(WAN) or local area network (LAN) from a POP3
server.
2060 IMAP4 Internet Message Access Protocol, version 4, enables
users to access their email box across the network
from an IMAP4 server. IMAP4 is suited to mobile
users because the mail remains on the server.
IMAP4 is server-centric, whereas POP3 is
client-centric.

1-14 Network Administration for the Solaris™ 10 Operating System

Table 1-5 Some TCP/IP Application Layer Protocol Descriptions (Continued)

RFC Protocol Description

1945, 2068 HTTP Hypertext Transfer Protocol and Secure Hypertext
None HTTPS Transfer Protocol are used on the World Wide Web
to transfer text, pictures, audio, and other
multimedia information that is accessible through a
web browser.
None SSH Secure shell is based on a number of drafts. SSH
logs in securely to a system across a network.

Introducing the TCP/IP Model 1-15

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing the TCP/IP Model

Exercise: Reviewing the TCP/IP Model

In this exercise, you review the TCP/IP model.

Preparation
There is no preparation for this exercise.

Tasks
Perform the following steps:
1. List the layers of the TCP/IP network model by their name and
function.
Name:_______________________________________________________
Function: ____________________________________________________

Name:_______________________________________________________
Function: ____________________________________________________

Name:_______________________________________________________
Function: ____________________________________________________
2. In your own words, define the term peer-to-peer.
_____________________________________________________________
_____________________________________________________________
3. In your own words, define the term protocol.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

1-16 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing the TCP/IP Model

4. Which protocols are part of the TCP/IP suite?

a. ARP
b. IP
c. TCIP
d. ICMP
5. Which statements describe data encapsulation?
a. Data travels up through layers at the destination system’s end.
b. Data travels down through layers at the source system’s end.
c. Headers and trailers are removed before the data is passed up
to the next layer.
d. Headers and trailers are added before the data is passed down
to the next layer.

Introducing the TCP/IP Model 1-17

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

1-18 Network Administration for the Solaris™ 10 Operating System

Exercise Solutions
Solutions to the exercise are as follows:
1. List the layers of the TCP/IP network model by their name and
function.
Name: Application
Function: Consists of user-accessed application programs and network
services. This layer is also responsible for defining the way in which
cooperating networks represent data.
Name: Transport
Function: Manages the transfer of data using connection-oriented and
connectionless transport protocols.
Name: Internet
Function: Manages data addressing and delivery between networks, as well
as fragmenting data for the Network Interface layer.
Name: Network Interface
Function: Manages the delivery of data across the physical network. This
layer provides error detection and packet framing.
2. In your own words, define the term peer-to-peer.
Peer-to-peer communication is the ability of a specific layer to communicate
with a corresponding layer on another host.
3. In your own words, define the term protocol.
A protocol is set of rules governing the exchange of data between two
entities. These rules describe:
● Syntax – Data format and coding
● Semantics – Control information and error handling
● Timing – Speed matching and sequencing

Introducing the TCP/IP Model 1-19

4. Which protocols are part of the TCP/IP suite?

a. ARP
b. IP
d. ICMP
5. Which statements describe data encapsulation?
b. Data travels down through layers at the source system’s end.
d. Headers and trailers are added before the data is passed down to the
next layer.

1-20 Network Administration for the Solaris™ 10 Operating System

Introducing LANs and Their Components

Objectives
This module describes LANs and their components. This module also
introduces LAN media, including IEEE LAN media identifiers and
Ethernet media. In addition, this module introduces network devices,
including shared hubs, bridges, and switches.

Upon completion of this module, you should be able to:

● Describe network topologies
● Describe LAN media
● Describe network devices

The course map in Figure 2-1 shows how this module fits into the current
instructional goal.

Configuring the Network Interface Layer

Introducing the Introducing LANs Describing Describing

TCP/IP and Their Ethernet ARP and
Model Components Interfaces RARP

Figure 2-1 Course Map

2-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Network Topologies

Introducing Network Topologies

The topology of a network relates to the way nodes on the network are
physically wired together. Many different network topologies are
commonly implemented in today’s network environments. Topology is
one of the most important considerations when you design a network.
Consider the size of the network, the type of business, any failover
requirements, and the amount of network traffic you expect when you
make decisions about which topology to use.

Bus Topologies
The bus configuration was the typical LAN topology for the original
Ethernet network specification. A typical bus configuration has coaxial
cables running through an area. Systems are attached at points along the
cable to enable communication with each other. The bandwidth of the
cable is shared between all the systems connected to the cable. Figure 2-2
shows an example of a bus configuration.

Figure 2-2 Bus Configuration

2-2 Network Administration for the Solaris™ 10 Operating System

Star Topologies
The LAN topology in a star configuration uses a central location, or hub,
from which a number of signal-carrying cables extend to each individual
device on a branch. Star configurations are well suited to many of today’s
LAN network methodologies.

An intelligent hub controls:

● Which messages are transferred between which ports
● What devices are connected to each port or segment

Note – A non-intelligent hub does not make any decisions about which
ports to send data. This essentially makes star configurations behave
exactly like bus configurations from the point of view of the nodes. A
benefit of the star configuration is that a fault on the cable to a node
affects only that node.

Depending upon the LAN methodology, there is a limit to the number of

segments that can be linked together. Figure 2-3 shows an example of the
star configuration.

Hub

Figure 2-3 Star Configuration

Introducing LANs and Their Components 2-3

Ring Topologies
In a ring configuration, the output of one node connects to the input of the
next node. Each node in the ring is between two other nodes. In a ring
network, if one node stops functioning the ring can be broken, which
affects communication on the network.

With the invention of the intelligent central hub, a ring configuration can
be implemented with the reliability of a star configuration. The reliability
is a result of the intelligent hub’s ability to bypass a non-functioning node
in the ring. Figure 2-4 shows a star-wired ring configuration.

Figure 2-4 Ring Configuration

2-4 Network Administration for the Solaris™ 10 Operating System

VLAN Topologies
Virtual local area network (VLAN) topologies are becoming increasingly
popular. A VLAN topology is implemented with a central device that
supports VLAN technology. All systems are physically connected to the
same device; however, the device is configured with multiple logical
networks (the VLANs) that have one or more ports on the switch assigned
to them. For example, on an 8-port switch, ports 1, 2, 5, and 6 can be
assigned to network A, while ports 3, 4, 7, and 8 can be assigned to
network B. The traffic on network A is separated from the traffic on
network B, and traffic does not pass between the two networks. Ports can
be assigned to different VLANs based on port number, the hardware or
software address of the systems, or the protocols used by the systems.

Using VLANs reduces the size of broadcast domains. You can move
computer systems between VLANs without any hardware configuration.
Although the term VLAN is in common use, every vendor provides their
own VLAN implementation and enhancements. This makes the task of
defining the term VLAN difficult.

Figure 2-5 shows an example of a network with all systems on the same
broadcast domain.

All systems on the same broadcast domain

Figure 2-5 VLAN With All Systems on the Same Domain

Introducing LANs and Their Components 2-5

Figure 2-6 shows how a single switch can be configured into three VLANs
so that there are three separate, smaller broadcast domains.

Smaller Broadcast Domains

Figure 2-6 VLAN Configurations

2-6 Network Administration for the Solaris™ 10 Operating System

Figure 2-7 shows, through shading, how the three VLANs are configured
by using software on the switch to which all systems are connected.

Three VLANs defined (by color)

Figure 2-7 Three VLANs Defined

Introducing LANs and Their Components 2-7

Introducing LAN Media

Many types of LAN methodologies include the media’s specifications as
part of the LAN’s name (identifier).

IEEE Identifiers
For the various types of LANs, the IEEE identifier indicates the types of
media used. These identifiers include three pieces of information:
● The first piece of information, 10, 100, or 1000, represents a media
speed of 10 megabits per second (Mbps), 100 Mbps, or 1000 Mbps,
respectively.
● The second piece of information, BASE, stands for baseband, which is
a type of signalling. Baseband signalling uses the entire bandwidth
of the cable for one signal. Two systems cannot transmit signals at
the same time.
● The third piece of information indicates the segment type or the
approximate segment length. For thick coaxial cable, 5 indicates the
500-meter maximum length allowed for individual segments. For
thin coaxial cable, 2 indicates 200 meters, which is rounded up from
the 185-meter maximum length for individual thin coaxial segments.
The designation T indicates that the segment type is twisted-pair,
and the designation F stands for fiber-optic cable.

An example identifier is 100BASE-T, which means that the transmission

speed is 100 megabits per second, baseband signaling is used, and the
media is twisted pair. Figure 2-8 shows how baseband segments are
designated.

Type of Signal = Baseband

Speed = 10 Mbs Segment Length

10 BASE-5
= 500 Meter

Type of Media
10 BASE-T
= Twisted Pair

Figure 2-8 IEEE Media Identifier

2-8 Network Administration for the Solaris™ 10 Operating System

The thick coaxial cable media segment was the first media segment to be
defined in the Ethernet specifications. The thin coaxial cable media
segment was defined next, followed by the twisted-pair and fiber-optic
media segments. The twisted-pair segment type is widely used today for
making network connections to the desktop.

IEEE 802.3 Types

Many different types of LAN media have been used, from half-inch thick
coaxial cable to optical fibre measured in microns. Consider the physical
distance, the security, the cost of the media, the cost to install the media,
and the media that is supported by current technology when you make
decisions about which LAN media to use.

10BASE-T Media Type

The 10BASE-T media type uses twisted-pair cables. The specifications for
this media type were published in 1990. This is one of the most widely
used media types for connections to the desktop.

The 10BASE-T media type uses two pairs of wires: one pair receives data
signals, and the other pair transmits data signals. The two wires in each
pair must be twisted together for the entire length of the segment. This is
a standard technique that improves the signal-carrying characteristics of a
wire pair. Multiple twisted-pair segments communicate using a multiport
hub or switch. You can implement 10BASE-T over Category 3 (two to
three twists per foot) or Category 5 (two to three twists per inch)
twisted-pair cable.

100BASE-TX Media Type

The 100BASE-TX media type is based on specifications published in the

American National Standards Institute (ANSI) Twisted-Pair – Physical
Media Standard (TP-PMD). The 100BASE-TX media type carries 100 Mbps
signals over two pairs of wire. Because the ANSI TP-PMD specification
provides for the use of either unshielded twisted-pair or shielded
twisted-pair cable, 100BASE-TX uses both. You can only implement
100BASE-TX over Category 5 cable.

Introducing LANs and Their Components 2-9

100BASE-T4 Media Type

The 100BASE-T4 media type operates over four pairs of wires. The
signaling system makes it possible to provide fast Ethernet signals
(100 megaHertz (MHz)) over any existing standard voice-grade
Category 3 or 4 unshielded twisted-pair cable that might be installed. One
pair of wires transmits data (TX), one pair receives data (RX), and two
pairs are bidirectional (BI) data pairs.

The 100BASE-T4 specifications recommend using Category 5 patch cables,

jumpers, and connecting hardware whenever possible because these
higher-quality components and cables improve the reception of signals on
the link.

100BASE-FX Media Type

The 100BASE-FX (fast fiber-optic) media system uses pulses of light

instead of electrical currents to send signals. The use of fiber provides
superior electrical isolation for equipment at each end of the fiber link.
While LAN equipment used in metallic media segments has protection
circuits designed for typical indoor electrical hazards, fiber-optic media is
nonconductive. This complete electrical isolation provides immunity from
much larger electrical hazards, such as lightning strikes, and from the
flow of current that can result from having different levels of electrical
ground currents that can be found in separate buildings. Complete
electrical isolation is essential when using LAN segments to link separate
buildings.

An advantage of the 100BASE-FX fiber-optic link segment is that it can

span long distances. Fiber also provides more security because the optical
signal does not cause induction.

1000BASE-X Media Type

In 1998, the IEEE Standards Board approved the gigabit Ethernet standard
for 1000 Mbps over multimode fiber (MMF) and single-mode fiber.
Gigabit Ethernet is an extension of the successful 10-Mbps and 100-Mbps
802.3 standards. Gigabit Ethernet provides a raw bandwidth of 1000 Mbps
and maintains full compatibility with the installed base of over 100
million Ethernet nodes. Gigabit Ethernet includes both full-duplex and
half-duplex operating modes.

The 1000BASE-X standard refers to two implementations of fiber-optic

segment types: 1000BASE-SX and 1000BASE-LX.

2-10 Network Administration for the Solaris™ 10 Operating System

1000BASE-SX Media Type

The 1000BASE-SX media system is the shortest wavelength specification

because it uses short wavelength lasers to transmit data over fiber-optic
cable. Sun’s implementation of the 1000BASE-SX system specification
supports the following distances:
● 300 meters over 62.5-micron MMF cable
● 550 meters over 50-micron MMF cable

1000BASE-LX Media Type

The 1000BASE-LX media system is the longest wavelength specification

because it uses longwave lasers to transmit data over fiber-optic cable.
Sun’s implementation of the 1000BASE-SX system specification supports
the following distances:
● 550 meters over 62.5-micron and 50-micron MMF cable
● 3000 meters over 9-micron single-mode fiber cable

1000BASE-CX Media Type

The 1000BASE-CX media system is the shortest-haul copper specification

because it uses high-quality shielded copper jumper cables to connect
devices. The 1000BASE-CX system uses connecting equipment in small
areas, such as wiring closets. Sun’s implementation of the 1000BASE-CX
system specification supports the 25 meters over twin-axial cable.

1000BASE-T Media Type

In 1999, the IEEE Standards Board approved the standard for the
1000BASE-T media system, for data transmissions of 1000 Mbps. This
standard is for gigabit Ethernet over four pairs of Category 5 unshielded
twisted-pair (UTP) cable.

The 1000BASE-T system uses the previously defined standards

100BASE-TX, 100BASE-T2, and 100BASE-T4 for its signal methodology.
Sun’s implementation of the 1000BASE-T system specification supports
distances up to 100 meters over four pairs of Cat-5 UTP (using a complex
encoding scheme).

Introducing LANs and Their Components 2-11

Introducing Network Devices

Networks consist of many different devices and device types. Devices that
are found on LANs range from printers to sophisticated switching
devices.

Repeaters
Repeaters are devices that amplify and regenerate the data signal, bit by
bit, to extend the distance of the transmission. A repeater does not read or
interpret the data.

Hubs
Shared hubs are the central devices of a star topology network. The hubs
connect all the hosts in a twisted-pair Ethernet installation. Hubs are
typically used in small LANs in which network performance is not
critical. Collisions commonly occur on a network implementing hubs
because the collision domain consists of all systems connected to the hub.

Bridges
A bridge is a network-layer device that reads and interprets addresses for
filtering or forwarding packets. Bridges connect two or more network
segments. Collisions commonly occur on a bridged network because the
collision domains often consist of more than one system.

Switches
Switches are multiport devices that control the logical dynamic
connection and disconnection between any two cable segments. Switches
are high-bandwidth devices because multiple data paths can be
established and used simultaneously.

Switches reduce the number of collisions on a network by replacing a

single shared data path with multiple dedicated data paths.

2-12 Network Administration for the Solaris™ 10 Operating System

Figure 2-9 shows how you can use an Ethernet switch to interconnect
shared hubs. Interconnecting the hubs increases intranet transfer rates
greatly and makes connections more economical. Because connecting
multiple subnets to an intranet using a switch requires no protocol
changes, the cost of a speed increase is minimized.

Hub
Hub

10BASE-T 10BASE-T

Ethernet Switch
10BASE-T
Hub
100BASE-T

10BASE-T 10BASE-T

Hub
Hub

Figure 2-9 Ethernet Switches

Introducing LANs and Their Components 2-13

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing LANs and Their Components

Exercise: Reviewing LANs and Their Components

In this exercise, you test your knowledge about common LAN
terminology.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Tasks
To test your knowledge about common LAN terminology, answer the
following questions:
1. Match the terms to their definition.

_____ Star topology a. This topology uses a central device,

from which signal-carrying cables
are connected to each individual
device on a branch. Additionally,
each individual device can be
configured to be in its own broadcast
domain.
_____ VLAN topology b. The cabling standard for 100-Mbps,
unshielded, twisted-pair media.
_____ 100BASE-TX c. The central device through which all
hosts connect in a single broadcast
domain in a twisted-pair, Ethernet
installation.
_____ Category 5 d. This topology uses a central device,
from which signal-carrying cables
extend to each individual device on
this branch.
_____ Switch e. The IEEE standard for 100-Mbps,
twisted-pair media.
_____ Shared hub f. The multiport device that provides
for the logical dynamic connection
and disconnection between any two
cable segments without operator
intervention.

2-14 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing LANs and Their Components

2. Which are topologies found in LANs?

a. Ring
b. Star
c. Bus
d. Wing
3. Which specifications support a media speed of 100 Mbps?
a. 10BASE-5
b. 10BASE-2
c. 100BASE-FX
d. 10BASE-T
e. 100BASE-T4
f. 100BASE-TX

Introducing LANs and Their Components 2-15

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

2-16 Network Administration for the Solaris™ 10 Operating System

Exercise Solutions
Solutions to the exercise are as follows:
1. Match the terms to their definition.

d Star topology a. This topology uses a central

device, from which signal-carrying
cables are connected to each
individual device on a branch.
Additionally, each individual
device can be configured to be in
its own broadcast domain.
a VLAN topology b. The cabling standard for
100-Mbps, unshielded,
twisted-pair media.
e 100BASE-TX c. The central device through which
all hosts connect in a single
broadcast domain in a
twisted-pair, Ethernet installation.
b Category 5 d. This topology uses a central
device, from which signal-carrying
cables extend to each individual
device on this branch.
f Switch e. The IEEE standard for 100-Mbps,
twisted-pair media.
c Shared hub f. The multiport device that provides
for the logical dynamic connection
and disconnection between any
two cable segments without
operator intervention.

Introducing LANs and Their Components 2-17

2. Which are topologies found in LANs?

a. Ring
b. Star
c. Bus
3. Which specifications support a media speed of 100 Mbps?
c. 100BASE-FX
e. 100BASE-T4
f. 100BASE-TX

2-18 Network Administration for the Solaris™ 10 Operating System

Describing Ethernet Interfaces

Objectives
This module describes Ethernet’s Carrier Sense Multiple Access/Collision
Detect (CSMA/CD) access method. This module also describes the
Ethernet frame, including addresses, frame fields, encapsulation,
maximum transmission units (MTUs), and errors. In addition, this
module describes network utilities that assist in configuring and
troubleshooting the system’s network interfaces.

Upon completion of this module, you should be able to:

● Describe Ethernet concepts
● Describe Ethernet frames
● Use network utilities

The course map in Figure 3-1 shows how this module fits into the current
instructional goal.

Configuring the Network Interface Layer

Introducing the Introducing LANs Describing Describing

TCP/IP and Their Ethernet ARP and
Model Components Interfaces RARP

Figure 3-1 Course Map

3-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Ethernet Concepts

Introducing Ethernet Concepts

Ethernet was designed as a packet-switching LAN over broadcast
technology. Devices connect to the network and compete for access to a
shared communications channel. The IEEE 802.3 standard for Ethernet
was defined in 1985. Ethernet standards are implemented at the Network
Interface layer of the TCP/IP protocol model.

Major Ethernet Elements

The three major elements of Ethernet networks are:
● Ethernet packets, called frames – These are units of data sent across
the network.
● The Ethernet access method, CSMA/CD – This method controls
packet transmission and information flow across the Ethernet
hardware.
● Hardware cables, connectors, and circuitry – These transfer data to
and from systems across the network.

CSMA/CD Access Method

Non-switched Ethernet uses a broadcast delivery mechanism in which
each frame that is transmitted is heard by every station. CSMA/CD is an
arbitrary access method that provides a method to detect and recover
from simultaneous transmissions. Each interface monitors the network for
a carrier signal (Carrier Sense). During a gap between transmissions, each
interface has an equal chance to transmit data (Multiple Access). If two
interfaces try to transmit data at the same time, the transceiver circuitry
detects a transmit collision (Collision Detection). Both interfaces must
wait a short period of time before they attempt to resend data. The wait
period is determined by using an exponential back-off algorithm.

3-2 Network Administration for the Solaris™ 10 Operating System

Figure 3-2 shows how CSMA/CD accesses the network. The figure
represents the CSMA/CD developed for the original Ethernet topology.
Ethernet originally consisted of a single-wire, bidirectional backbone. The
theory of operation is still the same today, but Ethernet topologies use
more advanced components that permit a higher transmission rate.

Multiple The host has

Access a message.

Carrier Is there
Yes

Sense traffic on the

network?

The host sends

a message.

Collision Was there

Detect a collision?

Yes

Success.

Send the

jam signal.

Wait. Back off

exponentially.

Figure 3-2 Structure of CSMA/CD

Describing Ethernet Interfaces 3-3

Full-Duplex and Half-Duplex Mode

Full-duplex network mode is when a system can send and receive data
simultaneously on a bidirectional network.

Half-duplex network mode is when a system can either send or receive

data on a bidirectional network. The system cannot send and receive data
simultaneously.

Full-duplex networking is more efficient than half-duplex networking.

Ethernet Statistics
The netstat command provides statistics on network-related
information, such as the collision rate. In a shared-media topology,
collisions occur frequently. The more transmitting nodes there are on a
network, the greater the likelihood that collisions occur because of an
increase in network traffic. The collision rate increases exponentially until
there is almost no throughput of data.

To display the current usage of the Ethernet interfaces, execute the

netstat command with the -i option, for example:
# netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 52559 0 52559 0 0 0
hme0 1500 sys11 sys11 18973 0 30292 0 0 0
#

Collision Rates

Collisions occur when two or more systems attempt to transmit data on

the network at the same time. Collision rates indicate the number of
collisions that occur on a network. Use collision rates to diagnose network
performance problems that are caused by collisions on a network.

To compute the collision rate, multiply 100 by the number of collisions,

and divide the product by the total number of output packets.

For example, assume that the netstat command reports 12 collisions and
1302 output packets. Calculate the collision rate as follows:

100 * 12 / 1302 = 1.0 percent collision rate

3-4 Network Administration for the Solaris™ 10 Operating System

In general:
● Collision rates higher than 5 percent on a 10-Mbps Ethernet network,
and 10 percent on a 100-Mbps Ethernet network, are the first
indication of network overload.
● Faulty network cabling frequently causes collisions through electrical
problems. Technical experts use special electronic equipment to
detect the elements that cause a collision and to provide a solution.
● Switches minimize collisions by limiting the collision domain to one
system.

Input and Output Errors

If the netstat command reports large numbers (approximately

20–25 percent) of input or output errors on the network system, you can
attribute the problem to one of the following reasons:
● Duplicate IP addresses used on the same network
● A faulty cable
● A faulty port on a concentrator, hub, switch, or router
● A faulty interface

Describing Ethernet Interfaces 3-5

Introducing Ethernet Frames

An Ethernet frame is a single unit of data transported across the LAN. It is
a series of bits with a well-defined beginning and a well-defined end. The
Ethernet specification describes how bits are encoded on the cable and
how devices on the network detect the beginning and the end of a
transmission.

Ethernet Addresses
An Ethernet address is the device’s unique hardware address. An
Ethernet address is sometimes referred to as a media access control
(MAC) address. An Ethernet address is 48 bits long and is displayed as
12 hexadecimal digits (six groups of two digits) separated by colons. An
example of an Ethernet address is 08:00:20:1e:56:7d.
● The IEEE administers unique Ethernet addresses. IEEE designates
the first three octets as vendor-specific. Sun has various Ethernet
prefixes, which include 08:00:20, 00:00:be, and 00:03:ba. Sun
assigns the last three octets to the products it manufactures to ensure
that each node on an Ethernet network has a unique Ethernet
address.
The list of vendor specific Ethernet addresses can be found at:
http://standards.ieee.org/regauth/oui/oui.txt
● The IEEE specification enables the vendor to decide whether to use
the host-based addressing approach or the port-based addressing
approach. By default, Sun uses host-based addressing on its
networks interface cards (NICs).
The network interface drivers in Sun systems obtain the Ethernet
address for the Ethernet interface from a system’s hardware. For
example, desktop systems use the address in the nonvolatile random
access memory (NVRAM) chip, while some large server systems
obtain their address from a special board installed in the system. By
default, all interface addresses on a system use just one Ethernet
address, either the NVRAM or the special board, even though each
Ethernet interface controller has a built-in Ethernet address.

For systems configured to have more than one interface on the same
physical subnet, you need a unique Ethernet address that is different from
the primary host-based assigned Ethernet address.

3-6 Network Administration for the Solaris™ 10 Operating System

Types of Ethernet Addresses

There are three types of Ethernet addresses: unicast, broadcast, and

multicast.

Unicast Addresses

Unicast addresses are used for one-to-one communication. The system

uses a unicast address to send a message to another system on the local
Ethernet network. You can use a system’s unique Ethernet address as a
unicast address.

Broadcast Addresses

A device uses a broadcast address to send messages to all systems on the

local Ethernet network. The Ethernet broadcast address is represented in
the form of all 1s in binary format and as ff:ff:ff:ff:ff:ff in
hexadecimal format. When the Network Interface layer receives an
Ethernet frame with a destination address of all 1s, it passes the address to
the next layer for processing.

Multicast Addresses

A system uses a multicast address to send a message to a subset of

systems on the local Ethernet. In Ethernet multicast addressing, the value
of the first three octets determines if the address is multicast. The last
three octets determine the specific multicast’s group identity.

Describing Ethernet Interfaces 3-7

Setting a Local Ethernet Address

In today’s network environments, many systems have multiple interfaces,
often on the same subnet or collision domain. Because an Ethernet
address targets systems, each interface on the same network or subnet on
a multi-interface system must have a unique Ethernet address. Sun
network adapters have local Ethernet addresses encoded in their
programmable read-only memories (PROMs).

To view the current, host-based Ethernet address, execute the banner

command at the ok prompt:
ok banner
Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 360MHz), No Keyboard
OpenBoot 3.19, 128 MB (50 ns) memory installed, Serial #12153379.
Ethernet address 8:0:20:b9:72:23, Host ID: 80b97223.
ok

To display the Ethernet address assigned to each interface, execute the

ifconfig -a command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Set the local-mac-address? variable in the system’s electrically erasable

programmable read-only memory (EEPROM) to true to enable the use of
port-based Ethernet addresses.

To view the current value of the local-mac-address? variable in the

EEPROM, execute the following command:
# eeprom local-mac-address?
local-mac-address?=false
#

3-8 Network Administration for the Solaris™ 10 Operating System

You can set the local-mac-address? variable to true by using the

eeprom command. This enables network drivers to use their own
port-based addresses after a reboot and not the system-default, host-based
addresses. To make this change, type the following command:
# eeprom local-mac-address?=true
#

You can also use the ifconfig ether command to configure port-based
addressing. This might be necessary if the interface card cannot supply its
own unique Ethernet address. You can change the interface Ethernet
address of 8:0:20:b9:72:23 from an Ethernet address assigned globally
to an address of 0a:0:20:f0:ac:61 assigned locally by changing the
seventh bit to 1, and assigning a local unique number to the last three
bytes.

To change the Ethernet address, type the following command:

# ifconfig hme0 ether a:0:20:f0:ac:61
#

To verify a change in the Ethernet address, type the following command:

# ifconfig hme0
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether a:0:20:f0:ac:61
#

This change of Ethernet address is effective until you reboot the system.
To make the change persistent across reboots, modify the
/etc/hostname.interface file.

Describing Ethernet Interfaces 3-9

Ethernet-II Frame Analysis

The Ethernet-II frame is a single unit of data transported through the
LAN. It is a series of bits with a definite beginning and a definite end. The
Ethernet specification describes how bits are encoded on the network and
how hosts on the network detect the beginning and the end of a
transmission. Figure 3-3 shows the Ethernet-II frame format.

Oc
tet
Loc
atio
n:
1-6

7-1
2
13-
Pre 14
am
ble
64 D ad 15-
151
Bits
dr 4 (M
48 B S ad a xim
its dr um
)
48 Las
Bits Typ t 4
e Oc
16 tets
Bits
(Ma Da
xim ta
um
150
0 Byt
es) CR
C
32
Bits

Figure 3-3 Ethernet-II Frame

Note – There are two common Ethernet frame formats: the Ethernet-II
format and the logical link control (802.3) format. The primary difference
between these formats is that in the Ethernet-II format, the fourth field is
a type field, while in the 802.3 format, the fourth field is a frame length
field. In the TCP/IP environments, typically the Ethernet-II frame format
is used.

3-10 Network Administration for the Solaris™ 10 Operating System

The information in each frame is necessary to receive and transmit data.

Table 3-1 shows a description of each frame field.

Table 3-1 Ethernet-II Frames

Field Description

Preamble The 64-bit Ethernet preamble field is used for

synchronization and is composed of 1s and 0s. Interface
synchronization helps the receiving network interfaces
determine where the Ethernet frame begins.
D addr The Ethernet address of the destination host.
S addr The Ethernet address of the source host.
Type The type of data encapsulated in the Ethernet frame, such
as IP, ARP, RARP, and IP version 6 (IPv6).
Data The data payload, which consists of header information
and data from the higher-level protocols.
CRC The cyclic redundancy check (CRC) used for error
detection. The value is calculated based on frame contents
by both the sending and the receiving hosts. If the two
values are not equivalent, the frame is discarded.

Describing Ethernet Interfaces 3-11

Maximum Transmission Units

The maximum transmission unit (MTU) is the largest amount of data that
can be transferred across a physical network. The MTU is hardware
specific. For a physical Ethernet interface, the MTU is 1500 bytes, while
the MTU is 8232 bytes for a loopback interface. The loopback interface is a
pseudo device that communicates, or loops back, to the host itself.

Note – The Sun GigaSwift Ethernet adapters hardware implements jumbo

frames, which support MTUs of up to 9194 bytes.

Figure 3-4 shows how application data is broken down according to the
maximum frame size across the LAN.

Application
Layer Application Data

Transport
Layer Transport Datagram

Internet
Layer Internet Datagram

Network
Interface 1500-byte Payload
Layer

Hardware Layer

Figure 3-4 Transportation of Data Across an Ethernet Network

3-12 Network Administration for the Solaris™ 10 Operating System

Ethernet Frame Errors

Ethernet frames can be significantly damaged when they traverse a
network. When a host receives a frame, the Ethernet interface performs
integrity checking to verify Ethernet frame validity. Table 3-2 shows some
of these error conditions.

Table 3-2 Error Conditions

Error Definition

Runts Packets that are less than 64 bytes, including the header, are
too short and are discarded. Runts are usually caused by
collisions. These can be formed by poor wiring and
electrical interference.
Jabbers Frames that are greater than 1518 bytes, including the
header, are too long and are discarded. These indicate that a
device has electrical problems.
Long A frame that is between 1518 bytes and 6000 bytes in length,
including the header, is too long. These are often caused by
faulty hardware or software on the sending system.
Giant A frame that is more than 6000 bytes long, including the
header, is too long. These are often caused by faulty
hardware or software on the sending system.
Bad CRC If the received packet fails the CRC, the packet is corrupted
and discarded. This is also known as a frame check sequence
(FCS) error.

Describing Ethernet Interfaces 3-13

Using Network Utilities

The Solaris 10 OS includes many different utilities to help you configure
and troubleshoot the system’s network interfaces.

Using the snoop Utility

The superuser can run the snoop utility to capture network packets and to
display the packet contents on the screen. Alternatively, you can capture
packets to a file as they are received, decreasing packet loss under
high-traffic conditions. You can use the snoop utility to display the
contents of the file. The snoop utility displays packet data in one of three
forms:
● Summary – This is the output mode when the -v or -V options are
not used on the command line.
Only data that pertains to the highest-level protocol header is
displayed. For example, an NFS packet only displays NFS
information. The underlying RPC, UDP, IP, and Ethernet frame
header information are not displayed.
To examine only broadcast frames on the hme0 interface in summary
mode, type the following:
# snoop -d hme0 broadcast
Using device /dev/hme (promiscuous mode)
192.168.1.12 -> (broadcast) ARP C Who is 192.168.1.3, sys13 ?
sys12 -> (broadcast) ARP C Who is 192.168.1.2, sys12 ?
sys12 -> (broadcast) ARP C Who is 192.168.1.1, sys11 ?
#
● Verbose – To invoke the verbose option, use the -v option on the
command line.
Multiple lines of output display for every protocol header in the
network packet.

3-14 Network Administration for the Solaris™ 10 Operating System

To examine only broadcast packets on the hme0 interface in the

verbose mode, type the following:
# snoop -v -d hme0 broadcast
Using device /dev/hme (promiscuous mode)
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 8 arrived at 13:18:44.01
ETHER: Packet size = 60 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 8:0:20:90:b5:c7, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender's hardware address = 8:0:20:90:b5:c7
ARP: Sender's protocol address = 192.168.1.2, sys12
ARP: Target hardware address = ?
ARP: Target protocol address = 192.168.1.1, sys11
ARP:
● Verbose summary – A single line of output is displayed for every
protocol or application contained within the packet.
You can examine packets by using both verbose summary mode and
by filtering the packets by IP address.
The snoop utility only displays output when there is network traffic
and the traffic matches the filter criteria.
For example, to examine packets by using verbose summary mode
and by filtering the packets by IP address on the hme0 interface,
perform the following command:
# snoop -d hme0 -V 192.168.1.2
Using the /dev/hme device (promiscuous mode)
...
sys12 -> sys11 ETHER Type=0800 (IP), size = 98 bytes
sys12 -> sys11 IP D=192.168.1.1 S=192.168.1.2 LEN=84, ID=48009, TOS=0x0, TTL=255
sys12 -> sys11 ICMP Echo request (ID: 345 Sequence number: 0)
...
sys11 -> sys12 ETHER Type=0800 (IP), size = 98 bytes
sys11 -> sys12 IP D=192.168.1.2 S=192.168.1.1 LEN=84, ID=45375, TOS=0x0, TTL=255
sys11 -> sys12 ICMP Echo reply (ID: 345 Sequence number: 0)
#

Describing Ethernet Interfaces 3-15

To capture this information to a file, type the following command:

# snoop -d hme0 -o /tmp/snooper 192.168.1.2
Using device /dev/hme (promiscuous mode)
2 <Control>-C
#
To capture broadcast traffic on the hme0 interface and store it in the
/tmp/snooper file, type the following command:
# snoop -d qfe0 -o /tmp/snooper broadcast
#

While the snoop utility is capturing information, a record counter

displays the number of recorded packets. You finish the capture by typing
a Control+C key sequence. The information in the file that is captured by
the snoop utility is in a data-compressed format, and can only be read by
executing the snoop -i command.
# file /tmp/snooper
/tmp/snooper: snoop capture file - version 2
#

To read this format, type the following command:

# snoop -i /tmp/snooper -V
...
1 0.00000 sys12 -> sys11 ETHER Type=0800 (IP), size = 98 bytes
1 0.00000 sys12 -> sys11 IP D=192.168.1.1 S=192.168.1.2 LEN=84, ID=48010, TOS=0x0, TTL=255
1 0.00000 sys12 -> sys11 ICMP Echo request (ID: 346 Sequence number: 0)
...
2 0.00010 sys11 -> sys12 ETHER Type=0800 (IP), size = 98 bytes
2 0.00010 sys11 -> sys12 IP D=192.168.1.2 S=192.168.1.1 LEN=84, ID=45376, TOS=0x0, TTL=255
2 0.00010 sys11 -> sys12 ICMP Echo reply (ID: 346 Sequence number: 0)
#

To filter out specific protocols or portions of the network trace, pipe the
output from the snoop -i command through the egrep command.

For example, the egrep -iv 'nfs|ack|contin|ftp|ip' command

ignores case (-i) and prints all lines except (-v) lines that contain the
patterns nfs, ack, contin, ftp, and ip.
# snoop -i /tmp/snooper -V | egrep -iv 'nfs|ack|contin|ftp|ip'
...
1 0.00000 sys12 -> sys11 ICMP Echo request (ID: 346 Sequence number: 0)
...
2 0.00010 sys11 -> sys12 ICMP Echo reply (ID: 346 Sequence number: 0)
#

3-16 Network Administration for the Solaris™ 10 Operating System

Using the netstat Command

The netstat command includes many options and is useful as a network
troubleshooting tool.

To display the current usage of the Ethernet interfaces, use the netstat
command with the -i option:
# netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 83505 0 83505 0 0 0
hme0 1500 sys11 sys11 21775 0 53541 0 0 0
#

Table 3-3 shows the descriptions of the output fields from the netstat
command.

Table 3-3 The netstat Output Field Descriptions

Field Description

Name The name of the device (interface).

Mtu The MTU in bytes.
Net/Dest The network number. The number can be resolved to a
name in the /etc/inet/networks file.
Address The IP address for that interface. The address can be
resolved to a name in the /etc/inet/hosts file.
Ipkts Input packets.
Ierrs Input errors.
Opkts Output packets.
Oerrs Output errors.
Collis The number of collisions on this interface.
Queue The number of packets that are waiting for
transmission.

Describing Ethernet Interfaces 3-17

To display protocol-related statistics, use the netstat command with the

-s option:
# netstat -s
<truncated output>
RAWIP
rawipInDatagrams = 298 rawipInErrors = 0
...
UDP
udpInDatagrams = 45966 udpInErrors = 0
...
TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400
...
IPv4 ipForwarding = 1 ipDefaultTTL = 255
...
IPv6 ipv6Forwarding = 2 ipv6DefaultHopLimit = 255
...
ICMPv4 icmpInMsgs = 3719 icmpInErrors = 0
...
ICMPv6 icmp6InMsgs = 0 icmp6InErrors = 0
...
IGMP:
123079 messages received
...
#

Using the ndd Command

You use the ndd command to examine and set many parameters
associated with networking.

To list the parameters for the hme driver, perform the command:
# ndd /dev/hme \?
? (read only)
transceiver_inuse (read only)
link_status (read only)
link_speed (read only)
link_mode (read only)
ipg1 (read and write)
...
...
...
instance (read and write)
lance_mode (read and write)
ipg0 (read and write)
#

3-18 Network Administration for the Solaris™ 10 Operating System

The \ character prevents the shell from interpreting ? as a special

character. Using the ? parameter lists all parameters for the driver and
indicates whether the parameter is read-only or read and write. You can
read the current parameter value or status information for the parameters
that are marked with at least a read; however, you may only change a
value if it is marked as read and write.

You can adjust most parameters accessible through the ndd command
without rebooting the system.

The following example shows how to use the ndd command to examine
the value of the link_speed parameter for the hme0 interface. Because
multiple hme interfaces might exist, use the ndd command to set the
instance parameter first. The instance parameter determines which
hme interface is addressed by subsequent ndd commands.

To set the instance to 0, use the following command:

# ndd -set /dev/hme instance 0
#

To view the current link speed of the hme0 interface, type the command:
# ndd /dev/hme link_speed
1
#

The output of 1 indicates that the hme0 interface is currently running at

100 Mbps, and a value of 0 indicates that the hme0 interface is running at
10 Mbps. The ndd parameters are also available for other network devices
and protocols. For example, to see which parameters are available for
other drivers, type the commands:
# ndd /dev/arp \?
# ndd /dev/ip \?
# ndd /dev/icmp \?
# ndd /dev/tcp \?

Sun Microsystems does not currently provide extensive ndd parameter

documentation, except for network card configuration.

Describing Ethernet Interfaces 3-19

There are several trade-offs involved in setting driver parameters. Because

the Solaris 10 OS is preconfigured, changing most driver parameters
requires you to change the Solaris 10 OS configuration. The default
settings are suitable for most situations. Sun Microsystems does not
encourage making parameter changes, because adjusting parameters can
affect normal system operation. Sun might also change the names of
parameters in future versions of the Solaris OS.

You can set device driver parameters in two ways: by using the ndd
command or by creating a Service Management Facility (SMF) service.
● Use the ndd command to set parameters that are valid until you
reboot the system. A good way to test parameter settings is by using
the ndd command on the command line.
● You can also create an SMF service.

Note – Information about setting ndd parameters in system startup

scripts can be found in Chapter 4 of the Solaris Tunable Parameters Reference
Manual located at the Uniform Resource Locator (URL)
http://docs.sun.com.

3-20 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Ethernet Interfaces

Exercise: Reviewing Ethernet Interfaces

In this exercise, you review many Ethernet concepts.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Tasks
Perform the following steps:
1. Match the terms to their definition.

_____ MTU a. A general term that describes the unit

of data sent across a packet-switching
network
_____ Unicast b. The process of passing data from layer
to layer in the protocol stack and
adding header information to the data
at each layer
_____ Preamble c. The field in the Ethernet frame that
describes the type of data being
carried in the frame
_____ Encapsulation d. An address format that reaches a
specific host
_____ Packet e. The field in an Ethernet frame used for
synchronization purposes
_____ Frame f. The maximum number of bytes that
are contained in the payload section in
a Network Interface layer frame
_____ Type field g. The unit of data sent from the
Ethernet interface to the Hardware
layer

Describing Ethernet Interfaces 3-21

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Ethernet Interfaces

2. Open a terminal window, and type the command:

# man snoop
Look at the various modes and options for capturing and viewing
frames available to you.
a. Which snoop option displays the size of the entire Ethernet
frame in bytes on the summary line?
________________________________________________________
b. Which snoop option captures packets to a file instead of to
standard output?
________________________________________________________
c. Which snoop option displays the most verbose output?
________________________________________________________
d. Which snoop option displays frames arriving on a non-primary
interface?
________________________________________________________
3. Open another terminal window, and execute the netstat command
to determine the name of your Ethernet interface. What are the
names of the Ethernet interfaces on your system, and what are their
purposes?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
4. In one terminal window, execute the snoop utility on the default
interface to capture only broadcast frames. Let this command run for
the next step.
5. Using another terminal window, log in to another host on your
subnet, and type the rup command.
a. Does the rup command send broadcast frames?
________________________________________________________
b. Do you see the replies to the rup command? Why?
________________________________________________________

3-22 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Ethernet Interfaces

Now you use different options of the snoop utility to provide different
amounts of output.
6. Stop the snoop utility that is currently running, and restart the snoop
utility in verbose mode. Capture only broadcast frames.
Write the command that you use:
_____________________________________________________________
7. In the terminal window logged in to the remote host, execute the rup
command again. Observe the format of the output from the snoop
utility running in verbose mode.
8. Stop the snoop utility, and execute the snoop utility in verbose
summary mode, capturing only broadcast frames.
Write the command that you use:
_____________________________________________________________
9. In the terminal window that is logged in to the remote host, execute
the rup command again. How do the two formats differ?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
10. Log off of the remote host, and quit all instances of the snoop utility
that you are running.

Note – While you might not understand everything that you see in this
section of the exercise, you should at least become familiar with the
command syntax, options, and output format of the ndd command. The
results of the exercise vary, depending on the type of network interface in
the system.

Describing Ethernet Interfaces 3-23

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Ethernet Interfaces

In this part of the exercise, you manipulate a specific interface on your

system.
11. Use the appropriate argument with the ndd command to make sure
that any instance information retrieved is for the primary network
interface.
Write the command that you use:
_____________________________________________________________
12. Use the ndd command to determine the value of the link_status
parameter of the primary network interface on your system. A status
of 0 indicates that the interface is down. A status of 1 indicates that
the interface is up.
Write the command that you use:
_____________________________________________________________
13. What command do you use to make the ndd command set your
system’s link_status parameter to 0?
_____________________________________________________________
14. Use the ndd command to determine the read and write attributes of
ndd parameters for your interface driver. For example, if your
system’s interface is an hme0 interface, use /dev/hme as the
parameter.
Write the command that you use:
_____________________________________________________________
Do you expect your command from Step 13 to work if you entered it
at the command line as the root user? Why?
________________________________________________________

3-24 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss the experiences, issues, or

discoveries that you had during the lab exercises.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Describing Ethernet Interfaces 3-25

Exercise Solutions
Solutions to the exercise are as follows:
1. Match the terms to their definition.

f MTU a. A general term that describes the unit

of data sent across a packet-switching
network
d Unicast b. The process of passing data from layer
to layer in the protocol stack and
adding header information to the data
at each layer
e Preamble c. The field in the Ethernet frame that
describes the type of data being
carried in the frame
b Encapsulation d. An address format that reaches a
specific host
a Packet e. The field in an Ethernet frame used for
synchronization purposes
g Frame f. The maximum number of bytes that
are contained in the payload section in
a Network Interface layer frame
c Type field g. The unit of data sent from the
Ethernet interface to the Hardware
layer

2. Open a terminal window, and type the command:

3-26 Network Administration for the Solaris™ 10 Operating System

c. Which snoop option displays the most verbose output?

-v
d. Which snoop option displays frames arriving on a non-primary
interface?
-d interface name
3. Open another terminal window, and execute the netstat command
to determine the name of your Ethernet interface. What are the
names of the Ethernet interfaces on your system, and what are their
purposes?
# netstat -i
The hme0 interface, the qfe0 interface, or perhaps the eri0 interface,
depending on your system. The purpose of the network interface is to
provide access to the LAN.
4. In one terminal window, execute the snoop utility on the default
interface to capture only broadcast frames. Let this command run for
the next step.
# snoop broadcast
5. Using another terminal window, log in to another host on your
subnet, and type the rup command.
a. Does the rup command send broadcast frames?
Yes, you will observe the rup utility sending remote status (RSTAT)
requests.
b. Do you see the replies to the rup command? Why?
No status replies are seen because the replies are sent to the host by
using a unicast address.

Now you use different options of the snoop utility to provide different
amounts of output.
6. Stop the snoop utility that is currently running, and restart the snoop
utility in the verbose mode. Capture only the broadcast frames.
# snoop -v broadcast
7. In the terminal window logged in to the remote host, execute the rup
command again. Observe the format of the output from the snoop
utility running in the verbose mode.
8. Stop the snoop utility, and execute the snoop utility in verbose
summary mode, capturing only broadcast frames.
# snoop -V broadcast

Describing Ethernet Interfaces 3-27

9. In the terminal window that is logged in to the remote host, execute

the rup command again. How do the two formats differ?
The -v option executes the verbose mode. It prints packet headers in great
detail. This display consumes many lines per packet and should be used
only on selected packets.
The -V option executes the summary verbose mode. This is halfway between
the summary mode and verbose mode in degree of verbosity. It displays a
single summary line for each protocol layer in the packet instead of
displaying multiple lines from each layer of encapsulation.
10. Log off of the remote host, and quit all instances of the snoop utility
that you are running.

In this part of the exercise, you manipulate a specific interface on your

system.
11. Use the appropriate argument of the ndd command to make sure
that any instance information retrieved is for the primary network
interface.
# ndd -set /dev/hme instance 0
12. Use the ndd command to determine the value of the link_status
parameter of the primary network interface on your system. A status
of 0 indicates that the interface is down. A status of 1 indicates that
the interface is up.
# ndd /dev/hme link_status

3-28 Network Administration for the Solaris™ 10 Operating System

13. What command do you use to make the ndd command set your
system’s link_status parameter to 0?
# ndd -set /dev/hme link_status 0
14. Use the ndd command to determine the read and write attributes of
ndd parameters for your interface driver. For example, if your
system’s interface is an hme0 interface, use /dev/hme as the
parameter.
# ndd /dev/device_of_interest \?
Do you expect your command from Step 13 to work if you entered it
at the command line as the root user? Why?
The command would fail because the link_status parameter is read only.

Describing Ethernet Interfaces 3-29

Describing ARP and RARP

Objectives
This module describes the Address Resolution Protocol (ARP) and the
Reverse Address Resolution Protocol (RARP). Additionally, this module
describes the ARP table, the in.rarpd RARP daemon, and the
/etc/inet/hosts and /etc/ethers databases.

Upon completion of this module, you should be able to:

● Describe ARP
● Describe RARP

The course map in Figure 4-1 shows how this module fits into the current
instructional goal.

Configuring the Network Interface Layer

Introducing the Introducing LANs Describing Describing

TCP/IP and Their Ethernet ARP and
Model Components Interfaces RARP

Figure 4-1 Course Map

4-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing ARP

Introducing ARP
ARP is the method used to map a 32-bit IP address to a 48-bit Ethernet
address.

Purpose of ARP
The ARP function occurs between the Internet and Network Interface
layers of the TCP/IP model. Figure 4-2 shows the location of the ARP
function in the model.

TCP/IP Layers

Application Layer

Transport Layer

Internet Layer
ARP
Network Interface Layer

Hardware Layer

Figure 4-2 ARP in the TCP/IP Model

Data is encapsulated into an Ethernet frame before it is transmitted. An

Ethernet frame includes a destination Ethernet address. Figure 4-3 shows
the Ethernet frame.

Destination Source Cyclic

Ethernet Ethernet Type Data Redundancy
Address Address Check

Figure 4-3 Ethernet Frame

When two systems need to communicate, they need each other’s Ethernet
addresses. ARP supplies the destination Ethernet address information if
the sending system does not already know the destination address.

4-2 Network Administration for the Solaris™ 10 Operating System

Operation of ARP
If the final destination (receiving system) of the message being sent is on
the same LAN as the sending system, only one address resolution is
required. If the final destination is on a different network, an address
resolution might be required on each network that the message traverses
on the path to its final destination.

Figure 4-4 shows a simplification of the address resolution process.

192.168.1.1 192.168.1.2 192.168.1.3

sys11 sys12 sys13
Who is 192.168.1.3?
1

192.168.1.3 is 8:00:20:c0:78:73
2

Figure 4-4 Address Resolution Process

For example, assume that the sys11 system must communicate with the
sys13 system:
1. The sys11 system sends an ARP request to the local network by
using the Ethernet broadcast address (ff:ff:ff:ff:ff:ff). The
ARP request includes the IP address of the sys13 system.
2. The broadcast is seen by the sys12 and sys13 systems.
3. The sys12 and sys13 systems recognize that the ARP request
contains the IP address and the Ethernet address of the sys11
system, and add this information to their ARP tables if it is not
already present. This type of entry is known as an unsolicited entry
because the information was not explicitly requested.

Describing ARP and RARP 4-3

4. The sys13 system identifies its own IP address in the ARP request
and sends an ARP reply to the sys11 system. The ARP reply
includes the Ethernet address of the sys13 system, and it is sent
using the unicast Ethernet address of the sys11 system
(8:0:20:b9:72:23).
5. The sys11 system receives the ARP reply and stores the information
about sys13 in its ARP table. This type of entry is a solicited entry
because the sys11 system requested the information.

ARP Table

ARP responses are stored in the ARP table so that the information is
available if it is required again in the near future. The ARP table, held in
memory, stores IP addresses and Ethernet addresses. This table is read
each time a destination Ethernet address is required to prepare an
Ethernet frame for transmission. If an Ethernet address does not appear in
the ARP table, an ARP request is sent to the local network. Other hosts
that see the ARP request also update their ARP table with the IP and
Ethernet addresses of the requesting host.

Use the ndd /dev/ip ip_ire_arp_interval command to display the

length of time that solicited ARP entries are cached. The default value is
1200000. This value is stored in milliseconds and translates to 20 minutes.

Use the ndd /dev/arp arp_cleanup_interval command to display

the length of time that unsolicited ARP entries are cached. The default
value is 300000. This value is stored in millisecond and translates to
5 minutes.

Solicited entries are those for which an Ethernet address was asked
specifically by a host, whereas unsolicited entries are a result of storing
information learned about a host that was performing an ARP request on
the local network.

4-4 Network Administration for the Solaris™ 10 Operating System

ARP Table Management

The arp command displays and controls the ARP table entries that map
IP addresses to Ethernet addresses. Complete entries map an IP address to
an Ethernet address. Incomplete entries contain an IP address only.

For example, to examine all entries in the ARP table type the command:
# arp -a
Net to Media Table: IPv4
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 sys13 255.255.255.255 08:00:20:c0:78:73
hme0 sys11 255.255.255.255 SP 08:00:20:b9:72:23
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
#

The fields displayed in the output from the arp -a command are shown
in Table 4-1.

Table 4-1 ARP Fields

Field Description

Device The network device (network interface) for this entry. This
is the interface connected to the network on which this
system resides.
IP The IP address or host name of the system to which this
Address entry applies.
Mask The host mask value applied. This indicates whether the
entry refers to a host or the multicast address range.
Flags The status of the ARP entry:
● S is a static entry. Static entries do not time out.
● P is a published entry. A system can be configured to
publish (advertise) an ARP entry on behalf of
systems that cannot respond to ARP requests.
● M is a mapped entry. This is used for the 224.0.0.0
multicast entry only.
● U is an unresolved or incomplete entry.
Phys Addr The physical address for the entry, also known as the MAC
or the Ethernet address.

Describing ARP and RARP 4-5

To examine a specific ARP table entry, type the command:

# arp hostname

where hostname is the name of the host or its decimal-dot notated IP

address. For example:
# arp sys13
sys13 (192.168.1.3) at 8:0:20:c0:78:73
#

Information about any flags is also displayed. For example:

# arp sys11
sys11 (192.168.1.1) at 8:0:20:b9:72:23 permanent published
#

The keyword permanent relates to the S flag. The keyword published

refers to the P flag.

To add a static (until reboot) ARP table entry, type the command:
# arp -s hostname ethernet_address

The preceding command overrides the default time-to-live (TTL) value for
ARP table entries by creating a static entry. For example, to add a host’s
Ethernet address manually to the ARP table, type the command:
# arp -s 192.168.1.99 1:2:3:4:5:6

Use the arp and grep commands to search for the new table entry:
# arp -a | grep 99
hme0 192.168.1.99 255.255.255.255 S 01:02:03:04:05:06
#

Populate an ARP table manually in situations in which the destination

device cannot respond to ARP requests, such as a system which is reached
through a modem connection.

Use a published ARP entry when you want a host to answer an ARP
request on behalf of another host. This is a useful option for
heterogeneous environments and for some SLIP or PPP configurations in
which some hosts cannot respond to ARP requests for themselves.

To add a published ARP table entry, execute the command:

# arp -s hostname ethernet_address pub

4-6 Network Administration for the Solaris™ 10 Operating System

To add ARP table entries from a file, execute the command:

# arp -f filename

Entries in the file can be in the following form:

hostname ethernet_address [pub]

To delete an ARP table entry, execute the command:

# arp -d hostname

where hostname is the name of the host or its decimal-dot notated IP

address.

For example, to remove the static entry that was added, type the
command:
# arp -d 192.168.1.99
192.168.1.99 (192.168.1.99) deleted
#

To view the network traffic generated by an ARP request, use the snoop
utility:
# snoop -v -d hme0 arp

In a second window, use the ping utility to contact another system on the
network that is not listed currently in the system’s ARP table:
# ping sys12
sys12 is alive
#

Observe the output from the snoop utility:

Using device /dev/hme (promiscuous mode)
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 13:47:30.00038
ETHER: Packet size = 42 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 8:0:20:b9:72:23, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1

Describing ARP and RARP 4-7

ARP: Protocol type = 0800 (IP)

ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender’s hardware address = 8:0:20:b9:72:23
ARP: Sender’s protocol address = 192.168.1.1, sys11
ARP: Target hardware address = ?
ARP: Target protocol address = 192.168.1.2, sys12
ARP:

ETHER: ----- Ether Header -----

ETHER:
ETHER: Packet 2 arrived at 13:47:30.00038
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:b9:72:23, Sun
ETHER: Source = 8:0:20:90:b5:c7, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 2 (ARP Reply)
ARP: Sender’s hardware address = 8:0:20:90:b5:c7
ARP: Sender’s protocol address = 192.168.1.2, sys12
ARP: Target hardware address = 8:0:20:b9:72:23
ARP: Target protocol address = 192.168.1.1, sys11
ARP:

<Control>-C#

4-8 Network Administration for the Solaris™ 10 Operating System

Introducing RARP
RARP is the method used to map a 48-bit Ethernet address to a 32-bit IP
address.

Purpose of RARP
RARP is one of the protocols that a system can use when it needs to
determine its IP address.

Diskless clients and JumpStart™ software clients depend upon another

host or server from which to retrieve a network boot file. Each network
boot file has a name that is based on the IP address of each client. To
request the correct network boot file, each client uses RARP to obtain its
IP address at boot time.

Operation of RARP
A system sends a RARP request to the Ethernet broadcast address when
the system is booting and does not have any way to determine what its IP
address will be without requesting the information over the network. Any
system on the subnet running the RARP server daemon (in.rarpd), and
that also has appropriately configured files or network naming service
information, responds with the booting system’s IP address.

RARP operations include a request and a reply. The RARP request is

reported as a REVARP request by the snoop utility. For example:
# snoop -v -d hme0 rarp
Using device /dev/hme (promiscuous mode)
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 12:52:11.00053
ETHER: Packet size = 64 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 8:0:20:90:b5:c7, Sun
ETHER: Ethertype = 8035 (RARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)

Describing ARP and RARP 4-9

ARP: Length of hardware address = 6 bytes

ARP: Length of protocol address = 4 bytes
ARP: Opcode 3 (REVARP Request)
ARP: Sender’s hardware address = 8:0:20:90:b5:c7
ARP: Sender’s protocol address = 0.0.0.0, OLD-BROADCAST
ARP: Target hardware address = 8:0:20:90:b5:c7
ARP: Target protocol address = ?
ARP:

<Control>-C#

The RARP reply is reported as a REVARP reply by the snoop utility. For
example:
# snoop -v -d hme0 rarp
Using device /dev/hme (promiscuous mode)
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 12:52:19.00053
ETHER: Packet size = 42 bytes
ETHER: Destination = 8:0:20:90:b5:c7, Sun
ETHER: Source = 8:0:20:b9:72:23, Sun
ETHER: Ethertype = 8035 (RARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 4 (REVARP Reply)
ARP: Sender’s hardware address = 8:0:20:b9:72:23
ARP: Sender’s protocol address = 192.168.1.1, sys11
ARP: Target hardware address = 8:0:20:90:b5:c7
ARP: Target protocol address = 192.168.1.2, sys12
ARP:

<Control>-C#

By default, the OpenBoot™ PROM is configured to use RARP as the

network boot strategy. To force a system to perform a RARP boot, type the
command:
ok boot net:rarp

4-10 Network Administration for the Solaris™ 10 Operating System

The in.rarpd RARP Daemon

The in.rarpd RARP daemon must be running (as the root user) on
systems that provide RARP responses to requests. The
svc:/network/rarp SMF service enables the in.rarpd RARP daemon.

Note – Before the Solaris 10 OS, the in.rarpd RARP daemon was started
by the /etc/rc3.d/S16boot.server start script if either the /tftpboot
directory or the /rplboot directory existed. Before the Solaris 9 OS, the
in.rarpd RARP daemon was started by the /etc/rc3.d/
S15nfs.server start script.

The /etc/ethers and the /etc/inet/hosts Databases

The /etc/ethers and the /etc/inet/hosts files (or the corresponding

network-naming service databases) support the Ethernet address-to-IP
address relationship, which is needed to respond to RARP requests.

The /etc/ethers file contains the Ethernet address and corresponding

host name for a system. View the /etc/ethers file with any text viewer,
for example:
# cat /etc/ethers
8:0:20:c0:78:73 sys13
8:0:20:90:b5:c7 sys12
#

Note – Usually, the /etc/ethers file is created on boot servers only.

The in.rarpd daemon queries the /etc/ethers file (or corresponding

network-naming service database) for the host name of the system that is
performing the RARP request. The host name is resolved to an IP address
by using the /etc/inet/hosts file (or corresponding network-naming
service database) on the server. The resulting IP address is returned to the
system that made the RARP request. Whether the boot server uses the
local /etc/ethers and /etc/inet/hosts files or the corresponding
naming service database, is specified in the /etc/nsswitch.conf file.

Describing ARP and RARP 4-11

Exercise: Reviewing ARPs and RARPs

In this exercise, you become more familiar with the ARP table and the arp
command. You force systems to perform ARP requests, and you view the
ARP transactions with the snoop utility.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Be sure to write, in the space provided, any commands that you use
during the exercise so that you can use this exercise as a reference after
you have completed this course.

Work with other students to make sure that you all can see the expected
results in the next part of this exercise.

4-12 Network Administration for the Solaris™ 10 Operating System

Tasks
Perform the following steps:
1. In a terminal window, display the current contents of the ARP table
on your host.
_____________________________________________________________
Explain why the table contents contain the entries reported by the
arp command.
_____________________________________________________________
_____________________________________________________________

To communicate with another host, the system must first learn the
Ethernet address of that host.
2. Issue the ping command to a host in your local network that is not
currently in your ARP table.
_____________________________________________________________
3. Examine the ARP table again. Observe the new ARP entry for the
host with which your system just communicated.
_____________________________________________________________
4. Use the arp command to delete all host entries except for the
multicast entry (224.0.0.x) and your host’s own entries.
_____________________________________________________________
5. In another window, start the snoop utility in verbose summary mode
to filter out all but the broadcast frames.
_____________________________________________________________
6. Open a terminal on your local host, and check the contents of your
ARP table for another host in your subnet that is not currently listed.
____________________________________________________________
7. Use the ping command to communicate with a host that is not in
your system’s ARP table.
____________________________________________________________
8. Examine the output from the snoop utility.
Why did you receive this result?
____________________________________________________________
____________________________________________________________

Describing ARP and RARP 4-13

9. Stop the snoop utility.

____________________________________________________________
10. Start the snoop utility in verbose summary mode to filter out all but
the ARP frames.
____________________________________________________________
11. Delete the ARP table entry for the host that you previously used.
____________________________________________________________
12. Use the ping command, and attempt to contact the host again.
____________________________________________________________
13. Examine the output from the snoop utility.
a. Did you see the ARP request?
_______________________________________________________
b. Why?
_______________________________________________________
c. Did you see the ARP response?
_______________________________________________________
d. Why?
_______________________________________________________
_______________________________________________________
_______________________________________________________
14. Use the ping command, and attempt to contact the host again.
____________________________________________________________
15. Examine the output from the snoop utility.
a. Did you see the ARP request?
_______________________________________________________
b. Why?
_______________________________________________________
_______________________________________________________
_______________________________________________________
16. Quit the snoop utility.
____________________________________________________________

4-14 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Describing ARP and RARP 4-15

Exercise Solutions
Solutions to the exercise are as follows:
1. In a terminal window, display the current contents of the ARP table
on your host.
# arp -a
Net to Media Table: IPv4
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 sys13 255.255.255.255 08:00:20:c0:78:73
hme0 sys11 255.255.255.255 SP 08:00:20:b9:72:23
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
#
Explain why the table contents contain the entries reported by the
arp command.
If the system has previously contacted another system on the LAN, an entry
is present. Locally configured interfaces have their own static, published
entries and multicast entries by default. Unsolicited entries generated by
ARP requests from other hosts might also be present.

To communicate with another host, the system must first learn the
Ethernet address of that host.
2. Issue the ping command to a host in your local network that is not
currently in your ARP table.
# ping sys12
sys12 is alive
#
3. Examine the ARP table again. Observe the new ARP entry for the
host with which your system just communicated.
# arp -a
Net to Media Table: IPv4
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 sys13 255.255.255.255 08:00:20:c0:78:73
hme0 sys12 255.255.255.255 08:00:20:90:b5:c7
hme0 sys11 255.255.255.255 SP 08:00:20:b9:72:23
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
#

4-16 Network Administration for the Solaris™ 10 Operating System

4. Use the arp command to delete all host entries except for the
multicast entry (224.0.0.x) and your host’s own entries.
# arp -d sys12
sys12 (192.168.1.2) deleted
# arp -d sys13
sys13 (192.168.1.3) deleted
#
5. In another window, start the snoop utility in verbose summary mode
to filter out all but the broadcast frames.
# snoop -V broadcast
Using device /dev/hme (promiscuous mode)
6. Open a terminal on your local host, and check the contents of your
ARP table for another host in your subnet that is not currently listed.
# arp -a

Net to Media Table: IPv4

Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 sys11 255.255.255.255 SP 08:00:20:b9:72:23
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
#
7. Use the ping command to communicate with a host that is not in
your system’s ARP table.
# ping sys12
sys12 is alive
#
8. Examine the output from the snoop utility.
Why did you receive this result?
The following is observed in the terminal running the snoop utility:
________________________________
sys11 -> (broadcast) ETHER Type=0806 (ARP), size = 42 bytes
sys11 -> (broadcast) ARP C Who is 192.168.1.2, sys12 ?
An address resolution was required because the host did not have the
destination host address information in its ARP table.
The snoop utility is filtering on broadcasts, resulting in the broadcast
requests that are observed in the snoop utility’s output. Recall that ARP
replies are unicasts, which explains why the ARP reply and the ICMP
traffic were not observed.

Describing ARP and RARP 4-17

9. Stop the snoop utility.

Press the Control+C key sequence to stop the snoop utility.
Control-C#
10. Start the snoop utility in verbose summary mode to filter out all but
the ARP frames.
# snoop -V arp
Using device /dev/hme (promiscuous mode)
11. Delete the ARP table entry for the host that you previously used.
# arp -d sys12
sys12 (192.168.1.2) deleted
#
12. Use the ping command, and attempt to contact the host again.
# ping sys12
sys12 is alive
#
13. Examine the output from the snoop utility.
________________________________
sys11 -> (broadcast) ETHER Type=0806 (ARP), size = 42 bytes
sys11 -> (broadcast) ARP C Who is 192.168.1.2, sys12 ?
________________________________
sys13 -> sys11 ETHER Type=0806 (ARP), size = 60 bytes
sys13 -> sys11 ARP R 192.168.1.2, sys12 is 8:0:20:90:b5:c7
a. Did you see the ARP request?
Yes.
b. Why?
The snoop utility is filtering out all but the ARP packets.
c. Did you see the ARP response?
Yes.
d. Why?
The snoop utility is filtering out all but ARP packets. The ARP
responses are unicast but are still ARP packets.
14. Use the ping command, and attempt to contact the host again.
# ping sys12
sys12 is alive
#

4-18 Network Administration for the Solaris™ 10 Operating System

15. Examine the output from the snoop utility.

No output is seen from the snoop utility.
a. Did you see the ARP request?
No.
b. Why?
The system resolved the destination Ethernet address by using its local
ARP table; therefore, an ARP request was unnecessary. The snoop
utility filters out all but ARP packets, which explains why you did not
see any ARP traffic resulting from the ping command.
16. Quit the snoop utility.
Press the Control+C key sequence.
Control-C#

Describing ARP and RARP 4-19

Configuring IP

Objectives
This module describes the features of IP, including the purpose of IP, the
IP datagram, and IP address types. This module also describes subnetting
and the variable length subnet mask (VLSM). Additionally, this module
explains the purpose of interface configuration files and describes how to
configure logical interfaces.

Upon completion of this module, you should be able to:

● Describe the Internet layer protocols
● Describe the IP datagram
● Describe the IP address types
● Describe subnetting and VLSMs
● Describe the interface configuration files
● Administer logical interfaces

5-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Objectives

The course map in Figure 5-1 shows how this module fits into the current
instructional goal.

Configuring the Network

Configuring IP
Configuring Network Configuring
IP Routing
Multipathing

Describing
Configuring the Transport
IPv6
Layer

Figure 5-1 Course Map

5-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Internet Layer Protocols

Introducing the Internet Layer Protocols

IP is implemented at the Internet layer and is documented in RFC 791.

Purpose of IP
IP is provided by a loadable kernel module and has two main functions.
IP provides:
● Connectionless delivery of datagrams on the network
● Fragmentation and reassembly of data to accommodate data links
that implement different sizes of MTUs

A companion protocol for IP, ICMP, enables systems to send control or

error messages to other systems. These messages provide a
communication mechanism between the IP layer on one system and the
IP layer on another system. Message types that are sent include echo
request, echo reply, destination unreachable, router advertisement,
redirect, router solicitation, and time exceeded.

Application data must fit in the data portion of an Ethernet frame. The
upper limit on the amount of data in the Ethernet frame is defined by the
MTU of the Network Interface layer. If the amount of application data is
larger than the MTU, fragments are created as units of data that are
broken into smaller units for transmission. Internet Protocol version 4
(IPv4) specifies that fragmentation occur at each router, based on the MTU
of the interface through which the IP datagrams must pass.

To view the MTU of an interface, type the ifconfig -a command:

# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Configuring IP 5-3
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Internet Layer Protocols

Purpose of ICMP
ICMP enables IP on one system to send control and error messages to IP
on other systems. This communication can include a control message,
such as a routing redirect, or an error message, such as Network is
unreachable. Network administrators and system utilities, such as the
traceroute command, use this error messaging feature as a diagnostic
tool.

ICMP Message Types

Some common ICMP message types include:

● Echo request and reply
● Destination unreachable
● Router advertisement
● Router solicitation
● Redirect
● Time exceeded

Note – To obtain supported ICMP message type information, view the

/usr/include/netinet/ip_icmp.h file.

ICMP messages are defined in RFC 792. The ICMP header appears after
the IP header and varies depending on the type of ICMP message. For
example, Figure 5-2 shows an ICMP header when the destination is
unreachable.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Code Checksum

Unused

Figure 5-2 ICMP Destination Unreachable Header Template Format

5-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Internet Layer Protocols

Figure 5-3 shows an ICMP header for a redirect message.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Code Checksum

Gateway Internet Address

Figure 5-3 ICMP Redirect Message Header Template Format

Figure 5-4 shows an ICMP header for an echo request or echo reply
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Code Checksum

Identifier Sequence Number

Figure 5-4 ICMP Echo Request or Echo Reply Message Header

Template Format

Configuring IP 5-5
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the IP Datagram

Introducing the IP Datagram

IP datagrams are the basic units of information that are passed across a
TCP/IP network. The datagram header contains information, such as the
source IP address and the destination IP address. The header also contains
information about which protocol will receive data from IP. These
protocols are UDP, TCP, and ICMP. The TTL field determines how many
routers or hosts can process a datagram before the datagram must be
discarded.

IP Datagram Header Fields

Figure 5-5 shows the IPv4 datagram header fields.

4 Bits
4 Bits
Versio
4 Bits
n Heade 4 Bits
Lengt r Type
4 Bits
h
Servicof
4 Bits
e 4 Bits
Datag Datag
4 Bits
ram Id ram L
entifie ength
r
Time t Flags
o Live
Fragm
Protoc ent Of
ol fset
Check
sum
Sourc
e IP A
ddres
s
Destin
ation I
P Add
ress
IP Op
tions a
nd Pa
dding
If Req
uired

Figure 5-5 IPv4 Datagram Header Fields

5-6 Network Administration for the Solaris™ 10 Operating System

The fields in the datagram header are described in Table 5-1.

Table 5-1 IP Datagram Header Fields

Field Description

Version The version of the protocol, for example 4

(IPv4).
Header length The length of a datagram header. This value
must be at least 20 bytes
Type of service The specified quality of service.
Datagram length The length of the entire datagram, measured in
bytes.
Datagram The value assigned by the sender to make
identifier reassembly of fragments possible for the
receiving system.
Flags Information related to fragmentation. These
flags define whether the datagram can be
fragmented and whether the datagram is part
of a message that was fragmented.
Fragment offset The location of the fragment in the overall set of
application data.
Time to live The maximum number of routers through
which the datagram can pass.
Protocol The Transport layer protocol to which the data
in this datagram is delivered.
Checksum The header checksum used to verify that the
header is not damaged.
Source IP address The source system’s IPv4 address.
Destination IP The destination system’s IPv4 address.
address
IP options and Optional information and padding, if required.
padding

Refer to RFC 791 for detailed information about the header fields.

Configuring IP 5-7
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the IP Datagram

IP Datagram Payload
The IP datagram payload can contain any one of the following: a UDP
datagram, a TCP segment, an ICMP message, or an Internet Group
Management Protocol (IGMP) message.

5-8 Network Administration for the Solaris™ 10 Operating System

Introducing IP Address Types

IPv4 addresses are 32 bits in length. They are normally represented as
four dot-separated, 8-bit fields, or octets, each represented by a decimal
number between 0–255 (for example, 129.150.182.31).

Each IPv4 address identifies a network and a unique interface on that

network.

Unicast Addresses
Unicast addresses identify a single interface on a network. Unicast
addresses are used when a system needs to communicate with another
system. There are three classes of unicast addresses: Class A, Class B, and
Class C. The value of the high-order bits (first three bits) determines which
portion of the IPv4 address is the network number and which portion is
the host number. This addressing scheme is called classful IPv4 addressing.

Class A Addresses

Class A addresses are for very large networks and provide 16,777,214 host
addresses. Figure 5-6 shows the beginning of the address in binary format.

1 - 127 Example: 10.102.2.113

Figure 5-6 Class A Unicast Addresses

If the first bit is 0, that bit and the next seven bits define the network
number, and the remaining 24 bits define the host number. This makes
possible up to 128 Class A networks.

The Internet Assigned Numbers Authority (IANA) has reserved the

Class A network 10.0.0.0 –10.255.255.255 for private networks. These
addresses are not routed in the Internet. Refer to RFC 1918 for additional
details. In addition, the 127.0.0.0 address range cannot be used because
127.0.0.1 is reserved for the loopback interface.

Configuring IP 5-9
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing IP Address Types

Class B Addresses

Class B addresses are for large networks and provide 65,534 host
addresses. Figure 5-7 shows the beginning of the address in binary format.

128 - 191 0 - 255 Example: 129.150.254.2

Figure 5-7 Class B Unicast Addresses

If the first two bits are 10, those two bits and the next 14 bits define the
network number, and the remaining 16 bits define the host number. This
makes possible 16,384 Class B networks. The IANA has reserved the
Class B networks 172.16.0.0–172.31.255.255 for private networks.
These addresses are not routed in the Internet. Refer to RFC 1918 for
additional details.

Class C Addresses

Class C addresses are for small-sized and medium-sized networks and

provide 254 host addresses. Figure 5-8 shows the beginning of the address
in binary format.

110

192 - 223 0 - 255 0 - 255 Example: 192.9.227.13

Figure 5-8 Class C Unicast Addresses

If the first three bits are 110, those three and the next 21 bits define the
network number, and the remaining eight bits define the host number.
This makes possible up to 2,097,152 Class C networks. The IANA has
reserved the Class C networks 192.168.0.0–192.168.255.255 for
private networks. These addresses are not routed in the Internet. Refer to
RFC 1918 for additional details.

5-10 Network Administration for the Solaris™ 10 Operating System

Broadcast Addresses
A broadcast address is the address that reaches all systems on a particular
network. A broadcast means that data is sent to all of the hosts on the
LAN. In the Solaris 10 OS, the default broadcast address is an address that
has a host number of all ones when represented in binary. An example of
a broadcast address is 192.168.1.255. You use the ifconfig command
to configure an interface’s broadcast address.

Multicast Addresses
Multicasting is a very efficient way to send large amounts of data to many
systems at the same time. A multicast address identifies interfaces that
belong to a specific multicast group. Packets that are sent to a multicast
address are received by all interfaces that are associated with the multicast
address. Figure 5-9 shows the beginning of a multicast address in binary
format.

1110

224 - 239 0 - 255 0 - 255 0 - 255

Example: 224.0.1.8

Figure 5-9 Multicasting

If the first four bits are 1110, which makes the first field an integer value
between 224 and 239, the address is a multicast address. The remaining
28 bits comprise a group identification number for a specific multicast
group. An IPv4 multicast address is a destination address for one or more
hosts, while a Class A, B, or C address is an address for an individual
host. The IPv4 multicast address maps to an Ethernet multicast address so
that the network interface listens for a multicast traffic. The low-order
23 bits of the IPv4 multicast address are placed into the low-order 23 bits
of the Ethernet multicast address. Therefore, an IPv4 multicast address of
224.0.0.1 maps to 01:00:5e:00:00:01.

Configuring IP 5-11
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Subnetting and VLSM

Introducing Subnetting and VLSM

The Internet is composed of many routers that interconnect different
networks. Each router interface must be on a unique network and must
have a unique address. Assigning different IP addresses to different
networks is required because of the IP addressing scheme required by
routers. Subnetting and VLSMs are two ways of dividing an assigned
network address into multiple, smaller networks for use within an
organization. These smaller networks are referred to as subnetworks, or
subnets.

Subnetting
You can divide a network into subnets to do the following:
● Isolate network traffic within local subnets, therefore reducing
contention for network bandwidth
● Secure or limit access to a subnet
● Enable localization of specific network protocols to a subnet
● Permit the association of a subnet with a specific geography or a
department
● Enable administrative work to be broken into logical units

Figure 5-10 shows the basic idea of subnetting, which is to divide the
standard host number field into two parts: the subnet number and the
host number on that subnet.
Two-level Hierarchy

Network Number Host Number

Three-level Hierarchy

Network Number Subnet Number Host Number

Figure 5-10 Subnetting

5-12 Network Administration for the Solaris™ 10 Operating System

Netmasks
An IP address contains both the network on which the Solaris OS is
located and the host number on the network assigned to that system. In a
subnet environment, you need to be able to determine how much of the IP
address represents the network and how much of the IP address
represents the host number. The netmask is the mechanism by which this is
determined.

Each IP address has a netmask associated with it. A netmask is 32 bits in

length. Each bit in the netmask is used to state whether the corresponding
bit in the IP address forms part of the network number or the host
number. The bit values are associated with either the network number or
the host number as follows:

1 The corresponding bit in the IP address is part of the network

number.
0 The corresponding bit in the IP address is part of the host number.

Netmasks are written by using the same decimal dot-separated notation

that is used for IP addresses. For example, a netmask which has the first
sixteen bits set to 1 and the last sixteen bits set to 0 is written:
255.255.0.0

A netmask which has the first twenty bits set to 1 and the last twelve bits
set to 0 is written:
255.255.240.0

There are standard netmasks for the three classes of unicast address. The
netmask for a Class A network is 255.0.0.0. The netmask for a Class B
network is 255.255.0.0. The netmask for a Class C network is
255.255.255.0.

Configuring IP 5-13
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Subnetting and VLSM

For example, consider the Class B network 172.16.0.0. The default

netmask for this network is 255.255.0.0, and the broadcast address is
172.16.255.255. This gives a single network of 65,534 hosts. By using a
different netmask, it is possible to divide this single network in to more,
smaller networks.

If you choose to divide this single network into, for example, eight smaller
networks, you can do so by changing the netmask. To do this, you first
need to know what power of 2 the number 8 is. (Netmasks always create
a total number of networks that is a power of 2.) The power of 2 value
determines how many extra 1s are required in the netmask.

Because the number 8 is the number 2 to the power 3, to create 8 separate

networks you need three additional 1s in the netmask. The default
netmask value (in binary) is:
11111111 11111111 00000000 00000000

The additional 1s are placed in the netmask next to the existing 1s to give:
11111111 11111111 11100000 00000000

Written in decimal format, this is 255.255.224.0.

This netmask creates eight new, smaller networks, each with 8190 hosts.
The network numbers and broadcast addresses of the eight new networks
are listed in Table 5-2.

Table 5-2 Netmask Network Addresses

Network Number Broadcast Address

172.16.0.0 172.16.31.255
172.16.32.0 172.16.63.255
172.16.64.0 172.16.95.255
172.16.96.0 172.16.127.255
172.168.128.0 172.16.159.255
172.168.160.0 172.16.191.255
172.168.192.0 172.16.223.255
172.168.224.0 172.16.255.255

5-14 Network Administration for the Solaris™ 10 Operating System

Contiguous Netmasks

Each bit in a netmask is independent of any other bit. It is possible to have

netmasks in which the 1s and 0s are interleaved, but this is not
recommended. RFC 950 recommends the use of contiguous subnet masks
only. A contiguous subnet mask is one that uses only contiguous,
high-order bits (that is, the netmask consists of a sequences of 1s followed
by a sequence of 0s). For example:
11111111 11111111 11111111 11110000

Noncontiguous Netmasks

Although RFC 950 recommends the use of contiguous subnet masks only,
nothing prevents the use of noncontiguous subnet masks. For example:
11111111 11111111 11111111 01001010

Using noncontiguous subnet masks makes administration of the network

more difficult and should be avoided if at all possible.

Configuring IP 5-15
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Subnetting and VLSM

Configuring the Netmask

A netmask is configured on each network interface when an IP address is
assigned. The default behavior is to apply the appropriate class of
netmask depending upon the address, but it is possible to specify a
netmask other than the default.

When configuring an interface on the command line by using the

ifconfig command, use the netmask argument to set the netmask for
an interface. The netmask argument is followed by the netmask value,
specified as:
● Dot-separated decimals
● A single, hexadecimal value preceded by 0x
● A + (plus) sign
● A name listed in the /etc/inet/networks file or equivalent
naming service database

For example:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
# ifconfig hme0 down
# ifconfig hme0 netmask 255.255.240.0
# ifconfig hme0 up
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask fffff000 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

5-16 Network Administration for the Solaris™ 10 Operating System

The broadcast address for an interface is related to the netmask. If the

netmask is changed, the broadcast address must also be changed to reflect
the new network. The simplest way to do this is to use the
broadcast + argument to the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask fffff000 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
# ifconfig hme0 down
# ifconfig hme0 broadcast +
# ifconfig hme0 up
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask fffff000 broadcast 192.168.15.255
ether 8:0:20:b9:72:23
#

The /etc/inet/netmasks File

The svc:/network/physical SMF service configures the network
interfaces at system boot. This method uses the ifconfig command to
configure the network interfaces. When configuring network interfaces,
the ifconfig command can be supplied with a netmask as an argument,
or it can determine which netmask to use based upon system information.

Note – Before the Solaris 10 OS, the network interfaces were configured at
boot time during the execution of the /etc/rcS.d/S30network.sh in
the Solaris 9 OS while earlier releases were configured as part of the
S30rootusr.sh script.

Configuring IP 5-17
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Subnetting and VLSM

Netmasks for particular networks can be defined in the

/etc/inet/netmasks file. The /etc/netmasks file is linked
symbolically to the /etc/inet/netmasks file. The
/etc/inet/netmasks file enables the permanent assignment of a
netmask. The ifconfig command consults the /etc/inet/netmasks
file (or equivalent naming-service database) if no netmask is specified as
an argument. For every network that is subnetted, an individual line is
entered into this file. Each entry in the /etc/inet/netmasks file contains
the netmask definition of a network number.

5-18 Network Administration for the Solaris™ 10 Operating System

For example:
# cat /etc/inet/netmasks
#
# The netmasks file associates Internet Protocol (IP) address
# masks with IP network numbers.
#
# network-number netmask
#
# The term network-number refers to a number obtained from the Internet
Network
# Information Center.
#
# Both the network-number and the netmasks are specified in
# "decimal dot" notation, e.g:
#
# 128.32.0.0 255.255.255.0
#
192.168.1.0 255.255.255.0
#

The netmask value in the netmask file can be specified when configuring
the network interface by using the + (plus) argument with the netmask
argument:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask fffff000 broadcast 192.168.15.255
ether 8:0:20:b9:72:23
# ifconfig hme0 down
# ifconfig hme0 netmask + broadcast +
# ifconfig hme0 up
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Configuring IP 5-19
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Subnetting and VLSM

VLSM
RFC 950 specifies how an IP network could use subnet masks. When an IP
network is assigned more than one subnet mask, it is considered a
network with VLSMs because the extended-network numbers have
different lengths at each subnet level.

Two of the main advantages to assign more than one subnet mask to a
given IP network number are:
● Multiple subnet masks permit more efficient use of an organization’s
assigned IP address space.
● Multiple subnet masks permit route aggregation, which can
significantly reduce the amount of routing information at the
backbone level within an organization’s routing domain.

An example of VLSM entries in the /etc/inet/netmasks file is:

12.0.0.0 255.255.0.0
12.3.0.0 255.255.255.0
12.3.254.0 255.255.255.224

Note – VLSM subnet masks’ syntax has been recognized since the
Solaris 2.6 OS.

Figure 5-11 shows these additional subnet and host addresses.

16-bit 24-bit 27-bit

Subnet Mask Subnet Mask Subnet Mask

12.3.1.0
12.3.2.0
12.1.0.0 12.3.3.0
12.2.0.0 .
12.3.0.0 . 12.3.254.0
. . 12.3.254.32
12.0.0.0 . 12.3.252.0 12.3.254.64
. 12.3.253.0 .
12.252.0.0 12.3.254.0 .
12.253.0.0 .
12.254.0.0 12.3.254.192
12.3.254.224

Figure 5-11 Subnet Mask Addresses

5-20 Network Administration for the Solaris™ 10 Operating System

One of the major problems with supporting only a single subnet mask
across a given network number is that once the mask is selected, it locks
the organization into a fixed number of fixed-sized subnets. For example,
a Class B subnet that is masked with 255.255.252.0 yields additional
subnet and host addresses.

Figure 5-12 shows the breakdown of the number of networks and the
number of hosts as a result of a fixed subnet mask being applied to the
address.
11111111 11111111 11111100 00000000

1024 Two Hosts Per Subnet

64 Subnets

Figure 5-12 Breakdown of Hosts and Subnets

Configuring IP 5-21
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Interface Configuration Files

Introducing the Interface Configuration Files

System administrators often configure system interfaces from the
command line so that the changes are made immediately without having
to reboot the system. This configuration must be performed manually
each time the system is restarted for any reason because changes made at
the command line are not stored in configuration files.

Configuration files enable systems to automatically configure interfaces

during the boot process.

The /etc/hostname.interface File

The svc:/network/physical SMF service reads the
/etc/hostname.interface file. The service assigns an IPv4 address on
the local system for each IPv4 interface. At least one
/etc/hostname.interface file must exist on the local system for each
interface to be configured. Additional interfaces can be configured by
creating additional hostname.interface files manually. These files must
contain at least one entry: the host name or the IPv4 address that is
associated with the network interface. For example, if the hme0 interface is
the primary network interface for a system called sys11, the file is called
/etc/hostname.hme0 and it contains at least one line, which is the name
of the system, sys11.

Note – In the Solaris 9 OS, the /etc/rcS.d/S30network.sh startup script

reads the /etc/hostname.interface file. In earlier releases of Solaris,
the S30rootusr.sh script reads the /etc/hostname.interface file.

The /etc/inet/hosts File

The /etc/inet/hosts file contains the IPv4 addresses and the host
names of the interfaces on your system. The /etc/hosts file is linked
symbolically to the /etc/inet/hosts file. This file is referenced when the
/etc/nsswitch.conf file has the files keyword for host resolution.
This file is also referenced at system startup when the interfaces are being
configured.

5-22 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing the Interface Configuration Files

An example of an /etc/inet/hosts file is:

# more /etc/inet/hosts
#
# Internet host table
#
127.0.0.1 localhost
192.168.1.1 sys11 loghost
#

In this example, the IPv4 address 127.0.0.1 is the loopback address, the
reserved network address that supports interprocess communication by
permitting the local system to send packets to itself. Every system on a
TCP/IP network must use the IP address 127.0.0.1 for the local host.

The /etc/nodename File

The /etc/nodename file contains one entry: the host name of the local
system. For example, on system sys11, the /etc/nodename file contains
the entry sys11. This file establishes the canonical name for the system for
applications.

If a system requires a host name change, the following files must be

edited to reflect the new host name:
● The /etc/inet/hosts file
● The /etc/nodename file
● The /etc/hostname.interface file

Note – Versions of the Solaris OS before Solaris 10 OS required the

/etc/net/*/hosts files to be edited when changing a system’s host
name. Editing these files is not required in the Solaris 10 OS.

Configuring IP 5-23
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Administering Logical Interfaces

Administering Logical Interfaces

Logical interfaces are also referred to as virtual interfaces. You can
configure a single, physical network interface to have many different IP
addresses, including IP addresses that are in different IP classes. Logical
interfaces do not have to exist on the same subnet as the primary
interface. This is one way in which a single system can appear to be
multiple systems.

To view the number of logical addresses that can be configured, type the
command:
# ndd /dev/ip ip_addrs_per_if
256
#

This represents the physical interface and a further 255 logical interfaces.
The ndd command can be used to change this value up to a maximum of
8192.

Introducing Logical Interfaces

Each logical interface is assigned a unique IP address and a unique host
name. Example scenarios in which logical interfaces might be applied
include:
● Systems that use high-availability failover
● Web servers that require multiple web site URLs
● Servers that run several applications which must appear as separate
systems

Some advantages of logical interfaces are:

● Lower cost – You do not need to purchase additional Ethernet cards.
● Easier to back up and administer – Backup and maintenance can be
done on one host instead of on several hosts.

5-24 Network Administration for the Solaris™ 10 Operating System

Some disadvantages of logical interfaces are:

● Heavy network load – Having many logical addresses tied to a
specific Ethernet interface can cause a network performance
bottleneck.
● Slower system start – Each logical interface must be configured on
system boot, which can be a lengthy process when a large number of
interfaces are configured.

Physical network interfaces have names of the form:

driver-name physical-unit-number

For example:
hme0
qfe3

Logical interfaces have names of the form:

driver-name physical-unit-number:logical-unit-number

For example:
hme0:1
qfe3:1

Figure 5-13 shows how a system with one interface can appear as two
different systems.

Web Server With One IP Address

hme0 192.168.1.1 www.sys11.com

Web Server Configured With Multiple IP Addresses

on a Single Ethernet Interface

hme0 192.168.1.1 www.sys11.com

hme0:1 192.168.1.99 www.sys99.com

Figure 5-13 System Interfaces

Configuring IP 5-25
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Administering Logical Interfaces

Configuring Logical Interfaces

After a physical interface is plumbed (it has STREAMS set up for IP and is
open), and is configured as up by the ifconfig command, you can
configure logical interfaces that are associated with the physical interface
by using separate plumb or addif options to the ifconfig command.

To view the current configuration of the interfaces on the system before

adding a logical interface, use the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

To configure logical network interface 1 on the hme0 physical interface,

use the ifconfig command. In this example, the logical interface is
assigned an IP address of 192.169.1.1:
# ifconfig hme0:1 plumb 192.169.1.1 up
#

To view the changes made to the interface, use the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.169.1.1 netmask ffffff00 broadcast 192.169.1.255
#

The hme0:1 interface is now configured, it has a default netmask of

ffffff00 (255.255.255.0), and it has a broadcast address of
192.169.1.255. You can assign different values for the netmask and
broadcast address if you choose to. Notice that the index number is
unique for each physical interface, while logical interfaces use the
physical interface’s index number.

5-26 Network Administration for the Solaris™ 10 Operating System

The addif Option

It can be tedious to increment the logical interface number each time you
add logical interfaces. The ifconfig command includes the addif
option, which causes the command to use the next available logical
interface.

For example, to add the next logical interface with an IP address of

192.168.55.1, use the following command:
# ifconfig hme0 addif 192.168.55.1 up
Created new logical interface hme0:2
#

The same results can be achieved by editing the /etc/hostname.hme0 file

so that its contents are similar to the following:
# cat /etc/hostname.hme0
sys11 up
addif 192.168.55.1 up

Then reboot the system to configure the logical interface.

# init 6
#

The hme0:1 interface is added and is functional.

Configuring IP 5-27
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Administering Logical Interfaces

Unconfiguring Logical Interfaces

To unconfigure a logical interface, use the ifconfig command with the
down and unplumb options. Use the down option before the unplumb
option to make sure that the interface is shut down in the correct order
and that no data is lost. For example, to unconfigure the hme0:1 interface,
type the following:
# ifconfig hme0:1 down unplumb
#

To verify that the interface is removed, use the ifconfig command:

The hme0:1 interface is no longer available.

When you know the logical interface’s IP address, but you do not know to
which logical interface the address is assigned, use the ifconfig
command with the removeif option. For example;
# ifconfig hme0 removeif 192.168.55.1
#

Caution – If you are logged in remotely and are using this interface for
your connection, you will lose your connectivity to the system.

5-28 Network Administration for the Solaris™ 10 Operating System

Exercise: Reviewing IP
In this exercise, you define logical interfaces in two ways: by explicitly
naming the logical interface and by using a command to automatically
add the next available logical interface.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Task Summary
In this exercise, you accomplish the following:
● Use the ifconfig command to define and configure a hme0:1
interface on a different network to the hme0 interface.
● Define the RFC 1918-compliant address by replacing the 192.168
part of your system’s address with 172.18/24. The /24 means that
the first 24 bits of the address represent the network address, and the
remaining 8 bits represent the host portion of the address.
● Configure the interface to use a Class C broadcast address. For
example, if your hme0 interface has an address of 192.168.1.2,
configure the hme0:1 interface to have an IP address of 172.18.1.2,
a netmask of 255.255.255.0, and a broadcast address of
172.18.1.255.

Configuring IP 5-29
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing IP

Tasks
Complete the following steps:
1. Use the ifconfig command to view the system’s interface
configuration before making any changes, so that you can easily
restore your system to its original state if needed.
Write the command that you use:
_____________________________________________________________
2. Use the ifconfig command to configure the hme0:1 interface with
the appropriate IP address and a netmask of 255.255.255.0. For
example, if your IP address begins with 192.168, then change it so
that it begins with 172.18. Use the appropriate command to cause
the interface to function properly.
Write the command that you use:
_____________________________________________________________
3. View the configuration of the interfaces on the system. Notice that
the index for the new logical interface is the same as the physical
interface and that no Ethernet address is listed under the new logical
interface.
Write the command that you use:
_____________________________________________________________
4. Use the ifconfig command with the appropriate option to
configure the next available logical interface with an IP address that
is incremented by 1 in the second octet. For example if you used
172.18.1.2 in the previous step, use 172.19.1.2 for this interface.
Configure a netmask of 255.255.255.0 and a broadcast address of
172.19.1.255. Be sure to use the appropriate command to cause the
interface to function properly.
Write the command that you use:
_____________________________________________________________
5. View the configuration of the interfaces on the system. Notice that
the next sequential logical interface was defined (hme0:2 in this
example). Also notice that the index for the new logical interface is
the same as the physical interface and that no Ethernet address is
listed under the new logical interface.
Write the command that you use:
_____________________________________________________________

5-30 Network Administration for the Solaris™ 10 Operating System

6. Use the removeif option of the ifconfig command to remove the

first logical interface that you defined.
Write the command that you use:
_____________________________________________________________
7. View the configuration of the interfaces on the system. Notice that
the first logical interface is removed.
Write the command that you use:
_____________________________________________________________
8. Use the appropriate command to specifically remove the second
logical interface that you defined.
Write the command that you use:
_____________________________________________________________
9. View the configuration of the interfaces on the system.
Write the command that you use:
_____________________________________________________________

Configuring IP 5-31
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise Summary

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

5-32 Network Administration for the Solaris™ 10 Operating System

Exercise Solutions
Solutions to the exercise are as follows:
1. Use the ifconfig command to view the system’s interface
configuration before making any changes, so that you can easily
restore your system to its original state if needed.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#
2. Use the ifconfig command to configure the hme0:1 interface with
the appropriate IP address and a netmask of 255.255.255.0. For
example, if your IP address begins with 192.168, then change it so
that it begins with 172.18. Use the appropriate command to cause
the interface to function properly.
# ifconfig hme0:1 plumb 172.18.1.2 netmask 255.255.255.0 broadcast 172.18.1.255 up
#
3. View the configuration of the interfaces on the system. Notice that
the index for the new logical interface is the same as the physical
interface and that no Ethernet address is listed under the new logical
interface.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.18.1.2 netmask ffffff00 broadcast 172.18.1.255
#

Configuring IP 5-33
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise Solutions

4. Use the ifconfig command with the appropriate option to

configure the next available logical interface with an IP address that
is incremented by 1 in the second octet. For example if you used
172.18.1.2 in the previous step, use 172.19.1.2 for this interface.
Configure a netmask of 255.255.255.0 and a broadcast address of
172.19.1.255. Be sure to use the appropriate command to cause the
interface to function properly.
# ifconfig hme0 addif 172.19.1.2 netmask 255.255.255.0 broadcast 172.19.1.255 up
Created new logical interface hme0:2
#
5. View the configuration of the interfaces on the system. Notice that
the next sequential logical interface was defined (hme0:2 in this
example). Also notice that the index for the new logical interface is
the same as the physical interface and that no Ethernet address is
listed under the new logical interface.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.18.1.2 netmask ffffff00 broadcast 172.18.1.255
hme0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.19.1.2 netmask ffffff00 broadcast 172.19.1.255
#
6. Use the removeif option of the ifconfig command to remove the
first logical interface that you defined.
# ifconfig hme0 removeif 172.18.1.2
#
7. View the configuration of the interfaces on the system. Notice that
the first logical interface is removed.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
hme0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.19.1.2 netmask ffffff00 broadcast 172.19.1.255
#

5-34 Network Administration for the Solaris™ 10 Operating System

8. Use the appropriate command to specifically remove the second

logical interface that you defined.
# ifconfig hme0:2 down unplumb
#
9. View the configuration of the interfaces on the system.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Configuring IP 5-35
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Module 6

Configuring IP Network Multipathing

Objectives
This module describes how to configure IP Network Multipathing
(IPMP). This module also describes the limitations of network interfaces,
IPMP requirements, configuration of IPMP on the command line and at
system boot, and troubleshooting.

Upon completion of this module, you should be able to:

● Describe IP multipathing
● Implement IP multipathing

The course map in Figure 6-1 shows how this module fits into the current
instructional goal.
Configuring the Network

Configuring IP
Configuring Configuring
Network
IP Routing
Multipathing

Describing
Configuring the Transport
IPv6 Layer

Figure 6-1 Course Map

6-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Increasing Network Availability

Increasing Network Availability

In today’s computing environments, the availability of network
connectivity is important. The Solaris 10 OS includes the IPMP feature,
which provides enhanced availability of network connections.

Limitations of Network Interfaces

Network interfaces are exposed to failure because they connect to
network cables and hardware components in the form of switches or
hubs. Failure of any of these interfaces results in network failure, even if
the NIC that is in place does not fail.

IPMP enables multiple interfaces with different IP addresses on the same

subnet to be grouped together. If any one of these interfaces fail, current
network connections through that interface will be migrated to another
interface in the group automatically to maintain network connectivity.

Figure 6-2 shows how a system can have multiple interfaces on the same
LAN.

qfe0
qfe1
qfe2
qfe3

Server

Client

Figure 6-2 IPMP Configuration

6-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configuring IP Network Multipathing

IPMP is a product that is included with the Solaris 10 OS and provides
enhanced network availability.

Introducing IPMP
IPMP enables the Solaris 10 OS to recover from network path failures.
IPMP also provides increased throughput by spreading the outbound
load across interfaces when multiple network adapters are connected to
the same IP network, such as to the same Ethernet switch.

If a failure occurs in the network link and an alternate adapter is

configured, the IP address fails over. The network access changes
automatically from the failed adapter to the new adapter, providing
uninterrupted access to the network.

IPMP has the following features:

● It eliminates a single network adapter as a single point of failure in
these cases:
● Network adapter failure
● Network link failure
● It enables interfaces to fail over within approximately 10 seconds
when using the default configuration.
● It can be configured by adjusting the parameters in the
/etc/default/mpathd file.
● It can be configured for use with both IPv4 and IPv6.
● It enables interfaces to be configured as standby interfaces. These
types of interfaces are only used for failover and are not used for
outbound load spreading, unless they are explicitly chosen by an
application.

Probe-based IPMP Configurations Compared With Link-based

IPMP Configurations

There are two methods for configuring IPMP: probe-based and link-based.
Probe-based IPMP utilizes test addresses to monitor the health of
interfaces. Link-based IPMP does not utilize test addresses. Instead, the
interface kernel driver performs this function.

Configuring IP Network Multipathing 6-3

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Probe-based IPMP Configuration

Probe-based failure detection for IPMP uses test addresses to detect
failures, and notify the networking subsystem.

Probe-based IPMP Requirements

The following items are required to configure probe-based IPMP on a

system:
● The Solaris 8 10/00 OS, as a minimum, must be installed.
● Unique MAC addresses must be configured on each network
interface.
The default configuration for most Sun network adapters has all
network interfaces on a system using the same MAC (Ethernet)
address. IPMP requires that all interfaces in an IPMP group be
connected to the same IP link. Switched networks use MAC
addresses when making decisions about where to send packets.
Therefore, you must change the system’s default configuration for
MAC addresses to avoid a MAC address conflict.
● Multiple network adapter interfaces must be connected on each
subnet.
You can configure IPMP with a single network interface to take
advantage of network failure detection. To use the full benefit of
IPMP, make sure that two or more network interfaces are connected
to the same subnet.
● An IPMP group name must be assigned to interfaces.
Interfaces that are to be deployed as part of an IPMP configuration
must belong to an IPMP group. Each IPMP group has an IPMP
group name. The in.mpathd daemon uses the IPMP group names.
Use a meaningful name that does not include spaces when you
choose a group name. The IPMP group name is local to the system
and is not used across the network.

6-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

● A test address is assigned to an interface.

The in.mpathd daemon uses test addresses, which must be
routable addresses, to monitor the status of each individual interface.
The test addresses are used to detect failure and recovery of an
interface. These addresses are deprecated at configuration time to
make sure that they cannot be used as source addresses by other
applications.
● Additional hosts or devices must exist on the same subnet.
The test interfaces are used to send ICMP echo requests to targets on
the local link, either by addressing a default router on the local link
or by using the all hosts multicast group (224.0.0.1), to test that
the network link is functioning.

Interface Failure Detection and Repair

Network interfaces on which IPMP is configured are monitored by the

in.mpathd daemon. The in.mpathd daemon can detect both the failure
and the repair of an interface by:
● Sending ICMP echo requests and receiving ICMP echo replies
through the interface
● Monitoring the internal IFF_RUNNING flag on the interface

An interface has failed if either of these two detection methods indicates a

failure. An interface is considered repaired only if both methods report
that the interface is operational and can send and receive packets through
the interface.

To detect the failure or repair of interfaces that belong to the IPMP group,
the in.mpathd daemon sends ICMP echo requests from the test addresses
on the IPMP interfaces to targets connected to the local network. The
in.mpathd daemon determines which targets to probe dynamically. If five
consecutive probes do not receive replies, the interface is considered
failed. Adjust the failure detection time by editing the
FAILURE_DETECTION_TIME variable from the default value of 10,000
milliseconds (10 seconds) in the /etc/default/mpathd file.

When responses to the ICMP echo requests are not received and a specific
time period has elapsed, the physical interface is considered failed. The IP
address that is associated with the failed address is moved to a new
logical interface associated with another physical interface in the same
IPMP group. Communications that were taking place continue to function
as though the original interface is still working properly.

Configuring IP Network Multipathing 6-5

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

ICMP echo requests are still attempted through the failed NIC to detect if
a physical interface is repaired.

If all the NICs or targets appear to fail at the same time, this is a group
failure, and no fail over is performed. The in.mpathd daemon flushes all
of the current targets and attempts to discover new targets. You cannot
configure the targets because the in.mpathd daemon determines
dynamically which targets to probe. Default routers connected to the link
are chosen as targets for probing. If no routers exist on the link, arbitrary
hosts on the link are chosen by sending a multicast packet to the all hosts
multicast address. When you configure IPMP, be sure to have at least one
additional system on the network that can act as a target.

You can configure IPMP by changing configuration files and rebooting, or

you can work at the command line to avoid rebooting the system.

Configuring Probe-based IPMP by Using Configuration

Files
This example shows IPMP configuration on an existing configured hme0
interface and on an existing but unconfigured qfe1 interface on the sys11
(192.168.1.1) system. The multipath group is called mpgrp-one.

Note – To maximize the resistance of your configuration to failure, the

IPMP group should consist of interfaces that each reside on a different
interface card. This approach minimizes the number of common
components in a configuration.

The test addresses are:

● The 192.168.1.51 address for the hme0 interface
● The 192.168.1.71 address for the qfe1 interface

The data address for the hme0 interface remains as 192.168.1.1, and the
data address for the qfe1 interface is 192.168.1.21.

6-6 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

To configure probe-based IPMP, complete the following steps, which are

described in greater detail in the next sections.
1. Verify the Solaris OS release.
2. Configure unique MAC addresses.
3. Define IP addresses.
4. Configure the interfaces.
5. Reboot the system.
6. View the interface configuration.

You must know the state of the system if you need to restore it. Before
making any changes to the system, view the system’s interface
configuration by executing the command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Verify the Solaris OS Release

The /etc/release file contains information about the installed version of

the Solaris OS.

The following system meets the minimum requirements:

# cat /etc/release
Solaris 8 10/00 s28s_u2wos_11b SPARC
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved.
Assembled 31 August 2000
#

The following system exceeds the minimum requirements:

# cat /etc/release
Solaris 10 3/05 s10_74L2a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 22 January 2005

Configuring IP Network Multipathing 6-7

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configure Unique MAC Addresses

To determine if unique MAC addresses are permitted, use the eeprom

command to view the contents of the system’s EEPROM:
# eeprom "local-mac-address?"
local-mac-address?=false
#

The preceding output indicates that the system is still in its default mode
and uses the same MAC address for every interface. This is indicated by
the setting of the local-mac-address? variable to false. Use the eeprom
command to change the local-mac-address? variable to true:
# eeprom "local-mac-address?=true"
#

Verify that the local-mac-address? variable is set to true:

# eeprom "local-mac-address?"
local-mac-address?=true
#

Note – Depending on the combination of your system’s firmware and

hardware architecture, you must either plumb an interface or reboot the
system to enable unique MAC address assignment after changing the
local-mac-address? variable.

Define the IP Addresses

Add the data and test IP addresses to the /etc/inet/hosts file for the
sake of clarity. After editing the /etc/inet/hosts file, use the cat
command to view the new information:
# cat /etc/inet/hosts
#
# Internet host table
127.0.0.1 localhost
192.168.1.1 sys11 loghost # Data address for hme0
# Modifications made for IPMP
192.168.1.21 sys11-data-qfe1 # Data address for qfe1
192.168.1.51 sys11-test-hme0 # Test address for hme0
192.168.1.71 sys11-test-qfe1 # Test address for qfe1
#

6-8 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configure the Interfaces

Multipath information is placed in the /etc/hostname.hme0 and

/etc/hostname.qfe1 files. Modify the /etc/hostname.hme0 file to
contain contents similar to the following:
# cat /etc/hostname.hme0
sys11 netmask + broadcast + group mpgrp-one up \
addif sys11-test-hme0 deprecated netmask + broadcast + -failover up
#

Table 6-1 describes the entries in the /etc/hostname.hme0 file.:

Table 6-1 Interface Configuration Entries

Entry Purpose

sys11 Assigns the address associated with the sys11 name.

netmask + Looks up the netmask in the netmasks database.
broadcast + Assigns the broadcast address. The + (plus) indicates that
the broadcast address should be calculated automatically
from the IP address and netmask.
group mpgrp-one Assigns mpgrp-one as the name for the IPMP group of
which this interface is a member.
up Marks the interface as up.
addif sys11-test-hme0 Creates the next unused logical interface, and assigns it the
IP address associated with the sys11-test-hme0 name.
deprecated Marks the address as a deprecated address. Addresses that
are marked as deprecated are not used as source addresses
for outgoing packets unless either there are no other
addresses available on this interface or the application is
bound to this address explicitly. The output from the
ifconfig -a command shows DEPRECATED as one of the
flags associated with this interface.
-failover Marks the address as a non-failover address. Addresses
that are marked in this way do not fail over when the
network interface fails. The output from the ifconfig -a
command shows NOFAILOVER as one of the flags associated
with this interface.

Configuring IP Network Multipathing 6-9

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Create the /etc/hostname.qfe1 file with contents similar to the

following:
# cat /etc/hostname.qfe1
sys11-data-qfe1 netmask + broadcast + group mpgrp-one up \
addif sys11-test-qfe1 deprecated netmask + broadcast + -failover up
#

Cable the Interfaces

You should ensure that all of the interfaces that are part of the IPMP
configuration have cables connecting them to the same IP link.

Note – In versions of the Solaris OS before the Solaris 10 OS, at this point
in the procedure, you had to disable the automatic configuration of the
system as a router. For example, if your host does not act as a router
currently, rebooting it with two interfaces configured causes it to be
configured as a router after the reboot. For a system that runs IPMP and is
connected to a single IP link, this is undesirable. To prevent this, type the
command touch /etc/notrouter.

Reboot the System

Reboot the system to enable IPMP:

# init 6

6-10 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

View the Interface Configuration

To view the configuration of the interfaces when the system is booted, use
the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:b9:72:23
hme0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 2
inet 192.168.1.51 netmask ffffff00 broadcast 192.168.1.255
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:ac:9b:21
qfe1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 3
inet 192.168.1.71 netmask ffffff00 broadcast 192.168.1.255
#

Observe the additional information that is reported by the preceding

ifconfig command for the hme0:1 interface:
hme0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 2
inet 192.168.1.51 netmask ffffff00 broadcast 192.168.1.255

This information includes the following:

● The interface’s index number is 2, the same as the physical interface.
● The hme0:1 interface’s MAC address is not shown because logical
interfaces use the same MAC address as the physical interface.
● The DEPRECATED and NOFAILOVER flags indicate that the interface is
not to be used by any application (other than the in.mpathd
daemon), and the interface must not be failed if a communication
failure occurs.
● The RUNNING flag is also monitored by the in.mpathd daemon to
ensure that communications are functioning as expected.

The system remains available to users if either of the interfaces fails or

becomes unusable for any reason.

Configuring IP Network Multipathing 6-11

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configuring Probe-based IPMP on the Command Line

A system can be configured for IPMP without being rebooted if the
system’s EEPROM is already configured to support unique MAC
addresses. The following steps demonstrate use of the ifconfig
command to configure IPMP on the command line. Although not shown
in this section, you can also use the ifconfig command to change and
delete IPMP group memberships.

This example shows configuring IPMP on an existing configured hme0

interface and on an existing, but unconfigured, qfe1 interface, where the
IPMP group is called mpgrp-one.

This configuration is on the sys11 (192.168.1.1) system, where the test

address is:
● The 192.168.1.51 address for the hme0 interface
● The 192.168.1.71 address for the qfe1 interface

The data address for the hme0 interface remains 192.168.1.1, and the
data address for the qfe1 interface is 192.168.1.21.

To configure IPMP, complete the following steps, which are described in

greater detail in the next sections.
1. Verify the Solaris OS release.
2. Configure unique MAC addresses.
3. Configure IP addresses.
4. Configure the hme0 interface as part of an IPMP group.
5. Configure a test address for the hme0 interface.
6. Configure the qfe1 interface as part of the same IPMP group.
7. Configure a test address for the qfe1 interface.
8. View the interface configuration.

6-12 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

You must know what state the system is in if you need to restore it. Before
making any changes to the system, view the system’s interface
configuration by typing the command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Verify the Solaris OS Release

The /etc/release file contains information about the installed version of

the Solaris OS.

The following system meets the minimum requirements:

# cat /etc/release
Solaris 8 10/00 s28s_u2wos_11b SPARC
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved.
Assembled 31 August 2000
#

The following system exceeds the minimum requirements:

# cat /etc/release
Solaris 10 3/05 s10_74L2a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 22 January 2005
#

Configure Unique MAC Addresses

To determine if unique MAC addresses are permitted, use the eeprom

command to view the contents of the EEPROM:
# eeprom "local-mac-address?"
local-mac-address?=false
#

Configuring IP Network Multipathing 6-13

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

The preceding output indicates that the system is still in its default mode
and uses the same MAC address for each interface. This is indicated by
the setting of the local-mac-address? variable to false. Use the eeprom
command to change the EEPROM’s local-mac-address? variable to
true. Type the command:
# eeprom "local-mac-address?=true"
#

Note – Depending on the combination of your system’s firmware and

hardware architecture, you will have to either plumb the interface or
reboot the system to enable unique MAC address assignment after
changing the local-mac-address? variable.

Verify that the local-mac-address? variable is set to true:

# eeprom "local-mac-address?"
local-mac-address?=true
#

Configure the IP Addresses

You can add the data and test IP addresses to the /etc/inet/hosts file
for the sake of clarity. After editing the /etc/inet/hosts file, use the cat
command to view the new information:
# cat /etc/inet/hosts
#
# Internet host table
#
127.0.0.1 localhost
192.168.1.1 sys11 loghost # Data address for hme0
# Modifications made for IPMP
192.168.1.21 sys11-data-qfe1 # Data address for qfe1
192.168.1.51 sys11-test-hme0 # Test address for hme0
192.168.1.71 sys11-test-qfe1 # Test address for qfe1
#

6-14 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configure the hme0 Interface as Part of a Multipath Group

To configure the hme0 interface as part of an IPMP group, specify the

name of the group, mpgrp-one, of which the hme0 interface will be a
member:
# ifconfig hme0 group mpgrp-one

To view the changes to the interface, use the ifconfig command:

Configure a Test Address for the hme0 Interface

Next, you configure a test address for the hme0 interface. You can assign
an alias name to this address by using the /etc/inet/hosts file. Do not
use this address for any purpose other than using it for the in.mpathd
daemon. When you define the address, mark it so that the in.mpathd
daemon recognizes it as a test address that must not fail over (-failover)
and must not be used by the system for any application data transmission
(deprecated). Type the command:
# ifconfig hme0 addif 192.168.1.51 deprecated netmask + \
broadcast + -failover up
Created new logical interface hme0:1
Setting netmask of hme0:1 to 255.255.255.0
#

To view the changes to the interface, use the ifconfig command:

Configuring IP Network Multipathing 6-15

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configure the qfe1 Interface as Part of the IPMP Group

Now, you configure the qfe1 interface and make it part of the same IPMP
group as the hme0 interface. Type the commands:
# ifconfig qfe1 plumb sys11-data-qfe1 netmask + broadcast +
Setting netmask of qfe1 to 255.255.255.0
# ifconfig qfe1 group mpgrp-one up

To view the changes to the interface, use the ifconfig command:

Observe the additional information that is reported by the preceding

output of the ifconfig command, for the qfe1 interface:
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:ac:9b:21

This information includes the following:

● The interface index number is incremented to 3 because a unique
index number is assigned to each non-logical interface as it is
configured. Since lo0 is 1 and hme0 is 2, qfe1 is assigned 3.
● The qfe1 interface’s MAC address is different from the hme0
interface’s MAC address, which is caused by changing the
local-mac-address? variable in the system’s EEPROM.

6-16 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configure a Test Address for the qfe1 Interface

Now, you configure a test address for the qfe1 interface. You can alias this
address to a name by using the /etc/inet/hosts file. Do not use this
address for any purpose other than using it for the in.mpathd daemon.
When you define the address, mark it so that the in.mpathd daemon
recognizes it as a test address that must not fail over (-failover) and
must not be used by the system for any application data transmission
(deprecated).

Type the command:

# ifconfig qfe1 addif 192.168.1.71 deprecated netmask + \
broadcast + -failover up
Created new logical interface qfe1:1
Setting netmask of qfe1:1 to 255.255.255.0
#

To view the changes to the interface, use the ifconfig command:

The interface’s index number is 3, which is the same as the physical

interface that supports this logical interface. Notice that the qfe1:1
interface MAC address is not shown because logical interfaces use the
same MAC address as the physical interface that supports the logical
interface.

Configuring IP Network Multipathing 6-17

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Start the in.mpathd Daemon to Monitor the Interfaces

The starting of the in.mpathd daemon is controlled by the

TRACK_INTERFACES_ONLY_WITH_GROUPS parameter in the
/etc/default/mpathd file. The contents of this file are:
# cat /etc/default/mpathd
#
#pragma ident "@(#)mpathd.dfl 1.2 00/07/17 SMI"
#
# Time taken by mpathd to detect a NIC failure in ms. The minimum time
# that can be specified is 100 ms.
#
FAILURE_DETECTION_TIME=10000
#
# Failback is enabled by default. To disable failback turn off this opti
on
#
FAILBACK=yes
#
# By default only interfaces configured as part of multipathing groups
# are tracked. Turn off this option to track all network interfaces
# on the system
#
TRACK_INTERFACES_ONLY_WITH_GROUPS=yes
#

If the TRACK_INTERFACES_ONLY_WITH_GROUPS variable is set to yes, the

ifconfig command’s group option starts the in.mpathd daemon
automatically. That is, as soon as you use the ifconfig command with
the group option in the command, the in.mpathd daemon starts.

If the TRACK_INTERFACES_ONLY_WITH_GROUPS variable is set to no, the

in.mpathd daemon will track all interfaces, including those that are not
part of an IPMP group.

The in.mpathd daemon is started by the svc:network/net-init SMF

service:
# grep in[.]mpathd /lib/svc/method/net-init
/usr/bin/pgrep -x -u 0 in.mpathd >/dev/null 2>&1 || /usr/lib/inet/in.mpathd -a

Note – Before the Solaris 10 OS, the in.mpathd daemon was started
during the execution of the /etc/rc2.d/S69inet start script.

6-18 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

If necessary, the in.mpathd daemon can be started from the command

line by running the command as the root user:
# /sbin/in.mpathd
#

View the Interface Configuration

Now that IPMP is completely configured, to view the configuration of the

interfaces, use the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:b9:72:23
hme0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 2
inet 192.168.1.51 netmask ffffff00 broadcast 192.168.1.255
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:ac:9b:21
qfe1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 3
inet 192.168.1.71 netmask ffffff00 broadcast 192.168.1.255
#

The system remains available to users if either of the network interfaces

fail or become unusable for any reason.

Configuring IP Network Multipathing 6-19

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Link-based IPMP Configuration

Link-based failure detection for IPMP uses the network interface kernel
driver to detect failures and notify the networking subsystem.

Link-based IPMP Requirements

The following items are required to configure link-based IPMP on a

system:
● Solaris 9 12/02 OS, at a minimum, must be installed.
● Network interfaces must use any of the following drivers:
● hme
● eri
● ce
● ge
● bge
● qfe
● dmfe
● Unique MAC addresses must be configured on each of the interfaces.
● An IPMP group name must be assigned to interfaces.

6-20 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configuring Link-based IPMP by Using Configuration

Files
This example shows IPMP configuration on an existing, configured hme0
interface and on an existing, but unconfigured, hme1 interface on the
sys11 (192.168.1.1) system. The multipath group is called
ipmp-group0.

The data address for the hme0 interface remains 192.168.1.1, and the
data address for the hme1 interface is 192.168.1.21.

To configure link-based IPMP, complete the following steps, which are

You must know the state of the system if you need to restore it. Before
making any changes to the system, view the system’s interface
configuration by executing the command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#

Configuring IP Network Multipathing 6-21

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Verify the Solaris OS Release

The /etc/release file contains information about the installed version of

the Solaris OS.

The following system meets the minimum requirements:

# cat /etc/release
Solaris 8 10/00 s28s_u2wos_11b SPARC
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved.
Assembled 31 August 2000
#

The following system exceeds the minimum requirements:

# cat /etc/release
Solaris 10 3/05 s10_74L2a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 22 January 2005
#

Configure Unique MAC Addresses

To determine if unique MAC addresses are permitted, use the eeprom

command to view the contents of the system’s EEPROM:
# eeprom "local-mac-address?"
local-mac-address?=false
#

Verify that the local-mac-address? variable is set to true:

# eeprom "local-mac-address?"
local-mac-address?=true

6-22 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Define the IP Addresses

Add the IP addresses to the /etc/inet/hosts file for the sake of clarity.
After editing the /etc/inet/hosts file, use the cat command to view
the new information:
# cat /etc/inet/hosts
#
# Internet host table
127.0.0.1 localhost
192.168.1.1 sys11 loghost # Data address for hme0
# Modifications made for IPMP
192.168.1.21 sys11-hme1 # Data address for hme1
#

Configure the Interfaces

Network interfaces are configured in the /etc/hostname.hme0 and

/etc/hostname.hme1 files. Modify the /etc/hostname.hme0 file to
contain contents similar to the following:
# cat /etc/hostname.hme0
sys11 netmask + broadcast + group ipmp_group0 up
#

Create the /etc/hostname.hme1 file to contain contents similar to the

following:
# cat /etc/hostname.hme1
sys11-hme1 netmask + broadcast + group ipmp_group0 up
#

Cable the Interfaces

You should ensure that all of the interfaces that are part of the IPMP
configuration have cables connecting them to the same IP link.

Reboot the System

Reboot the system to enable IPMP:

# init 6

Configuring IP Network Multipathing 6-23

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

View the Link-based IPMP Configuration

To verify that the IPMP daemon is running, use the following command:
# pgrep -fl mpathd
119 /usr/lib/inet/in.mpathd -a

Messages to the console (and to /var/adm/messages) from in.mpathd

indicate that the system is configured for link-based IPMP, rather than for
probe-based IPMP.
Dec 16 12:40:33 sys11 in.mpathd[119]: [ID 975029 daemon.error] No test
address configured on interface hme1; disabling probe-based failure
detection on it
Dec 16 12:40:33 sys11 in.mpathd[119]: [ID 975029 daemon.error] No test
address configured on interface hme0; disabling probe-based failure
detection on it

6-24 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Verify Link-based IPMP Operation

To verify the system’s IPMP configuration, the if_mpadm command can

be used. You can use this command to take a network interface offline
(detach it), which forces a failover. Messages are sent to the console and to
/var/adm/messages that indicate any failovers or failbacks which occur.

Take the hme0 interface offline to force a failover:

# if_mpadm -d hme0

The message on the console indicates that the failover was successful:
Dec 16 13:24:31 sys11 in.mpathd[119]: Successfully failed over from NIC hme0 to NIC hme1

To view the current status of the network interfaces, use the ifconfig
command:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=89000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,OFFLINE> mtu 0 index 2
inet 0.0.0.0 netmask 0
groupname ipmp_group0
ether 8:0:20:b9:72:23
hme1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname ipmp_group0
ether 8:0:20:ac:9b:21
hme1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255

Notice, that the IP address of the hme0 interface is 0.0.0.0, and a new
logical interface hme1:1 is created on the remaining physical interface
hme1. The new logical interface has the IP address (192.168.1.1) that
was assigned to the physical hme0 interface before it failed.

Reattach the hme0 interface, to force a failback:

# if_mpadm -r hme0

The message on the console indicates that the failback was successful:
Dec 16 13:41:47 sys11 in.mpathd[119]:Successfully failed back to NIC hme0

Configuring IP Network Multipathing 6-25

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

To view the current status of the network interfaces, use the ifconfig
command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname ipmp_group0
ether 8:0:20:b9:72:23
hme1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname ipmp_group0
ether 8:0:20:ac:9b:21
#

The hme0 interface is reassigned its original IP address, and the hme1:1
logical interface is removed automatically.

Configuring a Singleton IPMP Group

It is possible to configure an IPMP group that contains only one interface.
This enables you to monitor the status of the interface by using IPMP and
to receive notifications about the interface’s status, although it is not
possible to fail the interface over onto another network interface.

With only a single interface in the group, the data address can never move
on to a different interface, and so is always associated with the interface
being monitored. In this configuration, it is not necessary to configure a
separate test address because the system can use the data address for
testing purposes.

6-26 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Configure a Single IPMP Group on the Command Line

To create a singleton IPMP group, assign a multipath group name to the

interface:
# ifconfig hme0 group singleton
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu823
2 index 1
inet 127.0.0.1 netmask ff000000
hme0 flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname singleton
ether 8:0:20:b9:72:23
#

Note – Do not use the deprecated option because this prevents

applications from using the interface’s only IP address as a source
address.

If the single interface will be included in an IPMP group with multiple

interfaces, also set the NOFAILOVER flag on the interface by using the
-failover option.

Configure a Single IPMP Group at System Boot

To create a singleton IPMP group at system boot, ensure that the interface
configuration file contains the group option and the IPMP group name:
# cat /etc/hostname.hme0
sys11 group singleton up
#

Note – Use IPMP only on a single interface if multiple default routers

exist on the local network. This enables multiple targets to be probed
when checking the availability of the network.

Configuring IP Network Multipathing 6-27

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Viewing IPMP Operation

To verify the system’s failover configuration, or to change the operational
status of IPMP interfaces, use the if_mpadm command. You can use this
command to take an interface offline (detach) by forcing a fail over and
verifying that an alternate interface takes over as expected. If
configuration errors occur, they appear at this stage. Also, use the
if_mpadm command to reattach a detached interface.

For example, to detach the hme0 interface, type the command:

# if_mpadm -d hme0
Aug 4 14:00:38 sys11 in.mpathd[535]: Successfully failed over from NIC
hme0 to NIC qfe1
#

The message indicates that the failover was successful.

Note – This message appears in the console window and is not seen if you
are using an xterm or dtterm window.

To view the status of the interfaces, use the ifconfig command:

# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=89000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,OFFLINE> mtu 0 index 2
inet 0.0.0.0 netmask 0
groupname mpgrp-one
ether 8:0:20:b9:72:23
hme0:1: flags=89040842<BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,OFFLINE>
mtu 1500 index 2
inet 192.168.1.51 netmask ffffff00 broadcast 192.168.1.255
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:ac:9b:21
qfe1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 3
inet 192.168.1.71 netmask ffffff00 broadcast 192.168.1.255
qfe1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
#

6-28 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

The detached interface is assigned an IP address of 0.0.0.0, and a new

logical interface, qfe1:2, is created automatically on the functional qfe1
physical interface. The new logical interface has the IP address that was
assigned to the physical hme0 interface while it was working.

To reattach an offline interface, type the command:

# if_mpadm -r hme0
Aug 4 14:02:09 sys11 in.mpathd[535]: Successfully failed back to NIC
hme0
#

Note – This message appears in the console window and is not seen if you
are using an xterm or dtterm window.

The message indicates that the fail back was successful. To view the status
of the interfaces, use the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:b9:72:23
hme0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 2
inet 192.168.1.51 netmask ffffff00 broadcast 192.168.1.255
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.21 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:ac:9b:21
qfe1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 3
inet 192.168.1.71 netmask ffffff00 broadcast 192.168.1.255
#

The hme0 interface is reassigned its original IP address, and the qfe1:2
logical interface is removed automatically.

Configuring IP Network Multipathing 6-29

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

Troubleshooting an IPMP Configuration

Incorrectly configured network interfaces might not properly fail over
when connectivity to an interface fails for any reason. It is important to
thoroughly test your network interface after you configure IPMP.

Carefully read messages in the /var/adm/messages file or in the console

window to take the proper troubleshooting steps when you configure and
test the IPMP. For example:
# Aug 4 13:54:51 sys11 in.mpathd[535]: No test address configured on
interface hme0; disabling probe-based failure detection on it

The message indicates that the in.mpathd daemon with a process

identifier (ID) of 535 senses that IPMP is not properly configured. To
investigate further, use the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:b9:72:23
#

The output indicates that the configuration process is not complete. Recall
that IPMP requires a test address on a logical interface for each physical
interface. To configure a test interface, use the ifconfig command:
# ifconfig hme0 addif 192.168.1.51 deprecated netmask + \
> broadcast + -failover up
Created new logical interface hme0:1
Setting netmask of hme0:1 to 255.255.255.0
#

After defining a test interface with the ifconfig command, the following
message appears:
# Aug 4 13:55:37 sys11 in.mpathd[355]: Test address now configured on
interface hme0; enabling probe-based failure detection on it

6-30 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Configuring IP Network Multipathing

The in.mpathd daemon reports that it can now perform failure detection.
Be aware that more than one interface is required to provide effective
failover. To view the interface configuration, use the ifconfig command:
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp-one
ether 8:0:20:b9:72:23
hme0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 2
inet 192.168.1.51 netmask ffffff00 broadcast 192.168.1.255
#

Both the physical and logical interfaces are configured properly.

Configuring IP Network Multipathing 6-31

Exercise: Configuring IPMP

In this exercise, you configure IPMP on your system.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

At least two interfaces of the same type (for example, Ethernet) are
required for this exercise. Verify that your system meets the minimum
requirements and has enough network cabling before you continue. Work
with another student if your system does not have enough interfaces.

Caution – Remove any interfaces that you configured that are not part of
previous exercises before starting this exercise.

You need the following information when you configure IPMP in this
exercise:
● The IPMP group name – This name is required for each physical
interface that will be part of the IPMP group.
● A data IP address for each physical interface – Users and
applications use this address when accessing the system.
● A logical interface for each physical interface – The in.mpathd
daemon uses this interface to monitor the status of the physical
interface.
● A second physical interface – This interface must be connected with
a network cable.
● An IP address for each logical interface – This is the test address.

6-32 Network Administration for the Solaris™ 10 Operating System

Write the names and addresses that you will use:

● The IPMP group name is unique to your system.
Write the IPMP group name:
_____________________________________________________________
● The new physical interface uses an IP address of your system’s IP
address plus 20; for example, the new interface has an address of
192.168.1.21.
Write the new physical interface’s IP address:
_____________________________________________________________
● The test IP address for each logical interface is the physical
interface’s IP address plus 50. For example, the physical interface
address of 192.168.1.1 uses test a test address of 192.168.1.51,
and the physical interface IP address of 192.168.1.21 uses a test
address of 192.168.1.71.
Write the first logical interface’s IP address:
_____________________________________________________________
Write the second logical interface’s IP address:
_____________________________________________________________

The following is an example of a complete list of the information that you

need when you configure multipathing in the exercise.
● Assume that the IPMP group name is mpgrp-one.
● Assuming that the existing IP address is 192.168.1.1, the new
physical interface’s IP address is 192.168.1.21.
● The first logical interface’s IP address is 192.168.1.51.
● The second logical interface’s IP address is 192.168.1.71.

Configuring IP Network Multipathing 6-33

Tasks
Complete the following steps:
1. Open a console window to see any messages that might be sent to
the console but perform the other steps in a different (non-console)
window.
2. Verify that your system has a supported version of the Solaris OS.
Write the command that you use:
_________________________________________________
3. Can the system that displayed the preceding output be configured to
support IPMP? Why or why not?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
4. View and document your system’s current interface information
with the ifconfig command, so that you can compare the output
after you configure IPMP.
Write the command that you use:
_____________________________________________________________
5. Document the existing interface information. Ignore the loopback
interface that has an index of 1.
Write the interface type for index 2:
_____________________________________________________________
6. Configure your system to use unique MAC addresses.
Write the command that you use:
_____________________________________________________________
7. Reboot your system to enable unique MAC address assignment.
8. Edit your /etc/inet/hosts file, and add entries for the interfaces.
Use comments to help limit confusion.
Write the command that you use:
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

6-34 Network Administration for the Solaris™ 10 Operating System

9. Determine if the IPMP daemon is running on your system.

● Write the command that you use:
________________________________________________________
● Is the daemon running? Why or why not?
________________________________________________________
________________________________________________________
________________________________________________________
10. Configure IPMP on your system without rebooting, as follows:
a. Assign the system’s existing interface to an IPMP group.
Write the command that you use:
________________________________________________________
b. Determine if the IPMP daemon is running on your system.
Write the command that you use:
________________________________________________________
c. Is the daemon running? Why or why not?
________________________________________________________
________________________________________________________
________________________________________________________
11. Configure a test interface for the physical interface that you just
assigned to an IPMP group. Be sure to set the appropriate netmask
and broadcast addresses. Deprecate the interface, and configure
failover appropriately. Then, configure the interface so that it is up.
Write the command that you use:
_____________________________________________________________
_____________________________________________________________

Configuring IP Network Multipathing 6-35

12. Verify that the new physical interface is connected to the network
before proceeding with the following steps:
a. Configure and plumb the second physical interface. Specify the
appropriate IP address and addresses for broadcast and
netmask. Do not assign it membership in the IPMP group yet or
bring the interface up.
________________________________________________________
b. Assign the newly plumbed interface to the appropriate IPMP
group and bring the interface up.
________________________________________________________
13. Configure a test interface for the physical interface that you just
configured. Be sure to configure the netmask and broadcast
addresses. Deprecate the interface, and configure failover
appropriately. Then, configure the interface so that it is up.
Write the command that you use:
_____________________________________________________________
14. Work with another teammate for this step. Have your teammate:
a. Connect to one of your system’s physical IP addresses over the
network by using the telnet command.
b. Open an edit session by using an editor of your teammate’s
choice in the telnet session.
c. Start typing. While your teammate is typing, either unplug the
network cable to the interface or use the if_mpadm command to
detach one of your system’s IPMP interfaces.
Write the command you need if you used the if_mpadm
command:
________________________________________________________
Notice that your teammate’s work is frozen for a moment and
then continues, even though the interface to which your
teammate is connected is disabled.
d. Repair the interface by reconnecting the network cable or by
using the if_mpadm command.
Write the command that you need if you used the if_mpadm
command:
________________________________________________________

6-36 Network Administration for the Solaris™ 10 Operating System

15. Configure your system so that the interfaces are configured

automatically for IPMP at boot time. Be sure to make copies of your
system’s original configuration files because you will need to restore
your system’s configuration later in this exercise.
Document your configuration steps here:
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
16. Reboot your system to test the IPMP configuration.
Write the command that you use:
_____________________________________________________________
Pay careful attention to the system’s console while it is booting. Look
for any error messages relating to interfaces and address
assignments.
17. Work with another teammate for this step. Have your teammate:
a. Connect to one of your system’s physical IP addresses over the
network by using the telnet command.
b. Open an edit session by using an editor of your teammate’s
choice in the telnet session.
c. Start typing. While your teammate is typing, either unplug the
network cable to the interface or use the if_mpadm command to
detach one of your system’s IPMP interfaces.
Write the command you need if you used the if_mpadm
command:
________________________________________________________
Notice that your teammate’s work is frozen for a moment and
then continues, even though the interface to which your
teammate is connected is disabled.
d. Repair the interface by reconnecting the network cable or by
using the if_mpadm command.
Write the command that you need if you used the if_mpadm
command:
________________________________________________________

Configuring IP Network Multipathing 6-37

18. To prepare your system for future exercises, complete the following
steps and remove the IPMP configuration:
a. Restore the first hostname.interface file that you saved
earlier and delete the second interface file.
b. Reboot your system.

6-38 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Configuring IP Network Multipathing 6-39

Exercise Solutions
Solutions to the exercise are as follows:
1. Open a console window to see any messages that might be sent to
the console but perform the other steps in a different (non-console)
window.
# dtterm -C &
2. Verify that your system has a supported version of the Solaris OS.
# cat /etc/release
Solaris 10 3/05 s10_74L2a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 22 January 2005
#
3. Can the system that displayed the preceding output be configured to
support IPMP? Why or why not?
Yes. This system can be configured with IPMP because it has a version of
the operating environment that is at a minimum the Solaris 8 10/00 OS.
4. View and document your system’s current interface information
with the ifconfig command, so that you can compare the output
after you configure IPMP.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
#
5. Document the existing interface information. Ignore the loopback
interface that has an index of 1.
Write the interface type for index 2:
hme0
6. Configure your system to use unique MAC addresses.
Use the eeprom command.
# eeprom local-mac-address?=true
#

6-40 Network Administration for the Solaris™ 10 Operating System

7. Reboot your system to enable unique MAC address assignment.

# init 6
8. Edit your /etc/inet/hosts file, and add entries for the interfaces.
Use comments to help limit confusion.
The following is an example of the /etc/inet/hosts file:
# cat /etc/inet/hosts
#
# Internet host table
#
127.0.0.1 localhost
192.168.1.1 sys11 loghost # Existing phys hme0 interface
# entries added for IPMP example
192.168.1.51 sys11-hme0-ipmp-test # IPMP logical test addr for hme0
192.168.1.21 sys11-local-qfe1 # IPMP phys interface for qfe1
192.168.1.71 sys11-qfe1-ipmp-test # IPMP logical test addr for qfe1
#
9. Determine if the IPMP daemon is running on your system.
● Write the command that you use:
# pgrep -lf in.mpathd
#
● Is the daemon running? Why or why not?
No, the in.mpathd daemon should not be running because no
interfaces were defined as part of an IPMP group.
10. Configure multipathing on your system without rebooting, as
follows:
a. Assign the system’s existing interface to an IPMP group.
Write the command that you use:
# ifconfig hme0 group mpgrp-one
#
b. Determine if the IPMP daemon is running on your system.
# pgrep -lf in.mpathd
603 /usr/lib/inet/in.mpathd
#
c. Is the daemon running? Why or why not?
Yes, the in.mpathd daemon should be running because you just
assigned an IPMP group name to an interface. Recall that the group
option of the ifconfig command starts the in.mpathd daemon
automatically.

Configuring IP Network Multipathing 6-41

11. Configure a test interface for the physical interface that you just
assigned to an IPMP group. Be sure to set the appropriate netmask
and broadcast addresses. Deprecate the interface, and configure
failover appropriately. Then, configure the interface so that it is up.
# ifconfig hme0 addif 192.168.1.51 deprecated netmask + \
broadcast + -failover up
Created new logical interface hme0:1
#
12. Verify that the new physical interface is connected to the network
before proceeding with the following steps:
a. Configure and plumb the second physical interface. Specify the
appropriate IP address and addresses for broadcast and
netmask. Do not assign it membership in the IPMP group yet or
bring the interface up.
# ifconfig qfe1 plumb 192.168.1.21 netmask 0xffffff00 broadcast +
b. Assign the newly plumbed interface to the appropriate IPMP
group and bring the interface up.
# ifconfig qfe1 group mpgrp-one up
Console message:
in.mpathd[603]: No test address configured on interface qfe1; disabling
probe-based failure detection on it
13. Configure a test interface for the physical interface that you just
configured. Be sure to configure the netmask and broadcast
addresses. Deprecate the interface, and configure failover
appropriately. Then, configure the interface so that it is up.
Write the command that you use:
# ifconfig qfe1 addif 192.168.1.71 deprecated netmask 0xffffff00 \
broadcast + -failover up
Created new logical interface qfe1:1
#
Console message:
in.mpathd[603]: Test address now configured on interface qfe1; enabling
probe-based failure detection on it

6-42 Network Administration for the Solaris™ 10 Operating System

14. Work with another teammate for this step. Have your teammate:
a. Connect to one of your system’s physical IP addresses over the
network by using the telnet command.
b. Open an edit session by using an editor of your teammate’s
choice in the telnet session.
c. Start typing. While your teammate is typing, either unplug the
network cable to the interface or use the if_mpadm command to
detach one of your system’s IPMP interfaces.
# if_mpadm -d qfe1
#
Console message:
in.mpathd[603]: Successfully failed over from NIC qfe1 to NIC hme0
Notice that your teammate’s work is frozen for a moment and
then continues, even though the interface to which your
teammate is connected is disabled.
d. Repair the interface by reconnecting the network cable or by
using the if_mpadm command.
# if_mpadm -r qfe1
#
Console message:
in.mpathd[603]: Successfully failed back to NIC qfe1
15. Configure your system so that the interfaces are automatically
configured for IPMP at boot time. Be sure to make copies of your
system’s original configuration files because you will need to restore
your system’s configuration later in this exercise.
a. Copy your system’s interface files for future use:
# cp /etc/hostname.hme0 /etc/_hostname.hme0
b. Edit the /etc/hostname.hme0 file so that it has contents similar to
the following:
sys11 netmask 0xffffff00 broadcast + group mpgrp-one up
addif 192.168.1.51 deprecated netmask 0xffffff00 broadcast + -failover up
c. Create a /etc/hostname.qfe1 file so that it has contents similar to
the following:
sys11-local-qfe1 netmask 0xffffff00 broadcast + group mpgrp-one up
addif 192.168.1.71 deprecated netmask 0xffffff00 broadcast + -failover up

Configuring IP Network Multipathing 6-43

16. Reboot your system to test the IPMP configuration.

Write the command that you use:
# init 6
#
Pay careful attention to the system’s console while it is booting. Look
for any error messages relating to interfaces and address
assignments.
17. Work with another teammate for this step. Have your teammate:
a. Connect to one of your system’s physical IP addresses over the
network by using the telnet command.
b. Open an edit session by using an editor of your teammate’s
choice in the telnet session.
c. Start typing. While your teammate is typing, either unplug the
network cable to the interface or use the if_mpadm command to
detach one of your system’s IPMP interfaces.
# if_mpadm -d qfe1
#
Console message:
in.mpathd[159]: Successfully failed over from NIC qfe1 to NIC hme0
Notice that your teammate’s work is frozen for a moment and
then continues, even though the interface to which your
teammate is connected is disabled.
d. Repair the interface by reconnecting the network cable or by
using the if_mpadm command.
# if_mpadm -r qfe1
#
Console message:
in.mpathd[159]: Successfully failed back to NIC qfe1

6-44 Network Administration for the Solaris™ 10 Operating System

Configuring IP Network Multipathing 6-45

Configuring Routing

Objectives
This module describes how to configure routing, routing schemes, routing
types, and troubleshooting.

Upon completion of this module, you should be able to:

● Identify the fundamentals of routing
● Describe routing table population
● Describe routing protocol types
● Describe the routing table
● Configure static routing
● Configure dynamic routing
● Describe classless inter-domain routing (CIDR)
● Configure routing at system boot
● Troubleshoot routing

7-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Objectives

The course map in Figure 7-1 shows how this module fits into the current
instructional goal.
Configuring the Network

Configuring IP
Configuring Network Configuring
IP Routing
Multipathing

Describing
Configuring the Transport
IPv6 Layer

Figure 7-1 Course Map

7-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Identifying the Fundamentals of Routing

Identifying the Fundamentals of Routing

Routers are devices that forward IP datagrams between networks. The
process of forwarding IP datagrams to their destinations is called
forwarding. The process of sharing information about networks and routes
to networks is called routing. Routers and routing eliminate the concept of
one single, large, and very busy worldwide network.

Purpose of Routing
Routing is one of the important functions of the Internet layer in the
TCP/IP network model. This function is primarily supported by IP. An IP
router connects two or more networks and forwards IP datagrams
between them. An IP router can forward IP datagrams based on the
information in the IP header and information obtained from its routing
table. Figure 7-2 shows the layer in the TCP/IP network model in which
routing takes place.

TCP/IP Layers

Application Layer

Transport Layer

Internet Layer

Network Interface Layer

Hardware Layer

Figure 7-2 TCP/IP Network Model

Configuring Routing 7-3

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Identifying the Fundamentals of Routing

Types of Routes
Routes can be dividing in to two types: direct routes and indirect routes.

A direct route is a route in which the destination system is on the same

local network as the source system. The source system can send the IP
datagram to the destination system without any involvement from
another system. This activity could be thought of as direct delivery of a
datagram because no routers are required to complete the transaction.

An indirect route is a route in which the destination system is not on the

same local network as the source system. The IP datagram is sent through
one or more routers or gateways on its way to the destination. Because the
delivery of the datagram is not direct and other systems are involved in
the delivery, this is called an indirect route.

Note – A router connects two networks running the same protocol stack.
A gateway connects two networks running different protocol stacks.

7-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Identifying the Fundamentals of Routing

Figure 7-3 shows an example of direct and indirect routes. The sys11
system has a direct route to the sys13 system and an indirect route to the
sys24 system through the sys21 router.
192.168.1.0 192.168.30.0 192.168.4.0

sys11
instructor

sys12
sys21

sys13 sys24

Direct Route
Indirect Route

Figure 7-3 Direct and Indirect Routes

Configuring Routing 7-5

Introducing the Routing Table

The Solaris OS kernel uses a random access memory-based (RAM-based)
table, called the routing table, to store information needed to deliver IP
datagrams to their destinations. This table is populated with either static
or dynamic entries.

Static Routes
Static routes are permanent entries in the routing table. Static routes can
be removed through manual intervention only. The most common static
entries are the direct routes that a system creates to its local networks.

The ifconfig command updates the routing table with static entries for
networks that are directly connected to the local network interfaces when
an interface is configured as up. Therefore, even in single-user mode, a
system can route directly to its local network or networks because the
interfaces are initialized by the ifconfig command.

Static routes can also be added to your system’s routing table manually by
using the /etc/defaultrouter file or by using entries placed in the
/etc/gateways file. The /etc/defaultrouter file defines one or more
static default routes for a system. A default route defines the router to use
for all destinations that do not have an explicit routing table entry. The
/etc/gateways file is used to define static indirect routes to networks
and hosts.

7-6 Network Administration for the Solaris™ 10 Operating System

Dynamic Routes
Dynamic routes are added to or removed from the routing table by
processes, such as the in.routed daemons. When the routing table is
updated with information about other reachable networks, the router can
forward or deliver datagrams to these networks.

The svc:/network/initial SMF service enables routing. Routing in the

Solaris 10 OS is implemented by the in.routed daemon. The
in.routed daemon implements three routing protocols:
● Routing Information Protocol version 1 (RIPv1)
● Routing Information Protocol version 2 (RIPv2)
● ICMP Router Discovery Protocol

Routers advertise the networks that they know about. Other hosts and
routers listen to these periodic announcements and update their routing
table with the most current and correct information. Only those entries
calculated to be the best paths to a network destination remain in the
routing table.

Configuring Routing 7-7

Introducing Routing Protocol Types

A single routing protocol cannot efficiently handle all situations because
networks can be connected in many different ways. As a result, different
protocols were developed to manage routing in different areas of the
Internet.

Autonomous Systems
An autonomous system (AS), as shown in Figure 7-4, is a collection of
networks and routers under a single administrative control. This broad
definition was incorporated into the Internet in an attempt to reduce
excessively large routing tables.

Figure 7-4 Autonomous Systems

An autonomous system number is a unique 16-bit address that is assigned

by the Internet Corporation for Assigned Names and Numbers (ICANN).
The Internet can be considered to be a set of autonomous systems that are
connected together.

7-8 Network Administration for the Solaris™ 10 Operating System

Interior Gateway Protocols

Routing within an AS is managed by an Interior Gateway Protocol (IGP).
IGPs manage the sharing of routing information between networks in the
AS, and are also responsible for sharing information about any external
routes that the gateways (the routers which connect the AS to the rest of
the Internet) might be advertising to the networks in the AS.

Figure 7-5 shows how IGPs are used in networks.

IGP

AS IGP

Figure 7-5 Use of IGPs in Networks

Many routing protocols are designed to pass routing information within

an autonomous system. Two popular protocols are RIP and the Open
Shortest Path First (OSPF) Protocol.

RIP is a distance-vector protocol that exchanges route information

between IP routers. Distance-vector algorithms obtain their name from the
fact that they compute the least-cost path by using information that is
exchanged with other routers that describes reachable networks with their
distances, in the form of hop counts. There are two versions of RIP: RIPv1
and RIPv2.

Configuring Routing 7-9

OSPF is a link-state protocol. OSPF maintains a map of the network

topology instead of computing route paths that are based on distance
vectors in the way that RIP computes the route paths.

OSPF provides a view of the entire network and provides the shortest
path choices on routes. The map on each OSPF router is updated
regularly.

Exterior Gateway Protocols

An Exterior Gateway Protocol (EGP) is a routing protocol used to forward
packets between autonomous systems.

EGPs are used between organizations or sites, for example in a large

WAN, such as the Internet or a large corporation’s intranet.

Figure 7-6 shows the role of EGPs in Internet routing.

AS
EGP

EGP

EGP
AS

Figure 7-6 Role of EGPs in Internet Routing

EGP and the Border Gateway Protocol (BGP) are the two principal
protocols that exchange routing information among autonomous systems.

7-10 Network Administration for the Solaris™ 10 Operating System

EGP was developed in the early 1980s. The concept of an autonomous

system developed out of the research and development of EGP.

BGP was developed in the mid 1990s to replace EGP. BGP replaces the
distance-vector algorithm of EGP with a path-vector algorithm. The path
vector that is implemented by BGP causes the routing information to
include a complete path (all autonomous system numbers) from the
source to the destination. This eliminates the possibility of looping
problems that might arise from complex network topologies, such as the
Internet. A loop is detected by BGP when the path it receives has an
autonomous system listed twice. If this occurs, BGP generates an error
condition.

Configuring Routing 7-11

Working With the Routing Table

A system’s routing table is used to store routing information for the
system. The routing table is referenced when a path to another computer
is required. The routing table is often interrogated when you troubleshoot
connectivity issues.

Displaying the Routing Table

To display the contents of a system’s routing table without interpreting
the names of the systems, use the netstat command with the -r and -n
options. The -r option causes the routing table to be displayed. The -n
option causes the IP addresses to be displayed instead of resolving them
to names. For example:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 192.168.1.1 U 1 51 hme0
192.168.30.0 192.168.30.31 U 1 54 qfe0
224.0.0.0 192.168.1.1 U 1 0 hme0
127.0.0.1 127.0.0.1 UH 37 132 lo0
#

7-12 Network Administration for the Solaris™ 10 Operating System

Introducing Routing Table Information

Table 7-1 describes the output from the netstat -rn command.

Table 7-1 Routing Table Entries

Field Description

Destination The destination network or host address. This entry can

also contain the keyword default to represent a
default route.
Gateway The system that delivers or forwards the datagram.
Flags The status of this route. This field uses the following
flags:
● U – The interface is up.
● H – Host route. The destination is a system, not a
network.
● G – The delivery system is another system (an
indirect route).
● D – The entry was added dynamically by an
ICMP redirect.
Ref The current number of routes that share the same
network interface (Ethernet) address.
Use The number of datagrams that have used this route. For
the localhost entry, it is a snapshot of the number of
datagrams that are received.
Interface The local interface used to reach the destination.

Configuring Routing 7-13

Searching the Routing Table

Figure 7-7 shows the kernel routing algorithm.

Extract the destination

IP address, and compute the
network number.

Encapsulate the datagram

Does the by setting the destination
Ethernet address to that
destination IP address Yes of the router associated
match a host-specific route with the host route table
in the route entry. Deliver the
table? frame through the interface
connected to the system.

Encapsulate the datagram

by setting the destination
Does the Ethernet address to that
network number match Yes of the router associated
one found in the with the route table
route table? entry. Deliver the
frame through the interface
connected to the system.

Encapsulate the datagram

by setting the destination
Is there Ethernet address to that
Yes of the default router found
a default entry in
the route table? in the route table.
Deliver the packet through
the interface frame
connected to the system.

Generate a routing error

message through ICMP

Figure 7-7 The kernel Routing Algorithm

7-14 Network Administration for the Solaris™ 10 Operating System

The kernel routing algorithm searches for routing table entries in the
following order when determining where to send a datagram:
1. The kernel routing algorithm checks to see if the IP address is on a
local network.
The kernel extracts the destination IP address from the IP datagram
and computes the destination network number. The destination
network number is then compared with the network numbers of all
of the local interfaces (interfaces that are physically attached to the
system) for a match. If the destination network number matches that
of a local interface network number, the kernel encapsulates the IP
datagram inside an Ethernet frame and sends it through the
matching local interface for delivery.
2. The kernel routing algorithm checks the routing table for a route to
a matching host IP address on a non-local network.
The kernel searches the routing table entries for a matching host IP
address. If an entry that matches the host IP address is found, the
kernel encapsulates the IP datagram inside an Ethernet frame and
sends the frame to the router that is associated with that destination.
3. The kernel routing algorithm checks the routing table for a route to
a matching network number.
The kernel searches the routing table for a matching network
number. If a matching number is found, the kernel sets the
destination Ethernet address to that of the corresponding router and
delivers the frame to that router. The router that receives the frame
repeats the execution of the route algorithm, but leaves the
destination IP address unchanged.
4. The kernel routing algorithm checks for a default route in the
routing table.
The kernel searches the routing table for a default entry, which
signifies that a default route is configured. If a default route is found,
the kernel encapsulates the datagram, sets the destination Ethernet
address to that of the default router, leaves the destination IP address
unchanged, and delivers the datagram through the interface that is
local to the default router.
5. If there is no route to the destination, the kernel routing algorithm
check generates an ICMP error message. The kernel cannot forward
the datagram. The error message states either No route to host
or Network is unreachable.

Configuring Routing 7-15

Associating Names and Network Numbers

The netstat -rn command displays the routing table without resolving
any of the IP addresses in the routing table to names. If the netstat -r
command is used instead, the netstat command attempts to resolve IP
addresses to names, and displays the names instead of the numbers.

IP addresses and host names are associated by using the

/etc/inet/hosts file. An equivalent file for associating network names
and numbers also exists: the /etc/inet/networks file. The
/etc/networks file is a symbolic link to the /etc/inet/networks
file.

The fields in the /etc/inet/networks file are organized by network

name, network number, and nicknames. For example:
# cat /etc/inet/networks
#ident "@(#)networks 1.4 92/07/14 SMI" /* SVr4.0 1.1 */
#
# The networks file associates Internet Protocol (IP) network numbers
# with network names. The format of this file is:
#
# network-name network-number nicnames . . .
#

#
# The loopback network is used only for intra-machine communication
#
loopback 127

#
# Internet networks
#
arpanet 10 arpa # Historical

one 192.168.1 one

two 192.168.2 two
three 192.168.3 three
thirty 192.168.30 thirty
#

When the /etc/inet/networks file is modified, you can use the defined
network name in a command instead of a network address.

7-16 Network Administration for the Solaris™ 10 Operating System

To view how defined networks are displayed in the output from the
netstat command, use the netstat command with the -r option:
# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
one sys11 U 1 53 hme0
two sys11ext UG 1 0
three sys11ext UG 1 0
thirty sys11ext U 1 56 qfe0
224.0.0.0 sys11 U 1 0 hme0
localhost localhost UH 3 132 lo0
#

Observe that the destination networks are now displayed by name instead
of by network number, and the loopback address is replaced by its entry
from the /etc/inet/hosts file.

Configuring Routing 7-17

Configuring Static Routes

You can configure a route that does not change or time-out. This type of
route is called a static route. Static routes are not removed from the
routing table by the system.

Configuring Static Direct Routes

Static direct routes are routes to local networks which do not expire from
the routing table. A static direct route is added to a network when a
network interface is configured as up by the ifconfig command.

The ifconfig command builds the direct route entries initially when the
network interface is configured during system startup. To view the static
direct routes configured by the ifconfig command, use the
netstat -rn command:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 192.168.1.1 U 1 53 hme0
...
...
192.168.30.0 192.168.30.31 U 1 77 qfe0
224.0.0.0 192.168.1.1 U 1 0 hme0
127.0.0.1 127.0.0.1 UH 3 132 lo0
#

The 127.0.0.1 entry in the routing table is a loopback route to the local
host that is created when the lo0 pseudo interface is configured.

7-18 Network Administration for the Solaris™ 10 Operating System

Configuring the /etc/defaultrouter File

Default routes are routing table entries that define the default routers to
use if no specific host or network routes are available. Default route
entries can be either static entries or dynamic entries. The
/etc/defaultrouter file is used to define static default routes. Default
routes mean that you do not need to define every reachable network
because datagrams that are addressed to non-local destinations use a
default router in the absence of an explicit route.

You can define default routers by creating entries in the

/etc/defaultrouter file, which lists the host names or IP addresses of
the default routers. You must use host names that exist in the system’s
/etc/inet/hosts file because no name-resolution services are available
at the time that this file is read at system boot. A system that is configured
with an /etc/defaultrouter file does not execute the in.routed
daemon.

Some advantages of default routing are:

● The /etc/defaultrouter file prevents unneeded routing processes
from starting.
● The default entries result in a smaller routing table, which reduces
the processing time spent on each IP datagram.
● Multiple default routers can be identified, which eliminate single
points-of-failure within a network.
● Systems that use default route entries do not depend on actual
routing protocols.

Some disadvantages of default routing are:

● The default entries created by the /etc/defaultrouter file are
always present, even when the default router is not available. The
system does not learn about other possible routes.
● All systems must have a local /etc/defaultrouter file configured
properly because this file cannot be administered by a name service.
This can be an administrative problem on large, evolving networks.

Configuring Routing 7-19

Configuring the /etc/gateways File

The /etc/gateways file, if it exists, is read by the in.routed daemon
when the daemon starts. The in.routed daemon uses the contents of the
/etc/gateways file to add additional static routes to the routing table.
Static route entries in the /etc/gateways file use the format:
net|host destination gateway gateway metric hops [passive|active|extern]

For example:
# cat /etc/gateways
net 192.168.3.0 gateway sys31ext metric 1
#

Note – It is a better practice to use IP addresses rather than the host

names because it might not be possible to resolve host names.

The /etc/gateways file also supports the use of directives to control the
behavior of the system. For example, you can disable the RIP protocols
(RIPv1 and RIPv2) by placing the following directive in the
/etc/gateways file:
no_rip

Use the no_rip_v1in directive when you want your system to ignore
RIPv1 information received on a specific interface. For example, to ignore
RIPv1 information received on the qfe3 interface, use the following
directive in the /etc/gateways file:
no_ripv1_in if=qfe3

You can disable the RDISC protocol by placing the following directive in
the /etc/gateways file:
no_rdisc

Refer to the gateways man page for more information on the

/etc/gateways file.

7-20 Network Administration for the Solaris™ 10 Operating System

Configuring Static Routes on the Command Line

The route command enables manual manipulation of the routing table.
The route command can be used to add, remove, and change routing
table entries. The route command uses sub-commands to perform its
tasks.

To add routes to the routing table, you use the route add command. Its
basic format is:
route add destination gateway

The destination can be a host, a network, or a default route. For example,

to add a static route to the 192.168.3.0 network with the sys31ext
system as the gateway, type the command:
# route add net 192.168.3.0 sys31ext
add net 192.168.3.0: gateway sys31ext
#

To add a static route to the sys24 host with the sys21ext system as the
gateway, type the command:
# route add host sys24 sys21ext
add host sys24: gateway sys21ext
#

To add a default route with the instructor system as its gateway, type
the command:
# route add default instructor
add default: gateway instructor
#

To delete a route, you use the route delete command. Its basic format
is:
route delete destination gateway

For example, to delete the route to the host sys24 using the gateway
sys21ext, type the command:
# route delete sys24 sys21ext
delete host sys24: gateway sys21ext
#

Configuring Routing 7-21

To retrieve information about a specific route, use the route get

command. For example, to retrieve information about the default route,
type the following command:
# route get default
route to: default
destination: default
mask: default
gateway: instructor
interface: hme0
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,ms rttvar,ms hopcount mtu expire
0 0 0 0 0 0 1500 0
#

To change the routing table, use the route change command. For
example, to change the default route from instructor to sys41, type a
command similar to the following:
# route change default sys41
change net default: gateway sys41
#

To continuously report any changes to the routing table, route look-up

misses, or suspected network partitionings, use the route monitor
command. For example, when a route is deleted, to receive the following
output, type the route monitor command:
# route monitor
got message of size 124
RTM_DELETE: Delete Route: len 124, pid: 633, seq 1, errno 0,
flags:<UP,GATEWAY,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
192.168.3.0 sys11ext 255.255.255.0

To flush (remove) the routing table of all gateway entries, use the
route flush command. For example:
# route flush
192.168.9 sys13 done
two sys13 done
two sys11ext done
default 172.20.4.248 done
#

7-22 Network Administration for the Solaris™ 10 Operating System

To cause the routing table to flush before the remaining options are
evaluated, use the flush option in combination with other options. For
example, to flush the routing table of gateways and to add a route to the
192.168.2.0 network, type a command similar to the following:
# route -f add net 192.168.2.0 sys21ext
add net 192.168.2.0: gateway sys21ext
#

To add a route manually to the multicast address range of 224–239, type

the command:
# route add 224.0/4 ‘uname -n‘

Note – You can find the command syntax in the

/lib/svc/method/net-svc SMF method file.

To define a route that uses a specific netmask to support a network, use

the -netmask option with the route command. For example, to add a
route to the 192.168.3.0 network that uses a netmask of
255.255.255.224, type the command:
# route add net 192.168.3.0 sys31ext -netmask 255.255.255.224
add net 192.168.3.0: gateway sys31ext
#

To achieve the same results in a more concise way, specify the length of
the subnet mask after the destination. For example, enter:
192.168.3.0/27

The 255.255.255.224 netmask for the 192.168.3.0 network is

11111111.11111111.11111111.11100000 in binary format. There are
27 ones (1s) in the binary netmask, hence the /27 after the network
address. A command similar to the following is identical to the command
in the preceding example:
# route add net 192.168.3.0/27 sys31ext
add net 192.168.3.0/27: gateway sys31ext
#

Configuring Routing 7-23

Note – The in.routed process does not detect any routing table changes
that are performed by other programs on the machine, for example, routes
that are added, deleted, or flushed as a result of the route command.
Therefore, do not perform these types of changes while the in.routed
process is running. Instead, shut down the in.routed process, make the
required changes, and then restart the in.routed process. This ensures
that the in.routed process learns of any changes.

Network names can also be used to define routes. To add a route to the
two network, defined in the /etc/inet/networks file, type a command
similar to the following:
# route add net two 192.168.30.31
add net two: gateway 192.168.30.31
#

Note – Use of the metric argument in the route command is no longer

supported.

7-24 Network Administration for the Solaris™ 10 Operating System

Configuring Dynamic Routing

RIP is a routing protocol that is used commonly on computer systems to
provide dynamic routing. RIPv1 and RIPv2 are bundled with the
Solaris 10 OS. RIP is an Application layer protocol.

RIP Version 1
RIP version 1 is a distance-vector protocol that exchanges route
information between IP routers. RIP version 1 does not support VLSM or
CIDR.

Distance-Vector Protocols

Distance-vector algorithms compute the least-cost path of a route by using

information that is exchanged with other routers. This information
describes how far away (in distance) reachable networks are from the
sending or receiving system. This distance is measured by a metric known
as a hop. The total number of hops is called the hop count. The efficiency
of a route is determined by its distance from the source to the destination.
RIP maintains only the best route to a destination. When multiple paths to
a destination exist, only the first path with the lowest hop count is
maintained. Figure 7-8 shows the least hop count between a source host
and a destination host.
Metric = 1
(propagated to route tables)

Router

Router Router

Source Destination
Host Host
Metric = 2
(discarded)

Figure 7-8 Least Hop Count

RIP specifies a number of features that make its operation more stable in
the face of rapid network topology changes. These stability features
include a hop-count limit, hold-down states, split horizons, triggered
updates, and route poisoning.

Configuring Routing 7-25

Hop-Count Limits

RIP permits a maximum hop count of 15. A destination greater than

15 hops away is tagged as unreachable. The maximum hop count of RIP
greatly restricts its use in large networks but prevents a problem called
count to infinity from causing endless network routing loops.

This upper limit of 15 does not cause problems since RIP is an IGP and is
used within autonomous systems only.

Hold-Down States

Hold-down states prevent regular update messages from inappropriately

reinstating a route that has gone bad. When a route goes down,
neighboring routers detect this condition. These routers then calculate
new routes and send route update messages to inform their neighbors of
the route change. This activity begins a wave of route updates that filter
through the network. These updates do not instantly arrive at every
network device. It is possible that a device that has yet to be informed of
a network failure can send a regular update message (indicating that a
route that has just gone down is still available) to a device that has just
been notified of the network failure. In this case, the latter device now
contains (and potentially advertises) incorrect route information.

Hold-down states tell routers to hold down any changes that can affect
recently removed routes for a specified period of time. The hold-down
period is usually calculated to be just greater than the period of time that
is necessary to update the entire network with a route change.

Split Horizons

Split horizons derive from the fact that it is never useful to send
information about a route back in the direction from which it came. The
split-horizon rule prohibits this from happening. This helps prevent
two-node routing loops.

Triggered Updates

Triggered updates propagate changing route information quickly

throughout the network. As the router becomes aware that new routes are
available or that existing routes are not available, it advertises this
information immediately rather than waiting until the next 30-second
(default) advertisement interval occurs.

7-26 Network Administration for the Solaris™ 10 Operating System

Route Poisoning

When a router learns that a destination is no longer available, it issues a

triggered update for that destination. This update includes a hop-count
advertisement of 16. All other hosts and routers consider the destination
as unreachable, and the hosts and routers remove the route entry. This is
to ensure that other systems do not attempt to use the bad route.

RIP Version 2
RIP version 2 was developed to address some of the limitations of RIPv1,
while maintaining backward compatibility combined with the simplicity
of RIPv1. RIPv2 has the following characteristics:
● RIPv2 supports VLSM and non-byte-bounded subnet masks.
● RIPv2 uses muticast to advertise routes. The 224.0.0.9 multicast
address is reserved for RIPv2.
● RIPv2 includes support for simple authentication of messages.

Note – RIP version 2 is defined in RFC 2453.

Configuring Routing 7-27

The in.routed Daemon

RIPv1 and RIPv2 are implemented by the /usr/sbin/in.routed
daemon. The /usr/sbin/in.routed daemon causes a system to
broadcast its own routing information if IP forwarding and IP routing are
enabled by the routeadm command. A router sends routing information
to the networks to which it is directly connected every 30 seconds. You
cannot change this time interval.

If RIPv2 multicasts are being processed, only those hosts listening for the
RIPv2 multicast address process the information. If RIPv1 broadcasts are
being processed, all hosts receive the information, but only those hosts
that run the in.routed daemon use the information. Routers and
non-routers run the in.routed daemon.

The in.routed daemon is started at boot time if the ipv4-routing

option is specifically enabled by using the routeadm command, or if the
/etc/defaultrouter file is empty or does not exist.

Stopping and Starting the in.routed Daemon

The in.routed daemon can be stopped and started on the command

line by using the routeadm command. The routeadm command is used
to control whether a system runs the in.routed routing daemon and
whether a system forwards IP packets between networks.

To view the current configuration, type the routeadm command with no

arguments:
# routeadm
Configuration Current Current
Option Configuration System State

IPv4 forwarding default (disabled) disabled

IPv4 routing default (enabled) enabled
IPv6 forwarding default (disabled) disabled
IPv6 routing default (disabled) disabled

IPv4 routing daemon "/usr/sbin/in.routed"

IPv4 routing daemon args ""
IPv4 routing daemon stop "kill -TERM ‘cat /var/tmp/in.routed.pid‘"
IPv6 routing daemon "/usr/lib/inet/in.ripngd"
IPv6 routing daemon args "-s"
IPv6 routing daemon stop "kill -TERM ‘cat /var/tmp/in.ripngd.pid‘"
#

7-28 Network Administration for the Solaris™ 10 Operating System

To stop the in.routed daemon, type the command:

# routeadm -u -d ipv4-routing
#

To start the in.routed daemon, type the command:

# routeadm -u -e ipv4-routing
#

The -d option changes the contents of the /etc/inet/routing.conf

file to list the argument as disabled explicitly. The -e option changes the
contents of the /etc/inet/routing.conf file to list the argument as
enabled explicitly. The -u option updates the system’s current
configuration by using the contents of the /etc/inet/routing.conf
file.

Note – Using the routeadm command without the -u option causes the
configuration to be changed in the /etc/inet/routing.conf file, but
does not change the current configuration of the system.

To cause the system to revert to default behavior at system boot (start the
in.routed daemon unless the /etc/defaultrouter file is not
empty), type the command:
# routeadm -r ipv4-routing
#

Configuring Routing 7-29

The RDISC Protocol

The RDISC Protocol sends and receives router advertisement messages
pertaining to default routes. RFC 1256 specifies the format of related
ICMP messages. The in.routed daemon implements the RDISC Protocol.

Routers that run the in.routed daemon advertise their presence by using
the 224.0.0.1 multicast address every 600 seconds (10 minutes).
Non-routers running the in.routed daemon listen to the 224.0.0.1
multicast address for these router advertisement messages. The
in.routed process builds a default route entry for each router from
which an advertisement is received.

Some advantages of the RDISC Protocol are that it:

● Is independent of routing protocol
● Uses a multicast address
● Results in small routing tables
● Provides redundancy through multiple default-route entries

Note – The RDISC Protocol was previously implemented by using the

in.rdisc daemon. While the in.rdisc daemon is still present in the
Solaris 10 OS, it is no longer started at system boot. In the Solaris 10 OS,
the in.routed daemon has been enhanced to include equivalent route
discovery funtionality.

Some disadvantages of the RDISC protocol are:

● An advertisement period of 10 minutes can result in a black hole. A
black hole is the time period in which a router path is present in the
table, but the router is not actually available. The default lifetime for
a non-advertised route is 30 minutes (three times the advertising
time interval).
● Routers must still run a routing protocol, such as RIP, to learn about
other networks. The RDISC protocol provides a default route from
hosts to routers, not between routers.

The behavior of the RDISC protocol can be controlled by entries in the

/etc/gateways file. For example, to change the advertisement interval
to 100 seconds, create the entry:
rdisc_interval=100

7-30 Network Administration for the Solaris™ 10 Operating System

ICMP Redirects
ICMP provides control and error messages. ICMP on a router or gateway
attempts to send reports of problems to the original source if an IP
datagram cannot be delivered for some reason. ICMP datagrams are
always encapsulated in IP.

ICMP redirects occur when a system uses more than one default route. If
the router determines a more efficient route, or if there is only one way to
forward the datagram, it redirects the datagram using the better or only
route and reports that route to the sender. Figure 7-9 on page 7-32 shows
an ICMP redirect process where the sys21 system needs to communicate
with the server1 system and has a default route of sys11. The
information does reach the server1 system and the sys11 system sends
an ICMP redirect to the sys21 system, telling it that the best route to the
server1 system is through the instructor system.

The sending system’s routing table is updated with the new information.
The drawback to this method of routing is that for every ICMP redirect,
there is a separate entry in the sending system’s routing table. This action
can lead to a large routing table. However, this method of routing also
ensures that the datagrams that are going to all reachable hosts are taking
the shortest route.

Caution – An attacker might forge redirect errors to install false routes,

which might initiate a denial of service attack if the newly specified router
is not a router at all. There are rules governing valid redirect errors, all of
which can be spoofed easily. Use this ndd command to ignore IPv4 ICMP
redirect errors: ndd -set /dev/ip ip_ignore_redirect 1.
Refer to the Sun BluePrints™ document Solaris Operating Environment
Network Settings for Security, available at:
http://www.sun.com/solutions/blueprints/1200/
network-updt1.pdf.

Configuring Routing 7-31

server1

4 Datagram

5 Datagram

#telnet server1

sys21 instructor

3 ICMP Redirect

1 Datagram
2 Datagram

sys11

Figure 7-9 ICMP Redirect

7-32 Network Administration for the Solaris™ 10 Operating System

Introducing CIDR
The rapid growth of the Internet in the early 1990s created concerns about
the ability to scale and support future growth. The most severe problems
are:
● Impending depletion of Class B networks
● Increasing the size of routing tables

Depletion of Class B networks creates a problem for large organizations

because Class C addresses with 254 as their maximum number of host
addresses are not large enough. Assigning multiple Class C networks to
companies will, over time, dramatically increase the number of routes in
the routing table. Large routing tables cause poor router performance
because the router spends excessive time performing address lookups.

Purpose of CIDR
A task force was created by the Internet Engineering Task Force (IETF) to
develop a solution to the scale and growth problems. The solution became
known as CIDR, or supernetting, and is a way to make more-efficient use
of the IP address space. CIDR is documented in RFC 1517, RFC 1518,
RFC 1519, and RFC 1520. Three important features of CIDR that address
scalability and growth issues for the Internet are:
● Elimination of network classes (Class A, Class B, and Class C)
● Block address allocation
● Hierarchical routing

Operation of CIDR
CIDR uses classless addresses. Netmasks are referred to as network prefixes
and are used to create networks of varying sizes. The network prefix is
expressed in the following notation: X.X.X.X/Y. The value Y is an integer
value that specifies the number of 1s in the netmask. For example, using
/18 is equivalent to a netmask of 255.255.192.0. The first 18 bits
identify the network, and the remaining 14 bits identify the host.

Configuring Routing 7-33

Figure 7-10 shows an example of a CIDR prefix.

Evolution of Routing Protocols

Classful Routing Protocols
Network Route 10nnnnnn.nnnnnnnn.00000000.00000000
Subnet Route 10nnnnnn.nnnnnnnn.ssssssss.ss0000000
Host Route 10nnnnnn.nnnnnnnn.ssssssss.sshhhhhhh

Classless Routing Protocols

pppppppp.pppppppp.pp000000.00000000
Prefix Route
Prefix Length

n = Network
s = Subnet
h = Host

Figure 7-10 CIDR Prefix

This use of variable length subnet masks means making efficient use of
network address space by supernetting or subnetting.

Supernetting is the combining of two or more contiguous network

addresses. For example, 192.168.2/24
(11000000.10101000.00000010, 0xffffff00, or 255.255.255.0)
and
192.168.3/24 (11000000.10101000.00000011, 0xffffff00, or 255.255.255.0) can
be supernetted by using a prefix of /23
(11000000.10101000.0000001X, 0xfffffe00, or 255.255.254.0).

The systems on the supernetted networks must all use the following in
order to properly communicate without a router:
● Network address – 192.168.2.0/23
● Broadcast address – 192.168.3.255

Valid host addresses for this supernetted network range from

192.168.2.1–192.168.3.254 (510 addresses). The 192.168.2.255 and
192.168.3.0 addresses are valid host addresses, but they are not used in
the Solaris 10 OS.

7-34 Network Administration for the Solaris™ 10 Operating System

Following is an example that configures an interface on this supernetted

network:
# ifconfig eri0 plumb 192.168.3.239/23 broadcast + up
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.3.239 netmask fffffe00 broadcast 192.168.3.255
ether 0:3:ba:2a:9d:7a

# netstat -rnv
IRE Table: IPv4
Destination Mask Gateway Device Mxfrg Rtt Ref Flg Out In/Fwd
--------------- --------------- --------------- ------ ----- ---- --- --- ---- ------
172.20.221.6 255.255.255.255 192.168.2.254 1500* 0 1 UGH 0 0
192.168.2.0 255.255.254.0 192.168.3.239 eri0 1500* 0 1 U 0 0
127.0.0.1 255.255.255.255 127.0.0.1 lo0 8232* 0 1 UH 10 0
#

A CIDR and VLSM aware routing protocol, such as RIPv2, must be used
on the router that connects this supernetted network to other networks.

Subnetting is the application of a netmask on an IP address to divide the

network up into smaller pieces.

CIDR and VLSM permit a portion of the IP address space to be divided

into successively smaller pieces. For example, an Internet service provider
(ISP) could be allocated blocks of address space, which they then assign in
subset address blocks to smaller ISPs. These smaller ISPs can then supply
an even smaller subset of addresses to a customer or private organization.
CIDR and VLSM make this aggregation and subdivision of address space
possible.

The routing table entry for each ISP or organization reflects the first
address in the block assigned to it, for example, 204.106.8.0/22, even
though there can be additional network addresses that are associated with
the block. A range of CIDR addresses is known as a CIDR block. This
support of network addresses eliminates the number of entries required in
the backbone routing tables.

Configuring Routing 7-35

Consider an ISP that requires IP addresses for 1000 clients. Based on

254 clients per Class C network, the ISP requires four Class C networks.
You can supernet four Class C networks, for example:
● 204.106.8.0
● 204.106.9.0
● 204.106.10.0
● 204.106.11.0

Figure 7-11 shows the network addresses that can result from applying
different network prefixes.

Figure 7-11 CIDR Network Addresses

It can be seen from Figure 7-11 that the four networks being considered
have identical values in their first 22 bits. Therefore, if you consider the
first 22 bits only of an address on any of these networks to represent the
network portion of the address, every address on the four networks has
the same network address. The networks can therefore be supernetted
and a single route can be used to reach all four networks.

7-36 Network Administration for the Solaris™ 10 Operating System

Figure 7-12 shows an example of supernetting.

204.106.0.0/21
Internet Service Provider (2048 Host Addresses)

204.106.0.0/16 Address Range

(65,536 Host Addresses) 204.106.0.0204.106.7.0

Internet
204.106.8.0/22
(1024 Host Addresses)
204.106.0.0/20
(4096 Host Addresses) Address Range
204.106.8.0204.106.11.0

Figure 7-12 Supernetting Example

An ISP who is given a block of supernetted addresses can then divide the
range into different sized blocks to suit the needs of their customers, while
minimizing the number of routing table entries required.

Configuring Routing 7-37

Configuring Routing at Boot Time

The behavior of a Solaris 10 system in regard to route configuration is
different to previous versions of the Solaris OS.

The /etc/inet/routing.conf file contains two options regarding

route configuration on a Solaris 10 system: ipv4-routing and
ipv4-forwarding. The ipv4-routing option refers to whether a
system will start the in.routed daemon. The ipv4-forwarding
option refers to whether a system will be configured to forward packets
between networks.

Initializing a Router
When a system boots, the system first checks the contents of the
/etc/inet/routing.conf file. If the ipv4-routing or
ipv4-forwarding options are set explicitly to either enabled or
disabled, the setting is applied. If either option has not been set
explicitly, then the system determines whether or not to enable or disable
each option.

IPv4 routing is disabled if the /etc/defaultrouter file is not empty. If

the /etc/defaultrouter file is not present, or is empty, IPv4 routing is
enabled (the in.routed daemon is started).

IPv4 forwarding is disabled by default and must be enabled explicitly by

using the routeadm command.

7-38 Network Administration for the Solaris™ 10 Operating System

Figure 7-13 shows how the /lib/svc/method/net-init method

configures a system for IPv4 forwarding and routing.

Start

Disable
IPv4 forwarding

Does Yes Disable

/etc/defaultrouter
exist? IPv4 routing

IPv4 routing Yes Enable

enabled by
routeadm? IPv4 routing

Disable
IPv4 routing

IPv4
forwarding Yes Enable
enabled by IPv4 forwarding
routeadm?

Disable
IPv4 forwarding

End

Figure 7-13 IPv4 Router Initialization

Configuring Routing 7-39

Configuring a Router Without Rebooting

To configure a Solaris OS system as a router without rebooting, complete
the following steps:
1. Verify that the /etc/hostname.interface and the
/etc/inet/hosts files are configured properly.
2. Do one of the following:
● Turn on IP forwarding on all of the interfaces:
# routeadm -u -e ipv4-forwarding
● Turn on IP forwarding for specific interfaces:
# ifconfig specific_interface router
3. Stop and restart the in.routed daemon:
# routeadm -u -d ipv4-routing
# routeadm -u -e ipv4-routing
#

The system now functions as a router.

Initializing a Multihomed Host

A multihomed host is a system with two or more physical network
interfaces that does not forward IP datagrams between the networks to
which it is attached. In the Solaris 10 OS, all systems with two or more
physical network interfaces are multihomed hosts by default.

To create a multihomed host, complete the following steps:

1. Become a superuser on the prospective multihomed system.
2. Create an /etc/hostname.interface file for each additional
network interface that is installed in the system. For example, if the
qfe2 interface is to be enabled and known on the network, you
create the /etc/hostname.qfe2 file, containing contents similar to
the following:
# cat /etc/hostname.qfe2
sample-hostname-for-qfe2
#
This causes the interfaces to be configured by the SMF methods at
boot time.

7-40 Network Administration for the Solaris™ 10 Operating System

3. Add an entry to the /etc/inet/hosts file so that the interface can

be assigned an IP address at boot time. The entry looks similar to the
following:
# grep sample /etc/inet/hosts
192.168.19.1 sample-hostname-for-qfe2
#
4. Do either of the two following procedures:
● Reboot the system with the init 6 command.
● Complete the following steps to enable the configuration
without rebooting:
1. Use the ifconfig command to configure the new interface
as appropriate, but do not enable the interface at this stage:
# ifconfig qfe2 plumb 192.168.19.1 netmask + broadcast +
#
2. Use the routeadm command to disable IP forwarding
explicitly:
# routeadm -u -d ipv4_forwarding
#
3. Use the ifconfig command to enable the interface:
# ifconfig qfe2 up
#

The system is now a multihomed host that has connectivity to more than
one network and can be used without concern of advertising routes and
potentially causing routing issues on any of the networks to which it
belongs.

Initializing a Non-Router
Disabling IP forwarding stops a router from forwarding packets between
the networks to which it is connected. To initialize a non-router, use the
routeadm command to disable IP forwarding on all interfaces by typing
the following command:
# routeadm -u -d ipv4_forwarding

Configuring Routing 7-41

Troubleshooting Routing
One of the most challenging tasks that a network administrator has to
perform is troubleshooting routing. Router configuration and
troubleshooting relies on mastering other basic network skills.

Troubleshooting the Router Configuration

When troubleshooting a problem, verify the following:
● The device information tree recognizes the additional interfaces. Use
the prtconf command, and search for the interface with the grep
command. For example, to determine if the qfe interface is in the
device tree, use the following command:
# prtconf | grep qfe
SUNW,qfe, instance #0
SUNW,qfe, instance #1
SUNW,qfe, instance #2
SUNW,qfe, instance #3
#
● The ifconfig command reports the interface to be configured as
expected. For example, to determine if the qfe0 interface is
configured as expected, use the following command:
# ifconfig qfe0
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:ac:9b:20
#
If the interface is up, examine the inet (IP address), netmask, and
broadcast entries, and make sure that they are set correctly. If the IP
address is set incorrectly, check the contents of the /etc/inet/hosts
file.
If the netmask and broadcast addresses are wrong, check the
contents of the /etc/inet/netmasks file.
● The correct device and file name are defined for the interface. For
example, if you are configuring the qfe0 interface, to verify that the
hostname.qfe0 file is correct, type the command:
# ls -al /etc/hostname.qfe0
-rw-r--r-- 1 root other 113 Nov 16 14:58 /etc/hostname.qfe0
#

7-42 Network Administration for the Solaris™ 10 Operating System

● The name that is assigned to the interface is correct. For example, to

determine if qfe0 has an assigned host name of sys11ext, type the
command:
# cat /etc/hostname.qfe0
sys11ext
#
● The name that is defined in the hostname.interface file exists in
the /etc/inet/hosts file and is associated with the correct address.
For example, to determine if sys11 has an assigned IP address of
192.168.1.1, type the command:
# grep sys11 /etc/inet/hosts
192.168.30.31 sys11ext
192.168.1.1 sys11 # Data address for hme0
192.168.1.21 sys11-data-qfe1 # Data address for qfe1
192.168.1.51 sys11-test-hme0 # qfe0:1 Test address for hme0
192.168.1.71 sys11-test-qfe1 # qfe1:1 Test address for qfe1
#

Configuring Routing 7-43

Troubleshooting Network Names

The netstat command, when used with the -r option, displays routing
table information. For example:
# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
three sys33ext UG 1 0
one sys11 U 1 189 hme0
two sys32ext UG 1 0
192.168.30.0 sys11ext U 1 175 qfe0
224.0.0.0 sys11 U 1 0 hme0
localhost localhost UH 3 132 lo0
#

Observe how some of the destinations have names instead of numbers.

This can lead to errors when you configure a new interface. To report
addresses as numbers instead of names, use the -n option with the
netstat command. For example:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.3.0 192.168.30.33 UG 1 0
192.168.1.0 192.168.1.1 U 1 191 hme0
192.168.2.0 192.168.30.32 UG 1 0
192.168.30.0 192.168.30.31 U 1 176 qfe0
224.0.0.0 192.168.1.1 U 1 0 hme0
127.0.0.1 127.0.0.1 UH 3 132 lo0
#

7-44 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Exercise: Reviewing Routing Configuration

In this exercise, you configure a Sun Microsystems workstation as a router
and use the route command to configure the system’s routing tables
manually. At times, you are instructed to work as a group on the system
that is your subnet’s router. Be sure to watch for prompts in the task steps
to ensure that you are working on the correct system.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Populate your system’s /etc/inet/hosts file with all of the hosts in the
class network if this is not already done. Your /etc/inet/hosts file
should have contents similar to the following:
# cat /etc/inet/hosts
#
# Internet host table
#
127.0.0.1 localhost loghost
# SA-300-S10 host information
192.168.30.31 sys11ext # router to get to instructor->Internet
192.168.1.1 sys11
192.168.1.2 sys12
192.168.1.3 sys13
192.168.1.4 sys14
#
192.168.30.32 sys21ext # router to get to instructor->Internet
192.168.2.1 sys21
192.168.2.2 sys22
192.168.2.3 sys23
192.168.2.4 sys24
#
192.168.30.33 sys31ext # router to get to instructor->Internet
192.168.3.1 sys31
192.168.3.2 sys32
192.168.3.3 sys33
192.168.3.4 sys34
#
192.168.30.30 instructor
#

Configuring Routing 7-45

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Caution – If your system is designated by the instructor as being a router,

verify that its second interface is not configured. If the interface is
configured, the command output will not match the solutions properly for
the exercises.

Figure 7-14 shows the classroom’s network diagram. Take a few moments
to familiarize yourself with the diagram.

instructor

xxx.xxx.xxx.xxx
Internet

.30
192.168.30.0
.31 .32 .33
192.168.1.0 192.168.2.0 192.168.3.0

.1 .1 .1
sys11 sys21 sys31

.2 .2 .2
sys12 sys22 sys32

.2 .3 .3
sys13 sys23 sys33

.4 .4 .4
sys14 sys24 sys34

Figure 7-14 Classroom Network Diagram

7-46 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Tasks
Complete the following steps:
1. In your own words, define each of the following routing schemes:
a. Static route
________________________________________________________
________________________________________________________
________________________________________________________
b. Dynamic route
________________________________________________________
________________________________________________________
________________________________________________________
c. Default route
________________________________________________________
________________________________________________________
________________________________________________________
2. What is a multihomed host?
_____________________________________________________________
_____________________________________________________________
3. Define the term autonomous system.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
4. In your own words, describe the differences between an interior
gateway protocol and an exterior gateway protocol.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
5. Give two examples of an interior gateway protocol.
_____________________________________________________________
_____________________________________________________________

Configuring Routing 7-47

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

6. Give two examples of an exterior gateway protocol.

_____________________________________________________________
_____________________________________________________________
7. Explain the purpose of ICMP redirects.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Subnet Group: Working on the Routers

8. Before making any changes to the interfaces, write the netmask and
broadcast values of the Ethernet interface.
Command used: ______________________________________________
Netmask: ____________________________________________________
Broadcast: ___________________________________________________

Caution – Do not proceed if your system has more than one physical
interface configured. If additional interfaces are configured, remove the
relevant /etc/hostname.interface files, and use the ifconfig
command or reboot the system to remove the interface configuration. The
success of this exercise depends on your system having only one
configured physical interface.

If the /etc/defaultrouter file or the /etc/gateways file exists on

your system:
1. Remove the file/s.
2. Reboot the system in order to restore it to a default state for this
exercise.

a. Which class of IPv4 address (A, B, or C) is assigned to your

system?
________________________________________________________
b. How many bits of your IPv4 address are currently being used
for your network address?
________________________________________________________

7-48 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

9. Use the netstat -r command to observe your current routing table.

Write down which route destinations are available.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
10. Use the netstat command with the -rn options. What is the
difference between this output and the previous netstat -r output?
_____________________________________________________________
11. Use the ps command to determine if the routing daemon is currently
running on the system.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Individually: Working on Non-Router Systems

12. Use the ps command to determine if the routing daemon is currently

running on the system.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Subnet Group: Working on the Routers

13. Configure the router for your subnet.

a. Create the /etc/hostname.interface file for your system’s
second interface, and place the host name in it so that the
second interface is configured automatically at boot time.
b. Verify that the name to be associated with the second interface
that is used in the /etc/hostname.interface file exists in the
/etc/inet/hosts file. If it does not, edit the /etc/inet/hosts
file, and place an appropriate name in the file.

Configuring Routing 7-49

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

14. Configure IP forwarding and IP routing for IPv4 to become enabled

on the next boot of the router.
Write the command that you use:
_____________________________________________________________

Note – Do not proceed beyond this point until everyone in the class has
completed this step.

15. Reboot the router.

Write the command that you use:
_____________________________________________________________
16. Verify that each router is correctly configured.
a. Display the configuration of each network interface.
How many external interfaces are configured and running
now?
________________________________________________________
b. Display the contents of the routing table.
Which network destinations are now available?
________________________________________________________
________________________________________________________
________________________________________________________
c. Determine that the routing daemon is running on the router.
________________________________________________________
________________________________________________________
________________________________________________________
What does this daemon do?
________________________________________________________
________________________________________________________
________________________________________________________

7-50 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Individually: Working on Non-Router Systems

If the /etc/defaultrouter file or the /etc/gateways file exists on

your system:
1. Remove the file/s.
2. Reboot the system in order to restore it to a default state for this
exercise.

17. Complete the following steps:

a. Determine if the routing daemon is running on each non-router
system.
________________________________________________________
________________________________________________________
Why is this daemon running?
________________________________________________________
________________________________________________________
b. Run the netstat -r command, and record the current network
destinations.
________________________________________________________
________________________________________________________
________________________________________________________
c. Run the ifconfig -a command, and record the current
netmask and broadcast values.
________________________________________________________
________________________________________________________
________________________________________________________

Configuring Routing 7-51

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Subnet Group: Working on Your Router System

18. Start the snoop utility on the router to watch for network traffic
associated with multicast address 224.0.0.2 as the non-routers
reboot. (Hint: Use the icmp option on the snoop command line.) Be
sure to use the snoop utility on the appropriate interface for the
network that you want to monitor. Be prepared to see ICMP router
advertisements after the next step.
Write the command that you use:
_____________________________________________________________

Individually: Working on Non-Router Systems

19. Reboot your non-router workstation.

Write the command that you use:
_____________________________________________________________

Subnet Group: Working on Your Router System

20. Observe the snoop output on the router system.

Individually: Working on Non-Router Systems

21. Use the netstat -r command, and observe the change to the
routing tables.
Which new type of entry is now present? How was it entered into
the routing table?
_____________________________________________________________
22. Use the ps command on the non-router systems to determine if the
routing daemon is now running.
Write the command that you use:
_____________________________________________________________
Why is this daemon running?
_____________________________________________________________

7-52 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Subnet Group: Working on Your Router System

23. Terminate the snoop trace that you had running, and then start a
verbose snoop trace in a separate window on your router system.
Write the command that you use:
_____________________________________________________________
24. Working in a new window, use the routeadm command to terminate
the in.routed process on the router.
Write the command that you use:
_____________________________________________________________
25. View the output from the snoop utility. Look for the router
notification when the in.routed daemon terminates gracefully.
Hint: Look for multicasts and ICMP messages.
a. Examine the snoop trace. Did you see the router notification
when the in.routed daemon terminated gracefully?
________________________________________________________
b. What was the ETHER destination, as reported by the snoop
trace?
________________________________________________________
c. What protocol did the router notification use?
________________________________________________________
d. What was the destination IP address of the router notification?
________________________________________________________
26. Verify that the process has been terminated.
Write the command that you use:
_____________________________________________________________

Individually: Working on Non-Router Systems

27. Use the netstat command to view the routing tables on one of the
non-router systems. What is missing?
_________________________________________________

Note – Do not proceed beyond this point until everyone in the class has
completed this step.

Configuring Routing 7-53

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Subnet Group: Working on Your Router System

28. Verify that the snoop session started earlier on your router is still
running, and then start the in.routed process on your router
system, changing the advertisement interval to 90 seconds by placing
the appropriate entry in the /etc/gateways file.
What entry do you place in the /etc/gateways file?
_____________________________________________________________
Which command do you use to restart the in.routed daemon?
_____________________________________________________________
Observe ICMP and other traffic as the in.routed daemon is started.

Individually: Working on Non-Router Systems

29. Use the netstat command to view the routing tables on one of the
non-router systems to verify that the default route has been inserted
into the routing table.
Write the command that you use:
_____________________________________________________________

In this section, you test to see how long it takes for the default route to be
removed when no communications are received from a router. You use
the 9 (KILL) signal to kill the in.routed daemon, so that the daemon
does not have a chance to advertise that it is going down.
30. On a non-router, use the date and netstat commands to determine
how long before the default route entry is removed.

Note – The while statement syntax assumes that you are using the
Bourne shell:
while true
> do date; netstat -rn | grep default; sleep 20
> done

7-54 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Subnet Group: Working on Your Router System

31. Simulate a router crash, and kill the in.routed daemon on the
router again, but use the 9 (KILL) signal this time.
Write the command that you use:
_____________________________________________________________

Individually: Working on Non-Router Systems

32. Watch the output from the script, and keep track of the time. When
the default entry stops being reported, subtract the start time from
the finish time to determine how long the system took to remove the
default route entry.
Approximately how long did it take for the default entry to be
removed from the table?
_____________________________________________________________
When done, stop the script by pressing the Control+C key sequence.
33. Stop the in.routed daemon on the non-router systems.
Write the command that you use:
_____________________________________________________________

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

Individually: Working on All Systems

34. Flush the routing tables on routers first and then the non-router
systems.
Write the command that you use:
_____________________________________________________________

Individually: Working on Non-Router Systems

35. Working on a non-router system, use the ping command to attempt

to contact a non-router system on one of the other subnets.
What is the response from the ping command?
_____________________________________________________________

Configuring Routing 7-55

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Subnet Group: Working on Your Router System

36. Add routes manually to the other subnets by using the route
command.
Write the commands that you use:
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Individually: Working on Non-Router Systems

37. Add routes manually by using the route command to the remote
subnets.
Write the commands that you use.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

7-56 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Individually: Working on All Systems

38. Working on all systems, observe the routing tables.

Write the command that you use:
_____________________________________________________________

Individually: Working on Non-Router Systems

39. Working on a non-router system, use the ping command to attempt

to contact a non-router system on one of the other subnets.
What is the response from the ping command?
_____________________________________________________________
40. Edit the contents of the /etc/inet/networks file, and add the one,
two and three network names.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
41. Observe the changes to the routing table on all non-router systems.
Write the command that you use:
_____________________________________________________________
Are the networks described in the /etc/inet/networks file present
in the routing table?
_____________________________________________________________

Note – Do not proceed beyond this point until everyone in the class has
completed this step.

42. Reboot the routers. Schedule a job so that the non-routers reboot two
minutes later. Check to see if the in.routed daemon was started on
each of the non-router systems. Explain why you see the results that
you do.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Configuring Routing 7-57

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Reviewing Routing Configuration

Subnet Group: Working on Your Router System

Perform the following steps to leave your router system in a known

routing configuration for subsequent exercises:
43. Configure to enable IPv4 routing when the system next boots.
_____________________________________________________________
44. Configure to enable IPv4 forwarding when the system next boots.
_____________________________________________________________
45. If they exist, remove the /etc/gateways and /etc/defaultrouter
files.
_____________________________________________________________

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

46. Reboot the system.

_____________________________________________________________

Individually: Working on Non-Router Systems

Perform the following steps to leave your non-router system in a known

routing configuration for subsequent exercises:
47. Remove the /etc/inet/routing.conf file.
_____________________________________________________________
48. If they exist, remove the /etc/gateways and /etc/defaultrouter
files.
_____________________________________________________________
49. Reboot the system
_____________________________________________________________

7-58 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Configuring Routing 7-59

Exercise Solutions
Solutions to the exercise are as follows:
1. In your own words, define each of the following routing schemes:
a. Static route
Static routes are routes that are do not time-out and must be removed
manually. Rebooting the system removes the static entries. The most
common static entry is a system that routes datagrams to the locally
connected networks.
b. Dynamic route
Dynamic routing means that the routing environment changes.
Dynamic routing identifies other network destinations that are not
connected directly but are reachable through a router. After the
routing table identifies the other reachable networks, the identified
router can forward or deliver the datagrams.
c. Default route
A default route is a table entry that permits a system to define default
routes to use if a route entry for a specific destination does not exist. It
is used for all indirectly connected workstations. The default routers
must be reliable. There is no need to define every reachable network.
All indirectly connected datagram destinations go to the default
router.
2. What is a multihomed host?
A multihomed host is a host that has more than one physical network
interface and does not forward IP datagrams between networks.
3. Define the term autonomous system.
An autonomous system is a collection of networks and routers under a
single administrative control. This intentionally broad definition was
incorporated into the Internet to handle overly large routing tables.
4. In your own words, describe the differences between an interior
gateway protocol and an exterior gateway protocol.
A routing protocol used within an autonomous system is called an interior
gateway protocol. A routing protocol that communicates routes between
autonomous systems is called an exterior gateway protocol.
5. Give two examples of an interior gateway protocol.
OSPF protocol and RIP.

7-60 Network Administration for the Solaris™ 10 Operating System

6. Give two examples of an exterior gateway protocol.

EGP and BGP.
7. Explain the purpose of ICMP redirects.
ICMP redirects are used most commonly when a system uses default
routing. If the router determines a more efficient way to forward the
datagram, it redirects the datagram using the best route and reports the
correct route to the sender.

Subnet Group: Working on the Routers

8. Before making any changes to the interfaces, write the netmask and
broadcast values of the Ethernet interface.
router# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
The netmask is ffffff00.
The broadcast address is 192.168.1.255.

If the /etc/defaultrouter file or the /etc/gateways file exist on your

system:
1. Remove the file/s.
2. Reboot the system in order to restore it to a default state for this
exercise.

a. Which class of IPv4 address (A, B, or C) is assigned to your

system?
Class C (this might be different in your classroom).
b. How many bits of your IPv4 address are currently being used
for your network address?
Twenty-four bits (this might be different in your classroom).

Configuring Routing 7-61

9. Use the netstat -r command to observe your current routing table.

Write down which routing destinations are available.
router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys11 U 1 0 hme0
224.0.0.0 sys11 U 1 0 hme0
localhost localhost UH 2 6 lo0
10. Use the netstat command with the -rn options. What is the
difference between this output and the previous netstat -r output?
The netstat -rn command displays the table in numeric form.
router# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 192.168.1.1 U 1 0 hme0
224.0.0.0 192.168.1.1 U 1 0 hme0
127.0.0.1 127.0.0.1 UH 2 6 lo0
11. Use the ps command to determine if the routing daemon is currently
running on the system.
router# ps -ef | grep in[.]
root 153 1 0 04:42:54 ? 0:00 /usr/sbin/in.routed
The in.routed process is running.

Individually: Working on Non-Router Systems

12. Use the ps command to determine if the routing daemon is currently

running on the system.
non-router# ps -ef | grep in[.]
root 153 1 0 04:45:56 ? 0:00 /usr/sbin/in.routed

7-62 Network Administration for the Solaris™ 10 Operating System

Subnet Group: Working on the Routers

13. Configure the router for your subnet.

a. Create the /etc/hostname.interface file for your system’s
second interface, and place the host name in it so that the
second interface is configured automatically at boot time.
For example, if your second interface is qfe0, the contents of the
/etc/hostname.qfe0 file should be similar to:
router# cat /etc/hostname.qfe0
sys11ext
b. Verify that the name to be associated with the second interface
that is used in the /etc/hostname.interface file exists in the
/etc/inet/hosts file. If it does not, edit the /etc/inet/hosts
file, and place an appropriate interface name in the file.
router# grep sys11ext /etc/inet/hosts
192.168.30.31 sys11ext # router to get to instructor->Internet
14. Configure IP forwarding and IP routing for IPv4 to become enabled
on the next boot of the router.
Write the command that you use:
router# routeadm -e ipv4-forwarding
router# routeadm -e ipv4-routing

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

15. Reboot the router.

Write the command that you use:
router# init 6

Configuring Routing 7-63

16. Verify that each router is correctly configured.

a. Display the configuration of each network interface.
router# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4, VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:ac:9b:20
How many external interfaces are configured and running
now?
Two interfaces: hme0 and qfe0. The interfaces might be different on
your system.
b. Display the contents of the routing table.
router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys11 U 1 0 hme0
192.168.2.0 sys21ext UG 1 0
192.168.30.0 sys11ext U 1 1 qfe0
224.0.0.0 sys11 U 1 0 hme0
localhost localhost UH 2 6 lo0
Which network destinations are now available?
You should see the following routes if all of the groups in the
classroom have configured their routers (you may have to wait up to
5 minutes):
● 192.168.1.0
● 192.168.2.0
● 192.168.3.0
● 192.168.30.0
● 224.0.0.0
● 127.0.0.1 (localhost)
c. Determine that the routing daemon is running on the router.
router# ps -ef | grep in[.]
root 94 1 0 10:52:12 ? 0:00 /usr/sbin/in.routed
What does this daemon do?
The /usr/sbin/in.routed daemon sends ICMP router
advertisement messages and RIP messages.

7-64 Network Administration for the Solaris™ 10 Operating System

Individually: Working on Non-Router Systems

If the /etc/defaultrouter file or the /etc/gateways file exists on

your system:
1. Remove the file/s.
2. Reboot the system in order to restore it to a default state for this
exercise.

17. Complete the following steps:

a. Determine if the routing daemon is running on each non-router
system.
non-router# ps -ef | grep in[.]
root 156 1 0 13:31:57 ? 0:00 /usr/sbin/in.routed
Why is this daemon running?
The daemon is responsible for listening for ICMP router
advertisements and RIP messages.
b. Run the netstat -r command, and record the current
network destinations.
non-router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys12 U 1 1 hme0
192.168.2.0 sys11 UG 1 1 hme0
192.168.30.0 sys11 UG 1 1 hme0
224.0.0.0 sys12 U 1 0 hme0
localhost localhost UH 2 6 lo0
c. Run the ifconfig -a command, and record the current
netmask and broadcast values.
non-router# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4, VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:a4:8f:80

Configuring Routing 7-65

Subnet Group: Working on Your Router System

18. Start the snoop utility on the router to watch for network traffic
associated with multicast address 224.0.0.2 as the non-routers
reboot. (Hint: Use the icmp option on the snoop command line.) Be
sure to use the snoop utility on the appropriate interface for the
network that you want to monitor. Be prepared to see ICMP router
advertisements after the next step.
router# snoop -d hme0 icmp
Using device /dev/hme (promiscuous mode)

Individually: Working on Non-Router Systems

19. Reboot your non-router workstation.

non-router# init 6

Subnet Group: Working on Your Router System

20. Observe the snoop output on the router system.

sys11 -> 224.0.0.1 ICMP Router advertisement (Lifetime 1800s [1]: {sys11 0})
sys11 -> 224.0.0.1 ICMP Router advertisement (Lifetime 1800s [1]: {sys11 0})
sys11 -> 224.0.0.1 ICMP Router advertisement (Lifetime 1800s [1]: {sys11 0})
Notice that routers send direct advertisements to the multicast adddress to
which clients are listening.

7-66 Network Administration for the Solaris™ 10 Operating System

Individually: Working on Non-Router Systems

21. Use the netstat -r command, and observe the change to the
routing tables.
non-router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys12 U 1 0 hme0
224.0.0.0 sys12 U 1 0 hme0
default sys11 UG 1 0 hme0
localhost localhost UH 2 6 lo0
Which new type of entry is now present? How was it entered into
the routing table?
The newest entry is a default route. The system learns the default route
from routers on the subnet through the router discovery ICMP messages.
22. Use the ps command on the non-router systems to determine if the
routing daemon is now running.
non-router# ps -ef | grep in[.]
root 91 1 0 12:36:05 ? 0:00 /usr/sbin/in.routed
Why is this daemon running?
The in.routed daemon is running because the daemon is invoked by
default, at boot time. This is controlled by the routeadm utility. You can
view the configuration by looking at the contents of the
/etc/inet/routing.conf file.

Subnet Group: Working on Your Router System

23. Terminate the snoop trace that you had running, and then start a
verbose snoop trace in a separate window on your router system.
router# snoop -v -d hme0
Using device /dev/hme (promiscuous mode)
24. Working in a new window, use the routeadm command to terminate
the in.routed process on the router.
router# routeadm -u -d ipv4-routing

Configuring Routing 7-67

25. View the output from the snoop utility. Look for the router
notification when the in.routed daemon terminated gracefully.
Hint: Look for multicasts and ICMP messages.
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 8 arrived at 12:46:52.27
ETHER: Packet size = 50 bytes
ETHER: Destination = 1:0:5e:0:0:1, (multicast)
ETHER: Source = 8:0:20:ac:9b:20, Sun
ETHER: Ethertype = 0800 (IP)
ETHER:
...
...
IP: Protocol = 1 (ICMP)
IP: Header checksum = ea98
IP: Source address = 192.168.1.1, sys11
IP: Destination address = 224.0.0.1, 224.0.0.1
...
...
a. Examine the snoop trace. Did you see the router notification
when the in.routed daemon terminated gracefully?
Yes.
b. What was the ETHER destination, as reported by the snoop
trace?
1:0:5e:0:0:1.
c. What protocol did the router notification use?
ICMP.
d. What was the destination IP address of the router notification?
224.0.0.1.
26. Verify that the process has been terminated.
router# ps -ef | grep routed
root 94 1 0 10:52:12 ? 0:00 grep routed

7-68 Network Administration for the Solaris™ 10 Operating System

Individually: Working on Non-Router Systems

27. Use the netstat command to view the routing tables on one of the
non-router systems. What is missing?
non-router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys12 U 1 0 qfme0
224.0.0.0 sys12 U 1 0 qfe0
localhost localhost UH 2 6 lo0
The default route through the sys11 system was removed.

Note – Do not proceed beyond this point until everyone in the class has
completed this step.

Subnet Group: Working on Your Router System

28. Verify that the snoop session started earlier on your router is still
running, and then start the in.routed process on your router
system, changing the advertisement interval to 90 seconds by placing
the appropriate entry in the /etc/gateways file.
What entry do you place in the /etc/gateways file?
rdisc_interval=90
Which command do you use to restart the in.routed daemon?
router# routeadm -u -e ipv4-routing
Observe ICMP and other traffic as the in.routed daemon is started.
Output from snoop trace:
ETHER: Packet 8 arrived at 16:39:16.72
ETHER: Packet size = 50 bytes
ETHER: Destination = 1:0:5e:0:0:1, (multicast)
ETHER: Source = 8:0:20:ac:9b:20, Sun
...
...

Configuring Routing 7-69

IP: Source address = 192.168.1.1, sys11

IP: Destination address = 224.0.0.1, 224.0.0.1
IP: No options
IP:
ICMP: ----- ICMP Header -----
ICMP:
ICMP: Type = 9 (Router advertisement)
ICMP: Code = 0 (Lifetime 270s [1]: {sys11 0})
...
...

Individually: Working on Non-Router Systems

29. Use the netstat command to view the routing tables on one of the
non-router systems to verify that the default route has been inserted
into the routing table.
non-router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys12 U 1 0 qfe0
224.0.0.0 sys12 U 1 0 qfe0
default sys11 UG 1 0 qfe0
localhost localhost UH 2 6 lo0

Note – The while statement syntax assumes that you are using the
Bourne shell.

non-router# while true

> do
> date
> netstat -rn | grep default
> sleep 20
> done
Tue Dec 4 17:17:44 MST 2004

7-70 Network Administration for the Solaris™ 10 Operating System

default sys11 UG 1 0
Tue Dec 4 17:18:04 MST 2004
default sys11 UG 1 0
...
...

Subnet Group: Working on Your Router System

31. Simulate a router crash, and kill the in.routed daemon on the
router again, but use the 9 (KILL) signal this time.
router# pkill -9 in.routed

Individually: Working on Non-Router Systems

32. Watch the output from the script, and keep track of the time. When
the default entry stops being reported, subtract the start time from
the finish time to determine how long the system took to remove the
default route entry.
...
...
Tue Dec 4 17:20:24 MST 2004
default sys11 UG 1 0
Tue Dec 4 17:20:44 MST 2004
default sys11 UG 1 0
Tue Dec 4 17:21:04 MST 2004
Tue Dec 4 17:21:25 MST 2004
...
...
Approximately how long did it take for the default entry to be
removed from the table?
Four and a half (4-1/2) minutes.
When done, stop the script by pressing the Control+C key sequence.
33. Stop the in.routed daemon on the non-router systems.
non-router# ps -ef | grep in[.]
root 91 1 0 12:36:05 ? 0:00 /usr/sbin/in.routed
non-router#
non-router# routeadm -u -d ipv4-routing

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

Configuring Routing 7-71

Individually: Working on Your Router System

34. Flush the routing tables on routers first and then the non-router
systems.
Write the command that you use:
router# route flush
192.168.2 sys21ext done

Individually: Working on Non-Router Systems

non-router# route flush

Individually: Working on Non-Router Systems

35. Working on a non-router system, use the ping command to attempt

to contact a non-router system on one of the other subnets.
non-router# ping sys23
ICMP Host Unreachable from gateway sys12 (192.168.1.2)
for icmp from sys12 (192.168.1.2) to sys23 (192.168.2.3
What is the response from the ping command?
ICMP Host Unreachable from gateway.

Subnet Group: Working on Your Router System

36. Add routes manually to the other subnets by using the route
command.
router# route add net 192.168.2.0 192.168.30.32
add net 192.168.2.0: gateway 192.168.30.32
router#
router# route add net 192.168.3.0 192.168.30.33
add net 192.168.3.0: gateway 192.168.30.33

7-72 Network Administration for the Solaris™ 10 Operating System

Individually: Working on Non-Router Systems

37. Add routes manually by using the route command to the remote
subnets.
non-router# route add net 192.168.30.0 192.168.1.1
add net 192.168.30.0: gateway 192.168.1.1
non-router#
non-router# route add net 192.168.2.0 192.168.1.1
add net 192.168.2.0: gateway 192.168.1.1
non-router#
non-router# route add net 192.168.3.0 192.168.1.1
add net 192.168.3.0: gateway 192.168.1.1

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

Individually: Working on All Systems

38. Working on all systems, observe the routing tables.

On non-router systems:
non-router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys12 U 1 0 hme0
192.168.2.0 sys11 UG 1 0
192.168.3.0 sys11 UG 1 0
192.168.30.0 sys11 UG 1 0
224.0.0.0 sys12 U 1 0 hme0
localhost localhost UH 2 6 lo0
non-router#
On router systems:
router# netstat -r
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 sys11 U 1 16 hme0
192.168.2.0 sys21ext UG 1 0
192.168.3.0 sys31ext UG 1 0
192.168.30.0 sys11ext U 1 14 hme0
224.0.0.0 sys11 U 1 0 hme0
localhost localhost UH 2 6 lo0

Configuring Routing 7-73

Individually: Working on Non-Router Systems

39. Working on a non-router system, use the ping command to attempt

to contact a non-router system on one of the other subnets.
non-router# ping sys23
sys23 is alive
What is the response from the ping command?
sys23 is alive.
40. Edit the contents of the /etc/inet/networks file, and add the one,
two and three network names.
non-router# vi /etc/inet/networks
non-router# tail -3 /etc/networks
one 192.168.1
two 192.168.2
three 192.168.3
41. Observe the changes to the routing table on all non-router systems.
non-router# netstat -r

Routing Table: IPv4

Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
one sys12 U 1 1 hme0
two sys11 UG 1 2
three sys11 UG 1 0
192.168.30.0 sys11 UG 1 0
224.0.0.0 sys12 U 1 0 hme0
localhost localhost UH 2 6 lo0
Are the networks described in the /etc/inet/networks file present
in the routing table?
Yes.

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

7-74 Network Administration for the Solaris™ 10 Operating System

Subnet Group: Working on Your Router System

router# init 6

INIT: New run level: 6

...

Individually: Working on Non-Router Systems

non-router# at now+2minutes
at> init 6
at> ^D<EOT>
commands will be executed using /sbin/sh
job 1007515599.a at Tue Dec 4 18:26:39 2004

Subnet Group: Working on Your Router System

Perform the following steps to leave your router system in a known

routing configuration for subsequent exercises:
43. Configure to enable IPv4 routing when the system next boots.
router# routeadm -e ipv4-routing
44. Configure to enable IPv4 forwarding when the system next boots.
router# routeadm -e ipv4-forwarding
45. If they exist, remove the /etc/gateways and /etc/defaultrouter
files.
router# rm /etc/gateways; rm /etc/defaultrouter

Caution – Do not proceed beyond this point until everyone in the class
has completed this step.

46. Reboot the system.

router# init 6

Individually: Working on Non-Router Systems

Perform the following steps to leave your non-router system in a known

routing configuration for subsequent exercises:
47. If they exist, remove the /etc/gateways and /etc/defaultrouter
files.
non-router# rm /etc/gateways; rm /etc/defaultrouter

Configuring Routing 7-75

48. Remove the /etc/inet/routing.conf file.

non-router# rm /etc/inet/routing.conf
49. Reboot the system.
non-router# init 6

7-76 Network Administration for the Solaris™ 10 Operating System

Configuring IPv6

Objectives
This module describes IPv6 management, features, configuration and
troubleshooting, and IPv6 addressing and interfaces.

Upon completion of this module, you should be able to:

● Describe IPv6
● Describe IPv6 addressing
● Describe IPv6 autoconfiguration
● Describe IPv6 unicast address types
● Describe IPv6 multicast address types
● Enable IPv6
● Manage IPv6
● Configure 6to4 routing
● Configure IPv6 multipathing

8-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Objectives

The course map in Figure 8-1 shows how this module fits into the current
instructional goal.
Configuring the Network

Configuring IP
Configuring Configuring
Network
IP Routing
Multipathing

Describing
Configuring the Transport
IPv6 Layer

Figure 8-1 Course Map

8-2 Network Administration for the Solaris™ 10 Operating System

Introducing IPv6
IPv6 is the most recent version of the IP specification. Refer to RFC 2460
for a description of IPv6. In 1991, the Internet Architecture Board (IAB)
sponsored a working group to address a pending IP address shortage.
The IAB predicted that all Class B networks would be allocated by 1994
and that all IP addresses would be allocated by 2002 (see Christian
Huitema, Routing in the Internet, Second Edition, 2000).

The Need for IPv6

The IPv4 address shortage is only one reason that IPv6 was developed.
IPv6 was defined to resolve the following:
● IPv4 address shortage – IPv6 implements a 128-bit address scheme
that supports 340,282,366,920,938,463,463,347,607,431,768,211,456
nodes. IPv4, with a 32-bit address scheme, provides for more than
4 billion addresses. However, many of these addresses were not
usable because classful addressing techniques wasted large numbers
of possible IPv4 addresses. A technique for using IP addresses on
private networks without exposing them to the Internet is defined in
RFC 1918. This technique helps to alleviate the IP address shortage.
● Autoconfiguration – IPv6 systems configure their IPv6 addresses
automatically. There is no need to assign manually an IPv6 address,
as is done in IPv4 by editing the /etc/inet/hosts file and creating
/etc/hostname.xxx files. Autoconfiguration allocates IPv6
addresses to systems automatically. Administrators, however, still
have to administer the name-to-IPv6 address mapping.

Configuring IPv6 8-3

Features of IPv6
The IPv6 features are:
● Expanded addressing – The address size is increased from 32-bit
addresses to 128-bit addresses.
● Simplified header format – This format reduces the number of
header fields in an IPv6 datagram from 10 fields to 6 fields.
● Improved extension header and option support – This feature
supports extension headers in addition to the primary header.
Extension headers are located between the required IPv6 datagram
header and the payload; therefore, they provide special treatment of
some datagrams without a performance penalty.
● Quality of service – A flow label in the header provides for flows.
Flows identify a sequence of datagrams from the same source to the
same destination when the source requests special handling of the
specified datagram sequence by the intervening routers.
● Authentication and privacy headers – An authentication header
(AH) provides the authentication services, and the encapsulating
security payload (ESP) header provides privacy.

8-4 Network Administration for the Solaris™ 10 Operating System

Introducing IPv6 Addressing

IPv6 addressing uses 128 bits. Because of the autoconfiguration capability
in IPv6, it is no more difficult to administer IPv6 addressing than it is with
IPv4. The first part of the address is the format prefix, followed by a
routable prefix or padding. The second part of the address is the interface
identifier, analogous to the IPv4 host portion, and is derived from the
system’s MAC address.

Address Types
Like IPv4, IPv6 has three types of addresses that you can use to
communicate across a network. For sending messages, IPv6 supports:
● Unicast addresses
● Multicast addresses
● Anycast addresses

IPv6 differs from IPv4 in that IPv6 does not provide broadcast addresses
as a mechanism for communicating with other hosts on a subnet.

In IPv6 it is normal for several IPv6 addresses to be assigned to the same

physical interface.

Unicast Addressing

With the unicast address type, a unique address is assigned to an

interface. A unicast datagram is sent to a single machine with the
matching destination IPv6 address. Unicast addressing is called
point-to-point addressing in IPv4.

Multicast Addressing

With the multicast address type, an address is assigned to a group of

systems. Datagrams are delivered to all interfaces as identified by the
multicast address. Multicast addressing in IPv6 replaces broadcast
addressing in IPv4.

Configuring IPv6 8-5

Anycast Addressing

With the anycast address type, an address is assigned to a group of

systems. Anycast addresses identify the nearest member of a group of
systems that provide a particular type of service. Datagrams are delivered
to the nearest interface member, as identified by the routing protocol,
instead of being delivered to all members of a group.

IPv6 Address Representation

RFC 2373 describes how IPv6 128-bit hexadecimal addresses can be
represented in multiple ways:
● Eight 16-bit hexadecimal numbers, for example:
fe80:0000:0000:0000:0a00:20ff:feb5:4137
● Eight 16-bit hexadecimal numbers in which 0s (zeros) are
represented by a single leading 0, for example:
fe80:0:0:0:a00:20ff:feb5:4137

IPv6 permits address compression. You can compress leading or

embedded 0s (zeros) with a double colon (::). To compress an address,
you can represent consecutive 16-bit 0 numbers with double colons (::).
You can only do this once in any address, for example:
fe80::a00:20ff:feb5:4137

Format Prefixes
The format prefix (FP) in the address indicates the type of IPv6 address
that is used. For example:
● Link-local addresses are intended to identify hosts on a single
network link. They are similar to the way Ethernet addresses are
used to communicate on an Ethernet segment or subnet.
● Site-local addresses are valid across an intranet. They are similar to
an organization choosing a random IPv4 address class for the
organization, but not connecting to the Internet.

8-6 Network Administration for the Solaris™ 10 Operating System

● Aggregatable global addresses are valid across the Internet. They are
similar to an officially registered IPv4 address class for organizations
connected to the Internet.
● A multicast address is an identifier for a group of systems. A node
can belong to any number of multicast groups.

Table 8-1 shows several common types of IPv6 addresses.

Table 8-1 Initial Allocation of Format Prefixes From RFC 2373

Allocation FP (Binary) FP (Hexadecimal)

Link-local unicast addresses 1111 1110 10 FE8

Site-local unicast addresses 1111 1110 11 FEC
Aggregatable global-unicast 001 2 or 3
addresses
Multicast addresses 1111 1111 FF

Note – Refer to RFC 2373 for information about FPs that are not related to
the Solaris OS. The FP byte is binary. As defined in RFC 2373, unused
trailing bits in the byte are not shown. For example, the FP represented by
001 is 0x2 or 0x3, because the two binary values are 0010 and 0011. The FP
represented by 001 should not be confused with 0001, which is equal to
0x1.

Configuring IPv6 8-7

Introducing IPv6 Autoconfiguration

IPv6 address autoconfiguration includes:
● Determining what information should be autoconfigured, such as
addresses and routing prefixes
● Verifying the uniqueness of link-local addresses on the link

Stateful Autoconfiguration
Stateful autoconfiguration requires the additional setup of a DHCP server.
For this reason, stateful autoconfiguration is not a preferred configuration
method. Stateful autoconfiguration and stateless autoconfiguration, as
defined in IPv6, can coexist and operate together. Stateful
autoconfiguration supplies address and service information similar to the
way that DHCP provides information in IPv4.

Stateless Autoconfiguration
The stateless mechanism permits a host to generate its own addresses by
using a combination of information this is available locally and
information that is advertised by routers. Routers advertise prefixes that
identify the subnets associated with a link, while hosts generate an
interface identifier that uniquely identifies an interface on a subnet.

An address is formed by combining the advertised prefix and the

interface identifier. In the absence of routers, a host can generate only
link-local addresses. However, link-local addresses are sufficient for
permitting communication among systems that are attached to the same
link.

8-8 Network Administration for the Solaris™ 10 Operating System

Interface Identifier Calculation

Appendix A of RFC 2373 describes the process of automatically
calculating an IPv6 interface identifier address. The following is an
example of how a Sun Microsystems workstation computes an IPv6
interface identifier address from its MAC address.

The initial MAC address is 08:00:20:b5:41:37, where:

● 08:00:20 is the company identifier (CID)
● b5:41:37 is the vendor-supplied identifier (VID)

To build an interface identifier, perform the following steps:

1. Obtain the MAC address.
Figure 8-2 shows this address.
08:00:20:b5:41:37
CID VID
Figure 8-2 MAC Address

2. Convert the address to binary format.

Figure 8-3 shows the address in binary format.

0 8 0 0 2 0 B 5 4 1 3 7
0000 1000 0000 0000 0010 0000 1011 0101 0100 0001 0011 0111
CID VID

Figure 8-3 Binary Representation of the MAC Address

Configuring IPv6 8-9

3. Toggle bit 7, the universal/local bit, which is the seventh bit from the
left.
Figure 8-4 shows the address after conversion.

0 A 0 0 2 0 B 5 4 1 3 7
0000 1010 0000 0000 0010 0000 1011 0101 0100 0001 0011 0111
CID VID

Figure 8-4 MAC Address Conversion to an Interface Identifier

4. Insert two additional octets, 0xFF and 0xFE, between the CID and
the VID. This converts the MAC address to an interface identifier.
Figure 8-5 shows the resulting interface identifier.

0 A 0 0 2 0 F F F E B 5 4 1 3 7
0000 1010 0000 0000 0010 0000 1111 1111 1111 1110 1011 0101 0100 0001 0011 0111
CID VID

Figure 8-5 MAC Address With 0xFF and 0xFE Octets

5. Convert the binary address to hexadecimal format, and include

colons to show the IPv6-autoconfigured interface identifier address
of 0a00:20ff:feb5:4137.
This unique interface identifier is the basis of autoconfigured IPv6
addresses on the system. This unique interface identifier is only
64 bits of the 128-bit address and is called an end-unit identifier-64
(EUI-64).

Duplicate Address Detection

Systems run a duplicate address detection algorithm on an address before
that address is assigned to an interface. This is done without regard to the
manner in which the address was obtained. The duplicate address
detection algorithm works by sending a neighbor solicitation message to
the network that contains the address in question. The system receives a
neighbor advertisement from any device that is currently using the
address. Therefore, if no response is received, the systems assume that the
address is available for use and is assigned to the interface. If the address
in question is not unique, a unique address must be configured manually.

8-10 Network Administration for the Solaris™ 10 Operating System

Introducing Unicast Address Types

IPv6, like IPv4, supports the concept of unicast addressing.

Unicast addresses direct datagrams to a single interface or system. The

ability to transmit network data in this way enables systems that are not
included in the communication to efficiently ignore network data that is
not addressed to them.

Link-Local Addresses
Link-local addresses are valid on a local network link only. Link-local
addresses are not forwarded by routers. The first 10 bits of the address
prefix identify an address as a link-local address. The link-local address
format prefix is 1111 1110 10 in binary, or FE8 in hexadecimal, as shown in
Figure 8-6.
10 Bits 54 Bits 64 Bits

1111111010 All Zeros (0) Interface ID

fe80::a00:20ff:feb5:4137

Figure 8-6 Link-Local Address Format

Configuring IPv6 8-11

Site-Local Addresses
Site-local addresses are similar to link-local addresses but can be routed
through an intranet. Intranet routers can forward site-local addresses
through the intranet but not outside of the intranet. The first 10 bits of the
address prefix identify an address as a site-local address.The site-local
address format prefix is 1111 1110 11 in binary, or FEC in hexadecimal
format, as shown in Figure 8-7.

10 Bits 38 Bits 16 Bits 64 Bits

1111111011 All Zeros (0) Subnet ID Interface ID

fec0::0003:a00:20ff:feb5:4137

Figure 8-7 Site-Local Address Format

Aggregatable Global-Unicast Addresses

Aggregatable global addresses can be routed through the Internet. An
aggregatable global address always starts with 2 or 3 in hexadecimal
format. The first three bits are always set to 001, and they designate that
this address is a routable global-unicast address. Figure 8-8 shows the
frame format of an aggregatable global-unicast address.

3 Bits 13 Bits 32 Bits 16 Bits 64 Bits

001 TLA NLA SLA Interface ID

Figure 8-8 Aggregatable Global-Unicast Address Format

The frame format of an aggregatable global-unicast address includes:

● A prefix – The assigned prefix for aggregatable global addresses
(001).
● The top-level aggregator (TLA) – The identifying number of the
Internet authority that assigned the provider portion of the address,
for example, the IANA.
● The next level aggregator (NLA) – The address identifier that is
assigned to a company or organization by its ISP.

8-12 Network Administration for the Solaris™ 10 Operating System

● The site-level aggregator (SLA) – The subnet address assigned to

networks in the company or organization.
● Interface ID – The portion of the IP address that derives from the
MAC address, that is, the EUI-64 address.

Prefix Notation
RFC 2373 describes how IPv6 addresses use prefix notation. IPv6
addresses have two parts. The first part is the format prefix. The second
part is the interface identifier and is analogous to the IPv4 host portion.

An example of a subnet prefix address is:

fec0::0003:a00:20ff:feb5:4137/64

The /64 indicates that the subnet prefix is 64 bits in length. The first
64 bits of the address contain a subnet mask. The address can be broken
into a subnet prefix and a node address or into an interface identifier.
● fec0::0003 – The subnet prefix
● a00:20ff:feb5:4137 – The interface identifier

Embedded IPv4 Addresses

The IPv6 transition mechanisms include a technique for systems and
routers to tunnel IPv6 datagrams dynamically under the IPv4 routing
infrastructure. IPv6 systems that use this technique have special IPv6
unicast addresses assigned that carry an IPv4 address in the low-order
32 bits. This type of address is an IPv4-compatible IPv6 address. An
example of an embedded IPv4 address in an IPv6 address is:

0000:0000:0000:0000:0000:FFFF:yyyy:yyyy

where FFFF indicates that an embedded IPv4 address is present, and

yyyy:yyyy represents the 32 bits of the IPv4 address in hexadecimal
format.

Configuring IPv6 8-13

Unspecified Address Types

The source address of a system that has not had an address assigned will
be all zeros, for example: 0000:0000:0000:0000:0000:0000:0000:0000,
0:0:0:0:0:0:0:0, or :: in compressed format.

Loopback Address Types

IPv6 systems use the loopback address of
0000:0000:0000:0000:0000:0000:0000:0001, 0:0:0:0:0:0:0:1, or
::1 to send datagrams to themselves. This address is analogous to the
127.0.0.1 local address used by IPv4 systems.

8-14 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Multicast Address Types

Introducing Multicast Address Types

A datagram addressed to a multicast address is delivered to all systems
that are part of the multicast group. An IPv6 multicast address can be
thought of as a single identifier for a group of IPv6 systems that belong to
the multicast group.

Purpose of Multicast Addresses

The low-order 112 bits in an IPv6 address identify the multicast group to
which the datagram belongs.

A single interface can have multiple IPv6 addresses assigned to it,

including multicast addresses.

The FP of 11111111 or FF in hexadecimal format in an address identifies

the datagram as being a multicast datagram.

Multicast addresses include 4 bits of flags after the initial FF in the format
prefix. Three of the flag bits are reserved and are always set to 0. The
fourth flag bit is set to 0 if a well-known IANA-assigned multicast
address is used; the fourth bit is set to 1 if a temporary multicast address
is used. Figure 8-9 shows the multicast address types.

FP Flags Scope Multicast Group ID

8 Bits 4 Bits 4 Bits 112 Bits

11111111 000X XXXX

ff02:0:0:0:0:0:0:1

Figure 8-9 Multicast Address Types

Configuring IPv6 8-15

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Multicast Address Types

Scope Bits
Multicast addresses include four scope bits after the flag bits. The scope
bits determine how far the multicast datagram is routed:
● Node-local – FF01.
Route to all members of the group on the same node as the sender.
● Link-local – FF02.
Route to all members of the group on the same link as the sender.
● Site-local – FF05.
Route to all members of the group at the same site as the sender.
● Organization-local – FF08.
Route to all members of the same organization as the sender.
● Global – FF0E.
Route to all members of the group on the Internet.

For example, the multicast addresses for all routers are:

● FF01:0:0:0:0:0:0:2 – Node-local routers
● FF02:0:0:0:0:0:0:2 – Link-local routers
● FF05:0:0:0:0:0:0:2 – Site-local routers
● FF02:0:0:0:0:0:0:9 – Link-local, RIPv2 routers

The multicast addresses for all systems are:

● FF01:0:0:0:0:0:0:1 – Node-local systems
● FF02:0:0:0:0:0:0:1 – Link-local systems

Refer to RFC 2373 for additional IPv6 multicast information.

8-16 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Multicast Address Types

ICMPv6 Group Membership

RFC 2236 describes IGMP version 2 for IPv4. Hosts that join, belong to, or
leave multicast groups use IGMP version 2 to report this information to
local multicast routers. The following three IGMP version 2 messages are
relevant to this introduction:
● Membership query – Determines which groups have members on a
network
● Membership report – Reports if a system is part of a multicast
group
● Leave group – Determines when a system leaves a multicast group

All of the IGMP functionality has moved to ICMP version 6, which is

defined in RFC 1885.

Configuring IPv6 8-17

Enabling IPv6
You can enable IPv6 from the command line or by creating specific files
that are read by the /lib/svc/method/net-init and
/lib/svc/method/net-physical SMF methods at boot time.

Note – You can also enable IPv6 during initial installation of the
Solaris 10 OS.

The in.ndpd Daemon on a Non-Router

The in.ndpd daemon implements the Neighbor Discovery Protocol (ND).
Systems on the same network link use ND for IPv6 to:
● Perform address autoconfiguration – Systems configure an address
for an interface automatically. This eliminates the common duplicate
IP address problem experienced on IPv4 networks.
● Obtain MAC addresses – Neighbor solicitation messages are sent by
a node to determine the link-layer address of a neighbor or to verify
that a neighbor is still reachable by a cached link-layer address. A
solicitation can be sent if a node does not have an entry for a system
in its neighbor cache. This is similar to the ARP in IPv4. Neighbor
solicitations are also used for duplicate address detection.
● Gather reachability information about paths to active neighbors –
The in.ndpd daemon sends unsolicited neighbor advertisements to
discover newly available systems. The in.ndpd daemon can also
send unsolicited neighbor advertisements to announce a link-layer
address change. Systems use received neighbor advertisements to
update their neighbor cache with the MAC address of the sender.
● Discover routers – In IPv4, hosts had no way of knowing how to
locate routers unless the host had a static route defined or it was
running a type of routing protocol. IPv6 neighbor discovery replaced
the function that the IPv4’s RDISC protocol provided. Systems send
router solicitations to prompt routers to send router advertisements.

8-18 Network Administration for the Solaris™ 10 Operating System

Routers advertise their presence with various link and Internet

parameters, either periodically or in response to a router solicitation
message.
● Router advertisements contain prefixes used for on-link
determination or address configuration, a suggested hop limit
value, and other information.
● Systems use router advertisements to populate their neighbor
cache with the MAC address of the router. When an interface
becomes enabled, hosts can send router solicitations that
request routers to generate router advertisements immediately,
rather than at their next scheduled time. This enables the host to
become part of a network more quickly than it would have if it
waited for a normal router advertisement.
● Provide router redirects – A router informs a host of a better
first-hop node to reach a particular destination.

Refer to RFC 2461 for more information about neighbor discovery.

Configuring IPv6 on Non-Routers

You configure a system to support both IPv4 and IPv6. This configured
system is known as a dual-stack system.

IPv6 introduces new files, including:

● /etc/hostname6.interface – This file has similar functionality to
the /etc/hostname.interface file but contains no IP address or
host name information.

Note – The /etc/hostname6.interface file can still contain an IPv6

address or a resolvable host name to disable autoconfiguration and
enforce a given IPv6 address.

● /etc/inet/ipnodes – This file has similar functionality to the

/etc/inet/hosts file. There is no link from the /etc/ipnodes file.
The /etc/inet/ipnodes file can contain both IPv6 and IPv4
addresses.

Configuring IPv6 8-19

Note – If an application is IPv6-capable, the /etc/inet/ipnodes file is

consulted first, and then the /etc/inet/hosts file is consulted. The
/etc/inet/hosts file is the only file that is contacted for IPv4
applications, and it can only contain IPv4 addresses.

Configuring an Interface for IPv6

To configure an IPv6 interface on a system, create a

/etc/hostname6.interface file and reboot the system, or use the
ifconfig command to configure the interface manually. For example, to
configure IPv6 on a system’s hme0 interface, complete the following steps:
1. View the configuration of the system’s interfaces before making any
changes.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 823
2 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:90:b5:c7
#
2. Create the /etc/hostname6.hme0 file to cause the interface to
configure with IPv6, and then reboot the system.
# touch /etc/hostname6.hme0
# init 6
#
INIT: New run level: 6

8-20 Network Administration for the Solaris™ 10 Operating System

3. View the system’s interface configuration after the boot.

Configuring IPv6 Name Service Lookup

Like IPv4, you can apply names to IPv6 addresses so that you can more
easily refer to a system. For example, to name this system’s IPv6 hme0
interface sys12-v6, you can add an entry to the /etc/inet/ipnodes file
to make it look similar to the following:
# tail -2 /etc/inet/ipnodes
# added for ipnode example
fec0::a00:20ff:fe90:b5c7 sys12-v6
#

The /etc/inet/ipnodes file on each system on the local link that is

running IPv6 can be configured with a similar entry.

You can now address a system by its IPv6 interface by using the sys12-v6
host name. For example:
# uname -n
sys11
# ping sys12-v6
sys12-v6 is alive
#

Configuring IPv6 8-21

Name service lookup configuration for IPv6 is similar to name service

lookup configuration for IPv4.

The following are additional files:

● Two new NIS IPv6 maps are the ipnodes.byname and
ipnodes.byaddr maps. These maps have similar functionality to the
hosts.byname and hosts.byaddr files in IPv4.
● An additional NIS+ IPv6 table is created: ipnodes.org_dir. This
table has similar functionality to the hosts.org_dir. table in IPv4.
● A new DNS record type, AAAA (quad A) is available. The reverse is
similar to a normal PTR record but is much longer. Following is an
example of an AAAA record and a PTR record:
sys22.two.edu. IN AAAA fec0::a00:20ff:feb5:4137

7.3.1.4.5.b.e.f.f.f.0.2.0.0.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.int. IN PTR sys22.two.edu.

● The ipnodes line is used in the nsswitch.conf file for IPv6 system
name resolution.
hosts: files nisplus dns
ipnodes: files nisplus dns

Troubleshooting a Non-Router Configuration

You can use the netstat command with the address-family -f inet6
option to display only IPv6-specific information when you troubleshoot.
The netstat command has multiple forms and produces different types
and levels of output depending on the options that are used with the
command. To view only the IPv6 routing table, perform the command:
# netstat -f inet6 -r

Routing Table: IPv6

Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
fe80::/10 sys12-v6 U 1 0 hme0
ff00::/8 sys12-v6 U 1 0 hme0
default sys12-v6 U 1 0 hme0
localhost localhost UH 1 0 lo0
#

To view multicast group information for IPv6 interfaces, perform the

following command, which uses the g option for groups:
# netstat -f inet6 -g
Group Memberships: IPv6

8-22 Network Administration for the Solaris™ 10 Operating System

If Group RefCnt
----- --------------------------- ------
lo0 ff02::1:ff00:1 1
lo0 ff02::1 1
hme0 ff02::202 1
hme0 ff02::1:ff90:b5c7 1
hme0 ff02::1 2

You can use the ifconfig command to obtain IPv6-specific information

by using the inet6 address family parameter. For example, to view the
configuration of all IPv6 interfaces, perform the command:
# ifconfig -a inet6
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 825 2 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:fe90:b5c7/10
#

The in.ndpd Daemon on the Router

The IPv6 ND is implemented by the in.ndpd daemon. The in.ndpd
daemon implements IPv6 functions, including:
● Router discovery
● Prefix discovery
● Address autoconfiguration
● Address resolution
● Neighbor unreachability detection

IPv6 Routing Information Protocol

Routing in IPv6 is almost identical to IPv4 routing in CIDR, except that
the IPv6 addresses are 128 bits instead of 32 bits. The in.ripngd daemon
is the IPv6 routing daemon for the Solaris OS.

Configuring IPv6 8-23

The in.ripngd Daemon

In normal operation, the in.ripngd process listens on UDP port 521 for
routing information datagrams. If the host is a router, it supplies copies of
its routing table periodically to any directly connected host and network.

Configuring an IPv6 Router

You can use the command line to configure an IPv4 router to support
IPv6. You can activate IPv6 by starting specific processes or by rebooting
the system.

Configuring Interfaces for IPv6

To designate which interfaces are configured with IPv6 at boot time, use
the touch command to create a /etc/hostname6.interface file for each
IPv6 interface. For example, to configure the system to configure the hme0
and hme0 interfaces with IPv6 at boot time, type the following:
# touch /etc/hostname6.hme0 /etc/hostname6.qfe0
#

Alternatively, configure the hme0 and hme0 interfaces from the

command line as follows:
1. View the configuration of the interfaces.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 823 2 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:ac:9b:20
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:b9:72:23
#
2. Use the ifconfig command to configure the hme0 interface.
# ifconfig hme0 inet6 plumb up
#

8-24 Network Administration for the Solaris™ 10 Operating System

3. Use the ifconfig command to configure the qfe0 interface.

# ifconfig qfe0 inet6 plumb up
#
4. View the configuration of the interfaces.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4, VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:ac:9b:20
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:b9:72:23
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:ac:9b:20
inet6 fe80::a00:20ff:feac:9b20/10
qfe0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3
ether 8:0:20:b9:72:23
inet6 fe80::a00:20ff:feb9:7223/10
#

Configuring IPv6 Name Service Lookup in

/etc/nsswitch.conf

The IPv6 name service lookup mechanism is controlled in the same way
as IPv4. Verify that the ipnodes database is defined correctly for your
site’s name-service lookup mechanism. For example, make sure that the
following entry exists if the ipnodes database uses the system’s local file:
# grep ipnodes /etc/nsswitch.conf
ipnodes: files
#

Configuring the /etc/inet/ndpd.conf File

Configure the /etc/inet/ndpd.conf file to contain the subnet’s prefix

configuration information on the routers. You do not advertise link-local
addresses on a router because a link-local address cannot be routed. Recall
that:
● A link-local address starts with FE8.
● A site-local address starts with FEC.
● An aggregatable global-unicast address starts with 2 or 3.

Configuring IPv6 8-25

The following example demonstrates how to configure this information:

● Router advertisements are to be sent out to all interfaces.
● A site-local address on which the hme0 interface has a prefix of
fec0:0:0:9255::0/64.
● An aggregatable global-unicast address on which the hme0 interface
has a prefix of 2000:0:0:9255::0/64.
● A site-local address on which the qfe0 interface has a prefix of
fec0:0:0:9256::0/64.
● An aggregatable global-unicast address on which the qfe0 interface
has a prefix of 2000:0:0:9256::0/64.

Complete the following steps:

1. Define the /etc/inet/ndpd.conf file to have the following
contents:
# cat /etc/inet/ndpd.conf
# Send router advertisements out all interfaces
ifdefault AdvSendAdvertisements on
#
# Advertise an unregistered (bogus) site local prefix and global
# prefix using the default lifetimes
prefix fec0:0:0:9255::0/64 hme0
prefix 2000:0:0:9255::0/64 hme0
#
prefix fec0:0:0:9256::0/64 qfe0
prefix 2000:0:0:9256::0/64 qfe0
#

8-26 Network Administration for the Solaris™ 10 Operating System

2. Do one of the following:

● Reboot the system.
● Proceed to the Step 3 to configure the system from the
command line.
# init 6
#
INIT: New run level: 6
...
...
a. View the IPv6 configuration of the interfaces.
# ifconfig -a inet6
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
inet6 fe80::a00:20ff:feb9:7223/10
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 2000::9255:a00:20ff:feb9:7223/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 fec0::9255:a00:20ff:feb9:7223/64
qfe0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:feac:9b20/10
qfe0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2000::9256:a00:20ff:feac:9b20/64
qfe0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::9256:a00:20ff:feac:9b20/64
#
b. Observe how the site-local and aggregatable global-unicast
addresses are assigned to logical interfaces.
3. To configure your system without rebooting it, complete the
following steps:
a. Switch IPv6 IP forwarding on.
# routeadm -u -e ipv6-forwarding
or
# /usr/sbin/ndd -set /dev/ip ip6_forwarding 1
#
b. Configure the system to send routing redirects.
# /usr/sbin/ndd -set /dev/ip ip6_send_redirects 1
#
c. Configure the system to ignore routing redirects for IPv6.
# /usr/sbin/ndd -set /dev/ip ip6_ignore_redirect 1
#

Configuring IPv6 8-27

d. Start the in.ndpd daemon that reads the

/etc/inet/ndpd.conf file. Restart it if it is already running.
# /usr/lib/inet/in.ndpd
#
e. Start the in.ripngd daemon, and force it to supply routing
information to the network.
# /usr/lib/inet/in.ripngd -s
#
f. View the interface configuration.
# ifconfig -a inet6
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
inet6 fe80::a00:20ff:feb9:7223/10
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 2000::9255:a00:20ff:feb9:7223/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 fec0::9255:a00:20ff:feb9:7223/64
qfe0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:feac:9b20/10
qfe0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2000::9256:a00:20ff:feac:9b20/64
qfe0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::9256:a00:20ff:feac:9b20/64
#

8-28 Network Administration for the Solaris™ 10 Operating System

Figure 8-10 shows how the /lib/svc/method/net-init method

configures a system for IPv6 forwarding and routing.

Start

Disable
IPv6-forwarding

IPv6 routing
enabled by Yes Enable
routeadm and IPv6-routing
/etc/inet/ndpd.conf
exists?

Disable
IPv6-routing

IPv6
forwarding Yes Enable
enabled by IPv6 forwarding
routeadm?

Disable
IPv6 forwarding

End

Figure 8-10 IPv6 Router Initialization

Configuring IPv6 8-29

Configuring an IPv6 6to4 Router

The 6to4 router mechanism is designed to support the transition from
IPv4 to IPv6 addressing. Using the 6to4 mechanism, two IPv6 networks
can communicate with each other over an intermediate IPv4 network. A
6to4 tunnel is created and the intermediate network does not need to be
IPv6 aware.

Use of the 6to4 mechanism requires a boundary router on each IPv6

network. The boundary router is configured with one interface running
IPv4 and connected to the public internet by using a public IPv4 address,
as shown in Figure 8-11.

IPv6 IPv6
Network Network

Gateway Gateway
System IPv4 System
Network

Figure 8-11 Connecting IPv6 Networks Over an IPv4 Network

Implementing the 6to4 mechanism requires the use of a particular IPv6

address prefix. The 2002 prefix, part of the aggregatable global-unicast
address space, is reserved for 6to4 addresses. The 2002 prefix is combined
with the IPv4 address used on the boundary router to generate the format
prefix for all networks served by a particular boundary router.

The IPv4 address of the boundary router needs to be converted to

hexadecimal notation as part of the process. For example, if the boundary
router’s IPv4 address 192.168.30.31, 192 is c0 in hexadecimal, 168 is
a8 in hexadecimal, 30 is 1e in hexadecimal, and 31 is 1f in hexadecimal,
giving the representation c0a8:1e1f.

8-30 Network Administration for the Solaris™ 10 Operating System

Configuring a 6to4 Boundary Router

To configure a system as a 6to4 boundary router, perform the following
tasks:
1. Configure a 6to4 tunnel. The 6to4 tunnel bridges between the local
IPv6 networks and the public IPv4 network.
2. Configure the /etc/inet/ndpd.conf file to advertise 6to4
prefixes to the local IPv6 networks. The tunnel has a unique network
number in its prefix.

Calculating 6to4 Network Addresses

The 6to4 addresses have a defined format for the network portion of the
address:
● A 16-bit prefix that denotes the address as a 6to4 address (2002)
● A 32-bit, public IPv4 address on the boundary router in hexadecimal
notation
● A 16-bit subnet ID unique to each subnet – One subnet ID is used by
the end point of the tunnel

Configuring a 6to4 Tunnel

Configuring a 6to4 tunnel is a two-part process:

1. Plumb the 6to4 tunnel:
# ifconfig ip.6to4tun0 inet6 plumb
2. Configure the tunnel end points.
The tunnel end points are the global IPv4 address and an IPv6 host
address on a unique subnet within the 6to4 address range. A 6to4
tunnel can be configured without specifying explicitly an IPv6 host
address. If no IPv6 host address is specified, the tunnel is configured
with a subnet ID of 0 (zero) and a host ID of 1 (one).
To configure a 6to4 tunnel with no IPv6 host address, use the syntax:
ifconfig ip.6to4tun0 inet6 tsrc IPv4_Address up
For example, to configure a 6to4 tunnel with no IPv6 host address
and a public IPv4 address of 192.168.30.31, type the command:
# ifconfig ip.6to4tun0 inet6 tsrc 192.168.30.31 up
#

Configuring IPv6 8-31

This configures the tunnel endpoint with a subnet number of zero (0)
and a host number of one (1).
The tunnel configuration can be seen in the output from the
ifconfig -a command:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:f8:b7:23
qfe0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:f8:b7:23
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:fef8:b723/10
ether 8:0:20:f8:b7:23
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2002:c0a8:1e1f:1:a00:20ff:fef8:b723/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fef8:b723/64
ip.6to4tun0: flags=2300041<UP,RUNNING,ROUTER,NONUD,IPv6> mtu 8212 index 4
inet tunnel src 192.168.30.31
tunnel hop limit 60
inet6 2002:c0a8:1e1f::1/64
#
To configure a 6to4 tunnel with an explicit IPv6 host address as the
tunnel end point, use the syntax:
ifconfig ip.6to4tun0 inet6 tsrc IPv4_Address IPv6_Address up

Note – The 6to4 tunnel end point resides on its own IPv6 subnet. The
subnet ID used for the 6to4 tunnel must not be used on any of the local
IPv6 networks.

For example, to configure the tunnel end point as host ID 1 (one) on

subnet ffff:
# ifconfig ip.6to4tun0 inet6 tsrc 192.168.30.31 2002:c0a8:1e1f:ffff::1/64 up
#
The 6to4 tunnels can be configured at system boot by creating an
/etc/hostname.ip.6to4tun0 file. The contents of the file are the
arguments that follow the inet6 keyword on the command line. For
example:
# cat /etc/hostname6.ip.6to4tun0
tsrc 192.168.30.31 2002:c0a8:1e1f:ffff::1/64 up

8-32 Network Administration for the Solaris™ 10 Operating System

Troubleshooting a Router Configuration

To perform basic troubleshooting of an IPv6 router, confirm that processes
are running by examining the routing table, as shown in the following
examples:
● Determine if the ND daemon is running on each of the routers in
question.
# uname -n
sys11
# pgrep -lf ndpd
108 /usr/lib/inet/in.ndpd
#

# uname -n
sys21
# pgrep -lf ndpd
1497 /usr/lib/inet/in.ndpd
● View the IPv6 routing table on each router in question.
# uname -n
sys11
# netstat -rn -f inet6
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
2000:0:0:9255::/64 2000::9256:a00:20ff:feac:9b20 U 1 0 hme0:1
fec0:0:0:9255::/64 fec0::9256:a00:20ff:feac:9b20 U 1 0 hme0:2
2000:0:0:9256::/64 2000::9255:a00:20ff:feb9:7223 U 1 0 qfe0:1
fec0:0:0:9256::/64 fec0::9255:a00:20ff:feb9:7223 U 1 0 qfe0:2
2000:0:0:9257::/64 fe80::a00:20ff:fec0:449d UG 1 0 qfe0
fec0:0:0:9257::/64 fe80::a00:20ff:fec0:449d UG 1 0 qfe0
fe80::/10 fe80::a00:20ff:feac:9b20 U 1 0 hme0
fe80::/10 fe80::a00:20ff:feb9:7223 U 1 2 qfe0
ff00::/8 fe80::a00:20ff:feb9:7223 U 1 0 hme0
::1 ::1 UH 1 0 lo0
#

# uname -n
#
sys21
#

Configuring IPv6 8-33

# netstat -rn -f inet6

Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
2000:0:0:9257::/64 2000::9257:a00:20ff:fec0:449d U 1 0 hme0:1
fec0:0:0:9257::/64 fec0::9257:a00:20ff:fec0:449d U 1 0 hme0:2
2000:0:0:9256::/64 2000::9256:a00:20ff:feb8:2b08 U 1 0 qfe0:1
fec0:0:0:9256::/64 fec0::9256:a00:20ff:feb8:2b08 U 1 0 qfe0:2
2000:0:0:9255::/64 fe80::a00:20ff:feb9:7223 UG 1 0 qfe0
fec0:0:0:9255::/64 fe80::a00:20ff:feb9:7223 UG 1 0 qfe0
fe80::/10 fe80::a00:20ff:feb8:2b08 U 1 0 qfe0
fe80::/10 fe80::a00:20ff:fec0:449d U 1 1 hme0
#
● Send an ICMP echo request to a remote system to determine if you
receive an ICMP echo response from the remote system. Do not
attempt to communicate with the link-local address of a system
across a router because routers do not forward link-local addresses.
# ping fec0::9255:a00:20ff:fec0:449d
fec0::9255:a00:20ff:fec0:449d is alive
#
# ping 2000::9255:a00:20ff:fec0:449d
2000::9255:a00:20ff:fec0:449d is alive
#

8-34 Network Administration for the Solaris™ 10 Operating System

Managing IPv6
The tasks you use to manage IPv6 interfaces are similar to the tasks you
use to manage IPv4 interfaces.

Displaying the State of IPv6 Interfaces

Use the ifconfig command with the inet6 option to display the state of
the IPv6 interfaces, for example:
# ifconfig -a inet6
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:feb9:7223/10
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2000::9255:a00:20ff:feb9:7223/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::9255:a00:20ff:feb9:7223/64
qfe0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
inet6 fe80::a00:20ff:feac:9b20/10
qfe0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 2000::9256:a00:20ff:feac:9b20/64
qfe0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 fec0::9256:a00:20ff:feac:9b20/64
#

Modifying the Configuration of an IPv6 Interface

Use the ifconfig command to modify IPv6 interface configuration in a
similar manner to IPv4 interfaces. The family type of IPv6 must be
defined in the command after the interface option, for example:
ifconfig hme0 inet6 configuration options

Caution – Be sure to specify the inet6 family, or the command changes

the configuration of an IPv4 interface.

Configuring IPv6 8-35

Configuring Logical Interfaces

You can configure logical IPv6 interfaces by using the ifconfig
command with the inet6 parameter in a similar way as for IPv4, for
example:
ifconfig qfe0:3 inet6 plumb configuration options

To remove the logical interface, disable the interface, and then use the
unplumb parameter, for example:
# ifconfig qfe0:3 inet6 down unplumb
#

Troubleshooting IPv6 Interfaces

You troubleshoot IPv6 interfaces like you troubleshoot IPv4 interfaces.
Recall that different FPs are required on addresses destined beyond the
local subnet. Therefore, do not spend time attempting to determine why
you cannot access a system on another subnet with an IPv6 address that
starts with fe8.

Displaying the IPv6 Routing Table

You use the netstat command with the address-family -f inet6 option
to display the IPv6 routing table, for example:
# netstat -f inet6 -r

Routing Table: IPv6

Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
fe80::/10 sys11-v6 U 1 0 hme0
ff00::/8 sys11-v6 U 1 0 hme0
default sys11-v6 U 1 0 hme0
localhost localhost UH 1 0 lo0
#

8-36 Network Administration for the Solaris™ 10 Operating System

Exercise 1: Configuring IPv6

In this exercise, you configure IPv6 on a router and on a non-router.

The exercise consists of the following tasks:

● Configure IPv6 on your local subnet
● Configure 6to4 routing so that you can contact IPv6 systems on other
subnets
● Configure the whole classroom network to use IPv6

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Work with another group for these tasks if your system functions as a
router in the classroom.

Task 1 – Configuring IPv6 on the Local Subnet

To configure IPv6 on the local subnet, complete the following sections.

Working on All Non-Router Systems (sysX2, sysX3, sysX4)

To configure IPv6 on a non-router, complete the following steps:

1. Display the configuration of the system’s interfaces before you make
any changes.
______________________________________________
2. Create the relevant file to cause your system’s primary interface to be
configured with both IPv4 and IPv6.
______________________________________________
3. Reboot the system.
______________________________________________

Configuring IPv6 8-37

4. View the system’s interface configuration after the boot.

______________________________________________
Write your system’s IPv6 IP address:
______________________________________________
Can this IPv6 IP address be used by systems on other subnets to
contact your system? Why or why not?
______________________________________________
______________________________________________
______________________________________________
5. Ask another group on your subnet for its link-local IPv6 IP address.
Write the IP address:
______________________________________________
6. Use the ping command to verify that your system can send and
receive ICMP echo messages with another local IPv6 system.
______________________________________________
7. View the current routing table so that you will be able to see the
difference after the router is reconfigured later.
______________________________________________
8. Use the ps command to determine which routing daemons are
currently running on the system.
______________________________________________
Describe why the process or processes are running.
______________________________________________
______________________________________________
______________________________________________
______________________________________________

8-38 Network Administration for the Solaris™ 10 Operating System

Task 2 – Configuring 6to4 Routing

Complete the steps in the following sections.

Working on Your Subnet’s Router

Complete the following steps:

1. From the command line, configure IPv6 on the network interface
connected to the local subnet. Also create the necessary file to enable
this same configuration at any subsequent boot.
______________________________________________
2. Enable IPv6 routing.
______________________________________________
3. Enable IPv6 forwarding.
______________________________________________
4. Plumb an IPv6 6to4 tunnel.
______________________________________________
5. Configure the IPv6 tunnel using the router’s IPv4 address on the
30.X network (for example 192.168.30.31), and use network
number 0 (zero) and host number 1 (one) for the tunnel end point.
______________________________________________
6. Create an /etc/hostname6.ip.6to4tun0 file so that the 6to4
tunnel is created automatically with the appropriate source when the
system boots.
______________________________________________

Configuring IPv6 8-39

7. Create an /etc/inet/ndpd.conf file to advertise a 6to4 address

prefix and a site-local address prefix to your local subnet. Make the
subnet ID for both prefixes the same as the subnet ID used in your
IPv4 addresses. (For example, if you are on subnet 192.168.1.0,
use 1 (one) as your subnet ID). Use the following prefix lines:
● For sys11:
prefix fec0:0:0:1::0/64 hme0
prefix 2002:c0a8:1e1f:1::0/64 hme0
● For sys21:
prefix fec0:0:0:2::0/64 hme0
prefix 2002:c0a8:1e20:2::0/64 hme0
● For sys31:
prefix fec0:0:0:3::0/64 hme0
prefix 2002:c0a8:1e21:3::0/64 hme0
8. Reboot the router.
______________________________________________
9. Log in to the router and view the configuration of its network
interfaces.
______________________________________________
10. View the routing table on the router.
______________________________________________
11. View the daemons running on the router.
______________________________________________

Working on all Non-Router Systems (sysX2, sysX3, sysX4)

Continue as follows:
12. Obtain the IPv6 6to4 address of a system on a different subnet.
______________________________________________
13. Attempt to contact a system on a different subnet by using its IPv6
6to4 address.
______________________________________________

Caution – Do not proceed beyond this point until everyone in the class
completes this step.

8-40 Network Administration for the Solaris™ 10 Operating System

Task 3 – Configuring IPv6 Across the Whole Network

In this section you will remove the 6to4 tunnel just constructed so that
you can enable IPv6 across the whole network. Complete the steps in the
following sections.

Working on Your Subnet’s Router

Work with another teammate’s group for this task if your system
functions as a non-router in the classroom.

To configure IPv6 on a router, complete the following steps:

1. Display the router’s interface configuration so that you can back out
of the configuration at any stage.
______________________________________________
2. Unconfigure the 6to4 tunnel interface.
______________________________________________
______________________________________________
3. Determine which, if any, processes related to IPv6 routing are
running and, if so, with what options. Why are the processes
running with these options?
______________________________________________
______________________________________________
______________________________________________
______________________________________________
4. Verify that the files that you use to configure the router’s interfaces
with IPv6 at boot time exist. If they do not, create them.
______________________________________________
______________________________________________

Configuring IPv6 8-41

5. Edit the correct file on your router to cause it to use a site-local and
an aggregated global-unicast address for each interface on the router.
Use the following addresses:
● 192.168.1.0 uses fec0:0:0:1::0/64 and
2000:0:0:1::0/64
● 192.168.2.0 uses fec0:0:0:2::0/64 and 2000:0:0:2::0/64
● 192.168.3.0 uses fec0:0:0:3::0/64 and 2000:0:0:3::0/64
● 192.168.30.0 uses fec0:0:0:30::0/64 and
2000:0:0:30::0/64
Configure the file to cause the routing daemon to advertise IPv6 out
of all interfaces.
Be sure to remove an existing prefix 2002 lines.
Document your work.
6. Reboot the router systems.
______________________________________________
7. Verify that each router is configured correctly. Display the
configuration of each network interface.
______________________________________________
8. View your router’s IPv6 routing table. What routes are available?
______________________________________________
9. Determine which routing daemons are running on the router. Which
options are running with each routing daemon, and why?
______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________

8-42 Network Administration for the Solaris™ 10 Operating System

Working on all Non-Router Systems (sysX2, sysX3, sysX4)

Continue as follows:
10. Either reboot the non-router systems, or wait a few minutes for the
route information to propagate the network.
______________________________________________
11. Use the ping command to send ICMP echo requests from a non-
router system to the site-local address of another non-router system
on another subnet to verify that the routing is functioning as
expected. (You may have to wait enough time for the routing
information to be updated after the prior step’s system boot)
______________________________________________
12. Determine which routing daemons are running on each non-router
system. Which options are running with each routing daemon, and
why?
______________________________________________
______________________________________________
13. Display the system’s routing table. What type of routes are in the
routing table (link-local, site-local, or global)?
______________________________________________
14. Display the system’s interface configuration. Notice the logical
addresses that provide access to the different networks based on
the FP.
______________________________________________

Configuring IPv6 8-43

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

8-44 Network Administration for the Solaris™ 10 Operating System

Exercise 1 Solutions
The following solution is specific to an individual system. Your results
will be different if you are working on different systems.

Task 1 – Configuring IPv6 on the Local Subnet

To configure IPv6 on the local subnet, complete the following sections.

Working on All Non-Router Systems (sysX2, sysX3, sysX4)

To configure IPv6 on a non-router, complete the following steps:

1. Display the configuration of the system’s interfaces before you make
any changes.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4, VIRTIAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:c1:4b:44
#
2. Create the relevant file to cause your system’s primary interface to be
configured with both IPv4 and IPv6.
# touch /etc/hostname6.hme0
3. Reboot the system.
# init 6
#
INIT: New run level: 6
svc.startd: The system is coming down. Please wait.
...
...

Configuring IPv6 8-45

4. View the system’s interface configuration after the boot.

# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4, VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:c1:4b:44
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
#
The system’s primary interface is now configured with both the IPv4 and
IPv6 protocol stacks.
Write your system’s IPv6 IP address:
fe80::a00:20ff:fec1:4b44/10
Can this IPv6 IP address be used by systems on other subnets to
contact your system? Why or why not?
No, other systems cannot contact this IPv6 IP address because the address
has an FP of fe8, which is a link-local address and is limited to the local
subnet. The FP defines the scope that an IPv6 datagram is able to travel.
5. Ask another group on your subnet for its link-local IPv6 IP address.
Write the IP address:
fe80::a00:20ff:fe90:b5c7/10
6. Use the ping command to verify that your system can send and
receive ICMP echo messages with another local IPv6 system.
# ping fe80::a00:20ff:fe90:b5c7
fe80::a00:20ff:fe90:b5c7 is alive
#

8-46 Network Administration for the Solaris™ 10 Operating System

7. View the current routing table so that you will be able to see the
difference after the router is reconfigured later.
netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 192.168.1.3 U 1 2 hme0
224.0.0.0 192.168.1.3 U 1 0 hme0
default 192.168.1.1 UG 1 0 hme0
127.0.0.1 127.0.0.1 UH 2 6 lo0

Routing Table: IPv6

Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
fe80::/10 fe80::a00:20ff:fec1:4b44 U 1 0 hme0
ff00::/8 fe80::a00:20ff:fec1:4b44 U 1 0 hme0
default fe80::a00:20ff:fec1:4b44 U 1 0 hme0
::1 ::1 UH 1 0 lo0
#
8. Use the ps command to determine which routing daemons are
currently running on the system.
# ps -ef | grep in[.]
root 102 1 0 12:10:10 ? 0:00 /usr/sbin/in.routed
root 109 1 0 12:10:10 ? 0:00 /usr/lib/inet/in.ndpd
#
Describe why the process or processes are running.
The in.routed daemon is attempting to locate routers by sending
solicitation, and is listening for IPv4 routing messages after it boots.
The in.ndpd daemon provides the autoconfiguration components of
neighbor discovery and is not really considered to be a routing daemon.

Configuring IPv6 8-47

Task 2 – Configuring 6to4 Routing

Complete the steps in the following sections.

Working on Your Subnet’s Router

1. From the command line, configure IPv6 on the network interface

connected to the local subnet. Also create the necessary file to enable
this same configuration at any subsequent boot.
# ifconfig hme0 inet6 plumb up
# touch /etc/hostname6.hme0
#
2. Enable IPv6 routing.
# routeadm -u -e ipv6-routing
# routeadm
Configuration Current Current
Option Configuration System State
---------------------------------------------------------------
IPv4 forwarding enabled enabled
IPv4 routing enabled enabled
IPv6 forwarding enabled enabled
IPv6 routing enabled enabled

IPv4 routing daemon "/usr/sbin/in.routed"

8-48 Network Administration for the Solaris™ 10 Operating System

4. Plumb an IPv6 6to4 tunnel.

# ifconfig ip.6to4tun0 inet6 plumb
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
qfe2: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:ac:9b:22
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:feb9:7223/10
ether 8:0:20:b9:72:23
ip.6to4tun0: flags=2300040<RUNNING,ROUTER,NONUD,IPv6> mtu 65515 index 4
inet tunnel src 0.0.0.0
tunnel hop limit 60
inet6 fe80::32:0:10/10
5. Configure the IPv6 tunnel using the router’s IPv4 address on the
30.X network (for example 192.168.30.31), and use network
number 0 (zero) and host number 1 (one) for the tunnel end point.
# ifconfig ip.6to4tun0 inet6 tsrc 192.168.30.31 up
# cat /etc/hostname6.ip.6to4tun0
tsrc 192.168.30.31 up
6. Create an /etc/hostname6.ip.6to4tun0 file so that the 6to4
tunnel is created automatically with the appropriate source when the
system boots.
# echo tsrc 192.168.30.31 up > /etc/hostname6.ip.6to4tun0
# cat /etc/hostname6.ip.6to4tun0
tsrc 192.168.30.31 up
______________________________________________
7. Create an /etc/inet/ndpd.conf file to advertise a 6to4 address
prefix and a site-local address prefix to your local subnet. Make the
subnet ID for both prefixes the same as the subnet ID used in your
IPv4 addresses. (For example, if you are on subnet 192.168.1.0,
use 1 (one) as your subnet ID). Use the following prefix lines:
● For sys11:
prefix fec0:0:0:1::0/64 hme0
prefix 2002:c0a8:1e1f:1::0/64 hme0
● For sys21:
prefix fec0:0:0:2::0/64 hme0
prefix 2002:c0a8:1e20:2::0/64 hme0

Configuring IPv6 8-49

● For sys31:
prefix fec0:0:0:3::0/64 hme0
prefix 2002:c0a8:1e21:3::0/64 hme0

# cat /etc/inet/ndpd.conf
# Send router advertisements out all interfaces
ifdefault AdvSendAdvertisements on
# Advertise an unregistered (bogus) global prefix and a site
# local prefix using the default lifetimes
# Site-local address
prefix fec0:0:0:1::0/64 hme0
# 6to4 address
prefix 2002:c0a8:1e1f:1::0/64 hme0
#
8. Reboot the router.
# init 6
9. Log in to the router and view the configuration of its network
interfaces.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:f8:b7:23
qfe0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:f8:b7:23
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:fef8:b723/10
ether 8:0:20:f8:b7:23
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2002:c0a8:1e1f:1:a00:20ff:fef8:b723/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fef8:b723/64
ip.6to4tun0: flags=2300041<UP,RUNNING,ROUTER,NONUD,IPv6> mtu 8212 index 4
inet tunnel src 192.168.30.31
tunnel hop limit 60
inet6 2002:c0a8:1e1f::1/64
#

8-50 Network Administration for the Solaris™ 10 Operating System

10. View the routing table on the router.

# netstat -rn

Routing Table: IPv4

Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 192.168.1.3 U 1 38 hme0
192.168.2.0 192.168.30.32 UG 1 0 qfe0
192.168.30.0 192.168.30.31 U 1 34 qfe0
224.0.0.0 192.168.1.3 U 1 0 hme0
127.0.0.1 127.0.0.1 UH 9 152065 lo0

Routing Table: IPv6

Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
2002:c0a8:1e1f:1::/64 2002:c0a8:1e1f:1:a00:20ff:fef8:b723 U 1 6 hme0:1
fec0:0:0:1::/64 fec0::1:a00:20ff:fef8:b723 U 1 0 hme0:2
2002:c0a8:1e1f::/64 2002:c0a8:1e1f::1 U 1 0 ip.6to4tun0
2002::/16 2002:c0a8:1e1f::1 U 1 1 ip.6to4tun0
fe80::/10 fe80::a00:20ff:fef8:b723 U 1 18 hme0
ff00::/8 fe80::a00:20ff:fef8:b723 U 1 0 hme0
::1 ::1 UH 30 494 lo0
#
11. View the daemons running on the router.
# ps -ef | grep in[.]
root 147 1 0 15:42:56 ? 0:32 /usr/sbin/in.routed
root 149 1 0 15:42:56 ? 0:00 /usr/lib/inet/in.ndpd
root 151 1 0 15:42:56 ? 0:02 /usr/lib/inet/in.ripngd -s
#

Working on all Non-Router Systems (sysX2, sysX3, sysX4)

Continue as follows:
12. Obtain the IPv6 6to4 address of a system on a different subnet.
2002:c0a8:1e20:2:a00:20ff:feb6:c5de
13. Attempt to contact a system on a different subnet by using its IPv6
6to4 address.
# ping 2002:c0a8:1e20:2:a00:20ff:feb6:c5de
2002:c0a8:1e20:2:a00:20ff:feb6:c5de is alive
#

Caution – Do not proceed beyond this point until everyone in the class
completes this step.

Configuring IPv6 8-51

Task 3 – Configuring IPv6 Across the Whole Network

In this section you will remove the 6to4 tunnel just constructed so that
you can enable IPv6 across the whole network. Complete the steps in the
following sections.

Working on Your Subnet’s Router

Work with another teammate’s group for this task if your system
functions as a non-router in the classroom.

To configure IPv6 on a router, complete the following steps:

1. Display the router’s interface configuration so that you can back out
of the configuration at any stage.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:f8:b7:23
qfe0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:f8:b7:23
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:fef8:b723/10
ether 8:0:20:f8:b7:23
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2002:c0a8:1e1f:1:a00:20ff:fef8:b723/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fef8:b723/64
ip.6to4tun0: flags=2300041<UP,RUNNING,ROUTER,NONUD,IPv6> mtu 8212 index 4
inet tunnel src 192.168.30.31
tunnel hop limit 60
inet6 2002:c0a8:1e1f::1/64
#
2. Unconfigure the 6to4 tunnel interface
# ifconfig ip.6to4tun0 inet6 down unplumb
# rm /etc/hostname6.ip.6to4tun0
#
3. Determine which, if any, processes related to IPv6 routing are
running and, if so, with what options. Why are the processes
running with these options?
# ps -ef | grep in[.]

8-52 Network Administration for the Solaris™ 10 Operating System

root 161 1 0 14:25:20 ? 0:00 /usr/lib/inet/in.ndpd

root 158 1 0 14:25:20 ? 0:01 /usr/sbin/in.routed
root 163 1 0 14:25:20 ? 0:00 /usr/lib/inet/in.ripngd -s
The in.routed daemon runs to supply routing information to the local
networks. This is possible even if this system is not configured as a router.
4. Verify that the files that you use to configure the router’s interfaces
with IPv6 at boot time exist. If they do not, create them.
# touch /etc/hostname6.hme0
# touch /etc/hostname6.qfe0
#
5. Edit the correct file on your router to cause it to use a site-local and
an aggregated global unicast address for each interface on the router.
Use the following addresses:
● 192.168.1.0 uses fec0:0:0:1::0/64 and
2000:0:0:1::0/64
● 192.168.2.0 uses fec0:0:0:2::0/64 and 2000:0:0:2::0/64
● 192.168.3.0 uses fec0:0:0:3::0/64 and 2000:0:0:3::0/64
● 192.168.30.0 uses fec0:0:0:30::0/64 and
2000:0:0:30::0/64
Configure the file to cause the routing daemon to advertise IPv6 out
of all interfaces.
Be sure to remove existing prefix 2002 lines.
Document your work.
Edit the sys11 router’s /etc/inet/ndpd.conf file to contain contents
similar to the following:
sys11# cat /etc/inet/ndpd.conf
# Send router advertisements out all interfaces
ifdefault AdvSendAdvertisements on
# Advertise an unregistered (bogus) global prefix and a site
# local prefix using the default lifetimes
# Site-local addresses:
prefix fec0:0:0:2::0/64 qfe0
prefix fec0:0:0:30::0/64 hme0
# Aggregatable global unicast addresses
prefix 2000:0:0:2::0/64 qfe0
prefix 2000:0:0:30::0/64 hme0
Edit the sys21 router’s /etc/inet/ndpd.conf file to contain contents
similar to the following:
sys21# cat /etc/inet/ndpd.conf

Configuring IPv6 8-53

# Send router advertisements out all interfaces

ifdefault AdvSendAdvertisements on
# Advertise an unregistered (bogus) global prefix and a site
# local prefix using the default lifetimes
# Site-local addresses:
prefix fec0:0:0:2::0/64 qfe0
prefix fec0:0:0:30::0/64 hme0
# Aggregatable global unicast addresses
prefix 2000:0:0:2::0/64 qfe0
prefix 2000:0:0:30::0/64 hme0

8-54 Network Administration for the Solaris™ 10 Operating System

6. Reboot the router systems.

# init 6
#
svc.startd: The system is coming down. Please wait.
...
...
7. Verify that each router is configured correctly. Display the
configuration of each network interface.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:ac:9b:20
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
ether 8:0:20:b9:72:23
inet6 fe80::a00:20ff:feb9:7223/10
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:feb9:7223/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:feb9:7223/64
qfe0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
ether 8:0:20:ac:9b:20
inet6 fe80::a00:20ff:feac:9b20/10
qfe0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 2000::30:a00:20ff:feac:9b20/64
qfe0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 fec0::30:a00:20ff:feac:9b20/64
8. View your router’s IPv6 routing table. What routes are available?
# netstat -f inet6 -rn
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
2000:0:0:30::/64 2000::30:a00:20ff:feb9:7223 U 1 0 hme0:1
fec0:0:0:30::/64 fec0::30:a00:20ff:feb9:7223 U 1 0 hme0:2
2000:0:0:1::/64 2000::1:a00:20ff:feac:9b20 U 1 0 qfe0:1
fec0:0:0:1::/64 fec0::1:a00:20ff:feac:9b20 U 1 0 qfe0:2
2000:0:0:2::/64 fe80::203:baff:fe6b:5d34 UG 1 0 hme0
fec0:0:0:2::/64 fe80::203:baff:fe6b:5d34 UG 1 0 hme0
fe80::/10 fe80::a00:20ff:feb9:7223 U 1 0 hme0
fe80::/10 fe80::a00:20ff:feac:9b20 U 1 0 qfe0
ff00::/8 fe80::a00:20ff:feb9:7223 U 1 0 hme0
::1 ::1 UH 1 0 lo0

Configuring IPv6 8-55

9. Determine which routing daemons are running on the router. Which

options are running with each routing daemon, and why?
# ps -ef | grep in[.]
root 107 1 0 12:36:01 ? 0:00 /usr/sbin/in.routed
root 116 1 0 12:36:02 ? 0:00 /usr/lib/inet/in.ndpd
root 118 1 0 12:36:02 ? 0:00 /usr/lib/inet/in.ripngd -s
#
The in.routed process runs to supply routing information to the local
networks. This is possible even if this system is not configured as a router.
The in.ndpd process provides the autoconfiguration components of
neighbor discovery and is not really considered to be a routing daemon.
The in.ripngd process runs with the -s option to force the process to
supply routing information. This is possible even if this system is not
configured as a router.

Working on all Non-Router Systems (sysX2, sysX3, sysX4)

Continue as follows:
10. Either reboot the non-router systems, or wait a few minutes for the
route information to propagate the network.
# init 6
svc.startd: The system is coming down. Please wait.
...
...
11. Use the ping command to send ICMP echo requests from a non-
router system to the site-local address of another non-router system
on another subnet to verify that the routing is functioning as
expected. (You may have to wait enough time for the routing
information to be updated after the prior step’s system boot).
# ping fec0::2:a00:20ff:feb8:30c8
ICMPv6 Address Unreachable from gateway ....
...
# ping fec0::2:a00:20ff:feb8:30c8
fec0::2:a00:20ff:feb8:30c8 is alive
#

8-56 Network Administration for the Solaris™ 10 Operating System

12. Determine which routing daemons are running on each non-router

system. Which options are running with each routing daemon, and
why?
# ps -ef | grep in[.]
root 102 1 0 12:51:52 ? 0:00 /usr/sbin/in.routed
root 109 1 0 12:51:52 ? 0:00 /usr/lib/inet/in.ndpd
#
The in.routed daemon is listening for IPv4 routing information.
13. Display the system’s routing table. What type of routes are in the
routing table (link-local, site-local, or global)?
# netstat -rn -f inet6
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------ -----
2000:0:0:1::/64 2000::1:a00:20ff:fec1:4b44 U 1 0 hme0:1
fec0:0:0:1::/64 fec0::1:a00:20ff:fec1:4b44 U 1 0 hme0:2
fe80::/10 fe80::a00:20ff:fec1:4b44 U 1 0 hme0
ff00::/8 fe80::a00:20ff:fec1:4b44 U 1 0 hme0
default fe80::a00:20ff:feac:9b20 UG 1 0 hme0
::1 ::1 UH 1 0 lo0
#
The fe8, fec, and 200 FPs indicate that the system is aware of link-local,
site-local, and global networks.
14. Display the system’s interface configuration. Notice the logical
addresses that provide access to the different networks based on
the FP.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:c1:4b:44
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:fec1:4b44/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fec1:4b44/64
#

Configuring IPv6 8-57

Configuring IPv6 Multipathing

You can configure IPv6 multipathing either from the command line or by
editing a file to cause multipathing to be configured at boot time. IPv6
multipathing is similar in operation to the multipathing operation in IPv4,
but it has a significantly different configuration procedure.

Configuring IPMP Manually

You can configure a production server for IPv6 IPMP without rebooting if
your system was configured previously to support local MAC addresses.
This example shows how to configure IPMP on an existing
IPv6-configured hme0 interface and on an existing, but unconfigured,
qfe1 interface, in which the multipath group is called mpgrp6-one.

To configure IPMP at the command-line prompt by using the ifconfig

command, complete the following steps, which are described in greater
detail in the next sections:
1. Verify the Solaris OS release.
2. Confirm that the system recognizes unique MAC addresses.
3. Configure the hme0 interface as part of a multipath group.
4. Configure a test address for the hme0 interface.
5. Configure the qfe1 interface as part of the hme0 interface multipath
group.
6. Configure a test address for the qfe1 interface.
7. View the interface configuration.
8. Observe the IPMP failover.

8-58 Network Administration for the Solaris™ 10 Operating System

View your system’s interface configuration to have a baseline before you

make any changes to the system, so that you know the state of the system
if you need to restore the system for any reason.

Perform the command:

Verifying the Solaris OS Release

The /etc/release file contains information about the installed version of

the Solaris OS.

The following system meets the minimum requirements:

# cat /etc/release
Solaris 8 10/00 s28s_u2wos_11b SPARC
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved.
Assembled 31 August 2000
#

The following system exceeds the minimum requirements:

# cat /etc/release
Solaris 10 s10_67 SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 09 September 2004
#

Configuring IPv6 8-59

Configuring Unique MAC Addresses

To determine if unique MAC addresses are enabled, use the eeprom

command to view the contents of the EEPROM:
# eeprom local-mac-address?
local-mac-address?=false
#

The preceding output indicates that the system is still in its default mode
and uses the same MAC address for each interface. This is indicated by
the setting of the local-mac-address? variable to false. You now use
the eeprom command to change the EEPROM’s local-mac-address?
variable to true.
# eeprom local-mac-address?=true
#

Verify that the EEPROM’s local-mac-address? variable is set to true:

# eeprom local-mac-address?
local-mac-address?=true
#

Note – You must reboot the system for EEPROM changes to take place.

You can also set the EEPROM’s local-mac-address? variable from the
OpenBoot PROM.

Configuring the hme0 Interface as Part of a Multipath Group

To configure the hme0 interface as part of a multipath group, specify the

name of the group, mpgrp6-one, of which the hme0 interface will be a
part:
# ifconfig hme0 group mpgrp6-one
# Dec 19 12:49:04 sys13 in.mpathd[309]: Failures cannot be detected on
hme0 as no IFF_NOFAILOVER address is available

Note – You only see this and subsequent failure messages if you are
viewing the console.

8-60 Network Administration for the Solaris™ 10 Operating System

You can ignore the preceding message because the interface is still being
configured.

View the changes to the interface:

Observe the additional information in the preceding ifconfig output for

the inet6 hme0 interface output that indicates the new multipath group
information:
groupname mpgrp6-one

Configuring a Test Address for the hme0 Interface

Next, you configure a test address for the hme0 interface. To configure an
IPv6 test address, you use the link-local address.

When you configure the address, mark it so that the in.mpathd daemon
recognizes it as a test address that must not fail over (-failover). Enter
the following:
# ifconfig hme0 inet6 -failover
#

Configuring IPv6 8-61

To view the changes to the interface, use the ifconfig command:

Observe the additional information that is reported by the preceding

ifconfig command for the hme0 interface:
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index
2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
groupname mpgrp6-one

This information includes the following:

● The NOFAILOVER flag indicates that the interface must not be used as
a failover interface if another interface in the group fails. You do not
need to mark IPv6 test addresses as deprecated.
● The RUNNING flag is monitored by the in.mpathd daemon to ensure
that communications are functioning as expected.

Be aware that the logical interface cannot function if the physical interface
fails.

8-62 Network Administration for the Solaris™ 10 Operating System

Configuring the qfe1 Interface as Part of the hme0 Interface

Multipath Group

Half of the interface configuration is complete. Now, you configure the

qfe1 interface with IPv4, netmask, and broadcast addresses. You must
also configure it as part of the same IPMP group as the hme0 interface.
Type the following:
# ifconfig qfe1 plumb 192.168.1.200 netmask + broadcast + group \
> mpgrp6-one up
#

Configure the new interface to also support IPv6. You do not need to
assign the interface to group because the IPv6 interface assumes the same
group membership as the IPv4 interface. Type the following:
# ifconfig qfe1 inet6 plumb up

To view the changes to the interface, use the ifconfig command:

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:c1:4b:44
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.200 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:b7:4e:5d
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
groupname mpgrp6-one
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:fec1:4b44/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fec1:4b44/64
qfe1: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3
ether 8:0:20:b7:4e:5d
inet6 fe80::a00:20ff:feb7:4e5d/10
groupname mpgrp6-one
qfe1:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 2000::1:a00:20ff:feb7:4e5d/64
qfe1:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 fec0::1:a00:20ff:feb7:4e5d/64
#

Configuring IPv6 8-63

Observe the additional information that is reported by the preceding

ifconfig command for the qfe1 interface:
qfe1: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3
ether 8:0:20:b7:4e:5d
inet6 fe80::a00:20ff:feb7:4e5d/10
groupname mpgrp6-one

The interface index number is incremented to 3 because every physical

interface obtains its own index number (which is identical for a physical
interface’s different virtual interfaces): 1 for lo0, 2 for hme0, and 3 for
qfe1.

Configuring an IPv6 Test Address for the qfe1 Interface

Now you configure an IPv6 test address for the qfe1 interface. When you
configure the address, mark it so that the in.mpathd daemon recognizes
it as a test address that must not be used as a failover interface
(-failover) if another interface in the group fails. Perform the command:
# ifconfig qfe1 inet6 -failover
# Dec 19 14:47:47 sys13 in.mpathd[309]: Failure detection restored on
qfe1 as an IFF_NOFAILOVER address is available

8-64 Network Administration for the Solaris™ 10 Operating System

To view the changes to the interface, use the ifconfig command:

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:c1:4b:44
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.200 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:b7:4e:5d
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
groupname mpgrp6-one
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:fec1:4b44/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fec1:4b44/64
qfe1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 3
ether 8:0:20:b7:4e:5d
inet6 fe80::a00:20ff:feb7:4e5d/10
groupname mpgrp6-one
qfe1:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 2000::1:a00:20ff:feb7:4e5d/64
qfe1:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 fec0::1:a00:20ff:feb7:4e5d/64
#

Configuring IPv6 8-65

Starting the in.mpathd Daemon to Monitor the Interfaces

The start process of the in.mpathd daemon is controlled by the

TRACK_INTERFACES_ONLY_WITH_GROUPS parameter in the
/etc/default/mpathd file. The contents of this file are:
# cat /etc/default/mpathd
#
#pragma ident "@(#)mpathd.dfl 1.2 00/07/17 SMI"
#
# Time taken by mpathd to detect a NIC failure in ms. The minimum time
# that can be specified is 100 ms.
#
FAILURE_DETECTION_TIME=10000
#
# Failback is enabled by default. To disable failback turn off this option
#
FAILBACK=yes
#
# By default only interfaces configured as part of multipathing groups
# are tracked. Turn off this option to track all network interfaces
# on the system
#
TRACK_INTERFACES_ONLY_WITH_GROUPS=yes
#

If the TRACK_INTERFACES_ONLY_WITH_GROUPS variable is set to yes, the

ifconfig command’s group option starts the in.mpathd daemon
automatically. If the TRACK_INTERFACES_ONLY_WITH_GROUPS variable is
set to no, then the /lib/svc/method/net-init SMF method starts the
in.mpathd daemon at boot time.

If you need to start the in.mpathd daemon from the command line, use
the following command as the root user:
# /sbin/in.mpathd
#

8-66 Network Administration for the Solaris™ 10 Operating System

Viewing the Interface Configuration

To view the configuration of the interfaces, now that multipathing is

completely configured, use the ifconfig command:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:c1:4b:44
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.200 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:b7:4e:5d
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
groupname mpgrp6-one
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:fec1:4b44/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fec1:4b44/64
qfe1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 3
ether 8:0:20:b7:4e:5d
inet6 fe80::a00:20ff:feb7:4e5d/10
groupname mpgrp6-one
qfe1:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 2000::1:a00:20ff:feb7:4e5d/64
qfe1:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 fec0::1:a00:20ff:feb7:4e5d/64
#

The system now remains available to users even if either of the multipath
network interfaces fail or become unusable for any reason.

Configuring IPv6 8-67

Configuring IPMP at Boot Time

This example shows IPMP configuration on an existing IPv6-configured
hme0 interface and on an existing, but unconfigured, qfe1 interface on the
sys13 (192.168.1.3) system. The multipath group is called mpgrp6-one.

To configure IPMP, complete the following steps, which are described in

greater detail in the next sections.
1. Verify the Solaris OS release.
2. Configure unique MAC addresses.
3. Configure the interfaces.
4. Reboot the system.
5. View the interface configuration.
6. Observe the IPMP failover.

View your system’s interface configuration to have a baseline before you

make any changes to the system, so that you know the state of the system
if you need to restore the system for any reason.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:c1:4b:44
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
#

8-68 Network Administration for the Solaris™ 10 Operating System

Verifying the Solaris OS Release

The /etc/release file contains information about the installed version of

the Solaris OS.

The following system meets the minimum requirements:

# cat /etc/release
Solaris 8 10/00 s28s_u2wos_11b SPARC
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved.
Assembled 31 August 2000
#

The following system exceeds the minimum requirements:

# cat /etc/release
Solaris 10 s10_67 SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 09 September 2004
#

Configuring IPv6 8-69

Configuring Unique MAC Addresses

Before attempting to configure MAC addresses, determine if the code in

your system’s EEPROM supports unique MAC addresses.

To determine if unique MAC addresses are permitted, use the eeprom

command to view the current value of the local-mac-address?
variable:
# eeprom local-mac-address?
local-mac-address?=false
#

The preceding output indicates that the system is still in its default mode
and uses the same MAC address for each interface. You now use the
eeprom command to change the EEPROM’s local-mac-address?
variable to true.
# eeprom local-mac-address?=true
#

Verify that the EEPROM’s local-mac-address? variable is set to true:

# eeprom local-mac-address?
local-mac-address?=true
#

Note – You must reboot the system for EEPROM changes to take place.

You can also set the EEPROM’s local-mac-address? variable from the
OpenBoot PROM level.

8-70 Network Administration for the Solaris™ 10 Operating System

Configuring the Interfaces

Multipath information is placed in the /etc/hostname6.hme0 and

/etc/hostname6.qfe1 files. Modify the /etc/hostname6.hme0 file to
contain contents similar to the following:
# cat /etc/hostname6.hme0
-failover group mpgrp6-one up
#

where:

hme0 Assigns an interface.

hostname6 Forces the ifconfig command to configure the
interface as an IPv6 interface.
-failover Marks the interface as a non-failover interface.
Interfaces that are marked in this way do not fail
over to another physical interface in the
multipath group in a failover scenario.
group mpgrp6-one Assigns mpgrp6-one as the name for an IPMP
group.
up Marks the interface as up, and initializes the
hardware.

Configure the /etc/hostname.qfe1 file to permit the IPv4 stack to be

configured on the qfe1 interface at boot time. Create the
/etc/hostname.qfe1 file to contain contents similar to the following:
# cat /etc/hostname.qfe1
192.168.1.200
#

Create the /etc/hostname6.qfe1 file to contain contents similar to the

following:
# cat /etc/hostname6.qfe1
-failover group mpgrp6-one up
#

Configuring IPv6 8-71

Rebooting the System

Reboot system to enable IPMP.

# init 6
#

Viewing the Interface Configuration

To view the configuration of the interfaces when the system is booted, use
the ifconfig command:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.3 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:c1:4b:44
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.200 netmask ffffff00 broadcast 192.168.1.255
groupname mpgrp6-one
ether 8:0:20:b7:4e:5d
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
groupname mpgrp6-one
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:fec1:4b44/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fec1:4b44/64
qfe1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 3
ether 8:0:20:b7:4e:5d
inet6 fe80::a00:20ff:feb7:4e5d/10
groupname mpgrp6-one
qfe1:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 2000::1:a00:20ff:feb7:4e5d/64
qfe1:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 fec0::1:a00:20ff:feb7:4e5d/64
#

The system remains available to users, even if either of the multipath

network interfaces fail or become unusable for any reason.

8-72 Network Administration for the Solaris™ 10 Operating System

Configure a Singleton IPMP Group in IPv6

It is possible to configure an IPMP group that contains only one
IPv6-enabled interface. This enables you to monitor the status of the
interface by using IPMP and to receive notifications about the interface’s
status, although it is not possible to fail the IPv6 addresses over on to
another network interface.

With a single interface in the group, data addresses can never move to a
different interface, and so are always associated with the monitored
interface.

Configuring a Singleton IPMP Group in IPv6 on the Command

Line

To create a singleton IPMP group, assign a multipath group name to the

interface:
# ifconfig hme0 inet6 group singleton
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu8232 index 1
inet 128.0.0.1 netmask ff000000
hme0 flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
groupname singleton
ether 8:0:20:b9:72:23
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:c1:4b:44
inet6 fe80::a00:20ff:fec1:4b44/10
groupname singleton
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:fec1:4b44/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:fec1:4b44/64
#

If the single interface will be included in an IPMP group with multiple

interfaces in the future, you should also set the NOFAILOVER flag on the
link local by using the -failover option.

Configuring a Singleton IPMP Group in IPv6 at System Boot

To create a singleton IPMP group at system boot, ensure that the interface
configuration file contains the group option and the IPMP group name:
# cat /etc/hostname6.hme0
group singleton#

Configuring IPv6 8-73

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise 2: Configuring IPv6 Multipathing

Exercise 2: Configuring IPv6 Multipathing

In this exercise, you configure IPv6 multipathing.

Preparation
Unplumb any secondary interfaces that might be configured before
beginning this exercise.

Refer to the lecture notes as necessary to perform the tasks listed.

Tasks
Complete the following steps.

Working on Any System

In this section of the exercise, you configure IPv6 multipathing on two

interfaces on your systems. You use both interfaces for regular network
traffic. That is, your system runs at half of its potential capacity in the
event of a network failure on any of the two NICs. You can use any name
that you choose for your multipath group.
1. View your system’s interface configuration to have a baseline before
you make any changes to the system, so that you know the state of
the system if you need to restore the system for any reason.
Write the command that you use:
_____________________________________________________________
2. Verify that your operating system release can support multipathing.
Write the command that you use:
_____________________________________________________________

8-74 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise 2: Configuring IPv6 Multipathing

3. Verify that your system is configured to use unique MAC addresses.

Write the command that you use:
_____________________________________________________________
What command do you use to cause your system to use unique
MAC addresses?
_____________________________________________________________

Note – You must reboot the system for EEPROM changes to take place.

Write the name that you are going to assign to your multipath group:
_____________________________________________________________
4. Check your system for interfaces, and decide which interfaces that
you will use for multipathing.
Complete the following fields:
Multipath group name: _________________________
First interface: _______________________________
Second interface: _____________________________
IPv4 address for second interface: __________________
5. Configure your first interface as part of the multipath group that you
will use.
Write the command that you use:
_____________________________________________________________
6. Use the ifconfig command to verify that the interfaces were
configured as expected.
7. Configure a test address for your system’s first multipath interface,
and set the failover option appropriately for a multipathing test
address.
Write the command that you use:
_____________________________________________________________
8. Use the ifconfig command to verify that the interfaces were
configured as expected.

Caution – Before performing the next step, bring down and unplumb any
secondary interfaces that might be configured, as described in the
preparation section at the beginning of this exercise.

Configuring IPv6 8-75

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise 2: Configuring IPv6 Multipathing

9. Configure the IPv4 component of your system’s second interface. Be

sure to use the plumb option to enable the interface. Assign an IP,
netmask, and broadcast address; and assign it a status of up.
Write the command that you use:
_____________________________________________________________
10. Configure IPv6 on your system’s second multipathing interface. Be
sure to use the plumb option to enable the interface, assign it to the
multipath group, set an appropriate failover option to cause it to
function properly as a multipathing test address, and assign it a
status of up.
Write the command that you use:
_____________________________________________________________
11. Use the ifconfig command to verify that the interfaces were
configured as expected.
12. Verify that the multipathing daemon is running.
13. Verify that the multipathing is working as expected. Use the ping
command to send an echo request every second from any other IPv6
system to a site-local address on your system. While the ping
command is running, simulate a network failure and disconnect the
network interface cable connected to the interface that you are using
the ping command to detect.
14. Plug in the cable, and notice that the output from the ping
command continues without interruption when the interfaces fail
back.

8-76 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Configuring IPv6 8-77

Exercise 2 Solutions
The output in the following solution is specific to an individual system.
Your results will be different depending upon the system on which you
are working.

Task Solutions
This section provides solutions to the exercise tasks.

Working on Any System

In this section of the exercise, you configure IPv6 multipathing on two

interfaces on your systems. You use both interfaces for standard network
traffic. That is, your system runs at half of its potential capacity in the
event of a network failure on any of the two NICs. You can use any name
that you choose for your multipath group.
1. View your system’s interface configuration to have a baseline before
you make any changes to the system, so that you know the state of
the system if you need to restore the system for any reason.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.2.3 netmask ffffff00 broadcast 192.168.2.255
ether 8:0:20:b8:30:c8
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:b8:30:c8
inet6 fe80::a00:20ff:feb8:30c8/10
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::2:a00:20ff:feb8:30c8/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::2:a00:20ff:feb8:30c8/64
#

8-78 Network Administration for the Solaris™ 10 Operating System

2. Verify that your operating system release can support multipathing.

# cat /etc/release
Solaris 10 3/05 s10_74L2 SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 12 January 2005

This system can support multipathing because it is more recent than the
Solaris 8 10/00 OS.
3. Verify that your system is configured to use unique MAC addresses.
# eeprom local-mac-address?
local-mac-address?=true
#
This system assigns unique MAC addresses to each interface.
What command do you use to cause your system to use unique
MAC addresses?
# eeprom local-mac-address?=true
#

Note – You must reboot the system for EEPROM changes to take place.

Write the name that you are going to assign to your multipath group:
This solution uses a multipath group name of mp-demo.
4. Check your system for interfaces, and decide which interfaces that
you will use for multipathing.
Complete the following fields:
Multipath group name: _________________________
First interface: _______________________________
Second interface: _____________________________
IPv4 address for second interface: __________________
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.2.3 netmask ffffff00 broadcast 192.168.2.255
ether 8:0:20:b8:30:c8
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:b8:30:c8

Configuring IPv6 8-79

inet6 fe80::a00:20ff:feb8:30c8/10
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::2:a00:20ff:feb8:30c8/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::2:a00:20ff:feb8:30c8/64
#
This solution demonstrates use of the hme0 and qfe1 interfaces. The qfe1
interface is not configured for any network traffic at this stage.
● Multipath group name – mp-demo
● First interface – hme0
● Second interface – qfe1
The IPv4 address used for the secondary will be the primary interface’s
address plus 200. For example, 192.168.2.3 uses 192.168.2.203 for
the secondary interface.
5. Configure your first interface as part of the multipath group that you
will use.
# ifconfig hme0 inet6 group mp-demo
#
6. Use the ifconfig command to verify that the interfaces were
configured as expected.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.2.3 netmask ffffff00 broadcast 192.168.2.255
groupname mp-demo
ether 8:0:20:b8:30:c8
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
ether 8:0:20:b8:30:c8
inet6 fe80::a00:20ff:feb8:30c8/10
groupname mp-demo
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::2:a00:20ff:feb8:30c8/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::2:a00:20ff:feb8:30c8/64
#
Observe that the IPv4 interface has also joined the multipath group.
7. Configure a test address for your system’s first multipath interface,
and set the failover option appropriately for a multipathing test
address.
# ifconfig hme0 inet6 -failover
#

8-80 Network Administration for the Solaris™ 10 Operating System

8. Use the ifconfig command to verify that the interfaces were

configured as expected.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.2.3 netmask ffffff00 broadcast 192.168.2.255
groupname mp-demo
ether 8:0:20:b8:30:c8
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:b8:30:c8
inet6 fe80::a00:20ff:feb8:30c8/10
groupname mp-demo
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::2:a00:20ff:feb8:30c8/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::2:a00:20ff:feb8:30c8/64
#
Observe that only the IPv6 interface has a test address assigned to it.

Caution – Before performing the next step, bring down and unplumb any
secondary interfaces that might be configured, as described in the
preparation section at the beginning of this exercise.

9. Configure the IPv4 component of your system’s second interface. Be

sure to use the plumb option to enable the interface. Assign an IP,
netmask, and broadcast address; and assign it a status of up.
Write the command that you use:
# ifconfig qfe1 plumb 192.168.2.203 netmask 255.255.255.0 + broadcast + up
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.2.3 netmask ffffff00 broadcast 192.168.2.255
groupname mp-demo
ether 8:0:20:b8:30:c8
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.2.203 netmask ffffff00 broadcast 192.168.2.255
ether 8:0:20:b8:30:c9
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:b8:30:c8
inet6 fe80::a00:20ff:feb8:30c8/10
groupname mp-demo
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::2:a00:20ff:feb8:30c8/64

Configuring IPv6 8-81

hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2

inet6 fec0::2:a00:20ff:feb8:30c8/64
10. Configure the new IPv6 multipathing interface to be part of the
multipathing group. Set an appropriate failover option to cause it to
function properly as a multipathing test address and assign it a
status of up.
# ifconfig qfe1 inet6 plumb group mp-demo -failover up
#
11. Use the ifconfig command to verify that the interfaces were
configured as expected.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.2.3 netmask ffffff00 broadcast 192.168.2.255
groupname mp-demo
ether 8:0:20:b8:30:c8
qfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.2.203 netmask ffffff00 broadcast 192.168.2.255
groupname mp-demo
ether 8:0:20:b8:30:c9
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
ether 8:0:20:b8:30:c8
inet6 fe80::a00:20ff:feb8:30c8/10
groupname mp-demo
hme0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 2000::2:a00:20ff:feb8:30c8/64
hme0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
inet6 fec0::2:a00:20ff:feb8:30c8/64
qfe1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 3
ether 8:0:20:b8:30:c9
inet6 fe80::a00:20ff:feb8:30c9/10
groupname mp-demo
qfe1:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 2000::2:a00:20ff:feb8:30c9/64
qfe1:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
inet6 fec0::2:a00:20ff:feb8:30c9/64
#

8-82 Network Administration for the Solaris™ 10 Operating System

12. Verify that the multipathing daemon is running.

# ps -ef|grep mpath
root 480 273 0 12:34:29 console 0:00 grep mpath
root 457 1 0 11:46:17 ? 0:00 # /usr/lib/inet/in.mpathd
#
Yes, the multipathing process is running as expected.
13. Verify that the multipathing is working as expected. Use the ping
command to send an echo request every second from any other IPv6
system to a site-local address on your system. While the ping
command is running, simulate a network failure, and disconnect the
network interface cable connected to the interface that you are using
the ping command to detect.
# ping -s fec0::2:a00:20ff:feb8:30c8
PING fec0::2:a00:20ff:feb8:30c8: 56 data bytes
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=0. time=1. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=1. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=2. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=3. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=4. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=5. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=14. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=15. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=16. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=17. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=18. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=19. time=0. ms
64 bytes from fec0::2:a00:20ff:feb8:30c8: icmp_seq=20. time=0. ms
<Control>-C
#
Notice how nine seconds worth of data from the ping command was lost, as
can be seen by looking at the ICMP sequence numbers.
14. Plug in the cable, and notice that the output from the ping
command continues without interruption when the interfaces fail
back.

Configuring IPv6 8-83

Describing the Transport Layer

Objectives
This module describes Transport layer fundamentals, including the
different characteristics of UDP and TCP. In addition, this module
explains TCP flow control.

Upon completion of this module you should be able to:

● Describe Transport layer fundamentals
● Describe UDP
● Describe TCP
● Describe TCP flow control

The course map in Figure 9-1 shows how this module fits into the current
instructional goal.
Configuring the Network

Configuring IP
Configuring Configuring
Network
IP Routing
Multipathing

Describing
Configuring the Transport
IPv6 Layer

Figure 9-1 Course Map

9-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Introducing Transport Layer Fundamentals

The Transport layer transports data to and from the correct application.
This process is known as end-to-end communication. The Transport layer
provides a transport service for application data. Figure 9-2 shows the
position of the Transport layer in the TCP/IP network model.

TCP/IP Layers

Application Layer

Transport Layer

Internet Layer

Network Interface Layer

Hardware Layer

Figure 9-2 Position of the Transport Layer in the TCP/IP Network

Model

Protocol Characteristics
There are two main protocols that operate at the Transport layer, TCP and
UDP. To understand the differences between TCP and UDP, you must be
familiar with the different characteristics of network protocols. The two
protocols associated with the Transport layer, TCP and UDP, are provided
by a kernel-loadable module. Application designers decide which
transport protocol to use for their application.

9-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Connection-Oriented Protocols

With connection-oriented protocols, you must establish a logical

connection with the communication partner before exchanging data.
Figure 9-3 illustrates how a connection-oriented protocol could work.

Figure 9-3 Connection-Oriented Protocol Logical Connection

This method of connection:

● Is highly reliable because of acknowledgements
● Requires more computational processing than connectionless
protocols
● Has more overhead because of connection establishment and
termination

Describing the Transport Layer 9-3

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Connectionless Protocols

Figure 9-4 illustrates how a connectionless protocol could work.

Mail

Figure 9-4 Connectionless Protocol

With connectionless protocols, establishing a connection before sending

data is not necessary. Connectionless protocols transmit self-contained
messages. Self-contained messages:
● Include the full message
● Do not require any response

The connectionless protocol method has virtually no reliability features,

and therefore is best suited for use in highly reliable networks. This
method also requires lower overhead because it has no connection and no
setup requirements. This method is also suited to protocols that use a
broadcast approach to transmit information. This avoids the protocol
having to wait for multiple acknowledgements and having to know how
many acknowledgements to expect.

9-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Stateful Protocols

A stateful protocol is a protocol in which part of the data that is

exchanged between the client and the server systems includes state
information. Both systems keep track of the state of the communication
session. Figure 9-5 illustrates how interaction in a stateful protocol could
work.

Client Server

Figure 9-5 Stateful Protocol

Stateless Protocols

A stateless protocol is a protocol in which neither the client nor the server
system has an obligation to keep track of the state of the communication
session. A stateless protocol does not support most reliability features;
therefore, data that is sent can be lost or delivered out-of-sequence.
Figure 9-6 illustrates how interaction in a stateless protocol could work.

Client Server
Figure 9-6 Stateless Protocol

The advantages of a stateless protocol are that it has lower overheads and
it has a degree of isolation between the client and the server.
Connectionless protocols are typically stateless.

Describing the Transport Layer 9-5

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Reliable Protocols

A reliable protocol requires that each transmission is acknowledged by

the receiving host. The sender retransmits, if necessary. Figure 9-7 shows
how a reliable protocol could work.
Sender Receiver

Time
Send Packet 1
1

Receive Packet 1
Send Acknowledgement (ACK)

Receive ACK
Send Packet 2
3

Receive Packet 2
Send ACK
4

Receive ACK
Send Packet 3
5 Packet Lost

Timeout
Resend Packet 3
6 7 Receive Packet 3

Figure 9-7 Reliable Protocol

9-6 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Unreliable Protocols

An unreliable protocol does not require that each transmission is

acknowledged by the receiving host. Figure 9-8 shows how an unreliable
protocol could work.
Sender Receiver

Time
Send Packet 1
1

Send Packet 2
2

Send Packet 3
3 Packet Lost

Send Packet 4
4

Figure 9-8 Unreliable Protocol

Describing the Transport Layer 9-7

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing Transport Layer Fundamentals

Transport Protocols in TCP/IP

The Transport layer header includes a destination port number that
identifies the destination application program on the remote machine and
a source port number that identifies the application on the originating
machine.

In addition, the Transport layer handles error detection, can handle

recovery problems, and can regulate the flow of information. The way in
which the Transport layer handles error detection, the sequence of data,
and flow regulation depends on which protocol is used.

The TCP/IP protocol stack features two Transport layer protocols, TCP
and UDP. Figure 9-9 shows an analogy that compares TCP and UDP.
TCP

Certified

UDP

Uncertified

Figure 9-9 TCP and UDP Analogy

9-8 Network Administration for the Solaris™ 10 Operating System

Introducing UDP
UDP is a connectionless, stateless, and unreliable protocol. UDP is
designed for applications that do not require a reliable Transport layer
mechanism. UDP packets can be lost, duplicated, or delivered
out-of-order. The application program that uses UDP is responsible for
reliability, sequencing, and flow control, if required.

Purpose of UDP
UDP gives an application direct access to the Internet layer and includes
the source and the destination port numbers. UDP does not require that
the receiving host acknowledge transmissions. UDP has low overhead,
and it is designed for high-speed applications that run on reliable
networks. UDP is also used by Application layer protocols that transmit
information by broadcast mechanisms.

UDP Datagram Header

UDP receives incoming data from the application and encapsulates the
data in UDP datagrams. UDP datagrams have a leading header section,
shown in Figure 9-10, that contains the source and destination port
numbers, followed by the data section. UDP datagrams are sent to the
Internet layer for encapsulation and delivery. Large UDP datagrams can
be fragmented by IP.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Source Port Destination Port

Length Checksum

Figure 9-10 UDP Header

Describing the Transport Layer 9-9

Introducing TCP
TCP is a connection-oriented, stateful, and reliable protocol.

TCP is suited for situations where large volumes of data must travel
between systems, particularly across multiple routers and gateways. TCP
has four main features:
● Virtual circuit connection
● Full-duplex connection
● Unstructured stream orientation
● Buffered transfer

TCP Segment Header

The TCP segment header has many fields. Figure 9-11 shows the segment
header with its fields.

Figure 9-11 TCP Segment Header

Notice that the segment header includes sequence and acknowledgment

numbers that are used for connection-oriented and stateful connections.
Refer to RFC 793 and RFC 3168 for additional information.

9-10 Network Administration for the Solaris™ 10 Operating System

Virtual Circuit Connection

TCP must establish a connection between the sender and receiver before
the transmission can start. This is similar to making a phone call: the line
must be established before you can begin to talk.

Full-Duplex Connection
TCP connections provide concurrent transfer in both directions. A
full-duplex connection consists of two independent streams of data that
flow in opposite directions. The TCP protocol software sends control
information for one stream back to the source in the segments that carry
data in the opposite direction. This process is called piggybacking, and it
reduces network traffic.

Unstructured Stream Orientation

Data originating from the Application layer flows to TCP as a stream of
bytes. This stream of bytes is divided into packets called segments. As
seen previously, TCP segments have a leading header section that
contains control information, source and destination port numbers, and a
data section. The content in the data section is not read or translated by
TCP. TCP then sends the segments to the Internet layer for encapsulation
and delivery.

Buffered Transfer
Data that comes from the application is a flowing stream. Data can flow
fast or slow. To ensure the efficient flow of data to and from the
application, TCP provides both input and output buffers to regulate the
flow of data. The input and output buffers also enable the application to
see TCP as a full-duplex connection.

Describing the Transport Layer 9-11

Introducing TCP Flow Control

TCP is more than a basic send-receive-acknowledge-send progression.
TCP has sophisticated algorithms to optimize flow control on both the
sender side and the receiver side. The algorithm that implements flow
control on both the sender side and the receiver side follows what is
known as the sliding window principle.

Receiver-Side Window Advertisements

A TCP window advertisement determines the maximum amount of data
that can be sent before the sender must wait for an acknowledgement
from the receiver. By advertising its window size, the receiving side
manages flow control. With window advertisements, the receiving host
continually informs the sending host of how much data it is prepared to
receive.

Each TCP segment from the receiving side carries an acknowledgement

and a window advertisement. Each acknowledgement specifies that a
particular segment was received, and each window advertisement
specifies how many additional bytes the receiver is prepared to accept.
The size contained in the window advertisements varies over time;
therefore, it is considered a sliding window.

Sender-Side Congestion Window

To avoid network congestion, TCP maintains a congestion window on the
sending side. The congestion window adjusts the amount of data that can
be sent according to the number of segments that were recently lost or
acknowledged in transit. Lost segments are detected if a transmission
timeout occurs before an acknowledgement for the segment is received.

As acknowledgements begin to be received, TCP doubles the size of the

congestion window. If congestion is detected, TCP reduces the congestion
window size by one-half. If congestion continues, the congestion window
can be reduced in size by one-half multiple times.

Depending upon the severity of the congestion, TCP can use either a
slow-start or congestion-avoidance algorithm to begin to increase the size
of the congestion window. The slow-start algorithm quickly increases
window size by doubling it for each successful transmission. The
congestion-avoidance algorithm slowly increases the window’s size by
increasing it only one segment at a time for each successful transmission.

9-12 Network Administration for the Solaris™ 10 Operating System

TCP Large Window

The Solaris 10 OS implements RFC 1323, which permits larger TCP
window advertisement sizes to enhance performance over high-delay,
high-bandwidth networks, such as satellite networks.

A standard TCP header uses a 16-bit field to report the receiver window
size to the sender. Therefore, the largest window that can be used is 216 or
64 kilobytes (Kbyte). RFC 1323 introduces a mechanism to increase the
window size to 230 or 1 gigabyte (Gbyte).

Describing the Transport Layer 9-13

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Exercise: Describing the Transport Layer

Exercise: Describing the Transport Layer

In this exercise, you:
● Define Transport layer terms
● Describe why an application programmer uses an unacknowledged
transmission protocol
● Review the differences between TCP and UDP

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Tasks
Complete the following steps:
1. Match the terms to their definition.

_____ Sliding window a. A protocol that establishes a

communication session before
sending data
_____ UDP b. A reliable, stateful, and
connection-oriented Transport
layer protocol
_____ Connection-oriented c. An unacknowledged Transport
protocol layer protocol
_____ TCP d. A principle that optimizes TCP
flow control

2. Why would an application programmer use an unacknowledged

transmission protocol?
____________________________________________________________
____________________________________________________________

9-14 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Describing the Transport Layer 9-15

Exercise Solutions
Solutions to the exercise are as follows:
1. Match the terms to their definition.

d Sliding window a. A protocol that establishes a

communication session before
sending data
c UDP b. A reliable, stateful, and
connection-oriented Transport
layer protocol
a Connection-oriented c. An unacknowledged Transport
protocol layer protocol
b TCP d. A principle that optimizes TCP
flow control

2. Why would an application programmer use an unacknowledged

transmission protocol?
UDP has less overhead than TCP. UDP is best suited for short bursts of
communication or broadcast communication.

9-16 Network Administration for the Solaris™ 10 Operating System

Configuring DNS

Objectives
This module describes the basic components of DNS, including the
Berkeley Internet name domain (BIND), top-level domains, zones of
authority, server types, the name resolution process, and resource records.
This module also describes DNS configuration, including gathering
needed information, editing the BIND configuration file and other
relevant files, and performing basic troubleshooting procedures.

Upon completion of this module, you should be able to:

● Describe the basics of DNS
● Configure a DNS server
● Troubleshoot a DNS server by using basic utilities

The course map in Figure 10-1 shows how this module fits into the
current instructional goal.

Configuring and Managing Network Applications

Configuring the
Configuring Configuring Configuring Solaris™ IP
DNS DHCP NTP Filter Firewall

Figure 10-1 Course Map

10-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Introducing DNS Basics

Introducing DNS Basics

The DNS name space is composed of a set of hierarchical domains
arranged in a manner similar to the branches of an inverted tree.

BIND
BIND is the most frequently used implementation of DNS in the UNIX
environment. The Solaris 10 OS implements the BIND 9, version 9.2.4
software.

Note – Earlier versions of the Solaris OS implemented the BIND 8

software. In BIND 8 the daemon is /usr/sbin/in.named. In BIND 9 the
daemon is /usr/sbin/named.

The latest versions of the BIND software are available from the Internet
Systems Consortium’s (ISC) Web site, http://www.isc.org/. You can
download and compile the latest version; however, Sun Microsystems,
Inc. does not support this action.

Top-Level Domains
A domain:
● Is a collection of names that identifies network hosts and is a logical,
not physical entity. A domain is maintained by a group of
administrators. A single network can consist of hosts that belong to
many different domains.
● Is an index for looking up information in the DNS distributed
database.
● Can be branches or leaves in the DNS tree. Branches represent
collections of names in a common domain. Leaves represent
individual nodes and are considered domains unto themselves.
● Represents nodes or systems by name in the DNS naming tree,
which might not be in physical proximity. In other words, a domain
can span a large physical area.
● Can be broken into subdomains and can delegate authority for those
subdomains to another group of administrators.

10-2 Network Administration for the Solaris™ 10 Operating System

The top of the DNS hierarchy contains a nameless root domain. This
domain is a place holder containing names and servers for the top-level
domains. The IANA controls the root domain. The ICANN non-profit
group is the governing body of all IP address assignments and domain
names and controls the root domain.

Top-level domains are below the root domain. Top-level domains (TLDs)
include currently domains such as com, edu, gov, org and arpa. All
top-level domains are controlled currently by the ICANN. The proposals
for new TLDs are available at the http://www.icann.org/tlds URL.
Table 10-1 shows top-level domains and their descriptions.

Table 10-1 DNS Top-Level Domain Examples

Domain Description
com Commercial organizations (predominately in the
United States (U.S.))
edu Educational organizations
gov Governmental organizations (U.S.)
mil Military organizations (U.S.)
net Networking organizations and ISPs
org Non-profit and other organizations
arpa Reverse address lookups
ca Country-based domains, Canada in this example

Top-level domains have two main categories: organizational domains and

geographical domains. Organizational domains are based on the function
or the purpose of the domain. Geographical domains are based on the
physical location of the domain.

Second-level domains are below the top-level domains. The second level is
usually the first place that the ICANN delegates authority for a domain to
some other local organization. The ICANN, available at the
http://www.icann.org Web site, authorizes domain registrars to sell
domain names. The second-level domain, sun.com, for example, is
controlled by administrators of Sun Microsystems, not ICANN.

Configuring DNS 10-3

An organization can break up their second-level domains into lower-level

domains. This is usually done on an organizational, political, or as-needed
basis. For example, a large, multinational corporation might divide its
domain into country-based domains. A university might divide its
domain into department-based domains.

Lower-level domains can be split into more lower-level domains as

needed. All domains are subject to naming length restrictions. There is a
255-character maximum for a fully qualified domain name (FQDN), and a
63-character limit for an individual domain name. Fully qualified is
analogous to an absolute path in a file name.

Zones of Authority
In addition to dividing the name space into administrative domains, the
name space also divides into various zones of authority. These zones:
● Are the portion of the name space for which a server is authoritative
(that is, contains information for domains over which the server has
naming control in the form of resource records in the servers’
configuration files)
● Consist of at least one domain and its associated data
● Can span one or more domains

Server Types
DNS implements name resolution. The following are some of the more
common server types, which are described in more detail in this section.
Note that a single system can fulfill more than one role. For example, a
system might be a primary server for one zone and a secondary server for
a different zone. All servers also cache information.

The types of server are:

● Root servers
● Primary servers
● Secondary servers
● Caching-only servers
● Forwarding servers

10-4 Network Administration for the Solaris™ 10 Operating System

Root Servers

Root servers maintain data about each of the top-level zones. There are (as
of September, 2004) 13 root servers. Of these servers, nine serve the root
and top-level domains, and four serve the root domain only. ICANN
maintains the root servers, and the servers are moved to a common
domain for consistent naming purposes. The root servers are currently
named A.root-servers.net., B.root-servers.net., and so on.

You can download a current copy of the named.root file, which contains
a list of the current root servers, from the
ftp://ftp.rs.internic.net/domain/named.root URL.

Primary Servers

Each DNS zone must have a primary server. Although DNS does not
prohibit having more than one primary server, maintaining multiple
primary servers is difficult and is prone to having errors occur; therefore,
it is not frequently done. In the /etc/named.conf file, the keyword
master indicates the primary server.

Primary servers have the following features:

● They are the system on which all changes are made to the zone.
● They are authoritative servers for all zones that they serve. (See the
following sections for definitions of authoritative and
non-authoritative servers.)
● They provide update information and synchronize secondary servers
when the secondary servers request information.
● They can specify the delegation of authority for subdomains.

Secondary Servers

Each domain should have at least one secondary server. The ICANN does
not permit a domain to be registered officially as a subdomain of a
top-level domain until a site demonstrates two working DNS servers.

Configuring DNS 10-5

Secondary servers have the following features:

● There can be one or more secondary servers per zone.
● They obtain a copy of the zone information through zone transfers
for all domains that they serve from the appropriate primary server
or from another secondary server for the zone.
● They are authoritative for all of the zones that they serve; that is,
their answers to queries are considered highly accurate.

Caching-Only Servers

All DNS servers cache information for any domain for which they are not
authoritative. Caching-only servers are servers that are not authoritative
for any zone, but instead caches responses from other, authoritative, name
servers. Over time, the size of the cache grows.

Caching-only servers have the following features:

● They provide a rich cache of the most commonly accessed
namespace information.
● They are never authoritative for any domain, with the exception of
the loopback address.
● They reduce overhead that is associated with secondary servers that
perform zone transfers from primary servers.
● They permit DNS client access to naming information that is locally
cached without the expense of setting up a primary or a secondary
DNS server.

Forwarding Servers

Forwarding servers are DNS servers intended to act as focal points for all
off-site DNS queries. Off-site queries are queries for remote information.
Designating a server as a forwarding server causes all off-site requests to
consult initially the forwarding server or servers, and to wait for a reply. If
no reply is received from the forwarders, the name server resumes normal
operations and contacts the remote name servers itself.

Forwarding servers have the following features:

● All off-site queries go through forwarders first.
● The server that is used as a forwarder builds up a rich cache of
information, which reduces the number of redundant off-site
requests.

10-6 Network Administration for the Solaris™ 10 Operating System

● Special setup on forwarders is not required.

● Servers using forwarders are configured by adding a forwarder
directive to the /etc/named.conf file on the local servers.
● The local server can still contact the remote site if forwarders fail to
respond to queries.

Note – If a name server uses the directive forward only in addition to

the forwarders directive, then the name server may not contact remote
name servers on its own.

Answer Types
Answers that are returned from DNS servers can be described as
authoritative or non-authoritative.

Answers from authoritative DNS servers are:

● Sourced from a disk-based file.
● Usually correct. Because humans administer the DNS, it is possible
for incorrect data to enter the DNS database.

Answers from non-authoritative DNS servers are:

● Sourced from a server cache
● Usually correct
● Can be incorrect if the server’s cache contains stale data

Name-Resolution Process
DNS name resolution is the process of translating a domain name to an IP
address or translating an IP address to a domain name.

Name resolution begins with client-side resolver code. Resolver code is

built into the operating system libraries and is available to programs that
use system interface calls.

Configuring DNS 10-7

Client-resolver code:
● Does not cache any information
● Queries the DNS servers that are specified in the /etc/resolv.conf
file
● Is activated by a reference to DNS in the /etc/nsswitch.conf file
hosts entry

10-8 Network Administration for the Solaris™ 10 Operating System

A DNS client uses the following steps to query a name server to resolve
name-to-address or address-to-name requests. Figure 10-2 shows a client
attempting to resolve the ftp.internic.net name to an IP address.

1 /etc/nsswitch.conf File

2 /etc/inet/hosts File

3 LDAP Hosts Database

4 /etc/resolv.conf File

Local Name Server

5 6 Cache

Local Name Server

root Name Server
7 8

Local Name Server

net. Name Server
9 10

Local Name Server

internic.net. Name Server
11 12

Figure 10-2 DNS Name Resolution Process

Configuring DNS 10-9

The following describes the DNS name-resolution process where the

/etc/nsswitch.conf file has the following contents:
# cat /etc/nsswitch.conf
...
hosts: files ldap dns
...
#

The /etc/inet/hosts file has the following contents:

# cat /etc/inet/hosts
# Internet host table
127.0.0.1 localhost loghost
192.168.30.31 sys11ext # router to get to instructor
192.168.1.1 sys11
#

The following steps describe the DNS name-resolution process.

1. The client system consults the /etc/nsswitch.conf file to
determine the name resolution order. In this example, the order is
the local file, the Lightweight Directory Access Protocol (LDAP)
server, and then the DNS server.
2. The client system consults the local /etc/inet/hosts file and does
not find an entry.
3. The client system sends a query asking for the IP address of the
Internet name, ftp.internic.net., to the LDAP server and finds
no address.
4. The client system consults the /etc/resolv.conf file to determine
the name resolution search list and the address of the DNS servers.
5. The client system resolver routine sends a recursive DNS query
asking for the IP address for the Internet name,
ftp.internic.net., to the local DNS server. A recursive query
states: “I will wait for the answer, and you do all of the work.” The
client waits until the local server completes name resolution.
6. The local DNS server consults the contents of its cached information
in case this query has been recently resolved. If the address is in the
local cache, it is returned to the client as a non-authoritative answer.

10-10 Network Administration for the Solaris™ 10 Operating System

7. If the local DNS server does not have cached information about the
net or internic domains, it contacts one of the root servers and
sends an iterative query. An iterative query states: “Send me the best
answer you have, and I will do all of the work.” In this example, the
assumption is that the answer is not cached and that a root server
must be contacted.
8. The root server returns the best information it has. In this case, the
only information you are guaranteed is that the root server has the
names and addresses of all the net domain servers. The root server
returns these names and addresses along with a TTL value that
specifies how long the local DNS server can cache this information.
9. The local DNS server contacts one of the net domain servers
returned from the previous query and transmits the same iterative
query that was previously sent to a root server.
10. The net domain server that is contacted returns the best information
it has, which are the names and addresses of the internic.net
servers and a TTL value.
11. The local DNS server contacts one of the internic.net domain
servers and makes the same query for the IP address for the Internet
name, ftp.internic.net.
12. An internic.net server returns the IP addresses of the Internet
name, ftp.internic.net, along with a TTL value.

The local DNS server returns the requested address to the client system,
and the client can proceed.

Resource Records
Resource records are entries contained in the name server zone files and
are not case sensitive. A resource record can contain information that
pertains to a particular domain, including the server addresses, cache
time-out values, and the email address of the DNS administrator.
Resource records can also include information about a particular system
including its IP address, its domain name, and its contact information.

Although each type of resource record has specific syntax, the general
format of any resource record is:
[name] [ttl] class type data

Configuring DNS 10-11

Resource records have the fields shown in Table 10-2.

Table 10-2 Resource Record Fields

Field Description

name Specifies the domain name for which the resource record is
defining information. Because DNS is a distributed database,
this record also defines the possible key values that are used
in DNS queries. The sys12.one.edu and one.edu names
are examples of domain names.
ttl Specifies the cache TTL value that is given to remote DNS
servers when they query the information specified by this
record. This value is expressed in seconds, days, hours, and
so on. An example is 86400, which represents one day in
seconds, which can also be expressed as 1d.
class Specifies the type of network. The examples in this module
only use the IN or Internet class.
type Specifies the type of information that is defined for the
domain in field 1. Table 10-3 on page 10-13 shows commonly
used resource record types.
data Defines the appropriate data for this resource record and
depends on the record type specified in field 4, the type
field. Some record types specify a single argument in this
field, and other record types specify multiple arguments in
this field. Examples of a record type with multiple
arguments include a host name, an IP address, and an email
address.

Depending on the record type and other shortcuts being taken, not all of
the fields are always required.

Record Types

DNS zone files can contain blank lines and comments. Comments begin
with a semicolon.

10-12 Network Administration for the Solaris™ 10 Operating System

Table 10-3 shows examples of record types and their purposes.

Table 10-3 Examples of Resource Record Types

Record Type Purpose

$TTL The $TTL record identifies the cache TTL value that
remote DNS servers receive when they query the
information specified by this record.
SOA The start of authority (SOA) record identifies the
primary name server, contact information, and default
cache TTL values for all resource records in the domain.
NS The name server (NS) record specifies the name server
for a domain.
A The address (A) record specifies an IP address for a host
name.
PTR The pointer (PTR) record specifies a host name for an IP
address (used for inverse lookups and IP
address-to-host names).
CNAME The canonical name (CNAME) record defines a host name
alias (www can substitute for a specific host name).
AAAA The quad-A (AAAA) record specifies an IPv6 address for
a host name.

Following are examples of resource record types:

● The SOA resource record type:
$TTL 8h
. IN SOA instructor.thirty.edu. root.instructor.thirty.edu. (
20040923 ; version number
10800 ; refresh (3hrs.)
3600 ; retry (1hr.)
691200 ; expire (8days)
3600 ) ; negative caching info. kept for 1 hour
● The NS resource record type:
one.edu. IN NS sys12.one.edu.
● The A resource record type:
sys12.one.edu. IN A 192.168.1.2

Configuring DNS 10-13

● The PTR resource record type:

2.1.168.192 IN PTR sys12.one.edu.
● The CNAME resource record type:
www.one.edu. IN CNAME sys12.one.edu.

The $TTL directive identifies the cache TTL value that remote DNS servers
receive when they query the information specified by this directive. This
directive, or control statement, was not available for use until BIND 8.2.x
versions.

10-14 Network Administration for the Solaris™ 10 Operating System

Configuring a DNS Server

The DNS server daemon is the /usr/sbin/named process. This daemon
provides a service in the SMF. The named daemon is started at boot time
only if the /etc/named.conf file exists and the appropriate SMF service
is enabled.

The following svcs command is used to determine the status of the

DNS-related services:
# svcs -a | grep dns
disabled Oct_22 svc:/network/dns/client:default
disabled Oct_22 svc:/network/dns/server:default

The following svcadm commands enable the DNS naming service and the
default client service:
# svcadm enable svc:/network/dns/server:default
# svcadm enable svc:/network/dns/client:default

# svcs -a | grep dns

online 23:02:34 svc:/network/dns/client:default
online 23:08:27 svc:/network/dns/server:default

Note – The DNS client service will not start any new processes, but when
enabled, checks that the system is configured as a DNS client with an
/etc/resolv.conf file. Other services used for managing application
and daemons that require DNS, such as LDAP, will have a dependency on
the DNS client service to ensure that the system is a DNS client.

Gathering Information
When you configure a DNS server, supply the server with the following
types of information:
● The names and addresses of root servers.
● The information required to resolve all domains for which the server
is authoritative. This information consists of name-to-address
translations.

Configuring DNS 10-15

● The information needed to resolve all reverse domains for which the
server is authoritative. This information consists of address-to-name
translations.
● The names and addresses of servers for all domains that are one
level below the domains being served by this server. This
information is sometimes referred to as parenting or delegating.

Editing the BIND Configuration File

BIND version 8.x.x and later versions use a new configuration file,
/etc/named.conf, that replaced the /etc/named.boot file used in
versions 4.9.x and earlier. A BIND version 4.9.x named.boot file can be
converted to a named.conf file by running the
/usr/sbin/named-bootconf script.

The /etc/named.conf file contains statements that:

● Indicate the location of the file that includes the root servers
● Establish the server as a primary, a secondary, or a caching-only
server
● Specify the server’s zones of authority
● Indicate the location of the server’s data files
● Apply security selectively for specific zones
● Define logging specifications
● Apply options selectively for a set of zones

The named daemon reads the /etc/named.conf file when the daemon is
started by the SMF. The configuration file directs the named daemon either
to other servers or to local data files for a specified domain.

The /etc/named.conf file contains statements and can contain

comments. Statements end with a semicolon (;), they can contain a block
of statements enclosed within curly braces ({}), and each statement in the
block is terminated with a semicolon (;). Comments can start with /* and
end with */, can follow either # or //, and can extend to the end of the
line.

10-16 Network Administration for the Solaris™ 10 Operating System

Table 10-4 shows /etc/named.conf statements and their definitions.

Table 10-4 Statement Definitions for the /etc/named.conf File

Statement Definition

acl Defines a named IP address match list used for access

control. The address match list designates one or more
IP addresses or IP prefixes. The named IP address
match list must be defined by an acl statement before
it can be used elsewhere. No forward references are
permitted.
options Controls global server configuration options, and sets
default values for other statements.
zone Defines a zone. It applies options selectively on a
per-zone basis, rather than to all zones.

Configuring DNS 10-17

Figure 10-3 shows the contents of the /etc/named.conf file.

/etc/named.conf

options {
DIRECTORY "/var/named"; /var/named
};
acl "nets"{
{192.168.1.0/24;};
};
zone "." in {
type hint;
file "named.root"; named.root
};
zone "one.edu" in {
type master;
file "forward.zone"; forward.zone

allow-transfer {"nets";};
};
zone "1.168.192.in-addr.arpa" in {
type master;
file "reverse.rzone";
}; reverse.rzone
zone "0.0.127.in-addr.arpa" in {
type master;
file "loop.back"; loop.back
};
/* This is a comment */
// This is a comment
# This is a comment

Figure 10-3 The /etc/named.conf File

10-18 Network Administration for the Solaris™ 10 Operating System

Editing the named.root File

The /var/named/named.root file specifies name-to-address mappings
for the root servers.

The information in this file is described as hints to the named daemon

because the daemon attempts to contact one of the root servers listed until
one of the servers responds. The responding root server returns a list of
root servers. The name daemon uses this list that is returned from the root
server and does not use the servers that are specified in the hints file
again until the TTL value expires on the cached root-server information.

Accordingly, it is not imperative that this file be precisely up-to-date, but

it should be checked every few months because root servers change from
time to time.

The following is a modified (the IN entries for servers D–L have been
removed in order to conserve space on this page) excerpt taken from the
named.root file available at the ftp://ftp.rs.internic.net/
domain/named.root URL:
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 IN NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 IN NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
< Part of file truncated>
; housed in Japan, operated by WIDE
;
. 3600000 IN NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

Configuring DNS 10-19

In the first record:

● The dot (.) in the first field denotes the root domain.
● The TTL field is 3600000 seconds. This field is historic and is not
used in this file.
● The IN class stands for Internet.
● The NS record type indicates that a name server is being defined for
the root domain.
● The fifth field of the first record (the data field) is the FQDN of a
root server. Note the trailing dot associated with this field.

In the second record:

● The first (domain) field contains the FQDN of the root server that is
defined in the previous record.
● The TTL field is 3600000 seconds. This field is historic and is not
used in this file.
● The record type, A, contains an IP address.
● For A records, the fourth data field contains the IP address of the root
server that is specified in the first field.

The NS and A records combine to define the name and address of a single
root server. This file specifies additional pairs of records, as appropriate.

10-20 Network Administration for the Solaris™ 10 Operating System

Editing the Forward Domain File

The forward domain file (db.one.edu, in this example) contains the
mappings of host names to IP addresses for all systems in the domain that
are being served by this name server. In addition, this file must specify an
SOA record and NS records for all name servers for this domain. See
Figure 10-3 on page 10-18 for more information on this example.
$TTL 86400

;{name} {ttl} Class SOA Origin Postmaster

;----------------------------------------------------------------------------------
@ IN SOA sys12.one.edu. root.sys12.one.edu. (
2005010101 ; Serial
3600 ; Refresh (1 Hour)
1800 ; Retry (30 Minutes)
6048000 ; Expire (1 Week)
86400 ) ; Minimum (24 Hours)

;
;{name} {ttl} Class NS Nameserver Name
;------------------------------------------------------
IN NS sys12.one.edu.
IN NS sys13.one.edu.

;
;{name} {ttl} Class A IP Address
;-------------------------------------------------
sys11 IN A 192.168.1.1
sys12 IN A 192.168.1.2
sys13 IN A 192.168.1.3
sys14 IN A 192.168.1.4

localhost IN A 127.0.0.1

;
;{name} {ttl} Class CNAME Canonical Name
;-------------------------------------------------------
router IN CNAME sys11
dns IN CNAME sys12

The $TTL directive sets the default time to live for the zone’s information
to eight hours.

Configuring DNS 10-21

The SOA record is mandatory and has the following items:

● An at sign (@) in the name field – This is a shortcut for the domain
that is being served (one.edu. in this case). The actual value for the
@ comes from the second field of the appropriate record in the
named.conf file that references this file. The @ also defines the
default origin that determines the domain appended to any partially
qualified domain name in the configuration file’s resource records.
● Data field argument 1 (sys12.one.edu.) – This is the name of the
primary master server for this domain in FQDN format.
● Data field argument 2 (root.sys12.one.edu) – This is an email
address, in the format of DNS_admin_name.domain_name, that you
can use to report problems with the domain. The administrator is
usually the root user, as shown in this example. Note that the @ is
replaced with a dot in the SOA record because the @ has special
meaning in this file.
● Data field argument 3 – This is the version (Serial) number that the
secondary slave servers use to determine if they need to perform a
zone transfer to get a fresh copy of zone data. Any time you make
changes to this file, remember to update this number in such a way
that it gets larger. It is always safe to start at 1 and add 1 with each
change, or to use today’s date.
● Data field argument 4 – The refresh timer is the time interval, in
seconds, after which the secondary servers should check to
determine if the serial number has changed, and, if it has, a zone
transfer needs to occur.
● Data field argument 5 – The retry timer is the time interval, in
seconds, after which the secondary servers check back if a normal
refresh failed. This timer is usually set to a smaller value than the
refresh timer.
● Data field argument 6 – The expire timer is the time interval in
seconds after which, if a secondary server cannot contact the primary
server or another secondary server, the entire zone data should be
discarded. This prevents the secondary servers that have lost contact
with the rest of the name servers from continuing to give out
potentially stale information.
● Data field argument 7 – The negative caching timer (Minimum) is the
default value of time that the server keeps negative responses from
other authoritative servers.

You should define an NS record for all name servers in this domain that
you want to be recognized by DNS servers.

10-22 Network Administration for the Solaris™ 10 Operating System

Most of the remaining resource records are address records for each
system in the domain. Most of the host names are not fully qualified. The
names that are not fully qualified have the domain name origin (the value
of the @ in the SOA record by default) appended to them. This shorthand
method can save typing and improve the readability and maintainability
of the file.

The CNAME record defines host aliases, or nicknames for hosts. The CNAME
record in this instance is similar to the following entry in a
/etc/inet/hosts file:

192.168.1.1 sys11 router

The localhost entry specifies the loopback address for all hosts.

Configuring DNS 10-23

Editing the Reverse Domain File

Reverse domain files (db.192.168.1, in this example) contain mappings
for address-to-name translation. Address-to-name translation is important
and is used by various utilities, such as NFS, web servers, BIND, and
sendmail.

The following is an example of a reverse domain file:

; Information for the "reverse" domain 1.168.192.in-addr.arpa.
$TTL 86400

;
;{name} {ttl} Class SOA Origin Postmaster
;----------------------------------------------------------------------------------
@ IN SOA sys12.one.edu. root.sys12.one.edu. (
2005010101 ; Serial
3600 ; Refresh (1 Hour)
1800 ; Retry (30 Minutes)
6048000 ; Expire (1 Week)
86400 ) ; Minimum (24 Hours)

;
;{name} {ttl} Class NS Nameserver Name
;------------------------------------------------------
IN NS sys12.one.edu.
IN NS sys13.one.edu.

;
;{name} {ttl} Class PTR Real Name
;------------------------------------------------
1 IN PTR sys11.one.edu.
2 IN PTR sys12.one.edu.
3 IN PTR sys13.one.edu.
4 IN PTR sys14.one.edu.

Observe the following about this file:

● The @ (at the top of this resource record) in this example refers to the
1.168.192.in-addr.arpa. reverse domain, as indicated in the
/etc/named.conf file in which this reverse file is referenced.
● The address-to-name mappings are defined with the PTR record type.
The domain field in the PTR record contains the host portion of the IP
address. Because these resource records do not end with a . (dot), the
value of the @ is appended to each record. The argument field of the
PTR record should contain the FQDN of the name of the system at
which the record points. This completes the reverse address-to-name
mapping.

10-24 Network Administration for the Solaris™ 10 Operating System

Editing the Reverse Loopback Domain File

Reverse loopback domain files specify the reverse loopback domain
address-to-name translation. The contents are hard-coded, with the
exception that the server name changes depending upon on which server
the file is installed. This file is required on all DNS servers. Every name
server is the master for its own loopback address.

Here is an example (db.127.0.0) of a reverse loopback domain file:

$TTL 86400

;
;{name} {ttl} Class NS Nameserver Name
;------------------------------------------------------
IN NS sys12.one.edu.
IN NS sys13.one.edu.

;
;{name} {ttl} Class PTR Real Name
;------------------------------------------------
1 IN PTR localhost.

Observe the following about this file:

● You can use the @ when the domain name is the same as the origin,
127.in-addr.arpa. in this example.
● The only items that you change from domain to domain in the SOA
record are the host name (first) argument and the email address used
to report problems.
● You must specify the name of the system being configured on the NS
line.
● Use all other lines as shown in this example.

Configuring DNS 10-25

Configuring Dynamic Updates

Dynamic updates cause a DNS server to be updated automatically with
DHCP host information from a DHCP server. This enables nomadic
DHCP users to have access to systems and services without manual
administration.

To configure a server to permit dynamic updates to occur, complete the

following steps:
1. Log in as root on the DNS primary server, edit the
/etc/named.conf file, and add allow-update statements to both
the forward and reverse zones. For example:
zone "one.edu" in {
type master;
file "db.one.edu";
allow-update { 127.0.0.1; 192.168.1.2; };
};

zone "1.168.192.in-addr.arpa" in {
type master;
file "db.192.168.1";
allow-update { 127.0.0.1; 192.168.1.2; };
};
2. Restart the named process by using the svcadm commands. For
example:
# svcadm restart svc:/network/dns/server:default
#
or
# svcadm disable svc:/network/dns/server:default
# svcadm enable svc:/network/dns/server:default

10-26 Network Administration for the Solaris™ 10 Operating System

Configuring Security
Because of the nature of the Internet, DNS can be vulnerable to
unauthorized access.

Beginning with BIND version 8.x.x, security features are implemented

through the /etc/named.conf configuration file. Two important security
considerations are the control of name queries and the control of zone
transfers. By default, servers respond to any query or request for a zone
transfer. You can modify this behavior by using the allow-query and
allow-transfer keywords.

The allow-query statement enables you to establish an IP address-based

access list for queries. You can apply this access list to a specific zone or to
all queries that are received by the server. The IP address list determines
which systems receive responses from the server.

You can restrict queries to all zones by using the allow-query keyword
as an argument to the options statement for the zone.

For example:
options {
allow-query { 192.168.1/24; 192.168.3/24; };
};

In this case, only systems with the IP addresses 192.168.1.xxx and

192.168.3.xxx receive responses from the name server.

You can restrict queries for a specific zone by using the allow-query
keyword as an argument to the zone statement. For example:
zone "one.edu" in {
type master;
file "forward.zone";
allow-query { 192.168.3/24; };
};

In this case, only subnet 192.168.3.0 has access to the resource records
for this zone.

Configuring DNS 10-27

In the same manner, the allow-transfer keyword can limit which

systems may receive a zone transfer from a name server. You can restrict
zone transfers from a name server by using allow-transfer in the
options statement. For example:
options {
allow-transfer { 192.168.1.3/32; };
};

The allow-transfer keyword can also be applied to a specific zone, if

you want. Another feature that often is associated with restricting queries
and transfers is access control lists (ACLs). The list of IP addresses used in
the previous examples could be replaced by an ACL.

You can configure ACLs by using the acl keyword to build an ACL list
that can be used as an argument to the allow-query and
allow-transfer keywords.

For example:
acl "local" { 192.168.1.0/24; 192.168.2.0/24; 192.168.3.0/24; };

zone "one.edu" in {
type master;
allow-query { "local"; };
allow-transfer { "local"; };
};

10-28 Network Administration for the Solaris™ 10 Operating System

Configuring Secondary DNS Servers

The contents of the /etc/named.conf file on the secondary DNS server
can be less complex than that of the primary server. If a server is to act as
both a primary server for some domains and a secondary server for other
domains, the /etc/named.conf file must contain keywords that are
appropriate to both functions. The master keyword denotes a primary
server for a domain, and the slave keyword denotes a secondary server
for a domain when used as arguments to the type directive.

An example of an /etc/named.conf file for a secondary server is:

options
{
directory "/var/named";
};
zone "."
{
type hint;
file "db.root";
};
zone "one.edu"
{
type slave;
file "db.one.edu.slave";
masters
{
192.168.1.2;
};
};
zone "1.168.192.in-addr.arpa"
{
type slave;
file "db.192.168.1.slave";
masters
{
192.168.1.2;
};
};
zone "0.0.127.in-addr.arpa" in
{
type slave;
file "db.127.0.0.slave";
masters
{
192.168.1.2;
};
};

Configuring DNS 10-29

Observe the following about this file:

● Secondary servers are configured with and use the same root server
hints file as the primary name server.
● Secondary servers are configured with and use the same syntax for a
reverse loopback domain file as the primary name server uses,
except that the secondary name server is always listed as the
primary for the loopback address.
● The reverse.backup and reverse.rbackup files and their contents
are created automatically by the secondary server’s named daemon
after the primary name server is contacted successfully.
● The IP address from which the secondary server should download
its zone files is listed following the masters keyword. Up to 10 IP
addresses can be listed. The server or servers listed can be the
primary server or secondary servers.

Secondary servers start the named daemon during the boot process if the
/etc/named.conf file exists. The daemon is started by SMF.

10-30 Network Administration for the Solaris™ 10 Operating System

Checking Configuration and Database Files

The named-checkconf and named-checkzone commands can be used to
check the integrity of the named.conf and database files. These commands
report syntax errors.

The named-checkconf command is used to check the /etc/named.conf

file.

Missing punctuation can be detected:

sys12# named-checkconf
/etc/named.conf:32: missing ’;’ before ’zone’

Misspelled keywords are exposed:

sys12# named-checkconf
/etc/named.conf:32: unknown option ’zonee’

Missing required keywords are reported:

sys12# named-checkconf
/etc/named.conf:38: zone ’one.edu’: type not present

The named-checkzone command is used to check the any of the zone

files.

A clean one.edu zone in the db.192.168.1 file is reported:

# named-checkzone one.edu db.192.168.1
zone one.edu/IN: loaded serial 2005010101
OK

Typographical errors in the SOA record are detected:

sys12# named-checkzone one.edu db.192.168.1
dns_master_load: db.192.168.1:10: unknown RR type 'SA0'
zone one.edu/IN: loading master file db.192.168.1: unknown class/type

Missing NS records are reported:

sys12# named-checkzone one.edu db.192.168.1
zone one.edu/IN: has no NS records

Configuring DNS 10-31

Configuring DNS Clients

All DNS clients require the presence of the /etc/nsswitch.conf and
/etc/resolv.conf files. Note that the DNS server must also be
configured as a DNS client if it intends to use its own DNS services.

The /etc/nsswitch.conf file specifies the resolver library routines to be

used for resolving host names and addresses. Modify the
/etc/nsswitch.conf file by editing the hosts entry and adding the dns
keyword. To ensure proper network interface configuration during the
boot process, make sure that the files keyword is listed first. The
following example shows a hosts entry configured for DNS:
hosts: files dns

The /etc/resolv.conf file specifies the name servers that the client must
use, the client’s domain name, and the search path to use for queries.
; resolv.conf file for DNS clients of the one.edu domain
search one.edu two.edu three.edu
nameserver 192.168.1.2
nameserver 192.168.1.3

Observe that the search keyword specifies domain names to append to

queries that were not specified in the FQDN format. The first domain
listed following the search keyword designates the client’s domain. If
both "domain" and "search" keywords are present, then the last one in the
file is used and the other one(s) are ignored.

The nameserver keyword specifies the IP address of the DNS servers to

query. Do not specify host names. You can use up to three nameserver
keywords to increase your chances of finding a responsive server. In
general, list the name servers that are nearer to the local network first. The
client attempts to use the loopback address if there is no nameserver
keyword or if the /etc/resolv.conf file does not exists.

Starting the Client Service

The following svcadm command enables the DNS default client service:
# svcadm enable svc:/network/dns/client:default

# svcs -a | grep dns

online 23:02:34 svc:/network/dns/client:default

10-32 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

Troubleshooting the DNS Server by Using Basic Utilities

Usually, you cannot test every record in your domain files. Test
representative samples, and test several servers in other domains to
ensure that you have correctly identified the root servers.

Implementing named Logging

Use logging (named.conf(4)) to cause the named process to write to a log
file that you specify. Add the following to the top of the primary DNS
system's /etc/named.conf file and restart the named daemon:
logging {
channel logfile {
file "/var/named/bind-log";
print-time yes;
severity debug 9;
print-category yes;
print-severity yes;
};
category default { default_syslog; logfile; };
category queries { logfile; };
};

Logging starts as soon as the logging statement in the /etc/named.conf

file is parsed, so the logging statement should be the first entry in that file.

A logging channel controls the destination of the logged data. Following

is a description of each of the example entries:
● /var/named/bind-log – File to hold logged data
● print-time yes – Print time of the event
● severity debug 9 – Debug output of level 9 and below to be
logged
● print-category yes – Log category information
● print-severity yes – Log severity information

Configuring DNS 10-33

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

The category section describes how the channel information is used.

Following is a description of each of the example entries:
● category default { default_syslog; logfile; } – Log to
syslog and logfile
● category queries { logfile; } – Log queries

Following is an example of logged information during query using the

dig command:
sys12# tail -f /var/named/bind-log
Jan 12 16:02:19.918 client: debug 3: client 192.168.1.1#32810: UDP request
Jan 12 16:02:19.918 client: debug 5: client 192.168.1.1#32810: using view '_default'
Jan 12 16:02:19.918 security: debug 3: client 192.168.1.1#32810: request is not signed
Jan 12 16:02:19.918 security: debug 3: client 192.168.1.1#32810: recursion available:
approved
Jan 12 16:02:19.918 client: debug 3: client 192.168.1.1#32810: query
Jan 12 16:02:19.918 queries: info: client 192.168.1.1#32810: query: one.edu IN A
Jan 12 16:02:19.918 security: debug 3: client 192.168.1.1#32810: query 'one.edu/IN'
approved
Jan 12 16:02:19.919 client: debug 3: client 192.168.1.1#32810: send
Jan 12 16:02:19.919 client: debug 3: client 192.168.1.1#32810: sendto
Jan 12 16:02:19.919 client: debug 3: client 192.168.1.1#32810: senddone
Jan 12 16:02:19.919 client: debug 3: client 192.168.1.1#32810: next
Jan 12 16:02:19.919 client: debug 3: client 192.168.1.1#32810: endrequest
Jan 12 16:02:19.920 client: debug 3: client @94f88: udprecv
Jan 12 16:02:19.923 client: debug 3: client 192.168.1.1#32811: UDP request
Jan 12 16:02:19.924 client: debug 5: client 192.168.1.1#32811: using view '_default'
Jan 12 16:02:19.924 security: debug 3: client 192.168.1.1#32811: request is not signed
Jan 12 16:02:19.924 security: debug 3: client 192.168.1.1#32811: recursion available:
approved
Jan 12 16:02:19.924 client: debug 3: client 192.168.1.1#32811: query
Jan 12 16:02:19.924 queries: info: client 192.168.1.1#32811: query: 4.1.168.192.in-
addr.arpa IN PTR
Jan 12 16:02:19.924 security: debug 9: client 192.168.1.1#32811: v6 synthesis denied
Jan 12 16:02:19.924 security: debug 3: client 192.168.1.1#32811: query '4.1.168.192.in-
addr.arpa/IN' approved
Jan 12 16:02:19.924 client: debug 3: client 192.168.1.1#32811: send
Jan 12 16:02:19.924 client: debug 3: client 192.168.1.1#32811: sendto
Jan 12 16:02:19.925 client: debug 3: client 192.168.1.1#32811: senddone
Jan 12 16:02:19.925 client: debug 3: client 192.168.1.1#32811: next
Jan 12 16:02:19.925 client: debug 3: client 192.168.1.1#32811: endrequest
Jan 12 16:02:19.925 client: debug 3: client @94f88: udprecv

10-34 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

Examining the/var/adm/messages File

The named daemon sends messages to the syslogd daemon by using the
daemon facility. Messages that are sent with level notice or higher are
written to the /var/adm/messages file by default. The contents of this
file often show where configuration errors were made. For example, the
following highlighted entry shows that zone files without TTLs are now
rejected:
Jan 11 12:04:31 sys12 named[634]: [ID 873579 daemon.notice] starting BIND
9.2.4
Jan 11 12:04:32 sys12 named[634]: [ID 873579 daemon.warning]
named.root:5: no TTL specified; zone rejected
Jan 11 12:04:33 sys12 named[669]: [ID 873579 daemon.notice] couldn't add
command channel ::1#953: address not available
Jan 11 12:04:33 sys12 named[669]: [ID 873579 daemon.error] zone
1.168.192.in-addr.arpa/IN: loading
master file one.rzone: file not found
Jan 11 12:04:35 sys12 named[634]: [ID 873579 daemon.crit] exiting (due to
fatal error)

Configuring DNS 10-35

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

Using the dig Utility

Before the Solaris 9 OS, the primary test tool bundled with BIND was the
nslookup utility. As of the Solaris 9 OS, the domain information groper
(dig) utility was also bundled with the Solaris OS. In the Solaris 10 OS,
the nslookup utility is included, but is marked as obsolete with a
notification that it might be removed in a future release. The dig utility is
now preferred and does the following:
● Sends queries and displays replies for any of the valid resource
record types
● Queries the DNS server of your choice
● Debugs almost any domain that is not protected by a firewall

Executing Forward Queries

The syntax used for forward queries is as follows:

dig @DNS_server domain_name system_name

A typical debug query testing forward resolution might look like the
following:
# dig @192.168.1.2 one.edu sys11.one.edu

; <<>> DiG 9.2.4 <<>> @192.168.1.2 one.edu sys11.one.edu

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1334
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;one.edu. IN A

;; AUTHORITY SECTION:
one.edu. 86400 IN SOA sys12.one.edu.
root.sys12.one.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 4 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:56:12 2005
;; MSG SIZE rcvd: 72

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1440

10-36 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sys11.one.edu. IN A

;; ANSWER SECTION:
sys11.one.edu. 86400 IN A 192.168.1.1

;; AUTHORITY SECTION:
one.edu. 86400 IN NS sys12.one.edu.
one.edu. 86400 IN NS sys13.one.edu.

;; ADDITIONAL SECTION:
sys12.one.edu. 86400 IN A 192.168.1.2
sys13.one.edu. 86400 IN A 192.168.1.3

;; Query time: 3 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:56:12 2005
;; MSG SIZE rcvd: 119

The ANSWER SECTION lists the answer retrieved from the DNS server. An
answer number (on the flags line) greater than zero usually indicates
success.

Executing Reverse Queries

The syntax used for reverse queries is as follows:

dig @DNS_server domain_name -x IP_address

A typical debug query testing reverse resolution might look like the
following:
# dig @192.168.1.2 one.edu -x 192.168.1.1

; <<>> DiG 9.2.4 <<>> @192.168.1.2 one.edu -x 192.168.1.1

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1881
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;one.edu. IN A

;; AUTHORITY SECTION:

Configuring DNS 10-37

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

one.edu. 86400 IN SOA sys12.one.edu.

root.sys12.one.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 4 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:55:11 2005
;; MSG SIZE rcvd: 72

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1932
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;1.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 86400 IN PTR sys11.one.edu.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 86400 IN NS sys13.one.edu.
1.168.192.in-addr.arpa. 86400 IN NS sys12.one.edu.

;; ADDITIONAL SECTION:
sys12.one.edu. 86400 IN A 192.168.1.2
sys13.one.edu. 86400 IN A 192.168.1.3

;; Query time: 3 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:55:11 2005
;; MSG SIZE rcvd: 141

10-38 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

Dumping a Snapshot of the DNS Database by Using

the rndc Utility
The remote name daemon controller command, rndc, is used to dump the
currently cached contents of the server.
sys12# rndc dumpdb

All of the options for the rndc utility are listed when it is invoked without
any as follows:
# rndc
Usage: rndc [-c config] [-s server] [-p port]
[-k key-file ] [-y key] [-V] command

command is one of the following:

reload Reload configuration file and zones.

reload zone [class [view]]
Reload a single zone.
refresh zone [class [view]]
Schedule immediate maintenance for a zone.
reconfig Reload configuration file and new zones only.
stats Write server statistics to the statistics file.
querylog Toggle query logging.
dumpdb Dump cache(s) to the dump file (named_dump.db).
stop Save pending updates to master files and stop the server.
halt Stop the server without saving pending updates.
trace Increment debugging level by one.
trace level Change the debugging level.
notrace Set debugging level to 0.
flush Flushes all of the server's caches.
flush [view] Flushes the server's cache for a view.
status Display status of the server.
*restart Restart the server.

* == not yet implemented

Version: 9.2.4

Clearing the Cache

Clear the server’s cached data by restarting the named daemon. For
example:
sys12# svcs -a | grep dns
online 5:09:02 svc:/network/dns/client:default

Configuring DNS 10-39

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

online 5:09:25 svc:/network/dns/server:default

sys12# svcadm disable svc:/network/dns/server:default
sys12# svcs -a | grep dns
disabled 6:54:30 svc:/network/dns/server:default
online 5:09:02 svc:/network/dns/client:default
sys12# svcadm enable svc:/network/dns/server:default
sys12# svcs -a | grep dns
online 5:09:02 svc:/network/dns/client:default
online 6:54:45 svc:/network/dns/server:default

Verify that the cache has been cleared using the rndc command:
sys12# rndc dumpdb
sys12# cat /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050112135516

Dump Examples

Examining dumped caches is often a very productive way to troubleshoot

errors.

The following example shows an improper use of the dig command

attempting a reverse query:
sys13# dig @192.168.1.2 one.edu 192.168.1.1

; <<>> DiG 9.2.4 <<>> @192.168.1.2 one.edu 192.168.1.1

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1328
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;one.edu. IN A

;; AUTHORITY SECTION:
one.edu. 86400 IN SOA sys12.one.edu.
root.sys12.one.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 2 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 06:59:29 2005
;; MSG SIZE rcvd: 72

10-40 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1204
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;192.168.1.1. IN A

;; AUTHORITY SECTION:
. 10800 IN SOA instructor.thirty.edu.
root.instructor.thirty.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 4 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 06:59:29 2005
;; MSG SIZE rcvd: 90

The highlighted entries shown above indicate an unsuccessful reverse

resolution request. Dumping the cached data provides insights.
sys12# rndc dumpdb
sys12# cat /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050112135930
; authanswer
. 86381 IN NS instructor.thirty.edu.
; authauthority
192.168.1.1. 10781 \-ANY ;-$NXDOMAIN
; additional
instructor.thirty.edu. 86381 A 192.168.30.30
sys12#

The NXDOMAIN in the dumped data indicates that a non existent (NX)
domain was requested. Because the incorrect syntax was used (missing -x
option, needed for reverse queries), the IP address was mistaken for a
domain.

The following example shows a successful reverse query:

sys13# dig @192.168.1.2 two.edu -x 192.168.2.1

; <<>> DiG 9.2.4 <<>> @192.168.1.2 two.edu -x 192.168.2.1

;; global options: printcmd

Configuring DNS 10-41

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1174
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;two.edu. IN A

;; AUTHORITY SECTION:
two.edu. 10800 IN SOA sys22.two.edu.
root.sys22.two.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 11 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 08:07:30 2005
;; MSG SIZE rcvd: 72

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;1.2.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
1.2.168.192.in-addr.arpa. 86400 IN PTR sys21.two.edu.

;; AUTHORITY SECTION:
2.168.192.in-addr.arpa. 86400 IN NS sys23.two.edu.
2.168.192.in-addr.arpa. 86400 IN NS sys22.two.edu.

;; Query time: 6 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 08:07:30 2005
;; MSG SIZE rcvd: 109

The first highlighted QUESTION section indicates that the query is

requesting data that is not locally authoritative. A forwarding of the
request is required for information about the two.edu domain. The
second highlighted QUESTION and ANSWER sections are for the specified
request for information about the 192.168.2.1 address.

Examining the cached data details the resolution process.

sys12# rndc dumpdb
sys12# cat /var/named/named_dump.db
;

10-42 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

; Cache dump of view '_default'

;
$DATE 20050112150759
; authanswer
. 86353 IN NS instructor.thirty.edu.
; authauthority
2.168.192.in-addr.arpa. 86353 NS sys22.two.edu.
86353 NS sys23.two.edu.
; authanswer
1.2.168.192.in-addr.arpa. 86353 PTR sys21.two.edu.
; additional
instructor.thirty.edu. 86353 A 192.168.30.30
; glue
two.edu. 86353 NS sys22.two.edu.
86353 NS sys23.two.edu.
; authauthority
10753 \-A ;-$NXRRSET
; glue
sys22.two.edu. 86353 A 192.168.2.2
; glue
sys23.two.edu. 86353 A 192.168.2.3

The first three entries in the cached data show the resolution process. The
first highlight entry shows the forwarding of the request to the
instructor.thirty.edu. The second highlighted entry shows that
server supplying the and of the authoritative server for the
2.168.192.in-addr.arpa zone (sys22.two.edu). The last highlighted
entry shows the pointer information cached for the requested IP address.

Configuring DNS 10-43

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

This next example cache dump shows a similar resolution for a forward
query:
sys13# dig @192.168.1.2 two.edu sys21.two.edu
<dig output omitted>

sys12# rndc dumpdb

sys12# cat /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050112151434
; authanswer
. 86357 IN NS instructor.thirty.edu.
; additional
instructor.thirty.edu. 86357 A 192.168.30.30
; authauthority
two.edu. 86357 NS sys22.two.edu.
86357 NS sys23.two.edu.
; authauthority
10757 \-A ;-$NXRRSET
; authanswer
sys21.two.edu. 86357 A 192.168.2.1
; glue
sys22.two.edu. 86357 A 192.168.2.2
; glue
sys23.two.edu. 86357 A 192.168.2.3

Forcing the named Daemon to Reread the

Configuration and Changed Zone Files
You can use the rndc utility with the reconfig command to cause the
named process to reload its configuration file and implement any changes
to the zone files as follows:
sys12# rndc reconfig

10-44 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

Managing a DNS Server by Using the rndc Utility

Administrators use the remote name daemon control program (rndc) to
control the operation of a name server. Name servers have always been
controlled by administrators sending signals, such as SIGHUP and SIGINT.
The rndc utility provides a finer granularity of control, and it can be used
both interactively and non-interactively.

As of the Solaris 10 OS, the rndc utility replaces the ndc utility as the
name daemon control application. A significant difference between ndc
in BIND 8 and rndc in BIND 9 is that rndc uses its own configuration file,
rndc.conf.

Securing Control Sessions

The rndc utility supports security using key-based authentication.

Remote clients are authorized specifically to control the daemon by
establishing, configuring and using secret keys. Implementing this
security requires an rndc-key reference entry in the /etc/name.conf file
and the appropriate key information in the rndc.conf file.

Without a rndc-key reference in the /etc/named.conf file, the following

messages appear in the /var/adm/messages file:
Jan 12 08:22:12 sys12 named[1346]: [ID 873579 daemon.notice] command
channel listening on 127.0.0.1#953
Jan 12 08:22:12 sys12 named[1346]: [ID 873579 daemon.notice] couldn't add
command channel ::1#953: address not available
You can continue to use the rndc utility, albeit in a non-secure manner.

Use the rndc-confgen utility to generate the proper contents for the
rndc.conf and /etc/named.conf files. The rndc.conf file specifies
which server controls and algorithm the server should use. You need only
a rndc.conf file in place if the named.conf file has an entry for a
rndc-key.
sys12# /usr/sbin/rndc-confgen
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "jZOP5nh//i9t7BwHivvNzA==";
};

options {
default-key "rndc-key";

Configuring DNS 10-45

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Troubleshooting the DNS Server by Using Basic Utilities

default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as

needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "jZOP5nh//i9t7BwHivvNzA==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf
sys12#

Copy the rndc-key section into a new file called /etc/rndc.conf.

sys12# cat /etc/rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "jZOP5nh//i9t7BwHivvNzA==";
};

options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};

Add the named.conf section to the /etc/named.conf file. Be sure to

remove the comment indentifiers (#). The following is an example of a
finished /etc/named.conf file:
sys12# cat /etc/named.conf
options
{
directory "/var/named";
};

// added to stop couldn't add command channel ::1#953 messages

// from showing up in /var/adm/messages
// following is output from /usr/sbin/rndc-confgen

10-46 Network Administration for the Solaris™ 10 Operating System

key "rndc-key" {
algorithm hmac-md5;
secret "jZOP5nh//i9t7BwHivvNzA==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
// end of rndc.key addition

...

Test the rndc.key by stopping and starting the named process, using the
rndc utility, and examining the resulting /var/adm/messages file entries:
sys12# svcadm disable svc:/network/dns/server:default
sys12# svcadm enable svc:/network/dns/server:default
sys12# tail -4 /var/adm/messages
Jan 12 08:58:48 sys12 named[1402]: [ID 873579 daemon.notice] starting
BIND 9.2.4
Jan 12 08:58:48 sys12 named[1402]: [ID 873579 daemon.notice] command
channel listening on 127.0.0.1#953
Jan 12 08:58:48 sys12 named[1402]: [ID 873579 daemon.notice] running

The daemon starting without the command channel message implies a

successful key configuration The rndc command can now be used
securely.

You will see an error message similar to the following if either there is a
problem with the contents of the rndc.conf file:
sys12# rndc dumpdb
Jan 12 10:13:40 sys12 named[1431]: invalid command from 127.0.0.1#32839:
bad auth
rndc: connection to remote host closed
This may indicate that the remote server is using an older version of
the command protocol, this host is not authorized to connect,
or the key is invalid.
sys12#

Configuring DNS 10-47

Server Status

The rndc utility can be used to query server status and report statistics.

Now test to verify that the rndc utility works as expected:

sys12# rndc status
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running

Flushing the Memory Cache

You can use the rndc utility to flush the memory cache.
sys12# rndc flush
sys12# rndc dumpdb
sys12# cat /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050113141237
sys12#

Changing the Debug Level of the Daemon

Use the rndc utility to change the debug level of the server. Before
making any changes, determine the current debug level of the daemon.
sys12# rndc status
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running

10-48 Network Administration for the Solaris™ 10 Operating System

Increment the debug level by one.

sys12# rndc trace
sys12# rndc status
number of zones: 5
debug level: 1
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running

Assign the debug level to a specific level.

sys12# rndc trace 8
sys12# rndc status
number of zones: 5
debug level: 8
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running
sys12#

If logging is enabled, the debug level is shown along with the logged
messages:
sys12# tail -f /var/named/bind-log
Jan 13 07:12:37.548 general: debug 1: received control channel command
'dumpdb'
Jan 13 07:17:02.598 general: debug 1: received control channel command
'status'
Jan 13 07:17:15.249 general: debug 1: received control channel command
'trace'
Jan 13 07:17:17.929 general: debug 1: received control channel command
'status'
Jan 13 07:17:34.838 general: debug 1: received control channel command
'trace 8'
Jan 13 07:17:37.149 general: debug 1: received control channel command
'status'

Configuring DNS 10-49

Exercise: Configuring DNS

In this exercise, you configure DNS.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Before starting this lab; make sure that:

● The classroom network is not connected to the public Internet
because the names and addresses used are not registered with the
ICANN.
● The instructor has set up a root domain server for use in this lab.
● The domains to be set up are named one.edu., two.edu., and
three.edu., respectively.

The self-contained root server (instructor) serves the .(root), edu.,

30.168.192.in-addr.arpa., and 127.in-addr.arpa.loopback
domains. The system and server-client functions for these exercises are
listed in Table 10-5.

Table 10-5 Exercise Host Functions

Host Function

instructor Root DNS name server

sysX1 Router
sysX2 Primary DNS name server, DNS client
sysX3 Secondary DNS name server, DNS client
sysX4 DNS client

10-50 Network Administration for the Solaris™ 10 Operating System

Task Summary
In this exercise, team up with the other students on your subnet, and
configure a DNS primary server, a DNS secondary server, and clients on
your subnet. You practice using troubleshooting tools, such as the
nslookup utility. Work as a team, and move as a team to each system that
is to be configured. In this way, you experience most of the aspects of
configuring DNS.

Tasks
To configure DNS, complete the following steps.

Your first task is to configure your domain’s primary DNS server.

Working on the Primary DNS Server

To configure your domain’s primary DNS server, perform the following:

1. Set up the /etc/named.conf file for your domain on the system that
will be your domain’s primary DNS server. You can create the file
yourself, or you can use the template file that your instructor makes
available to you.
● What is the purpose of the /etc/named.conf file?
______________________________________________________
______________________________________________________
______________________________________________________
● What is the purpose of the following /etc/named.conf file
keywords?
● zone
___________________________________________________
___________________________________________________
● options
___________________________________________________
___________________________________________________
2. Create the /var/named directory.
______________________________________________________

Configuring DNS 10-51

3. Set up the /var/named/db.root file for your domain on the system

that will be your domain’s primary DNS server. You can create the
file yourself, or you can use the template file that your instructor
makes available to you.
● What is the purpose of the db.root file?
___________________________________________________
___________________________________________________
___________________________________________________
● Where can you obtain a current copy of the current root name
servers?
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
● What is the purpose of the following resource record types?
● NS
___________________________________________________
● A
___________________________________________________
4. Set up the zone file for your domain on the system that will be your
domain’s primary DNS server. You can create the file yourself, or
you can use the template file that your instructor makes available to
you.
● What is the purpose of a domain’s zone file?
___________________________________________________
___________________________________________________
___________________________________________________
● What is the purpose of the SOA resource record?
___________________________________________________
___________________________________________________
● What is the purpose of the CNAME resource record?
___________________________________________________
___________________________________________________
___________________________________________________

10-52 Network Administration for the Solaris™ 10 Operating System

5. Set up the reverse lookup file for your domain on the system that
will be your domain’s primary DNS server. You can create the file
yourself, or you can use the template file that your instructor makes
available to you.
● What is the purpose of the reverse lookup zone file?
___________________________________________________
● What is the purpose of the PTR resource record?
___________________________________________________
6. Set up the loopback file for your domain on the system that will be
your domain’s primary DNS server. You can create the file yourself,
or you can use the template file that your instructor makes available
to you.

Your next task is to configure name resolution on all of your systems.

Working on All Systems

To configure name resolution on all systems, perform the following:

7. Working on all of your DNS clients and DNS servers, copy the
/etc/nsswitch.dns file to the /etc/nsswitch.conf file.
Write the command that you use:
___________________________________________________
● What is the purpose of the /etc/nsswitch.conf file?
___________________________________________________
___________________________________________________
● What effect does the dns keyword have on this file?
___________________________________________________
___________________________________________________
___________________________________________________
8. Set up the /etc/resolv.conf file on your DNS server and DNS
clients.
● What is the purpose of the /etc/resolv.conf file?
___________________________________________________
___________________________________________________
___________________________________________________

Configuring DNS 10-53

● What is the purpose of the domain keyword?

___________________________________________________
___________________________________________________
● What is the purpose of the namesserver keyword?
___________________________________________________
___________________________________________________

Working on the Primary DNS Server

Continue as follows:
9. Start the name server daemon on your DNS server:
a. Use the svcadm command to enable both the name server
daemon and the DNS client.
___________________________________________________
___________________________________________________
b. Use the svcs command to verify that the services are online.
___________________________________________________
c. Check that the server daemon is running.
___________________________________________________
10. Check the /var/adm/messages file for DNS error messages.
Before continuing, troubleshoot to eliminate any DNS-related error
messages that appear in the /var/adm/messages file.

Working on the Client Systems

Note – Since the client service was just enabled on the primary name
server, this step does not have to be done on those systems.

11. Use the svcadm command to enable the default client service and
verify that it is enabled.
___________________________________________________
___________________________________________________

10-54 Network Administration for the Solaris™ 10 Operating System

Working on Any System

Troubleshoot DNS-related errors as follows:

12. Test and debug as required. For example, list the contents of the
domain by querying the primary name server for its resource
records.
13. Use the techniques that are described in the lecture part of the
module, testing both your local domain and your remote domain
servers as they become available.
Test and debug your setup by using the dig utility.

Working on the Primary DNS Server

Your final task is to configure a secondary DNS server.

Working on the Secondary DNS Server

To configure a secondary DNS server:

15. Create the /var/named directory.

Working on the Primary DNS Server

Continue as follows:
16. Update both the forward and reverse zone files on the primary
server to support the secondary name server. Write the updates that
you use in each file.
_________________________________________________________
_________________________________________________________
_________________________________________________________

Configuring DNS 10-55

Working on All Systems

Continue as follows:
17. Add the secondary name server to the /etc/resolv.conf file on the
DNS clients and servers in your domain.
Write the updates that you put in the file:
_________________________________________________________
_________________________________________________________

Working on the Secondary DNS Server

Continue as follows:
18. Set up the /etc/named.conf file for your domain on the system that
will be your domain’s secondary DNS server. You can create the file
yourself, or you can use the template file that your instructor makes
available to you.
19. Set up the /var/named/db.root file for your domain on the system
that will be your domain’s secondary DNS server. You can create the
file yourself, or you can use the template file that your instructor
makes available to you.
20. Start the name server daemon on your DNS server:
a. Use the svcadm command to enable both the name server
daemon and the DNS client.
_____________________________________________________
_____________________________________________________
b. Use the svcs command to verify that the services are online.
_____________________________________________________
c. Check that the server daemon is running.
_____________________________________________________
21. Verify that the new zone files have been created in the /var/named
directory.
__________________________________________________________
22. Verify that the secondary name server performs forward lookup
requests as expected.
__________________________________________________________

10-56 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Configuring DNS 10-57

Exercise Solutions
Solutions to this exercise are provided in the following section.

Task Solutions
To configure DNS, complete the following steps.

Your first task is to configure your domain’s primary DNS server.

Working on the Primary DNS Server

To configure your domain’s primary DNS server, perform the following:

1. Set up the /etc/named.conf file for your domain on the system that
will be your domain’s primary DNS server. You can create the file
yourself, or you can use the template file that your instructor makes
available to you.
Your /etc/named.conf file should be similar to the following:
sys12# cat /etc/named.conf
options
{
directory "/var/named";
};

zone "."
{
type hint;
file "db.root";
};

zone "one.edu"
{
type master;
file "db.one.edu";
};

zone "1.168.192.in-addr.arpa"
{
type master;
file "db.192.168.1";
};

10-58 Network Administration for the Solaris™ 10 Operating System

zone "0.0.127.in-addr.arpa" in
{
type master;
file "db.127.0.0";
};
● What is the purpose of the /etc/named.conf file?
The /etc/named.conf file is the configuration file read by the
named daemon at system start up. The named.conf file specifies the
directory that contains the other configuration files, the root servers,
the domains served by this server, and the type of server that this
system will be for each of those domains.
● What is the purpose of the following /etc/named.conf file
keywords?
● zone
It defines a zone of authority and applies options selectively on a
per-zone basis, rather than to all zones.
● options
It controls global server configuration options and sets default
values for other statements.
2. Create the /var/named directory.
sys12# mkdir /var/named
3. Set up the /var/named/db.root file for your domain on the system
that will be your domain’s primary DNS server. You can create the
file yourself, or you can use the template file that your instructor
makes available to you.
Your /var/named/db.root file should be similar to the following:
sys12# cat /var/named/db.root
;
; db.root
;
;{name} {ttl} Class NS Nameserver Name
;--------------------------------------------------------------
. 604800 IN NS instructor.thirty.edu.
;
;{name} {ttl} Class A IP Address
;---------------------------------------------------------
instructor.thirty.edu. 604800 IN A 192.168.30.30
#

Configuring DNS 10-59

● What is the purpose of the db.root file?

Root servers are positioned at the top, or the root, of the DNS
hierarchy, and they maintain data about each of the top-level zones.
Non-root servers can begin queries at the root level if no other
information is available. This file’s contents directs non-root servers to
root servers.
● Where can you obtain a current copy of the current root name
servers?
You can retrieve them from the
ftp://ftp.rs.internic.net/domain/named.root URL. Be
sure to check that the file’s syntax is correct.
● What is the purpose of the following resource record types?
● NS
The NS record (name server record) identifies the name server of a
domain.
● A
The A record (address record) yields an IP address that
corresponds to a host name.
4. Set up the zone file for your domain on the system that will be your
domain’s primary DNS server. You can create the file yourself, or
you can use the template file that your instructor makes available to
you.
Your /var/named/db.one.edu file should be similar to the following:
sys12# cat /var/named/db.one.edu
; db.one.edu
$TTL 86400
;
;{name} {ttl} Class SOA Origin Postmaster
;----------------------------------------------------------------------------------
@ IN SOA sys12.one.edu. root.sys12.one.edu. (
2005010101 ; Serial
3600 ; Refresh (1 Hour)
1800 ; Retry (30 Minutes)
6048000 ; Expire (1 Week)
86400 ) ; Minimum (24 Hours)

;
;{name} {ttl} Class NS Nameserver Name
;------------------------------------------------------
IN NS sys12.one.edu.

10-60 Network Administration for the Solaris™ 10 Operating System

;{name} {ttl} Class A IP Address

;-------------------------------------------------
sys11 IN A 192.168.1.1
sys12 IN A 192.168.1.2
sys13 IN A 192.168.1.3
sys14 IN A 192.168.1.4

localhost IN A 127.0.0.1

;
;{name} {ttl} Class CNAME Canonical Name
;-------------------------------------------------------
router IN CNAME sys11
dns IN CNAME sys12
● What is the purpose of a domain’s zone file?
This file contains the mappings of names to IP addresses for all
systems in the domain being served by this name server. In addition,
this file must specify an SOA record and NS records for all name
servers for this domain.
● What is the purpose of the SOA resource record?
The SOA record identifies the primary server, contact information, and
cache time-out values for the entries in the domain.
● What is the purpose of the CNAME resource record?
The CNAME record defines an alias for a host name.
5. Set up the reverse lookup file for your domain on the system that
will be your domain’s primary DNS server. You can create the file
yourself, or you can use the template file that your instructor makes
available to you.
Your /var/named/db.192.168.1 file should be similar to the following:
sys12# cat /var/named/db.192.168.1
; db.192.168.1
;

$TTL 86400

Configuring DNS 10-61

;{name} {ttl} Class NS Nameserver Name

;------------------------------------------------------
IN NS sys12.one.edu.

;
;{name} {ttl} Class PTR Real Name
;------------------------------------------------
1 IN PTR sys11.one.edu.
2 IN PTR sys12.one.edu.
3 IN PTR sys13.one.edu.
4 IN PTR sys14.one.edu.
● What is the purpose of the reverse lookup zone file?
This file contains mappings for address-to-name translation.
● What is the purpose of the PTR resource record?
The PTR record specifies a host name for an IP address.
6. Set up the loopback file for your domain on the system that will be
your domains primary DNS server. You can create the file yourself,
or you can use the template file that your instructor makes available
to you.
Your /var/named/db.127.0.0 file should be similar to the following:
sys12# cat /var/named/db.127.0.0
; db.127.0.0
;

$TTL 86400

;
;{name} {ttl} Class NS Nameserver Name
;------------------------------------------------------
IN NS sys12.one.edu.

;
;{name} {ttl} Class PTR Real Name
;------------------------------------------------
1 IN PTR localhost.

Your next task is to configure name resolution on all of your systems.

10-62 Network Administration for the Solaris™ 10 Operating System

Working on All Systems

To configure name resolution on all systems, perform the following:

7. Working on all of your DNS clients and DNS servers, copy the
/etc/nsswitch.dns file to the /etc/nsswitch.conf file.
Write the command that you use:
# cp /etc/nsswitch.dns /etc/nsswitch.conf
● What is the purpose of the /etc/nsswitch.conf file?
The etc/nsswitch.conf file specifies which resolver library
routines are to be used in resolving host names and addresses.
● What effect does the dns keyword have on this file?
The dns keyword causes the dns resolver library routine to be
added when resolving host names and addresses. Its position in the
hosts line determines the order in which it is used.
8. Set up the /etc/resolv.conf file on your DNS server and DNS
clients.
Your system’s /etc/resolv.conf file should have contents similar to the
following:
# cat /etc/resolv.conf
domain one.edu
nameserver 192.168.1.2
● What is the purpose of the /etc/resolv.conf file?
This file specifies the resolver library routines that the domain search
list applies to any names that are not specified in the FQDN form and
specifies the IP addresses of DNS servers to query.
● What is the purpose of the domain keyword?
The domain keyword specifies domain names to append to names that
were not specified in the FQDN format and in what order to append
them.
● What is the purpose of the namesserver keyword?
The nameserver keyword specifies DNS servers to query by IP
address.

Configuring DNS 10-63

Working on the Primary DNS Server

Continue as follows:
9. Start the name server daemon on your DNS server:
a. Use the svcadm command to enable both the name server
daemon and the DNS client.
sys12# svcadm enable svc:/network/dns/server:default
sys12# svcadm enable svc:/network/dns/client:default
b. Use the svcs command to verify that the services are online.
sys12# svcs -a | grep dns
online 14:53:08 svc:/network/dns/server:default
online 14:56:04 svc:/network/dns/client:default
c. Check that the server daemon is running.
sys12# pgrep named
97
10. Check the /var/adm/messages file for DNS error messages.
sys12# tail -4 /var/adm/messages
Jan 12 13:23:18 sys12 named[1516]: [ID 873579 daemon.notice] starting BIND 9.2.4
Jan 12 13:23:18 sys12 named[1516]: [ID 873579 daemon.notice] command channel listening
on 127.0.0.1#953
Jan 12 13:23:18 sys12 named[1516]: [ID 873579 daemon.notice] command channel listening
on ::1#953
Jan 12 13:23:18 sys12 named[1516]: [ID 873579 daemon.notice] running
Before continuing, troubleshoot to eliminate any DNS-related error
messages that appear in the /var/adm/messages file.

Working on the Client Systems

Note – Since the client service was just enabled on the primary name
servers, this step does not have to be done on those systems.

11. Use the svcadm command to enable the default client service and
verify that it is enabled.
# svcadm enable svc:/network/dns/client:default
# svcs -a | grep dns
online 15:02:34 svc:/network/dns/client:default
...

10-64 Network Administration for the Solaris™ 10 Operating System

Working on Any System

Troubleshoot DNS-related errors as follows:

; <<>> DiG 9.2.4 <<>> @192.168.1.2 one.edu sys11.one.edu

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 106
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;one.edu. IN A

;; AUTHORITY SECTION:
one.edu. 86400 IN SOA sys12.one.edu.
root.sys12.one.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 3 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 13:27:39 2005
;; MSG SIZE rcvd: 72

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sys11.one.edu. IN A

;; ANSWER SECTION:
sys11.one.edu. 86400 IN A 192.168.1.1

;; AUTHORITY SECTION:
one.edu. 86400 IN NS sys12.one.edu.

;; ADDITIONAL SECTION:

Configuring DNS 10-65

sys12.one.edu. 86400 IN A 192.168.1.2

;; Query time: 2 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 13:27:39 2005
;; MSG SIZE rcvd: 119

The preceding output indicates that the 192.168.1.2 DNS server

determined that the sys11.one.edu system has an IP address of
192.168.1.1.

10-66 Network Administration for the Solaris™ 10 Operating System

Working on the Primary DNS Server

Continue as follows:
14. Test your DNS server. Use the techniques that are described in the
lecture part of the module.
a. Take a snapshot of the DNS information in memory.
Use the following command:
sys12# rndc dumpdb
b. View the dumped DNS data to look for errors.
sys12# view /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050112203358
The dumped cache file is currently empty because the server has been
started recently and no queries have been cached at this time.

Your final task is to configure a secondary DNS server.

Working on the Secondary DNS Server

To configure a secondary DNS server:

15. Create the /var/named directory.
sys13# mkdir /var/named

Working on the Primary DNS Server

Continue as follows:
16. Update both the forward and reverse zone files on the primary
server to support the secondary name server. Write the updates that
you use in each file.
The addition to the forward zone file should be similar to the following,
added under the existing name server configuration:

;{name} {ttl} Class NS Nameserver Name

;------------------------------------------------------
IN NS sys12.one.edu.
IN NS sys13.one.edu.

Configuring DNS 10-67

The addition to the reverse zone file should be similar to the following,
added under the existing name server configuration:

;{name} {ttl} Class NS Nameserver Name

;------------------------------------------------------
IN NS sys12.one.edu.
IN NS sys13.one.edu.

Working on All Systems

Continue as follows:
17. Add the secondary name server to the /etc/resolv.conf file on the
DNS clients and servers in your domain.
Write the updates that you put in the file:
Your /etc/resolv.conf file should be similar to the following:
# cat /etc/resolv.conf
domain one.edu
nameserver 192.168.1.2
nameserver 192.168.1.3

Working on the Secondary DNS Server

Continue as follows:
18. Set up the /etc/named.conf file for your domain on the system that
will be your domain’s secondary DNS server. You can create the file
yourself, or you can use the template file that your instructor makes
available to you.
Your /etc/named.conf file should be similar to the following:
sys13# cat /etc/named.conf
options
{
directory "/var/named";
};

zone "."
{
type hint;
file "db.root";
};

10-68 Network Administration for the Solaris™ 10 Operating System

zone "one.edu"
{
type slave;
file "db.one.edu.slave";
masters
{
192.168.1.2;
};
};

zone "1.168.192.in-addr.arpa"
{
type slave;
file "db.192.168.1.slave";
masters
{
192.168.1.2;
};
};

zone "0.0.127.in-addr.arpa" in
{
type slave;
file "db.127.0.0.slave";
masters
{
192.168.1.2;
};
};
19. Set up the /var/named/db.root file for your domain on the system
that will be your domain’s secondary DNS server. You can create the
file yourself, or you can use the template file that your instructor
makes available to you.
Your /var/named/db.root file should be similar to the following:
sys13# cat /var/named/db.root
; db.root
;
;{name} {ttl} Class NS Nameserver Name
;--------------------------------------------------------------
. 604800 IN NS instructor.thirty.edu.

;
;{name} {ttl} Class A IP Address
;---------------------------------------------------------
instructor.thirty.edu. 604800 IN A 192.168.30.30
sys13#

Configuring DNS 10-69

20. Start the name server daemon on your DNS server:

a. Use the svcadm command to enable both the name server
daemon and the DNS client.
sys13# svcadm enable svc:/network/dns/server:default
sys13# svcadm enable svc:/network/dns/client:default
b. Use the svcs command to verify that the services are online.
sys13# svcs -a | grep dns
online 14:53:08 svc:/network/dns/server:default
online 14:56:04 svc:/network/dns/client:default
c. Check that the server daemon is running.
sys13# pgrep in.named
853
21. Verify that the new zone files have been created in the /var/named
directory.
sys13# ls -al
total 20
drwxr-xr-x 3 root root 512 Jan 12 05:14 .
drwxr-xr-x 45 root sys 1024 Jan 11 16:50 ..
-rw------- 1 root root 353 Jan 12 13:36 db.127.0.0.slave
-rw------- 1 root root 430 Jan 12 13:56 db.192.168.1.slave
-rw------- 1 root root 460 Jan 12 13:46 db.one.edu.slave
-rw-r--r-- 1 root root 405 Jan 12 05:13 db.root
22. Verify that the secondary name server performs forward lookup
requests as expected.
You could use one of a few tools to test DNS lookup requests. This example
demonstrates using the dig utility where:
● @192.168.1.3 – Designates which DNS server to use
● one.edu – Designates the domain of interest
● sys14.one.edu – Designates the name to query
sys11# dig @192.168.1.3 one.edu -x 192.168.1.4

; <<>> DiG 9.2.4 <<>> @192.168.1.3 one.edu -x 192.168.1.4

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2032
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;one.edu. IN A

10-70 Network Administration for the Solaris™ 10 Operating System

;; AUTHORITY SECTION:
one.edu. 86400 IN SOA sys12.one.edu.
root.sys12.one.edu. 2005010101 3600 1800 6048000 86400

;; Query time: 3 msec

;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Wed Jan 12 14:25:50 2005
;; MSG SIZE rcvd: 72

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 322
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;4.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
4.1.168.192.in-addr.arpa. 86400 IN PTR sys14.one.edu.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 86400 IN NS sys13.one.edu.
1.168.192.in-addr.arpa. 86400 IN NS sys12.one.edu.

;; ADDITIONAL SECTION:
sys12.one.edu. 86400 IN A 192.168.1.2
sys13.one.edu. 86400 IN A 192.168.1.3

;; Query time: 1 msec

;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Wed Jan 12 14:25:50 2005
;; MSG SIZE rcvd: 141

Configuring DNS 10-71

Configuring DHCP

Objectives
This module explains the fundamentals of DHCP, including the purpose
of DHCP and client and server functions. This module explains how to
configure DHCP and how to troubleshoot a DCHP server.

Upon completion of this module, you should be able to:

● Describe the fundamentals of DHCP
● Configure a DHCP server
● Configure and manage DHCP clients
● Troubleshoot a DHCP server
● Troubleshoot a DHCP client

The course map in Figure 11-1 shows how this module fits into the current
instructional goal.

Configuring and Managing Network Applications

Configuring the
Configuring Configuring Configuring Solaris™ IP
DNS DHCP NTP Filter Firewall

Figure 11-1 Course Map

Introducing the Fundamentals of DHCP

DHCP enables you to provide network-related information to client
systems through a centrally located server system.

DHCP evolved from the bootstrap protocol (BOOTP). DHCP provides the
following enhanced functionality:
● Messages include network configuration for clients, such as:
● IP address
● Boot server IP address
● DNS domain, DNS server, and default router
● Lease periods are provided for IP address assignments.
● Routers can be configured to act as a BOOTP relay agent.
● Support is available for clients that need to boot over a network,
which, in effect, replaces the need for using RARP and the
/etc/bootparams file.
● Support is available for DHCP clients in the Solaris 10 OS.

Purpose of DHCP
DHCP reduces the cost of managing networks by eliminating the need to
manually assign or change IP addresses repeatedly. DHCP also reclaims
IP addresses that are no longer needed or if the time period for their use
has expired. These IP addresses can then be used by other clients. DHCP
also makes it easier to renumber the network if the ISP is changed. The
DHCP server would be reconfigured to provide the new IP addresses
offered from this new ISP.

IP addresses are assigned to each system when an organization sets up its

computer network.
● Without DHCP, you assign an IP address to each computer manually.
If a computer moves to another location in a different part of the
network, you assign a new IP address to that computer manually.
● With DHCP, you configure the DHCP server to distribute IP
addresses from a central point. You configure the DHCP server to
send a new IP address automatically when a computer is moved to a
different place on the network and requests a new IP address at boot
time.

11-2 Network Administration for the Solaris™ 10 Operating System

DHCP Client Functions

DHCP has two client functions. DHCP supplies:
● Sufficient information to properly configure the network interface
● Parameters needed by system-level and application-level software

Figure 11-2 shows the DHCP client functions.

DHCP

Configure Parameters
Network (System and
Interfaces Application)

• IP Address • NIS Server

• Netmask • WWW Server
• Router • NTP Server

Figure 11-2 DHCP Client Functions

To perform the first function, the dhcpagent daemon acquires an IP

address that is valid for the network attached to the client’s hardware
interface.

The client’s dhcpagent daemon:

● Constructs and sends packets
● Listens for responses from servers
● Caches the configuration information received
● Releases or renews leases
● Configures the interfaces with sufficient information to enable
communications with the network through the interface

Configuring DHCP 11-3

DHCP Server Functions

The DHCP server manages the IP address space of networks connected
directly to that server and also manages remote networks connected by
BOOTP relay agents. The in.dhcpd daemon runs on the DHCP server.
Figure 11-3 shows the interaction between a DHCP client and server.
DHCP
Client Server

Time
DHCPDISCOVER
1

DHCPOFFER
2

All DHCP offers are

evaluated and
DHCPREQUEST is sent
3

DHCPACK
4

Figure 11-3 DHCP Client-Server Interaction

11-4 Network Administration for the Solaris™ 10 Operating System

Figure 11-4 shows the difference that a BOOTP relay makes for a client
that is attempting to contact a server.

BOOTP DHCP
Client Relay Server

Time
DHCPDISCOVER

DHCPDISCOVER
2

DHCPOFFER

All DHCP requests are evaluated and

DHCPREQUEST is sent
4

DHCPACK
5

Figure 11-4 DHCP Client-Server BOOTP

The BOOTP relay picks up incoming requests from clients and forwards
them to the DHCP server. The DHCP server replies to the BOOTP relay,
which then forwards the response on to the client.

DHCP servers can be primary or secondary servers. A primary DHCP

server passes IP addresses to clients. The IP address is defined during the
installation and configuration of the software on the server. A primary
DHCP server can give an IP address to a client that is requesting a new
configuration from the range of IP addresses for which it is responsible.
Multiple primary-DHCP servers can exist on the same network, as long as
each server is responsible for a different IP address range.

A secondary DHCP server confirms existing configurations supplied

previously by a primary DHCP server when the primary DHCP server
cannot respond to requests for confirmation. Every primary DHCP server
also acts as a secondary server. Primary and secondary DHCP servers
must have access to the exact same data source that contains the IP
addresses being served to clients. Copies cannot be used. This common
data access can be achieved by using NIS+ tables or by using NFS to share
the DHCP network tables.

Configuring DHCP 11-5

The dhcpconfig command and the dhcpmgr utility are available for use
to configure DHCP servers and BOOTP relay servers. These utilities
enable you to set startup options, configure the DHCP service database
type and location, and initialize the dhcptab file and DHCP network
tables for any networks.

11-6 Network Administration for the Solaris™ 10 Operating System

Configuring a DHCP Server

Configuring a DHCP server on the network consists mainly of
configuring and starting the DHCP server daemon.

The DHCP server’s configuration information is stored in the

/etc/inet/dhcpsvc.conf file. This file is created when the configuration
commands are run and should never be edited manually. This file was the
/etc/default/dhcp file prior to the Solaris 9 OS.

To view the configuration information, type the command:

# cat /etc/inet/dhcpsvc.conf
DAEMON_ENABLED=TRUE
RUN_MODE=server
RESOURCE=SUNWfiles
PATH=/var/dhcp
CONVER=1
VERBOSE=TRUE
ICMP_VERIFY=TRUE
INTERFACES=hme0,qfe0
UPDATE_TIMEOUT=15
LOGGING_FACILITY=7
BOOTP_COMPAT=automatic
#

Configuring DHCP 11-7

Configuring DHCP by Using Different Methods

Use the graphical dhcpmgr (DHCP Manager) utility or the command-line
dhcpconfig (DHCP configuration) command to configure a DHCP
server. Select options and enter data to create the dhcptab and DHCP
network tables that the DHCP server uses. Comparisons of how these
two methods work is as follows:
● The dhcpmgr utility enables you to view the information gathered
from system files and to change the information if needed. The
dhcpconfig command enables you to specify the network
information using command-line options.
● The dhcpmgr utility speeds up the configuration process by omitting
prompts for non-essential server options by using default values for
them. You can change non-essential options after the initial
configuration. The dhcpconfig command is faster, but you must
specify values for many options. Use this process if you are an
advanced user and want to use scripts.
● The dhcpmgr utility checks the validity of user input as it is entered.
The dhcpconfig command does not check the validity of user input
as it is entered.

11-8 Network Administration for the Solaris™ 10 Operating System

Performing Initial DHCP Server Configuration by Using

the dhcpmgr Utility
Use the dhcpmgr utility to configure, define, edit, and manage DHCP
services, such as macros, networks, addresses, and policies. The DHCP
Manager runs in an X-window system, such as the Common Desktop
Environment (CDE), GNOME, or the Sun Java Desktop System.

Note – If the server is already configured, the windows in this section do

not appear.

To configure the server, complete the following steps:

1. To start the dhcpmgr utility, type the command:
# /usr/sadm/admin/bin/dhcpmgr &
This example uses the sys12 system to demonstrate how to
configure a basic DHCP server by using the dhcpmgr utility.
If the system is not configured as a DHCP server or a BOOTP relay,
the Choose Server Configuration window appears. Figure 11-5
enables you to configure the server as a DHCP server. This example
uses the default Configure as the DHCP server.

Figure 11-5 Choose Server Configuration Window

Configuring DHCP 11-9

2. Click OK.
The DHCP Configuration Wizard – Step 1 window appears.
Figure 11-6 shows you where to select the data storage format.

Figure 11-6 DHCP Configuration Wizard – Step 1 Window

3. Select Text files, and click >.

11-10 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 2 window appears.

Figure 11-7 shows you where to enter a path for the data store. This
example uses the default directory.

Figure 11-7 DHCP Configuration Wizard – Step 2 Window

4. Accept the default path name, and click >.

Configuring DHCP 11-11

The DHCP Configuration Wizard – Step 3 window appears.

Figure 11-8 enables you to specify the name service in which to store
host records.

Figure 11-8 DHCP Configuration Wizard – Step 3 Window

5. Select /etc/hosts, and click >.

11-12 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 4 window appears.

Figure 11-9 shows you where to specify the length of the lease. This
example uses the defaults 1 and days.

Figure 11-9 DHCP Configuration Wizard – Step 4 Window

6. Accept the defaults of 1 and days, and click >.

Configuring DHCP 11-13

The DHCP Configuration Wizard – Step 5 window appears.

Figure 11-10 shows you where to specify the DNS domain and DNS
servers. This example uses the default of no DNS.

Figure 11-10 DHCP Configuration Wizard – Step 5 Window

7. Do not accept a DNS domain or DNS server, and click >.

11-14 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 6 window appears.

Figure 11-11 shows you where to specify the network address and a
subnet mask. This example uses the 192.168.1.0 network.

Figure 11-11 DHCP Configuration Wizard – Step 6 Window

8. Specify a network address by either selecting one or typing one, type

a subnet mask, and click >.

Configuring DHCP 11-15

The DHCP Configuration Wizard – Step 7 window appears.

Figure 11-12 shows you where to specify information about the
network. This example uses the defaults Local-Area (LAN) and Use
router discovery protocol.

Figure 11-12 DHCP Configuration Wizard – Step 7 Window

9. Select either Local-Area (LAN) or Point-to-Point.

10. Select either Use router discovery protocol or type the router
information in the Use router field.
11. Click >.

11-16 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 8 window appears.

Figure 11-13 shows you where to specify the NIS domain and
servers. This example uses the defaults of no NIS domain and no
NIS server.

Figure 11-13 DHCP Configuration Wizard – Step 8 Window

12. If appropriate, type the NIS domain configuration in the NIS Domain
field.
13. If appropriate, type the NIS server IP address in the NIS Servers
field, and click Add for each NIS server that you are specifying.
14. Click >.

Configuring DHCP 11-17

The DHCP Configuration Wizard – Step 9 window appears.

Figure 11-14 shows you where to specify the NIS+ domain and
servers. This example uses the defaults of no NIS+ domain and no
NIS+ server.

Figure 11-14 DHCP Configuration Wizard – Step 9 Window

15. If appropriate, type the NIS+ domain configuration in the NIS+

Domain field.
16. If appropriate, type the NIS+ server IP address in the NIS+ Servers
field, and click Add for each NIS+ server that you are specifying.
17. Click >.

11-18 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 10 window appears.

Figure 11-15 shows you a summary of the information you entered
previously. This example uses the sample information indicated
previously.

Figure 11-15 DHCP Configuration Wizard – Step 10 Window

18. Review the information and, if the information is correct, click

Finish.

Configuring DHCP 11-19

The DHCP Configuration Manager Window closes, the main DHCP

Manager Window appears, and the Start Address Wizard window
appears. Figure 11-16 shows you where to indicate that you want to
configure addresses for the server.

Figure 11-16 Start Address Wizard Window

19. Click Yes to proceed with address configuration.

The DHCP network file will now be populated.

11-20 Network Administration for the Solaris™ 10 Operating System

Adding Addresses by Using the dhcpmgr Utility

Use the procedures described in this section to add addresses by using the
dhcpmgr utility.

Note – The following steps are a continuation of initial server

configuration.

The DHCP Address Configuration Wizard – Step 1 window appears as

shown in Figure 11-17. This figure shows you where to specify the
number of IP addresses to configure. This example uses five addresses
and a comment of net1.

Figure 11-17 DHCP Address Configuration Wizard – Step 1 Window

1. Modify the number of IP addresses to use.

2. Add a comment if necessary.
3. Click >.

Configuring DHCP 11-21

The DHCP Address Configuration Wizard – Step 2 window appears.

Figure 11-18 shows you where to specify the DHCP server and
starting IP address. In this example, the Managed by Server field is
set to the default, and the starting IP address is changed to
192.168.1.10. This example uses sys12-dhcp for the root name.

Figure 11-18 DHCP Address Configuration Wizard – Step 2 Window

4. Verify that Managed by Server and Starting IP Address display the

correct information.
5. If appropriate, select Generate Client Names.
6. Click >.

11-22 Network Administration for the Solaris™ 10 Operating System

The DHCP Address Configuration Wizard – Step 3 window appears.

Figure 11-19 shows you the IP addresses that you specified in the
previous step.

Figure 11-19 DHCP Address Configuration Wizard – Step 3 Window

7. Verify that the address information is correct, and click >.

Configuring DHCP 11-23

The DHCP Address Configuration Wizard – Step 4 window appears.

Figure 11-20 shows you the name of the macro to be associated with
the DHCP interface.

Figure 11-20 DHCP Address Configuration Wizard – Step 4 Window

8. Select Configuration Macro from the drop-down list box and verify
that Addresses are unusable is unchecked.
9. If you want to view the contents of the selected macro, click View. To
exit the contents window, click OK.
10. Click >.

11-24 Network Administration for the Solaris™ 10 Operating System

The DHCP Address Configuration Wizard – Step 5 window appears.

Figure 11-21 shows you where to specify the type of lease. This
example uses the default of Dynamic.

Figure 11-21 DHCP Address Configuration Wizard – Step 5 Window

Note – Normally, routers, mail servers, and systems that provide services
use permanent lease types.

11. Select either Dynamic or Permanent, and click >.

Configuring DHCP 11-25

The DHCP Address Configuration Wizard – Step 6 window appears.

Figure 11-22 shows the information that you entered in previous
steps.

Figure 11-22 DHCP Address Configuration Wizard – Step 6 Window

12. Review the information, and click Finish.

11-26 Network Administration for the Solaris™ 10 Operating System

The DHCP Manager Window appears. Figure 11-23 shows the

information that you have provided.

Figure 11-23 DHCP Manager Window

13. Choose Exit from the File menu to close the DHCP Manager
window.
14. To view the information that the dhcpmgr utility added to the
/etc/inet/hosts file, use the grep command:
# grep dhcp /etc/inet/hosts
192.168.1.10 sys13-dhcp-10 #net1
192.168.1.11 sys13-dhcp-11 #net1
192.168.1.12 sys13-dhcp-12 #net1
192.168.1.13 sys13-dhcp-13 #net1
192.168.1.14 sys13-dhcp-14 #net1
192.168.1.15 sys13-dhcp-15 #net1
192.168.1.16 sys13-dhcp-16 #net1
192.168.1.17 sys13-dhcp-17 #net1
192.168.1.18 sys13-dhcp-18 #net1
192.168.1.19 sys13-dhcp-19 #net1
#

Configuring DHCP 11-27

Using the dhcpconfig Command

Use the dhcpconfig command when you configure a DHCP server with
scripts. This command has options that enable you to:
● Configure and unconfigure a DHCP server
● Convert to a new data store
● Import data to and export data from other DHCP servers

Note – The dhcpconfig command is no longer menu-driven as it was in

previous versions of the Solaris OS.

Configuring a DHCP Server

To configure a DHCP server for the first time, type the command by using
the following format:
/usr/sbin/dhcpconfig -D -r datastore -p location

where:

-D This option specifies to configure the DHCP

service.
-r datastore This option is a data resource, which is one of the
following: SUNWfiles, SUNWbinfiles, or
SUNWnisplus.
-p location This option is the data-store-dependent location
where the DHCP data is maintained. For
SUNWfiles and SUNWbinfiles, this is an absolute
path name; for example, /var/dhcp. For
SUNWnisplus, this is an NIS+ table name.

The dhcpconfig command uses the appropriate system and network

configuration files, such as /etc/inet/hosts, /etc/inet/netmasks
or others, on the DHCP server to determine values that are not provided
on the command line.

11-28 Network Administration for the Solaris™ 10 Operating System

To configure (-D) a system for DHCP services using ASCII files for
datastore (-r) and locate (-p) the datastore files in the /var/dhcp
directory, enter the following:
# /usr/sbin/dhcpconfig -D -r SUNWfiles -p /var/dhcp
Created DHCP configuration file.
Created dhcptab.
Added "Locale" macro to dhcptab.
Added server macro to dhcptab - sys12.
DHCP server started.
#

Note – Using the ASCII datastore format (SUNWfiles) is much slower

than storing the files in the binary datastore format (SUNWbinfiles). The
examples use the ASCII datastore format because the resulting files are
viewed more easily.

After the datastore location and type are established, you must configure
the appropriate files to function as a DHCP server.

To configure the system to provide DHCP services for the 192.168.1.0

network (-N) and the 192.168.1.1 router (-t), type the command:
# /usr/sbin/dhcpconfig -N 192.168.1.0 -t 192.168.1.1
Added network macro to dhcptab - 192.168.1.0.
Created network table.
#

Configuring DHCP 11-29

Introducing DHCP Network Files

DHCP network files contain the ranges of IP addresses that the DHCP
server assigns and controls for networks. These files map the client
identifiers of DHCP clients to IP addresses and the associated
configuration parameters of each IP address assigned to these clients.
Figure 11-24 shows the interaction between the client ID and the client
and the server addresses.

DHCP
Network

192.168.1.0

Client ID IP Address and

Configuration Parameters

00 Client Address:

192.168.30.1
Server Address:

192.168.30.30

Figure 11-24 The DHCP Network File

One DHCP network file exists for each network that is served by the
DHCP server. The name of each file is determined from the datastore
format and the network address of the network that it supports, such as
SUNWfiles1_192_168_1_0. There is no table or file with the name
SUNWfiles. The name always includes an IP address and an identifier
about the file type (SUNWbinfiles, SUNWfiles, or SUNWnisplus).

11-30 Network Administration for the Solaris™ 10 Operating System

To view the initial contents of the DHCP network file, type the command:
# cat SUNWfiles1_192_168_1_0
# SUNWfiles1_192_168_1_0
#
# Do NOT edit this file by hand -- use pntadm(1M) or dhcpmgr(1M) instead
#

The DHCP network tables can exist as ASCII text files, binary files, or
NIS+ tables, depending on the datastore used. Binary files are faster and
more efficient and are recommended for networks with a DHCP client
base of many thousands of systems.

Using the pntadm Command

Use the pntadm command to manage DHCP network tables to:
● Add and remove networks under DHCP management
● Add, delete, and modify IP address records within network tables
● View tables

You can use any one of the following option flags with the pntadm
command:

-C Creates a DHCP network table

-A Adds an entry to a DHCP network table
-M Modifies an entry made to a DHCP network table
-P Views changes made to a DHCP network table
-D Deletes an entry from a DHCP network table
-r Uses the supplied datastore resource, not the default database
-p Uses the supplied path, not the default path

Creating a Table for the 192.168.30.0 DHCP Network

To create a table for the 192.168.30.0 network, type the command:

# pntadm -C 192.168.30.0

Configuring DHCP 11-31

Note – You can use an alias name for this network in place of the network
number if the alias is defined in the /etc/inet/networks file.

To verify that the network table was created, type the command:
# ls /var/dhcp | grep 30
SUNWfiles1_192_168_30_0
#

To view the initial contents of the new table, use the cat command:
# cat /var/dhcp/SUNWfiles1_192_168_30_0
# SUNWfiles1_192_168_30_0
#
# Do NOT edit this file by hand -- use pntadm(1M) or dhcpmgr(1M) instead
#

Adding an Entry to the SUNWfiles1_192.168.30.0 Table

To add an entry to the SUNWfiles1_192.168.30.0 table located in the

/var/dhcp directory, type the command:
# pntadm -r SUNWfiles -p /var/dhcp -A 192.168.30.1 192.168.30.0

To view the table and observe the changes made by the pntadm command,
type the command:
# cat /var/dhcp/SUNWfiles1_192_168_30_0
# SUNWfiles1_192_168_30_0
#
# Do NOT edit this file by hand -- use pntadm(1M) or dhcpmgr(1M) instead
192.168.30.1|00|00|192.168.1.2|0|8214847195300495361|UNKNOWN|
#

11-32 Network Administration for the Solaris™ 10 Operating System

Modifying an Entry to the SUNWfiles1_192.168.30.0 Table

To modify the 192.168.30.1 entry of the SUNWfiles1_192.168.30.0

table to change the macro name (-m) to mymacro, and to set the flags
field to MANUAL and PERMANENT, type the command:
# pntadm -M 192.168.30.1 -m mymacro -f ’PERMANENT+MANUAL’ 192.168.30.0
#

To view the changes, type the following:

# pntadm -P 192.168.30.0
Client ID Flags Client IP Server IP Lease Expiration Macro Comment
00 03 192.168.30.1 192.168.1.2 Zero mymacro
#

Note – Observe that the Flags value is 03, which represents the sum of 2
and 1, where MANUAL is represented by 2 and PERMANENT is represented
by 1. Refer to the DHCP network man page for more information.

To view the changes by using the table, type the command:

# cat /var/dhcp/SUNWfiles1_192_168_30_0
# SUNWfiles1_192_168_30_0
#
# Do NOT edit this file by hand -- use pntadm(1M) or dhcpmgr(1M) instead
#
192.168.30.1|00|03|192.168.1.2|0|8214847195300495362|mymacro|
#

To change the 192.168.30.1 entry to 192.168.30.2 (-n), type the

command:
# pntadm -M 192.168.30.1 -n 192.168.30.2 192.168.30.0

To verify the changes, type the command:

# pntadm -P 192.168.30.0
Client ID Flags Client IP Server IP Lease Expiration Macro Comment
00 03 192.168.30.2 192.168.1.2 Zero mymacro
#

To delete the 192.168.30.2 entry from the 192.168.30.0 table, type the
command:
# pntadm -D 192.168.30.2 192.168.30.0

Configuring DHCP 11-33

To verify the changes, type the command:

# pntadm -P 192.168.30.0
Client ID Flags Client IP Server IP Lease Expiration Macro Comment
#

Removing DHCP Network Tables

To list the existing DHCP tables, type the command:

# pntadm -L
192.168.1.0
192.168.30.0
#

To remove the 192.168.30.0 table, type the command:

# pntadm -R 192.168.30.0
#

To list the remaining DHCP tables, type the command:

# pntadm -L
192.168.1.0
#

Introducing the dhcptab Table

Use the dhcptab configuration table to organize groups of configuration
parameters as macro definitions. You can reference one macro in the
definition of other macros. The DHCP server uses these macros to return
groups of configuration parameters to DHCP and BOOTP clients.

The preferred methods of managing the dhcptab table are through the
use of the dhcpmgr utility or dhtadm command.

View the contents of the dhcptab table by using the Macros and Options
tabs in the DHCP Manager, or by using the dhtadm -P command on the
command line.

11-34 Network Administration for the Solaris™ 10 Operating System

Using the dhtadm Command

Use the dhtadm command to manage the DHCP service configuration

table, dhcptab. You can specify one of the following option flags:

-C Creates the DHCP table

-A Adds a symbol or macro definition to the DHCP table
-M Modifies an existing symbol or macro definition
-D Deletes a symbol or macro definition

Symbols are individual parameters to which values can be assigned.

Macros are collections of symbols that are associated with an IP address
and are used to define the set of information that is given to a DHCP
client system

To create the DHCP service configuration table, dhcptab, type the

command:
# dhtadm -C

To add a symbol called NewSym to the dhcptab table, type the command:
# dhtadm -A -s NewSym -d ’Vendor=SUNW.PCW.LAN,20,IP,1,0’ -r SUNWfiles -p
/var/dhcp

To add a macro called NewMacro to the dhcptab table, type the command:
# dhtadm -A -m NewMacro
’:Timeserv=192.168.1.1:DNSserv=192.168.1.1:’
#

To view the changes, type the command:

# dhtadm -P
Name Type Value
==================================================
NewMacro Macro :Timeserv=192.168.1.1:DNSserv=192.168.1.1:
192.168.1.0 Macro :Subnet=255.255.255.0:Router=192.168.1.1:Broadcst=192.168.1.255:
sys12 Macro :Include=Locale:Timeserv=192.168.1.1:LeaseTim=86400:LeaseNeg:
Locale Macro :UTCoffst=-25200:
NewSym Symbol Vendor=SUNW.PCW.LAN,20,IP,1,0
#

Configuring DHCP 11-35

You can modify an existing symbol or macro definition. In this example,

to remove the Timeserv symbol from the NewMacro macro, type the
command:
# dhtadm -M -m NewMacro -e ’Timeserv=’

To view the changes, type the command:

# dhtadm -P
Name Type Value
==================================================
NewMacro Macro :DNSserv=192.168.1.1:
192.168.1.0 Macro :Subnet=255.255.255.0:Router=192.168.1.1:Broadcst=192.168.1.255:
sys12 Macro :Include=Locale:Timeserv=192.168.1.1:LeaseTim=86400:LeaseNeg:
Locale Macro :UTCoffst=-25200:
NewSym Symbol Vendor=SUNW.PCW.LAN,20,IP,1,0
#

To define a value for the LeaseTim symbol, type the command:

# dhtadm -M -m NewMacro -e ’LeaseTim=3600’
#

To view the changes, type the command:

# dhtadm -P
Name Type Value
==================================================
NewMacro Macro :DNSserv=192.168.1.1:LeaseTim=3600:
192.168.1.0 Macro :Subnet=255.255.255.0:Router=192.168.1.1:Broadcst=192.168.1.255:
sys12 Macro :Include=Locale:Timeserv=192.168.1.1:LeaseTim=86400:LeaseNeg:
Locale Macro :UTCoffst=-25200:
NewSym Symbol Vendor=SUNW.PCW.LAN,20,IP,1,0
#

To delete the NewSym symbol from the dhcptab table, type the command:
# dhtadm -D -s NewSym
#

To verify the changes, type the command:

11-36 Network Administration for the Solaris™ 10 Operating System

To delete the NewMacro macro from the dhcptab table, type the command:
# dhtadm -D -m NewMacro

To verify the changes, type the command:

# dhtadm -P
Name Type Value
==================================================
192.168.1.0 Macro :Subnet=255.255.255.0:Router=192.168.1.1:Broadcst=192.168.1.255:
sys12 Macro :Include=Locale:Timeserv=192.168.1.1:LeaseTim=86400:LeaseNeg:
Locale Macro :UTCoffst=-25200:
#

Table 11-1 shows the items that are created during DHCP configuration.

Table 11-1 Items Created During DHCP Server Configuration

Item Description Contents

The service configuration Records keywords and Data store type and
file, values for server location. Options used with
/etc/inet/dhcpsvc.conf configuration options. the in.dhcpd daemon to
start the DHCP daemon
when the system boots.
The dhcptab table Creates a dhcptab table if it Macros and options with
does not already exist. assigned values.
The Locale macro Contains the local time The UTCoffst option.
(optional) zone’s offset in seconds
from Coordinated Universal
Time.
The server macro, named to Contains options with The Locale macro. The
match the server’s node values determined by input options: Palatinoerv,
name from the administrator who which is set to point to the
configured the DHCP server’s primary IP address;
server. The options apply to LeaseTim and LeaseNeg, if
all clients that use addresses you select negotiable leases;
owned by the server. and DNSdmain and DNSserv,
if DNS is configured.

Configuring DHCP 11-37

Table 11-1 Items Created During DHCP Server Configuration (Continued)

Item Description Contents

The network address macro, Contains options with The options: Subnet
which is named the same as values determined by input Router or RDiscvyF
the network address of the from the administrator who Broadcst, if the network is
client’s network configured the DHCP a LAN, maximum transfer
server. The options apply to unit (MTU); NISdmain and
all clients that are located on NISservs, if NIS is
the network specified by the configured; and
macro name. NIS+dom and NIS+serv, if
NIS+ is configured.
The DHCP network table Creates an empty table until None, until you add the IP
for the network you create the IP addresses addresses.
for the network.

11-38 Network Administration for the Solaris™ 10 Operating System

Configuring and Managing DHCP Clients

Configuring DHCP clients is an easy process. Most management is
performed on the DHCP server side.

Configuring a DHCP Client

When you install the Solaris 10 OS from the installation compact disc,
read-only memory (CD-ROM), you are prompted to use DHCP to
configure network interfaces. If you select yes in the installation script,
the DHCP client software is enabled on your system during Solaris 10 OS
installation. You do not need to do anything else on the Solaris 10 OS
client to use DHCP.

If your client is not a Solaris 10 OS client, consult the client’s

documentation for configuration instructions.

Configuring a DHCP Client to Request a Dynamic Host Name

If a client system is already running the Solaris 10 OS and is not using

DHCP, complete the following steps to configure the DHCP client to
request dynamic host names:
1. Log in as the root user on the DHCP client system.
2. Enable DHCP on the client by creating the appropriate file for the
external interface, which is hme0 in this example.
# touch /etc/dhcp.hme0

Note – Verify that the /etc/hostname.interface file exists for the

interface being configured using DHCP; otherwise, the interface will not
be plumbed. This is a requirement for a successful DHCP configuration of
the client.

3. Configure the /etc/default/dhcpagent file on the DHCP client so

that it releases its IP address if it is rebooted or shut down.
4. Edit the /etc/default/dhcpagent file, and remove the # in front of
the RELEASE_ON_SIGTERM=yes parameter. This causes the DHCP
client to relinquish its address when it reboots or is shut down
properly.

Configuring DHCP 11-39

5. Reboot the client, and watch the system console as the system boots.
6. Observe the hostname, for example:
Copyright 1983-2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: sys13-dhcp-14

Configuring a DHCP Client to Use its Own Host Name

DHCP clients running the Solaris 10 OS can be configured to use their

own hostname instead of a hostname supplied by the DHCP server.

If a client system is already running the Solaris 10 OS and is not using

DHCP, complete the following steps to configure the DHCP client to use
its own host name:
1. Log in as the root user on the DHCP client system.
2. Edit the /etc/default/dhcpagent file.
3. Find the keyword REQUEST_HOSTNAME in the
/etc/default/dhcpagent file, and verify that the entry is not
formatted as a comment and is set to yes:
REQUEST_HOSTNAME=yes
4. Edit the /etc/hostname.interface file on the client system, and
enter the following:
inet hostname
where hostname is the name you want the client to use. For example,
the file contents in this example are:
# cat /etc/hostname.qfe0
inet dhcp-hostname-test
#
5. To have the client perform a full DHCP negotiation upon rebooting,
type the commands:
# pkill dhcpagent
# rm /etc/dhcp/interface.dhc
# init 6

Note – The state file is written only when the dhcpagent process is
terminated and the dhcpagent program is not configured to release its IP
address on termination.

11-40 Network Administration for the Solaris™ 10 Operating System

The DHCP server makes sure that the host name is not in use by another
system on the network before the server assigns it to the client.
Depending on how the DHCP server is configured, it can also update
naming services with the client’s host name.

If your client is not a Solaris 10 OS client, consult the client’s

documentation for configuration instructions.

Configuring DHCP 11-41

Troubleshooting a DHCP Server

IP address allocation errors are reported using the syslog facility or as
server debug output. This type of problem can occur when a client
attempts to obtain or verify an IP address.

The following are possible IP address allocation errors and solutions:

● There is no n.n.n.n dhcp-network table for DHCP
client’s network
This error message means that a client requests a specific IP address
or seeks to extend a lease on its current IP address, but the DHCP
server cannot find the DHCP network table for that address.
The DHCP network table might have been deleted by mistake.
Recreate the DHCP network table by adding the network again
using the dhcpmgr utility or the pntadm command.
● ICMP ECHO reply to the OFFER candidate is n.n.n.n,
disabling
The IP address considered for a DHCP client is already in use. This
might occur if more than one DHCP server owns the address or if an
address is manually configured for a non-DHCP network client.
Determine the correct ownership of the address, and correct either
the DHCP server database or the host’s network configuration.
● ICMP ECHO reply to OFFER candidate n.n.n.n. No
corresponding dhcp network record
The IP address considered for a DHCP client does not have a record
in a network table. This might occur if the IP address record is
deleted from the DHCP network table after the address is selected,
but before the duplicate address check is complete.
Use the dhcpmgr utility or the pntadm command to view the DHCP
network table. If the IP address is missing, create it with the DHCP
Manager (select Create from the Edit menu on the Address tab) or
use the pntadm command.

11-42 Network Administration for the Solaris™ 10 Operating System

● DHCP network record for n.n.n.n is unavailable,

ignoring request
The record for the requested IP address is not in the DHCP network
table; therefore, the server drops the request.
Use the dhcpmgr utility or the pntadm command to view the DHCP
network table and, if the IP address is missing, create it with the
dhcpmgr utility (select Create from the Edit menu on the Address
tab) or use the pntadm command.
● n.n.n.n currently marked as unusable
The requested IP address cannot be offered because it is marked
unusable in the network table.
Use the DHCP Manager or the pntadm command to make the
address usable.
● n.n.n.n was manually allocated. No dynamic address will
be allocated.
The client’s ID is assigned a manually allocated address, and that
address is marked “unusable.” The server cannot allocate a different
address to this client.
Use the DHCP Manager or the pntadm command to make the
address usable, or manually allocate a different address to the client.
● Manual allocation (n.n.n.n, client ID has n other
records). Should have 0.
The client that has the specified client ID is manually assigned more
than one IP address. There should be only one address. The server
selects the last manually assigned address it finds in the network
table.
Use the DHCP Manager or the pntadm command to modify IP
addresses to remove the additional manual allocations.
● No more IP addresses on n.n.n.n network.
All IP addresses that are currently managed by DHCP on the
specified network are allocated.
Use the DHCP Manager or the pntadm command to create new IP
addresses for this network.

Configuring DHCP 11-43

● Client: clientID lease for n.n.n.n expired.

The lease was not negotiable, and it has timed out.
The client restarts the protocol to obtain a new lease.
● Offer expired for client: n.n.n.n
The server made an IP address offer to the client, but the client took
too long to respond, and the offer expired.
The client issues another discover message. If this request times out,
increase the cache-offer timeout for the DHCP server. In the DHCP
Manager, select Modify from the Service menu.
● Client: clientID REQUEST is missing requested IP
option.
The client’s request did not specify the offered IP address, so the
DHCP server ignores the request. This problem might occur if the
client is not compliant with the updated DHCP, RFC 2131.
Update the client software.
● Client: clientID is trying to renew n.n.n.n, an IP
address it has not leased.
The IP address recorded in the DHCP network table for this client
does not match the IP address that the client specified in its renewal
request. The DHCP server does not renew the lease.
This problem occurs if you delete a client’s record while the client is
still using the IP address.
Use the DHCP Manager or the pntadm command to examine the
network table, and correct if necessary. The client’s ID should be
bound to the specified IP address. If it is not, edit the address
properties to add the client ID.
To enable the client to receive a new lease immediately, restart the
DHCP agent on the client by typing the commands:
# ifconfig interface dhcp release
# ifconfig interface dhcp start

11-44 Network Administration for the Solaris™ 10 Operating System

Troubleshooting DHCP Clients

The problems you might encounter with a DHCP client fall into the
following categories:
● Problems communicating with the DHCP server
● Problems with inaccurate DHCP configuration information

After you enable the client software and reboot the system, the client tries
to reach the DHCP server to obtain its network configuration. If the client
fails to reach the server or if the client does not receive correct
information, you can see error messages, such as:
DHCP or BOOTP server not responding
Need router-ip to communicate with TFTP server
TFTP server’s IP address not known!

Before you determine the problem, you must gather diagnostic

information from both the client and the server, and analyze this
information. To gather information, you can:
● Run the client in debug mode.
● Run the server in debug mode.
● Start the snoop utility to monitor network traffic.

You can perform these tasks separately or concurrently.

The information you gather can help you determine if the problem is with
the client, server, or a relay agent.

Configuring DHCP 11-45

Exercise: Configuring a DHCP Server and Client

In this exercise, you configure a basic DHCP server and client
configuration.

Preparation
Before performing this exercise, do the following:
● Refer to your network diagram to determine the function of each
system on your subnet.
● Refer to the lecture notes as necessary to perform the tasks listed.

Note – Use the default configuration parameters in these exercises unless

otherwise specified.

The exercise examples show the DHCP server as 192.168.X.3 and the
DHCP client as 192.168.X.4. The complete system and server-client
functions for these exercises are shown in Table 11-2.

Table 11-2 Exercise Host Functions

Host Function

Instructor Root DNS name server

sysX1 Router
sysX2 Primary DNS name server, DNS client
sysX3 Secondary DNS name server, DNS client, DHCP server
sysX4 DNS client, DHCP client

11-46 Network Administration for the Solaris™ 10 Operating System

Task Summary
In this exercise, you accomplish the following tasks:
● Configure a DHCP server.
● Configure a DHCP client.
● Use the snoop utility to view DHCP client server interaction.

Task 1 – Configuring the DHCP Server

Complete the steps in this section.

Working on the sysX3 System

In this part of the exercise, use the DHCP Manager graphical user
interface (GUI) utility (dhcpmgr utility) to configure a DHCP server on
your subnet. Permit the network wizard to start and configure at least five
hosts with the address range starting at 192.168.xxx.xxx, where
xxx.xxx is provided by the instructor depending on the classroom setup.

Note – Use the default configuration parameters in this task unless

otherwise specified.

This example uses the sys13 system to demonstrate configuring a basic

DHCP server with the dhcpmgr GUI utility.

To configure the DHCP server, complete the following steps:

1. Start the dhcpmgr utility.
2. Initially configure the DHCP server.
3. Add at least five addresses.
4. To view the information that the dhcpmgr utility added to the
/etc/inet/hosts file, use the grep command.

Configuring DHCP 11-47

Task 2 – Configuring the DHCP Client

Complete the steps in this section.

Working on the sysX4 System

This example uses the sys14 system as the DHCP client. To configure the
DHCP client, complete the following steps:
1. Log in as the root user on the DHCP client.
2. Enable DHCP on the client.
3. Configure the /etc/default/dhcpagent file on the DHCP client so
that it releases its IP address if it is rebooted or is shut down.
4. Reboot the client, and watch the system console as the system boots.

Task 3 – Using the snoop Utility to View DHCP

Client-Server Interaction
An important part of troubleshooting DHCP issues is using the snoop
utility to observe the network interaction between the server and the
client.

To view DHCP client-server interaction, complete the following steps:

1. Start the snoop utility on any system on the subnet other than the
DHCP client. Be sure to use the snoop utility on an interface that is
on the same subnet as the DHCP client, which is hme0 in this
example. Have the snoop utility write to the /tmp/dhcp-snoop.snp
file.
2. Reboot the DHCP client system.
3. After the DHCP client is booted, stop the snoop utility by pressing
the Control+C key sequence.
4. View the summary of the captured information.

11-48 Network Administration for the Solaris™ 10 Operating System

5. Use the snoop utility to convert the trace data to ASCII text, and
output that text to the /tmp/dhcp-snoop.txt file for viewing with
any text editor that provides easy navigation and searching of the
data.
6. Use the view utility to view the trace data in the
/tmp/dhcp-snoop.txt file. Look for messages, such as
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, in the trace.
Observe the ETHER destination addresses, the source and destination
IP addresses, and the DHCP messages.
7. Prevent the client system from continuing to act as a DHCP by
removing the /etc/dhcp.* files and rebooting the system.

Configuring DHCP 11-49

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

11-50 Network Administration for the Solaris™ 10 Operating System

Exercise Solutions
Solutions to the exercise are provided in this section.

Task 1 – Configuring the DHCP Server

Complete the steps in this section.

Working on the sysX3 System

In this part of the exercise, use the DHCP Manager GUI utility
(dhcpmgr utility) to configure a DHCP server on your subnet. Permit the
network wizard to start and configure at least five hosts with the address
range starting at 192.168.xxx.xxx, where xxx.xxx is provided by the
instructor depending on the classroom setup.

Note – Use the default configuration parameters in this task unless

otherwise specified.

This example uses the sys13 system to demonstrate configuring a basic

DHCP server with the dhcpmgr GUI utility.

To configure the DHCP server, complete the following steps:

1. Start the dhcpmgr utility.
# /usr/sadm/admin/bin/dhcpmgr &
2. Initially configure the DHCP server.

Configuring DHCP 11-51

If the system is not configured as a DHCP server or BOOTP relay,

Figure 11-25 appears.

Figure 11-25 Choose Server Configuration Window

Perform the following:

a. Click OK.
The DHCP Configuration Wizard – Step 1 window in Figure 11-26
appears.

Figure 11-26 DHCP Configuration Wizard – Step 1 Window

11-52 Network Administration for the Solaris™ 10 Operating System

b. Select Text files, and click >.

The DHCP Configuration Wizard – Step 2 window in Figure 11-27
appears. This example uses the default directory.

Figure 11-27 DHCP Configuration Wizard – Step 2 Window

c. Accept the default path name, and click >.

Configuring DHCP 11-53

The DHCP Configuration Wizard – Step 3 window in Figure 11-28

appears.

Figure 11-28 DHCP Configuration Wizard – Step 3 Window

d. Select /etc/hosts, and click >.

11-54 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 4 window in Figure 11-29

appears. This example uses the defaults 1 and days.

Figure 11-29 DHCP Configuration Wizard – Step 4 Window

e. Accept the defaults of 1, days, and Clients can renew their leases,
then click >.

Configuring DHCP 11-55

The DHCP Configuration Wizard – Step 5 window in Figure 11-30

appears. This example uses the default DNS information.

Figure 11-30 DHCP Configuration Wizard – Step 5 Window

f. Accept the default DNS domain and DNS servers, and click >.

11-56 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 6 window in Figure 11-31

appears. This example uses the 192.168.1.0 network.

Figure 11-31 DHCP Configuration Wizard – Step 6 Window

g. Specify a network address by either selecting one or typing one, type a

subnet mask, and click >.

Configuring DHCP 11-57

The DHCP Configuration Wizard – Step 7 window in Figure 11-32

appears. This example uses the defaults of Local-Area (LAN) and Use
router discovery protocol.

Figure 11-32 DHCP Configuration Wizard – Step 7 Window

h. Select Local-Area (LAN).

i. Select Use router discovery protocol.
j. Click >.

11-58 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 8 window in Figure 11-33

appears. This example uses the defaults of no NIS Domain and no NIS
Servers.

Figure 11-33 DHCP Configuration Wizard – Step 8 Window

k. Accept the defaults, no entries, as shown.

l. Click >.

Configuring DHCP 11-59

The DHCP Configuration Wizard – Step 9 window in Figure 11-34

appears. This example uses the defaults of no NIS+ domain and no
NIS+ servers.

Figure 11-34 DHCP Configuration Wizard – Step 9 Window

m. Accept the default of no entries, as shown.

n. Click >.

11-60 Network Administration for the Solaris™ 10 Operating System

The DHCP Configuration Wizard – Step 10 window in Figure 11-35

appears. This example uses the sample information indicated
previously.

Figure 11-35 DHCP Configuration Wizard – Step 10 Window

o. Review the information and, if the information is correct, click Finish.

Configuring DHCP 11-61

The DHCP Configuration Manager Window closes, the main DHCP

Manager Window appears, and the Start Address Wizard window in
Figure 11-36 appears.

Figure 11-36 Start Address Wizard Window

p. Click Yes to proceed with address configuration.

11-62 Network Administration for the Solaris™ 10 Operating System

The DHCP Address Configuration Wizard – Step 1 window in

Figure 11-37 appears. This example uses five addresses and a comment
of net1.

Figure 11-37 DHCP Address Configuration Wizard – Step 1 Window

3. Add at least five addresses.

Perform the following:
a. Enter 5 in the Number of IP Addresses field.
b. Add the comment net1 in this example. (This is the comment
appended to the end of each DHCP-managed IP address line added to
the /etc/inet/hosts file).
c. Click >.

Configuring DHCP 11-63

The DHCP Address Configuration Wizard – Step 2 window in

Figure 11-38 appears. In this example, the Managed by Server field is
set to the default, and the starting IP address must be changed to
192.168.1.10. This example allows client name generation and
uses sys13-dhcp for the root name.

Figure 11-38 DHCP Address Configuration Wizard – Step 2 Window

d. Verify that Managed by Server and Starting IP Address fields display

the correct information.
e. Select Generate Client Names.
f. Type a name in the Root Name field.
g. Click >.

11-64 Network Administration for the Solaris™ 10 Operating System

The DHCP Address Configuration Wizard – Step 3 window in

Figure 11-39 appears.

Figure 11-39 DHCP Address Configuration Wizard – Step 3 Window

h. Verify that the address information is correct, and click >.

Configuring DHCP 11-65

The DHCP Address Configuration Wizard – Step 4 window in

Figure 11-40 appears.

Figure 11-40 DHCP Address Configuration Wizard – Step 4 Window

i. Use the default Configuration Macro and verify that Addresses are
unusable is checked.
j. Click >.

11-66 Network Administration for the Solaris™ 10 Operating System

The DHCP Address Configuration Wizard – Step 5 window in

Figure 11-41 appears. This example uses the default Dynamic.

Figure 11-41 DHCP Address Configuration Wizard – Step 5 Window

k. Select Dynamic, and click >.

Configuring DHCP 11-67

The DHCP Address Configuration Wizard – Step 6 window in

Figure 11-42 appears.

Figure 11-42 DHCP Address Configuration Wizard – Step 6 Window

l. Review the information, and click Finish.

Note – You can continue without problems if one or two addresses are
already in use from earlier exercises.

11-68 Network Administration for the Solaris™ 10 Operating System

The DHCP Manager window in Figure 11-43 appears.

Figure 11-43 DHCP Manager Window

m. Select Exit from the File menu to close the DHCP Manager window.
4. To view the information that the dhcpmgr utility added to
the/etc/inet/hosts file, use the grep command:
# grep dhcp /etc/inet/hosts
192.168.1.10 sys13-dhcp-10 #net1
192.168.1.11 sys13-dhcp-11 #net1
192.168.1.12 sys13-dhcp-12 #net1
192.168.1.13 sys13-dhcp-13 #net1
192.168.1.14 sys13-dhcp-14 #net1
#

Task 2 – Configuring the DHCP Client

Complete the steps in this section.

Working on the sysX4 System

This example uses the sys14 system as the DHCP client. To configure the
DHCP client, complete the following steps:
1. Log in as the root user on the DHCP client.
2. Enable DHCP on the client.
Create the appropriate file for the external interface, which is hme0 in this
example.
The command syntax used to enable the DHCP client is:
# touch /etc/dhcp.hme0

Configuring DHCP 11-69

Note – Verify that the /etc/hostname.interface file exists for the

interface being configured using DHCP; otherwise, the interface is not
plumbed. This is a requirement for a successful DHCP configuration of
the client.

3. Configure the /etc/default/dhcpagent file on the DHCP client so

that it releases its IP address if it is rebooted or is shut down.
Edit the /etc/default/dhcpagent file, and remove the # in front of the
RELEASE_ON_SIGTERM=yes parameter.
4. Reboot the client, and watch the system console as the system boots.
You should see something similar to the following:
SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: sys13-dhcp-14

Task 3 – Using the snoop Utility to View DHCP

Client-Server Interaction
An important part of troubleshooting DHCP issues is using the snoop
utility to observe the network interaction between the server and the
client.

To view DHCP client-server interaction, complete the following steps:

1. Start the snoop utility on any system on the subnet other than the
DHCP client. Be sure to use the snoop utility on an interface that is
on the same subnet as the DHCP client, which is hme0 in this
example. Have the snoop utility write to the /tmp/dhcp-snoop.snp
file.
# snoop -d hme0 -o /tmp/dhcp-snoop.snp
Using device /dev/hme (promiscuous mode)
2. Reboot the DHCP client system.
# init 6
3. After the DHCP client has booted, stop the snoop utility by pressing
the Control+C key sequence.

11-70 Network Administration for the Solaris™ 10 Operating System

4. View the summary of the captured information.

# snoop -i /tmp/dhcp-snoop.snp | more
1 0.96445 192.168.1.1 -> 192.168.1.255 RIP R (3 destinations)
2 1.02589 fe80::203:baff:fe6b:5e06 -> ff02::9 RIPng R (6 destinations)
...
...
24 1.51914 192.168.1.14 -> sys13.one.edu DHCP/BOOTP DHCPRELEASE
...
...
105 0.61469 OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER
106 0.00254 sys13.one.edu -> 192.168.1.14 ICMP Echo request (ID: 4 Sequence number: 0)
107 1.00656 sys13.one.edu -> 192.168.1.14 DHCP/BOOTP DHCPOFFER
108 0.37637 ? -> (multicast) ETHER Type=0001 (LLC/802.3), size = 52 bytes
109 0.79455 OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPREQUEST
110 0.01810 sys13.one.edu -> 192.168.1.14 DHCP/BOOTP DHCPACK
111 0.00096 OLD-BROADCAST -> (broadcast) ARP C Who is 192.168.1.14, 192.168.1.14 ?
112 1.00432 192.168.1.14 -> (broadcast) ARP C Who is 192.168.1.14, 192.168.1.14 ?
...
5. Use the snoop utility to convert the trace data to ASCII text, and
output that text to the /tmp/dhcp-snoop.txt file for viewing with
any text editor that provides easy navigation and searching of the
data.
# snoop -v -i /tmp/dhcp-snoop.snp > /tmp/dhcp-snoop.txt
6. Use the view utility to view the trace data in the
/tmp/dhcp-snoop.txt file. Look for messages, such as
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, in the trace.
Observe the ETHER destination addresses, the source and destination
IP addresses, and the DHCP messages.
DHCPRELEASE:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 24 arrived at 9:31:56.83990
ETHER: Packet size = 342 bytes
ETHER: Destination = 0:3:ba:68:45:39,
ETHER: Source = 0:3:ba:68:44:d3,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability

Configuring DHCP 11-71

IP: .... ..0. = not ECN capable transport

IP: .... ...0 = no ECN congestion experienced
IP: Total length = 328 bytes
IP: Identification = 55877
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 1cfd
IP: Source address = 192.168.1.14, 192.168.1.14
IP: Destination address = 192.168.1.3, sys13.one.edu
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 68
UDP: Destination port = 67 (BOOTPS)
UDP: Length = 308
UDP: Checksum = B341
UDP:
DHCP: ----- Dynamic Host Configuration Protocol -----
DHCP:
DHCP: Hardware address type (htype) = 1 (Ethernet (10Mb))
DHCP: Hardware address length (hlen) = 6 octets
DHCP: Relay agent hops = 0
DHCP: Transaction ID = 0x6fdf1bbf
DHCP: Time since boot = 0 seconds
DHCP: Flags = 0x0000
DHCP: Client address (ciaddr) = 192.168.1.14
DHCP: Your client address (yiaddr) = 0.0.0.0
DHCP: Next server address (siaddr) = 0.0.0.0
DHCP: Relay agent address (giaddr) = 0.0.0.0
DHCP: Client hardware address (chaddr) = 00:03:BA:68:44:D3
DHCP:
DHCP: ----- (Options) field options -----
DHCP:
DHCP: Message type = DHCPRELEASE
DHCP: Error Message = DHCP agent is exiting
DHCP: DHCP Server Identifier = 192.168.1.3

DHCPDISCOVER:

11-72 Network Administration for the Solaris™ 10 Operating System

ETHER: ----- Ether Header -----

ETHER:
ETHER: Packet 105 arrived at 9:34:5.95251
ETHER: Packet size = 342 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 0:3:ba:68:44:d3,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = not ECN capable transport
IP: .... ...0 = no ECN congestion experienced
IP: Total length = 328 bytes
IP: Identification = 4
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 7aa1
IP: Source address = 0.0.0.0, OLD-BROADCAST
IP: Destination address = 255.255.255.255, BROADCAST
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 68
UDP: Destination port = 67 (BOOTPS)
UDP: Length = 308
UDP: Checksum = E7EC
UDP:
DHCP: ----- Dynamic Host Configuration Protocol -----
DHCP:
DHCP: Hardware address type (htype) = 1 (Ethernet (10Mb))
DHCP: Hardware address length (hlen) = 6 octets
DHCP: Relay agent hops = 0
DHCP: Transaction ID = 0x926aa722
DHCP: Time since boot = 48 seconds

Configuring DHCP 11-73

DHCP: Flags = 0x0000

DHCP: Client address (ciaddr) = 0.0.0.0
DHCP: Your client address (yiaddr) = 0.0.0.0
DHCP: Next server address (siaddr) = 0.0.0.0
DHCP: Relay agent address (giaddr) = 0.0.0.0
DHCP: Client hardware address (chaddr) = 00:03:BA:68:44:D3
DHCP:
DHCP: ----- (Options) field options -----
DHCP:
DHCP: Message type = DHCPDISCOVER
DHCP: Maximum DHCP Message Size = 1472 bytes
DHCP: IP Address Lease Time = -1 seconds
DHCP: Client Class Identifier = "SUNW.UltraAX-i2"
DHCP: Requested Options:
DHCP: 1 (Subnet Mask)
DHCP: 3 (Router)
DHCP: 6 (DNS Servers)
DHCP: 12 (Client Hostname)
DHCP: 15 (DNS Domain Name)
DHCP: 28 (Broadcast Address)
DHCP: 43 (Vendor Specific Options)

DHCPOFFER:

11-74 Network Administration for the Solaris™ 10 Operating System

ETHER: ----- Ether Header -----

ETHER:
ETHER: Packet 107 arrived at 9:34:6.96163
ETHER: Packet size = 359 bytes
ETHER: Destination = 0:3:ba:68:44:d3,
ETHER: Source = 0:3:ba:68:45:39,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = not ECN capable transport
IP: .... ...0 = no ECN congestion experienced
IP: Total length = 345 bytes
IP: Identification = 42935
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 4f7a
IP: Source address = 192.168.1.3, sys13.one.edu
IP: Destination address = 192.168.1.14, 192.168.1.14
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 67
UDP: Destination port = 68 (BOOTPC)
UDP: Length = 325
UDP: Checksum = 84B8
UDP:
DHCP: ----- Dynamic Host Configuration Protocol -----
DHCP:
DHCP: Hardware address type (htype) = 1 (Ethernet (10Mb))
DHCP: Hardware address length (hlen) = 6 octets
DHCP: Relay agent hops = 0
DHCP: Transaction ID = 0x926aa722
DHCP: Time since boot = 48 seconds

Configuring DHCP 11-75

DHCP: Flags = 0x0000

DHCP: Client address (ciaddr) = 0.0.0.0
DHCP: Your client address (yiaddr) = 192.168.1.14
DHCP: Next server address (siaddr) = 0.0.0.0
DHCP: Relay agent address (giaddr) = 0.0.0.0
DHCP: Client hardware address (chaddr) = 00:03:BA:68:44:D3
DHCP:
DHCP: ----- (Options) field options -----
DHCP:
DHCP: Message type = DHCPOFFER
DHCP: DHCP Server Identifier = 192.168.1.3
DHCP: UTC Time Offset = -25200 seconds
DHCP: RFC868 Time Servers at = 192.168.1.3
DHCP: IP Address Lease Time = 86400 seconds
DHCP: DNS Domain Name = one.edu
DHCP: DNS Servers at = 192.168.1.2
DHCP: DNS Servers at = 192.168.1.3
DHCP: Broadcast Address = 192.168.1.255
DHCP: Perform Router Discovery Flag flag = 0x1
DHCP: Subnet Mask = 255.255.255.0
DHCP: Client Hostname = sys13-dhcp-14

DHCPREQUEST:

11-76 Network Administration for the Solaris™ 10 Operating System

ETHER: ----- Ether Header -----

ETHER:
ETHER: Packet 109 arrived at 9:34:8.13256
ETHER: Packet size = 342 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 0:3:ba:68:44:d3,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = not ECN capable transport
IP: .... ...0 = no ECN congestion experienced
IP: Total length = 328 bytes
IP: Identification = 5
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 7aa0
IP: Source address = 0.0.0.0, OLD-BROADCAST
IP: Destination address = 255.255.255.255, BROADCAST
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 68
UDP: Destination port = 67 (BOOTPS)
UDP: Length = 308
UDP: Checksum = 9B2C
UDP:
DHCP: ----- Dynamic Host Configuration Protocol -----
DHCP:
DHCP: Hardware address type (htype) = 1 (Ethernet (10Mb))
DHCP: Hardware address length (hlen) = 6 octets
DHCP: Relay agent hops = 0
DHCP: Transaction ID = 0x21a95f6
DHCP: Time since boot = 48 seconds

Configuring DHCP 11-77

DHCP: Flags = 0x0000

DHCP: Client address (ciaddr) = 0.0.0.0
DHCP: Your client address (yiaddr) = 0.0.0.0
DHCP: Next server address (siaddr) = 0.0.0.0
DHCP: Relay agent address (giaddr) = 0.0.0.0
DHCP: Client hardware address (chaddr) = 00:03:BA:68:44:D3
DHCP:
DHCP: ----- (Options) field options -----
DHCP:
DHCP: Message type = DHCPREQUEST
DHCP: IP Address Lease Time = 86400 seconds
DHCP: Maximum DHCP Message Size = 1472 bytes
DHCP: Requested IP Address = 192.168.1.14
DHCP: DHCP Server Identifier = 192.168.1.3
DHCP: Client Class Identifier = "SUNW.UltraAX-i2"
DHCP: Requested Options:
DHCP: 1 (Subnet Mask)
DHCP: 3 (Router)
DHCP: 6 (DNS Servers)
DHCP: 12 (Client Hostname)
DHCP: 15 (DNS Domain Name)
DHCP: 28 (Broadcast Address)
DHCP: 43 (Vendor Specific Options)

DHCPACK:

11-78 Network Administration for the Solaris™ 10 Operating System

ETHER: ----- Ether Header -----

ETHER:
ETHER: Packet 110 arrived at 9:34:8.15066
ETHER: Packet size = 359 bytes
ETHER: Destination = 0:3:ba:68:44:d3,
ETHER: Source = 0:3:ba:68:45:39,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = not ECN capable transport
IP: .... ...0 = no ECN congestion experienced
IP: Total length = 345 bytes
IP: Identification = 44125
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 4ad4
IP: Source address = 192.168.1.3, sys13.one.edu
IP: Destination address = 192.168.1.14, 192.168.1.14
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 67
UDP: Destination port = 68 (BOOTPC)
UDP: Length = 325
UDP: Checksum = 84B8
UDP:
DHCP: ----- Dynamic Host Configuration Protocol -----
DHCP:
DHCP: Hardware address type (htype) = 1 (Ethernet (10Mb))
DHCP: Hardware address length (hlen) = 6 octets
DHCP: Relay agent hops = 0
DHCP: Transaction ID = 0x21a95f6
DHCP: Time since boot = 48 seconds

Configuring DHCP 11-79

DHCP: Flags = 0x0000

DHCP: Client address (ciaddr) = 0.0.0.0
DHCP: Flags = 0x0000
DHCP: Client address (ciaddr) = 0.0.0.0
DHCP: Your client address (yiaddr) = 192.168.1.14
DHCP: Next server address (siaddr) = 0.0.0.0
DHCP: Relay agent address (giaddr) = 0.0.0.0
DHCP: Client hardware address (chaddr) = 00:03:BA:68:44:D3
DHCP:
DHCP: ----- (Options) field options -----
DHCP:
DHCP: Message type = DHCPACK
DHCP: DHCP Server Identifier = 192.168.1.3
DHCP: UTC Time Offset = -25200 seconds
DHCP: RFC868 Time Servers at = 192.168.1.3
DHCP: IP Address Lease Time = 86400 seconds
DHCP: DNS Domain Name = one.edu
DHCP: DNS Servers at = 192.168.1.2
DHCP: DNS Servers at = 192.168.1.3
DHCP: Broadcast Address = 192.168.1.255
DHCP: Perform Router Discovery Flag flag = 0x1
DHCP: Subnet Mask = 255.255.255.0
DHCP: Client Hostname = sys13-dhcp-14

7. Prevent the client system from continuing to act as a DHCP by

removing the /etc/dhcp.* files and rebooting the system.
# rm /etc/dhcp.*
# init 6

11-80 Network Administration for the Solaris™ 10 Operating System

Configuring NTP

Objectives
This module introduces how to configure the Network Time Protocol
(NTP). This module also introduces NTP basics, including how computers
keep time, the uses of NTP, and NTP terms. This module also describes
how to configure an NTP server and an NTP client. In addition, this
module describes how to troubleshoot NTP, including how to view logs
and how to use the snoop utility.

Upon completion of this module, you should be able to:

● Identify NTP basics
● Configure an NTP server
● Configure an NTP client
● Troubleshoot NTP

The course map in Figure 12-1 shows how this module fits into the
current instructional goal.

Configuring and Managing Network Applications

Configuring the
Configuring Configuring Configuring Solaris™ IP
DNS DHCP NTP Filter Firewall

Figure 12-1 Course Map

Identifying NTP Basics

Before you configure NTP, you must be aware of some basic computer
clock and NTP-related concepts.

How Computers Keep Time

This section describes how computers keep time. This is a high-level
introduction and is not meant to be all inclusive.

When the system is not running the Solaris OS, the time-of-day chip
maintains basic 24-hour time. This time is copied into a 64-bit counter
used by the kernel to maintain 24-hour time for a running system.

Sun systems use a combination of an oscillator and a 64-bit counter to

keep track of time. A specific number of oscillations cause an interrupt
that, if processed, will cause the counter to increment.

The Sun system central processing units (CPUs) generate the regular
interrupts. By default, 100 interrupts are generated per second. For the
system’s counter to increment, the CPUs interrupt must be processed by
the kernel. Each interrupt that gets processed is known as a clock tick.
However, not all interrupts get processed. This is often due to high system
loads and higher priority tasks that take precedence within the kernel.
Therefore, gradually, a clock will fall slightly behind because not all time
interrupts are processed. However, the controller boards in Sun FIre™ 12k
to 25k high-end servers use a real-time clock, not the normal 100
interrupts per second method. This makes them excellent NTP servers,
since the clock does not drift as it does on a regular server or workstation.
However, making them an NTP client can cause issues with the SMS
software.

Note – The 32-bit time counter would reach its limit in the year 2038. The
64-bit time counter was started at 0 at midnight, January 1, 1970
Greenwich Mean Time (GMT). The counter will reach its limit in about
290 million years.

Variation in the frequency of the oscillator and delays to the kernel

interrupt routine cause clock drifts. NTP disciplines the system clock
frequency and time, producing more accurate timing mechanisms for the
system.

12-2 Network Administration for the Solaris™ 10 Operating System

Uses of NTP
Many network applications need synchronized clocks to properly
function. For example:
● Encryption – This application often uses time as a component of
encryption keys.
● Network management – This application uses time to determine
exactly when something took place.
● Logging – The syslog facility uses time to display system events.
● File systems – Applications time stamp files when they are created or
modified. Many backup applications are configured to use time as a
criteria for determining backups, so that clock synchronization
between the backup server and other systems is important.
● Cluster Nodes – Individual nodes in a Sun Cluster configuration use
NTP to ensure that they all agree on the time.

NTP Terms
Several terms are used when describing time-related topics. These terms
are described in Table 12-1.

Table 12-1 NTP Terms

Term Description

Reference A clock that provides current time by accurately

clock following a time standard, such as Coordinated
Universal Time (UTC).
Strata NTP servers are arranged in a hierarchy of levels, called
strata. A stratum-1 server is more accurate than a
stratum-10 server. There are 16 strata.
Stratum-1 A highly available NTP server that has its own
server reference clock.
Resolution The smallest increment in time that a clock offers. For
example, a wristwatch usually has a resolution of one
second.
Precision The smallest increase in time that a computer program
can use.

Configuring NTP 12-3

Table 12-1 NTP Terms (Continued)

Term Description
Jitter The difference of the differences experienced when
repeatedly measuring time.
Accuracy How close a clock follows an official time reference,
such as UTC.
Reliability The length of time that a clock can remain accurate
within a specified range.
Wander All clocks suffer from frequency variations. This
variation is called wander.
Drift file A file that contains the frequency offset of the local
system’s clock oscillator. Drift file contents can be used
by protocols, like NTP, to cause a system’s clock to be
more accurate. The default location for Sun’s NTP drift
file is /var/ntp/ntp.drift.
xntpd The NTP daemon.
The ntp.conf A file that causes the xntpd daemon to start in either
file the client or the server mode and provides
configuration statements that control the behavior of
the xntpd daemon.
The fudge You can use the fudge command in the ntp.conf file
command as a keyword to configure reference clocks in special
ways, such as defining calibration constants to force a
time offset to a particular external-time standard.
Discipline A general term used for various actions carried out by
some protocol, which helps keep a local clock better
synchronized to an official time source, such as UTC.

12-4 Network Administration for the Solaris™ 10 Operating System

Configuring an NTP Server

The /etc/inet/ntp.server file is a template for configuring an NTP
server. Copy this file to /etc/inet/ntp.conf, and edit it to meet your
network’s requirements. When viewing contents of the
/etc/inet/ntp.server file, remember that an NTP server is also an NTP
client.

The xntpd daemon is started at system boot if the /etc/inet/ntp.conf

file exists and the NTP service is enabled by the SMF. The xntpd daemon
starts in either the client or the server mode, depending on the contents of
the ntp.conf file.

The following steps describe the behavior of the xntpd daemon:

1. Broadcast NTP servers advertise every 64 seconds, by means of a
multicast address (224.0.1.1), that they are NTP servers. Any NTP
client that is not configured with the unicast address of an NTP
server multicasts to this same address when the xntpd daemon is
started. View the line that causes the system to act as an NTP server
by typing the following:
# grep broadcast /etc/inet/ntp.server
broadcast 224.0.1.1 ttl 4
#
2. Local NTP servers answer the multicast advertisements.
3. The NTP client sends time request packets to all of the NTP servers
by using the servers’ unicast addresses. Included in the time request
packet is the client’s local time.
4. The NTP server replies by inserting UTC time into the packet and
then returns the packet to the client.
5. The client compares its original request time with its own time when
it receives the response from the server. This enables the client to
determine how long the packet was in transit on the network.
6. The client uses the UTC time value from the NTP server after it
receives several responses from the NTP server. It can take up to five
minutes for an NTP client to synchronize with an NTP server.

Configuring NTP 12-5

Table 12-2 shows the parts of an NTP server’s configuration file and their
descriptions.

Table 12-2 NTP Configuration File Parts

Part Description

server 127.127.1.0 prefer The IP address of the preferred NTP server. In this
case, the loopback network is used, indicating the
use of a local clock. The server keyword indicates
an IP address of an NTP server from which time
will be received.
If the system is a stratum-1 server, then you use X
in the 127.127.X.0 syntax to identify a reference
clock source. If X is set to 1, the system uses its
local clock as the reference clock source.
If the server is a stratum-2 (or higher), this entry is
an IP address of another NTP server to contact for
time information. The prefer keyword means
that if multiple systems of the same strata are used
to getting clock information, a preferred server is
the one that is always used when performing
calculations.
fudge 127.127.1.0 stratum 0 The fudge entry is available to change (fudge) the
stratum that the server advertises.
broadcast 224.0.1.1 ttl 4 The address the server uses to advertise to the
network along with the TTL value to use in IP
datagrams.
enable auth monitor The configuration entry that enables
authentication and the monitoring facility.
driftfile /var/ntp/ntp.drift The location of the drift file.
statsdir /var/ntp/ntpstats/ The location of NTP statistics.
keys /etc/inet/ntp.keys The conventional name of the key file used for
authentication.
trustedkey 0 The encryption identifier. (Refer to RFC 1305 for
more information.)
controlkey 0 The key identifier. (Refer to RFC 1305 for more
information.)

Note – Different types of facilities, such as loopstats or clockstats, can

also be enabled (refer to the xntpd man page for more details).

12-6 Network Administration for the Solaris™ 10 Operating System

Using an Undisciplined Local Clock

NTP servers can, but should not, use their own undisciplined local clock
as an official, reliable time source.

To use an undisciplined local clock, complete the following steps:

1. Copy the /etc/inet/ntp.server file to the /etc/inet/ntp.conf
file.
# cp /etc/inet/ntp.server /etc/inet/ntp.conf
#
2. Open the /etc/inet/ntp.conf file for editing, and change the
server IP address to 127.127.1.0, where the number 1 represents
the undisciplined local clock. Comment out the fudge keyword
because special configuration is not needed for the local reference
clock.
# vi /etc/inet/ntp.conf
Change:
server 127.127.XType.0
fudge 127.127.XType.0 stratum 0
to:
server 127.127.1.0 prefer
# fudge 127.127.XType.0 stratum 0

Note – Choices for XType are listed in the comments of the

/etc/inet/ntp.server file.

3. Create a drift file as specified by the driftfile

/var/ntp/ntp.drift entry in the /etc/inet/ntp.conf file.
# touch /var/ntp/ntp.drift
#

Note – The xntpd daemon creates the contents of the drift file
dynamically.

4. Verify that the file exists.

# ls -al /var/ntp/ntp.drift
-rw-r--r-- 1 root root 0 Aug 16 11:06 /var/ntp/ntp.drift
#

Configuring NTP 12-7

5. Start the NTP daemon by using the svcadm command.

# svcadm -v enable svc:/network/ntp
network/ntp enabled.
#
6. Verify that the NTP daemon is running.
# pgrep -lf ntp
1585 /usr/lib/inet/xntpd
#
7. Use the snoop utility to view NTP server multicast advertisements.
# snoop | grep -i ntp
Using device /dev/hme (promiscuous mode)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:11:52.98017)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:12:56.98017)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:14:00.98016)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:15:04.98016)
...
...

Note – Notice the 64-second interval between NTP advertisements sent

out. This is due to the NTP polling value of 6; 26 is 64. The polling value
can be seen by using the snoop -v command.

Configure the Stratum

You can configure the stratum of an NTP server manually by editing the
fudge entry in the /etc/inet/ntp.conf file. This is useful when you do
not have access to an external NTP server and you have to synchronize
with another system manually.

When a local clock is configured to act as an accurate source of time, NTP

detects this. Systems that use their own clock as a time source advertise
themselves as a stratum-4 server by default. However, the fudge keyword
can be used to alter this behavior. The fudge configuration entry can use
the stratum option to override the stratum level sent out with the NTP
server’s time advertisements.

Note – The snoop utility output includes the stratum level of the server.
NTP servers and clients that are in the process of synchronization have a
stratum level of 0 (zero) initially, until they establish their correct stratum
level.

12-8 Network Administration for the Solaris™ 10 Operating System

Using External NTP Reference Servers

Determine which NTP servers are reachable by your NTP server. Refer to
http://www.eecis.udel.edu/~mills/ntp/servers.html for links to
lists of public NTP servers. You must notify the NTP server’s
administrators of your intention to use their NTP server as a reference
server so that the administrator can properly size NTP servers for the
additional NTP load.

To use external NTP reference servers, complete the following steps:

1. Copy the /etc/inet/ntp.server file to the /etc/inet/ntp.conf
file.
# cp /etc/inet/ntp.server /etc/inet/ntp.conf
#
2. Open the /etc/inet/ntp.conf file for editing, and change the
server entry. Comment out the fudge keyword because special
configuration is not needed for an external reference clock.
# vi /etc/inet/ntp.conf
Change:
server 127.127.XType.0
fudge 127.127.XType.0 stratum 0
to:
server external-time-server-a
server external-time-server-b
server external-time-server-c
# fudge 127.127.XType.0 stratum 0
3. Create a drift file as specified by the driftfile
/var/ntp/ntp.drift entry in the /etc/inet/ntp.conf file.
# touch /var/ntp/ntp.drift
#
4. Verify that the file exists.
# ls -al /var/ntp/ntp.drift
-rw-r--r-- 1 root root 0 Aug 16 14:41 /var/ntp/ntp.drift
#

Configuring NTP 12-9

5. Start the NTP daemon by using the svcadm command.

# svcadm -v svc:/enable network/ntp
network/ntp enabled.
6. Check to see if the NTP daemon is running.
# pgrep -lf ntp
1595 /usr/lib/inet/xntpd
#

Note – NTP servers and client that are synchronizing with specific servers
defined in the /etc/inet/ntp.conf file use a 64-second polling
interval initially. When time synchronization is established, the polling
interval increases to 17 minutes and 4 seconds (that is, 1024 seconds, or 210
seconds).

Managing Daemons
By default, all NTP messages are sent to the syslog facility.

To view the logged information in pseudo real-time, use the tail

command with the follow (-f) option. For example:
# tail -f /var/adm/messages
Aug 16 14:25:37 sys11 xntpd[1614]: [ID 450285 daemon.error] 0 makes a
poor control keyid
...

You can query or configure a running xntpd daemon by using the xntpdc
utility, which was introduced in the Solaris 8 OS. The xntpdc command
provides an extensive view of the state of the xntpd daemon. You can
view statistical information interactively or on the command-line. Use the
? command to view a list of commands available inside xntpdc.
# xntpdc
xntpdc> ?
Commands available:
addpeer addrefclock addserver addtrap authinfo
broadcast clkbug clockstat clrtrap controlkey
ctlstats debug delay delrestrict disable
dmpeers enable exit fudge help
host hostnames iostats kerninfo keyid
keytype leapinfo listpeers loopinfo memstats
monlist passwd peers preset pstats

12-10 Network Administration for the Solaris™ 10 Operating System

quit readkeys requestkey reset reslist

restrict showpeer sysinfo sysstats timeout
timerstats traps trustedkey unconfig unrestrict
untrustedkey version
xntpdc>

The commands can be used to display and configure the NTP setup. For
example, the sysinfo command displays information about the current
configuration:
xntpdc> sysinfo
system peer: instructor
system peer mode: client
leap indicator: 00
stratum: 2
precision: -14
root distance: 0.00081 s
root dispersion: 0.31441 s
reference ID: [192.168.30.30]
reference time: c4cc99b1.2ce5f000 Tue, Aug 17 2004 15:50:25.175
system flags: auth monitor pll stats kernel_sync
frequency: -16.000 ppm
stability: 38.345 ppm
broadcastdelay: 0.003906 s
authdelay: 0.000122 s
xntpdc> quit
#

The NTP service is started automatically at boot time if the

/etc/inet/ntp.conf file exists and the NTP service was enabled by
SMF. You can stop the service manually by using the svcadm command.

To stop the daemon, perform the command:

# svcadm -v disable svc:/network/ntp
network/ntp disabled.
#

To start the daemon, perform the command:

# svcadm -v enable svc:/network/ntp
network/ntp enabled.
#

Configuring NTP 12-11

Determining NTP Peers

The ntpq utility is the standard NTP query program. Use the ntpq utility
to identify NTP peers on the network. For example:
# ntpq
ntpq> peers
remote refid st t when poll reach delay offset disp
==============================================================================
*instructor .LCL. 1 u 29 64 377 0.69 0.000 0.06
224.0.1.1 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
ntpq> exit
#

12-12 Network Administration for the Solaris™ 10 Operating System

Configuring an NTP Client

Configuration of an NTP client also requires the /etc/inet/ntp.conf
file to be created, as it does with NTP servers.

Establishing Basic Configuration

To initialize the file configuration, complete the following step:
Copy the /etc/inet/ntp.client file to the /etc/inet/ntp.conf
file.
# cp /etc/inet/ntp.client /etc/inet/ntp.conf
#
The /etc/inet/ntp.client file contains only one entry, which
configures the client to use the default multicast address to solicit for
servers.
# tail -1 /etc/inet/ntp.client
multicastclient 224.0.1.1

Starting the NTP Client Daemon

To start the NTP client daemon, perform the following:
1. Check to determine if the NTP daemon is running.
# pgrep -lf ntp
#
2. Start the NTP daemon by using the svcadm command.
# svcadm -v enable svc:/network/ntp
network/ntp enabled.
#
The SMF NTP method, /lib/svc/method/xntp, uses the ntpdate
command to synchronize the client’s clock to UTC. After the
ntpdate command is executed, the xntpd daemon is started by the
SMF method to maintain synchronization.
# pgrep -lf ntp
1680 /usr/sbin/ntpdate -s -m 224.0.1.1
1679 /sbin/sh /etc/init.d/xntpd start
1676 /sbin/sh /etc/init.d/xntpd start
#

Configuring NTP 12-13

Note – The ntpdate command runs automatically to gather NTP inputs

and to set the initial time on this system. The ntpdate command might
perform this initial setting by means of a step or a slew. Refer to the
ntpdate(1M) man page for further details.

Stopping the NTP Client Daemon

Stop the NTP client daemon by using the svcadm command.
# svcadm -v disable network/ntp
network/ntp disabled.
#

The xntpd daemon is no longer running.

# pgrep -lf ntp
#

12-14 Network Administration for the Solaris™ 10 Operating System

Troubleshooting NTP
Use a combination of tools, such as viewing system error logs and using
the snoop utility, to troubleshoot NTP.

Viewing Messages
Log messages result from setting the time forward on the system. The
system sends out its periodic (every 64 seconds) NTP requests with the
incorrect time. The NTP servers respond with the correct time. After
receiving multiple updates from the NTP servers, the client changes its
time and writes a message to the /var/adm/messages file.
# tail -50 /var/adm/messages | grep -i ntp
Aug 17 15:21:46 sys11 ntpdate[1680]: [ID 318594 daemon.notice] no server
suitable for synchronisation found yet
Aug 17 15:21:46 sys11 ntpdate[1680]: [ID 147394 daemon.notice] trying ttl
1 for multicast server synchronisation
Aug 17 15:21:46 sys11 ntpdate[1680]: [ID 558725 daemon.notice] adjust tim
e server 192.168.30.30 offset 0.004158 sec
Aug 17 15:22:48 sys11 xntpd[1676]: [ID 702911 daemon.notice] xntpd 3-5.93
e+sun 03/08/29 16:23:05 (1.4)
Aug 17 15:22:48 sys11 xntpd[1676]: [ID 301315 daemon.notice] tickadj = 5,
tick = 10000, tvu_maxslew = 495, est. hz = 100
Aug 17 15:22:48 sys11 xntpd[1676]: [ID 266339 daemon.notice] using kernel
phase-lock loop 0041, drift correction 0.00000
#

Configuring NTP 12-15

Using the snoop Utility

To view NTP server multicast advertisements, use the snoop utility.
# snoop port ntp
Using device /dev/hme (promiscuous mode)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:11:52.98017)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:12:56.98017)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:14:00.98016)
sys11 -> 224.0.1.1 NTP broadcast [st=1] (2004-08-16 11:15:04.98016)
<Control>-C#

Clients synchronize with servers using unicast packets, as follows:

1. The NTP client sends a message to an NTP server with its idea of the
local time.
sys12 -> sys11 NTP client [st=0] (2004-08-17 15:24:17.32955)
Note that the client is at stratum 0 initially. It sets the correct stratum
level after synchronization is established.
2. The NTP server responds with the correct time.
sys11 -> sys12 NTP server [st=1] (2004-08-17 15:24:17.32834)
3. This exchange between the NTP server and the NTP client repeats
many times. Eventually, the NTP client acknowledges that its time is
incorrect. The client then takes action to change its own time, based
on NTP time advertisements received from one or more NTP servers.
Information about the actions taken by the NTP client is sent to the
syslog facility for proper processing.
sys12 -> sys11 NTP client [st=0] (2004-08-17 15:25:21.32958)
4. The NTP server responds again with the correct time.
sys11 -> sys12 NTP server [st=1] (2004-08-17 15:25:21.32839)

12-16 Network Administration for the Solaris™ 10 Operating System

Exercise: Configuring NTP

In this exercise, you configure NTP.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed. The
instructor’s system must be configured as a stratum-0 server even though
the system might be using its local clock. This configuration must be
completed at least five minutes before this exercise starts so that the NTP
server has an opportunity to initialize itself properly.

Task Summary
In this exercise, you configure an NTP server and an NTP client on your
subnet. Your NTP server uses the instructor system as an external NTP
server. After the NTP server is configured, it broadcasts NTP updates to
your local subnet.

Team up with other students in your subnet group so that you can
experience most aspects of NTP configuration.

Configuring NTP 12-17

Tasks
Your first task is to configure your subnet’s router as an NTP server.

Working on Your Subnet Group’s Router

To configure your subnet’s router as an NTP server, perform the

following:
1. Verify that your router is receiving NTP updates from the instructor
system. (Either use the -c 1 option to the snoop command so that
only one NTP broadcast packet is captured or remember to terminate
the snoop session when you are finished with this step. Be sure not
to let snoop run continually).
Write the commands that you use:
_____________________________________________________________
2. Copy and rename the NTP configuration template in preparation for
specifying configurations in that file the next time the NTP service is
enabled.
Write the command that you use:
_____________________________________________________________
3. Edit the NTP configuration file, and modify the server entry so that
your system looks to the instructor system for NTP updates. Ensure
that the instructor system is your preferred server. While you edit
the file, comment out the fudge and keys entries and modify the
broadcast entry.
4. Create a drift file as specified by the drift file entry in the
configuration file.
Write the command that you use:
_____________________________________________________________
5. Start the snoop utility on your router system’s to observe NTP traffic
between the router and the instructor system.
Write the command that you use:
_____________________________________________________________
6. In another window, determine if the NTP daemon is running on
your system.
Write the command that you use, and write the output of the
command:
_____________________________________________________________

12-18 Network Administration for the Solaris™ 10 Operating System

7. Start the NTP daemon, and view the NTP transactions that can be
seen on the snoop trace that is running. Watch the transactions for a
few minutes to see your system’s time becoming synchronized with
the instructor’s stratum-0 NTP server. When you are finished,
terminate the snoop session.
Write the command that you use:
_____________________________________________________________

Your second task is to configure an NTP client on any of the remaining

systems on your subnet.

Working on a Non-Router System

To configure an NTP client on remaining systems on your subnet,

continue as follows:
8. Use the snoop utility to verify that your system is receiving the NTP
broadcasts from your subnet’s NTP server. When you are finished,
terminate the snoop session.
Write the command that you use:
_____________________________________________________________
9. Copy and rename the NTP client configuration template to specify
the configuation of the NTP service when it is enabled.
Write the command that you use:
_____________________________________________________________
10. Determine if the NTP daemon is running.
Write the command that you use, and write your answer:
_____________________________________________________________
_____________________________________________________________
11. Start a snoop session on the appropriate interface on the client. In the
window running the snoop trace on the NTP client. After you start
the NTP service in the next step, be prepared to examine the trace
carefully.
Write the commands that you use:
_________________________________________________

Configuring NTP 12-19

12. Start the NTP daemon and verify that it is running.

Write the commands that you use:
_____________________________________________________________
13. Examine the snoop trace and locate the part of the snoop trace where
the client time changed to match the server’s time. (Hint: Use X-Off
(Control+S key sequence) to stop the snoop trace from scrolling and
use X-On (Control+Q key sequence) to enable scrolling again.

12-20 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Configuring NTP 12-21

Exercise Solutions
Solutions to this exercise are provided in the following section.

Task Solutions
Your first task is to configure your subnet’s router as an NTP server.

Working on Your Subnet Group’s Router

To configure your subnet’s router as an NTP server, perform the

following:
1. Verify that your router is receiving NTP updates from the instructor
system. (Either use the -c 1 option to the snoop command so that
only one NTP broadcast packet is captured or remember to terminate
the snoop session when you are finished with this step. Be sure not
to let snoop run continually).
Write the commands that you use:
First, determine which interface is on the instructor system’s
192.168.30.0 network.
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b9:72:23
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:ac:9b:20
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
ether 8:0:20:b9:72:23
inet6 fe80::a00:20ff:feb9:7223/10
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 2000::1:a00:20ff:feb9:7223/64
hme0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 fec0::1:a00:20ff:feb9:7223/64
qfe0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
ether 8:0:20:ac:9b:20
inet6 fe80::a00:20ff:feac:9b20/10
qfe0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 2000::30:a00:20ff:feac:9b20/64
qfe0:2: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 fec0::30:a00:20ff:feac:9b20/64

12-22 Network Administration for the Solaris™ 10 Operating System

Use a combination of the snoop and grep utilities to look for NTP updates
on the interface (qfe0) closest to the instructor system as follows:
# snoop -d qfe0 -c 1 port ntp
Using device /dev/qfe (promiscuous mode)
instructor.thirty.edu -> 192.168.30.255 NTP broadcast [st=1]
(2004-11-05 09:41:20.83034)
1 packets captured
#
You can continue to configure your system as an NTP server because it is
receiving NTP updates from the instructor system that is acting as a
stratum-0 server.
2. Copy and rename the NTP configuration template in preparation for
specifying configurations in that file for the next time the NTP
service is enable.
Write the command that you use:
Copy the /etc/inet/ntp.server file to the /etc/inet/ntp.conf file.
# cp /etc/inet/ntp.server /etc/inet/ntp.conf
3. Edit the NTP configuration file, and modify the server entry so that
your system looks to the instructor system for NTP updates. Ensure
that the instructor system is your preferred server. While you edit
the file, comment out the fudge and keys entries and modify the
broadcast entry.
Edit the /etc/inet/ntp.conf file.
# vi /etc/inet/ntp.conf
Change the server and fudge entries to be similar to the following:
server 192.168.30.30 prefer
# fudge 127.127.XType.0 stratum 0
Change the keys entries to be similar to the following:
#keys /etc/inet/ntp.keys
#trustedkey 0
#requestkey 0
#controlkey 0
Change the broadcast entry to be similar to the following:
broadcast 192.168.1.255 ttl 4
4. Create a drift file as specified by the drift file entry in the
configuration file.
Write the command that you use:
# touch /var/ntp/ntp.drift

Configuring NTP 12-23

5. Start the snoop utility on your router system’s to observe NTP traffic
between the router and the instructor system.
Write the command that you use:
Start the snoop utility on the 192.168.30.0 network.
# snoop -d qfe0 port ntp
Using device /dev/qfe (promiscuous mode)
instructor -> 192.168.30.255 NTP broadcast [st=1] (2004-11-05 10:04:48.83026)
...
6. In another window, determine if the NTP daemon is running on
your system.
Write the command that you use, and write the output of the
command:
# pgrep -lf ntp
1142 snoop -d qfe0 port ntp
No, the NTP daemon is not running, as expected.
7. Start the NTP daemon, and view the NTP transactions that can be
seen on the snoop trace that is running. Watch the transactions for a
few minutes to see your system’s time becoming synchronized with
the instructor’s stratum-0 NTP server.
Write the command that you use:
# svcadm enable svc:/network/ntp:default
svc:/network/ntp:default enabled
#
# snoop -d qfe2 port ntp
Using device /dev/qfe (promiscuous mode)
sys11ext -> instructor NTP client [st=0] (2004-11-05 10:05:14.45062)
instructor -> sys11ext NTP server [st=1] (2004-11-05 10:09:39.79242)
...

Your second task is to configure an NTP client on any of the remaining

systems on your subnet.

12-24 Network Administration for the Solaris™ 10 Operating System

Working on a Non-Router System

To configure an NTP client on remaining systems on your subnet,

continue as follows:
8. Use the snoop utility to verify that your system is receiving the NTP
broadcasts from your subnet’s NTP server. When you are finished,
terminate the snoop session.
Write the command that you use:
# snoop -d hme0 port ntp
Using device /dev/hme (promiscuous mode)
sys11.one.edu -> 192.168.1.255 NTP broadcast [st=2] (2004-11-05 10:18:16.08248)

You can continue with configuring your system as an NTP client because it
is receiving NTP updates from your router system, which acts as a
stratum-2 server.
9. Copy and rename the NTP client configuration template to specify
the configuation of the NTP service when it is enabled.
Write the command that you use:
# cp /etc/inet/ntp.client /etc/inet/ntp.conf
10. Determine if the NTP daemon is running.
Write the command that you use, and write your answer:
# pgrep -lf ntp
No, the NTP daemon is not running, as expected.
11. Start a snoop session on the appropriate interface on the client. In the
window running the snoop trace on the NTP client. After you start
the NTP service in the next step, be prepared to examine the trace
carefully.
# snoop -d hme0 port ntp
...
12. Start the NTP daemon and verify that it is running.
Write the commands that you use:
# svcadm -v enable svc:/network/ntp
svc:/network/ntp:default enabled.
#
# pgrep -lf ntp
1528 /usr/lib/inet/xntpd

Configuring NTP 12-25

13. Examine the snoop trace and locate the part of the snoop trace where
the client time changed to match the server’s time. (Hint: Use X-Off
(Control+S key sequence) to stop the snoop trace from scrolling and
use X-On (Control+Q key sequence) to enable scrolling again.
...
sys12.one.edu -> 224.0.1.1 NTP client [st=0] (2005-02-02 15:58:11.61034)
sys12.one.edu -> 224.0.1.1 NTP client [st=0] (2005-02-02 15:58:12.61016)
sys12.one.edu -> 224.0.1.1 NTP client [st=0] (2005-02-02 15:58:13.61026)
sys12.one.edu -> 224.0.1.1 NTP client [st=0] (2005-02-02 15:58:14.61010)
sys11.one.edu -> 192.168.1.255 NTP broadcast [st=2] (2005-02-02 15:57:47.06304)
sys12.one.edu -> sys11.one.edu NTP client [st=0] (2005-02-02 15:58:38.02497)

{observe that server’s time is 15:57 while client’s time is 15:58}

sys11.one.edu -> sys12.one.edu NTP server [st=2] (2005-02-02 15:57:47.06425)

sys12.one.edu -> sys11.one.edu NTP client [st=0] (2005-02-02 15:58:38.02556)
sys11.one.edu -> sys12.one.edu NTP server [st=2] (2005-02-02 15:57:47.06474)
sys12.one.edu -> sys11.one.edu NTP client [st=0] (2005-02-02 15:58:38.02602)
sys11.one.edu -> sys12.one.edu NTP server [st=2] (2005-02-02 15:57:47.06518)
sys12.one.edu -> sys11.one.edu NTP client [st=0] (2005-02-02 15:58:38.02645)
sys11.one.edu -> sys12.one.edu NTP server [st=2] (2005-02-02 15:57:47.06560)
sys11.one.edu -> 192.168.1.255 NTP broadcast [st=2] (2005-02-02 15:58:51.06343)
sys12.one.edu -> sys11.one.edu NTP client [st=0] (2005-02-02 15:59:22.72971)

{observe that the client has updated its time to that of the server}

sys11.one.edu -> sys12.one.edu NTP server [st=2] (2005-02-02 15:59:22.72968)

sys11.one.edu -> 192.168.1.255 NTP broadcast [st=2] (2005-02-02 15:59:55.06379)
sys12.one.edu -> sys11.one.edu NTP client [st=0] (2005-02-02 16:00:26.72968)
sys11.one.edu -> sys12.one.edu NTP server [st=2] (2005-02-02 16:00:26.72945)
sys11.one.edu -> 192.168.1.255 NTP broadcast [st=2] (2005-02-02 16:00:59.064

12-26 Network Administration for the Solaris™ 10 Operating System

Configuring the Solaris™ IP Filter Firewall

Objectives
This module introduces how to configure the Solaris IP Filter host-based
firewall. This module also introduces the basics of the Solaris IP Filter
firewall, including how the firewall decides whether or not to pass a
packet and how rules for the firewall can be defined based on various
criteria.

Upon completion of this module, you should be able to:

● Identify Solaris IP Filter firewall basics
● Configure the Solaris IP Filter firewall behavior

The course map in Figure 13-1 shows how this module fits into the
current instructional goal.

Configuring and Managing Network Applications

Configuring the
Configuring Configuring Configuring Solaris™ IP
DNS DHCP NTP Filter Firewall

Figure 13-1 Course Map

Identifying Firewall Basics

IP routers are used to connect networks together and to pass traffic
between the networks. An IP router will, by default, forward all traffic
that arrives at one of its interfaces to another network. An IP router can be
considered to be an open door between networks, permitting free access.

In a controlled or constrained environment, free access between networks

where all the systems are known is not necessarily a problem. When
connecting a network to external networks, unrestricted access is typically
not desirable.

An unprotected network connected to the Internet by an IP router exposes

all of the systems on the network to the whole Internet. Anyone on the
Internet can attempt to access any of the systems in any manner. To avoid
this situation, the network can be connected by using some form of device
that is more restrictive in the access it permits. Access restrictions can be
applied to systems outside the network looking to access systems inside
the network, and to control the access that systems inside the network
have to the rest of the Internet. This is the purpose of a firewall.

A firewall is a device which runs some software designed to control traffic

between networks, similar to an IP router. Unlike an IP router, a firewall is
selective about the traffic that it forwards, and can decide not to permit
certain traffic to be forwarded. The decision to forward or not to forward
traffic is controlled by a set of rules defined on the firewall.

The rules in the firewall can be based on characteristics of traffic such

source and destination IP addresses for both individual hosts and
networks, on port numbers and payload types.

Solaris IP Filter firewall is a utility that enables a Solaris 10 OS system to

act as a firewall. The behavior of the Solaris IP Filter firewall is controlled
by a configuration file, the /etc/ipf/ipf.conf file. The Solaris IP Filter
firewall is an integral part of the Solaris 10 OS and can be configured on
Solaris 10 OS systems acting as routers and on individual hosts.

13-2 Network Administration for the Solaris™ 10 Operating System

Configuring the Behavior of the Solaris IP Filter Firewall

When defining packet filtering rules in the /etc/ipf/ipf.conf file, it
is necessary to understand how the Solaris IP Filter firewall reads this file
and compares any packet against the rules in the file. Each rule in the file
contains:
● An action
● A direction
● Criteria which are compared against the packet to determine
whether the packet matches the rule

The default behavior of the Solaris IP Filter firewall is to read every rule in
the /etc/ipf/ipf.conf file. Each rule in the file tells the Solaris IP
Filter firewall to either permit or deny the packet to be sent or received.
When processing a packet, the Solaris IP Filter firewall performs the
following tasks:
1. Compare the packet against the direction and criteria in the rule.
2. If the packet matches, remember the action specified in the rule.
3. Discard any action remembered previously.
4. If the end of the rules is reached or the matched rule contains the
quick keyword, stop matching and perform the action.
5. If no rules match, pass the packet.

Enabling Packet Filtering With the Solaris IP Filter

Firewall
For the Solaris IP Filter firewall to function, the pfil kernel module must
be loaded on each network interface on the system on which packet
filtering is to be applied. The pfil kernel module is loaded on an
individual network interface when the interface is plumbed if packet
filtering has been enabled for that type of interface (hme, qfe, and so on).

The default configuration in the Solaris 10 OS is that packet filtering is not

enabled for any network interface. Packet filtering is enabled on a
particular network interface type by uncommenting the line relating to
the network interface type in the /etc/ipf/pfil.ap file.

Configuring the Solaris™ IP Filter Firewall 13-3

The /etc/ipf/pfil.ap file contains a list of network interfaces. Remove

the leading comment character from the appropriate lines for the interface
for which filtering is to be configured.
# cat /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major minor lastminor modules

#le -1 0 pfil
#qe -1 0 pfil
#hme -1 0 pfil
#qfe -1 0 pfil
#eri -1 0 pfil
#ce -1 0 pfil
#bge -1 0 pfil
#be -1 0 pfil
#vge -1 0 pfil
#ge -1 0 pfil
#nf -1 0 pfil
#fa -1 0 pfil
#ci -1 0 pfil
#el -1 0 pfil
#ipdptp -1 0 pfil
#lane -1 0 pfil
#dmfe -1 0 pfil
#

Any existing, plumbed network interfaces to which you choose to apply

filtering must be unplumbed and plumbed. For example, you can use the
autopush command to read changes to the /etc/ipf/pfil.ap file before
you unplumb and plumb the interfaces.
# autopush -f /etc/ipf/pfil.ap

Solaris IP Filter Services

The svc:/network/pfil and the svc:/network/ipfilter SMF services

control the pfild daemon process. Like other SMF services, use the svcs
and svcadm commands to manage these filtering services.

13-4 Network Administration for the Solaris™ 10 Operating System

Configuring the Solaris IP Filter Firewall Actions

Every rule in the /etc/ipf/ipf.conf file starts with an action. The
action states whether the Solaris IP Filter firewall will permit or deny the
packet if the rule is matched. There are two action keywords: block and
pass.

Figure 13-2 shows how filtering works when based upon traffic direction.

Traffic
Flow

hme0 hme1

Block/pass in Block/pass out

on hme0 on hme1

Internet

Corporate
Traffic Network
Flow

hme0 hme1

Block/pass out Block/pass in

on hme0 on hme1

Figure 13-2 Filtering Based Upon Traffic Direction

Using the block keyword

The block keyword is an action keyword which tells the Solaris IP Filter
firewall that the packet should be blocked (dropped) if the packet matches
the rule.

All rules to block packets use this keyword:

block ...

Configuring the Solaris™ IP Filter Firewall 13-5

Using the pass keyword

The pass keyword is the action keyword that tells the Solaris IP Filter
firewall that the packet should be accepted or sent if the packet matches
the rule.

All rules to permit packets to pass use this keyword:

pass ...

Configuring Packet Direction

The second keyword in all packet filtering rules is a direction keyword.
The direction keyword relates to the movement of the packet in relation to
the system on which the Solaris IP Filter firewall is running. There are two
direction keywords in the Solaris IP Filter firewall: in and out.

Using the in Keyword

The in keyword is used for rules that relate to packets arriving at the
system from the network. Any rule that contains the in keyword is
applied only to packets arriving at the system from the network.

All rules that are intended to block packets arriving at a system start with
the following:
block in ...

All rules that are intended to pass packets arriving at a system start with
the following:
pass in ...

13-6 Network Administration for the Solaris™ 10 Operating System

Using the out Keyword

The out keyword is used for rules that relate to packets leaving the
system to go out on to the network. Any rule containing the out keyword
is applied only to packets leaving the system.

All rules that are intended to block packets leaving a system start with the
following:
block out ...

All rules that are intended to pass packets leaving a system start with the
following:
pass out ...

Configuring Filter Rules

This section describes how to configure filter rules. The
/usr/share/ipfilter/examples directory contains IPFilter examples to
help you define rules.
# ls /usr/share/ipfilter/examples
BASIC.NAT example.1 example.12 example.3 example.6 example.9
ftp-proxy mkfilters pool.conf
BASIC_1.FW example.10 example.13 example.4 example.7 example.sr
ftppxy nat-setup server
BASIC_2.FW example.11 example.2 example.5 example.8 firewall
ip_rules nat.eg tcpstate

Using the quick keyword

Recall that the default behavior of the Solaris IP Filter firewall is to find
every rule that matches and remember the action from the last rule
matched. The quick keyword is used to change this behavior.

If a packet matches a rule containing the quick keyword, then the Solaris
IP Filter firewall stops matching at that rule and applies the action
contained in the rule. The remaining rules are not processed against the
packet for matches.

The quick keyword, if present, is found between the direction keyword

and the matching keywords in the rule.

Configuring the Solaris™ IP Filter Firewall 13-7

To define a rule that will block any incoming packet matching the rule
and will stop the Solaris IP Filter firewall from processing any further
rules, start the rule with:
block in quick ...

To define a rule that will permit any outgoing packet matching the rule
and will stop the Solaris IP Filter firewall from processing any further
rules, start the rule with:
pass out quick ...

Matching All Packets

The all keyword is used to match every packet either arriving or leaving
at a system.

For example, to block every packet arriving at a system, use the rule:
block in all

To block every packet arriving at a system and stop processing rules at

this point, use the rule:
block in quick all

To permit all packets arriving at a system to be passed, use the rule:

pass in all

To permit all packets arriving at a system to be passed and to stop

processing rules at this point use the rule:
pass in quick all

Configuring Specific Matching

This section describes how to configure specific matching for filters.

Configuring Filtering on a Specific Network Interface

The Solaris IP Filter firewall applies each rule to every network interface
on the system by default. Use of the on keyword enables you to apply a
rule to a particular network interface only.

13-8 Network Administration for the Solaris™ 10 Operating System

Note – The Solaris IP Filter firewall does not filter the loopback interface.
You should not use the interface identifier lo0 in the
/etc/ipf/ipf.conf file. Note that the lo identifier does not appear in
the /etc/ipf/pfil.ap file.

To apply a rule to a specific interface, use the on keyword followed by the

name of the interface. For example, to permit all packets arriving and
leaving the hme0 interface and to stop further processing rules at this
point, use the rules:
pass in quick on hme0 all
pass out quick on hme0 all

Configuring Filtering on IP Address

The Solaris IP Filter firewall can filter packets based on their source and
destination IP addresses. To filter packets based on the source IP address,
the from keyword is used. To filter packets based on the destination IP
address, the to keyword is used.

The from and to keywords take IP addresses as arguments. IP addresses

are suffixed by a netmask value specified by using prefix notation. To
specify an IP address for a single host, use the suffix /32 or
/255.255.255.255. To specify a Class C network, use the suffix /24 or
/255.255.255.0. To specify a Class B network, use the suffix /16 or
/255.255.0.0. To match any IP address, use the keyword any.

For example, the rule:

pass in from 192.168.1.0/24 to any

will permit any packets originating from the Class C network

192.168.1.0 and intended for any destination to enter the system from
the network on any network interface.

The rule:
block out from any to 192.168.30.30/32

will block any packets leaving the current system which have the host
192.168.30.30 as their destination.

Configuring the Solaris™ IP Filter Firewall 13-9

Network interfaces and IP addresses can be combined in rules. For

example, the rule:
block in on qfe0 from any to 192.168.1.0/24

will block any packets arriving at the qfe0 network interface from any
source IP address which are intended for the 192.168.1.0 network.

IP addresses can be used as both source and destination addresses. For

example, the rule
block out on qfe0 from 192.168.1.2/32 to 192.168.3.0/24

will block any packet leaving the qfe0 interface which originated from
the host 192.168.1.2 and is intended for the 192.168.3.0 network.

13-10 Network Administration for the Solaris™ 10 Operating System

Configuring Filtering on Protocol Type and Port Number

The Solaris IP Filter firewall is also capable of filtering traffic based on the
network protocol contained in a packet. The protocols which can be
filtered are TCP, UDP and ICMP.

The proto keyword is used to filter on protocol type. The proto keyword
is followed by a second keyword that identifies the protocol or protocols
to be filtered. Table 13-1 shows the keywords and the protocols to which
they relate.

Table 13-1 Protocol Keywords

Keyword Protocols Filtered

icmp ICMP
tcp TCP
udp UDP
tcp/udp Both TCP and UDP

For example, to block all ICMP packets arriving on the hme0 interface, use
the rule:
block in on hme0 proto icmp from any to any

In this form, this rule blocks all ICMP packets. The icmp-type keyword
can be used to specify a single ICMP type value for the rule. All ICMP
packets contain a type value in the ICMP header. Some common ICMP
types are shown in Table 13-2.

Table 13-2 ICMP Type Values and Keywords

ICMP Type Value Keyword

Echo reply 0 echorep

Echo request 8 echo
Router advertisement 9 routerad
Router solicitation 10 routersol

Configuring the Solaris™ IP Filter Firewall 13-11

Note – A complete list of ICMP type values can be found in the

/usr/include/netinet/ip_icmp.h file.

The icmp-type keyword is appended to the end of a rule to make the

rule apply to a specific type of ICMP packet. The type value can be
specified numerically or textually. For example, to permit a system to
receive ICMP router discovery solicitations on the hme0 interface
connected to the 192.168.1.0 network and to send router
advertisements on the same interface, but to block all other ICMP traffic
on the hme0 interface, use the rules:
pass in quick on hme0 proto icmp from 192.168.1.0/24 to any icmp-type 10
pass out quick on hme0 proto icmp from any to 192.168.1.0/24 icmp-type 9
block in quick on hme0 proto icmp from any to any
block out quick on hme0 proto icmp from any to any

To block outgoing ICMP echo replies (responses to the ping command) on

the qfe0 interface, use the rule:
block out quick on qfe0 proto icmp from any to any icmp-type echorep

Filtering of TCP and UDP packets can be restricted to a particular port by

using the port = keywords. The port to which the rule is to apply is
specified after the equal sign (=). For example, to block the default telnet
server port (23) the keywords port = 23 are appended to the rule.

Port-based filtering can be applied to the source address or the destination

address. Note that the spaces on either sides of the equals sign are
required.

Note – When configuring filtering based upon port number, it is

important to understand the manner in which the applications you are
filtering uses ports. Some applications, for example, routing protocols, use
the same port on the server and the client. Other applications, for
example, FTP and telnet, use a well-known port on the server side and
an anonymous port for the client.

When writing rules for protocols like Telnet and FTP, the keep state
keywords are a convenient way to avoid having to know the per-session,
anonymous-client port assignments. See the ipf.conf(4) man page for
details.

13-12 Network Administration for the Solaris™ 10 Operating System

To block all incoming packets intended for the telnet server port (port
23), use the rule:
block in quick proto tcp from any to any port = 23

To block all incoming telnet packets except those originating from the
192.168.1.0 network, use the rules:
pass in quick proto tcp from 192.168.1.0/24 to any port = 23
block in quick proto tcp from any to any port = 23

To permit incoming RPC requests to the rpcbind daemon from the

192.168.1.0 network on the hme0 interface only, use the rules:
pass in quick on hme0 proto tcp/udp from 192.168.1.0 to any port = 111
block in quick on hme0 proto tcp/udp from any to any port = 111

To permit packets to leave the telnet server port if they are intended for
the local subnet, use the rule:
pass out quick proto tcp from 192.168.1.1/32 port = 23 to 192.168.1.0/24

Configuring the Solaris™ IP Filter Firewall 13-13

Changing and Updating the Solaris IP Filter Firewall

Configuration
The ipf command is used to update the set of filtering rules in place on a
system.

The -f option is used to add filtering rules. The -f option takes the name
of a file containing the new rules as an argument. The rules found in the
file are appended to any existing rules:
# ipf -f /etc/ipf/ipf.conf
#

The ipf command can also be used to remove rules from the current
configuration. The -F (flush) option is used to clear rules. The -F option is
combined with one of three choices of the rules to clear:

-Fa Flush all rules (both input and output)

-Fi Flush input rules only
-Fo Flush output rules only

For example, to clear all of the input rules, type the command:
# ipf -Fi
#

If you have made changes to the rule set in the /etc/ipf/ipf.conf

file, you can load the new rules by combining a flush operation and an
add operation in one command:
# ipf -Fa -f /etc/ipf/ipf.conf
#

Note – Options to the ipf command are executed in the order in which
they are specified on the command line. If a flush option is specified after
an add rules option, the new rules will be added, then flushed along with
the old rules. To clear the existing rules and load a new or updated set, the
flush option must be specified first.

13-14 Network Administration for the Solaris™ 10 Operating System

Viewing the Solaris IP Filter Firewall Configuration

The ipfstat command is used to display information about the
behavior and configuration of the Solaris IP Filter firewall.

Running the ipfstat command with no arguments displays statistics

about the Solaris IP Filter firewall:
# ipfstat
bad packets: in 0 out 0
input packets: blocked 37 passed 71 nomatch 71 counted 0 short 0
output packets: blocked 0 passed 77 nomatch 50 counted 0 short 0
input packets logged: blocked 0 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 0 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 0 lost 0
packet state(out): kept 0 lost 0
ICMP replies: 0 TCP RSTs sent: 0
Invalid source(in): 0
Result cache hits(in): 13 (out): 27
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 10 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
IPF Ticks: 1426
Packet log flags set: (0)
none
#

The ipfstat command can also be used to display the rules being used
currently by using the -io option:
# ipfstat -io
empty list for ipfilter(out)
block in proto tcp from any to 192.168.2.0/24 port = telnet
#

Note – The ipfstat -io command does not display the rules in the
same sequence as they are listed in the /etc/ipf/ipf.conf file. The
out rules are listed in order first, and then the in rules are listed.

Configuring the Solaris™ IP Filter Firewall 13-15

Configuring Logging in the Solaris IP Filter Firewall

The Solaris IP Filter firewall includes the ability to log its actions.

Logged information is sent to the /dev/ipl device. The /dev/ipl

device can be monitored by running the ipmon command. The ipmon
command can log information to standard output, to a file, or send the
information to the syslogd daemon.

Configuring Logging of a Rule Match

To configure a rule match to be logged by the Solaris IP Filter firewall, the

log keyword is used. The log keyword is placed immediately after the
direction keyword in a rule, and any matches of that rule are sent to the
/dev/ipl device.

For example, to log any packets which are received on the hme0 interface
and intended for the rpcbind daemon, but which do not originate from
the 192.168.1.0 network, add the log keyword to the block rule in
the following example:
pass in quick on hme0 proto tcp/udp from 192.168.1.0 to any port = 111
block in log quick on hme0 proto tcp/udp from any to any port = 111

Configuring the Solaris IP Filter Firewall to Log to Standard

Output

To display logged information on standard output, use the ipmon

command:
# ipmon
23/07/2004 15:27:35.607407 hme0 @0:1 b 192.168.2.2,32861 -> 192.168.2.1,23 PR tc
p len 20 52 -S IN
23/07/2004 15:27:38.978075 hme0 @0:1 b 192.168.2.2,32861 -> 192.168.2.1,23 PR tc
p len 20 52 -S IN
23/07/2004 15:27:45.738002 hme0 @0:1 b 192.168.2.2,32861 -> 192.168.2.1,23 PR tc
p len 20 52 -S IN
23/07/2004 15:27:59.248572 hme0 @0:1 b 192.168.2.2,32861 -> 192.168.2.1,23 PR tc
p len 20 52 -S IN
23/07/2004 15:28:03.121993 hme0 @0:1 b 192.168.2.2,32861 -> 192.168.2.1,23 PR tc
p len 20 40 -R IN
Control-C#

13-16 Network Administration for the Solaris™ 10 Operating System

Configuring the Solaris IP Filter Firewall to Log to a File

To capture logged information to a file, supply the name of the file to log
to as an argument to the ipmon command:
# ipmon /var/tmp/filterlog.txt
<Control>-C
#

The ipmon process can be instructed to run as a daemon by using the -D

option:
# ipmon -D /var/tmp/filterlog2.txt
#

Configuring the Solaris IP Filter Firewall to Log by Using Syslog

The -s option to the ipmon command causes log information to be sent

to the syslogd daemon.

The Solaris IP Filter firewall sends packets by using the local0 facility,
and so the /etc/syslog.conf file must be configured appropriately to
record logging information sent to it by the ipmon command.

The Solaris IP Filter firewall generates messages at four levels, as show in

Table 13-3.

Table 13-3 Solaris IP Filter Firewall Message Levels

Message Level Meaning

local0.error Packets that are logged and are short.

local0.warning Packets blocked by Solaris IP Filter firewall.
local0.notice Packets passed by Solaris IP Filter firewall.
local0.info Packets matching a logged rule, but that do not
have the action associated with the rule applied.
This information tells you that the packet matches
the rule, but has been matched by a later rule in
the /etc/ipf/ipf.conf file subsequently.

Configuring the Solaris™ IP Filter Firewall 13-17

To configure the ipmon command to run as a daemon and to send

logging information by using the syslogd daemon to the
/var/adm/ipflog file:
# cat /etc/syslog.conf
local0.notice /var/adm/ipflog
# touch /var/adm/ipflog
# pkill -HUP syslogd
# ipmon -D -s
# ...

13-18 Network Administration for the Solaris™ 10 Operating System

Exercise: Configuring the Solaris IP Filter Firewall

In this exercise, you configure the Solaris OS IP filter, the Solaris IP Filter
firewall, by performing the following:
● Configuring packet filtering rules
● Restricting access to a subnet

Preparation
Caution – Before beginning this exercise, check that DNS services are
running as they were in the prior DNS exercise. If the services are not
running, issue the appropropriate svcadm commands on the appropriate
systems to once again enable them.

There is no preparation for this exercise.

Team up with other students in your subnet group so that you can
experience most aspects of the Solaris IP Filter firewall configuration.

Also, be aware of what other subnet groups are doing. Configurations on

other group’s router firewall, for example, can influence behavior that you
observe locally.

Task Summary
In this exercise, you configure packet filtering on your subnet’s router and
on client systems in your subnet.

Configuring the Solaris™ IP Filter Firewall 13-19

Task 1 – Configuring Firewall Rules

In the first part of the lab you will configure the Solaris IP Filter firewall’s
rules to show how to enable and disable access to services on a host and a
network.

The first set of exercise steps is to configure packet filtering in order to

prevent any telnet requests from reaching your system.

Working on a Non-Router System on Your Subnet

To enable the packet filter to block all incoming telnet requests to your
system, perform the following:
1. Use another system to verify that your network is functioning
properly and that your system can be accessed with the telnet
utility. After you verify that telnet access is permitted, terminate
the telnet session.
_____________________________________________________________
2. Determine the current status of the svc:/network/ipfilter and
svc:/network/pfil services by using the svcs command.
_____________________________________________________________
3. Use the ifconfig command to determine to which interface to
apply filter rules.
_____________________________________________________________
4. Edit the Solaris IP Filter firewall’s autopush configuration file to
specify the network interface for packet filtering on your system. Do
this by removing the comment from the appropriate interface
learned in the previous step.
Which file do you edit?
_____________________________________________________________

13-20 Network Administration for the Solaris™ 10 Operating System

5. Edit the /etc/ipf/ipf.conf file and add the relevant rules to block
all incoming telnet requests to your system. Your file should have
contents similar to the following:
sys12# cat /etc/ipf/ipf.conf
#
# ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
# IP Filter rules syntax.
block in proto tcp from any to 192.168.1.2/32 port = 23
#
6. Enable the packet filter.
a. Start the service, and write the command that you use.
________________________________________________________
b. Verify that the service started, and write the command that you
use.
________________________________________________________
7. Verify that, although a rule to block telnet access was established
and the ipfilter service enabled, it is possible to use the telnet
utility to access from another system to your system. After you
verify that telnet access is permitted, terminate the telnet session.
_____________________________________________________________

Caution – Although you added a blocking rule in the /etc/ipf/ip.conf

file, filtering rules do not take effect when the service is enabled. The
system is not secure at this point.

Configuring the Solaris™ IP Filter Firewall 13-21

8. From the command line force the pfild daemon to read the rule file
by performing the following steps. (You can also reboot the system
to accomplish the same effect.)
a. Use the ifconfig command to determine the configuration of
your system’s interfaces. Document the relevant interface
information, such as IP address, mask, and broadcast address.
________________________________________________________
b. Force the autopush configuration file to be read by using the
following command:
sys12# autopush -f /etc/ipf/pfil.ap
c. Unplumb your system’s interface.
________________________________________________________
d. Plumb your system’s interface to load the packet filter into the
interface’s IP stack.
________________________________________________________
9. As done previously, use another system and attempt to use the
telnet utility to determine if your system permits a telnet
connection.
_____________________________________________________________

13-22 Network Administration for the Solaris™ 10 Operating System

11. Update the Solaris IP Filter firewall configuration to include the new
rule by using the following ipf command:
sys12# ipf -Fa -f /etc/ipf/ipf.conf
12. Display the new rule set by using the ipfstat command.
_____________________________________________________________
13. Validate that the new configuration is working. Attempt to establish
a telnet session to your system from a host on the local subnet and
from a host on another subnet.
_____________________________________________________________

Working on the Router on Your Subnet

The next steps configure your router to block all telnet requests from
outside your subnet to any system on your subnet.
14. Verify that the systems can properly communicate across subnets by
establishing an appropriate telnet session that passes through your
router system. Terminate the telnet session after you verify
successful communication.
_____________________________________________________________
15. Edit the Solaris IP Filter firewall’s autopush configuration file to
specify the network interfaces for packet filtering on your router
system. Do this by removing the comments from the appropriate
interfaces. (The ifconfig command shows the interfaces.)
Which file do you edit?
_____________________________________________________________
16. Edit the relevant file on your router system and add rules to block all
incoming telnet requests to your local subnet that do not originate
from the local subnet. Document the file that you edit and your
rules.
_____________________________________________________________

Configuring the Solaris™ IP Filter Firewall 13-23

17. Enable the packet filter by performing the following steps:

a. Verify the status of the svc:/network/ipfilter service, and
write the command that you use.
________________________________________________________
b. Start the service, and write the command that you use.
________________________________________________________
c. Verify that the service started, and write the command that you
use.
________________________________________________________
18. From the command line force the pfild daemon to read the rule file
by performing the following steps. (You can also reboot the system
to accomplish the same effect.)
a. Force the autopush configuration file to be read by using the
following command:
sys11# autopush -f /etc/ipf/pfil.ap
b. Determine the configuration of your system’s interfaces.
Document the relevant interface information, such as IP
address, mask, broadcast address, and routing information.
________________________________________________________
c. Unplumb your system’s interfaces.
________________________________________________________
d. Plumb and restore your system’s interface configurations to
load the packet filter into the interface’s IP stack.
________________________________________________________
e. Verify that the rule functions as expected by using the telnet
command.
________________________________________________________

The next steps block your non-router system from sending any outgoing
ICMP echo replies.

13-24 Network Administration for the Solaris™ 10 Operating System

Working on a Non-Router System on Your Subnet

Continue as follows on the same non-router system on which you have

been working:
19. Before establishing a blocking rule, verify that you are now able to
contact your system from another system on your local subnet by
using the ping command.
_____________________________________________________________
20. Update the Solaris IP Filter firewall’s configuration file to include a
rule on the last line that blocks outgoing ICMP echo replies from the
host.
Write the rule that you entered in the /etc/ipf/ipf.conf file:
_____________________________________________________________
21. Update the Solaris IP Filter firewall configuration to include the new
rule by using the ipf command.
sys12# ipf -Fa -f /etc/ipf/ipf.conf
22. Verify the rules by using the ipfstat command.
_____________________________________________________________
23. Test that the new rule is functioning correctly by using the ping
command from the test system again.
_____________________________________________________________
24. Verify that a local system can successfully perform DNS lookups
across routers. Use the dig command to find the IP address of a
system on another network. (Successful completion of this step will
aide you in later steps when you write rules to specifically allow
DNS through firewalls.)
_____________________________________________________________

Configuring the Solaris™ IP Filter Firewall 13-25

Task 2 – Disabling Services

In the second part of the lab you restrict access to your subnet by
disabling all services except a defined set.

Working on the Router on Your Subnet

Perform the following:

1. Edit the Solaris IP Filter firewall’s rules to block all traffic on the
router.
Remove all existing rules currently in the configuration file, and
write and document the new rules that you entered in the
/etc/ipf/ipf.conf file.
_____________________________________________________________
_____________________________________________________________
2. Update the Solaris IP Filter firewall configuration to include the new
rules by using the ipf command.
_____________________________________________________________
3. Verify the rules by using the ipfstat command.
_____________________________________________________________

Working on Each Non-Router System on Your Subnet

Continue as follows on the same non-router system on which you have

been working:
4. Remove all of the rules in the /etc/ipf/ipf.conf file.
5. Reboot all of the non-router systems.
_____________________________________________________________
The reboot is performed as an easy way to flush cached information
on the non-router systems. It is not a necessary part of the Solaris IP
Filter firewall’s configuration.

13-26 Network Administration for the Solaris™ 10 Operating System

Working on the Router on Your Subnet

Continue as follows on the same router system on which you have been
working:
6. Update the Solaris IP Filter firewall configuration to permit routing
information traffic to be sent and received.
Before the existing block out all and block in all rules, write
the rules that you entered in the /etc/ipf/ipf.conf file:
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
7. Update the Solaris IP Filter firewall configuration to use the new
rules by using the ipf command.
_____________________________________________________________
8. Verify the rules by using the ipfstat command.
_____________________________________________________________

Working on a Non-Router System on Your Subnet

Continue as follows on the non-router system on which you have been

working:
9. Test that the new rules function correctly by checking the
configuration of the routing tables on the non-router hosts and by
snooping the network to look for routing packets.
_____________________________________________________________
_____________________________________________________________

Configuring the Solaris™ IP Filter Firewall 13-27

Working on the Router on Your Subnet

Continue as follows on the same router system on which you have been
working:
10. Update the Solaris IP Filter firewall configuration to permit DNS
traffic to be sent and received.
At the beginning of the configuration file, write the rules that you
entered in the /etc/ipf/ipf.conf file.
_____________________________________________________________
_____________________________________________________________
11. Update the Solaris IP Filter firewall configuration to include the new
rule by using the ipf command.
_____________________________________________________________
12. Verify the rules by using the ipfstat command.
_____________________________________________________________

Working on a Non-Router System on Your Subnet

Continue as follows on a non-router system on the same subnet on which

you have been working:
13. Use the dig command to find the IP address of a system on another
network. Be sure to query a DNS server on that other network.
_____________________________________________________________

13-28 Network Administration for the Solaris™ 10 Operating System

Working on the Router on Your Subnet

Continue as follows on the same router system on which you have been
working:
14. Even though this group of steps is to be performed on your router
system, before configuring rules for FTP, verify that your firewalls
are functioning properly by insuring that you cannot initiate an FTP
session from your non-router system to the instructor machine.
Once you verify this, you can proceed with writing rules to allow
FTP through the router firewall system.
_____________________________________________________________
15. Update the Solaris IP Filter firewall configuration to permit FTP
traffic to pass from the local subnet to the instructor system only. Log
any traffic that matches one of the rules that you define.
Assume that your system will get more DNS traffic than FTP traffic.
Placing the new FTP rules after the DNS rules would recognize this
and, appropriately, be more responsive to the DNS traffic.
Hint: Use the keep state keywords in your rules.
Write the rules that you entered in the /etc/ipf/ipf.conf file.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
16. Update the Solaris IP Filter firewall configuration to include the new
rule by using the ipf command.
_____________________________________________________________
17. Verify the rules by using the ipfstat command.
_____________________________________________________________

Configuring the Solaris™ IP Filter Firewall 13-29

18. Use the ipmon command as a daemon to log information to the

/var/tmp/ipfilter.log file.
_____________________________________________________________

Working on a Non-Router System on Your Subnet

Continue as follows on any non-router system on your subnet. You will

now be using FTP to connect to another system on another subnet across
your firewall router.
19. Use FTP to access a system on another subnet.
_____________________________________________________________
What behavior do you see?
_____________________________________________________________
20. Use FTP to access the instructor system.
_____________________________________________________________
What behavior do you see?
_____________________________________________________________

Working on the Router on Your Subnet

Complete as follows on the same router system on which you have been
working:
21. View the log file created by the ipmon command.
_____________________________________________________________

13-30 Network Administration for the Solaris™ 10 Operating System

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Configuring the Solaris™ IP Filter Firewall 13-31

Exercise Solutions
Solutions to this exercise are provided in the following sections.

These solutions use sys12 as the example non-router system and sys11
as the example router system. Solution results vary accordingly.

Task 1 Solutions
In the first part of the lab you will configure the Solaris IP Filter firewall’s
rules to show how to enable and disable access to services on a host and a
network.

The first set of exercise steps is to configure packet filtering in order to

prevent any telnet requests from reaching your system.

Working on a Non-Router System on Your Subnet

To enable the packet filter to block all incoming telnet requests to your
system, perform the following:
1. Use another system to verify that your network is functioning
properly and that your system can be accessed with the telnet
utility. After you verify that telnet access is permitted, terminate
the telnet session.
sys13# telnet sys12
Trying 192.168.1.2...
Connected to sys12.one.edu
Escape character is '^]'.
login: root
Password:
Last login: Mon Dec 20 03:46:26 from sys13.one.edu
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA300-S10_A on sys12
sys12# exit
Connection to sys12.one.edu closed by foreign host.
sys13#
This proves that your system responds to the telnet request as expected.
Now you can proceed with configuring the firewall and have confidence that
your working blocking rule will be responsible for blocking telnet
requests and not some other networking issue.

13-32 Network Administration for the Solaris™ 10 Operating System

2. Determine the current status of the svc:/network/ipfilter and

svc:/network/pfil services by using the svcs command.
sys12# svcs -a | grep network | egrep "pfil|ipf"
disabled 8:31:38 svc:/network/ipfilter:default
online 8:31:42 svc:/network/pfil:default
3. Use the ifconfig command to determine to which interface to
apply filter rules.
sys12# ifconfig -a inet
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
4. Edit the Solaris IP Filter firewall’s autopush configuration file to
specify the network interface for packet filtering on your system. Do
this by removing the comment from the appropriate interface
learned in the previous step.
Which file do you edit?
The /etc/ipf/pfil.ap file.
Your configuration file should look similar to the following:
sys12# cat /etc/ipf/pfil.ap
...
#qe
hme
#qfe
...
5. Edit the /etc/ipf/ipf.conf file and add the relevant rules to block
all incoming telnet requests to your system. Your file should have
contents similar to the following:
sys12# cat /etc/ipf/ipf.conf
#
# ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
# IP Filter rules syntax.
block in proto tcp from any to 192.168.1.2/32 port = 23
#

Configuring the Solaris™ IP Filter Firewall 13-33

6. Enable the packet filter.

a. Start the service, and write the command that you use.
sys12# svcadm enable svc:/network/ipfilter:default
Note that when enabled in this manner, the service is configured to
run automatically on subsequent system boots.
b. Verify that the service started, and write the command that you
use.
sys12# svcs -a | grep -i ipf
online 3:48:09 svc:/network/ipfilter:default
7. Verify that, although a rule to block telnet access was established
and the ipfilter service enabled, it is possible to use the telnet
utility to access from another system to your system. After you
verify that telnet access is permitted, terminate the telnet session.
sys13# telnet sys12
Trying 192.168.1.2...
Connected to sys12.one.edu.
Escape character is '^]'.
login: root
Password:
Last login: Mon Dec 20 03:46:26 from sys13.one.edu
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA300-S10_A on sys12
sys12# exit
Connection to sys12.one.edu closed by foreign host.
sys13#

Caution – Although you added a blocking rule in the /etc/ipf/ip.conf

file, filtering rules do not take effect when the service is enabled. The
system is not secure at this point.

13-34 Network Administration for the Solaris™ 10 Operating System

8. From the command line force the pfild daemon to read the rule file
by performing the following steps. (You can also reboot the system
to accomplish the same effect.)
a. Use the ifconfig command to determine the configuration of
your system’s interfaces. Document the relevant interface
information, such as IP address, mask, and broadcast address.
sys12# ifconfig -a inet
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
b. Force the autopush configuration file to be read by using the
following command:
sys12# autopush -f /etc/ipf/pfil.ap
c. Unplumb your system’s interface.
sys12# ifconfig hme0 down unplumb
d. Plumb your system’s interface to load the packet filter into the
interface’s IP stack.
sys12# ifconfig hme0 plumb 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 up
9. As done previously, use another system and attempt to use the
telnet utility to determine if your system permits a telnet
connection.
sys13# telnet sys12
Trying 192.168.1.2...
telnet: Unable to connect to remote host: Connection timed out
sys13#
You should observe that telnet access is now blocked.

Configuring the Solaris™ IP Filter Firewall 13-35

The next steps are to configure your system to permit incoming telnet
requests from the local subnet, but block telnet requests from all other
networks and not process any other rules.
10. Edit the Solaris IP Filter firewall configuration file by adding a new
rule that:
● Permits incoming telnet access only from other hosts on your
local subnet
● Stops processing of subsequent rules by using the quick
keyword.
Write the rule that you entered in the /etc/ipf/ipf.conf file:
pass in quick proto tcp from 192.168.1.0/24 to 192.168.1.2/32 port = 23
Did you put the new rule before or after the existing rule? Why?
Because you used the quick keyword in the new rule, it should be placed
before the old rule to permit local telnet access only.
If you place it after the old the rule, the old rule attempts to block the
telnet requests and then the new rule permits telnet access from the
local subnet.
11. Update the Solaris IP Filter firewall configuration to include the new
rule by using the following ipf command:
sys12# ipf -Fa -f /etc/ipf/ipf.conf
12. Display the new rule set by using the ipfstat command.
sys12# ipfstat -io
empty list for ipfilter(out)
pass in quick proto tcp from 192.168.1.0/24 to 192.168.1.2/32 port = telnet
block in proto tcp from any to 192.168.1.2/32 port = telnet
13. Validate that the new configuration is working. Attempt to establish
a telnet session to your system from a host on the local subnet and
from a host on another subnet.
sys13# telnet 192.168.1.2
Trying 192.168.1.2...
Connected to sys12.
Escape character is ’^]’.
login:

sys22# telnet 192.168.1.2

Trying 192.168.1.2...
You should observe that telnet access succeeds on the local subnet only.

13-36 Network Administration for the Solaris™ 10 Operating System

Working on the Router on Your Subnet

The next steps configure your router to block all telnet requests from
outside your subnet to any system on your subnet.
14. Verify that the systems can properly communicate across subnets by
establishing an appropriate telnet session that passes through your
router system. Terminate the telnet session after you verify
successful communication.
sys21# telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
login: root
Password:
Last login: Mon Dec 20 05:54:27 from sys21ext.thirty
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA300-S10_A on sys11
sys11# exit
Connection to 192.168.1.1 closed by foreign host.
Now that you have established successful communication you can have
confidence that subsequent failed sessions will be the result of a firewall
configured properly, and not some other networking issue.
15. Edit the Solaris IP Filter firewall’s autopush configuration file to
specify the network interfaces for packet filtering on your router
system. Do this by removing the comments from the appropriate
interfaces. (The ifconfig command shows the interfaces.)
Which file do you edit?
The /etc/ipf/pfil.ap file.
Your configuration file should look similar to the following:
sys11# cat /etc/ipf/pfil.ap
...
#qe
hme
qfe
#eri
...

Configuring the Solaris™ IP Filter Firewall 13-37

16. Edit the relevant file on your router system and add rules to block all
incoming telnet requests to your local subnet that do not originate
from the local subnet. Document the file that you edit and your
rules.
sys11# cat /etc/ipf/ipf.conf
block in on qfe2 proto tcp from any to 192.168.1.0/24 port = 23
17. Enable the packet filter by performing the following steps:
a. Verify the status of the svc:/network/ipfilter service, and
write the command that you use.
sys11# svcs -a | grep ipfilter
disabled 8:31:38 svc:/network/ipfilter:default
b. Start the service, and write the command that you use.
sys11# svcadm enable svc:/network/ipfilter:default
c. Verify that the service started, and write the command that you
use.
sys11# svcs -a | grep ipfilter
online 5:56:23 svc:/network/ipfilter:default
18. From the command line force the pfild daemon to read the rule file
by performing the following steps. (You can also reboot the system
to accomplish the same effect.)
a. Force the autopush configuration file to be read by using the
following command:
sys11# autopush -f /etc/ipf/pfil.ap
b. Determine the configuration of your system’s interfaces.
Document the relevant interface information, such as IP
address, mask, broadcast address, and routing information.
sys11# ifconfig -a inet

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1

inet 127.0.0.1 netmask ff000000
hme0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.1.1 netmask ffffff00 broadcast 192.168.1.255
qfe2: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 192.168.30.31 netmask ffffff00 broadcast 192.168.30.255
c. Unplumb your system’s interfaces.
sys11# ifconfig hme0 down unplumb
sys11# ifconfig qfe2 down unplumb

13-38 Network Administration for the Solaris™ 10 Operating System

d. Plumb and restore your system’s interface configurations to

load the packet filter into the interface’s IP stack.
sys11# ifconfig hme0 plumb 192.168.1.1 netmask 0xffffff00 broadcast + up
sys11# ifconfig qfe2 plumb 192.168.30.31 netmask 0xffffff00 broadcast + up
e. Verify that the rule functions as expected by using the telnet
command.
sys21# telnet 192.168.1.1
Trying 192.168.1.1...
telnet: Unable to connect to remote host: Connection timed out
sys21#
You should observe that local telnet traffic is permitted but traffic
initiated from another subnet is not.

The next steps block your non-router system from sending any outgoing
ICMP echo replies.

Working on a Non-Router System on Your Subnet

Continue as follows on the same non-router system on which you have

been working:
19. Before establishing a blocking rule, verify that you are now able to
contact your system from another system on your local subnet by
using the ping command.
sys13# ping sys12
sys12 is alive
sys13#
20. Update the Solaris IP Filter firewall’s configuration file to include a
rule on the last line that blocks outgoing ICMP echo replies from the
host.
Write the rule that you entered in the /etc/ipf/ipf.conf file:
block out quick proto icmp from any to any icmp-type 0
Note that even though the first rule uses the quick keyword, ping traffic
will reach this new, third rule because the first rule will not match ICMP
traffic and therefore the quick keyword will not apply.

Configuring the Solaris™ IP Filter Firewall 13-39

21. Update the Solaris IP Filter firewall configuration to include the new
rule by using the ipf command.
sys12# ipf -Fa -f /etc/ipf/ipf.conf
22. Verify the rules by using the ipfstat command.
sys12# ipfstat -io
block out quick proto icmp from any to any icmp-type echorep
pass in quick proto tcp from 192.168.1.0/24 to 192.168.1.2/32 port = telnet
block in proto tcp from any to 192.168.1.2/32 port = telnet
#
23. Test that the new rule is functioning correctly by using the ping
command from the test system again.
sys13# ping sys12
no answer from sys12
24. Verify that a local system can successfully perform DNS lookups
across routers. Use the dig command to find the IP address of a
system on another network. (Successful completion of this step will
aid you in later steps when you write rules to specifically allow DNS
through firewalls.)
sys13# dig @192.168.2.2 two.edu -x 192.168.2.4
; <<>> DiG 9.2.4 <<>> @192.168.2.2 two.edu -x 192.168.2.4
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1914
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;two.edu. IN A
;; AUTHORITY SECTION:
two.edu. 86400 IN SOA sys22.two.edu.
root.sys22.two.edu. 2005010101 3600 1800 6048000 86400
;; Query time: 4 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed Jan 12 08:19:05 2005
;; MSG SIZE rcvd: 72
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1194
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;4.2.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.2.168.192.in-addr.arpa. 86400 IN PTR sys24.two.edu.
;; AUTHORITY SECTION:
2.168.192.in-addr.arpa. 86400 IN NS sys22.two.edu.
2.168.192.in-addr.arpa. 86400 IN NS sys23.two.edu.
;; ADDITIONAL SECTION:

13-40 Network Administration for the Solaris™ 10 Operating System

sys22.two.edu. 86400 IN A 192.168.2.2

sys23.two.edu. 86400 IN A 192.168.2.3
;; Query time: 1 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed Jan 12 08:19:05 2005
;; MSG SIZE rcvd: 141

Task 2 Solutions
In the second part of the lab you restrict access to your subnet by
disabling all services except a defined set.

Working on the Router on Your Subnet

Perform the following:

1. Edit the Solaris IP Filter firewall’s rules to block all traffic on the
router.
Remove all existing rules currently in the configuration file, and
write and document the new rules that you entered in the
/etc/ipf/ipf.conf file.
block in all
block out all
2. Update the Solaris IP Filter firewall configuration to include the new
rules by using the ipf command.
sys11# ipf -Fa -f /etc/ipf/ipf.conf
3. Verify the rules by using the ipfstat command.
sys11# ipfstat -io
block out all
block in all
#

Working on Each Non-Router System on Your Subnet

Continue as follows on the same non-router system on which you have

been working:
4. Remove all of the rules in the /etc/ipf/ipf.conf file.
The /etc/ipf/ipf.conf file should be empty.
5. Reboot all of the non-router systems.
sys12# init 6

Configuring the Solaris™ IP Filter Firewall 13-41

The reboot is performed as an easy way to flush cached information

on the non-router systems. It is not a necessary part of the Solaris IP
Filter firewall’s configuration.

Working on the Router on Your Subnet

Continue as follows on the same router system on which you have been
working:
6. Update the Solaris IP Filter firewall configuration to permit routing
information traffic to be sent and received.
Before the existing block out all and block in all rules, write
the rules that you entered in the /etc/ipf/ipf.conf file:
pass in quick proto udp from any to any port = 520
pass out quick proto udp from any to any port = 520
pass in quick proto udp from any to any port = 521
pass out quick proto udp from any to any port = 521
pass in quick proto icmp from any to any icmp-type 10
pass out quick proto icmp from any to any icmp-type 9
7. Update the Solaris IP Filter firewall configuration to use the new
rules by using the ipf command.
sys11# ipf -Fa -f /etc/ipf/ipf.conf
8. Verify the rules by using the ipfstat command.
sys11# ipfstat -io
pass out quick proto udp from any to any port = route
pass out quick proto udp from any to any port = ripngd
pass out quick proto icmp from any to any icmp-type routerad
block out all
pass in quick proto udp from any to any port = route
pass in quick proto udp from any to any port = ripngd
pass in quick proto icmp from any to any icmp-type routersol
block in all

13-42 Network Administration for the Solaris™ 10 Operating System

Working on a Non-Router System on Your Subnet

Continue as follows on the non-router system on which you have been

working:
9. Test that the new rules function correctly by checking the
configuration of the routing tables on the non-router hosts and by
snooping the network to look for routing packets.
sys12# netstat -rn -f inet
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.1.0 192.168.1.2 U 1 0 hme0
224.0.0.0 192.168.1.2 U 1 0 hme0
default 192.168.1.1 UG 1 0 hme0
127.0.0.1 127.0.0.1 UH 4 77 lo0
sys12#
sys12# snoop
...
sys11 -> 192.168.1.255 RIP R (3 destinations)
sys11 -> 192.168.1.255 RIP R (3 destinations)
...
You should see evidence of routing information in the routing table (a
default route, for example) or in the snoop trace (router advertisements for
example, but no other non-routing services.)

Working on the Router on Your Subnet

Continue as follows on the same router system on which you have been
working:
10. Update the Solaris IP Filter firewall configuration to permit DNS
traffic to be sent and received.
At the beginning of the configuration file, write the rules that you
entered in the /etc/ipf/ipf.conf file.
pass in quick proto udp from any to any port = 53 keep state
pass out quick proto udp from any to any port = 53 keep state
11. Update the Solaris IP Filter firewall configuration to include the new
rule by using the ipf command.
sys11# ipf -Fa -f /etc/ipf/ipf.conf
12. Verify the rules by using the ipfstat command.
sys11# ipfstat -io
pass out quick proto udp from any to any port = domain keep state

Configuring the Solaris™ IP Filter Firewall 13-43

pass out quick proto udp from any to any port = route
pass out quick proto udp from any to any port = ripng
pass out quick proto icmp from any to any icmp-type routerad
block out all
pass in quick proto udp from any to any port = domain keep state
pass in quick proto udp from any to any port = route
pass in quick proto udp from any to any port = ripng
pass in quick proto icmp from any to any icmp-type routersol
block in all

Working on a Non-Router System on Your Subnet

Continue as follows on a non-router system on the same subnet on which

you have been working:
13. Use the dig command to find the IP address of a system on another
network. Be sure to query a DNS server on that other network.
sys13# dig @192.168.2.2 two.edu -x 192.168.2.4
; <<>> DiG 9.2.4 <<>> @192.168.2.2 two.edu -x 192.168.2.4
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1914
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;two.edu. IN A
;; AUTHORITY SECTION:
two.edu. 86400 IN SOA sys22.two.edu.
root.sys22.two.edu. 2005010101 3600 1800 6048000 86400
;; Query time: 4 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed Jan 12 08:19:05 2005
;; MSG SIZE rcvd: 72
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1194
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;4.2.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.2.168.192.in-addr.arpa. 86400 IN PTR sys24.two.edu.
;; AUTHORITY SECTION:
2.168.192.in-addr.arpa. 86400 IN NS sys22.two.edu.
2.168.192.in-addr.arpa. 86400 IN NS sys23.two.edu.
;; ADDITIONAL SECTION:
sys22.two.edu. 86400 IN A 192.168.2.2
sys23.two.edu. 86400 IN A 192.168.2.3

13-44 Network Administration for the Solaris™ 10 Operating System

;; Query time: 1 msec

;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed Jan 12 08:19:05 2005
;; MSG SIZE rcvd: 141

Working on the Router on Your Subnet

Configuring the Solaris™ IP Filter Firewall 13-45

15. Update the Solaris IP Filter firewall configuration to permit FTP

traffic to pass from the local subnet to the instructor system only. Log
any traffic that matches one of the rules that you define.
Assume that your system will get more DNS traffic than FTP traffic.
Placing the new FTP rules after the DNS rules would recognize this
and, appropriately, be more responsive to the DNS traffic.
Hint: Use the keep state keywords in your rules.
Write the rules that you entered in the /etc/ipf/ipf.conf file.
pass in log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass out log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass in log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass out log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass in log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass out log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass in log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass out log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
16. Update the Solaris IP Filter firewall configuration to include the new
rule by using the ipf command.
sys11# ipf -Fa -f /etc/ipf/ipf.conf

17. Verify the rules by using the ipfstat command.

sys11# ipfstat -io
pass out quick proto udp from any to any port = domain keep state
pass out log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass out log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass out log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass out log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass out quick proto udp from any to any port = route
pass out quick proto udp from any to any port = ripng
pass out quick proto icmp from any to any icmp-type routerad
block out all
pass in quick proto udp from any to any port = domain keep state
pass in log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass in log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 21 keep state
pass in log quick on hme0 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass in log quick on qfe2 from 192.168.1.0/24 to 192.168.30.30/32 port = 20 keep state
pass in quick proto udp from any to any port = route
pass in quick proto udp from any to any port = ripng
pass in quick proto icmp from any to any icmp-type routersol
block in all

18. Use the ipmon command as a daemon to log information to the

/var/tmp/ipfilter.log file.
# ipmon -D /var/tmp/ipfilter.log

13-46 Network Administration for the Solaris™ 10 Operating System

Working on a Non-Router System on Your Subnet

Continue as follows on any non-router system on your subnet. You will

now be using FTP to connect to another system on another subnet across
your firewall router.
19. Use FTP to access a system on another subnet.
sys13# ftp 192.168.2.3
ftp: connect: Connection timed out
ftp>
What behavior do you see?
The attempt to connect fails.
20. Use FTP to access the instructor system.
sys13# ftp 192.168.30.30
Connected to 192.168.30.30.
220 instructor.thirty.edu FTP server ready.
Name (192.168.30.30:root):
What behavior do you see?
The attempt to connect succeeds.

Configuring the Solaris™ IP Filter Firewall 13-47

Working on the Router on Your Subnet

Complete as follows on the same router system on which you have been
working:
21. View the log file created by the ipmon command.
sys11# cat /var/tmp/ipfilter.log
03/02/2005 14:13:12.223769 hme0 @0:2 p 192.168.1.3,32788 -> 192.168.30.30,21 PR tcp
len 20 52 -S K-S IN
03/02/2005 14:13:12.223821 qfe0 @0:2 p 192.168.1.3,32788 -> 192.168.30.30,21 PR tcp
len 20 52 -S K-S OUT
03/02/2005 14:13:12.224270 qfe0 @0:2 p 192.168.30.30,21 -> 192.168.1.3,32788 PR tcp
len 20 52 -AS K-S IN
03/02/2005 14:13:12.224486 hme0 @0:2 p 192.168.30.30,21 -> 192.168.1.3,32788 PR tcp
len 20 52 -AS K-S OUT
03/02/2005 14:13:12.224930 hme0 @0:2 p 192.168.1.3,32788 -> 192.168.30.30,21 PR tcp
len 20 40 -A K-S IN
03/02/2005 14:13:12.224950 qfe0 @0:2 p 192.168.1.3,32788 -> 192.168.30.30,21 PR tcp
len 20 40 -A K-S OUT
03/02/2005 14:13:12.274058 qfe0 @0:2 p 192.168.30.30,21 -> 192.168.1.3,32788 PR tcp
len 20 85 -AP K-S IN
03/02/2005 14:13:12.274078 hme0 @0:2 p 192.168.30.30,21 -> 192.168.1.3,32788 PR tcp
len 20 85 -AP K-S OUT
03/02/2005 14:13:12.274309 hme0 @0:2 p 192.168.1.3,32788 -> 192.168.30.30,21 PR tcp
len 20 40 -A K-S IN
03/02/2005 14:13:12.274326 qfe0 @0:2 p 192.168.1.3,32788 -> 192.168.30.30,21 PR tcp
len 20 40 -A K-S OUT

13-48 Network Administration for the Solaris™ 10 Operating System

Sun Microsystems Publications

The following publications are available from Sun Microsystems:
● Sun Microsystems, Inc. Solaris Tunable Parameters Reference Manual,
part number 806-7009-10.
● Sun Microsystems, Inc. System Administration Guide: Advanced
Administration, part number 806-4074-10.
● Sun Microsystems, Inc. System Administration Guide: IP Services, part
number 806-4075-11.
● Sun Microsystems, Inc. System Administration Guide: Naming and
Directory Services (DNS, NIS, and LDAP), part number 806-4077-10.
● Sun Microsystems, Inc. System Administration Guide: Security Services,
part number 806-4078-10.
● Sun Microsystems, Inc. Using NTP to Control and Synchronize System
Clocks – Part I: Introduction to NTP, Sun BluePrints OnLine part
number 816-1475-10.
● Sun Microsystems, Inc. Using NTP to Control and Synchronize System
Clocks – Part II: Basic NTP Administration and Architecture, Sun
BluePrints OnLine part number 816-0092-10.
● Sun Microsystems, Inc. Using NTP to Control and Synchronize System
Clocks – Part III: NTP Monitoring and Troubleshooting, Sun BluePrints
OnLine part number 816-2353-10.

Books
The following books were used to create this course:
● Albitz, Paul, and Cricket Liu. DNS & BIND, Fourth Edition.
Sebastopol, CA: O’Reilly & Associates, Inc., 2001.
● Comer, Douglas. Internetworking with TCP/IP, Second Edition.
Englewood Cliffs, NJ: Prentice Hall, 1991.
● Comer, Douglas E. Internetworking With TCP/IP, Vol. 1, Third Edition.
Upper Saddle River, NJ: Prentice Hall, Inc. 1995.
● Huitema, Christian. IPv6 The New Internet Protocol, Second Edition.
Upper Saddle River, NJ: Prentice Hall, Inc. 1998.
● Huitema, Christian. Routing in the Internet. Upper Saddle River, NJ:
Prentice-Hall. 1995.
● Huitema, Christian. Routing in the Internet, Second Edition. Upper
Saddle River, NJ: Prentice Hall, Inc., 1999.
● Loshin, Pete. IPv6 Clearly Explained. San Francisco: Morgan
Kaufmann, 1999.
● Perlman, Radia. Interconnections, Second Edition. Menlo Park, CA:
Addison-Wesley, 1999.
● Spurgeon, Charles E. Ethernet: The Definitive Guide. Sebastopol, CA:
O’Reilly & Associates, Inc., 2000.

The following book can be used when studying for the Solaris 8 Network
Certification Exam:

Bushnell, Rick. Sun Certified Net Administration for Solaris 8 Study

Guide. Upper Saddle River, NJ: Prentice Hall, Inc., 2002.

Bibliography-2 Network Administration for the Solaris™ 10 Operating System

Online References
Many online references were used to create this course, including:
● Mills, David. Information on Time and Frequency Services. [Online].
Available: http://www.eecis.udel.edu/~mills/ntp/, last
accessed: 2000.
● Windl, U. and D. Dalton. What about NTP?: Understanding and Using
the Network Time Protocol (A First Try on a Non-Technical Mini-HOWTO
and FAQ on NTP). [Online]. Available:
www.ntp.org/ntpfaq/NTP-a-faq.htm. Last accessed: 03/04/2000.
● The Solaris OS online manual pages.
● The http://docs.sun.com Web site.
● The http://www.sun.com/solutions/blueprints/ Sun
BluePrints Web site.

RFCs
Many RFCs were used to create this course, including:
● RFC 1323: TCP Extensions for High Performance.
● Conta, A., and S. Deering. RFC 2463: Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
Network Working Group Request for Comments: 2463, 1998.
● Fenner, W. RFC 2236: Internet Group Management Protocol, Version 2.
Network Working Group Request for Comments: 2236, 1997.
● Hinden, R., and S. Deering. RFC 2373: IP Version 6 Addressing
Architecture. Network Working Group Request for Comments: 2373,
1998.
● Hinden, R., and S. Deering. RFC 2460: Internet Protocol, Version 6
(IPv6) Specification. Network Working Group Request for Comments:
2460, 1998.
● Mills, David. RFC 1305: Network Time Protocol (Version 3) Specification,
Implementation and Analysis. Network Working Group Request for
Comments: 1305, 1992.
● Narten, T., E. Nordmark, and W. Simpson. RFC 2461: Neighbor
Discovery for IP Version 6 (IPv6). Network Working Group Request for
Comments: 2461, 1998.
● Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear.
RFC 1918: Address Allocation for Private Internets. Network Working
Group Request for Comments: 1918, 1996.
● Thomson, S., and T. Narten. RFC: 2462: IPv6 Stateless Address
Autoconfiguration. Network Working Group Request for Comments:
2462, 1998.

Bibliography-4 Network Administration for the Solaris™ 10 Operating System

Numerals
10BASE-T
An evolution of Ethernet technology that succeeded 10BASE-5 and
10BASE-2 as the most popular method of physical network
implementation. A 10BASE-T network has a data transfer rate of
10 megabits per second and uses unshielded twisted-pair wiring.

A
ACL
(access control list) ACLs provide a higher level of file security than the
standard UNIX file permissions. ACLs give a file owner the ability to
permit access to that file or directory to one or more specific users or
groups and to set the default permissions for specific users or groups.
AH
Authentication header.
ANSI
American National Standards Institute.
application
A program that combines all the functions necessary for the user to
accomplish a particular set of tasks (for example, word processing or
inventory tracking).
Application layer
In the International Standards Organization/Open Systems
Interconnection (ISO/OSI) model of network standards, the seventh
layer, which handles services, such as login procedures, file and print
server operation, and other basic functions.

Glossary-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
ARP
(Address Resolution Protocol) The Internet protocol that dynamically
maps Internet addresses to physical (hardware) addresses on local area
networks. ARP is limited to networks that support hardware broadcast.
AS
Autonomous system.
ASCII
(American Standard Code for Information Interchange) A standard
assignment of 7-bit numeric codes to characters.

B
BCC
Block-check character.
BIND
Berkeley Internet Name Domain.
boot
(bootstrap) To load the system software into memory and start it.
Bourne shell
The Bourne shell is the default shell for the Solaris Operating
Environment. It does not have aliasing or history capabilities.
broadcast address
One of three types of Ethernet addresses, the broadcast address
represents broadcasts to the network. A host sends a message to all
hosts on the local Ethernet using a broadcast address. The Ethernet
broadcast address is all 1s (ff:ff:ff:ff:ff:ff in hexadecimal).

C
cache
A buffer of high-speed memory filled at medium speed from main
memory, often with instructions or the most frequently accessed
information. A cache increases effective memory transfer rates and
processor speed.
caching-only server
A domain name server that is not authoritative for any domain. This
server queries servers that have authority for the information needed
and caches that data.

Glossary-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
canonical
Characteristic of adhering to standard, accepted, or authoritative
procedures or principles.
Category 3
Category 3 twisted-pair cabling is a voice-grade cable. It features two to
three twists per foot and is used in 10BASE-T and 100BASE-T4
networks.
Category 5
Category 5 twisted-pair cable is a data-grade cable. It features two to
three twists per inch used in 10BASE-T and 100BASE-TX networks.
CCITT
Comite Consultatif Internationale de Telegraphie et Telephonie.
CDE
(Common Desktop Environment) This is a graphical user interface
between the user and the operating system. It provides built-in menus
for users to select and run utilities and programs without using the
Solaris 2.x OE commands. It enables users to control multiple working
documents or applications on the screen at the same time.
checksum
A checksum is a number that is calculated from the binary bytes of the
file. It is used to determine if the file contents have changed.
CIDR
(classless inter-domain routing) This type of routing was introduced as a
stop-gap solution to the Class B IPv4 address exhaustion and routing
table explosion. CIDR enables more efficient allocation of IP address
space, and it enables routing information to be aggregated to reduce the
size of routing tables on backbone routers.
client-server model
A client-server environment is a network environment that contains at
least one of each of the following:
● Server – A host or a process that provides services to other
systems on the network.
● Client – A host or a process that uses services provided by
servers.
CNAME
Canonical name.

Glossary/Acronyms Glossary-3
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
connectionless
A type of data transfer in which self-contained messages are delivered
without acknowledgement of receipt. User Datagram Protocol (UDP) is
an example of a protocol in which a connection is not necessary.
connection-oriented
A type of data transfer in which a connection with another system must
be established before exchanging data. Transmission Control Protocol
(TCP) is an example of a connection-oriented protocol.
CRC
(cyclical redundancy check) A system of error checking performed at
both the sending and receiving station after a block-check character
(BCC) has been accumulated.
CSMA/CD
(carrier sense multiple access/collision detection) The Ethernet access
method protocol used to control packet transmission and flow over the
Ethernet hardware.

D
daemon
A process that performs a particular system task.
datagram
The Internet Protocol (IP) datagram is the basic unit of information that
is passed on a Transmission Control Protocol/Internet Protocol
(TCP/IP) network. Datagrams contain at least data and destination
addresses.
Data Link layer
In the International Standards Organization/Open Systems
Interconnection (ISO/OSI) model, the second layer, which enables
establishing, maintaining, and releasing services between network
entities.
decryption
The process of converting coded data to plain text.
de-encapsulation
The process of removing a header from a segment of data when systems
are communicating with each other.

Glossary-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
DHCP
(Dynamic Host Configuration Protocol) This automatically assigns
Internet Protocol (IP) addresses to Transmission Control
Protocol/Internet Protocol (TCP/IP) client computers when the client
joins the network. This eliminates the need to maintain a static list of
addresses for each client. DHCP selects an IP address from a
preconfigured pool.
DNS
(Domain Name System) DNS provides translations of host names into
Internet Protocol (IP) addresses. This enables Internet communications
using only host names.
domain
The name assigned to a group of systems on a local network that share
administrative files. It is required for the Network Information Service
(NIS) database to work properly.

E
EBCDIC
Extended Binary Coded Decimal Interchange Code.
EEPROM
(electrically erasable programmable read-only memory) A nonvolatile
PROM that can be written to as well as read from. In Sun workstations,
an EEPROM holds information about the current system configuration,
alternate boot paths, and so on.
EGPs
Exterior gateway protocols.
encapsulation
The process of adding a header to a segment of data when systems are
communicating with each other.
encryption
The process of protecting information from unauthorized use by making
the information unintelligible. Encryption is based on a code, called a
key, which is used to decrypt the information.
ESP
Encapsulation security payload.
Ethernet
A type of local area network that enables real-time communication
between machines connected directly through cables.

Glossary/Acronyms Glossary-5
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
Ethernet address
The physical address of an individual Ethernet controller board. It is
called the hardware address or media access control (MAC) address.
The Ethernet address of every Sun workstation is unique and coded into
a chip on the motherboard. Additional Ethernet interfaces are assigned
different Ethernet addresses.
Ethernet MAC address
The physical address also known as the media access controller (MAC)
or Ethernet address. An Ethernet address is a unique hardware address.
It is 48 bits long. An example of a complete Ethernet address is
8:0:20:le:56:7:d.
EUI
End-unit identifier.

F
FCS
Frame check sequence.
FP
Format prefix.
FQDN
(fully qualified domain name) A domain name that ends with a dot
followed by a domain label of length zero (the root). For example,
andy.sun.com, where andy is the name of a host.
frame
A series of bits with a well-defined beginning and a well-defined end.

H
hierarchal domains
A tree of domains or namespaces, each one of them having their own
authority.
hierarchy
A classification of relationships in which each item except the top one
(called the root) is a specialized form of the item above it. Each item can
have one or more items below it in the hierarchy.

Glossary-6 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
host name
A unique name identifying a host machine connected to a network. The
name must be unique on the network. The hostname command
determines a system’s host.
hub
The central device through which all hosts in a twisted-pair Ethernet
installation are connected.

I
IAB
Internet Architecture Board.
IANA
Internet Assigned Numbers Authority.
ICANN
Internet Corporation for Assigned Names and Numbers.
ICMP
(Internet Control Message Protocol) A network layer protocol that
provides for routing, reliability, flow control, and sequencing of data.
IEEE
(Institute of Electrical and Electronics Engineers) The standards
organization that is responsible for developing networking standards
relating to Ethernet, token bus, token ring, and metropolitan area
networks.
IGMP
Internet Group Management Protocol.
IGP
(Interior Gateway Protocol) The protocol that enables the exchange or
routing information between collaborating routers on the Internet.
Examples of IGPs include Routing Information Protocol (RIP) and Open
Shortest Path First (OSPF).
IP
(Internet Protocol) The basic protocol of the Internet. It enables the
unreliable delivery of individual packets from one host to another. The
IP does not determine whether the packet will be delivered, how long it
will take, or if multiple packets will arrive in the order they were sent.
Protocols built on top of this protocol add the functions of connection
and reliability.

Glossary/Acronyms Glossary-7
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
IP address
In Transmission Control Protocol/Internet Protocol (TCP/IP), a unique
32-bit number that identifies each host in a network.
IPG
Internet Gateway Protocol.
IPMP
Internet Protocol Messaging Protocol.
IP network number
The first octet or octets of an Internet Protocol (IP) address that uniquely
identify an IP network within an organization, and on the Internet, if
that network has been registered with the Internet governing
organization.
IPsec
Internet Protocol Security Architecture.
IPv4
(Internet Protocol version 4) One of two versions of IP addressing. It is a
32-bit addressing scheme currently used as the dominant scheme. An
IPv4 address is a unique number assigned to a host on a network. IPv4
addresses are 32 bits divided into four 8-bit fields. Each 8-bit field, or
octet, is represented by a decimal number between 0 and 255, separated
by periods; for example, 129.150.182.31.
IPv6
(Internet Protocol version 6) A new version designed to be an
evolutionary step from the current version, Internet Protocol version 4
(IPv4). IPv6 is an increment to IPv4. Deploying IPv6, using defined
transition mechanisms, does not disrupt current operations. In addition,
IPv6 provides a platform for new Internet functionality.
ISO
(International Organization for Standardization) An international
standards body that reviews and approves independently designed
products for use within specific industries. ISO also develops standards
for information exchange, such as the ISO/OSI model for computer
networks.
ISP
(Internet service provider) A company providing an Internet package.
This often includes a phone number access code, user name, and
software, all for a provider fee.

Glossary-8 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
J
JPEG
Joint Pictures Expert Group.
JPG
Joint Pictures Group.
JumpStart process
An automatic installation process available in a network environment
that enables system administrators to categorize machines and
automatically install systems based on the machine’s category.

K
kernel
The master program (core) of the Solaris Operating Environment. It
manages devices, memory, swap, processes, and daemons. The kernel
also controls the functions between the system programs and the system
hardware.

L
LAN
(local area network) A group of computer systems in close proximity
that can communicate by way of some connecting hardware and
software.
layer
One of a set of services, functions, and protocols that span all open
systems.

M
MAC
Media access control.
master server
The server that maintains the master copy of the network information
service database. It has a disk and a complete copy of the operating
system.
mirror
Disk mirroring is a feature that guards against component failure by
writing the same data to two or more disk drives at the same time.
MMF
Multimode fiber.

Glossary/Acronyms Glossary-9
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
MTU
(maximum transmission unit) An MTU is the largest amount of data
that can be transferred across a given physical network. The MTU is
hardware specific. For example, the MTU for a physical Ethernet
interface is 1500 bytes.
multicast address
One of three types of Ethernet address, the multicast address is used to
send a message to a subset of hosts on a network. In Ethernet multicast
addressing, the first three octets must contain a value of 01.00.5E. The
last three octets are used to assign host group identity.

N
name service
A name service provides a means of identifying and locating resources
(traditionally host names and Internet Protocol [IP] addresses) available
to a network. The default name service product available in the
Solaris 2.x Operating Environment is Network Information Service Plus
(NIS+).
NDP
Neighbor Discovery Protocol.
network
Technically, the hardware connecting various systems, enabling them to
communicate. Informally, the systems so connected.
network address
The address, consisting of up to 20 octets, used to locate an Open
Systems Interconnection (OSI) transport entity. The address is formatted
into an initial domain part that is standardized for each of several
addressing domains, and a domain-specific part that is the responsibility
of the addressing authority for that domain.
Network layer
In the International Standards Organization/Open Systems
Interconnection (ISO/OSI) model of network standards, the third layer,
which enables routing and switching blocks of data between two
devices that support Transport layer protocols over a connection.
network segment
In Integrated Services Digital Network (ISDN), when the TCP adds an
information header to a packet of data for decoding by the TCP on the
remote machine, the expanded packet is referred to as a segment. It is
then passed to the Network layer, which converts it to a datagram. It
then goes to the Data Link layer, which converts it to a frame.

Glossary-10 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
NFS
(Network File System) A file system distributed by Sun that provides
transparent access to remote file systems on heterogeneous networks.
NIC
Network interface card.
NIS
(Network Information Service) The Sun Operating System 4.0
(minimum) network information service. A distributed network
database containing key information about the systems and the users on
the network. The NIS database is stored on the master server and all the
slave servers. See also NIS+.
NIS+
(Network Information Service Plus) The Sun Operating System 5.0
(minimum) network information service. NIS+ replaces NIS, the Sun OS
4.0 (minimum) NIS.
NLA
Next level aggregator.
node
A node is an addressable point on a network. Each node in a Sun
network has a different name. A node can connect a computing system,
a terminal, or various other peripheral devices to the network.
NS
Name server.
NSCD
Name service cache daemon.
NTP
Network Time Protocol.
NVRAM
Nonvolatile random access memory.

O
OpenBoot PROM
OpenBoot programmable read-only memory.
OS
(operating system) A collection of programs that monitor the use of the
system and supervise the other programs executed by it.

Glossary/Acronyms Glossary-11
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
OSI
(Open Systems Interconnection) OSI is an international standardization
program that was developed to facilitate communications among
computers from different manufacturers.
OSPF
Open Shortest Path First.

P
PDU
Packet data unit.
peer-to-peer communication
The communications between peer devices.
Physical layer
In the International Standards Organization/Open Systems
Interconnection (ISO/OSI) model of network standards, the first layer,
which supplies the mechanical, electrical, and procedural means of
establishing, maintaining, and releasing physical connections.
PID
(process identification number) A unique, system-wide, identification
number assigned to a process. Also called process ID, process number.
PLM
Physical layer medium.
PPP
(Point-to-Point Protocol) A way to connect to the Internet; PPP also
provides error-checking features.
PROM
(programmable read-only memory) A permanent memory chip
programmed by the user rather than at the chip manufacturer, as is true
with a read-only memory (ROM). You need a PROM programmer or
burner to write data onto a PROM. PROM has been mostly replaced by
erasable programmable read-only memory (EPROM), a type of PROM
that can be erased by ultraviolet light and reprogrammed.
protocol
A way to transmit data between devices. A computer or device must
have a correct protocol to be able to communicate successfully with
other computers or devices.
PTR
DNS pointer record.

Glossary-12 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
R
RARP
(Reverse Address Resolution Protocol) RARP is an Internet Protocol that
maps a physical (hardware) address to an Internet address. Diskless
clients use RARP to find its Internet address at startup.
RDISC
Router discovery.
RFC
Request for Comment.
RIP
(Routing Information Protocol) RIP provides for automated distribution
of routing information between systems.
RPC
(remote procedure call) This is an easy and popular paradigm for
implementing the client-server model of distributed computing. A
request is sent to a remote system to execute a designated procedure,
using supplied arguments. The result is returned to the caller. There are
many variations of this, resulting in a variety of different RPC protocols.
run level
One of the eight initialization states in which a system can run. A
system can run in only one initialization state at a time. The default run
level for each system is specified in the /etc/inittab file.
run level 2
A multiuser mode without remote resources available. All daemons are
running except for remote file-sharing daemons.
run level S
A single-user mode in which the operating system is running, but all
users are logged out and most system processes, such as print and mail,
are not running. Only one user (the superuser) is logged in to the
system. Run level S is convenient for doing backups because, because no
users are logged in, all data is stable.

S
SLA
Site-level aggregator.

Glossary/Acronyms Glossary-13
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
slave server
A server system that maintains a copy of the Network Information
Service (NIS) database. It has a disk and a complete copy of the
operating system.
SLIP
(Serial-Line Internet Protocol) An Internet protocol used to run Internet
Protocol (IP) over serial lines such as telephone circuits or RS-232 cables
interconnecting two systems. The Point-to-Point Protocol (PPP) is the
preferred protocol.
SMF
Service Management Framework.
SNMP
(Simple Network Management Protocol) The network management of
choice for Transmission Control Protocol/Internet Protocol-based
(TCP/IP-based) Internets.
snoop
This command captures network packets and displays their contents.
The command can be run only by the superuser.
SOA
(start of authority) An SOA record marks the beginning of a zone’s
authority and defines parameters that affect an entire zone.
stateful
A type of data transfer where part of the data sent from the client to the
server includes the status of the client. Transmission Control Protocol
(TCP) is an example of a stateful protocol.
stateless
A type of data transfer where the server has no obligation to keep track
of the state of the client. User Datagram Protocol (UDP) is an example of
a stateless protocol.
subnetwork
A collection of International Standards Organization/Open Systems
Interconnection (ISO/OSI) end systems and intermediate systems under
the control of a single administrative domain and using a single
network access protocol; for example, private X.25 networks and a
collection of bridged LANs.

Glossary-14 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
T
TCP
(Transmission Control Protocol) A communications protocol that
ensures data is sent between computers on the Internet.
TCP/IP
(Transmission Control Protocol/Internet Protocol) An Internet protocol
that provides for the reliable delivery of data streams from one host to
another. SunOS networks run on TCP/IP by default. Also called Internet
Protocol suite. See also IP.
TLA
Top-level aggregator.
TP
Twisted pair.
TP-PLM
Twisted-pair physical layer medium.
Transport layer
In the International Standards Organization/Open Systems
Interconnection (ISO/OSI) model of network standards, the fourth layer,
which controls the transfer of data between session layer entities.
TTL
(time-to-live) Complete entries in the Address Resolution Protocol
(ARP) table have a TTL value and a period during which they are
considered to be valid entries (normally 30 minutes). TTL is also used in
Domain Name System (DNS) zone files.

U
UDP
(User Datagram Protocol) This protocol is a transport protocol in the
Internet suite of protocols. It uses Internet Protocol (IP) for delivery, and
provides for exchange of datagrams without acknowledgements or
guaranteed delivery.
UTC
Coordinated Universal Time. This is the official standard for current
time. Several institutions contribute their calculations of the current
time, and UTC is a combination of these estimates.
UTP
Unshielded twisted-pair.

W
WAN
(wide area network) WANs are slower-speed networks typically used by
organizations to connect their local area networks. WANs are often built
from leased telephone lines capable of moving data at speeds of
56 kilobits per second to 1.55 megabits per second. A WAN might be
used to bridge a company’s office on two opposite ends of town or on
opposite ends of a continent.

Glossary-16 Network Administration for the Solaris™ 10 Operating System

Numerics IPv6
anycast 8-6
1000BASE-CX media multicast 8-5
system 2-11 representation 8-6
1000BASE-LX media types 8-5
system 2-11 unicast 8-5
1000BASE-SX media link-local 8-6
system 2-11 loopback type 8-14
1000BASE-T media system 2-11 multicast 3-7, 5-11, 8-7
100BASE-FX media system 2-10 network number 5-9
100BASE-T4 media system 2-10 scope bits 8-16
100BASE-TX media system 2-9 site-local 8-6
10BASE-T media system 2-9 test 6-5
unicast 3-7, 5-9
unspecified type 8-14
A address-to-name
access list 10-27 translation 10-24, 10-25
access method, Ethernet 3-2 aggregatable global address 8-7,
addif option 5-27 8-12
address anycast address 8-6
aggregatable global 8-7 Application layer
broadcast 3-7, 5-11 common protocols 1-9
Class A 5-9 description 1-4, 1-8
Class B 5-10 formatting data 1-9
Class C 5-10 functions 1-9
classful 5-9 presenting data 1-9
define test 8-61 transporting data 1-9
detecting duplicates 8-10 ARP
embedded IPv4 8-13 adding entries from a file 4-6
Ethernet 3-6 adding permanent table
host number 5-9 entries 4-6
IP 5-9 adding table entries 4-6
IPv4 5-9 cache 4-4

Index-1
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
cache management 4-5 classful address 5-9
cache times 4-4 classless inter-domain routing. See CIDR
control table entries 4-5 CNAME record 10-23
deleting table entries 4-7 coaxial cable 2-8
description 1-13, 4-2 collision
display table entries 4-5 detection 3-2
Ethernet frame 4-2 rates 3-4
operation 4-2 collision rates 3-4
process 4-3 commands
removing static entries 4-7 banner 3-8
removing table entries 4-6 eeprom 3-8
searching for new cache entries 4-6 ndd 4-4
table entries 4-5 route 7-24
TCP/IP model 4-2 communication architecture 1-2
time to live 4-6 computers
arp utility 4-5 keeping time 12-2
ASCII 1-9 networking fundamentals 1-2
autonomous system 7-8 configuration errors file 10-35
configuring
default route 7-19
B DHCP
banner command 3-8 address 11-21 to 11-38
BASE 2-8 initial 11-9, 11-20
baseband 2-8 server 11-28
BIND 10-24 DHCP client 11-39
bridges 2-12 DNS
bridging devices 2-12 client 10-32
broadcast addresses 3-7, 5-11 dynamic routing 7-25
buffered transfer 9-11 interface for IPv6 8-20
bus configurations 2-2 IPMP
at boot time 8-68
manually 8-58
C IPv6
autoconfiguration 8-3, 8-8
capture network packets 3-14 interfaces 8-24
carrier sense 3-2 multipathing 8-58
carrier sense multiple access/collision name service lookup 8-21, 8-25
detection. See CSMA/CD on non-router 8-19
changing host name 5-23 router 8-24
CIDR logical interfaces 5-26, 8-36
block 7-35 multipathing 6-6, 6-21
operation 7-33 ndpd.conf file 8-25
purpose 7-33 NTP client 12-13
Class A address 5-9 NTP server 12-5
Class B address 5-10 router troubleshooting 7-42
Class C address 5-10 routing

Index-2 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
at boot time 7-38 network 7-17
without rebooting 7-40 network number 7-15
secondary DNS server 10-29 DHCP
static route 7-18 adding table entries 11-32
static route manually 7-21 address configuration 11-21, 11-38
stratum of a NTP server 12-8 client functions 11-3
troubleshooting routers 8-33 configuration file 11-7
connectionless communication 1-8 configuring
connection-oriented communication 1-8 client 11-39
connection-oriented protocol 9-3 servers 11-7, 11-28
connections, full-duplex and virtual creating tables 11-31
circuit 9-11 description 1-14
contiguous netmask 5-15 dhcptab table 11-34
contiguous subnet masks 5-15 functionality 11-2
CRC 1-5 fundamentals 11-2
creating DHCP tables 11-31 graphical manager 11-8
CSMA/CD initial configuration 11-9 to 11-20
Ethernet access method 3-2 managing tables 11-31
structure 3-3 server 10-26
cyclical redundancy check (CRC) 1-5 server functions 11-4
troubleshooting
clients 11-45
D dhcp_network file 11-30
daemons dhcpconfig utility 11-8, 11-28
/usr/sbin/in.routed 7-28 dhcpmgr utility 11-8
in.dhcpd 11-4 dhcptab table 11-34
in.mpathd 6-4, 6-18, 8-66 dhtadm utility 11-34
in.ndpd 8-18, 8-23 direct route 7-4
in.rarpd 4-9, 4-11 directory, /tftpboot 4-11
in.ripngd 8-24 discover routers 8-18
in.routed 7-20 diskless clients 4-9
xntpd 12-7 displaying
data communication 1-2 ARP data 4-4
data encapsulation 1-11, 4-2 ARP table entries 4-6
data format 1-2 IPv6 route table 8-36
data transfer 1-2 route table 7-12
datagram state of IPv6 interfaces 8-35
connectionless delivery of 5-3 distance-vector algorithms 7-11, 7-25
header fields 5-6 DNS
IP 5-6 access list 10-27
IP fields 5-6 allow-query BIND file 10-27
payload 5-8 allow-transfer BIND file 10-27
default route 7-6, 7-19 configuring server 10-29
define test address 8-61 configuring the client 10-32
destination description 1-14
IP address 7-15 dynamic updates 10-26

Index Index-3
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
restricting queries 10-28 Ethernet-II frames 3-10
reverse-domain file 10-24 Exterior Gateway Protocol (EGP) 7-10
security 10-27
server 10-25
troubleshooting the server 10-33 F
Domain Name System. See DNS failover 6-2
drift file 12-7 FAILURE_DETECTION_TIME variable 6-5
duplicate address detection 8-10 features of a protocol stack 1-3
Dynamic Host Configuration Protocol. File Transfer Protocol (FTP) 1-9, 1-14
See DHCP files
dynamic route 7-7 /etc/default/dhcp 11-7
dynamic routing, configuring 7-25 /etc/default/mpathd 6-3, 6-5, 6-18,
8-66
/etc/defaultrouter 7-6, 7-19
E /etc/ethers 4-11
EBCDIC 1-9 /etc/gateways 7-20
EEPROM 3-8 /etc/hostname.hme0 5-27
eeprom command 3-8 /etc/hostname.interface 5-22,
EGP 7-10 5-23
electrically erasable programmable /etc/inet/dhcpsvc.conf 11-7
read-only memory (EEPROM) 3-8 /etc/inet/hosts 3-17, 4-11, 5-23
embedded IPv4 address 8-13 /etc/inet/netmasks 5-18
enabling IPv6 8-18 /etc/inet/networks 7-16
Ethernet /etc/inet/ntp.conf 12-7, 12-11
access method 3-2 /etc/inet/ntp.server 12-5
address mapping 4-5 /etc/named.conf 10-27
addresses 3-6 /etc/net/hosts 5-22
ARP 4-2 /etc/netmask 5-18
changing the address 3-9 /etc/nodename 5-23
displaying the address 3-8 /etc/nsswitch.conf 4-11
displaying the state 3-4 /usr/include/netinet/ip_icmp.h
elements 3-2 5-4
frame header information 3-14 /var/adm/messages 10-35
frames 3-2, 3-6, 3-10 /var/ntp/ntp.drift 12-7
permanent change to address 3-9 dhcp_network 11-30
statistics 3-4 interface configuration 5-22
switches 2-13 ndpd.conf 8-25
topology 3-3 ntp.conf 12-8
viewing the address 3-8 one-backup 10-30
Ethernet frames one-rbackup 10-30
bad CRC 3-13 flow control 9-12
error conditions 3-13 flushing route table 7-23
giant 3-13 format prefix 8-6
jabbers 3-13 formatting data, Application layer
long 3-13 functions 1-9
runts 3-13 fragmentation 5-3

Index-4 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
frame check sequence 3-13 description 1-13
frames, Ethernet 3-2 error detection 1-7
framing packets 1-5 functions 5-3
FTP 1-9, 1-14 message types 5-4
fudge entry 12-8 message-type file 5-4
full-duplex purpose 5-3, 5-4
connection 9-11 redirect 7-31
transmission 3-4 routing data 1-7
full-duplex transmission 3-4 ICMPv6 group membership 8-17
function, \? 3-19 IEEE 802.3 standard 2-9, 3-2
IEEE identifiers 2-8
if_mpadm utility 6-28
G ifconfig utility
group membership 8-17 addif option 5-27
configuring logical interfaces 5-26
unconfiguring logical interfaces 5-28
H viewing the MTU of an interface 5-3
IGP 7-9
half-duplex transmission 3-4 IMAP4 1-14
hardware address 4-5 in.dhcpd daemon 11-4
header fields, IP 5-7 in.mpathd daemon
hme driver 3-18 failure detection 6-5
hme interfaces 3-19 multipath group 6-4
hme0 interface 3-19, 5-22 repair detection 6-5
hold-down state 7-26 starting 6-18, 8-66
hop count 7-25 in.ndpd daemon 8-18, 8-23
hop-count limit 7-26 in.rarpd daemon 4-9, 4-11
host alias 10-23 in.rdisc process 7-30
host name, changing 5-23 in.ripngd daemon 8-24
host nickname 10-23 in.routed daemon 7-20
host-based addressing media 3-6 incrementing interface number 5-27
host-based approach, Ethernet indirect route 7-4
addresses 3-6 initializing
HTTP 1-15 multihomed host 7-40
http 1-4, 12-9 non-router 7-41
hubs input errors, network system 3-5
intelligent 2-3 instance of hme interface 3-19
non-intelligent 2-3 instance parameter 3-19
shared 2-12 Institute of Electrical and Electronics
Hypertext Transfer Protocol (HTTP) 1-15 Engineers, Inc. (IEEE) identifiers 2-8
intelligent hubs 2-3
interface configuration files 5-22
I interface failure definition 6-5
IANA 5-9 interface identifier 8-8
ICMP interface identifier calculation 8-9
definition 5-3 interface repair definition 6-6

Index Index-5
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
interfaces authentication 8-4
hme 3-19 autoconfiguration 8-3, 8-8
hme0 3-19 configure on non-router 8-19
logical 5-24 configuring interfaces 8-20, 8-24
virtual 5-24 configuring multipathing 8-58
Internet Assigned Numbers Authority configuring name service lookup 8-21
(IANA) 5-9 displaying interfaces 8-35
Internet Control Message Protocol. See displaying route table 8-36
ICMP embedded IPv4 address 8-13
Internet Gateway Protocol (IGP) 7-9 enabling 8-18
Internet layer expanded addressing 8-4
description 1-4, 1-6 format prefix 8-6
functions 1-6 interface troubleshooting 8-36
ICMP 1-7 IPMP configuration 8-58
IP 1-7 link-local address 8-6
Internet Message Access Protocol managing 8-35
version 4 (IMAP4) 1-14 multicast address 8-5, 8-7
Internet Protocol. See IP name service lookup 8-25
IP privacy header 8-4
address mapping 4-5 RFC 8-3
address types 5-9 RIP 8-23
datagram 5-3, 5-6, 7-15 router configuration 8-24
datagram header fields 5-6 site-local address 8-6
datagram payload 5-8 stateful autoconfiguration 8-8
description 1-13 stateless autoconfiguration 8-8
fragmenting data 1-7 unicast address 8-5
header fields 5-7
ICMP 5-3
MTUs 5-3 J
purpose 5-3 JumpStart software
routing 7-3 clients 4-9
routing data 1-7
IPMP
configuring at boot time 8-68 L
features 6-3
manual configuration 8-58 LAN
requirements 6-4, 6-20 media 2-8
IPv4 network devices 2-12
address shortage 8-3 link speed 3-19
addresses 5-9 link-local address 8-6, 8-11
IPv6 link-state protocol 7-10
address representation 8-6 localhost entry 7-18
address shortage 8-3 local-mac-address? variable 3-8
address types 8-5 logical interfaces
aggregatable global address 8-7, 8-12 administering 5-24
anycast address 8-6 configuring 5-26, 8-36

Index-6 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
description 5-24 multihomed host 7-40
incrementing 5-27 multipath, viewing operation 6-28
removeif option 5-28 multipathing
unconfiguring 5-28 configuring 6-6, 6-21, 8-58
loopback address type 8-14 troubleshooting 6-30
loopback interface 3-12 multiple access 3-2

M N
MAC address name daemon control program (ndc) 10-45
banner command 3-8 name server 10-20
files 4-11 name service lookup 8-21, 8-25
ifconfig utility 3-8 name-service database 4-11
setting 3-8 names-to-IP addresses 10-21
viewing 3-8 ND 8-18
managing ndc utility 10-45
DHCP tables 11-31 ndd parameters 3-19
IPv6 8-35 ndd utility 3-18, 3-19, 3-20, 4-4
NTP daemons 12-10 ndpd.conf file 8-25
mappings to host names 10-21 Neighbor Discovery Protocol (ND) 8-18
maximum transfer unit. See MTU netmask
media access control address. See MAC contiguous 5-15
address definition 5-18
media systems file 5-18
1000BASE-CX 2-11 noncontiguous 5-15
1000BASE-LX 2-11 netstat utility
1000BASE-SX 2-11 displaying collisions 3-4
1000BASE-T 2-11 displaying Ethernet interfaces 3-17
100BASE - TX 2-9 field descriptions 3-17
100BASE-FX 2-10 -i option 3-17
100BASE-T4 2-10 input and output errors 3-5
10BASE-T 2-9 network devices
messages, ICMP 5-4 bridges 2-12
monitoring route table changes 7-22 LANs 2-12
MTU switches 2-12
data size 3-12 Network File System (NFS) 1-9
description 3-12 network interface card (NIC) 3-6, 6-2
fragmentation 5-3 Network Interface layer
Internet layer 5-3 description 1-4
maximum frame size 3-12 protocols
multicast address IEEE 802.4 1-6
description 3-7, 5-11 IEEE 802.5 1-6
format prefixes 8-7 PPP 1-12
IPv6 8-5 SLIP 1-12
purpose 8-15 TCP/IP 3-2
scope bits 8-16 network is unreachable 7-15

Index Index-7
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
network model query program 12-12
concepts 1-3 snoop utility 12-16
functions 1-3 terms 12-3
layered model 1-3 troubleshooting 12-15
layers 1-3 undisciplined local clock 12-7
rules 1-3 xntpdc utility 12-10
structure 1-3 ntp.conf file 12-8
network name 7-16, 7-44 ntpq utility 12-12
network number 5-18 NVRAM 3-6
network overload 3-5
network packets, capturing 3-14
network performance problems 3-4 O
network protocols 1-2 one-backup file 10-30
Network Time Protocol. See NTP one-rbackup file 10-30
network topologies output errors 3-5
and OSPF 7-10
bus configurations 2-2
describing 2-2 P
ring configurations 2-4
star configurations 2-3 packet data unit 1-5
NFS 1-9 parameters
NIC 3-6, 6-2 instance 3-19
no route to host 7-15 TRACK_INTERFACES_ONLY_WITH_
noncontiguous netmasks 5-15 GROUPS 8-66
noncontiguous subnet masks 5-15 path-vector algorithm 7-11
non-intelligent hubs 2-3 PDU 1-5
nonvolatile random access memory peer-to-peer
(NVRAM), Ethernet addresses 3-6 description 1-10
noripin directive 7-20 encapsulation 1-11
NS record 10-20, 10-21 physical network interface 5-25
nslookup utility 10-36 piggybacking 9-11
NTP pntadm utility 11-31
basic concepts 12-2 Point-to-Point Protocol (PPP) 1-12
configuration file parts 12-6 POP3 1-14
configuring a server 12-5 port-based address 3-8
configuring clients 12-13 port-based approach, Ethernet
configuring stratum of a NTP addresses 3-6
server 12-8 Post Office Protocol, version 3
configuring the stratum 12-8 (POP3) 1-14
external reference servers 12-9 PPP 1-12
fudge entry 12-8 prefix notation 8-13
functions 12-3 presenting data, Application layer
managing daemons 12-10 functions 1-9
multicast advertisement 12-8 process, in.rdisc 7-30
ntpg utility 12-12 programmable read-only memory
peers 12-12 (PROM) 4-10

Index-8 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
protocol stack features 1-3 retransmit message 9-6
protocol statistics 3-18 REVARP request 4-9
protocols Reverse Address Resolution Protocol. See
connection-oriented 9-3 RARP
EGP 7-10 reverse loopback 10-25
FTP 1-9, 1-14 reverse-domain file 10-24
functions 1-2 RFC
ICMP 5-3 documents 1-4
IGP 7-9 listings 1-4
IP 5-3 ring configurations 2-4
link-state 7-10 RIP 7-7, 8-23
NFS 1-9 root name server 10-20
RDISC 7-30 route command 7-24
reliable 9-6 route poisoning 7-27
SLIP 1-12 route table
SMTP 1-9 description 7-12
SNMP 1-9 display 7-12
SSH 1-9 fields 7-13
stack 1-2 flush 7-23
stateful 9-5 monitoring changes 7-22
stateless 9-5 netmask 7-23
TCP 9-2, 9-8 protocol 7-10
telnet 1-9 search order 7-14
Transport layer 9-2, 9-8 updates 7-6, 7-31
UDP 9-2, 9-8 router
unreliable 9-7 advertisement 8-19
configuration 8-24
discover 8-18
R troubleshooting 8-22
RARP Router Discovery (RDISC) Protocol 8-18
/etc/ethers files 4-11 routing
/etc/inet/hosts files 4-11 add route 7-24
description 1-13 advertisement 7-7
in.rarp daemon 4-11 autonomous system 7-8
operation 4-9 broadcast 7-28
performing a boot 4-10 configuring at boot time 7-38
PROM 4-10 configuring without rebooting 7-40
TCP/IP Internet layer protocol default 7-6, 7-19
description 1-13 direct 7-4
RDISC Protocol 7-30, 8-18 dynamic 7-7
reducing network traffic 9-11 fundamentals 7-3
reference clock 12-3 hold-down state 7-26
reliable protocol 9-6 hops 7-25
remote procedure call (RPC) 3-14 indirect 7-4
removeif option 5-28 initialization 7-38
Request for Comment. See RFC initializing non-router 7-41

Index Index-9
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
route poisoning 7-27 using 3-14
route table 7-6 verbose mode 3-14
split horizons 7-26 SOA record 10-22
static 7-6 speed matching 1-2
triggered updates 7-26 split horizons 7-26
troubleshooting 7-42 SSH 1-9
Routing Information Protocol (RIP) 7-7, standby interface 6-3
8-23 star configurations 2-3
RPC 3-14 stateful
RUNNING flag 6-5 autoconfiguration 8-8
protocol 9-5
stateless
S autoconfiguration 8-8
scope bits 8-16 protocol 9-5
scripts static routes
/etc/rc2.d/S69inet 4-11, 5-17, 6-18, configuring 7-18
7-7, 7-39, 8-29 configuring manual 7-21
/etc/rc2.d/S72inetsvc 5-17 definition 7-6
/etc/rcSd/S30network.sh 5-17, strata 12-3
6-18 stratum-1 server 12-3
secure shell 1-9 subnet address 5-21
security subnet masks
DNS 10-27 contiguous 5-15
restricting queries 10-28 noncontiguous 5-15
segment type 2-8 subnetting 5-12
self-contained messages 9-4 switches 2-12
semantics in network protocols 1-2 switching devices 2-12
sender side congestion window 9-12
sequencing 1-2
Serial Line Internet Protocol (SLIP) 1-12
T
servers TCP
DHCP configuration 11-7 congestion window 9-12
stratum 12-3 datagram header 9-10
Simple Mail Transfer Protocol description 1-13, 9-10
(SMTP) 1-9, 1-14 flow control 9-12
Simple Network Management Protocol header information 9-11
(SNMP) 1-9, 1-14 high-bandwidth network 9-13
site-local address 8-6, 8-12 large window 9-13
SLIP 1-12 network congestion 9-12
SMTP 1-9, 1-14 protocol 1-8, 9-2, 9-8
SNMP 1-9, 1-14 receiver-side window
snoop utility advertisements 9-12
capture network packets 3-14 reliability 1-8
NTP 12-16 satellite networks 9-13
reading the file 3-16 segment acknowledgement 9-12
summary mode 3-14 segments 1-8

Index-10 Network Administration for the Solaris™ 10 Operating System

Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
TCP/IP IPv6 interface 8-36
ARP 4-2 multipathing 6-30
common protocols 1-12 network names 7-44
model 1-1 non-router configuration 8-22
Network Interface layer 3-2 NTP 12-15
peer-to-peer communication 1-10 router configuration 7-42, 8-33
PPP 1-12 routing 7-42, 7-44
protocol stack 9-8 tools 3-17
protocols 1-12 twisted-pair 2-8
SLIP protocol 1-12
TCP/IP layer model
Application layer 1-4 U
common hardware platform 1-4 UDP
Internet layer 1-4 datagram header 9-9
Network Interface layer 1-4 datagrams 1-8
primary functions 1-5 description 1-13, 9-9
Transport layer 1-4 procedure call 3-14
telnet protocol 1-9, 1-14 protocol 9-2, 9-8
test address 6-5, 8-61 reliability 1-8, 9-9
time keeping 12-2 unconfiguring logical interfaces 5-28
time-to-live 10-20 undisciplined local clock 12-7
timing in network protocols 1-2 unicast addresses
TRACK_INTERFACES_ONLY_WITH_GROUPS description 3-7, 5-9, 8-5
parameter 8-66 types 8-11
transfer, buffered 9-11 unreliable protocol 9-7
transmission unspecified address type 8-14
full-duplex 3-4 unstructured stream orientation 9-11
half-duplex 3-4 User Datagram Protocol. See UDP
Transmission Control Protocol. See TCP utilities
Transmission Control Protocol/Internet arp 4-5
Protocol. See TCP/IP dhcpconfig 11-8, 11-28
Transport layer dhcpmgr 11-8
connectionless communication 1-8 dhtadm 11-34
connection-oriented if_mpadm 6-28
communication 1-8 ifconfig 5-3, 5-26
description 1-4, 1-7 ndc 10-45
error detection 9-8 ndd 3-18, 3-19, 3-20
fundamentals 9-2 netstat 3-4, 3-5
protocol 9-2, 9-8 nslookup 10-36
transport server 9-2 ntpg 12-12
transporting data, Application layer ntpq 12-12
functions 1-9 pntadm 11-31
triggered updates 7-26 snoop 3-14, 12-16
troubleshooting xntpdc 12-10
DHCP clients 11-45
DNS server 10-33

Index Index-11
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.1
V
variable length subnet mask (VLSM) 5-20
variables
FAILURE_DETECTION_TIME 6-5
local-mac-address? 3-8
virtual circuit connection 9-11
virtual interfaces 5-24
Virtual Local Area Network (VLAN) 2-5
VLAN 2-5
VLSM 5-20

W
web servers 10-24
window advertisement 9-12

X
xntpd daemon 12-7
xntpdc utility 12-10

Index-12 Network Administration for the Solaris™ 10 Operating System

CTS-D Certified Technology Specialist-Design Exam Guide
From Everand
CTS-D Certified Technology Specialist-Design Exam Guide
Brad Grimes
3.5/5 (3)
Thank You For Your Purchase: Huawei H12-821 - V1.0 Exam Question & Answers HCIP-Datacom-Core Technology V1.0 Exam
100% (1)
Thank You For Your Purchase: Huawei H12-821 - V1.0 Exam Question & Answers HCIP-Datacom-Core Technology V1.0 Exam
23 pages
Sun Cluster Training Guide
No ratings yet
Sun Cluster Training Guide
586 pages
Telecommunications Crash Course, Third Edition
From Everand
Telecommunications Crash Course, Third Edition
Steven Shepard
No ratings yet
Build Your Own Teams of Robots with LEGO® Mindstorms® NXT and Bluetooth®
From Everand
Build Your Own Teams of Robots with LEGO® Mindstorms® NXT and Bluetooth®
Cameron Hughes
No ratings yet
Actual4Test: Actual4test - Actual Test Exam Dumps-Pass For IT Exams
No ratings yet
Actual4Test: Actual4test - Actual Test Exam Dumps-Pass For IT Exams
14 pages
Sun Cluster 3.1 Administration ES-338
No ratings yet
Sun Cluster 3.1 Administration ES-338
540 pages
Solar Is Admin 2
No ratings yet
Solar Is Admin 2
790 pages
Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000
No ratings yet
Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000
456 pages
Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000
No ratings yet
Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000
456 pages
SCSA II Student Guide SA 299
No ratings yet
SCSA II Student Guide SA 299
860 pages
Sun Virtualization-Solaris Logical Domains Administration SA-345-S10
No ratings yet
Sun Virtualization-Solaris Logical Domains Administration SA-345-S10
134 pages
Dynamic Performance Tuning and Troubleshooting With DTrace SA 327 S10 New PDF
No ratings yet
Dynamic Performance Tuning and Troubleshooting With DTrace SA 327 S10 New PDF
274 pages
Dynamic Performance Tuning and Troubleshooting With DTrace (SA-327-S10) - New
No ratings yet
Dynamic Performance Tuning and Troubleshooting With DTrace (SA-327-S10) - New
274 pages
Solaris 10 For Experienced System Administrators Student Guide
No ratings yet
Solaris 10 For Experienced System Administrators Student Guide
434 pages
Veritas Volume Manager 1
100% (2)
Veritas Volume Manager 1
406 pages
820-5986 Deployment Example SAML v2 Using Sun OpenSSO Enterprise 80
No ratings yet
820-5986 Deployment Example SAML v2 Using Sun OpenSSO Enterprise 80
338 pages
Sun Cluster Concepts Guide For Solaris OS: Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A
No ratings yet
Sun Cluster Concepts Guide For Solaris OS: Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A
104 pages
Site Preparation Guide
No ratings yet
Site Preparation Guide
150 pages
820-3746 Deployment Planning Guide
No ratings yet
820-3746 Deployment Planning Guide
204 pages
820 6551
No ratings yet
820 6551
610 pages
Solaris 10 Jumpstart
No ratings yet
Solaris 10 Jumpstart
202 pages
ES445 Sun Cluster 3 2 Advanced Administration SG PDF
No ratings yet
ES445 Sun Cluster 3 2 Advanced Administration SG PDF
402 pages
ES445 - Sun Cluster 3.2 Advanced Administration - SG
No ratings yet
ES445 - Sun Cluster 3.2 Advanced Administration - SG
402 pages
Sun Glassfish Communications Server 2.0 Error Message Reference
No ratings yet
Sun Glassfish Communications Server 2.0 Error Message Reference
376 pages
Administration Guide
No ratings yet
Administration Guide
320 pages
Network Based Installation
No ratings yet
Network Based Installation
278 pages
SUN Cluster QuickGuide 819 0912
No ratings yet
SUN Cluster QuickGuide 819 0912
48 pages
819-2970 Sun Cluster
No ratings yet
819-2970 Sun Cluster
320 pages
820-5985 Deployment Example Single SignOn Load Balancing and Fail Over Using Sun OpenSSO Enterprise 80
No ratings yet
820-5985 Deployment Example Single SignOn Load Balancing and Fail Over Using Sun OpenSSO Enterprise 80
306 pages
SUN - Solaris 10 - System Administration Commands
No ratings yet
SUN - Solaris 10 - System Administration Commands
2,382 pages
Sun Java System Application Server Platform Edition 9 Administration Guide
No ratings yet
Sun Java System Application Server Platform Edition 9 Administration Guide
284 pages
Sun Cluster Software Installation Guide For Solaris OS
No ratings yet
Sun Cluster Software Installation Guide For Solaris OS
242 pages
Sun Glassfish Enterprise Server V2.1.1 Administration Guide
No ratings yet
Sun Glassfish Enterprise Server V2.1.1 Administration Guide
254 pages
Operations Management Capabilities Model: Sun Microsystems, Inc
No ratings yet
Operations Management Capabilities Model: Sun Microsystems, Inc
224 pages
820-3747 Performance Tuning Guide
100% (1)
820-3747 Performance Tuning Guide
34 pages
FMDPRM 1
No ratings yet
FMDPRM 1
204 pages
Glassfish 2.1 Tuning
No ratings yet
Glassfish 2.1 Tuning
128 pages
Ipmp Administration Guide Ip Services PDF
No ratings yet
Ipmp Administration Guide Ip Services PDF
924 pages
Sun Java System Message Queue 4.1 Administration Guide
No ratings yet
Sun Java System Message Queue 4.1 Administration Guide
402 pages
Sun Admiin Guide Ip Services
No ratings yet
Sun Admiin Guide Ip Services
822 pages
820-4807 Sun Directory Server Enterprise Edition 7.0 Installation Guide
No ratings yet
820-4807 Sun Directory Server Enterprise Edition 7.0 Installation Guide
72 pages
Flow Simulation Using SOLIDWORKS 2023
From Everand
Flow Simulation Using SOLIDWORKS 2023
Prof. Sham Tickoo
No ratings yet
Oracle JDeveloper 11g Handbook: A Guide to Fusion Web Development
From Everand
Oracle JDeveloper 11g Handbook: A Guide to Fusion Web Development
Duncan Mills
No ratings yet
Make Your Own PCBs with EAGLE: From Schematic Designs to Finished Boards
From Everand
Make Your Own PCBs with EAGLE: From Schematic Designs to Finished Boards
Simon Monk
4.5/5 (3)
Programming and Customizing the Multicore Propeller Microcontroller: The Official Guide
From Everand
Programming and Customizing the Multicore Propeller Microcontroller: The Official Guide
Parallax
3.5/5 (2)
How to Use the Snap-On SOLUS
From Everand
How to Use the Snap-On SOLUS
Mandy Concepcion
No ratings yet
Build Your Own Quadcopter: Power Up Your Designs with the Parallax Elev-8
From Everand
Build Your Own Quadcopter: Power Up Your Designs with the Parallax Elev-8
Donald Norris
No ratings yet
Programming with STM32: Getting Started with the Nucleo Board and C/C++
From Everand
Programming with STM32: Getting Started with the Nucleo Board and C/C++
Donald Norris
3.5/5 (3)
Understanding Performance Flight Testing: Kitplanes and Production Aircraft
From Everand
Understanding Performance Flight Testing: Kitplanes and Production Aircraft
Hubert C. Smith
5/5 (1)
Modern Intelligent Instruments - Theory and Application
From Everand
Modern Intelligent Instruments - Theory and Application
Changjian Deng
No ratings yet
Angular and Machine Learning Pocket Primer: A Comprehensive Guide to Angular and Integrating Machine Learning
From Everand
Angular and Machine Learning Pocket Primer: A Comprehensive Guide to Angular and Integrating Machine Learning
Mercury Learning and Information
No ratings yet
A DIY Smart Home Guide: Tools for Automating Your Home Monitoring and Security Using Arduino, ESP8266, and Android
From Everand
A DIY Smart Home Guide: Tools for Automating Your Home Monitoring and Security Using Arduino, ESP8266, and Android
Robert Chin
No ratings yet
Programming the Intel Edison: Getting Started with Processing and Python
From Everand
Programming the Intel Edison: Getting Started with Processing and Python
Donald Norris
1/5 (1)
Arduino Projects for Amateur Radio
From Everand
Arduino Projects for Amateur Radio
Jack Purdum
5/5 (1)
Video Data Analytics for Smart City Applications: Methods and Trends
From Everand
Video Data Analytics for Smart City Applications: Methods and Trends
PublishDrive
No ratings yet
Angular and Deep Learning Pocket Primer: A Comprehensive Guide to AI and Expert Systems for Professionals
From Everand
Angular and Deep Learning Pocket Primer: A Comprehensive Guide to AI and Expert Systems for Professionals
Mercury Learning and Information
No ratings yet
Digital Innovation Adoption: Architectural Recommendations and Security Solutions
From Everand
Digital Innovation Adoption: Architectural Recommendations and Security Solutions
Muhammad Ehsan Rana
No ratings yet
OCA Oracle Database 11g Administration I Exam Guide (Exam 1Z0-052)
From Everand
OCA Oracle Database 11g Administration I Exam Guide (Exam 1Z0-052)
John Watson
No ratings yet
Advances in Manufacturing Technologies and Production Engineering
From Everand
Advances in Manufacturing Technologies and Production Engineering
PublishDrive
No ratings yet
SOA-Based Enterprise Integration: A Step-by-Step Guide to Services-based Application
From Everand
SOA-Based Enterprise Integration: A Step-by-Step Guide to Services-based Application
Waseem Roshen
No ratings yet
New Age Cyber Threat Mitigation for Cloud Computing Networks
From Everand
New Age Cyber Threat Mitigation for Cloud Computing Networks
Akashdeep Bhardwaj
No ratings yet
First Hop Redundancy Protocol (HSRP) - : HSRP Election Process (Bydefault)
No ratings yet
First Hop Redundancy Protocol (HSRP) - : HSRP Election Process (Bydefault)
24 pages
NETWORK LAYER_ IP Addressing (2)
No ratings yet
NETWORK LAYER_ IP Addressing (2)
41 pages
CCNA 4 Final Exam Answers (D)
No ratings yet
CCNA 4 Final Exam Answers (D)
11 pages
How To Configure IPSec VPN
No ratings yet
How To Configure IPSec VPN
6 pages
ExampleGuide-ActiveDNS
No ratings yet
ExampleGuide-ActiveDNS
17 pages
HA PaloAlto
No ratings yet
HA PaloAlto
26 pages
Routing Algorithms
0% (1)
Routing Algorithms
36 pages
Brkaci 3101 PDF
No ratings yet
Brkaci 3101 PDF
176 pages
Azure Virtual Network
No ratings yet
Azure Virtual Network
11 pages
HP 1910-CMW520-R1513P51 Release Notes (Software Feature Changes)
No ratings yet
HP 1910-CMW520-R1513P51 Release Notes (Software Feature Changes)
28 pages
Net Lec 5
No ratings yet
Net Lec 5
98 pages
MPLS Forwarding Commands PDF
No ratings yet
MPLS Forwarding Commands PDF
56 pages
Inicia Configuración Del Equipo: MG6004ET
No ratings yet
Inicia Configuración Del Equipo: MG6004ET
6 pages
Polytechnic University of The Philippines College of Engineering Computer Engineering Department
No ratings yet
Polytechnic University of The Philippines College of Engineering Computer Engineering Department
13 pages
CCNA Exploration 1: Network Fundamentals v4.0 - Final Exam Answers - Full - 2013-2014
No ratings yet
CCNA Exploration 1: Network Fundamentals v4.0 - Final Exam Answers - Full - 2013-2014
53 pages
Curriculum Vitae Tole Mueez: Career Objective
No ratings yet
Curriculum Vitae Tole Mueez: Career Objective
5 pages
Nse4 6
No ratings yet
Nse4 6
27 pages
LP-1521 Wideband Router 123 Manual L VPN Configuration Between Two LP-1521's With Dynamic IP
No ratings yet
LP-1521 Wideband Router 123 Manual L VPN Configuration Between Two LP-1521's With Dynamic IP
10 pages
BGP Route Distinguisher Vs Route Target
No ratings yet
BGP Route Distinguisher Vs Route Target
2 pages
Enarsi Chapter 14
No ratings yet
Enarsi Chapter 14
57 pages
Which Three Addresses Belong To The Category of Private IP Addresses
No ratings yet
Which Three Addresses Belong To The Category of Private IP Addresses
20 pages
IP Traffic Management With Access Control List Using Cisco Packet Tracer
No ratings yet
IP Traffic Management With Access Control List Using Cisco Packet Tracer
7 pages
Dumps: Torrent
No ratings yet
Dumps: Torrent
6 pages
CCNA 200-301 Syllabus
100% (1)
CCNA 200-301 Syllabus
6 pages
Shortest Path Forwarding Using OpenFlow PDF
No ratings yet
Shortest Path Forwarding Using OpenFlow PDF
58 pages
Why Can't I Browse The Internet When Using A GRE Tunnel
No ratings yet
Why Can't I Browse The Internet When Using A GRE Tunnel
4 pages
Ex - No: 1 Study of Basic Network Commands
No ratings yet
Ex - No: 1 Study of Basic Network Commands
6 pages
Examen BGP 6.0
No ratings yet
Examen BGP 6.0
9 pages