Datasheet

© 2011 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 14
3750-X#remote command all show version | include Hardware
Switch: 1: (Master)
---------------------
Hardware Board Revision Number: 0x03
Switch: 2:
---------------------
Hardware Board Revision Number: 0x03
Cisco has been shipping switches compatible with the service module since January 2011. Refer to the account
manager for how to replace older revisions when ordering the service module.
In case the service module is plugged into an old hardware revision switch, Flexible NetFlow and MACsec
functionalities will be disabled: the service module will operate in “pass-through” mode, essentially behaving like a
10GE Network Module.
The minimal Cisco IOS Software release for the service module is 15.0(1)SE. Older Cisco IOS Software
revisions will not recognize the service module.
The license level required on the switch to support the service module is either IP Base or IP Services. A service
module inserted into a switch running LAN Base will operate in pass-through mode.
Software Compatibility for the Service Module
Differently from other field-replaceable uplink modules available for Cisco Catalyst 3560-X and 3750-X Series, the
service module has its own operating system, CPU, memory, switching fabric, and file system. This can enable
many sophisticated applications such as Flexible NetFlow, but from the software management perspective it
introduces an additional software subsystem in the switch or stack of switches. The version-numbering scheme for
the service module software is the same as in Cisco IOS Software.
The service module software is deployed through a software package, a .tar file, distinct from the Cisco IOS
Software image. Caveats can be tracked down to a particular version specifically for the service module software,
meaning it will be a new product in the Cisco Defect and Enhancement Tracking System (CDETS) system.
Software version incompatibility: A matching between the software version on the service module and the Cisco
IOS Software version on the stack (for example, 15.0(2)SE1 and 15.0(2)SE1) is expected; otherwise, a version
mismatch will occur (for example, 15.0(1)SE and 15.0(2)SE2). Versions of the service module can be retrieved
through the Cisco IOS Software command-line interface.
If within a particular Cisco IOS Software release, changes are not required in the service module software, as
might happen when the product has matured, a new version will be provided regardless. In this case the change
will be just the software version string and will be documented in the release notes.
With the simple compatibility schema just described and the implementation of the update requirements, there is
no need for a compatibility matrix to be maintained and documented. Let’s see its implications to the most
common situations seen by customers, where software compatibility needs to be assessed:
●
The service module is deployed in a stack of switches for the first time.
As the network is already undergoing maintenance, customer will make an assessment of the most suitable
software release and perform an update of all the subsystems in the stack, including the service module.