Operating instructions

56 Cisco Systems Intelligent Gigabit Ethernet Switch Module
There is another (internal) consequence of the Management Module proxying for its IP
subnet: If a blade server is placed on the IP subnet and VLAN that is being used by the
IGESM’s management interface, the blade server will almost certainly fail to bring up its IP
interface, as one of the first things most OSs do when they bring up an IP interface is to send
out an ARP request looking for its own IP address (to make sure someone else is not already
using it). If the blade server is on the same VLAN/IP subnet that the IGESM is using for its
management VLAN, the Management Module will respond back to this ARP request and the
blade server OS will shut down the TCP stack, as it assumes a duplicate IP address is
already on the network.
Perhaps even more of a problem for this internal issue is that if the blade server is already up
and running, and the Management Module and the IGESM are then placed into the same
VLAN, the blade server will usually keep operating normally until it gets rebooted. When it
comes back up it will re-attempt to see whether anyone has its IP address, and will fail when
the Management Module responds to the initial ARP from the blade server. (The blade server
sees this ARP response to its own IP address and will assume someone else already has its
IP address.)
One final issue with placing the blade servers on the same VLAN as the IGESMs
management interface is that under certain cases (if the Management Module is also using
that same IP subnet), some user data traffic can actually attempt (unsuccessfully) to flow
through the Management Module, instead of strictly through the IGESM’s uplink ports.
For the purpose of the scenarios discussed in this section we will define three types of traffic:
򐂰 Data Traffic
This is user data carried from the production network, over the uplink ports of the IGESM,
and into and out of the blade servers installed within the BladeCenter.
򐂰 Management Module Traffic
This is management traffic that is carried to or from the Management Module, carried over
the Management Module uplink port, for accessing the Management Module.
򐂰 IGESM Traffic
This is management traffic that is carried to or from the IGESM for managing the IGESM,
and may be carried via the Management Module’s uplink connection or over the IGESM’s
uplink connections.
While the IGESM will not permit ports g0/15 and 16 to be shut down—they are hard-coded to
always be up—the other side of the connection (MM ETH1 interface) can be set to Disabled,
which disables
all internal Ethernet connections from the Management Module to any device
in the BladeCenter. This is because it does not shut the port down; instead it stops
responding to any inbound internal requests. This includes any other Ethernet Switch
Modules, as well as any SAN modules and even any Serial over LAN connection (if one has
been configured) from the Management Module to blade servers. Because of this complete
loss of Ethernet access, disabling the ETH1 interface is useful only in very specific
situations—for example, if you did not need internal Ethernet management access to any
other devices in the BladeCenter, or Serial over LAN—thus usually is not recommended.
Tip: The best way to guarantee that these internal issues will not happen is to keep the
blade servers off of the VLAN that is defined as the management interface VLAN on the
IGESM.