C H A P T E R  11

Configuring IPMP for Network Resiliency on Solaris x86 Blades

This chapter contains the following sections:


11.1 Taking Advantage of Having Two Switches in the System Chassis

This chapter modifies and supplements the information available in Chapter 5 of the Sun Fire B1600 Blade System Chassis Software Setup Guide. Please read that chapter before following the instructions in this one.

The instructions in this chapter enable you to deploy a chassis containing Solaris x86 blades in a configuration that:

The next section (Section 11.2, How IPMP Works on B100x and B200x Blades) tells you how IPMP works on an x86 blade in the B1600 chassis. It states (and explains) the number of IP addresses each blade (B100x or B200x) needs for the type of configuration you require.



Note - The IPMP instructions provided in this chapter assume that you have two SSCs installed, that each is connected on all its ports to an external switch on the data network (the connections on each port of one SSC being duplicated on each port of the other, but connected to a different external switch on the data network), and that the NETMGT port on each SSC is connected to the management subnet. For information about configuring the switches and System Controllers in the chassis, refer to the Sun Fire B1600 Blade System Chassis Software Setup Guide.



Before you can set up IPMP on a blade, you need to reconfigure the blade to make it stop using DHCP. The DHCP configuration was required to enable you to install the operating system; instructions for migrating the blade to a static IP configuration (in preparation for IPMP) are provided in Section 11.3, Migrating From DHCP to Static IP Addresses.

Finally, instructions for configuring IPMP on a blade are provided in:

 


11.2 How IPMP Works on B100x and B200x Blades

The instructions in this chapter tell you how to use the Solaris IP Network Multipathing (IPMP) facility to take advantage of the redundant connections from each server blade to the switches in the chassis. A B100x blade's two 1000Mbps Ethernet interfaces are labeled respectively bge0 and bge1 (bge0 is connected to the switch in SSC0, and bge1 is connected to the switch in SSC1). A B200x blade's four 1000Mbps Ethernet interfaces are labeled respectively bge0, bge1, bge2, bge3 (bge0 and bge1 are connected to the switch in SSC0, and bge2 and bge3 are connected to the switch in SSC1). When the Sun Fire B1600 blade system chassis is fully operational, both switches are constantly active.

The IPMP driver on a server blade works by periodically pinging the default gateway from each Ethernet interface using a test IP address. The test addresses are used privately by the IPMP driver for the ping process. If for any reason one of the pings fails (indicating that the path to the network is no longer available on the interface that was used to perform the ping) the IPMP driver ensures that network traffic uses only the interface or interfaces that remains valid. Both interfaces on a B100x blade, or all interfaces on a B200x blade, can be active. This is referred to as an active/active configuration.

Alternatively the interfaces can be configured in an active/standby configuration in which one interface on the blade is active and the other one (on a B100x blade) is a standby interface, or (on a B200x blade) the other three are standby interfaces. In this type of configuration, if the failed interface is the active one, the driver assigns the IP address to the standby interface (or one of the standby interfaces), and that interface becomes the active one.

Because both switches inside the chassis are active (when the chassis is working normally), the instructions in this chapter tell you how to perform an active/active configuration. This maximises the performance of the chassis by ensuring that no interfaces are idle. For information about performing an active/standby configuration, refer to the IP Network Multipathing Administration Guide (816-0850).

The IP addresses you require for each blade to support the active/active configuration are:

The active IP addresses can be registered on a Name Server. They are the addresses by which other devices on the network communicate with the blade.

Test addresses are required (one per interface) for the ping process. These addresses are private to the IPMP driver (they are not registered on the Name Server).

In the next chapter, instructions are provided for setting up multiple pairs of virtual IPMP interfaces, each pair providing redundant virtual connections to separate VLANs.


11.3 Migrating From DHCP to Static IP Addresses

To install Solaris x86 onto a blade, you need to use DHCP as described in Chapter 10 (the PXE installation process depends upon it). However, if you want to use IPMP, you must stop using DHCP because it is not possible to configure a DHCP Server to support IPMP data and test addresses and grouping.

This section tells you how to make the blades use static IP addresses instead of addresses assigned by DHCP.

1. Make sure the addresses you intend to use for the blade or blades are not already in use by another device.

The addresses you use must be ones that cannot be assigned to another device by a DHCP server on the same subnet as the blade you are configuring. Either reserve the addresses in your DHCP configuration or use addresses for the blade or blades that are outside the range of addresses managed by the DHCP server.

For a:

For information about reserving addresses on the DHCP server, refer to the Solaris DHCP Administration Guide.

2. On each blade for which you are configuring one or more static addresses, remove or rename the files /etc/dhcp.interface, where interface is bge0 and bge1 (plus bge2 and bge3 for a B200x blade).

3. Edit the /etc/hosts file on the blade to define the IP addresses for the interfaces on the blade.

For purposes of illustration, the instructions in this chapter assume a base hostname of "medusa" for the chassis being configured. Various suffixes are then added to this base hostname to indicate an individual component or a network interface on a particular blade.

For example, for a B100x blade you will need entries in the /etc/hosts file that are similar to those in CODE EXAMPLE 11-1:

CODE EXAMPLE 11-1 Sample /etc/hosts File Entries for a B100x Blade
127.0.0.1       local host
192.168.1.151   medusa-s1  loghost    # first interface
192.168.1.152   medusa-s1-1           # second interface

For a B200x blade you will need entries in the /etc/hosts file that are similar to those in CODE EXAMPLE 11-2:

CODE EXAMPLE 11-2 Sample /etc/hosts File Entries for a B200x Blade
127.0.0.1       local host
192.168.1.151   medusa-s1  loghost    # first interface
192.168.1.152   medusa-s1-1           # second interface
192.168.1.167   medusa-s1-2           # third interface
192.168.1.168   medusa-s1-3           # fourth interface

4. On the blade, create an /etc/nodename file that contains the blade's hostname.

This will normally be the name used by the first network interface as specified in the /etc/hosts file (see Step 3). For example, if the blade's hostname is medusa-s1, the /etc/nodename file needs to contain the following information:

medusa-s1

5. On the blade, create a hostname.interface file for each interface, where interface is bge0 and bge1 (plus bge2 and bge3 for a B200x blade).

CODE EXAMPLE 11-3 Sample File for hostname.bge0
medusa-s1

CODE EXAMPLE 11-4 Sample File for hostname.bge1
medusa-s1-1

For a B200x blade you will need hostname.bge2 and hostname.bge3 files as well.

CODE EXAMPLE 11-5 Sample File for hostname.bge2
medusa-s1-2

CODE EXAMPLE 11-6 Sample File for hostname.bge3
medusa-s1-3

6. Disable routing, because the server blade is not being used to perform routing:

# touch /etc/notrouter
# ndd -set /dev/ip ip_forwarding 0

7. If your network routers do not advertise their presence to network devices, create an /etc/defaultrouter by typing the following command:

# echo ip-address > /etc/defaultrouter

8. where ip-address is the IP address of the router on the same subnet as the blade. For example, if the IP address of the default router were 123.123.123.8, you would type:

# echo 123.123.123.8 > /etc/defaultrouter

9. Reboot the blade to make it boot with its new static IP configuration:

# reboot


11.4 Configuring IPMP on a B100x Blade

This section tells you how to configure IPMP on a B100x server blade with two interfaces so that both interfaces actively transmit and receive data.



Note - Before following the instructions in this section, make sure you have performed the steps required in Section 11.3, Migrating From DHCP to Static IP Addresses.





Note - You need to perform the instructions in this section on each B100x server blade that requires a redundant connection to the network.



1. Log in as root to the console of the server blade whose interfaces you want to configure.

Type the following at the System Controller's sc> prompt:

sc> console sn

where n is the number of the slot containing the server blade you want to log into.

2. Edit the /etc/hosts file on the server blade to add the blade's two test IP addresses.

For example:

#
# /etc/hosts on the server blade in system chassis Medusa, slot 0
#
127.0.0.1      localhost       
 
192.168.1.151  medusa-s1   loghost # First active data address
192.168.1.152  medusa-s1-1         # Second active data address
192.168.1.101  medusa-s1-test0     # Test address for bge0
192.168.1.102  medusa-s1-test1     # Test address for bge1

3. Set the netmask in the server blade's /etc/netmasks file for the IP addresses of the interfaces on the blade.

For example:

192.168.1.0     255.255.255.0

4. If you have not already done so, disable routing because the server blade is not being used to perform routing:

# touch /etc/notrouter
# ndd -set /dev/ip ip_forwarding 0

5. In the /etc directory, create a hostname.bge0 and a hostname.bge1 file.

CODE EXAMPLE 11-7 Sample hostname.bge0 File
medusa-s1 netmask + broadcast + group medusa_grp0 up \
addif medusa-s1-test0 deprecated -failover netmask + broadcast + up

CODE EXAMPLE 11-8 Sample hostname.bge1 File
medusa-s1-1 netmask + broadcast + group medusa_grp0 up \
addif medusa-s1-test1 deprecated -failover netmask + broadcast + up

6. Reboot the blade so that it boots with its new IPMP configuration:

# reboot

7. Inspect the configuration of the four network adapters:

# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.1.151 netmask ffffff00 broadcast 192.168.1.255
        groupname medusa_grp0
        ether 0:3:ba:29:f0:de 
bge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
        inet 192.168.1.101 netmask ffffff00 broadcast 192.168.1.255
bge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 192.168.1.152 netmask ffffff00 broadcast 192.168.1.255
        groupname medusa_grp0
        ether 0:3:ba:29:f0:df 
bge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 3
        inet 192.168.1.102 netmask ffffff00 broadcast 192.168.1.255

The output above shows that four addresses have been defined. The two IPMP test addresses (associated with bge0:1 and bge1:1 respectively) are marked NOFAILOVER. This means that they will not be transferred to the surviving interface in the event of a failure.

8. Test that the IPMP configuration works by temporarily removing one SSC from the chassis.

This will cause error messages similar to the following to appear on the console:

Nov 19 13:20:47 medusa-s1 bge: NOTICE: bge1: link down
Nov 19 13:20:47 medusa-s1 in.mpathd[107]: The link has gone down on bge1
Nov 19 13:20:47 medusa-s1 in.mpathd[107]: NIC failure detected on bge1 of group medusa_grp0
Nov 19 13:20:47 medusa-s1 in.mpathd[107]: Successfully failed over from NIC bge1 to NIC bge0



Note - It takes approximately 10 seconds for the IPMP daemon to detect and recover from a network failure with the default configuration. The configuration of the IPMP daemon is defined in the /etc/default/mpathd file.




11.5 Configuring IPMP on a B200x Blade

This section tells you how to configure IPMP on a B200x server blade with four interfaces so that all interfaces actively transmit and receive data. The section provides two different methods of achieving network resiliency using an active/active configuration.

 FIGURE 11-1 Diagram Showing a Single IPMP Group Containing All Four Blade Interfaces

Line diagram illustrating the grouping of all four interfaces into a single IPMP group

 FIGURE 11-2 Diagram Showing Two IPMP Groups, Each Containing Two Interfaces

Line diagram illustrating the grouping of the blade interfaces into a two separate IPMP groups


Note - that the achievement of network resilience (enabling a blade to recover from different hardware and network failures) depends upon each IPMP group containing one connection to each switch. A configuration in which both interfaces in a group of two were connected to the same switch would not continue to transport network traffic if that switch failed. In Section 11.2, How IPMP Works on B100x and B200x Blades, we saw that bge0 and bge1 are connected to switch 0, and bge2 and bge3 to switch 1. This is also shown in FIGURE 11-2.





Note - Before following the instructions in this section, make sure you have performed the steps required in Section 11.3, Migrating From DHCP to Static IP Addresses.





Note - You need to perform the instructions in this section on each B200x server blade that requires a redundant connection to the network.



11.5.1 Configuring IPMP on a B200x Blade Using a Single IPMP Group for All Interfaces

1. Log in as root to the console of the server blade whose interfaces you want to configure.

Type the following at the System Controller's sc> prompt:

sc> console sn

where n is the number of the first slot (of the two) containing the double-width blade you want to log into.

2. Edit the /etc/hosts file on the server blade to add the blade's two test IP addresses.

For example:

#
# /etc/hosts on the server blade in system chassis Medusa, slot 0
#
127.0.0.1       localhost
192.168.1.151   medusa-s1  loghost  # first data address
192.168.1.152   medusa-s1-1         # second data address
192.168.1.153   medusa-s1-2         # third data address
192.168.1.154   medusa-s1-3         # fourth data address
 
192.168.1.101   medusa-s1-test0     # test address for bge0
192.168.1.102   medusa-s1-test1     # test address for bge1
192.168.1.103   medusa-s1-test2     # test address for bge2
192.168.1.104   medusa-s1-test3     # test address for bge3

3. Set the netmask in the server blade's /etc/netmasks file for the IP addresses of the interfaces on the blade.

For example:

192.168.1.0     255.255.255.0

4. If you have not already done so, disable routing because the server blade is not being used to perform routing:

# touch /etc/notrouter
# ndd -set /dev/ip ip_forwarding 0

5. In the /etc directory, create a hostname.bge0 and a hostname.bge1 file.