I have a network with 2 Cisco 3750 fiber switches. I configured each switch with a unique vlan 1 ip address for remote management. All ports are in trunking mode as each port may connect to a Ethernet switch with ports in vlan 1 or vlan 2. When the switches were installed on site, the installer cascaded the switches together using the StackWise cable. I did not realise that a stack would form because of this cabling. However, things became complicated when we put in a wireless tower. One switch had to be put in ip routing mode because one port needed an IP address as it was directly connected into a Dragon Wave wireless modem. I became very confused one day when the power went out and the switches rebooted so that switch two came up and was elected the master, getting the config of switch one. This, of course, made no sense since it is not in ip routing mode and no ports have an ip address. After much frothing around, I disconnected the StackWise cable and just used one port on each switch to interconnect. I had to manually restore each switch to its original configuration. This, however, makes no sense because I am wasting a port on each switch. The issue has become a little more complicated now because I had to upgrade switch 1 to the advancedIP firmware. An ISP helped us put in Cisco 2821 routers to take adavantage of OSPF routing and a MetroNetwork.
My question: Can I interconnect 3750's using the StackWise cables, but preserve the independence of each switch, that is, disable the formattion of a Cisco stack? I have a couple of other sites with switches interconneted using one of the fiber ports, so I would like to be able to free up these ports and just use the StackWise cable.
Sal is quite correct. If you use the stackwise cable then you get a stack. If you want the switches to operate independently, and especially if you want to run different images, then you need to connect port to port.
OK, that clarifies the issue. However, I am now wondering about connecting 3750s using the StackWise cables when neither switch is in IP routing mode, they are all just working at layer 2. As indicated previously, I configure each switch with a unique IP address on vlan 1. All ports are in trunking mode. If I connected several 3750 switches using a StackWise cable, they become a stack (and remove the port to port interconnect). From the stack master, I could logon to the other members using the "session stack-member-number" command. However, my question relates to assigning IP addresses. If only one becomes elected as the stack member, how would I know which IP address to telnet to in order to manage one of the switches (i.e., which one becomes the master)? Would I need to provide a vlan 1 ip address for each (as is the case now) or should I assign a vlan 1 IP address to just one? The latter doesn't make too much sense. What would happen if one of the switches without an assigned vlan address become the master? At most we have 4 switches interconnected, but I can see this as being a bigger problem if you had say 10 switches cascaded together.
The stack operates as a single logical entity and needs only 1 IP address for management purposes. So if you configure VLAN 1 and assign an IP address to that interface then it will be used by the master switch in the stack. And if that master fails then some other switch in the stack will become the new master. And the new master should get the config that was being used and should get the IP address that was configured on VLAN 1.
If the switches operate as separate independent entities then each switch needs its own IP address. If the switches operate in a stack then there is a single logical entity and it needs only a single IP address.
That does help. I will remove the vlan ip address from all but one switch and shutdown the switches and then reboot them. The stack will recognize that one of its members has a vlan 1 ip address and the master (even if it is not the switch with the IP add) will take on that IP address as its management address.
to further comment on these posts, a switch getting elected as "master", doesn;t necessarily make that switch "switch 1" master election is determined by a number od different criteria upon startup. Any member can be elected the "master" of the stack. See here:
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...