Solaris Networking
Solaris Basic Network Configuration
Solaris comes with a bounteous supply of startup scripts. Solaris stashes some network configuration files in /etc and some in /etc/inet. Many are duplicated through the magic of symbolic links, with the actual files living in /etc/inet and the links in /etc.
To set the hostname, enter it into the file /etc/nodename. The change will take effect when the machine is rebooted. Some sites use just the short hostname. Others use the fully qualified domain name.
The /etc/defaultdomain file’s name suggests that it might be used to specify the DNS domain, but it actually specifies the NIS and NIS+ domain name. The DNS domain is specified in /etc/resolv.conf as usual.
Solaris uses /etc/nsswitch.conf to set the order in which /etc/hosts, NIS, NIS+, and DNS are consulted for hostname resolution. We recommend looking at the hosts file, then DNS for easy booting. A line from nsswitch.conf would be
hosts: files dns
This is the default configuration if the host receives the addresses of its DNS server through DHCP.
Solaris networking can run in traditional mode or in “Network Auto-Magic” (NWAM) mode, where networking is managed autonomously by the nwamd daemon. NWAM mode is fine for workstations, but it has limited configurability and allows only one network interface to be active at a time. What follows assumes traditional mode.
To see which networking mode is active, run svcs svc:/network/physical. There should be two configuration lines, one for NWAM and one for the traditional mode, i.e. default. Run svcadm to switch the configuration. For example, the following exchange shows the system being taken from NWAM to traditional mode.
$ svcs svc:/network/physical STATE STIME FMRI Disabled Mar_31 svc:/network/physical:default Online Mar_31 svc:/network/physical:nwam $ sudo svcadm disable svc:/network/physical:nwam $ sudo svbcadm enable svc:/network/physical:default
Solaris configures the IP address of each network interface through a file called /etc/hostname.interface, where interface is the usual name of the interface. These files can contain either a hostname that appears in the hosts file or an IP address. The value in a hostname.interface file is used as the address parameter to ifconfig, so it is safest to use an address, even though the configuration filename implies that a hostname is expected.
Any special ifconfig options can also be put in the hostname.interface file on the same line as the hostname or IP address. It is all one big ifconfig command line. The startup scripts try to discover the IP addresses of any interfaces without corresponding hostname files by using DHCP.
As shipped, the Solaris startup files rely on using the ifconfig options netmask + and broadcast +. The pluses mean to look in /etc/netmasks for the netmask value and to figure out the broadcast address value from it. The /etc/netmasks file lists network numbers and their corresponding netmask values. Any network that is subnetted differently from its inherent network class, e.g. A, B, or C, must be represented in the file. Here is an example of a netmasks file from SPARC2:
# # 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.48.0 255.255.255.128
From the textbook we have:
# CS Department network masks database # Network netmask # ======####### # 128.138.0.0 255.255.255.192 # default for dept # 128.138.192.64 255.255.255.192 # drag 128.138.192.192 255.255.255.192 # csops 128.138.193.0 255.255.255.224 # bcrg 128.138.193.32 255.255.255.224 # database 128.138.198.0 255.255.255.0 # slip …………
The first line sets a default of /26 for the class B address 128.138.0.0, which is then overridden with specific masks that vary from the default. All networks are listed, even though many use the default value and could in fact be left out. On the systems from which this example is taken the netmasks file is centrally maintained and distributed to all hosts. No single host has interfaces on all of these networks. The startup scripts live in /lib/sbc/method on Solaris 10 operating systems.
If /etc/defaultrouter exists, it is assumed to contain the identity which again can be either a hostname or a numeric address of the default gateway, and no further routing configuration is performed. As usual, a numeric address is preferable. Using a name requires an /etc/hosts entry or a DNS server on the local network.
Solaris Configuration Examples
Here are some examples of the commands needed to bring up a Solaris interface and add a route to a default gateway:
$ sudo ifconfig e1000g0 plumb $ sudo ifconfig e1000g0 192.108.21.48 netmask 255.255.255.0 up $ sudo route add default 192.108.21.254
The following examples show how to see the status of network interfaces and routing tables. Commands prefaced with sudo must be run as root. The final example shows a feature of the Solaris route command that is not present on other architectures: the get argument shows the next hop to a particular destination. We have taken some liberties to make the examples fit the screen. From Orange we have
$ /sbin/ifconfig -a lo0: flags=2001000849
$ sudo ifconfig e1000g0 e1000g0: flags=1004843
Notice that when run as root, ifconfig shows the hardware address, but when run as a user, it does not.
$ netstat -r
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface ------default 172.19.48.1 UG 1 1662696 e1000g0 172.19.48.0 CPSC424-Orange U 1 809 e1000g0 BASE-ADDRESS.MCAST.NET CPSC424-Orange U 1 0 e1000g0 localhost localhost UH 1 92 lo0
solaris$ route get google.com route to: yw-in-f99.1e100.net destination: default mask: default gateway: 172.19.48.1 interface: e1000g0 flags:
Solaris DHCP Configuration
Solaris includes a DHCP client and wins the prize for the easiest and most sensible DHCP client configuration:
$ sudo ifconfig interface dhcp
It just works! ifconfig calls the dhcpagent program to get the parameters for the interface from DHCP and to configure the interface with them. You can include several options on the ifconfig command line to specify the interface as the primary one, set timeouts, increase lease times, or display the status of the interface. To manually unconfigure DHCP, just run
$ sudo ifconfig interface drop
This is all very nice, but you probably want DHCP to be automatically consulted at boot time. You can set this up either by providing no configuration files for an interface at all, thus relying on autoconfiguration, or by creating an /etc/dhcp.interface file to go with the corresponding /etc/hostname.interface file. If you like, the dhcp.interface file can contain additional command-line parameters to be passed to the ifconfig command.
The hostname.interface file must still exist to get the interface to be plumbed. However, it can be left empty. If the hostname.interface file is not empty, the startup scripts will first statically configure the interface by using its content and then later reconfigure the interface by using DHCP. dhcpagent manages the interface from DHCP’s point of view. Among other tasks, it negotiates extensions to leases and cancels leases when they are no longer needed. If an interface that has been configured with DHCP is later reconfigured by hand, dhcpagent will discontinue management of that interface. dhcpagent collects the leased values from the DHCP server, default route, domain name servers, etc, but it does not act on most of them directly. Instead, it makes the parameters available through the dhcpinfo command. The service management scripts consult dhcpinfo for various pieces of information, which are then used as arguments to route, put into the resolv.conf file, etc. dhcpagent transmits errors to syslog with facility daemon and priorities info through critical. Debug-level syslog output is available with the -d flag.
You can check the files in /etc/dhcp to view the configuration of a particular interface. However, the existence of an interface.dhc file for an interface does not necessarily mean that dhcpagent is currently controlling the interface – the lease may have expired.
ndd: TCP/IP and Interface Tuning For Solaris
Solaris’s ndd command reconfigures the TCP/IP protocol stack on a running system. Perhaps “reconfigure” is too strong a word. Each module exposes parameters that can be examined and in some cases adjusted on the fly.
The basic syntax is
nnd [ -set ] device ? | variable [ value ]
If you give the argument ?, which must be protected from the shell as \?, ndd returns a list of variables understood by the driver for the specific device. If you supply the name of a variable, nnd returns the value of that variable. If you use the -set flag and supply a value, the specified variable is set to the value you specify.
Unfortunately, the ndd man page does not tell you the possible names of devices, and it does not tell you that you must be root to run ndd on some devices, e.g. ip and hme, and not on others, e.g. tcp and udp. The table below provides a quick cheat sheet.
Device Description Variable Names /dev/tcp TCP protocol variables tcp_* /dev/udp UDP protocol variables udp_* /dev/ip IP protocol variables ip_* and ip6_* /dev/icmp ICMP protocol variables icmp_* /dev/rawip Identical to /dev/icmp icmp_* /dev/arp ARP protocol variables arp_* Devices you can probe with Solaris’s ndd command
Interface-specific variable names in the /dev/ip category control IP forwarding on specific network interfaces. For example, e1000g0:ip_forwarding controls IP forwarding on /dev/e1000g0. There is a global ip_forwarding variable, also.
Solaris Security
The table below shows Solaris’s default behavior with regards to various touchy network issues. You can adjust most of these setting with ndd.
Feature Default nnd variable IP forwarding off ip_forwarding ICMP redirects obeys cannot be changed Source routing ignores ip_forward_src_routed Broadcast ping (respond) on ip_respond_to_echo_broadcast Broadcast ping (forward) off ip_forward_directed_broadcasts
Security-Related Network Behaviors in Solaris
Solaris Firewalls and Filtering
You generally should not use a UNIX box as a firewall or NAT gateway. Use a dedicated piece of network hardware instead. Solaris used to make it easy to follow this rule by not including any filtering software, but Darren Reed’s free IPFilter software has now been bundled into the basic distribution. If you must use a UNIX-based filter, Solaris is a good choice.
The IPFilter suite implements IP filtering, NAT, and transparent port forwarding. It is free, open source, and works on either SPARC or Intel hardware. The IPFilter package includes ipf for configuring a firewall, ipfstat for printing out the filter rules that have been installed, and ipnat for implementing NAT.
Solaris NAT
To make NAT work, you must tell the kernel what addresses to map from, what addresses to map to, and what port range to use to extend the address space. To configure NAT, you supply rules to the ipnat command. The rules are similar to those used with ipf to implement packet filtering. But beware, like ipf rules, ipnat rules are ordered. However, they have opposite precedence. Just to keep you on your toes, the first matching rule is selected, not the last.
Below are some examples of ipnat rules. To be activated at boot time, these would go in the /etc/ipf/ipnat.conf file:
map eth1 192.168.1.0/24 -> 128.138.198.0/26 portmap tcp/udp 20000:65000 map eth1 192.168.1.0/24 -> 128.138.198.0/26
We have assumed that eth1 is our interface to the Internet and that our internal network is numbered with the class C private address space range. These rules map addresses from a /24 network into addresses from a /26 network. Since a /26 network can accommodate only one-quarter of the hosts that a /24 network can, it is potentially possible to run out of target addresses in this configuration. But the portmap clause extends the address range by allowing each address to be used with 45,000 different source ports.
The first rule above covers all TCP and UDP traffic but does not affect ICMP. ICMP does not use the concept of a port. The second rule catches ICMP messages and tries to get them routed back to the right host. If the kernel cannot unambiguously determine who should receive a particular ICMP message, it sends the packet out as a broadcast. Machines that receive it out of context can just ignore it.
Solaris Networking Quirks
The output of ifconfig –a is different when it is run as root than when it is run as a regular user. When run by root, it shows the link-level Ethernet addresses in addition to the IP addresses and parameters.
Solaris lets you change the link-level (MAC) address of a network interface with the ifconfig command and the address family ether. This feature can be useful if you need to worm your way onto a MAC- restricted wireless network.