Skip to main content

3750 Stackwise using mixed versions

I was unsure if it was possible to create a 3750 stack using a mixture of standard and enhanced licenses.  I was pretty sure they would join the stack but was unsure what features would work afterwards.  Would the entire stack gain routing functionality or would it be limited to just the EMI images?  Would the entire stack be forced to run as an SMI image?  These were the questions I needed answers to.  After much digging I came across a Cisco TAC article which answered all my questions.
* The IOS software version on all stack members, including the stack master, should be the same. This helps ensure full compatibility in the stack protocol version among the stack members. For example, all stack members should have either the EMI or SMI

* If your switch stack must have switches running SMI and EMI software,the switch running the EMI software should be the stack master. EMI features become unavailable to all stack members if the stack master is running the SMI software.

* At least two stack members should have the EMI software installed to ensure redundant support of the EMI features. The EMI has precedence over the SMI during stack master election, assuming that the priority value of the stack members are the same. If the EMI stack master fails,the other stack member running the EMI software becomes the stack master.

* When a switch running the EMI joins a switch stack running the SMI of the same version, the EMI switch does not automatically become the stack master. If you want the EMI switch to become the stack master, reset the current SMI stack master by using the reload slot stack-member-number privileged EXEC command. The EMI switch is elected the stack master, assuming its priority value is higher or the same as the other stack members.

However, there are some issues to consider when deploying such mixed stacks.

* If you have a stack of SMI switches, with a single EMI unit, the EMI unit will, by default, become the master switch. It will give EMI functionality to the entire stack. This is because Layer-3 functionality is centralized in nature, on the 3750. However, if the master switch were to fail, the entire stack would revert to the feature-set of the new master, who happens to be SMI. The user would lose all EMI-only functionality such as advanced IP routing protocols. This is the reason we include a recommendation that if users deploy a mixed stack, they should have at least two EMI units to provide protection against such failures.

* If the user does decide to use the unified upgrade feature to upgrade the stack, it will be a single upgrade. This means that the entire stack will get upgraded to the same image. The upgrade process will involve copying the same new image file to the flash of every switch in the stack. So, if the new image is an EMI image, all the EMI switches will get upgraded. The originally SMI switches will not get upgraded to EMI, in this scenario! They will give a "Version Mismatch" error and you will need to upgrade them separately, to an SMI image (or purchase an SMI-to-EMI upgrade license for those switches).

Comments

Popular posts from this blog

Error Message %DUAL-6-NBRINFO: EIGRP-IPv4 34256

If you see the error  %DUAL-6-NBRINFO: EIGRP-IPv4 xxxx  is blocked: not on common subnet then it simply means that there are EIGRP devices sending multicast hellos on an interface which have a different IP Range configured to the receiving router.  160617: .Feb 22 15:11:05.194 GMT: %DUAL-6-NBRINFO: EIGRP-IPv4 34256: Neighbor 17 2.31.253.1 (Vlan43) is blocked: not on common subnet                                                     (172.31.252.1/31) 160618: .Feb 22 15:11:12.770 GMT: %DUAL-6-NBRINFO: EIGRP-IPv4 34256: Neighbor 19 2.168.205.0 (Vlan44) is blocked: not on common subnet (192.168.204.1/31)                                                                                          This is most likely to occur by accident when two subnets are configured on the same VLAN, with EIGRP running on the interface.

Moving the SSH port on a CISCO router

If you admin your routers over the internet you probably know you should be using SSH. Telnet being sent in clear text is easily sniffed and your passwords captured. However Cisco routers use the standard TCP port 22 for their SSH service. As soon as you open this up to the world and turn on SSH access logging you will start to see hundreds of IP's connecting to your device and running dictionary attacks against you using standard username and password combinations. The majority of these IP's seem to originate from China or Russia and they find your open port extremely quickly. This is very anoying it fills up your log files with these attacks and uses up your system resources dealing with them. I believe they are simply running scans for any open TCP port 22. For this reason I decided I could cut down the amount of attacks by moving the SSH port to a different number. One thing you should know before we start is that there is no way to actually change the SSH port number o

Shutting Cisco 3750 Stackwise ports

Today I came across a customers 3750 switch stack which had a flapping stackwise link. The stackwise link was transitioning up/down around 3 times a second and causing massive issues with connectivity and EIGRP routing for the site. Previously I believed that I would need to physically remove the Stackwise cable in order to restore service by shutting the flapping link. It seems it is possible to shut the Stackwise port from the CLI although it is done from enable mode rather than Configure terminal. The command is.. Switch#switch 1 stack port 1 ? disable Disable stack port enable Enable stack port The first number 1 would indicate the switch number in the stack and the second number 1 after the port is the Stackwise port number you want to shut. Make a note of which switch and port you shut as it will not show up in the config or the show outputs which could prove tricky when you want to reenable it.. You can determine the status of the ports using the command below but not how