From: Subject: Configuring Network Interface Cards Date: Sun, 17 Jun 2001 11:56:32 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.enteract.com/~lspitz/interfaces.html X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Configuring Network Interface Cards getting your = interfaces to=20 talk
Configuring Network Interface Cards=20

Lance=20 Spitzner
Last Modified: 17 August, 1999
 =20
This article is the first of a two part series. In this first = article we=20 will cover how to configure, troubleshoot, and modify system interfaces. = The second article = will=20 cover static routing tables for systems with two or more interfaces. In = both=20 articles I will be focusing on TCP/IP in a Ethernet environment. =
 =20

Interfaces=20

Network Interface Cards are what allow your system to talk to the = network.=20 When they don?t work, neither do you. I will cover how to configure,=20 troubleshoot, and modify your interfaces. I will not be covering routing = issues,=20 that will follow in the next article. My goal here is to get your = interface up=20 and properly running.=20

The first place to start is installing and testing the hardware. Once = you=20 have installed the hardware, SPARC systems can be tested at the EPROM = level to=20 verify the network interface cards. Use the manual that accompanies the=20 interface card on how to test that specific card. Solaris x86 is a = little=20 different, as there is no true EPROM, and the drivers are different. = However,=20 Solaris x86 2.6 is Plug and Play compatible, and I have had fairly good = luck=20 adding network interface cards.=20

Once you have confirmed at the hardware and driver level that = everything=20 works, the fun can begin. The place to start is the ifconfig command. = This=20 powerful command allows you configure and modify your interfaces in real = time.=20 However, any modifications made with ifconfig are not permanent. When = the system=20 reboots, it will default to its previous configuration. I will first = show you=20 how to make all modifications with the ifconfig command. The second half = of this=20 article will cover making these modifications permanent by modifying the = proper=20 configuration files.
 
 =20

ifconfig=20

ifconfig -a will show you which interfaces are currently installed = and=20 active. Remember, just because you added the physical network interface = card=20 does NOT mean it is active. If you do an ifconfig before you have = configured the=20 device, the interface will not show up. Once configured however, the = typical=20 output of the ifconfig -a command would look like this:=20

lo0:=20 flags=3D849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 =
           = inet=20 127.0.0.1 netmask ff000000
hme0:=20 flags=3D863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu=20 1500
          inet=20 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255 =
          ether=20 8:0:20:9c:6b:2d=20

Here we see two interfaces, lo0 and hme0. lo0 is the standard = loopback=20 interface found on all systems. hme0 is a 10/100 Mbps interface. All hme = interfaces are 10/100 Mbps, all le interfaces are 10 Mbps, all qe = interface are=20 quad 10 Mbps, and qfe interfaces are quad 10/100 Mbps.  There are = three=20 lines of information about the interface. The first line is about the = TCP/IP=20 stack. For the interface hme0, we see the system is up, running both = broadcast=20 and multicast, with a mtu (maximum transfer unit) of 1500 bytes, = standard for an=20 Ethernet LAN. Notrailers is a flag no longer used, but kept for = backwards=20 compatibility reasons.=20

The second line is about the IP addressing. Here we see the IP = address,=20 netmask in hexadecimal format, and the broadcast address. The third line = is the=20 MAC address. Unlike most interfaces, Sun Microsystems?s interfaces = derive the=20 MAC addressing from the NVRAM, not the interface itself. Thus, all the=20 interfaces on a single SPARC system will have the same MAC address. This = does=20 not cause a problem in routing, since most NICs are always on a = different=20 network. Note, you must be root to see the MAC address with the ifconfig = command, any other user will only see the first two lines of = information.=20

The first step in bringing up an interface is "plumbing" the = interface. By=20 plumbing, we are implementing the TCP/IP stack. We will use the above = interface,=20 hme0, as an example. Lets say we had just physically added this network=20 interface card and rebooted, now what? First, we plumb the device with = the plumb=20 command.=20

ifconfig hme0=20 plumb=20

This sets up the streams needed for TCP/IP to use the device. = However, the=20 stack has not been configured as you can see below.=20

hme0:=20 flags=3D842<BROADCAST,RUNNING,MULTICAST> mtu 1500 =
           = inet=20 0.0.0.0 netmask 0
           = ether=20 8:0:20:9c:6b:2d=20

 The next step is to configure the TCP/IP stack. We configure = the stack=20 by adding the IP address, netmask, and then telling the device it is up. = All=20 this can be down in one command, as seen below.=20

 homer = #ifconfig hme0=20 192.168.1.132 netmask 255.255.255.0 up=20

This single command configures the entire device. Notice the up = command,=20 which initializes the interface. The interface can be in one of two = states, up=20 or down. When an interface is down, the system does not attempt to = transmit=20 messages through that interface. A down interface will still show with = the=20 ifconfig command, however it will not have the word "up" on the first = line.=20
 =20

Virtual=20 Interfaces=20

Before moving on to the configuration files, I would first like to = cover=20 virtual interfaces. A virtual interface is one or more logical = interfaces=20 assigned to an already existing interface. Solaris can have up to 255 = virtual=20 interfaces assigned to a single interface.=20

Once again, lets take the interface hme0 as an example. We have = already=20 covered how to configure this device. However, lets say the device is on = a VLAN=20 (virtual LAN) with several networks sharing the same wire. We can = configure the=20 device hme0 to answer to another IP address, say 172.20.15.4. To do so, = the=20 command would be the same as used for hme0, except the virtual interface = is=20 called hme0:*, where * is the number you assign to the virtual = interface. For=20 example, virtual interface one would be hme0:1. The command to configure = it=20 looks as follows.=20

ifconfig hme0:1 = 172.20.15.4=20 netmask 255.255.0.0 up=20

 Once you have configured the virtual interface, you can compare = hme0=20 and hme0:1 with the ifconfig command.=20

hme0:=20 flags=3D843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 =
          inet=20 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255 =
          ether=20 8:0:20:9c:6b:2d
hme0:1: flags=3D842<BROADCAST,RUNNING,MULTICAST> mtu=20 1500
          inet = 172.20.15.4=20 netmask ffff0000 broadcast 172.20.255.255=20

Here you see the two devices, both of which are on the same physical = device.=20 Notice how the virtual interface hme0:1 has no MAC address, as this is = the same=20 device as hme0. We can repeat this process all the way up to hme0:255. = The=20 operating system and most applications will treat these virtual devices = as=20 totally independent devices.=20

Note, Matthew A. Domurat has identified a "bug" with Solaris 2.6. = When=20 working with virtual interfaces, Solaris 2.6 will randomly select one of = the=20 interfaces as its source address for every packet sent. These are the = patches to=20 fix this:
105786-05: SunOS 5.6: /kernel/drv/ip patch
105787-04: = SunOS=20 5.6_x86: /kernel/drv/ip patch=20

Configuration=20 Files=20

Now you know how to configure your network interface cards. = Unfortunately,=20 any modifications, additions, or deletions you make with ifconfig are = only=20 temporary, you will lose these configurations when you reboot. I will = now=20 discuss what files you have to configure to make these changes = permanent.=20

The place to start is the file /etc/hostname.*, where * is the name = of the=20 interface. In the case of hme0, the file name is /etc/hostname.hme0. The = virtual=20 interface hme0:1 would have the file name /etc/hostname.hme0:1. This = file has a=20 single entry, the name of the interface. This name is used in the = /etc/hosts=20 file to resolve name to IP address.=20

The file /etc/hostname.* is critical, this is what causes the device = to be=20 plumbed. During the boot process, the /etc/rcS.d/rootusr.sh file reads = all the=20 /etc/hostname.* files and plumbs the devices. Once plumbed, the devices = are=20 configured by reading the /etc/hosts and the /etc/netmasks file. By = reading=20 these two files, the device is configured for the proper IP and netmask, = and=20 brought to an up state.  Lets take the device hme0 as an example. = During=20 the boot process, /etc/rcS.d/rootusr.sh looks for any /etc/hostname.* = files. It=20 finds /etc/hostname.hme0, which contains the following entry.=20

homer=20

/etc/rcS.d/rootusr.sh looks in /etc/hosts and resolves the name homer = with an=20 IP address of 192.168.1.132. The device hme0 is now assigned this IP = address.=20 The script then looks at /etc/netmasks to find the netmask for that IP = address.=20 With this information, the startup script brings up interface hme0 with = an IP=20 address of 192.168.1.132 and a netmask of 255.255.255.0. It may seem = redundant=20 having the script review the netmask of a class C address. However, do = not=20 forget that, starting with 2.6, Solaris supports both classless routing = and VLSM=20 (Variable Length Subnet Masks), both of which I will discuss in my next = article.=20

As you have seen in this example, there are three files that must be = modified=20 for every interface. The first is /etc/hostname.*, this is the file you = create=20 to designate the interface?s name. The second file is /etc/hosts, here = you=20 resolve the IP to the interface name. Last is /etc/netmasks, this is = where you=20 define the netmask of the IP address.
 =20

Troubleshooting=20

Once you have mastered the tricks to modifying your interfaces,=20 troubleshooting should be easier. Several things I always look for when=20 troubleshooting an interface. First, when working with an unfamiliar = machine,=20 often you do not know how many physical interfaces are on the machine. A = quick=20 way to tell is use dmesg, this will give you information on the physical = hardware. Look for le0, qfe0, hme0, or qe0. These are the names assigned = to the=20 physical devices.=20

If an interface is not responding to the network, check to be sure it = is the=20 correct IP address and netmask. The ifconfig command is a quick and = temporary=20 way to change IP and netmask information for troubleshooting = purposes.  Mtu=20 (maximum transfer unit) is another possibility. Some systems may have = problems=20 communicating due to fragmented packets. Changing the mtu size may solve = that=20 problem. You?ll notice that you did not have to set the mtu size in the = examples=20 above, these are set to defaults automatically, such as 1500 for = Ethernet=20 interfaces.=20

If that fails, try bringing the face down, then reinitializing it = with the up=20 command. If nothing else works, unplumb the device, then plumb it again. = Basically, this reinstalls the TCP/IP stack.
 =20

Conclusion=20

Network Interface Cards are critical to your systems networking = capability.=20 Understanding the configuration of your interface(s) ensures your = system?s=20 productivity. Next month we will look at routing tables, and ensure that = once=20 your interfaces are configured and up, your packets will know where to = go.=20
 
 =20

Author?s=20 bio
Lance Spitzner enjoys learning by = blowing up=20 his Unix systems at home. Before this, he was an Officer in the = Rapid=20 Deployment Force, where he blew up things of a different nature. You = can=20 reach him at lance@honeynet.org .=20
 
 =20

Whitepapers /=20 = Publications