Articles and Tips:
01 Jul 1998
Editor's Note: "Technically Speaking" answers your technical questions, focusing on issues that affect network administrators. To submit a question for a future column, please send an e-mail message to firstname.lastname@example.org, or fax the question to 1-801-228-4576.
The last issue ofNetWare Connectionexplained what a switch does and when you should install a switch on your company's network to improve performance. (See "Switching to Switches,"NetWare Connection, June 1998, pp. 33-34. )To improve performance even more, you can install multiple network interface boards in a server. You can then increase throughput between the server and the switch by implementing one of the following solutions:
Load balancing, which is built into Novell's NetWare Link Services Protocol (NLSP) extension for IPX
Port aggregation, which is built into specialized network interface boards and hardware drivers
This article explains how each solution works. To help you decide which solution is best for your company's network, this article also lists the hardware requirements and performance issues associated with each solution. For example, when not properly configured, load balancing can actually reduce performance. (For more information about potential configuration problems, see document number 2910835 on Novell's Support Connection site. To view this document and other documents mentioned in this article, go to http://support.novell.com, and select the KnowledgeBase option. Then enter the document number in the search field, and click the Find button.)
Load balancing increases network throughput by distributing the network load across multiple network interface boards in a server. With load balancing, the server can send packets through multiple network interface boards connected to the same segment, rather than using only one network interface board, which can become a bottleneck.
Load balancing is an outbound service, handling only packets being sent from the server. Incoming packets still determine their route based on the server's responses to workstations' Get Nearest Server requests. Although incoming packets are not load balanced, the server's responses to these requests are.
To determine which network interface board should reply to which packet, the server builds a routing table that includes the media access control (MAC) address of each network interface board connected to the same segment and assigns a unique sequence number to each network interface board. The server uses this routing table to ensure that the network load is distributed among the network interface boards.
The first time the server needs to send a packet using the routing table, the server sends this packet through the first network interface board listed in this routing table. The server then sends the second packet through the second network interface board, the third packet through the third network interface board, and so on. Once all network interface boards have been used, the server starts over with the first network interface board. (See document number 2926169 on Novell's Support Connection web site.)
For example, suppose that a server contained two network interface boards enabled for load balancing and that the server received Get Nearest Server requests from three workstations connected to that server. To reply to the first workstation, the server would send a response through the first network interface board in the routing table. To reply to the second workstation, the server would send a response through the second network interface board. And to reply to the third workstation, the server would go back to the first network interface board to send a response.
Before you decide whether to enable load balancing, you should know that Novell's load-balancing services require specific hardware. First, you must install multiple network interface boards in a server. (You can also install one multiport network interface board and connect all of the ports to the switch.)
With load balancing, you can use any network interface boards and hardware drivers that support Open Data-link Interface (ODI) Server Specification 3.2 or above. (Hardware drivers that support this specification also support NLSP.) In addition, you can install any combination of network interface boards in the server. For example, you could enable load balancing on a server in which you had installed a network interface board from 3Com and a network interface board from Intel.
Second, you must install a switch on the same segment as the server that contains multiple network interface boards. Of course, Novell's load-balancing services allow you to distribute the network load across multiple network interface boards that are connected to any device on the same segment, such as a standard hub. However, you will not receive a performance benefit unless you connect the network interface boards to a switch, which enables concurrent packets to travel to and from the server.
Third, the segment on which the server resides cannot contain a bridge. If the server were connected to two segments through a bridge, the network interface board connected to segment A could send a reply through the bridge to a workstation on segment B. As a result, performance could be degraded. (See document number 2926169 on Novell's Support Connection web site.)
As mentioned earlier, Novell's load-balancing services are built into NLSP, which is implemented as an enhancement to IPX. Because load balancing using NLSP is IPX specific, you cannot use this type of load-balancing with other protocols, such as TCP/IP and AppleTalk. Novell's load-balancing services support TCP/IP only across WAN links that use the Open Shortest Path First (OSPF) routing extension to TCP/IP. (See document number 2924197 on Novell's Support Connection web site.)
You should also consider two performance issues as you decide whether to enable load balancing. First, each additional network interface board you install in a server does not provide a 100 percent increase in network throughput. In fact, load balancing offers diminishing returns: One additional network interface board may increase network throughput by up to 50 percent, while a second additional network interface board may increase network throughput by only 33 percent more. And the third additional network interface board may increase network throughput by only 25 percent more.
Second, if a majority of workstations established a connection to the server through one network interface board, this board will respond to the majority of incoming packets. For example, suppose a server contained two network interface boards. If the first network interface board were busy when 10 workstations sent Get Nearest Server requests, the second network interface board would respond to these workstations. Once a workstation establishes a connection through a specific network interface board, that network interface board responds to all packets the workstation sends to the server until this workstation changes its connection to another network interface board.
You can try changing the workstation's connection by rebooting the workstation, which forces it to reestablish the connection. However, there is no way to ensure that the workstation establishes this connection through a different network interface board. Because you have no control over which network interface board the server will use to send a response to the workstation's Get Nearest Server request, this workstation may establish a connection through the same network interface board to which the workstation was previously connected.
In addition, you should know that if you enable load balancing on a server, the server cannot automatically reestablish a workstation's connection if this connection is lost. (See document number 1004697 on Novell's Support Connection web site). As a result, if autoreconnect capabilities are critical to a network, you should not use load balancing.
Losing autoreconnect capabilities can cause a problem: If the connection between the switch and one of the server's network interface boards were lost, the server would be unaware of this lost connection and would continue to send packets through the network interface board. As a result, workstations would lose their connections to the server and could not reestablish these connections because the server would not recognize that the workstations were no longer connected.
Enabling Load-Balancing Services
To enable Novell's load-balancing services, you must install multiple network interface boards in the server, and you must connect these network interface boards to a switch on the same segment. You must then complete the following steps at the server console:
Load the INETCFG utility by entering this command at the server console:LOAD INETCFG
Select the IPX option from the Protocols menu, and then select the NLSP option to enable NLSP.
Select the IPX Expert Configuration option from the IPX menu. In the Maximum Number of Path Splits field, enter the number of network interface boards in the server that are connected to the network or the number of ports in the server that are connected to a switch. The highest number you can enter is 8.
Select the Load Balance NCP Packets to Local Clients option from the IPX menu; then select the Enabled option.
Save your changes, and exit the INETCFG utility.
Next, view the NETINFO.CFG file, which is located in the SYS/ETC directory, to ensure that the following line appears in this file:LOAD IPXRTR ROUTING=NLSPIf this line does not appear, add it to the server's AUTOEXEC.NCF file before the SYS:ETC\INITSYS.NCF command.
Ensure that the following line appears after the LOAD IPXRTR command in the NETINFO.CFG file:SET LOAD BALANCE LOCAL LAN=ONIf this line does not appear, add it to the server's AUTOEXEC.NCF file after the SYS:ETC\INITSYS.NCF command.
Port aggregation also increases network throughput by distributing the network load across multiple network interface boards in a server. With port aggregation, however, the network interface boards are combined to create one virtual network interface board with multiple ports. The switch is connected to the server through this virtual network interface board.
For example, suppose that a switch were connected to a server containing two network interface boards, which were combined to create one virtual network interface board with two ports. When the virtual network interface board received a packet, a port aggregation driver would split the packet evenly across both ports, sending the portions of this packet to the server in a single action. The server and the switch negotiate how the packet is split across the ports and generate a sequence for reassembling the packet.
Port aggregation requires specialized network interface boards and port aggregation drivers, in addition to a switch. These specialized network interface boards and port aggregation drivers usually cost more than standard network interface boards and drivers.
Adaptec Inc. is the only company I know of that provides specialized network interface boards and port aggregation drivers that offer full-port aggregation services for a NetWare network. Adaptec makes DuraLAN Fast Ethernet network interface boards and Duralink port aggregation drivers. (For more information about DuraLAN, go to http://www.adaptec.com/adaptec/press/release980427a.html. For more information about Duralink, go to http://www.adaptec.com/products/overview/portaggregation.html.)
In addition to specialized network interface boards and port aggregation drivers, port aggregation requires a switch, which must be located on the same segment as the server that contains the specialized network interface boards. (Port aggregation does not work with a standard hub.) You must then connect the specialized network interface boards to the switch, thus enabling concurrent packets to travel to and from the server.
Although you may have to pay more to implement port aggregation because you have to purchase specialized network interface boards and port aggregation drivers, this solution does offer a significant advantage: Because port aggregation is based on hardware rather than on protocol extensions, port aggregation is protocol independent. As a result, port aggregation works with IPX, TCP/IP, AppleTalk, and any other protocol bound to the virtual network interface board. Port aggregation also works with both incoming and outgoing packets, evenly distributing these packets across ports.
Port aggregation addresses the performance issues associated with load balancing. In terms of raw network throughput, port aggregation offers a one-to-one ratio of added network interface boards and increased network throughput. For example, if you added a second, specialized network interface board to a server, you would increase network throughput from 10 Mbit/s to 20 Mbit/s in an Ethernet environment. You would increase network throughput from 100 Mbit/s to 200 Mbit/s in a Fast Ethernet environment.
With port aggregation, you can increase network throughput even more by running the virtual network interface board in full-duplex mode, if the switch you are using supports full-duplex mode. (Full-duplex mode allows the virtual network interface board and the switch to send and receive packets simultaneously.)
Port aggregation also provides a resilient link: If the connection between the switch and one of the server's network interface boards were lost, the virtual network interface board would simply disable the port associated with the lost connection. The remaining ports then continue to operate normally. As a result, one lost connection does not prevent workstations from connecting to the server.
If you implement load balancing or port aggregation in a properly configured switched environment, you can increase throughput from the server to the switch. You should use Novell's load-balancing services if you want to increase network throughput over IPX and if you do not need a resilient link. If you want to use other protocols or if you do need a resilient link, you should use port aggregation.
Mickey Applebaum has worked with NetWare for more than 14 years. Mickey provides technical support on the Internet for The Forums (http://theforums.com).
NetWare Connection,July 1998, pp. 22-24
* Originally published in Novell Connection Magazine