Virtualizing Switch Management

What has been happening to your data center port density over the years? If you've been adding server hardware, then chances are port density has been increasing in one's and two's. But if you've been adding virtualization, the port density may be rising in four's or eight's as you try to balance network I/O over multiple NIC's. Get ready to virtualize your management.

Mike Fratto, Former Network Computing Editor

March 4, 2009

4 Min Read

What has been happening to your data center port density over the years? If you've been adding server hardware, then chances are port density has been increasing in one's and two's. But if you've been adding virtualization, the port density may be rising in four's or eight's as you try to balance network I/O over multiple NIC's. Get ready to virtualize your management.Increasing port density is leading to increasing switch hardware, which adds to overall management burden. More switches to configure, monitor, and manage is just tedious. Even if you're using a network management system, you still have to deal with the devices. Recent announcements from Cisco with its Nexus Fabric Extender and Juniper's Stratus Project, both of which abstract management from infrastructure, are moves which should lead to simplified management.

When Cisco announced its Nexus Fabric Extender, a hardware switch that extends the functionality of the Nexus 5000 and soon 7000 switches to the top-of-rack hardware, it marked a shift in how data centers will be managed. Dubbed by Cisco as a rack and roll design, the Fabric Extender sports 48 Gigabit Ethernet ports and 4 10-Gigabit Ethernet ports which can uplink to a Nexus 5000. There is no configuration for a Fabric Extender. Just plug it in, power it up, and it grabs its configuration from the Nexus it is connected to. The ports on the Fabric Extender appear on the Nexus 5000 as local ports, which can be managed from that switch. The Fabric Extender itself doesn't even switch frames. It simply forwards frames from connected hosts up to the Nexus. The Nexus switches or routes the frame to its next destination.

Rather than manage up to 40 top-of-rack/end-of-row switches in addition to a core Nexus 5000, you can manage one Nexus 5000 with 1,920 ports distributed around your data center. Once support for the Nexus 7000 is added, the port counts go through the roof. Plug in, turn on, tune out.

Juniper, not to be upstaged by Cisco, announced its Data Center Solutions last year and provided some more details in February 2009. Stratus is a product vision -- there are no shipping products today, but Juniper is confident that it will have something at some point in the future... Stratus aims to virtualize the data center network fabric by treating all of the data center Juniper switches as one big switch, thus allowing management to scale into tens of thousands of ports. How it will accomplish this goal is unknown, but it articulated three value propositions:

  1. Linear scaling of performance while maintaining relatively simple management.

  2. Converging data networking and storage networking

  3. Create and maintain an elastic fabric that can support dynamism that virtualization offers

During the briefing I took, Junipers executives were going on about the mega data centers with more servers and switches than there are atoms in the universe (OK, I'm exaggerating (slightly)), but what about the rest of world that doesn't call themselves Google or Amazon? Juniper's execs indicated that Stratus is going to be beneficial at the more modest thousands of ports. I can buy that kind of port density, even for smaller data centers. Rather than manage a bunch of Juniper switches through JunOS, you manage all of the switches though what conceptually is a virtual JunOS interface.

All That And A Can Of Beans

Maybe I don't get it, but once you reach a handful of switches, doesn't it make sense to automate the management? I would think so, but an informal poll of some administrators I keep in touch with was enlightening. Even with network management systems, a lot of administration is very much manual on a switch-by-switch basis. That's largely due to the emergent chaos reining in networking as new devices are added, removed, or moved. Sticking to a strict naming convention for ports or even ensuring specific ports are used for specific purposes is difficult, if not impossible.

For most of the people I talked to, it's easier, cognitively, to think about switches and switch ports as discrete units named something like Rack 15, port 16 rather than that same port as port 254 or a port/slot/port model. You know where Rack 15 is. You don't know where port 254 or port 4, slot 1, port 16 is located. (I am just guessing on the naming structure, I don't actually know.)

Virtualizing switch management might have some benefits, but even so, I'm not sure that much is gained in simplifying management and I am pretty confident that it won't be a critical buying decision. I'd like to see what happens once these products make it into the field.

Read more about:

20092009

About the Author(s)

Mike Fratto

Former Network Computing Editor

Mike Fratto is a principal analyst at Current Analysis, covering the Enterprise Networking and Data Center Technology markets. Prior to that, Mike was with UBM Tech for 15 years, and served as editor of Network Computing. He was also lead analyst for InformationWeek Analytics and executive editor for Secure Enterprise. He has spoken at several conferences including Interop, MISTI, the Internet Security Conference, as well as to local groups. He served as the chair for Interop's datacenter and storage tracks. He also teaches a network security graduate course at Syracuse University. Prior to Network Computing, Mike was an independent consultant.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights