Sun Microsystems' N1400V Switch

While other vendors in the L4-7 application switching market have been concentrating on application-oriented features such as acceleration, security, and protocol-specific switching, Sun Microsystems has been quietly working on virtualization. In addition to traditional network-based failover capabilities, its recently released N1400V now also supports virtual failover capabilities. Instead of an all-or-nothing scenario, one set of virtual services can fail over to a second switch while the others keep running.

The N1400V uses the same technology as Sun's N2120V and N2040V switches, but it's scaled down from a 2U to a 1U form factor. And with only a single network processor to power its four SFP Gigabit Ethernet ports, it costs half the price of the earlier model. Sun's custom function cards, separate from the mainboard in the N2100V family line, are integrated with the mainboard in the N1400V, and the user interface has been improved. In the past, for instance, if one administrator cleared the counters for any part of the system--like virtual services--they were cleared permanently on the switch. Now the clearing of counters is session-based, and clearing them for one administrator won't clear them for other administrators logged into the device.

Sun's N1400V assumes the same virtual concepts as the N2000 series--that is, virtual switches (vSwitches) and virtual routers (vRouters) are used to partition a single switching device into virtual entities. As with software virtualization, each vSwitch and vRouter can be designated a specific set of ports (just like a VLAN), but unlike the concept of VLANs, each vSwitch can be allocated a set amount of resources (memory, bandwidth, etc.), which helps keep applications from tromping on one another. The concept is also useful for keeping traffic completely segregated, as traffic on one vSwitch can't be seen on another.

Using its proprietary Virtual Switch Redundancy Protocol (VSRP), you can actually put to good use the second switch in a redundant pair, which is often considered little more than availability insurance. The N1400V uses the Virtual Router Redundancy Protocol (VRRP) for standard failover scenarios and VSRP for more flexible scenarios, including the ability to fail over to a single vSwitch without forcing all traffic to move to the secondary one. The 1400V can be configured in an "all-or-nothing" setting, but the real power of virtual switches is seen in the alternate "per-vSwitch" mode.

I set up a pair of N1400V units in our Real World Lab in Green Bay, WI, with an HP ProCurve 3400cl series Ethernet switch between them. After configuring multiple VLANs on the HP switch and setting up the appropriate vSwitches, vRouters, and virtual services on both of the Sun units, I was ready to test. This isn't by any means a simple task. The configuration of VSRP parameters needs to be carefully considered in order to create the desired failover scenario.

The active switch is automatically determined by selecting the unit with the highest VSRP preference value. When configured in an "all-or-nothing" mode, this value is determined by summing the number of master VRRP links, the unit's initial VSRP preference value, and bonus points as specified in the initial configuration. By giving one switch a VSRP preference of 100 and the other 0, I was able to force the first switch into being elected the master. As links fail, the VRRP award on the standby switch increases until the secondary switch VSRP preference value surpasses the first. The second switch will now be elected as the VSRP master, and the failover process is complete.

Interswitch communication of the Routing Information Protocol version 2 (RIPv2) sessions over separate VLANs allows this failover mechanism to work properly. But this also increases the complexity of the configuration, and the flexibility of allowing a per-vSwitch scenario means a bit more work than with most high-availability implementations. The addition of a new export option makes this configuration a bit less onerous because it's now possible to configure one switch, export the configuration, and then replay it on the secondary switch.

In this case, I wanted Service1 active on Switch1 and Service2 active on Switch2, with standby services for each running on the alternate switch. This splits the traffic for each service across the two switches, making both of them useful without necessarily running into the issues typically associated with an active-active failover scenario--such as when traffic rises to over 50 percent capacity on both switches and one of them fails, a problem because a single switch can't handle greater than 100 percent capacity. Services can easily be assigned based on traffic patterns such that if all services on a single switch are active, the volume should still be manageable. This is due to Sun's unique virtual switch architecture, and it makes purchasing that secondary device a lot more palatable than it is with some competing systems.

Once the switches were configured, I fired up a Spirent Web Avalanche and started tossing requests at both services. A Spirent Web Reflector served to emulate the back-end HTTP servers. I tested two different virtual service configurations: one doing simple L4 load balancing, and one with TCP offloading capabilities through Sun's custom function cards, essentially terminating the TCP connection on the switch in a half-NAT configuration. Each client requested a total of 24KB in five files (one text, four image). Both tests showed an average successful transaction rate averaging 12,000 HTTP GETs per second with a roundtrip time of 438ms, all while sustaining traffic rates of 850Mbps.

After running the basic performance tests, I set the Avalanche up to run in a steady state for several hours. During that time I shut down the TCP offloading functionality in Switch1 and watched as all traffic was immediately diverted to the secondary device as expected. After starting the functionality back up, the primary device was re-elected as the master switch, another feature not often found in other high-availability devices. This is a configurable option that's based on the VSRP election increase parameter; the default is to not fail back.

I also tested the N1400V's ability to take advantage of multiple paths through the system. I started up a long-running test on the Avalanche, and then disabled one of the primary VLANs on the secondary switch while traffic was flowing to Service2. Traffic was immediately rerouted through a backup VLAN with no apparent interruption. I then enabled the VLAN, and traffic again began flowing as normal, with no traffic traversing the backup VLAN. This feature is particularly useful on the back end because it provides an alternative route to back-end servers using interswitch communications channels. The feature is available on many modern switches, but it's a plus if you're upgrading from older switches without this capability.

At a list price of $21,995 for the N1400 (including only one virtual switch) and $25,995 for the N1400V, this is a good investment. I'd suggest the N1400V, as the real power and bonus features of the product are really seen when configured to use multiple virtual switches.Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator, and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].