System Administration Guide: IP Services

Chapter 5 Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

TCP/IP network administration evolves in two stages. The first stage is to assemble the hardware. Then, you configure the daemons, files, and services that implement the TCP/IP protocol.

This chapter explains how to configure TCP/IP on a network that implements IPv4 addressing and services.


Note –

Many of the tasks in this chapter apply to both IPv4-only and IPv6-enabled networks. Where configuration tasks differ between the two addressing formats, the IPv4 configuration steps are in this chapter. The tasks in this chapter then cross reference the equivalent IPv6 tasks in Chapter 7, Configuring an IPv6 Network (Tasks).


This chapter contains the following information:

What's New in This Chapter

In Solaris 10 8/07, the following changes are made:

Before You Configure an IPv4 Network (Task Map)

Before you configure TCP/IP, complete the tasks that are listed in the following table. 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 

1. Design the network topology. 

Determine the physical layout of the network. 

Network Topology Overview and IPv4 Autonomous System Topology

2. Obtain a network number from your ISP or Regional Internet Registry (RIR). 

Get a registered network number, which enables systems at your site to communicate externally. 

Designing Your IPv4 Addressing Scheme.

3. Plan the IPv4 addressing scheme for the network. If applicable, include subnet addressing. 

Use the network number as the basis for your addressing plan. 

Designing Your IPv4 Addressing Scheme.

4. Assemble the network hardware depending on the network topology. Assure that the hardware is functioning properly. 

Set up the systems, network media, routers, switches, hubs and bridges that you outlined in the network topology design. 

The hardware manuals and Network Topology Overview.

5. Assign IPv4 addresses and host names to all systems in the network. 

Assign the IPv4 addresses during Oracle Solaris installation or post installation, in the appropriate files. 

Designing Your IPv4 Addressing Scheme and How to Change the IPv4 Address and Other Network Configuration Parameters

6. Run configuration software that is required by network interfaces and routers, if applicable. 

Configure routers and multihomed hosts. 

Planning for Routers on Your Network and Configuring an IPv4 Router for information on routers.

7. Determine which name service or directory service your network uses: NIS, LDAP, DNS, or local files. 

Configure your selected name service and/or directory service. 

System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

8. Select domain names for your network, if applicable. 

Choose a domain name for your network and register it with the InterNIC. 

System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Determining Host Configuration Modes

As a network administrator, you configure TCP/IP to run on hosts and routers (if applicable). You can configure these systems to obtain configuration information from files on the local system or from files that are located on other systems on the network. You need the following configuration information:

A system that obtains TCP/IP configuration information from local files operates in local files mode. A system that obtains TCP/IP configuration information from a remote network server operates in network client mode.

Systems That Should Run in Local Files Mode

To run in local files mode, a system must have local copies of the TCP/IP configuration files. These files are described in TCP/IP Configuration Files. The system should have its own disk, though this recommendation is not strictly necessary.

Most servers should run in local files mode. This requirement includes the following servers:

Additionally, routers should run in local files mode.

Systems that function exclusively as print servers do not need to run in local files mode. Whether individual hosts should run in local files mode depends on the size of your network.

If you are running a very small network, the amount of work that is involved in maintaining these files on individual hosts is manageable. If your network serves hundreds of hosts, the task becomes difficult, even with the network divided into a number of administrative subdomains. Thus, for large networks, using local files mode is usually less efficient. However, because routers and servers must be self-sufficient, they should be configured in local files mode.

Network Configuration Servers

Network configuration servers are the servers that supply the TCP/IP configuration information to hosts that are configured in network client mode. These servers support three booting protocols:

Network configuration servers can also function as NFS file servers.

If you are configuring any hosts as network clients, then you must also configure at least one system on your network as a network configuration server. If your network is subnetted, then you must have at least one network configuration server for each subnet with network clients.

Systems That Are Network Clients

Any host that obtains its configuration information from a network configuration server operates in network client mode. Systems that are configured as network clients do not require local copies of the TCP/IP configuration files.

Network client mode simplifies administration of large networks. Network client mode minimizes the number of configuration tasks that you perform on individual hosts. Network client mode assures that all systems on the network adhere to the same configuration standards.

You can configure network client mode on all types of computers. For example, you can configure network client mode on standalone systems.

Mixed Configurations

Configurations are not limited to either an all-local-files mode or an all-network-client mode. Routers and servers should always be configured in local mode. For hosts, you can use any combination of local files and network client mode.

IPv4 Network Topology Scenario

Figure 5–1 shows the hosts of a fictitious network with the network number 192.9.200. The network has one network configuration server, which is called sahara. Hosts tenere and nubian have their own disks and run in local files mode. Host faiyum also has a disk, but this system operates in network client mode.

Finally, the system timbuktu is configured as a router. The system includes two network interfaces. The first interface is named timbuktu. This interface belongs to network 192.9.200. The second interface is named timbuktu-201. This interface belongs to network 192.9.201. Both networks are in the organizational domain deserts.worldwide.com. The domain uses local files as its name service.

Figure 5–1 Hosts in an IPv4 Network Topology Scenario

Diagram shows a sample network with one network server
that serves four hosts.

Adding a Subnet to a Network (Task Map)

If you are changing from a network that does not use a subnet to a network that does use a subnet, perform the tasks in the following task map.


Note –

The information in this section applies to IPv4 subnets only. For information on planning IPv6 subnets, refer to Preparing the Network Topology for IPv6 Support and Creating a Numbering Scheme for Subnets.


The following table lists different tasks for adding a subnet to the current network. 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 

1. Determine if your network topology requires subnets. 

Decide on the new subnet topology, including where to locate routers and hosts on the subnets. 

Planning for Routers on Your Network, What Is Subnetting?, and Network Classes

2. Assign the IP addresses with the new subnet number to the systems to become members of the subnet. 

Configure IP addresses that use the new subnet number, either during Oracle Solaris installation or later, in the /etc/hostname.interface file.

Deciding on an IP Addressing Format for Your Network

3. Configure the network mask of the subnet on all prospective systems in the subnet. 

Modify the /etc/inet/netmasks file, if you are manually configuring network clients. Or, supply the netmask to the Oracle Solaris installation program.

netmasks Database and Creating the Network Mask for IPv4 Addresses

4. Edit the network databases with the new IP addresses of all systems in the subnet. 

Modify /etc/inet/hosts and, for Solaris 10 11/06 and earlier releases,/etc/inet/ipnodes, on all hosts to reflect the new host addresses.

hosts Database

5. Reboot all systems. 

   

Network Configuration Task Map

The following table lists additional tasks to perform after changing from a network configuration without subnets to a network that uses subnets. 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 

Configure a host for local files mode 

Involves editing the nodename, hostname, hosts, defaultdomain, defaultrouter, and netmasks files

How to Configure a Host for Local Files Mode

Set up a network configuration server 

Involves turning on the in.tftp daemon, and editing the hosts, ethers, and bootparams files

How to Set Up a Network Configuration Server

Configure a host for network client mode 

Involves creating the hostname file, editing the hosts file, and deleting the nodename and defaultdomain files, if they exist

How to Configure Hosts for Network Client Mode

Specify a routing strategy for the network client 

Involves determining whether to use static routing or dynamic routing on the host. 

How to Enable Static Routing on a Single-Interface Host and How to Enable Dynamic Routing on a Single-Interface Host.

Modify the existing network configuration  

Involves changing the host name, IP address, and other parameters that were set at installation or configured at a later time. 

How to Change the IPv4 Address and Other Network Configuration Parameters

Configuring Systems on the Local Network

Network software installation occurs along with the installation of the operating system software. At that time, certain IP configuration parameters must be stored in appropriate files so that they can be read at boot time.

The network configuration process involves creating or editing the network configuration files. How configuration information is made available to a system's kernel is conditional. The availability depends on whether these files are stored locally (local files mode) or acquired from the network configuration server (network client mode).

The parameters that are supplied during network configuration follow:

If the Oracle Solaris installation program detects more one interface on the system, you can optionally configure the additional interfaces during installation. For complete instructions, see Oracle Solaris 10 9/10 Installation Guide: Basic Installations.

This chapter contains information on creating and editing local configuration files. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on working with name service databases.

ProcedureHow to Configure a Host for Local Files Mode

Use this procedure for configuring TCP/IP on a host that runs in local files mode.

  1. 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.

  2. Change to the /etc directory.

  3. Verify that the correct host name is set in the /etc/nodename file.

    When you specify the host name of a system during Oracle Solaris installation, that host name is entered into the /etc/nodename file. Make sure that the node name entry is the correct host name for the system.

  4. Verify that an /etc/hostname.interface file exists for each network interface on the system.

    For file syntax and basic information about the /etc/hostname.interface file, refer to Basics for Administering Physical Interfaces.

    The Oracle Solaris installation program requires you to configure at least one interface during installation. The first interface that you configure automatically becomes the primary network interface. The installation program creates an /etc/hostname.interface file for the primary network interface and any other interfaces that you optionally configure at installation time.

    If you configured additional interfaces during installation, verify that each interface has a corresponding /etc/hostname.interface file. You do not need to configure more than one interface during Oracle Solaris installation. However, if you later want to add more interfaces to the system, you must manually configure them.

    For steps for manually configuring interfaces, refer to Administering Interfaces in Solaris 10 3/05 or How to Configure a Physical Interface After System Installation, for releases starting with Solaris 10 1/06.

  5. For Solaris 10 11/06 and earlier releases, verify that the entries in the /etc/inet/ipnodes file are current.

    The Oracle Solaris 10 installation program creates the /etc/inet/ipnodes file. This file contains the node name and IPv4 address, and IPv6 address, if appropriate, of every interface that is configured during installation.

    Use the following format for entries in the /etc/inet/ipnodes file:


    IP-address node-name nicknames...
    

    nicknames are additional names by which an interface is known.

  6. Verify that the entries in the /etc/inet/hosts file are current.

    The Oracle Solaris installation program creates entries for the primary network interface, loopback address, and, if applicable, any additional interfaces that were configured during installation.

    1. Make sure that the existing entries in /etc/inet/hosts are current.

    2. (Optional) Add the IP addresses and corresponding names for any network interfaces that were added to the local host after installation.

    3. (Optional) Add the IP address or addresses of the file server, if the /usr file system is NFS mounted.

  7. Type the host's fully qualified domain name in the /etc/defaultdomain file.

    For example, suppose host tenere was part of the domain deserts.worldwide.com. Therefore, you would type deserts.worldwide.com in /etc/defaultdomain. See /etc/defaultdomain File for more information.

  8. Type the router's name in the /etc/defaultrouter file.

    See /etc/defaultrouter File for information about this file.

  9. Type the name of the default router and its IP addresses in the /etc/inet/hosts file.

    Additional routing options are available, as discussed in How to Configure Hosts for Network Client Mode. You can apply these options to a local files mode configuration.

  10. Add the network mask for your network, if applicable:

    • If the host gets its IP address from a DHCP server, you do not have to specify the network mask.

    • If you have set up a NIS server on the same network as this client, you can add netmask information into the appropriate database on the server.

    • For all other conditions, do the following:

    1. Type the network number and the netmask in the /etc/inet/netmasks file.

      Use the following format:


      network-number netmask

      For example, for the Class C network number 192.168.83, you would type:


      192.168.83.0    255.255.255.0
      

      For CIDR addresses, convert the network prefix into the equivalent dotted decimal representation. Network prefixes and their dotted decimal equivalents can be found in Table 2–3. For example, use the following to express the CIDR network prefix 192.168.3.0/22.


      192.168.3.0 255.255.252.0
    2. Change the lookup order for netmasks in /etc/nsswitch.conf, so that local files are searched first:


      netmasks:   files nis
  11. Reboot the system.

ProcedureHow to Set Up a Network Configuration Server

Information for setting up installation servers and boot servers is found in Oracle Solaris 10 9/10 Installation Guide: Basic Installations.

  1. 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.

  2. Change to the root (/) directory of the prospective network configuration server.

  3. Turn on the in.tftpd daemon by creating the directory /tftpboot:


    # mkdir /tftpboot
    

    This command configures the system as a TFTP, bootparams, and RARP server.

  4. Create a symbolic link to the directory.


    # ln -s /tftpboot/. /tftpboot/tftpboot
    
  5. Enable the tftp line in the /etc/inetd.conf file.

    Check that the entry reads as follows:


    tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

    This line prevents in.tftpd from retrieving any file other than the files that are located in /tftpboot.

  6. Edit the hosts database.

    Add the host names and IP addresses for every client on the network.

  7. Edit the ethers database.

    Create entries for every host on the network that runs in network client mode.

  8. Edit the bootparams database.

    See bootparams Database. Use the wildcard entry or create an entry for every host that runs in network client mode.

  9. Convert the /etc/inetd.conf entry into a Service Management Facility (SMF) service manifest, and enable the resulting service:


    # /usr/sbin/inetconv
    
  10. Verify that in.tftpd is working correctly.


    # svcs network/tftp/udp6
    

    You should receive output resembling the following:


    STATE          STIME    FMRI
    online         18:22:21 svc:/network/tftp/udp6:default
Administering the in.tftpd Daemon

The in.tftpd daemon is managed by the Service Management Facility. Administrative actions on in.tftpd, such as enabling, disabling, or restarting, can be performed using the svcadm command. Responsibility for initiating and restarting this service is delegated to inetd. Use the inetadm command to make configuration changes and to view configuration information for in.tftpd. You can query the service's status by using the svcs command. For an overview of the Service Management Facility, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.

Configuring Network Clients

Network clients receive their configuration information from network configuration servers. Therefore, before you configure a host as a network client you must ensure that at least one network configuration server is set up for the network.

ProcedureHow to Configure Hosts for Network Client Mode

Do the following procedure on each host to be configured in network client mode.

  1. 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.

  2. Search the /etc directory for the nodename file.

    If such a file exists, delete it.

    Eliminating /etc/nodename causes the system to use the hostconfig program to obtain the host name, domain name, and router addresses from the network configuration server. See Configuring Systems on the Local Network.

  3. Create the /etc/hostname.interface file, if it does not exist.

    Ensure that the file is empty. An empty /etc/hostname.interface file causes the system to acquire the IPv4 address from the network configuration server.

  4. Ensure that the /etc/inet/hosts file contains only the localhost name and IP address of the loopback network interface.


    # cat /etc/inet/hosts
    # Internet host table
    #
    127.0.0.1       localhost

    The IPv4 loopback interface has the IP address 127.0.0.1.

    For more information, see Loopback Address. The file should not contain the IP address and host name for the local host (primary network interface).

  5. Check for the existence of an /etc/defaultdomain file.

    If such a file exists, delete it.

    The hostconfig program automatically sets the domain name. To override the domain name that is set by hostconfig, type the substitute domain name in the /etc/defaultdomain file.

  6. Ensure that the search paths in the client's /etc/nsswitch.conf file reflect the name service requirements for your network.

ProcedureHow to Change the IPv4 Address and Other Network Configuration Parameters

This procedure explains how to modify the IPv4 address, host name, and other network parameters on a previously installed system. Use the procedure for modifying the IP address of a server or networked standalone system. The procedure does not apply to network clients or appliances. The steps create a configuration that persists across reboots.


Note –

The instructions apply specifically to changing the IPv4 address of the primary network interface. To add another interface to the system, refer to How to Configure a Physical Interface After System Installation.


In almost all cases, the following steps use traditional IPv4 dotted decimal notation to specify the IPv4 address and subnet mask. Alternatively, you can use CIDR notation to specify the IPv4 address in all the applicable files in this procedure. For an introduction to CIDR notation, see IPv4 Addresses in CIDR Format.

  1. 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.

  2. For Solaris 10 11/06 and earlier releases only, modify the IP address in the /etc/inet/ipnodes file or equivalent ipnodes database.

    Use the following syntax for each IP address that you add to the system:


    IP-address host-name, nicknames
    IP-address interface-name, nicknames
    

    The first entry should contain the IP address of the primary network interface and the host name of the system. You can optionally add nicknames for the host name. When you add additional physical interfaces to a system, create entries in /etc/inet/ipnodes for the IP addresses and associated names of those interfaces.

  3. If the system's host name must change, modify the host name entry in the /etc/nodename file.

  4. Modify the IP address and, if applicable, the host name in the /etc/inet/hosts file or equivalent hosts database.

  5. Modify the IP address in the /etc/hostname.interface file for the primary network interface.

    You can use any of the following as the entry for the primary network interface in the /etc/hostnameinterface file:

    • IPv4 address, expressed in traditional dotted decimal format

      Use the following syntax:


      IPv4 address subnet mask
      

      The netmask entry is optional. If you do not specify it, the default netmask is assumed.

      Here is an example:


      # vi hostname.eri0
      10.0.2.5 netmask 255.0.0.0
      
    • IPv4 address, expressed in CIDR notation, if appropriate for your network configuration.


      IPv4 address/network prefix
      

      Here is an example:


      # vi hostname.eri0
      10.0.2.5/8
      

      The CIDR prefix designates the appropriate netmask for the IPv4 address. For example, the /8 above indicates the netmask 255.0.0.0.

    • Host name.

      To use the system's host name in the /etc/hostname.interface file, be sure that the host name and associated IPv4 address are also in the hosts database.

  6. If the subnet mask has changed, modify the subnet entries in the following files:

    • /etc/netmasks

    • (Optional) /etc/hostname.interface

  7. If the subnet address has changed, change the IP address of the default router in /etc/defaultrouter to that of the new subnet's default router.

  8. Reboot the system.


    # reboot -- -r
    

Example 5–1 Modifying the IPv4 Address and Other Network Parameters to Persist Across Reboots

This example shows how to change the following network parameters of a system that is moved to another subnet:

Check the system's current status:


# hostname
myhost
# 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.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 

Next, change the system's host name and the IP address of eri0 in the appropriate files:


# vi /etc/nodename
mynewhostname

In Solaris 10 11/06 and earlier Solaris 10 releases only, do the following:
# vi /etc/inet/ipnodes
192.168.55.14   mynewhostname      #moved system to 192.168.55 net

# vi /etc/inet/hosts
#
# Internet host table
#
127.0.0.1       localhost
192.168.55.14   mynewhostname        loghost
# vi /etc/hostname.eri0
192.168.55.14   netmask  255.255.255.0

Finally, change the netmask and the IP address of the default router.


# vi /etc/netmasks.
.
.
192.168.55.0    255.255.255.0
# vi /etc/defaultrouter
192.168.55.200        #moved system to 192.168.55 net
#

After making these changes, reboot the system.


# reboot -- -r

Verify that the configuration you just set is maintained after the reboot:


# hostname
mynewhostname
# 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 192.168.55.14 netmask ffffff00 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 


Example 5–2 Changing the IP Address and Host Name For the Current Session

This example shows how to change a host's name, IP address of the primary network interface, and subnet mask for the current session only. If you reboot, the system reverts to its previous IP address and subnet mask. The IP address for the primary network interface eri0 changes from 10.0.0.14 to 192.168.34.100.


# 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.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# ifconfig eri0 192.168.34.100 netmask 255.255.255.0 broadcast + up
# vi /etc/nodename
mynewhostname

# 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 192.168.34.100 netmask ffffff00 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# hostname
mynewhostname


Example 5–3 Changing the IPv4 Address for the Current Session, Using CIDR Notation

This example shows how to change a host name and IP address for the current session only, using CIDR notation. If you reboot, the system reverts to its previous IP address and subnet mask. The IP address for the primary network interface, eri0, changes from 10.0.0.14 to 192.168.6.25/27.


# 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.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# ifconfig eri0 192.168.6.25/27 broadcast + up
# vi /etc/nodename
mynewhostname
# 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 192.168.06.25 netmask ffffffe0 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# hostname
mynewhostname

When you use CIDR notation for the IPv4 address, you do not have to specify the netmask. ifconfig uses the network prefix designation to determine the netmask. For example, for the 192.168.6.0/27 network, ifconfig sets the netmask ffffffe0. If you had used the more common /24 prefix designation, the resulting netmask is ffffff00. Using the /24 prefix designation is the equivalent of specifying the netmask 255.255.255.0 to ifconfig when configuring a new IP address.


See Also

To change the IP address of an interface other than the primary network interface, refer to System Administration Guide: Basic Administration and How to Configure a Physical Interface After System Installation.

Packet Forwarding and Routing on IPv4 Networks

This section contains procedures and examples that show how to configure forwarding and routing for routers and hosts on IPv4 networks.

Packet forwarding is the basic method for sharing information across systems on a network. Packets are transferred between a source interface and a destination interface, usually on two different systems. When you issue a command or send a message to a nonlocal interface, your system forwards those packets onto the local network. The interface with the destination IP address that is specified in the packet headers then retrieves the packets from the local network. If the destination address is not on the local network, the packets are then forwarded to the next adjacent network, or hop. By default, packet forwarding is automatically configured when you install Oracle Solaris.

Routing is the process by which systems decide where to send a packet. Routing protocols on a system “discover” the other systems on the local network. When the source system and the destination system are on the same local network, the path that packets travel between them is called a direct route. If a packet must travel at least one hop beyond its source system, the path between the source system and destination system is called an indirect route. The routing protocols learn the path to a destination interface and retain data about known routes in the system's routing table.

Routers are specially configured systems with multiple physical interfaces that connect the router to more than one local network. Therefore, the router can forward packets beyond the home LAN, regardless of whether the router runs a routing protocol. For more information about how routers forward packets, refer to Planning for Routers on Your Network.

Routing protocols handle routing activity on a system and, by exchanging routing information with other hosts, maintain known routes to remote networks. Both routers and hosts can run routing protocols. The routing protocols on the host communicate with routing daemons on other routers and hosts. These protocols assist the host in determining where to forward packets. When network interfaces are enabled, the system automatically communicates with the routing daemons. These daemons monitor routers on the network and advertise the routers' addresses to the hosts on the local network. Some routing protocols, though not all, also maintain statistics that you can use to measure routing performance. Unlike packet forwarding, you must explicitly configure routing on an Oracle Solaris system.

This section contains tasks for administering packet forwarding and routing on IPv4 routers and hosts. For information about routing on an IPv6-enabled network, refer to Configuring an IPv6 Router.

Routing Protocols Supported by Oracle Solaris

Routing protocols are classified as interior gateway protocols (IGPs), exterior gateway protocols (EGPs), or a combination of both. Interior gateway protocols exchange routing information between routers on networks under common administrative control. In the network topology shown in Figure 5–3, the routers run an IGP for exchanging routing information. Exterior gateway protocols enable the router that connects the local internetwork to an external network to exchange information with another router on the external network. For example, the router that connects a corporate network to an ISP runs an EGP to exchange routing information with its router counterpart at the ISP. Border Gateway Protocol (BGP) is a popular EGP that is used for carrying routing information between different organizations and IGPs.

The following table provides information about the Oracle Solaris routing protocols and the location of each protocol's associated documentation.

Table 5–1 Oracle Solaris Routing Protocols

Protocol 

Associated Daemon 

Description 

For Instructions 

Routing Information Protocol (RIP) 

in.routed

IGP that routes IPv4 packets and maintains a routing table 

How to Configure an IPv4 Router

Internet Control Message Protocol (ICMP) Router Discovery 

in.routed

Used by hosts to discover the presence of a router on the network 

How to Enable Static Routing on a Single-Interface Host and How to Enable Dynamic Routing on a Single-Interface Host

Routing Information Protocol, next generation (RIPng) Protocol 

in.ripngd

IGP that routes IPv6 packets and maintains a routing table 

How to Configure an IPv6-Enabled Router

Neighbor Discovery (ND) Protocol 

in.ndpd

Advertises the presence of an IPv6 router and discovers the presence of IPv6 hosts on a network 

Configuring an IPv6 Interface

Oracle Solaris 10 also supports the Open Source Quagga routing protocol suite. These protocols are available from the SFW consolidation disk, though they are not part of the mainOracle Solaris distribution. The following table lists the Quagga protocols:

Table 5–2 OpenSolaris Quagga Protocols

Protocol 

Daemon  

Description 

RIP protocol 

ripd

IPv4 distance vectoring IGP that routes IPv4 packets and advertises its routing table to neighbors. 

RIPng 

ripngd

IPv6 distance vectoring IGP. Routes IPv6 packets and maintains a routing table. 

Open Shortest Path First (OSPF) protocol 

ospfd

IPv4 link state IGP for packet routing and high availability networking 

Border Gateway Protocol (BGP) 

bgpd

IPv4 and IPv6 EGP for routing across administrative domains. 

The following figure shows an autonomous system that uses the Quagga routing protocols:

Figure 5–2 Corporate Network That Runs Quagga Protocols

This figure shows a corporate network that runs the Quagga
routing protocols. The context explains the figure.

The figure shows a corporate network autonomous system that is subdivided into two routing domains, A and B. Arouting domain is an internetwork with a cohesive routing policy, either for administrative purposes or because the domain uses a single routing protocol. Both domains in the figure run routing protocols from the Quagga protocol suite.

Routing Domain A is an OSPF domain, which is administered under a single OSPF domain ID. All systems within this domain run OSPF as their interior gateway protocol. In addition to internal hosts and routers, Domain A includes two border routers.

Border router R1 connects the Corporate Network to an ISP and ultimately the Internet. To facilitate communications between the Corporate Network and the outside world, R1 runs BGP over its externally facing network interface. The border router R5 connects Domain A with Domain B. All systems on Domain B are administered with RIP as their interior gateway protocol. Therefore, border router R5 must run OSPF on the Domain A facing interface and RIP on the Domain B facing interface.

For more information on the Quagga protocols, refer to the Open Solaris Quagga. For configuration procedures for these protocols, go to the documentation for quagga.

IPv4 Autonomous System Topology

Sites with multiple routers and networks typically administer their network topology as a single routing domain, or autonomous system (AS) . The following figure shows a typical network topology that would be considered a small AS. This topology is referenced in the examples throughout this section.

Figure 5–3 Autonomous System With Multiple IPv4 Routers

This topology diagram of an autonomous system is explained
in the following context.

The figure shows an AS that is divided into three local networks, 10.0.5.0, 172.20.1.0, and 192.168.5. Four routers share packet-forwarding and routing responsibilities. The AS includes the following types of systems:

Configuring an IPv4 Router

This section contains a procedure and example for configuring an IPv4 router. To configure an IPv6-enabled router, refer to How to Configure an IPv6-Enabled Router.

Because a router provides the interface between two or more networks, you must assign a unique name and IP address to each of the router's physical network interfaces. Thus, each router has a host name and an IP address that are associated with its primary network interface, in addition to a minimum of one more unique name and IP address for each additional network interface.

You can also use the following procedure to configure a system with only one physical interface (by default, a host) to be a router. You might configure a single interface system as a router if the system serves as one endpoint on a PPP link, as explained in Planning a Dial-up PPP Link in System Administration Guide: Network Services.


Note –

You can configure all interfaces of a router during Oracle Solaris system installation. For instructions, see Oracle Solaris 10 9/10 Installation Guide: Basic Installations.


ProcedureHow to Configure an IPv4 Router

The following instructions assume that you are configuring interfaces for the router after installation.

Before You Begin

After the router is physically installed on the network, configure the router to operate in local files mode, as described in How to Configure a Host for Local Files Mode. This configuration ensures that routers boot if the network configuration server is down.

  1. On the system to be configured as a router, 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.

  2. Starting in the Solaris 10 1/06 release, use the dladm show-link command to determine which interfaces are physically installed on the router.


    # dladm show-link
    

    The following example output from dladm show-link indicates that a qfe NIC with four interfaces and two bge interfaces are physically available on the system.


    qfe0             type: legacy    mtu: 1500       device: qfe0
    qfe1             type: legacy    mtu: 1500       device: qfe1
    qfe2             type: legacy    mtu: 1500       device: qfe0
    qfe3             type: legacy    mtu: 1500       device: qfe1
    bge0             type: non-vlan  mtu: 1500       device: bge0
    bge1             type: non-vlan  mtu: 1500       device: bge1
  3. Review which interfaces on the router were configured and plumbed during installation.


    # ifconfig -a
    

    The following example output from ifconfig -a shows that the interface qfe0 was configured during installation. This interface is on the 172.16.0.0 network. The remaining interfaces on the qfe NIC, qfe1 - qfe3, and the bge interfaces have not been configured.


    lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000 
    qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
            inet 172.16.26.232 netmask ffff0000 broadcast 172.16.26.255
            ether 0:3:ba:11:b1:15 
             
  4. Configure and plumb another interface.


    # ifconfig interface plumb up
    

    For example, for qfe1, you would type:


    # ifconfig qfe1 plumb up
    

    Note –

    Interfaces that are explicitly configured with the ifconfig command do not persist across reboots.


  5. Assign an IPv4 address and a netmask to the interface.


    Caution – Caution –

    You can configure an IPv4 routers to receive its IP address through DHCP, but this is recommended only for very experienced DHCP system administrators.



    # ifconfig interface IPv4-address netmask+netmask
    

    For example, to assign the IP address 192.168.84.3 to qfe1, do either of the following:

    • Using traditional IPv4 notation, type the following:


      # ifconfig qfe1 192.168.84.3 netmask + 255.255.255.0
      
    • Using CIDR notation, type the following:


      # ifconfig qfe1 192.168.84.3/24
      

      The prefix /24 automatically assigns the 255.255.255.0 netmask to qfe1. For a table of CIDR prefixes and their dotted-decimal netmask equivalents, refer to Figure 2–2.

  6. (Optional) To ensure that the interface configuration persists across reboots, create an /etc/hostname.interface file for each additional physical interface.

    For example, you would create the /etc/hostname.qfe1 and /etc/hostname.qfe2 files. Then you would type the host name timbuktu in /etc/hostname.qfe1 file and host name timbuktu-201 in /etc/hostname.qfe1. For more information about configuring single interfaces, refer to How to Configure a Physical Interface After System Installation.

    Be sure to do a configuration reboot after creating this file:


    # reboot -- -r
    
  7. Add the host name and IP address of each interface to the /etc/inet/hosts file.

    For example:


    172.16.26.232      deadsea        #interface for network 172.16.0.0
    192.168.200.20     timbuktu       #interface for network 192.168.200
    192.168.201.20     timbuktu-201   #interface for network 192.168.201
    192.168.200.9      gobi
    192.168.200.10     mojave
    192.168.200.110    saltlake
    192.168.200.12     chilean

    The interfaces timbuktu and timbuktu-201 are on the same system. Notice that the network address for timbuktu-201 is different from the network interface for timbuktu. The difference exists because the physical network media for network 192.168.201 is connected to the timbuktu-201 network interface while the media for network 192.168.200 is connected to the timbuktu interface.

  8. For Solaris 10 11/06 and earlier releases of Solaris 10 only, add the IP address and host name of each new interface into the /etc/inet/ipnodes file or equivalent ipnodes database.

    For example:


    vi /etc/inet/ipnodes
    172.16.26.232      deadsea        #interface for network 172.16.0.0
    192.168.200.20     timbuktu       #interface for network 192.168.200
    192.168.201.20     timbuktu-201   #interface for network 192.168.201
    
  9. If the router is connected to any subnetted network, add the network number and the netmask to the /etc/inet/netmasks file.

    • For traditional IPv4 address notation, such as 192.168.83.0, you would type:


      192.168.83.0    255.255.255.0
    • For CIDR addresses, use the dotted-decimal version of the prefix in the entry in the /etc/inet/netmask file. Network prefixes and their dotted-decimal equivalents can be found in Figure 2–2. For example, you would use the following entry in /etc/netmasks to express the CIDR network prefix 192.168.3.0/22:


      192.168.3.0 255.255.252.0
  10. Enable IPv4 packet forwarding on the router.

    Use either of the following commands to enable packet forwarding:

    • Use the routeadm command, as follows:


      # routeadm -e ipv4-forwarding -u
      
    • Use the following service management facility (SMF) command:


      # svcadm enable ipv4-forwarding
      

    At this point, the router can forward packets beyond the local network. The router also supports static routing, a process where you can manually add routes to the routing table. If you plan to use static routing on this system, then router configuration is complete. However, you need to maintain routes in the system routing table. For information on adding routes, see Configuring Routes and the route(1M) man page.

  11. (Optional) Start a routing protocol.

    The routing daemon /usr/sbin/in.routed automatically updates the routing table, a process that is known as dynamic routing. Turn on the default IPv4 routing protocols in either of the following ways:

    • Use the routeadm command, as follows:


      # routeadm -e ipv4-routing -u
      
    • Use the following SMF command to start a routing protocol such as RIP.


      # svcadm enable route:default
      

      The SMF FMRI associated with the in.routed daemon is svc:/network/routing/route.

    For information about the routeadm command, see the routeadm(1M) man page.


Example 5–4 Configuring the Default Router for a Network

This example shows how to upgrade a system with more than one interface to become a default router. The goal is to make Router 2, which is shown in Figure 5–3, the default router for network 172.20.1.0. Router 2 contains two wired network connections, one connection to network 172.20.1.0 and one to network 10.0.5.0. The example assumes that the router operates in local files mode, as described in How to Configure a Host for Local Files Mode.

After becoming superuser or assuming an equivalent role, you would determine out the status of the system's interfaces.Starting with Solaris 10 1/06, you can use the dladm command as follows:


# dladm show-link
ce0             type: legacy    mtu: 1500       device: ce0 
bge0            type: non-vlan  mtu: 1500       device: bge0 
bge1            type: non-vlan  mtu: 1500       device: bge1

# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 172.20.1.10 netmask ffff0000 broadcast 172.20.10.100
        ether 8:0:20:c1:1b:c6 

The output of dladm show-link indicates that three links are available on the system. Only the ce0 interface has been plumbed. You would begin default router configuration by physically connecting the bge0 interface to the 10.0.5.0 network. Then, you would plumb the interface and make it persist across reboots.


# ifconfig bge0 plumb up
# ifconfig bge0 10.0.5.10
# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 172.20.1.10 netmask ffff0000 broadcast 172.255.255.255
        ether 8:0:20:c1:1b:c6 
bge0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.5.10 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:e5:95:c4
 # vi /etc/hostname.bge0
10.0.5.10
255.0.0.0

Reboot the system, using the reconfiguration boot command:


# reboot -- -r

Continue by configuring the following network databases with information about the newly plumbed interface and the network to which it is connected:


# vi /etc/inet/hosts
127.0.0.1       localhost
172.20.1.10        router2        #interface for network 172.20.1
10.0.5.10          router2-out    #interface for network 10.0.5
# vi /etc/inet/netmasks
172.20.1.0    255.255.0.0
10.0.5.0      255.0.0.0

Finally, use SMF to enable packet forwarding and then enable the in.routed routing daemon.


# svcadm enable ipv4-forwarding
# svcadm enable route:default

Now IPv4 packet forwarding and dynamic routing through RIP are enabled on Router 2. However, the default router configuration for network 172.20.1.0 is not yet complete. You would need to do the following:


Routing Tables and Routing Types

Both routers and hosts maintain a routing table. The routing daemon on each system updates the table with all known routes. The system's kernel reads the routing table before forwarding packets to the local network. The routing table lists the IP addresses of networks that the system knows about, including the system's local, default network. The table also lists the IP address of a gateway system for each known network. The gateway is a system that can receive outgoing packets and forward them one hop beyond the local network. The following is a simple routing table for a system on an IPv4-only network:


Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG       1    532   ce0
224.0.0.0            10.0.5.100           U        1      0   bge0
10.0.0.0             10.0.5.100           U        1      0   bge0
127.0.0.1            127.0.0.1            UH       1     57   lo0

You can configure two types of routing on an Oracle Solaris system: static and dynamic. You can configure either or both routing types on a single system. A system that implements dynamic routing relies on routing protocols, such as RIP for IPv4 networks, and RIPng for IPv6 networks, to maintain its routing tables. A system that runs only static routing does not rely on a routing protocol for routing information and for updating the routing table. Instead, you must maintain the system's known routes manually through the route command. For complete details, refer to the route(1M) man page.

When you configure routing for the local network or autonomous system, consider which type of routing to support on particular routers and hosts.

The following table shows the different types of routing and the networking scenarios to which each routing type is best applied.

Routing Type 

Best Used on 

Static 

Small networks, hosts that get their routes from a default router, and default routers that only need to know about one or two routers on the next few hops.

Dynamic 

Larger internetworks, routers on local networks with many hosts, and hosts on large autonomous systems. Dynamic routing is the best choice for systems on most networks.

Combined static and dynamic 

Routers that connect a statically routed network and a dynamically routed network, and border routers that connect an interior autonomous system with external networks. Combining both static and dynamic routing on a system is a common practice. 

The AS that is shown is Figure 5–3 combines both static and dynamic routing.

Configuring Routes

To implement dynamic routing for an IPv4 network, use the routeadm or svcadm command to start the in.routed routing daemon. For instructions, see How to Configure an IPv4 Router. Dynamic routing is the preferred strategy for most networks and autonomous systems. However, your network topology or a particular system on your network might require static routing. In that case, you must manually edit the system routing table to reflect the known route to the gateway. The next procedure shows how to add a static route.


Note –

Two routes to the same destination does not automatically cause the system to do load balancing or failover. If you need these capabilities, use IPMP, as explained in Chapter 30, Introducing IPMP (Overview).


ProcedureHow to Add a Static Route to the Routing Table

  1. View the current state of the routing table.

    Use your regular user account to run the following form of the netstat command:


    % netstat -rn
    

    Your output would resemble the following:


    Routing Table: IPv4
      Destination           Gateway           Flags  Ref   Use   Interface
    -------------------- -------------------- ----- ----- ------ ---------
    192.168.5.125        192.168.5.10          U      1   5879   ipge0
    224.0.0.0            198.168.5.10          U      1  0       ipge0
    default              192.168.5.10          UG     1  91908
    127.0.0.1            127.0.0.1             UH     1  811302   lo0
  2. 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.

  3. (Optional) Flush the existing entries in the routing table.


    # route flush
    
  4. Add a route that persists across system reboots.


    # route -p add -net network-address -gateway gateway-address
    
    -p

    Creates a route that must persist across system reboots. If you want the route to prevail only for the current session, do not use the -p option.

    add

    Indicates that you are about to add the following route.

    -net network-address

    Specifies that the route goes to the network with the address in network-address.

    -gateway gateway-address

    Indicates that the gateway system for the specified route has the IP address gateway-address.


Example 5–5 Adding a Static Route to the Routing Table

The following example shows how to add a static route to a system. The system is Router 2, the default router for the 172.20.1.0 network that is shown in Figure 5–3. In Example 5–4, Router 2 is configured for dynamic routing. To better serve as the default router for the hosts on network 172.20.1.0, Router 2 additionally needs a static route to the AS's border router, 10.0.5.150.

To view the routing table on Router 2, you would do the following:


# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG        1    249 ce0
224.0.0.0            172.20.1.10          U         1      0 ce0
10.0.5.0             10.0.5.20            U         1     78 bge0
127.0.0.1            127.0.0.1            UH        1     57 lo0

The routing table indicates two routes that Router 2 knows about. The default route uses Router 2's 172.20.1.10 interface as its gateway. The second route, 10.0.5.0, was discovered by the in.routed daemon running on Router 2. The gateway for this route is Router 1, with the IP address 10.0.5.20.

To add a second route to network 10.0.5.0, which has its gateway as the border router, you would do the following:


# route -p add -net 10.0.5.0/24 -gateway 10.0.5.150/24
add net 10.0.5.0: gateway 10.0.5.150

Now the routing table has a route for the border router, which has the IP address 10.0.5.150/24.


# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG        1    249 ce0
224.0.0.0            172.20.1.10          U         1      0 ce0
10.0.5.0             10.0.5.20            U         1     78 bge0
10.0.5.0             10.0.5.150           U         1    375 bge0
127.0.0.1            127.0.0.1            UH        1     57 lo0

Configuring Multihomed Hosts

In Oracle Solaris, a system with more than one interface is considered a multihomed host. A multihomed host does not forward IP packets. However, you can configure a multihomed host to run routing protocols. You typically configure the following types of systems as multihomed hosts:

ProcedureHow to Create a Multihomed Host

  1. On the prospective multihomed host, 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.

  2. Configure and plumb each additional network interface that was not configured as part of the Oracle Solaris installation.

    Refer to How to Configure a Physical Interface After System Installation.

  3. Verify that IP forwarding is not enabled on the multihomed host.


    # routeadm
     
    

    The routeadm command without options reports the state of the routing daemons. The following output from routeadm shows that IPv4 forwarding is enabled:


       Configuration   Current              Current
                         Option   Configuration        System State
    ---------------------------------------------------------------
                   IPv4 routing   disabled             disabled
                   IPv6 routing   disabled             disabled
                IPv4 forwarding   enabled              disabled
                IPv6 forwarding   disabled             disabled
    
                Routing services   "route:default ripng:default"
  4. Turn off packet forwarding, if it is enabled on the system.

    Use either of the following commands:

    • For the routeadm command, type the following:


      # routeadm -d ipv4-forwarding -u
      
    • To use SMF, type the following:


      # svcadm disable ipv4-forwarding
      
  5. (Optional) Turn on dynamic routing for the multihomed host.

    Use either of the following commands to enable the in.routed daemon:

    • For the routeadm command, type the following:


      # routeadm -e ipv4-routing -u
      
    • To use SMF, type the following:


      # svcadm enable route:default
      

Example 5–6 Configuring a Multihomed Host

The following example shows how to configure the multihomed host that is shown in Figure 5–3. In the example, the system has the host name hostc. This host has two interfaces, which are both connected to network 192.168.5.0.

To begin, you would display the status of the system's interfaces.


# dladm show-link
hme0           type: legacy    mtu: 1500       device: hme0 
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
# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet 192.168.5.82 netmask ff000000 broadcast 192.255.255.255
      ether 8:0:20:c1:1b:c6 
 

The dladm show-link command reports that hostc has two interfaces with a total of five possible links. However, only hme0 has been plumbed. To configure hostc as a multihomed host, you must add qfe0 or another link on the qfe NIC. First, you would physically connect the qfe0 interface to the 192.168.5.0 network. Then you would plumb the qfe0 interface, and make the interface persist across reboots.


# ifconfig qf0 plumb up
# ifconfig qfe0 192.168.5.85
# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.5.82 netmask ff0000 broadcast 192.255.255.255
        ether 8:0:20:c1:1b:c6 
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.5.85 netmask ff000000 broadcast 192.255.255.255
        ether 8:0:20:e1:3b:c4
 # vi /etc/hostname.qfe0
192.168.5.85
255.0.0.0

Reboot the system, using the reconfiguration command:


# reboot -- -r

Next, you would add the qfe0 interface to the hosts database:


# vi /etc/inet/hosts
127.0.0.1           localhost
192.168.5.82        host3    #primary network interface for host3
192.168.5.85        host3-2  #second interface

Then, you would check the state of packet forwarding and routing on host3:


# routeadm
              Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   enabled              enabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   enabled              enabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

The routeadm command reports that dynamic routing through the in.routed daemon and packet forwarding are currently enabled. However, you would need to disable packet forwarding:


# svcadm disable ipv4-forwarding

You can also use the routeadm commands as shown in How to Create a Multihomed Host to turn off packet forwarding. When packet forwarding is disabled, host3 becomes a multihomed host.


Configuring Routing for Single-Interface Systems

Single-interface hosts need to implement some form of routing. If the host is to obtain its routes from one or more local default routers, then you must configure the host to use static routing. Otherwise, dynamic routing is recommended for the host. The following procedures contain the instructions for enabling both routing types.

ProcedureHow to Enable Static Routing on a Single-Interface Host

This procedure enables static routing on a single-interface host. Hosts that use static routing do not run a dynamic routing protocol such as RIP. Instead, the host must rely on the services of a default router for routing information. The figure IPv4 Autonomous System Topology shows several default routers and their client hosts. If you supplied the name of a default router when you installed a particular host, that host is already configured to use static routing.


Note –

You can also use the following procedure to configure static routing on a multihomed host.


For information about the /etc/defaultrouter file, see /etc/defaultrouter File. For information about static routing and the routing table, refer to Routing Tables and Routing Types.

  1. On the single interface host, 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.

  2. Verify whether the /etc/defaultrouter file is present on the host.


    # cd /etc
    # ls | grep defaultrouter
    
  3. Open a text editor to create or modify the /etc/defaultrouter file

  4. Add an entry for the default router.


    # vi  /etc/defaultrouter
    router-IP
           
    

    where router-IP indicates the IP address of the default router for the host to use.

  5. Verify that routing and packet forwarding are not running on the host.


    # routeadm
       Configuration   Current              Current
                         Option   Configuration        System State
    ---------------------------------------------------------------
                   IPv4 routing   disabled             disabled
                   IPv6 routing   disabled             disabled
                IPv4 forwarding   disabled            disabled
                IPv6 forwarding   disabled             disabled
    
               Routing services   "route:default ripng:default"
  6. Add an entry for the default router in the local /etc/inet/hosts file.

    For information about configuring /etc/inet/hosts, refer to How to Change the IPv4 Address and Other Network Configuration Parameters.


Example 5–7 Configuring a Default Router and Static Routing for a Single-Interface Host

The following example shows how to configure static routing for hostb, a single-interface host on the network 172.20.1.0 that is shown in Figure 5–3. hostb needs to use Router 2 as its default router.

First, you would log in to hostb as superuser, or assume an equivalent role. Then, you would determine whether the /etc/defaultrouter file is present on the host:


# cd /etc
# ls | grep defaultrouter

No response from grep indicates that you need to create the /etc/defaultrouter file.


# vi /etc/defaultrouter
172.20.1.10

The entry in the /etc/defaultrouter file is the IP address of the interface on Router 2, which is attached to the 172.20.1.0 network. Next, you verify whether the host currently enables packet forwarding or routing.


# routeadm
   Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   disabled             disabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   enabled              enabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

Packet forwarding is enabled for this particular host. You would turn it off as follows:


# svcadm disable ipv4-forwarding

Lastly, you would make sure that the host's /etc/inet/hosts file has an entry for the new default router.


# vi /etc/inet/hosts
127.0.0.1           localhost
172.20.1.18         host2    #primary network interface for host2
172.20.1.10         router2  #default router for host2

ProcedureHow to Enable Dynamic Routing on a Single-Interface Host

Dynamic routing is the easiest way to manage routing on a host. Hosts that use dynamic routing run the routing protocols provided by the in.routed daemon for IPv4 or in.ripngd daemon for IPv6. Use the next procedure to enable IPv4 dynamic routing on a single interface host. For more information about dynamic routing, refer to Packet Forwarding and Routing on IPv4 Networks.

  1. On the host, 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.

  2. Verify whether the /etc/defaultrouter file exists.


    # cd /etc
    # ls | grep defaultrouter
    
  3. If /etc/defaultrouter exists, delete any entry that you find there.

    An empty /etc/defaultrouter file forces the host to use dynamic routing.

  4. Verify whether packet forwarding and routing are enabled on the host.


    # routeadm
       Configuration   Current              Current
                         Option   Configuration        System State
    ---------------------------------------------------------------
                   IPv4 routing   disabled             disabled
                   IPv6 routing   disabled             disabled
                IPv4 forwarding   enabled              enabled
                IPv6 forwarding   disabled             disabled
    
               Routing services   "route:default ripng:default"
  5. If packet forwarding is enabled, turn it off

    Use either of the following commands:

    • For the routeadm command, type the following:


      # routeadm -d ipv4-forwarding -u
      
    • To use SMF, type the following:


      # svcadm disable ipv4-forwarding
      
  6. Enable routing protocols on the host.

    Use either of the following commands:

    • For the routeadm command, type the following:


      # routeadm -e ipv4-routing -u
      
    • To use SMF, type the following:


      # svcadm enable route:default
      

    Now IPv4 dynamic routing is enabled. The host's routing table is dynamically maintained by the in.routed daemon.


Example 5–8 Running Dynamic Routing on a Single-Interface Host

The following example shows how to configure dynamic routing for hosta, a single-interface host on the network 192.168.5.0 that is shown in Figure 5–3. hosta currently uses Router 1 as its default router. However, hosta now needs to run dynamic routing.

First, you would log in to hosta as superuser or assume an equivalent role. Then, you would determine whether the /etc/defaultrouter file is present on the host:


# cd /etc
# ls | grep defaultrouter
defaultrouter

The response from grep indicates that a /etc/defaultrouter file exists for hosta.


# vi /etc/defaultrouter
192.168.5.10

The file has the entry 192.168.5.10, which is the IP address for Router 1. You would delete this entry to enable static routing. Next, you would need to verify whether packet forwarding and routing are already enabled for the host.


# routeadm   Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   disabled             disabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   disabled             disabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

Both routing and packet forwarding are turned off for hosta. Turn on routing to complete the configuration of dynamic routing for hosta, as follows:


# svcadm enable route:default

Monitoring and Modifying Transport Layer Services

The transport layer protocols TCP, SCTP, and UDP are part of the standard Oracle Solaris package. These protocols typically need no intervention to run properly. However, circumstances at your site might require you to log or modify services that run over the transport layer protocols. Then, you must modify the profiles for these services by using the Service Management Facility (SMF), which is described in Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.

The inetd daemon is responsible for starting standard Internet services when a system boots. These services include applications that use TCP, SCTP, or UDP as their transport layer protocol. You can modify existing Internet services or add new services using the SMF commands. For more information about inetd, refer to inetd Internet Services Daemon.

Operations that involve the transport layer protocols include:

For detailed information on the inetd daemon refer to the inetd(1M)man page.

ProcedureHow to Log the IP Addresses of All Incoming TCP Connections

  1. On the local system, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Set TCP tracing to enabled for all services managed by inetd.


    # inetadm -M tcp_trace=TRUE
    

ProcedureHow to Add Services That Use the SCTP Protocol

The SCTP transport protocol provides services to application layer protocols in a fashion similar to TCP. However, SCTP enables communication between two systems, either or both of which can be multihomed. The SCTP connection is called an association. In an association, an application divides the data to be transmitted into one or more message streams, or multi-streamed. An SCTP connection can go to endpoints with multiple IP addresses, which is particularly important for telephony applications. The multihoming capabilities of SCTP are a security consideration if your site uses IP Filter or IPsec. Some of these considerations are described in the sctp(7P) man page.

By default, SCTP is included in the Oracle Solaris and does not require additional configuration. However, you might need to explicitly configure certain application layer services to use SCTP. Some example applications are echo and discard. The next procedure shows how to add an echo service that uses an SCTP one-to-one style socket.


Note –

You can also use the following procedure to add services for the TCP and UDP transport layer protocols.


The following task shows how to add an SCTP inet service that is managed by the inetd daemon to the SMF repository. The task then shows how to use the Service Management Facility (SMF) commands to add the service.

Before You Begin

Before you perform the following procedure, create a manifest file for the service. The procedure uses as an example a manifest for the echo service that is called echo.sctp.xml.

  1. Log in to the local system with a user account that has write privileges for system files.

  2. Edit the /etc/services file and add a definition for the new service.

    Use the following syntax for the service definition.


    service-name |port/protocol | aliases
    
  3. Add the new service.

    Go to the directory where the service manifest is stored and type the following:


    # cd dir-name
    # svccfg import service-manifest-name
    

    For a complete syntax of svccfg, refer to the svccfg(1M) man page.

    Suppose you want to add a new SCTP echo service using the manifest echo.sctp.xml that is currently located in the service.dir directory. You would type the following:


    # cd service.dir
    # svccfg import echo.sctp.xml
    
  4. Verify that the service manifest has been added:


    # svcs FMRI
    

    For the FMRI argument, use the Fault Managed Resource Identifier (FMRI) of the service manifest. For example, for the SCTP echo service, you would use the following command:


    # svcs svc:/network/echo:sctp_stream
    

    Your output should resemble the following:


    	STATE          STIME    FMRI
    disabled       16:17:00 svc:/network/echo:sctp_stream

    For detailed information about the svcs command, refer to the svcs(1) man page.

    The output indicates that the new service manifest is currently disabled.

  5. List the properties of the service to determine if you must make modifications.


    # inetadm -l FMRI
    

    For detailed information about the inetadm command, refer to the inetadm(1M) man page.

    For example, for the SCTP echo service, you would type the following:


    # inetadm -l svc:/network/echo:sctp_stream
    SCOPE    NAME=VALUE
    	         name="echo"
    	         endpoint_type="stream"
    	         proto="sctp"
    	         isrpc=FALSE
    	         wait=FALSE
    	         exec="/usr/lib/inet/in.echod -s"
             .
             .
             default  tcp_trace=FALSE
           	default  tcp_wrappers=FALSE
  6. Enable the new service:


    # inetadm -e FMRI
    
  7. Verify that the service is enabled:

    For example, for the new echo service, you would type the following:


    # inetadm | grep sctp_stream
    .
    .
    	enabled   online         svc:/network/echo:sctp_stream

Example 5–9 Adding a Service That Uses the SCTP Transport Protocol

The following example shows the commands to use and the file entries required to have the echo service use the SCTP transport layer protocol.


$ cat /etc/services
.
.
echo            7/tcp
echo            7/udp
echo            7/sctp

# cd service.dir

	# svccfg import echo.sctp.xml

# svcs network/echo*
	STATE          STIME    FMRI
	disabled       15:46:44 svc:/network/echo:dgram
	disabled       15:46:44 svc:/network/echo:stream
	disabled       16:17:00 svc:/network/echo:sctp_stream

# inetadm -l svc:/network/echo:sctp_stream
	SCOPE    NAME=VALUE
	         name="echo"
	         endpoint_type="stream"
	         proto="sctp"
	         isrpc=FALSE
	         wait=FALSE
	         exec="/usr/lib/inet/in.echod -s"
	         user="root"
	default  bind_addr=""
	default  bind_fail_max=-1
	default  bind_fail_interval=-1
	default  max_con_rate=-1
	default  max_copies=-1
	default  con_rate_offline=-1
	default  failrate_cnt=40
	default  failrate_interval=60
	default  inherit_env=TRUE
	default  tcp_trace=FALSE
	default  tcp_wrappers=FALSE

# inetadm -e svc:/network/echo:sctp_stream

# inetadm | grep echo
	disabled  disabled       svc:/network/echo:stream
	disabled  disabled       svc:/network/echo:dgram
	enabled   online         svc:/network/echo:sctp_stream

ProcedureHow to Use TCP Wrappers to Control Access to TCP Services

The tcpd program implements TCP wrappers. TCP wrappers add a measure of security for service daemons such as ftpd by standing between the daemon and incoming service requests. TCP wrappers log successful and unsuccessful connection attempts. Additionally, TCP wrappers can provide access control, allowing or denying the connection depending on where the request originates. You can use TCP wrappers to protect daemons such as SSH, Telnet, and FTP. The sendmail application can also use TCP wrappers, as described in Support for TCP Wrappers From Version 8.12 of sendmail in System Administration Guide: Network Services.

  1. On the local system, 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.

  2. Set TCP wrappers to enabled.


    # inetadm -M tcp_wrappers=TRUE
    
  3. Configure the TCP wrappers access control policy as described in the hosts_access(3) man page.

    This man page can be found in the /usr/sfw/man directory on the SFW CD-ROM, which is packaged along with the Oracle Solaris CD-ROM.

Administering Interfaces in Solaris 10 3/05

This section contains the following tasks for administering physical interfaces:

What's New in This Section

This section contains information on configuring interfaces for users of the Solaris 10 3/05 OS only. If you are using an update to the Oracle Solaris 10, refer to Chapter 6, Administering Network Interfaces (Tasks). 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.

Configuring Physical Interfaces in Solaris 10 3/05

An Oracle Solaris-based system usually has two types of interfaces, physical and logical. Physical interfaces consist of a driver and a connector into which you plug network media, such as an Ethernet cable. Logical interfaces are logically configured onto existing physical interfaces, such as interfaces that are configured for tunnels or configured with IPv6 addresses. This section describes how to configure physical interfaces after installation. Instructions for configuring logical interfaces are included with tasks for features that require logical interfaces, for example, How to Manually Configure IPv6 Over IPv4 Tunnels.

Types of physical interfaces include interfaces that are built into the system and separately purchased interfaces. Each interface resides on a network interface card (NIC).

Built-in NICs are present on the system when it is purchased. An example of an interface on a built-in NIC is the primary network interface, such as eri0 or hme0. You must configure the system's primary network interface at installation time.

NICs such as eri and hme have only one interface. However, many brands of NICs have multiple interfaces. A multiple interface NIC such as the qfe card has four interfaces, qfe0qfe3. The Oracle Solaris installation program detects all interfaces present at installation and asks if you want to configure the interfaces. You can configure these interfaces at boot time or at a later date.


Note –

NICs are also referred to as network adapters.


In addition to the built-in NICs, you can add separately purchased NICs to a system. You physically install a separately purchased NIC according to the manufacturer's instructions. Then, you need to configure the interfaces on the NIC so that the interfaces can be used for passing data traffic.

The following are reasons to configure additional interfaces on a system after installation:

ProcedureHow 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.

The physical interface to be configured must be present on the system. For information on installing separately purchased NIC hardware, refer to the manufacturers instructions that accompany the NIC.

The next procedure assumes that you have performed a reconfiguration boot after physically installing a new interface.


Note –

The next procedure contains applies to users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to How to Configure a Physical Interface After System Installation.


  1. 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.

  2. 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.


  3. Assign an IPv4 address and netmask to the interface.


    # ifconfig interface IPv4-address netmask+netmask
    

    For example, for qfe0 you would type:


    # ifconfig qfe0 10.0.0.32 netmask + 255.255.255.0
    
  4. 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
  5. (Optional) To make the interface configuration persist across reboots, perform the following steps:

    1. 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
      
    2. Edit the /etc/hostname.interface file.

      At a minimum, add the IPv4 address of the interface to the file. 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


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

    4. Perform a reconfiguration boot.


      # reboot -- -r
      
    5. Verify that the interface you created in the /etc/hostname.interface file has been configured.


      # ifconfig -a
      

Example 5–10 Configuring an Interface After System Installation

The following example shows how to add two interfaces, qfe0 and qfe1. These interfaces are attached to the same network as the primary network interface, hme0. Note that this interface configuration exists until you reboot the system. For an example that shows how to make interface configurations persist across reboots, see Example 6–2. However, the dladm command that is used in that example is only available starting with the Solaris 10 1/06 OS.


# ifconfig qfe0 plumb up
# ifconfig qfe1 plumb up
# ifconfig qfe0 10.0.0.32 netmask 255.0.0.0
# ifconfig qfe1 10.0.0.33 netmask 255.0.0.0

# 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.0.0.14 netmask 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 10.0.0.32 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c8:f4:1d 
qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.0.0.33 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c8:f4:1e 

See Also

ProcedureHow to Remove a Physical Interface in Solaris 10 3/05 ONLY


Note –

The next procedure contains applies to users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to How to Remove a Physical Interface.


  1. 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.

  2. Remove the physical interface.

    Use the following form of the ifconfig command:


    # ifconfig interfacedown unplumb
    

    For example, you would remove the interface eri1 as follows:


    # ifconfig eri1 down unplumb
    

Configuring VLANs in Solaris 10 3/05 ONLY


Note –

This section contains information on configuring VLANs for users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to Administering Virtual Local Area Networks.


Virtual local area networks (VLANs) are commonly used to split up groups of network users into manageable broadcast domains, to create logical segmentation of work groups, and to enforce security policies among each logical segment. With multiple VLANs on an adapter, a server with a single adapter can have a logical presence on multiple IP subnets. By default, 512 VLANs can be defined for each VLAN-aware adapter on your server.

If your network does not require multiple VLANs, you can use the default configuration, in which case no further configuration is necessary.

For an overview of VLANs, refer to Overview of VLAN Topology.

VLANs can be created according to various criteria, but each VLAN must be assigned a VLAN tag or VLAN ID (VID). The VID is a 12-bit identifier between 1 and 4094 that identifies a unique VLAN. For each network interface (for example, ce0, ce1, ce2, and so on) 512 possible VLANs can be created. Because IP subnets are commonly used, use IP subnets when setting up a VLAN network interface. This means that each VID assigned to a VLAN interface of a physical network interface belongs to different subnets.

Tagging an Ethernet frame requires the addition of a tag header to the frame. The header is inserted immediately following the destination MAC address and the source MAC address. The tag header consists of two bytes of the Ethernet Tag Protocol Identifier (TPID, 0x8100) and two bytes of Tag Control Information (TCI). The following figure shows the Ethernet Tag Header format.

Figure 5–4 Ethernet Tag Header Format

The figure shows the layout of the Ethernet tag header,
as described in the previous context.

ProcedureHow To Configure Static VLANs in Solaris 10 3/05 ONLY


Note –

This procedure contains information on configuring VLANs for users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to How to Configure a VLAN


  1. 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.

  2. Determine the type of interfaces in use on your system.

    The network adapter on your system might not be referred to by the letters ce, which is required for a VLAN.


    # 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 129.156.200.77 netmask ffffff00 broadcast
    129.156.200.255
  3. Create one hostname.cenum file (hostname6.cenum file for IPv6) for each VLAN that will be configured for each adapter on the server.

    Use the following naming format that includes both the VID and the physical point of attachment (PPA):

    VLAN logical PPA = 1000 * VID + Device PPA ce123000 = 1000*123 + 0

    For example: hostname.ce123000

    VLAN logical PPA = 1000 * VID + Device PPA ce11000 = 1000*11 + 0

    For example: hostname.ce11000

    This format limits the maximum number of PPAs (instances) you can configure to 1000 in the /etc/path_to_inst file.

    For example, on a server with the Sun Gigabit Ethernet/P 3.0 adapter having an instance of 0, that belongs to two VLANs with VIDs 123 and 224, you would use ce123000 and ce224000, respectively, as the two VLAN PPAs.

  4. Configure a VLAN virtual device:

    For example, you could use the following examples of ifconfig:


    # ifconfig ce123000 plumb up
    # ifconfig ce224000 plumb up
    

    The output of ifconfig -a on a system with VLAN devices ce123000 and ce224000 should resemble the following:


    # 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 129.144.131.91 netmask ffffff00 broadcast 129.144.131.255
            ether 8:0:20:a4:4f:b8 
    ce123000: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
            inet 199.199.123.3 netmask ffffff00 broadcast 199.199.123.255
            ether 8:0:20:a4:4f:b8 
    ce224000: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
            inet 199.199.224.3 netmask ffffff00 broadcast 199.199.224.255
            ether 8:0:20:a4:4f:b8 
  5. On the switch, set VLAN tagging and VLAN ports to coincide with the VLANs you have set up on the server.

    Using the examples in Step 4, you would set up VLAN ports 123 and 224 on the switch or VLAN ports 10 and 11.

    Refer to the documentation that came with your switch for specific instructions for setting VLAN tagging and ports.