Operating instructions

68 Cisco Systems Intelligent Gigabit Ethernet Switch Module
Of primary note is the fact that each of the management paths (for the IGESM and the
Management Module) are on separate VLANs, thus separate IP subnets, and that the paths
that are used for data traffic into the blade servers does not use either of these VLANs.
This follows network-design best practices in keeping user and management traffic isolated,
and it prevents the Management Module (via VLAN and IP subnet isolation) from trying to
provide proxy support for the IGESM and is thus completely stable and fully recommended.
Note that the link between the IGESM and the upstream network is shown as an 802.1Q
trunk in this example. There are other ways to meet the separation of traffic requirement, such
as putting VLAN Y on a single access link on IGESM port g0/17, then putting VLANs A, B, C,
and so on onto an 802.1Q trunk port made up of any combination of IGESM ports g0/18, 19,
or 20. This accomplishes the same end-requirement of separation of the management VLAN
from blade server VLANs, so it would work.
However, it is not very practical, as there is no redundancy to the management interface of
the IGESM. If port g0/17 goes down, you lose management connectivity to the IGESM. A
more logical approach is to produce one or two Etherchannel bundles out of the uplinks from
the IGESM and configure them as 802.1Q trunks to carry all desired VLANs—both the
management VLAN and the blade server VLANs.
One final comment: The red line between the IGESM and the Management Module is shown
here to reiterate that, technically, VLAN Y is actually carried over to the Management Module
(over the native VLAN on the link). In this scenario it is not an issue, as the IP subnet on the
Management Module is different from that being used on the IGESM management interface
(VLAN Y), so there is no chance that the Management Module will attempt to proxy for
devices on VLAN Y because the Management Module only proxies for devices on its own IP
subnet.