Cisco Ethernet switch Operations Instructions download pdf (Page 69)

Chapter 5. Cisco Systems IGESM management and user orientation 55

5.3 In-depth management path discussions

In this section, we take a closer look at the interactions of the Cisco Systems IGESM with the

Management Module and at the rules that are necessary to ensure a stable management

connection to the IGESM.

5.3.1 Introduction to this in-depth management discussion

This section attempts to clarify the preferred paths, in particular the management paths for

the various types of traffic that will be carried to and through the Cisco Systems IGESM in the

IBM BladeCenter. We show examples of seven possible scenarios and detail why some

designs are recommended and why some are not.

Note that the discussions in this section were valid when we wrote this section. It is possible

that future revisions of code or hardware may change the operation as defined here and may

invalidate portions or all of this section.

For reference purposes, this section was verified against an IGESM model number 13N2286

(as reported by the Management Module, but also referred to as the 13N2281) with IOS

revision 12.1(14)AY4. The Management Module in use was a model 02R1606 running

release firmware BRET67D, dated 7-22-04, revision 16.

5.3.2 Why was this in-depth section created?

Because of the design of the BladeCenter—there are possibly two paths to manage the

IGESM (via the Management Module uplink port or via the IGESMs uplink ports) and the fact

that there is always an internal link between the IGESM and the Management

Module—certain designs will lead to unexpected results and possible hit-or-miss connectivity

to the management VLAN interface of the IGESM.

To define this further, there is an issue with certain designs based on the fact that the IGESM

always tries to provide a path between itself and the Management Module, and the

Management Module always tries to act as a proxy for the IGESM’s management IP address

(and several other IP addresses on its internal IP subnet). The end result is that the

Management Module will respond to any ARP request on its uplink port, for any IP address

that it manages on its internal subnet (this includes the eth1 interface of the Management

Module and the IP address for each switch bay in the BladeCenter).

If both the Management Module uplink and the IGESM uplinks are placed in the same IP

subnet, on the same VLAN, and External management over all ports for the IGESM is set to

Enabled (a Management Module feature setting), then both the Management Module and the

IGESM will attempt to respond to ARP requests for the IGESM’s IP address. Under this

condition, if the Management Module’s ARP response is accepted by the upstream device,

IGESM management traffic may try to flow through the Management Module, which may or

may not actually pass it on to the IGESM. Also, ARPs are broadcast-based, so the IGESM

sees the Management Module response and sends out a gratuitous ARP to tell the world that

it owns its own IP address. The Management Module sees this and responds in kind, and an

ARP war breaks out on the upstream network that owns the IP address of the IGESM.

The primary purpose of the remainder of this section is to discuss how to integrate the IGESM

into an infrastructure in such a fashion as to avoid these issues and ensure stable

management connectivity.

Note: All of these issues take place on the upstream external network from the

BladeCenter.

1 ... 68 69 70 ... 266

Comments to this Manuals

No comments

Cisco Ethernet switch Operations Instructions Page 69

Comments to this Manuals

Related products and manuals for Networking Cisco Ethernet switch