I’ve been a big fan of Cisco Service Modules and often used the Cisco Application Control Engine (ACE) and Firewall Service Modules (FWSM) to solve design and operational needs. But I’ve moved on – it’s time to realise that Service Modules don’t cut it for modern virtualization networks. In this post, I look at the reasons why they were useful, and why I’m not  fan now and speculate on the lost value of these solutions to problems.

Attractions

Here are some of the attractions of service modules when I’ve used them previously :

• I don’t need to rack them. For some organisations, getting equipment installed into racks is an substantial problem. But adding a new module doesn’t require the same approval.
• by connecting to the backplane they were more likely to be in the right place, and didn’t need extra cabling. Again, in some businesses getting cabling or data center access is very difficult.
• no external consoles needed since they were managed from the C6500 console in an emergency. Not all organisations have console servers in place.
• the virtualization features were highly useful and arrived ahead of other vendors (industry leading at the time)
• the flexibility to “reach” all the VLANs was a great feature.

The list of Advanced Integration Services Modules can be found here, but my favourite of service modules has been the Network Analysis Module (NAM). My least favourite thing has been the price gouging of Cisco product managers in bringing these products to market.

For those companies where data center or network changes is too difficult, the NAM was a particular relief. When installed into the C6500, I could connect and monitor any VLANs, IP address, MAC address, Application. The software was good — not awesome, but it was simple enough to use, didn’t crash or fail much, and provided enough information and reports to be broadly useful.

The NAM software is often the only tool in some organisations that I was allowed to dynamically configure – Network management teams controlled the apps, sniffers required physical access and SPAN changes which are change controlled. Its ability to hold long term charts and monitoring solved all of these problems.

Thus, things in favour of the NAM are:

• easy install – no cabling or power appropriation process.
• existing vendor – therefore no tender / supplier / evaluation process
• software is good enough. Not great, just OK.
• connects to the core of your network
• avoids change control being able to tap any VLAN in the chassis ( although SPAN and RSPAN is still possible if needed).

Things against the NAM:

• WS-SVC-NAM-2-250S Cisco Catalyst 6500 and Cisco 7600 Network Analysis Module $29,995.00
• CON-SNTE-WSSVNAM2 SMARTNET 8X5X4 Catalyst 6500 Networ $3,212.00

If you look closely at the NAM module (see below), you’ll notice that it’s a Intel server chipset on a daughterboard (the visible PCB on top here), complete with HDD, RAM, North and South Bridges etc. The motherboard (on the bottom) provides “network adapters” that connect to the C6500 backplane via some fabric interconnect chips and power connections.

That right, it’s a USD$2000 server, at best, stuck on top of a C6500 blade.

What’s Changed

The service modules have failed to innovate at a pace that is acceptable. I believe this is because the inherent physical architecture limitations of using the C6500 backplane:

• Physically fit onto a C6500 line card.
• connecting to the switch fabric via the backplane which required a dedicated silicon chip with unusual requirements ie. it’s not a NIC so new software is required to communications.
• Use the Cisco custom silicon fabric interface to connect to the backplane.
• Low thermal requirements – C6500 modules are not able to have special cooling, and the chassis wasn’t designed for a lot of cooling in the first place.

I’m guessing that Cisco’s business units found it hard to agree and the modules were not a high priority – they haven’t been able to keep up with wider developments.

We’ve recently seen the release of the ASA-SM which basically an Intel computer ( because that what the ASA hardware – commodity Intel silicon with what I think is Cavium crypto chip ) on a C6500 module to replace the very old FWSM. I’ve heard rumours of this module for about three years, and it was due in 2009, 2010, then 2011.

This long delay has me wondering about what the underlying challenge was. Some speculation :

• Cisco’s internal development suffered a major challenges when chip design moved from America to India a few years back.
• Then followed the management change to a feudal management model meant that, likely, business units found it difficult to co-operate effectively because each unit had to make it’s figures this quarter, not in the future.
• The C6500 is obviously being replaced by the Nexus 7000 family and therefore product management might have been wavering around funding the project ? Not helped by the executive mixup either. Were there questions about making a product for a product family that was obviously nearing the end of it’s useful life ?

IDS Modules

If my research and guessing is correct, the IDS modules are unlikely to return to the C6500 and we are stuck with the performance limited IDSM-2. The IPS software needs a lot of CPU and the software is growing more complex and more CPU is needed to perform at speed. Fast CPU’s generate a lot heat and the thermal capacity of a C6500 slot is quite limited.

The latest generation IPS units at 10Gbps have 4RU chassis and that mostly because of the cooling requirements for a system that will constantly run the CPU hard and hot.

ACE Modules

The previous generations of the ACE20 silicon is End of Life. Apparently the existing architecture is not IPv6 capable and a new silicon spin is needed.

Just a thought here. How could Cisco design the ACE module without thinking about IPv6 ? The module is only five years old and well within the predictive timeframe of the IPocalypse. This seems like a gross internal business/product failure to me.

Given the money and time invested into the ACE20 modules, are you really going to pony up for the ACE30 ? The software really isn’t that great, it’s expensive and missing a lot of features at the application level. The bugs I’ve experienced over the last four years have been grim – that is, they weren’t hard to find bugs they were impressively stupid — “reboot it every week or it will lockup” or “hang in the middle of the day” type problems over multiple sites. I may have been unlucky, but it’s unlikely given the application mix and thus I’ve lost faith in the platform.

My belief in the Application Control Engine is pretty much over ( I previously reviewed it here ). For load balancers, I’m into F5 if I can get the money or anything else if I can’t. Unless someone can assure me that the ACE software got a lot better in the last year or so, I’ll continue to look other products by preference.

Other Service Modules

Much of this debate applies to other service modules that I’ve not discussed such as the IPsec, VPN etc. However most of those are deprecated or have limited application and I’ll not discuss them here.

Service Modules software

One of the bigger problems with all Service Modules has been the slow pace of software updates to any of those modules – bugs take a long time to get fixed. I surmise that the use of the backplane fabric chips causes a lot of delays in custom driver development. The ASA platform, for example, uses off the shelf network adapters that are well known to developers and could even reuse existing open source code.

The EtherealMind View

I look at Service Modules as something that filled a technology niche that existed before 10GbE arrived and doesn’t now. The FWSM was a good multi-gigabit firewall on release – but there a lot of multi-gigabit firewalls that have far more capabilities than stateful packet filtering of the FWSM – consider SonicWall and their new platform which has a great interface for reporting and feedback as well as 10GbE performance. Or the ASA558x series which has up to 10GbE performance, and is more easily replaced and upgraded and support is much better for that unit. Similar logic for the IDSM-2, or ACE30 or FWSM. Using external units with 10GbE is far more cost effective today and appears to be better value.

The combination of:

• slow pace of software updates and bug fixes
• the outdated architecture & relatively limited backplane speed of the C6500 (compared to Nexus 700)
• and limited performance of new and existing products

all suggest that the time for planning and designing Service Modules is over. There are no suggestions that service modules for the Nexus 7000 will be developed that I can see. I can prognosticate that it would slow down the development of the core switch / route / performance functions, and it will be some years before those core capabilities are complete enough that service modules would become viable product development tasks — they might be in development, but not much chance of going into production. 1

Do I sound bitter about Service Modules ? A bit. I’ve had a number of hard to solve problems that lasted months before code fixes arrived. I’ve been fan of the NAM but the price is now far removed from it’s practical value. USD$30K List is way over priced for its capabilities and even with a 30% discount, you can buy a lot of network management systems that deliver much better functions and features for that price.

Service Modules look like a product of 2005 and the needs of that time. The drive to open standards means they are losing relevance as Cisco focusses on the Nexus NX-OS platform for growth over the next five years and the wider market chooses multi-vendor solutions to cover gaps in Cisco’s portfolio. Until the roadmap for Nexus 7000 includes Service Modules, I’ll be looking to choose standalone units. All the positive points of Service Modules are business process so I’ll do the paperwork and change requests, because that’s less hassle than owning a service module.