Solaris Networking

Solaris 10 Static IP Network configuration guide

This is pretty simple task. Although some find it difficult because it is different from other Linux distributions.

To configure Solaris 10 network interface in Local files mode, you must first remove the file /etc/dhcp.interface (for ex. /etc/dhcp.e1000g0), then you have to configure six files.

/etc/nodename
/etc/hostname.interface
/etc/inet/hosts
/etc/inet/ipnodes
/etc/defaultdomain
/etc/defaultrouter

In /etc/nodename, you must specify your name of the server/host.
Ex.

#cat /etc/nodename
solarisbox1

The interface names in solaris include ce, hme, bge, e1000g etc. So, if you have an interface called e1000g0 there should be a file named /etc/hostname.e1000g0 In this file, you must specify network configuration information such as IP address, netmask etc.
Ex.

#cat /etc/hostname.e1000g0
10.91.10.5 netmask 255.255.255.0
#cat /etc/hostname.qfe0
192.168.0.88 netmask 255.255.255.0

The /etc/inet/hosts file serves as local file name resolver. It resolves hostnames, log hosts etc. You can specify any number of hosts associted with IP addresses in it. You must specify hostname of you system in it.
Ex.

#cat /etc/inet/hosts
#
# Internet host table
#
::1 localhost
127.0.0.1 localhost loghost solarisbox1
10.91.10.5 solarisbox1
192.168.0.88 solarisbox1
10.91.10.6 solarisbox2

For Solaris 10 11/06 and earlier releases, you must keep /etc/inet/ipnodes updated.
Ex.

# vi /etc/inet/ipnodes
10.0.0.14 myhost

The /etc/defaultdomain file specifies nothing other than FQDN (Fully Qualified Domain Name) of the System.
Ex.

#cat /etc/defaultdomain
solarisbox1.solarisstudy.com

The /etc/defaultrouter file specifies your default router (or gateway) details.
Ex.

#touch /etc/defaultrouter
#echo 10.91.10.1 >> /etc/defaultrouter

Read more at http://kaustubhghanekar.blogspot.com/2012/05/configuring-static-network.html#FoEkmktRXdoeI8V3.99
==================================================================================
Solaris network configuration

News See Also Recommended Links Administering Logical Network Interfaces Quiz Default Router Troubleshooting Solaris Network Problems Solaris Snoop Packet Sniffer
Solaris Multipathing Solaris ndd Solaris getent Command Solaris Network Certification Solaris route command netstat Humor Etc
Lecture Notes from my FDU class (largely based on Sun Solaris Student Guide materials and O’Reilly books).

Summary

Introduction

MAC Address

IP Address

Changing status of an Ethernet Interfaces (UP/Down)

Capturing Network Traffic

Configuring Network Interfaces

Changing the Hostname

The sys-unconfig Command

Summary

Two methods of getting MAC address:

Using ifconfig -a command
Getting MAC address from boot prompt: ok banner
Test question: Which three statements identify information which is displayed by the ifconfig -a command? (Choose three.)

Ping

ping command can be used to check and display network connectivity. To use ping the following five conditions must be met:

The interface must be plumbed.
The interface must be configured.
The interface must be up.
The interface must be physically connected.
The interface must have valid routes configured.
Changing the hostname

On Solaris the hostname of a system is contained in (at least) six files, which all need to be changed to change the host name of the system ( there can be multiple /etc/hostname.xxn files; one for each networking interface):

/etc/nodename
All /etc/hostname.xxn files (can be more then one)
/etc/inet/hosts
Three /etc/net/tic* files:
/etc/net/ticlts/hosts
/etc/net/ticots/hosts
/etc/net/ticotsord/hosts
Snoop

Snoop can be used for monitoring network traffic. It switches interface into promiscuous mode. Most important options include:

snoop Summary output
snoop -v Detailed verbose output
snoop -V Summary verbose output (negation of -v)
snoop -o filename Redirects the snoop utility output to filename in summary mode
snoop -i filename Displays packets that were previously captured in filename
snoop -a service To turn on audible clicks for network traffic, for example snoop -a dhcp
Note: Press Control-C to stop the snoop utility. For more information see Solaris Snoop Packet Sniffer

The purpose of this lecture is to give you some understanding of how to set up Solaris network interfaces using the command-line interface. Also included are some basic troubleshooting hints.

The network interfaces that a system uses to communicate with other systems on the network use both hardware and software configuration components. When adding a network interface to a system, you must configure specific files to establish a relationship between the hardware and the software addresses.

Introduction

Sysadmin needs to be able:

To use the ifconfig command,
To use the ping command,
To use the snoop command,
Control and monitor the functionality of network interfaces,
Display MAC address and IP address, netmask, and routing table
Configure interfaces at boot time.
In order to enable a network interface under Solaris, several steps may be necessary. These include:

Assigning an IP address to the interface
Deciding whether the interface acts as a router component or as a component of a multi-homed host
Creating a hosts entry that maps the IP address to a hostname
Configuring and plumbing the interface for passing traffic
An IP address is for each interface is stored in the hostname file, located in the /etc directory. For a system with a single interface (e.g., /dev/bge0), there is one such file. If system has multiple interfaces there are as many files as there are actve interfaces. For example a quad ethernet card (with devices /dev/qfe0, /dev/qfe1, /dev/qfe2, and /dev/qfe3) would have four hostname files containing distinct IP addresses: hostname.qfe0, hostname.qfe1, hostname.qfe2, and hostname.qfe3.

A mulit-homed host allows data to be exchanged only on the local area network (including with the router defined for that network), while a router is responsible for conveying packets between networks. To prevent routing, a multi-homed host must touch the file /etc/notrouter. In addition, the default router for the local network should have its IP address inserted into the file /etc/defaultrouter.

You can create a hosts entry for each interface in the /etc/hosts file or by inserting a record into whatever distributed naming service is mandated by /etc/nsswitch.conf. For example, if the IP address contained in hostname.qfe0, hostname.qfe1, hostname.qfe2, and hostname.qfe3 were to be mapped to the hostnames www1, www2, www3, and www4, the /etc/hosts file would contain the following entries:

# cat /etc/hosts
www1 192.64.18.1
www2 192.64.18.2
www3 192.64.18.3
www4 192.64.18.4
Alternatively, if DNS is being used (as shown in Chapter 5), the following entries would need to be made in the appropriate zone file:

www1 IN A 192.64.18.1 ;webserver
www2 IN A 192.64.18.2 ;webserver
www3 IN A 192.64.18.3 ;webserver
www4 IN A 192.64.18.4 ;webserver
Each interface needs to be plumbed before it can pass and receive IP traffic. Once the device is plumbed, its runtime parameters, such as its IP address, can also be configured by using the ifconfig command:

# /usr/sbin/ifconfig hme0 10.64.18.3 broadcast 10.64.18.255 netmask 255.255.

255.0
To bring up the interface, the up keyword must be used:

# /usr/sbin/ifconfig hme0 up
All of these individual commands can be combined into the following command, which configures the hardware, sets all parameters, and brings up the interface:

# /usr/sbin/ifconfig hme0 10.64.18.3 broadcast 10.64.18.255 netmask 255.255.255.0 plumb up
In order to determine whether the interfaces are being addressed correctly by other hosts on the local network, use the arp command to display all active connections between the localhost and other hosts:

# /usr/sbin/arp -a

Net to Media Table: IPv4
Device IP Address Mask Flags Phys Addr
—— ——————– ————— —– —————
hme0 hp 255.255.255.255 00:50:ba:13:08:18
hme0 austin 255.255.255.255 SP 00:03:ba:04:a4:e8
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
This displays the ethernet address to IP address mapping for the local host. The flags displayed include:

Once the interface has been enabled, the ifconfig command can be used to view all active interfaces:

# /usr/sbin/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 10.64.18.3 netmask ffffff00 broadcast 10.64.18.255
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
inet6 fe80::203:baff:fe04:a4e8/10
Obtaining Ethernet Card(s) MAC Address

The media access control (MAC) address is your computer’s unique hardware address on a local area network (LAN). The MAC address is also the Ethernet address on an Ethernet LAN. When you are connected to a LAN, an address resolution table maps your computer’s physical MAC address to an Internet Protocol (IP) address on the LAN. Two ways to display the MAC address or the Ethernet address are:

Use the ifconfig -a command
Use the boot programmable read-only memory (PROM) banner command
Note – The MAC address is displayed only if the root user issues the ifconfig command. Only the IP address information is displayed if a non-root user issues the ifconfig command.

You can also retrieve the MAC address from a system that has not yet been booted by performing the banner command at the ok prompt:

ok banner

IP Address

The ifconfig command displays the current configuration for one of all network (he -a option) interfaces.

Changing status on an Ethernet Interface(Up/Down)

When an Ethernet interface is marked as down, it means that it cannot communicate. You can use the ifconfig command to change status of the interface: mark it up or down. For example, to mark the hme0 interface as down use the commands:

# ifconfig hme0 down && ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.30.41 netmask ffffff00 broadcast 192.168.30.255
ether 8:0:20:93:c9:af

Note – After to take interface down UP flag should no longer be present. When an interface is flagged as UP, it is ready to communicate.

When you mark an interface as up, the UP status appears in the flags field of the ifconfig command output:

# ifconfig hme0 up
# ifconfig -a
lo0: flags=1000849<UP…

The following conditions must be satisfied: for the ping command to succeed in solaris environment:

The interface must be plumbed.
The interface must be configured.
The interface must be up.
The interface must be physically connected.
The interface must have valid routes configured.
Capturing Network Traffic

Snoop utility can capture network packets. This utility is similar to tcpdump and output formats are almost identical. You can use the snoop utility to see what happens when one system tries to communicate with another system. For example the command to view network traffic between two specific systems alpha and beta is:

# snoop alpha, beta

Snoop options include:

snoop Summary output
snoop -v Detailed verbose output
snoop -V Summary verbose output (negation of -v)
snoop -o filename Redirects the snoop utility output to filename in summary mode
snoop -i filename Displays packets that were previously captured in filename
Note – Press Control-C to stop the snoop utility.
Note: Use the -a option to enable audible clicks, which notify you of any network traffic. Although noisy, the clicks are useful when troubleshooting, for example: snoop -a dhcp

Configuring Network Interfaces

Network interfaces in Solaris are controlled by three files:

The /etc/rcS.d/S30network.sh file
The /etc/hostname.xxnfile
The /etc/inet/hosts file
The /etc/rcS.d/S30network.sh File

The /etc/rcS.d/S30network.sh file is one of the startup scripts. The script searches for files called hostname.xxn in the /etc directory, where xx is an interface type and n is the instance of the interface. For every file named /etc/hostname.xxn, the script uses the ifconfig command with the plumb option to make the kernel ready to talk to this type of interface. The script then configures the named interface with an IP address and other required network information.. For example /etc/hostname.hme0 is a file used to configure hme0 interface.

Note: The /etc/rcS.d/S30network.sh file first appeared in the Solaris 8.

The /etc/hostname.xxn File

The /etc/hostname.xxn file contains an entry for the configuration of a corresponding interface. The xxn component of the file name is replaced by an interface type and a number that differentiates between multiple interfaces of the same type present in the system. For example:

/etc/hostname.le0 First le Ethernet interface in the system
/etc/hostname.hme0 First hme Ethernet interface in the system
/etc/hostname.hme1 Second hme Ethernet interface in the system
/etc/hostname.qfe0 First qfe Ethernet interface in the system
The xx codes for the interface types are product codes. For example, the le code is an abbreviation of the Lance Ethernet, and the qfe code is an abbreviation for Quadfast Ethernet.

The /etc/hostname.hme0 file should contain either the host name or the IP address of the system that contains the hme0 interface. The host name contained in the file must exist in the /etc/hosts file so that it can be resolved to an IP address at system boot time. You can edit the /etc/hostname.hme0 file to contain either the host name or the IP address from the /etc/hosts file, for example:

# cat /etc/hostname.hme0
192.168.1.1

The /etc/inet/hosts File

The /etc/inet/hosts file is a local database that associates the IP addresses of hosts with their names. You can use the /etc/inet/hosts file with, or instead of, other hosts databases, including the Domain Name System (DNS), the Network Information Service (NIS) hosts map, and the Network Information Service Plus (NIS+) hosts table. Programs use library interfaces to access information in the /etc/inet/hosts file.

The /etc/inet/hosts file contains at least the loopback and host information. The file has one entry for each IP address of each host. If a host has more than one IP address, this file will have one entry for each address, on separate lines. The format of each line is:

IP-address official-host-name [nicknames] . . .

Items are separated by any number of space or tab characters. The first item on a line is the host’s IP address. The second entry is the host’s official name. Subsequent entries on the same line are alternative names for the same machine, or nicknames. Nicknames are optional. For a host with more than one IP address, consecutive entries for these
addresses will contain different host names.

# cat /etc/inet/hosts
.
< output truncated>
.
127.0.0.1 localhost
.
< output truncated>

Note – The /etc/inet/hosts file is the official POSIX location of the hosts file. The symbolic link /etc/hosts exists for Berkeley Software Distribution (BSD) compatibility.

Changing the Hostname

You must modify following files to successfully change a system’s hostname:

The /etc/nodename file
All the /etc/hostname.xxn file
The /etc/inet/hosts file
The /etc/net/ticlts/hosts file
The /etc/net/ticots/hosts file
The /etc/net/ticotsord/hosts file
Editing the /etc/nodename File. Each Solaris OE has a canonical name, which is the official name used when referring to a system. By convention, the system name is the same as the host name associated with the IP address of the primary network interface; for example, hostname.hme0. The following example shows a system’s /etc/nodename file:

# cat /etc/nodename

You can change the canonical name by editing the /etc/nodename file, and rebooting the system. If the machine’s network configuration is managed remotely and delivered by the DHCP or remote procedure calls (RPC) bootparams protocols, the /etc/nodename file is not used. The file is not used because the remote service delivers the canonical name.

Editing the /etc/hostname.xxn File. The /etc/hostname.xxn file contains either the host name or the IP address of the system that contains the named interface.

Editing the /etc/inet/hosts File. Network addresses are written in the conventional decimal-dot notation. Host names are text strings up to 24 characters. Alphabetic characters, numbers, the minus sign, and a period are allowed in the host name. Periods are only allowed when they serve to delimit components of domain style names. Blanks and spaces are not allowed in the host name. No distinction is made between uppercase and lowercase characters. The first character must be an alphabetic character. The last character can’t be a minus sign (-) or a dot (.). This file accept regular shell style comments starting with a pound sign (#). All characters after #, up to the end of the line, are not interpreted.

Editing the Three Transport Layer Independent (TLI) Files. The /etc/net directory contains three subdirectories: /etc/net/ticlts, /etc/net/ticots, and /etc/net/ticotsord. Each of these directories contains a hosts file. These files contain configuration information for transport-independent network services. If these files become corrupted, unpredictable results can occur when trying to resolve the system host name when using network services. In addition, when you execute the /usr/sbin/sys-unconfig command, the system deletes all of the hosts files. If the files get corrupted or deleted, you can use any editor to restore them. The format of the file is:

hostname hostname

The sys-unconfig Command

/usr/sbin/sys-unconfig command can be used to undo a Solaris system configuration. It restores a system’s configuration to an “as-manufactured” state. The system’s configuration includes a host name, NIS domain name, time zone, IP address, IP subnet mask, and root password. The sys-unconfig command does the following:

Saves the current /etc/inet/hosts file information in the /etc/inet/hosts.saved file.
If the current /etc/vfstab file contains Network File System (NFS) mount entries, it saves the /etc/vfstab file to the /etc/vfstab.orig file.
Restores the default /etc/inet/hosts file.
Removes the default host name in the /etc/hostname.xxnfiles for all configured interfaces.
Removes the default domain name in the /etc/defaultdomain file.
Restores the time zone to PST8PDT in the /etc/TIMEZONE file.
Resets naming services to local files.
Removes the entries for this host in the /etc/net/tic*/hosts file.
Removes the /etc/inet/netmasks file.
Removes the /etc/defaultrouter file for naming services.
Removes the password set for the root user in the /etc/shadow file.
Removes the /etc/.rootkey file for NIS+.
Executes all system configuration applications. These applications are defined by prior executions of a sysidconfig -a command.
Removes the /etc/resolv.conf file for DNS.
Disables Lightweight Directory Access Protocol (LDAP) by removing:
The /var/ldap/ldap_client_cache file
The /var/ldap/ldap_client_file file
The /var/ldap/ldap_client_cred file
The /var/ldap/cachemgr.log file
When the sys-unconfig command is finished, it performs a system shutdown. The sys-unconfig command is a potentially dangerous utility and can only be run by the root user.

When you restart the system, a configuration scripts prompts you to configure the system information. The sys-unconfig command is not available on diskless clients.

P Published address
S Static address
U Unresolved address
M Mapping address for multicast
Finally, it may be necessary to set some protocol transmission parameters manually to achieve optimal performance. Use the ndd command to set parameters for TCP, UDP, ARP, and IP. In addition, ndd can be used to display the list of all current parameter values relating to a specific protocol. For example, to display the parameters currently associated with TCP, use the following command:

# ndd /dev/tcp \?
? (read only)
tcp_close_wait_interval (read and write)
tcp_conn_req_max_q (read and write)
tcp_conn_req_max_q0 (read and write)
tcp_conn_req_min (read and write)
tcp_conn_grace_period (read and write)
tcp_cwnd_max (read and write)
tcp_debug (read and write)
tcp_smallest_nonpriv_port (read and write)
tcp_ip_abort_cinterval (read and write)
tcp_ip_abort_linterval (read and write)
tcp_ip_abort_interval (read and write)
tcp_ip_notify_cinterval (read and write)
tcp_ip_notify_interval (read and write)
tcp_ip_ttl (read and write)
tcp_keepalive_interval (read and write)
tcp_maxpsz_multiplier (read and write)
tcp_mss_def (read and write)
tcp_mss_max (read and write)
tcp_mss_min (read and write)
tcp_naglim_def (read and write)
tcp_rexmit_interval_initial (read and write)
tcp_rexmit_interval_max (read and write)
tcp_rexmit_interval_min (read and write)
tcp_wroff_xtra (read and write)
tcp_deferred_ack_interval (read and write)
tcp_snd_lowat_fraction (read and write)
tcp_sth_rcv_hiwat (read and write)
tcp_sth_rcv_lowat (read and write)
tcp_dupack_fast_retransmit (read and write)
tcp_ignore_path_mtu (read and write)
tcp_rcv_push_wait (read and write)
tcp_smallest_anon_port (read and write)
tcp_largest_anon_port (read and write)
tcp_xmit_hiwat (read and write)
tcp_xmit_lowat (read and write)
tcp_recv_hiwat (read and write)
tcp_recv_hiwat_minmss (read and write)
tcp_fin_wait_2_flush_interval (read and write)
tcp_co_min (read and write)
tcp_max_buf (read and write)
tcp_zero_win_probesize (read and write)
tcp_strong_iss (read and write)
tcp_rtt_updates (read and write)
tcp_wscale_always (read and write)
tcp_tstamp_always (read and write)
tcp_tstamp_if_wscale (read and write)
tcp_rexmit_interval_extra (read and write)
tcp_deferred_acks_max (read and write)
tcp_slow_start_after_idle (read and write)
tcp_slow_start_initial (read and write)
tcp_co_timer_interval (read and write)
tcp_extra_priv_ports (read only)
tcp_extra_priv_ports_add (write only)
tcp_extra_priv_ports_del (write only)
tcp_status (read only)
tcp_bind_hash (read only)
tcp_listen_hash (read only)
tcp_conn_hash (read only)
tcp_queue_hash (read only)
tcp_host_param (read and write)
tcp_1948_phrase (write only)
Obtaining Network Statistics

Once all network interfaces are configured as required, use the netstat command, which is responsible for gathering network statistics of various types, to verify their operational status. This data is gathered by using the interfaces on the local host.

netstat is able to gather statistics for the following types of data:

Data grouped by protocol type
Device statistics grouped by address type, including IPv4, IPv6, and Unix addresses
DHCP data
Interface data grouped by multicast
Routing table details (including multicast)
STREAMS data
The state of all available IP interfaces
The state of all active sockets, routes, physical interfaces, and logical interfaces
In the following sections, we’ll review each of these data gathering operations and discuss how each is used to aid in troubleshooting and pinpointing performance issues.

Protocol Statistics

The per-protocol statistics can be divided into several categories:

RAWIP (raw IP) packets
TCP packets
IPv4 packets
ICMPv4 packets
IPv6 packets
ICMPv6 packets
UDP packets
IGMP packets
Each packet type has a specific set of measures associated with it. For example, RAWIP packets have counters that check the number of input (rawipInDatagrams) and output (rawipOutDatagrams) datagrams received since boot. UDP has a corrsponding set of counters that measure the number of input (udpInDatagrams) and output (udpOutDatagrams) datagrams received since boot. In addition to counters of normal events, netstat reports on error events, such as the number of UDP input (udpInErrors) and the number of UDP output (udpOutErrors) errors. These values should be monitored regularly to ensure that the ratio of error to normal conditions does not increase over time. For example, there are 293 tcpActiveOpens shown in the following listing, compared to only one tcpAttemptFails event. If the ratio of tcpAttemptFails to tcpActiveOpens increases over time for TCP traffic, the appropriate TCP parameters may need to be modified by using ndd, or a network error may need to be diagnosed. Here’s a representative set of examples for understanding per-protocol errors for IPv6.

$ netstat -s

IPv6 ipv6Forwarding = 2 ipv6DefaultHopLimit = 255
ipv6InReceives = 0 ipv6InHdrErrors = 0
ipv6InTooBigErrors = 0 ipv6InNoRoutes = 0
ipv6InAddrErrors = 0 ipv6InUnknownProtos = 0
ipv6InTruncatedPkts = 0 ipv6InDiscards = 0
ipv6InDelivers = 25 ipv6OutForwDatagrams= 0
ipv6OutRequests = 42 ipv6OutDiscards = 2
ipv6OutNoRoutes = 0 ipv6OutFragOKs = 0
ipv6OutFragFails = 0 ipv6OutFragCreates = 0
ipv6ReasmReqds = 0 ipv6ReasmOKs = 0
ipv6ReasmFails = 0 ipv6InMcastPkts = 0
ipv6OutMcastPkts = 14 ipv6ReasmDuplicates = 0
ipv6ReasmPartDups = 0 ipv6ForwProhibits = 0
udpInCksumErrs = 0 udpInOverflows = 0
rawipInOverflows = 0 ipv6InIPv4 = 0
ipv6OutIPv4 = 0 ipv6OutSwitchIPv4 = 0

ICMPv6 icmp6InMsgs = 0 icmp6InErrors = 0
icmp6InDestUnreachs = 0 icmp6InAdminProhibs = 0
icmp6InTimeExcds = 0 icmp6InParmProblems = 0
icmp6InPktTooBigs = 0 icmp6InEchos = 0
icmp6InEchoReplies = 0 icmp6InRouterSols = 0
icmp6InRouterAds = 0 icmp6InNeighborSols = 0
icmp6InNeighborAds = 0 icmp6InRedirects = 0
icmp6InBadRedirects = 0 icmp6InGroupQueries = 0
icmp6InGroupResps = 0 icmp6InGroupReds = 0
icmp6InOverflows = 0
icmp6OutMsgs = 8 icmp6OutErrors = 0
icmp6OutDestUnreachs= 0 icmp6OutAdminProhibs= 0
icmp6OutTimeExcds = 0 icmp6OutParmProblems= 0
icmp6OutPktTooBigs = 0 icmp6OutEchos = 0
icmp6OutEchoReplies = 0 icmp6OutRouterSols = 3
icmp6OutRouterAds = 0 icmp6OutNeighborSols= 1
icmp6OutNeighborAds = 0 icmp6OutRedirects = 0
icmp6OutGroupQueries= 0 icmp6OutGroupResps = 4
icmp6OutGroupReds = 0
Address Type Statistics

The per-address statistics can be divided into three categories:

inet (AF_INET)
inet6 (AF_INET6)
unix (AF_UNIX)
Let’s look at sample output from the AF_UNIX sockets:

$ netstat -f unix

Active UNIX domain sockets
Address Type Vnode Conn Local Addr Remote Addr
30000d03738 stream-ord 30000d1eb78 00000000 /tmp/.X11-unix/X0
30000d038e0 stream-ord 00000000 00000000
30000d03a88 stream-ord 30000ce4a30 00000000 /tmp/jd_sockV6
30000d03c30 stream-ord 30000a62d78 00000000 /dev/kkcv
30000d03dd8 stream-ord 30000a62f50 00000000 /dev/ccv
Here we can see a number of different active sockets using Unix type addressing, such as the X11 server, which has the address 30000d03738.

Multicast Statistics

The multicast statistics option provides an overview of interfaces that are currently listening for multicast broadcasts on the 224.0.0.1 (ALL_HOSTS) address. This is so that packets can be routed appropriately using the router discovery daemon (in.rdisc), discussed in the next section, “Routing.” In the following example, both the IPv4 and IPv6 multicast groups are displayed:

$ netstat -g

Group Memberships: IPv4
Interface Group RefCnt
——— ——————– ——
lo0 224.0.0.1 1
hme0 224.0.0.1 1

Group Memberships: IPv6
If Group RefCnt
—– ———————— ——
lo0 ff02::1:ff00:1 1
lo0 ff02::1 1
hme0 ff02::202 1
hme0 ff02::1:ff04:a4e8 1
hme0 ff02::1 2
Routing Statistics

The kernel maintains a table of routes, constructed by the routing daemon, in.routed. The various routes that have been configured are always viewable by checking the routing statistics:

$ netstat -r

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
——————– ——————– —– —– —— ———
10.64.18.0 austin U 1 5 hme0
224.0.0.0 austin U 1 0 hme0
localhost localhost UH 25 215051 lo0
Here, we can see there are two network routes available for packets on the primary Ethernet interface hme0: the 10.64.18.0 network and the 224.0.0.0 multicast network. In addition, the loopback interface (lo0) has the local host interface, which is commonly used for troubleshooting and testing. These routes are all IPv4; however, IPv6 routing details are also displayed:

Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
————————— ————————— —– — —— —–
fe80::/10 fe80::203:baff:fe04:a4e8 U 1 0 hme0
ff00::/8 fe80::203:baff:fe04:a4e8 U 1 0 hme0
default fe80::203:baff:fe04:a4e8 U 1 0 hme0
localhost localhost UH 5 28 lo0
STREAMS Statistics

STREAMS is a System V package that provides access to system calls, standard libraries, and the kernel for the purposes of writing network applications. Any application that uses STREAMS has a specific set of properties about which statistics can be collected, since the I/O operations are distinct from other networking APIs (such as the BSD-style socket API). netstat reports these statistics, including queues, which comprise the read/write operations that characterize a stream:

$ netstat -m
streams allocation:
cumulative allocation
current maximum total failures
streams 326 340 7634 0
queues 938 962 18662 0
mblk 1144 1651 7773 0
dblk 1140 1729 2349590 0
linkblk 11 169 18 0
strevent 9 169 121739 0
syncq 25 50 101 0
qband 0 0 0 0

1646 Kbytes allocated for streams data
More details can be obtained by reading the manpage for streamio.

IP Interface Statistics

netstat also reports statistics obtained at the IP level. This includes the number of input and output packets counted, the number of input and output errors, and the number of packet collisions. Again, separate entries are shown for IPv4 and IPv6:

$ netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 227695 0 227695 0 0 0
hme0 1500 austin austin 2573 0 2130 0 0 0

Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis
lo0 8252 localhost localhost 227705 0 227705 0 0
hme0 1500 fe80::203:baff:fe04:a4e8/10 fe80::203:baff:fe04:a4e8 2573 0
2130 0 0
Combined Socket, Route, and Interface Statistics

Most administrators prefer to combine the information that netstat provides into a single report-style format. This can be achieved by using the combined route, socket, and interface statistics, as shown in the output in Example 4-1.

Example 4-1: Output of the netstat-a command

$ netstat -a
UDP: IPv4
Local Address Remote Address State
——————– ——————– ——-
*.route Idle
*.* Unbound
*.* Unbound
*.sunrpc Idle
*.* Unbound
*.32771 Idle
*.sunrpc Idle
*.* Unbound
*.32775 Idle
*.32779 Idle
*.32780 Idle
Routing
*.* Unbound
*.32821 Idle
*.32822 Idle
*.32823 Idle
*.name Idle
*.biff Idle
*.talk Idle
*.time Idle
*.echo Idle

UDP: IPv6
Local Address Remote Address State
If
——————————— ——————————— ———- –
—-
*.* Unbound
*.sunrpc Idle
*.* Unbound
*.32771 Idle
*.32779 Idle
*.* Unbound
*.32821 Idle
*.time Idle

TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
——————– ——————– —– —— —– —— ——-
*.* *.* 0 0 24576 0 IDLE
*.sunrpc *.* 0 0 24576 0 LISTEN
*.* *.* 0 0 24576 0 IDLE
*.sunrpc *.* 0 0 24576 0 LISTEN
*.* *.* 0 0 24576 0 IDLE
*.32775 *.* 0 0 24576 0 LISTEN
*.32776 *.* 0 0 24576 0 LISTEN
*.32782 *.* 0 0 24576 0 LISTEN
*.32783 *.* 0 0 24576 0 LISTEN

TCP: IPv6
Local Address Remote Address Swind Send-Q Rwind Recv-Q State If
*.* *.* 0 24576 0 IDLE
*.sunrpc *.* 0 0 24576 0 LISTEN
*.* *.* 0 0 24576 0 IDLE
*.32775 *.* 0 0 24576 0 LISTEN
localhost.32780 localhost.32775 32768 0 32768 0 CLOSE_WAIT
*.32782 *.* 0 0 24576 0 LISTEN
*.32791 *.* 0 0 24576 0 LISTEN
*.ftp *.* 0 0 24576 0 LISTEN
*.telnet *.* 0 0 24576 0 LISTEN

Active UNIX domain sockets
Address Type Vnode Conn Local Addr Remote Addr
30000d03738 stream-ord 30000d1eb78 00000000 /tmp/.X11-unix/X0
30000d038e0 stream-ord 00000000 00000000
30000d03a88 stream-ord 30000ce4a30 00000000 /tmp/jd_sockV6
30000d03c30 stream-ord 30000a62d78 00000000 /dev/kkcv
30000d03dd8 stream-ord 30000a62f50 00000000 /dev/ccv
Some of the TCP messages shown in this output, for both IPv4 and IPv6, may be unfamiliar, so we review each of them individually:

Message

Description

BOUND

Socket is bound.

CLOSED

Socket is closed.

CLOSING

Socket is closing.

CLOSE_WAIT

Socket is waiting to close.

ESTABLISHED

Socket has connected successfully.

FIN_WAIT_1

Socket is closing (local).

FIN_WAIT_2

Socket is closing (remote).

IDLE

Socket is idle.

LAST_ACK

Socket will close after receiving last acknowledgment.

LISTEN

Socket is active and listening.

SYN_RECEIVED

Socket is being synchronized.

SYN_SENT

Socket is creating a connection.

TIME_WAIT

Socket is waiting to close.

Routing

Imagine that you are a courier, and your run always starts at the local courier depot. You’re given a list of addresses, which are associated with a set of packages, and your goal is to deliver them in as little time as possible, subject to the following constraints:

The number of roads you take to deliver each package must be minimized.
You must avoid deadends and accidents.
You can only determine which roads to take by consulting a street directory and by crosschecking street names along your path with those in your directory.
If this seems like a fairly trivial task for a courier, consider how much more difficult the job would be if the following conditions prevailed:

The number of possible roads increases exponentially each year. You might be asked to take roads you’ve never heard of before!
There is no way of knowing, in advance, where accidents or deadends might occur.
The street directory you have is completely out of date, because the number of highways increases exponentially each year.
This scenario describes the difficulties faced by the emergence of the Internet and the massive interconnections between hosts and networks. In order for a packet of data to be transferred from host A to host B, a physical path must be identified for the packet to travel.

There is no central lookup service that decides how to route each packet between all possible combinations of two hosts on the Internet (i.e., between the sender and the receiver). This means routes must be generated dynamically. (The only exceptions to this rule are certain situations where a predictable static route may be installed.)

When transferring data around the Internet or between subnets, intermediate hosts must be responsible for transferring packets between networks; these hosts are called routers and are responsible for routing packets between hosts, which can be separated by single subnets or by entire continents.

Often more then a dozen routers are involved in transfer packets between the sender and the receiver. In addition, the observed response times can be quite slow. It is possible for attempted connections to time out. This can be very useful when trying to identify which intermediate host and/or network is having problems when your remote connection to a host half a world away suddenly dies!

Static routing typically involves creating a direct physical connection between two hosts, where the implementation of dynamic routing would be wasteful or a security risk. For example, if your local network has three subnets that need to share data, a static route could be created between each router and the other two routers in the network. The number of specific routes required to allow data to flow seamlessly between networks is directly proportional to the square of the number of routers on the network. Every time a change is made to the network topology, these routes will have to be modified manually. If that sounds like too much hard work, consider the situation where it might be desirable: a secure database server that can be accessible only by knowing the route to the host and is not publicly announced. Instead of permitting route discovery, a static route is an appropriate technique here. This could be implemented by creating a point-to-point configuration using ifconfig on a secondary interface, as discussed in the network interface configuration section.

The alternative to static routing is dynamic routing, which involves two daemons: the routing daemon proper (in.routed) and the route discovery daemon (in.rdisc). The in.routed daemon implements the Routing Information Protocol, and is responsible for updating and managing entries in the kernel’s routing tables. It uses UDP (port 520) for performing routing operations and operates on all network interfaces that have been plumbed and are identified as up.

If the /etc/notrouter file does not exist, and given that two or more operational interfaces can be found, the host begins to act as a router. Data can then be exchanged between data received on one interface, destined to be transmitted from another interface. For a local area network, the interface that connects to all local hosts is usually known as the internal interface, while the interface that is visible downstream to an ISP or another subnet is known as the external interface. By using packet filtering, it is possible to specify a set of rules governing what type (TCP or UDP) of packets can be transferred between interfaces and on which ports. This is obviously important for protecting local networks, since services that are available to local hosts may not be appropriate for public access.

The route discovery daemon, in.rdisc, implements the Internet Control Message Protocol (ICMP). In terms of route discovery, in.rdisc running on host systems listens for multicast broadcasts on the 224.0.0.1 (ALL_HOSTS) address. These messages are prioritized, and the default router is selected based on its proximity to the host. On routers, in.rdisc broadcasts its availability using multicast on 224.0.0.1, and listens for requests on 224.0.0.2 (ALL_ROUTERS). Hosts may request a router directly by broadcasting on 224.0.0.2.

Etc
==========================================================================================
System Administration Guide: IP Services
Previous: Chapter 5 Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)
Next: Chapter 7 Configuring an IPv6 Network (Tasks)
Chapter 6 Administering Network Interfaces (Tasks)
This chapter contains tasks and information about network interfaces:

Interface Administration (Task Map)

Basics for Administering Physical Interfaces

Administering Individual Network Interfaces

What’s New in Administering Network Interfaces
The information in this chapter describes interface configuration starting with the Solaris 10 1/06 release. If you are using the original release of Solaris 10, 3/05, refer to Administering Interfaces in Solaris 10 3/05. For a complete listing of new Oracle Solaris features and a description of Oracle Solaris releases, refer to Oracle Solaris 10 9/10 What’s New.

In Solaris 10 1/06, the following new features were introduced:

The new dladm command for viewing interface status is introduced in How to Configure a Physical Interface After System Installation.

VLAN support has extended to GLDv3 interfaces, as explained in Administering Virtual Local Area Networks.

Link aggregation support is introduced in Overview of Link Aggregations.

In Solaris 10 7/07, the /etc/inet/ipnodes becomes obsolete. Use /etc/inet/ipnodes only for earlier Solaris 10 releases, as explained in the individual procedures.

Interface Administration (Task Map)
The following table lists different tasks for configuring network interfaces, including special configurations such as VLANs and link aggregations. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task

Description

For Instructions

Check the status of interfaces on a system.

List all interfaces on the system and check which interfaces are already plumbed.

How to Obtain Interface Status

Add a single interface after system installation.

Change a system to a multihomed host or router by configuring another interface.

How to Configure a Physical Interface After System Installation

SPARC: Check that the MAC address of an interface is unique.

Ensure that the interface is configured with its factory-installed MAC address, rather than the system MAC address (SPARC only).

SPARC: How to Ensure That the MAC Address of an Interface Is Unique

Plan for a virtual local area network (VLAN).

Perform required planning tasks prior to creating a VLAN.

How to Plan a VLAN Configuration

Configure a VLAN.

Create and modify VLANs on your network.

How to Configure a VLAN

Plan for aggregations.

Design your aggregation and perform required planning tasks prior to configuring aggregations.

Overview of Link Aggregations

Configure an aggregation.

Perform various tasks related to link aggregations.

How to Create a Link Aggregation

Plan for and configure an IPMP group.

Configure failover and failback for interfaces that are members of an IPMP group.

How to Plan for an IPMP Group

How to Configure an IPMP Group With Multiple Interfaces

Administering Individual Network Interfaces
After Oracle Solaris installation, you might configure or administer interfaces on a system for the following purposes:

To upgrade the system to become a multihomed host. For more information, refer to Configuring Multihomed Hosts.

To change a host to a router. For instructions on configuring routers, refer to Configuring an IPv4 Router.

To configure interfaces as part of a VLAN. For more information, refer to Administering Virtual Local Area Networks.

To configure interfaces as members of an aggregation. For more information, refer to Overview of Link Aggregations.

To add an interface to an IPMP group. For instructions on configuring an IPMP group, refer to Configuring IPMP Groups

This section contains information about configuring individual network interfaces , starting with the Solaris 10 1/06 release. Refer to the following sections for information about configuring interfaces into one of the following groupings:

For configuring interfaces into a VLAN, refer to Administering Virtual Local Area Networks.

For configuring interfaces into an aggregation, refer to Overview of Link Aggregations.

For configuring interfaces as members of IPMP groups, refer to Configuring IPMP Groups.

ProcedureHow to Obtain Interface Status
Starting with Solaris 10 1/06, this procedure explains how to determine which interfaces are currently available on a system and their status. This procedure also shows which interfaces are currently plumbed. If you are using the earlier Solaris 10 3/05, refer to How to Get Information About a Specific Interface.

On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Determine which interfaces are currently installed on your system.
# dladm show-link
This step uses the dladm command, which is explained in detail in the dladm(1M) man page. This command reports on all the interface drivers that it finds, regardless of whether the interfaces are currently configured.

Determine which interfaces on the system are currently plumbed.
# ifconfig -a
The ifconfig command has many additional functions, including plumbing an interface. For more information, refer to the ifconfig(1M) man page.

Example 6–1 Obtaining the Status of an Interface with the dladm command

The next example shows the status display of the dladm command.
# dladm show-link
ce0 type: legacy mtu: 1500 device: ce0
ce1 type: legacy mtu: 1500 device: ce1
bge0 type: non-vlan mtu: 1500 device: bge0
bge1 type: non-vlan mtu: 1500 device: bge1
bge2 type: non-vlan mtu: 1500 device: bge2

The output of dladm show-link indicates that four interface drivers are available for the local host. Both the ce and the bge interfaces can be configured for VLANs. However, only the GLDV3 interfaces with a type of non-VLAN can be used for link aggregations.

The next example shows the status display of 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
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 3
inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
ether 0:3:ba:7:84:5e
bge0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>mtu 1500 index 2
inet 10.8.57.39 netmask ffffff00 broadcast 10.8.57.255
ether 0:3:ba:29:fc:cc
The output of the ifconfig -a command displays statistics for only two interfaces, ce0 and bge0. This output shows that only ce0 and bge0 have been plumbed and are ready for use by network traffic. These interfaces can be used in a VLAN. Because bge0 has been plumbed, you can no longer use this interface in an aggregation.

ProcedureHow to Configure a Physical Interface After System Installation
Use the next procedure for configuring interfaces. If you are using the Solaris 10 3/05 release, use the procedure How to Add a Physical Interface After Installation in Solaris 10 3/05 ONLY.

Before You Begin
Determine the IPv4 addresses that you want to use for the additional interfaces.

Ensure that the physical interface to be configured has been physically installed onto the system. For information about installing separately purchased NIC hardware, refer to the manufacturer’s instructions that accompany the NIC.

If you have just installed the interface, perform a reconfiguration boot before proceeding with the next task.

On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Determine which interfaces are currently installed on the system.
# dladm show-link
Configure and plumb each interface.
# ifconfig interface plumb up
For example, for qfe0 you would type:
# ifconfig qfe0 plumb up
Note –
Interfaces that are explicitly configured with the ifconfig command do not persist across a reboot.

Assign an IPv4 address and netmask to the interface.
# ifconfig interface IPv4-address netmask+netmask
For example, for qfe0 you would type:
# ifconfig
qfe0 192.168.84.3 netmask + 255.255.255.0
Note –
You can specify an IPv4 address in either traditional IPv4 notation or CIDR notation.

Verify that the newly configured interfaces are plumbed and configured, or “UP.”
# ifconfig
-a
Check the status line for each interface that is displayed. Ensure that the output contains an UP flag on the status line, for example:
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500 index 2
(Optional) To make the interface configuration persist across reboots, perform the following steps:

Create an /etc/hostname.interface file for each interface to be configured.

For example, to add a qfe0 interface, you would create the following file:
# vi /etc/hostname.qfe0
Note –
If you create alternate hostname files for the same interface, the alternate files must also follow the naming format hostname.[0–9]*, such as hostname.qfe0.a123. Names such as hostname.qfe0.bak or hostname.qfe0.old are invalid and will be ignored by scripts during system boot.

Note, too, that a given interface must have only one corresponding hostname file. If you create an alternate hostname file for an interface with a valid filename, such as /etc/hostname.qfe and /etc/hostname.qfe.a123, the boot scripts will attempt to configure by referencing the contents of both hostname files and would therefore generate errors. To prevent these errors, provide an invalid file name to the hostname file that you do not want to use in a given configuration.

Edit the /etc/hostname.interface file.

At a minimum, add the IPv4 address of the interface to the file. You can use traditional IPv4 notation or CIDR notation to specify the IP address of the interface. You can also add a netmask and other configuration information to the file.

Note –
To add an IPv6 address to an interface, refer to Modifying an IPv6 Interface Configuration for Hosts and Servers

For Solaris 10 11/06 and earlier releases of Oracle Solaris 10, add entries for the new interfaces into the /etc/inet/ipnodes file.

Add entries for the new interfaces into the /etc/inet/hosts file.

Perform a reconfiguration boot.
# reboot — -r
Verify that the interface you created in the /etc/hostname.interface file has been configured.
# ifconfig -a
For examples, refer to Example 6–2.

Example 6–2 Adding Persistent Interface Configurations

The example shows how to configure the interfaces qfe0 and qfe1 to a host. These interfaces remain persistent across reboots.
# dladm show-link
eri0 type: legacy mtu: 1500 device: eri0
qfe0 type: legacy mtu: 1500 device: qfe0
qfe1 type: legacy mtu: 1500 device: qfe1
qfe2 type: legacy mtu: 1500 device: qfe2
qfe3 type: legacy mtu: 1500 device: qfe3
bge0 type: non-vlan mtu: 1500 device: bge0
# vi /etc/hostname.qfe0
192.168.84.3 netmask 255.255.255.0
# vi /etc/hostname.qfe1
192.168.84.72 netmask 255.255.255.0
# vi /etc/inet/hosts
# Internet host table
#
127.0.0.1 localhost
10.0.0.14 myhost
192.168.84.3 interface-2
192.168.84.72 interface-3
For Solaris 10 11/06 and earlier releases:# vi /etc/inet/ipnodes
10.0.0.14 myhost
192.168.84.3 interface-2
192.168.84.72 interface-3
At this point, you would reboot the system.
# reboot — -r
After the system boots, you would then verify the interface configuration.
ifconfig -a
# 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 2
inet 10.0.0.14netmask ff000000 broadcast 10.255.255.255
ether 8:0:20:c1:8b:c3
qfe0:flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.84.3 netmask ffffff00 broadcast 192.255.255.255
ether 8:0:20:c8:f4:1d
qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4
inet 192.168.84.72 netmask ffffff00 broadcast 10.255.255.255
ether 8:0:20:c8:f4:1e
See Also
To configure an IPv6 address onto an interface, refer to How to Enable an IPv6 Interface for the Current Session.

To set up failover detection and failback for interfaces by using IP Network Multipathing (IPMP), refer to Chapter 31, Administering IPMP (Tasks).

ProcedureHow to Remove a Physical Interface
Use this procedure for removing a physical interface. If you are using the earlier Solaris 10 3/05, refer to How to Remove a Physical Interface in Solaris 10 3/05 ONLY.

On the system with the interface to be removed, assume the Primary Administrator role or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Remove the physical interface.
# ifconfig interface down unplumb
For example, to remove the interface qfe1, you would type:
# ifconfig qfe1 down unplumb
ProcedureSPARC: How to Ensure That the MAC Address of an Interface Is Unique
Use this procedure for configuring MAC addresses.

Some applications require every interface on a host to have a unique MAC addresses. However, every SPARC based system has a system-wide MAC address, which by default is used by all interfaces. Here are two situations where you might want to configure the factory-installed MAC addresses for the interfaces on a SPARC system.

For link aggregations, you should use the factory-set MAC addresses of the interfaces in the aggregation configuration.

For IPMP groups, each interface in the group must have a unique MAC address. These interfaces must use their factory-installed MAC addresses.

The EEPROM parameter local-mac-address? determines whether all interfaces on a SPARC system use the system-wide MAC address or their unique MAC address. The next procedure shows how to use the eeprom command to check the current value of local-mac-address? and change it, if necessary.

On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Determine whether all interfaces on the system currently use the system-wide MAC address.
# eeprom local-mac-address?
local-mac-address?=false
In the example, the response to the eeprom command, local-mac-address?=false, indicates that all interfaces do use the system-wide MAC address. The value of local-mac-address?=false must be changed to local-mac-address?=true before the interfaces can become members of an IPMP group. You should also change local-mac-address?=false to local-mac-address?=true for aggregations.

If necessary, change the value of local-mac-address? as follows:
# eeprom local-mac-address?=true
When you reboot the system, the interfaces with factory-installed MAC addresses now use these factory settings, rather than the system-wide MAC address. Interfaces without factory-set MAC addresses continue to use the system-wide MAC address.

Check the MAC addresses of all the interfaces on the system.

Look for cases where multiple interfaces have the same MAC address. In this example, all interfaces use the system-wide MAC address 8:0:20:0:0:1.
ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127
ether 8:0:20:0:0:1
ce0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.0.114 netmask ffffff80 broadcast 10.0.0.127
ether 8:0:20:0:0:1
ce1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127
ether 8:0:20:0:0:1
Note –
Continue to the next step only if more than one network interface still has the same MAC address. Otherwise, go on to the final step.

If necessary, manually configure the remaining interfaces so that all interfaces have unique MAC address.

Specify a unique MAC address in the /etc/hostname.interface file for the particular interface.

In the example in Step 4, you would need to configure ce0 and ce1 with locally administered MAC addresses. For example, to reconfigure ce1 with the locally administered MAC address 06:05:04:03:02, you would add the following line to /etc/hostname.ce1:
ether 06:05:04:03:02
Note –
To prevent any risk of manually configured MAC addresses conflicting with other MAC addresses on your network, you must always configure locally administered MAC addresses, as defined by the IEEE 802.3 standard.

You also can use the ifconfig ether command to configure an interface’s MAC address for the current session. However, any changes made directly with ifconfig are not preserved across reboots. Refer to the ifconfig(1M) man page for details.

Reboot the system.

Basics for Administering Physical Interfaces
Network interfaces provide the connection between a system and a network. An Oracle Solaris-based system can have two types of interfaces, physical and logical. Physical interfaces consist of a software driver and a connector into which you connect network media, such as an Ethernet cable. Physical interfaces can be grouped for administrative or availability purposes. Logical interfaces are configured onto existing physical interfaces, usually for adding addresses and creating tunnel endpoints on the physical interfaces.

Note –
Logical network interfaces are described in the tasks where they are used: IPv6 tasks, IPMP tasks, DHCP tasks, and others.

Most computer systems have at least one physical interface that is built-in by the manufacturer on the main system board. Some systems can also have more than one built-in interface.

In addition to built-in interfaces, you can add separately purchased interfaces to a system. A separately purchased interface is known as a network interface card (NIC). You physically install a NIC according to the manufacturer’s instructions.

Note –
NICs are also referred to as network adapters.

During system installation, the Oracle Solaris installation program detects any interfaces that are physically installed and displays each interface’s name. You must configure at least one interface from the list of interfaces. The first interface to be configured during installation becomes the primary network interface. The IP address of the primary network interface is associated with the configured host name of the system, which is stored in the /etc/nodename file. However, you can configure any additional interfaces during installation or later.

Network Interface Names
Each physical interface is identified by a unique device name. Device names have the following syntax:
<driver-name><instance-number>
Driver names on Oracle Solaris systems could include ce, hme, bge, e1000g and many other driver names. The variable instance-number can have a value from zero to n, depending on how many interfaces of that driver type are installed on the system.

For example, consider a 100BASE-TX Fast Ethernet interface, which is often used as the primary network interface on both host systems and server systems. Some typical driver names for this interface are eri, qfe, and hme. When used as the primary network interface, the Fast Ethernet interface has a device name such as eri0 or qfe0.

NICs such as eri and hme have only one interface. However, many brands of NICs have multiple interfaces. For example, the Quad Fast Ethernet (qfe) card has four interfaces, qfe0 through qfe3.

Plumbing an Interface
An interface must be plumbed before it can pass traffic between the system and the network. The plumbing process involves associating an interface with a device name. Then, streams are set up so that the interface can be used by the IP protocol. Both physical interfaces and logical interfaces must be plumbed. Interfaces are plumbed either as part of the boot sequence or explicitly, with the appropriate syntax of the ifconfig command.

When you configure an interface during installation, the interface is automatically plumbed. If you decide during installation not to configure the additional interfaces on the system, those interfaces are not plumbed.

Oracle Solaris Interface Types
Starting with the Solaris 10 1/06 release, Oracle Solaris supports the following two types of interfaces:

Legacy interfaces – These interfaces are DLPI interfaces and GLDv2 interfaces. Some legacy interface types are eri, qfe, and ce. When you check interface status with the dladm show-link command, these interfaces are reported as “legacy.”

Non-VLAN interfaces – These interfaces are GLDv3 interfaces.

Note –
Currently GLDv3 is supported on the following interface types: bge, xge, and e1000g.

Administering Virtual Local Area Networks
Note –
If you are using the earlier Solaris 3/05, refer to Configuring VLANs in Solaris 10 3/05 ONLY.

A virtual local area network (VLAN) is a subdivision of a local area network at the datalink layer of the TCP/IP protocol stack. You can create VLANs for local area networks that use switch technology. By assigning groups of users to VLANs, you can improve network administration and security for the entire local network. You can also assign interfaces on the same system to different VLANs.

Consider dividing your local network into VLANs if you need to do the following:

Create a logical division of workgroups.

For example, suppose all hosts on a floor of a building are connected on one switched-based local network. You could create a separate VLAN for each workgroup on the floor.

Enforce differing security policies for the workgroups.

For example, the security needs of a Finance department and an Information Technologies department are quite different. If systems for both departments share the same local network, you could create a separate VLAN for each department. Then, you could enforce the appropriate security policy on a per-VLAN basis.

Split workgroups into manageable broadcast domains.

The use of VLANs reduces the size of broadcast domains and improves network efficiency.

Overview of VLAN Topology
Switched LAN technology enables you to organize the systems on a local network into VLANs. Before you can divide a local network into VLANs, you must obtain switches that support VLAN technology. You can configure all ports on a switch to serve a single VLAN or multiple VLANs, depending on the VLAN topology design. Each switch manufacturer has different procedures for configuring the ports of a switch.

The following figure shows a local area network that has the subnet address 192.168.84.0. This LAN is subdivided into three VLANs, Red, Yellow, and Blue.

Figure 6–1 Local Area Network With Three VLANs

The surrounding context describes the figure’s content.
Connectivity on LAN 192.168.84.0 is handled by Switches 1 and 2. The Red VLAN contains systems in the Accounting workgroup. The Human Resources workgroup’s systems are on the Yellow VLAN. Systems of the Information Technologies workgroup are assigned to the Blue VLAN.

VLAN Tags and Physical Points of Attachment
Each VLAN in a local area network is identified by a VLAN tag, or VLAN ID (VID). The VID is assigned during VLAN configuration. The VID is a 12-bit identifier between 1 and 4094 that provides a unique identity for each VLAN. In Figure 6–1, the Red VLAN has the VID 789, the Yellow VLAN has the VID 456, and the Blue VLAN has the VID 123.

When you configure switches to support VLANs, you need to assign a VID to each port. The VID on the port must be the same as the VID assigned to the interface that connects to the port, as shown in the following figure.

Figure 6–2 Switch Configuration for a Network with VLANs

The surrounding context describes the figure’s content.
Figure 6–2 shows multiple hosts that are connected to different VLANs. Two hosts belong to the same VLAN. In this figure, the primary network interfaces of the three hosts connect to Switch 1. Host A is a member of the Blue VLAN. Therefore, Host A’s interface is configured with the VID 123. This interface connects to Port 1 on Switch 1, which is then configured with the VID 123. Host B is a member of the Yellow VLAN with the VID 456. Host B’s interface connects to Port 5 on Switch 1, which is configured with the VID 456. Finally, Host C’s interface connects to Port 9 on Switch 1. The Blue VLAN is configured with the VID 123.

The figure also shows that a single host can also belong to more than one VLAN. For example, Host A has two VLANs configured over the host’s interface. The second VLAN is configured with the VID 456 and is connected to Port 3 which is also configured with the VID 456. Thus, Host A is a member of both the Blue VLAN and the Yellow VLAN.

During VLAN configuration, you have to specify the physical point of attachment, or PPA, of the VLAN. You obtain the PPA value by using this formula:
driver-name + VID * 1000 + device-instance
Note that the device-instance number must be less than 1000.

For example, you would create the following PPA for a ce1 interface to be configured as part of VLAN 456:
ce + 456 * 1000 + 1= ce456001
Planning for VLANs on a Network
Use the following procedure to plan for VLANs on your network.

ProcedureHow to Plan a VLAN Configuration
Examine the local network topology and determine where subdivision into VLANs is appropriate.

For a basic example of such a topology, refer to Figure 6–1.

Create a numbering scheme for the VIDs, and assign a VID to each VLAN.

Note –
A VLAN numbering scheme might already exist on the network. If so, you must create VIDs within the existing VLAN numbering scheme.

On each system, determine which interfaces will be members of a particular VLAN.

Determine which interfaces are configured on a system.
# dladm show-link
Identify which VID will be associated with each datalink on the system.

Create PPAs for each interface to be configured with a VLAN.

All interfaces on a system do not necessarily have to be configured on the same VLAN.

Check the connections of the interfaces to the network’s switches.

Note the VID of each interface and the switch port where each interface is connected.

Configure each port of the switch with the same VID as the interface to which it is connected.

Refer to the switch manufacturer’s documentation for configuration instructions.

Configuring VLANs
Note –
If you are using the earlier Solaris 10 3/05, refer to Configuring VLANs in Solaris 10 3/05 ONLY.

Oracle Solaris now supports VLANs on the following interface types:

ce

bge

xge

e1000g

Of the legacy interface types, only the ce interface can become a member of a VLAN. You can configure interfaces of different types in the same VLAN.

Note –
You can configure multiple VLANs into an IPMP group. For more information about IPMP groups, see IPMP Interface Configurations.

ProcedureHow to Configure a VLAN
If you are using Solaris 10 3/05, use the procedure How To Configure Static VLANs in Solaris 10 3/05 ONLY.

Assume the Primary Administrator role, or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Determine the types of interfaces in use on your system.
# dladm show-link
The output shows the available interface types:
ce0 type: legacy mtu: 1500 device: ce0
ce1 type: legacy mtu: 1500 device: ce1
bge0 type: non-vlan mtu: 1500 device: bge0
bge1 type: non-vlan mtu: 1500 device: bge1
bge2 type: non-vlan mtu: 1500 device: bge2
Configure an interface as part of a VLAN.
# ifconfig interface-PPA plumb IP-address up
For example, you would use the following command to configure the interface ce1 with a new IP address 10.0.0.2 into a VLAN with the VID 123:
# ifconfig ce123001 plumb 10.0.0.2
up
Note –
You can assign IPv4 and IPv6 addresses to VLANs just as you do to other interfaces.

(Optional) To make the VLAN settings persist across reboots, create a hostname.interface-PPA file for each interface that is configured as part of a VLAN.
# cat hostname.interface-PPA
IPv4-address
On the switch, set VLAN tagging and VLAN ports to correspond with the VLANs that you have set up on the system.

Example 6–3 Configuring a VLAN

This example shows how to configure devices bge1 and bge2 into a VLAN with the VID 123.
# dladm show-link
ce0 type: legacy mtu: 1500 device: ce0
ce1 type: legacy mtu: 1500 device: ce1
bge0 type: non-vlan mtu: 1500 device: bge0
bge1 type: non-vlan mtu: 1500 device: bge1
bge2 type: non-vlan mtu: 1500 device: bge2
# ifconfig bge123001 plumb 10.0.0.1 up
# ifconfig bge123002 plumb 10.0.0.2 up
# cat hostname.bge123001 10.0.0.1
# cat hostname.bge123002 10.0.0.2
# ifconfig -a
lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge123001: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255
ether 0:3:ba:7:84:5e
bge123002:flags=201000803 <UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 3
inet 10.0.0.2 netmask ff000000 broadcast 10.255.255.255
ether 0:3:ba:7:84:5e
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4
inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
ether 0:3:ba:7:84:5e
# dladm show-link
ce0 type: legacy mtu: 1500 device: ce0
ce1 type: legacy mtu: 1500 device: ce1
bge0 type: non-vlan mtu: 1500 device: bge0
bge1 type: non-vlan mtu: 1500 device: bge1
bge2 type: non-vlan mtu: 1500 device: bge2
bge123001 type: vlan 123 mtu: 1500 device: bge1
bge123002 type: vlan 123 mtu: 1500 device: bge2
Overview of Link Aggregations
Note –
The original Oracle Solaris 10 release and earlier versions of Oracle Solaris do not support Link Aggregations. To create link aggregations for these earlier Oracle Solaris releases, use Sun Trunking, as described in the Sun Trunking 1.3 Installation and Users Guide.

Oracle Solaris supports the organization of network interfaces into link aggregations. A link aggregation consists of several interfaces on a system that are configured together as a single, logical unit. Link aggregation, also referred to as trunking, is defined in the IEEE 802.3ad Link Aggregation Standard.

The IEEE 802.3ad Link Aggregation Standard provides a method to combine the capacity of multiple full-duplex Ethernet links into a single logical link. This link aggregation group is then treated as though it were, in fact, a single link.

The following are features of link aggregations:

Increased bandwidth – The capacity of multiple links is combined into one logical link.

Automatic failover/failback – Traffic from a failed link is failed over to working links in the aggregation.

Load balancing – Both inbound and outbound traffic is distributed according to user selected load-balancing policies, such as source and destination MAC or IP addresses.

Support for redundancy – Two systems can be configured with parallel aggregations.

Improved administration – All interfaces are administered as a single unit.

Less drain on the network address pool – The entire aggregation can be assigned one IP address.

Link Aggregation Basics
The basic link aggregation topology involves a single aggregation that contains a set of physical interfaces. You might use the basic link aggregation in the following situations:

For systems that run an application with distributed heavy traffic, you can dedicate an aggregation to that application’s traffic.

For sites with limited IP address space that nevertheless require large amounts of bandwidth, you need only one IP address for a large aggregation of interfaces.

For sites that need to hide the existence of internal interfaces, the IP address of the aggregation hides its interfaces from external applications.

Figure 6–3 shows an aggregation for a server that hosts a popular web site. The site requires increased bandwidth for query traffic between Internet customers and the site’s database server. For security purposes, the existence of the individual interfaces on the server must be hidden from external applications. The solution is the aggregation aggr1 with the IP address 192.168.50.32. This aggregation consists of three interfaces,bge0 through bge2. These interfaces are dedicated to sending out traffic in response to customer queries. The outgoing address on packet traffic from all the interfaces is the IP address of aggr1, 192.168.50.32.

Figure 6–3 Basic Link Aggregation Topology

The figure shows a block for the link aggr1. Three physical
interfaces, bge0–bge2, descend from the link block.
Figure 6–4 depicts a local network with two systems, and each system has an aggregation configured. The two systems are connected by a switch. If you need to run an aggregation through a switch, that switch must support aggregation technology. This type of configuration is particularly useful for high availability and redundant systems.

In the figure, System A has an aggregation that consists of two interfaces, bge0 and bge1. These interfaces are connected to the switch through aggregated ports. System B has an aggregation of four interfaces, e1000g0 through e1000g3. These interfaces are also connected to aggregated ports on the switch.

Figure 6–4 Link Aggregation Topology With a Switch

The figure is explained in the preceding context.
Back-to-Back Link Aggregations
The back-to-back link aggregation topology involves two separate systems that are cabled directly to each other, as shown in the following figure. The systems run parallel aggregations.

Figure 6–5 Basic Back-to-Back Aggregation Topology

The figure is explained in the following context.
In this figure, device bge0 on System A is directly linked to bge0 on System B, and so on. In this way, Systems A and B can support redundancy and high availability, as well as high-speed communications between both systems. Each system also has interface ce0 configured for traffic flow within the local network.

The most common application for back-to-back link aggregations is mirrored database servers. Both servers need to be updated together and therefore require significant bandwidth, high-speed traffic flow, and reliability. The most common use of back-to-back link aggregations is in data centers.

Policies and Load Balancing
If you plan to use a link aggregation, consider defining a policy for outgoing traffic. This policy can specify how you want packets to be distributed across the available links of an aggregation, thus establishing load balancing. The following are the possible layer specifiers and their significance for the aggregation policy:

L2 – Determines the outgoing link by hashing the MAC (L2) header of each packet

L3 – Determines the outgoing link by hashing the IP (L3) header of each packet

L4 – Determines the outgoing link by hashing the TCP, UDP, or other ULP (L4) header of each packet

Any combination of these policies is also valid. The default policy is L4. For more information, refer to the dladm(1M) man page.

Aggregation Mode and Switches
If your aggregation topology involves connection through a switch, you must note whether the switch supports the link aggregation control protocol (LACP). If the switch supports LACP, you must configure LACP for the switch and the aggregation. However, you can define one of the following modes in which LACP is to operate:

Off mode – The default mode for aggregations. LACP packets, which are called LACPDUs are not generated.

Active mode – The system generates LACPDUs at regular intervals, which you can specify.

Passive mode – The system generates an LACPDU only when it receives an LACPDU from the switch. When both the aggregation and the switch are configured in passive mode, they cannot exchange LACPDUs.

See the dladm(1M) man page and the switch manufacturer’s documentation for syntax information.

Requirements for Link Aggregations
Your link aggregation configuration is bound by the following requirements:

You must use the dladm command to configure aggregations.

An interface that has been plumbed cannot become a member of an aggregation.

Interfaces must be of the GLDv3 type: xge, e1000g, and bge.

All interfaces in the aggregation must run at the same speed and in full-duplex mode.

You must set the value for MAC addresses to “true” in the EEPROM parameter local-mac-address? For instructions, refer to How to Ensure That the MAC Address of an Interface Is Unique.

ProcedureHow to Create a Link Aggregation
Before You Begin
Note –
Link aggregation only works on full-duplex, point-to-point links that operate at identical speeds. Make sure that the interfaces in your aggregation conform to this requirement.

If you are using a switch in your aggregation topology, make sure that you have done the following on the switch:

Configured the ports to be used as an aggregation

If the switch supports LACP, configured LACP in either active mode or passive mode

Assume the Primary Administrator role, or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Determine which interfaces are currently installed on your system.
# dladm show-link
Determine which interfaces have been plumbed.
# ifconfig -a
Create an aggregation.
# dladm create-aggr -d interface -d interface […]key
interface
Represents the device name of the interface to become part of the aggregation.

key
Is the number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.

For example:
# dladm create-aggr -d bge0 -d bge1 1
Configure and plumb the newly created aggregation.
# ifconfig aggrkey plumb IP-address up
For example:
# ifconfig aggr1 plumb 192.168.84.14 up
Check the status of the aggregation you just created.
# dladm show-aggr
You receive the following output:
key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached
bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby
The output shows that an aggregation with the key of 1 and a policy of L4 was created.

(Optional) Make the IP configuration of the link aggregation persist across reboots.

For link aggregations with IPv4 addresses, create an /etc/hostname.aggrkey file. For IPv6–based link aggregations, create an /etc/hostname6.aggrkey file.

Enter the IPv4 or IPv6 address of the link aggregation into the file.

For example, you would create the following file for the aggregation that is created in this procedure:
# vi /etc/hostname.aggr1
192.168.84.14
Perform a reconfiguration boot.
# reboot — -r
Verify that the link aggregation configuration you entered in the /etc/hostname.aggrkey file has been configured.
# ifconfig -a
.
.
aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.84.14 netmask ff000000 broadcast 192.255.255.
Example 6–4 Creating a Link Aggregation

This example shows the commands that are used to create a link aggregation with two devices, bge0 and bge1, and the resulting output.
# dladm show-link
ce0 type: legacy mtu: 1500 device: ce0
ce1 type: legacy mtu: 1500 device: ce1
bge0 type: non-vlan mtu: 1500 device: bge0
bge1 type: non-vlan mtu: 1500 device: bge1
bge2 type: non-vlan mtu: 1500 device: bge2
# ifconfig -a
lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
ether 0:3:ba:7:84:5e
# dladm create-aggr -d bge0 -d bge1 1
# ifconfig aggr1 plumb 192.168.84.14 up
# dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached
bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby

# ifconfig -a
lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
ether 0:3:ba:7:84:5e
aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.84.14 netmask ff000000 broadcast 192.255.255.255
ether 0:3:ba:7:84:5e
Note that the two interfaces that were used for the aggregation were not previously plumbed by ifconfig.

ProcedureHow to Modify an Aggregation
This procedure shows how to make the following changes to an aggregation definition:

Modifying the policy for the aggregation

Changing the mode for the aggregation

Assume the Primary Administrator role, or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Modify the aggregation to change the policy.
# dladm modify-aggr -Ppolicy key
policy
Represents one or more of the policies L2, L3, and L4, as explained in Policies and Load Balancing.

key
Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.

If LACP is running on the switch to which the devices in the aggregation are attached, modify the aggregation to support LACP.

If the switch runs LACP in passive mode, be sure to configure active mode for your aggregation.
# dladm modify-aggr -l LACP mode -t timer-value key
-l LACP mode
Indicates the LACP mode in which the aggregation is to run. The values are active, passive, and off.

-t timer-value
Indicates the LACP timer value, either short or long.

key
Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.

Example 6–5 Modifying a Link Aggregation

This example shows how to modify the policy of aggregation aggr1 to L2 and then turn on active LACP mode.
# dladm modify-aggr -P L2 1
# dladm modify-aggr -l active -t short 1
# dladm show-aggr
key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached
bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby
ProcedureHow to Remove an Interface From an Aggregation
Assume the Primary Administrator role, or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Remove an interface from the aggregation.
# dladm remove-aggr -d interface
Example 6–6 Removing Interfaces From an Aggregation

This example shows how to remove the interfaces of the aggregation aggr1.
# dladm show-aggr
key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached
bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby
# dladm remove-aggr -d bge1 1
# dladm show-aggr
key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached

ProcedureHow to Delete an Aggregation
Assume the Primary Administrator role, or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Delete the aggregation.
# dladm delete-aggr key
key
Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.

Example 6–7 How to Delete an Aggregation

This example shows how to remove the aggregation aggr1.
# dladm show-aggr
key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
# dladm delete-aggr -d 1
ProcedureHow to Configure VLANs Over a Link Aggregation
In the same manner as configuring VLANs over an interface, you can also create VLANs on a link aggregation. VLANs are described in Administering Virtual Local Area Networks. This section combines configuring VLANs and link aggregations.

Before You Begin
Configure the link aggregation first with a valid IP address. Note the value of the aggregation’s key which you will need when you create the VLANs over the aggregation. To create link aggregations, refer to How to Create a Link Aggregation.

If a link aggregation has already been previously created, obtain that aggregation’s key.
# dladm show-aggr
Create the VLANs over the link aggregation.
# ifconfig aggrVIDkey plumb
where

VID
The ID of the VLAN

key
The key of the link aggregation over which the VLAN is created. The key must be in a 3–digit format. For example, if the aggregation’s key is 1, then the key number that is included in the name of the VLAN is 001.

Repeat Step 2 to create other VLANs over the aggregation.

Configure the VLANs with valid IP addresses.

To create persistent VLAN configurations, add the IP address information to the corresponding /etc/hostname.VLAN configuration files.

Example 6–8 Configuring Multiple VLANs Over a Link Aggregation

In this example, two VLANs are configured on a link aggregation. The output of the dladm show-aggr command indicates that the link aggregation’s key is 1. The VLANs are assigned VIDs 193 and 194, respectively.
# dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto)
device address speed duplex link state
bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached
bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby

# ifconfig aggr193001 plumb
# ifconfig aggr193001 192.168.10.5/24 up

# ifconfig aggr194001 plumb
# ifconfig aggr194001 192.168.10.25/24 up

# vi /etc/hostname.aggr193001
192.168.10.5/24

# vi /etc/hostname.aggr194001
192.168.10.25/24
===========================================================================================
Solaris – 10

Previous: How to Obtain Interface Status
Next: How to Remove a Physical Interface
ProcedureHow to Configure a Physical Interface After System Installation
Use the next procedure for configuring interfaces. If you are using the Solaris 10 3/05 release, use the procedure How to Add a Physical Interface After Installation in Solaris 10 3/05 ONLY.

Before You Begin
Determine the IPv4 addresses that you want to use for the additional interfaces.

Ensure that the physical interface to be configured has been physically installed onto the system. For information about installing separately purchased NIC hardware, refer to the manufacturer’s instructions that accompany the NIC.

If you have just installed the interface, perform a reconfiguration boot before proceeding with the next task.

On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

Determine which interfaces are currently installed on the system.
# dladm show-link
Configure and plumb each interface.
# ifconfig interface plumb up
For example, for qfe0 you would type:
# ifconfig qfe0 plumb up
Note –
Interfaces that are explicitly configured with the ifconfig command do not persist across a reboot.

Assign an IPv4 address and netmask to the interface.
# ifconfig interface IPv4-address netmask+netmask
For example, for qfe0 you would type:
# ifconfig
qfe0 192.168.84.3 netmask + 255.255.255.0
Note –
You can specify an IPv4 address in either traditional IPv4 notation or CIDR notation.

Verify that the newly configured interfaces are plumbed and configured, or “UP.”
# ifconfig
-a
Check the status line for each interface that is displayed. Ensure that the output contains an UP flag on the status line, for example:
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500 index 2
(Optional) To make the interface configuration persist across reboots, perform the following steps:

Create an /etc/hostname.interface file for each interface to be configured.

For example, to add a qfe0 interface, you would create the following file:
# vi /etc/hostname.qfe0
Note –
If you create alternate hostname files for the same interface, the alternate files must also follow the naming format hostname.[0–9]*, such as hostname.qfe0.a123. Names such as hostname.qfe0.bak or hostname.qfe0.old are invalid and will be ignored by scripts during system boot.

Note, too, that a given interface must have only one corresponding hostname file. If you create an alternate hostname file for an interface with a valid filename, such as /etc/hostname.qfe and /etc/hostname.qfe.a123, the boot scripts will attempt to configure by referencing the contents of both hostname files and would therefore generate errors. To prevent these errors, provide an invalid file name to the hostname file that you do not want to use in a given configuration.

Edit the /etc/hostname.interface file.

At a minimum, add the IPv4 address of the interface to the file. You can use traditional IPv4 notation or CIDR notation to specify the IP address of the interface. You can also add a netmask and other configuration information to the file.

Note –
To add an IPv6 address to an interface, refer to Modifying an IPv6 Interface Configuration for Hosts and Servers

For Solaris 10 11/06 and earlier releases of Oracle Solaris 10, add entries for the new interfaces into the /etc/inet/ipnodes file.

Add entries for the new interfaces into the /etc/inet/hosts file.

Perform a reconfiguration boot.
# reboot — -r
Verify that the interface you created in the /etc/hostname.interface file has been configured.
# ifconfig -a
For examples, refer to Example 6–2.

Example 6–2 Adding Persistent Interface Configurations

The example shows how to configure the interfaces qfe0 and qfe1 to a host. These interfaces remain persistent across reboots.
# dladm show-link
eri0 type: legacy mtu: 1500 device: eri0
qfe0 type: legacy mtu: 1500 device: qfe0
qfe1 type: legacy mtu: 1500 device: qfe1
qfe2 type: legacy mtu: 1500 device: qfe2
qfe3 type: legacy mtu: 1500 device: qfe3
bge0 type: non-vlan mtu: 1500 device: bge0
# vi /etc/hostname.qfe0
192.168.84.3 netmask 255.255.255.0
# vi /etc/hostname.qfe1
192.168.84.72 netmask 255.255.255.0
# vi /etc/inet/hosts
# Internet host table
#
127.0.0.1 localhost
10.0.0.14 myhost
192.168.84.3 interface-2
192.168.84.72 interface-3
For Solaris 10 11/06 and earlier releases:# vi /etc/inet/ipnodes
10.0.0.14 myhost
192.168.84.3 interface-2
192.168.84.72 interface-3
At this point, you would reboot the system.
# reboot — -r
After the system boots, you would then verify the interface configuration.
ifconfig -a
# 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 2
inet 10.0.0.14netmask ff000000 broadcast 10.255.255.255
ether 8:0:20:c1:8b:c3
qfe0:flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.84.3 netmask ffffff00 broadcast 192.255.255.255
ether 8:0:20:c8:f4:1d
qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4
inet 192.168.84.72 netmask ffffff00 broadcast 10.255.255.255
ether 8:0:20:c8:f4:1e
See Also
To configure an IPv6 address onto an interface, refer to How to Enable an IPv6 Interface for the Current Session.

To set up failover detection and failback for interfaces by using IP Network Multipathing (IPMP), refer to Chapter 31, Administering IPMP (Tasks).

Previous: How to Obtain Interface Status
Next: How to Remove a Physical Interface