A new feature that comes along with the modular image is the inclusion of Cisco Embedded Event Manager (EEM).  This feature allows the EEM process to ‘catch’ a defined event and then spawn an action from that raised event.  For example, the device can generate and send an email when the CPU goes over a certain percentage for a period that is longer than a defined threshold.  The engine behind this functionality is controlled using the Python scripting language.  Using Python to write these embedded event handlers provides some powerful capabilities at your fingertips.

This article wasn’t really intended to help you decide on using the IOS modularity option, but to explain the upgrade/conversion process.  The first thing to do is obtain the proper image from CCO.  The modular version has the same feature sets and versions available just like the native IOS versions do.  Just pick the right modular image based on your hardware and services needed just like you would any other time.

Once you have downloaded the image, upload it to storage that is available on the (primary) supervisor.  Before the ‘installation’ of the modular IOS, the supervisor has to boot from it first, like it would any other image.  In fact, the switch can load the modular IOS .bin file and run just like it was the non-modular version.  However, this would defeat the purpose, since patching is not available until the installation has been performed and the system rebooted.

Put a boot statement in the configuration pointing it to the .bin file that was just uploaded to storage and reload the switch.  Once the switch is back up running on the new image here is where it starts to get fun…

Let’s look at the output of the show version command after the switch has booted the new IOS image:

6500switch#sh version
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-VM),
Version 12.2(33)SXH3a, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Wed 24-Sep-08 14:37 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

6500switch uptime is 14 hours, 53 minutes
Uptime for this control processor is 14 hours, 52 minutes
Time since 6500switch switched to active is 14 hours, 52 minutes
System returned to ROM by reload at 23:22:24 CDT Tue Oct 14 2008
 (SP by reload)
System image file is "disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin"

cisco WS-C6506-E (R7000) processor (revision 1.1) with
516096K/8192K bytes of memory.
SR71000 CPU at 600Mhz, Implementation 1284, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
52 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

Patching is not available since the system is not running from an
installed image. To install please use the "install file" command

Take a look at the last couple of lines of the output. This output is telling you to run the ‘install file’ command in order to install the image. The installation procedure creates a directory structure on the file system specified in the install command. In this example, the image is running from flash installed in slot0:, which is known to the switch as disk0:. We are going to install onto the sup-bootdisk0: flash, which is an compact flash module installed internally with a compact flash adapter that replaces the SP bootflash on the supervisor. Cisco recommends the modular installation use internal storage, because it is too easy to eject the flash from the slots on the front of the supervisor – which would cause the switch to crash.

The command to start the process will be: install file disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin sup-bootdisk0:/sys . The syntax is basically the source image to use then the destination. Notice the /sys at the end of the destination, which is a required argument and is called the search root. The search root is basically just a top level directory and valid entries are: sys|newsys|oldsys .  Below is a normal output during the installation:

6500switch#install file disk0:s72033-advipservicesk
9_wan-vz.122-33.SXH3a.bin sup-bootdisk:/sys
Source filename [s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin]?
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Verifying checksums of extracted files

Verifying installation compatibility

Finalizing installation ...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Computing and verifying file checksums
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Writing installation meta-data.  Please wait ...

NOTE: The newly added base image is not yet active.
      To activate the new base image, perform an 'install bind' in
      config mode followed by a 'reload'.

[DONE]

6500switch#

The last thing you see is a note on how to activate the new base image.  The correct command in this example is: 6509switch(config)#install bind sup-bootdisk:/sys .  Notice this command is done from configuration mode.  This command basically just adds a boot statement in the switch configuration pointing to the new modular image.  Here is the output from the install bind command:

6500switch(config)#install bind sup-bootdisk:/sys
WARNING: This system is running in a redundant mode.  However, the specified
search root on the Standby does not contain installed software, or is unavailable.
Unless the proper software is installed on the Standby,
it will not boot from this binding

The message we received above was due to the fact the example system was running dual supervisor modules.  If you have a single supervisor, this message will not display.  In order to get the installation onto the redundant supervisor, the process is a little simpler.  There is a copy command that will copy the existing installation on sup-bootflash0:/sys to the redundant supervisor’s file system.  The following is all that is required to insure the secondary supervisor can boot successfully:

6500switch#install copy sup-bootdisk:/sys slavesup-bootdisk:/sys
Copying installed software at sup-bootdisk:/sys to slavesup-bootdisk:/sys
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[DONE]

A look at the running configuration shows the following:

6500switch#show run

boot-start-marker
boot system flash disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin
boot system flash sup-bootdisk:
boot system sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm
boot-end-marker

As you can see, the install bind command will not remove any of the previous boot statements.  In all the upgrades I have performed so far, I have went ahead and removed all the old boot statements, just to make sure the supervisor boots correctly.

6500switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
6500switch(config)#no boot system flash disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin
6500switch(config)#no boot system flash sup-bootdisk:
6500switch(config)#end
6500switch#wr
Building configuration...
[OK]
6500switch#sh boot
BOOT variable = sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
CONFIG_FILE variable =
BOOTLDR variable =
Configuration register is 0x2102

Standby is up
Standby has 524288K/8192K bytes of memory.

Standby BOOT variable = sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
Standby CONFIG_FILE variable =
Standby BOOTLDR variable =
Standby Configuration register is 0x2102

The last thing to do is reload the switch:

6500switch#reload
Proceed with reload? [confirm]

Once the switch is back up, the output of show version now looks like:

6500switch# sh ver
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-VM),
 Version 12.2(33)SXH3a, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Wed 24-Sep-08 14:37 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

 6500switch uptime is 8 minutes
Uptime for this control processor is 7 minutes
Time since 6500switch switched to active is 7 minutes
System returned to ROM by reload at 15:07:48 CDT Wed Oct 15 2008 (SP by reload)
System image file is "sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm"

cisco WS-C6506-E (R7000) processor (revision 1.1) with 516096K/8192K bytes of memory.
SR71000 CPU at 600Mhz, Implementation 1284, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
52 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

System is currently running from installed software
For further information use "show install running"

To look at the actual software versions along with any patch information, issue the show install running command:

6500switch#show install running

B/P C State     Filename
--- - --------  --------

Software running on card installed at location s72033_rp - Slot 6 :
 B    Active    slavesup-bootdisk:/sys/s72033_rp/base/DRACO2_MP

Software running on card installed at location s72033 - Slot 5 :
 B    Active    sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm -
Version 12.2(33)SXH3a

Software running on card installed at location s72033_rp - Slot 5 :
 B    Active    sup-bootdisk:/sys/s72033_rp/base/DRACO2_MP

Software running on card installed at location c2_lc - Slot 1 :
 B    Active    sup-bootdisk:/sys/c2_lc/base/C2LC

Software running on card installed at location s72033 - Slot 6 :
 B    Active    slavesup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm -
Version 12.2(33)SXH3a

LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
   system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
   installation.  On reload, this file will not run and will move to
   PendInst state.  If 'install activate' is done before reload, pending
   removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
   If the card reloads, it will be active on the system pending a rollback
   If 'install activate' is done before a reload, the pending install and
   removal with cancel each other and the file will simply be removed
Occluded - This file has been occluded from the system,
   a newer version of itself has superceded it.

6500switch#

All things considered, this is a pretty easy upgrade – just take your time and make sure each step is followed carefully. I would recommend allocating 1.5 hours for the first upgrade performed. Once you’re familiar with the process, it can be done in half that time and even quicker if the image is transferred to a filesystem on the switch prior to performing the upgrade.

Before you configure STP, select a switch to be the root of the spanning tree. This switch does not need to be the most powerful switch, but choose the most centralized switch on the network. All data flow across the network is from the perspective of this switch. Switches in the distribution layer often serve as the spanning tree root because these switches typically do not connect to end stations. Also, moves and changes within the network are less likely to affect these switches.

Let’s consider the following network diagram:

Vlan3 is defined on the network with SW1configured as the root bridge.

SW1#show spanning-tree root
VLAN3
  Root ID    Priority    8192
             Address     cc00.0cf4.0002
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

The output of the previous show command reflects that it is the root bridge for Vlan3.  The mac-address shown is the address of the switch serving as the root bridge.  Using the mac address shown in the show spanning-tree root output, we can go searching for the root bridge of any vlan.

The priority was configured on SW1 in order for it to assume root bridge status for vlan 3.  The configuration command executed on SW1:

SW1(config)#spanning-tree vlan 3 priority 8192

SW2 is configured to assume the root bridge in the event SW1fails:

SW2(config)#spanning-tree vlan 3 priority 16384

Let’s say on SW3 we configure the following:

SW3(config)#spanning-tree vlan 3 priority 4096

Run the show spanning-tree root command again on SW1:

SW1#show spanning-tree root
VLAN3
  Root ID    Priority    4096
             Address     cc02.0cf4.0002
             Cost        12
             Port        321 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

The mac-address cc02.0cf4.0002 belongs to SW3, which has now become the root bridge for vlan3.  How do you prevent this from happening?

Using best practice configuration techniques, make sure SW3 and SW4 does not become the root bridge for any vlan.

SW3(config)#spanning-tree vlan 1-4094 priority 65535
SW4(config)#spanning-tree vlan 1-4094 priority 65535

Configure SW1 and SW2 as the primary and secondary root bridges for vlan 3

SW1(config)#spanning-tree vlan 3 priority 1
SW2(config)#spanning-tree vlan 3 priority 2

Remember to do this configuration for each vlan on the network, because in per vlan spanning-tree, there is a root bridge for each spanning-tree instance.

Consider the following illustration:

In the above illustration, switchA and switchB is considered the core/distribution switches in this small office scenario. Switch A & B have a Layer 2 connection between them for high speed switching in this collapsed core layer. Servers connect to both core/distribution switches with NIC teaming configured in the Operating System. The switches C & D serve as access switches in the wiring closets for office workstations. The access switches have dual uplinks, one to each core/distribution switch for redundancy.

There are 10 vlans configured in this example network, half of them are load balanced on one uplink connection and the other half of the vlans are forwarded on the second uplink connection. Each access switch uplink also serves as a backup to the other.

PVST – Per Vlan Spanning Tree – This is the original Cisco proprietary, per vlan spanning tree protocol. It maintains a spanning tree instance for each VLAN configured in the network.

Configuration Example:

switchA(config)# spanning-tree mode pvst
switchA(config)# spanning-tree vlan 1,2,3,4,5 root primary
switchA(config)# spanning-tree vlan 6,7,8,9,10 root secondary
switchA(config)# spanning-tree backbonefast

switchB(config)# spanning-tree mode pvst
switchB(config)# spanning-tree vlan 1,2,3,4,5 root secondary
switchB(config)# spanning-tree vlan 6,7,8,9,10 root primary
switchB(config)# spanning-tree backbonefast

switchC(config)# spanning-tree mode pvst
switchC(config)# spanning-tree uplinkfast

switchD(config)# spanning-tree mode pvst
switchD(config)# spanning-tree uplinkfast

PVST+ – Per Vlan Spanning Tree Plus – It can be thought of as PVST version 2, still Cisco proprietary, with enhancements added to the original version. The difference between the two protocols is PVST supports ISL as the trunking protocol, where PVST+ makes use of the 802.1Q trunking protocol.

RSTP – Rapid Spanning Tree Protocol – This is the standards based (802.1w) spanning tree protocol that is very similar to Cisco’s proprietary PVST+. Many of the previously Cisco proprietary methods of speeding up convergence, such as Portfast, Uplinkfast, Backbone now have standards based equivalents that are built into RSTP.

Configuration Example:

switchA(config)# spanning-tree mode rapid-pvst
switchA(config)# spanning-tree vlan 1,2,3,4,5 root primary
switchA(config)# spanning-tree vlan 6,7,8,9,10 root secondary

switchB(config)# spanning-tree mode rapid-pvst
switchB(config)# spanning-tree vlan 1,2,3,4,5 root secondary
switchB(config)# spanning-tree vlan 6,7,8,9,10 root primary

switchC(config)# spanning-tree mode rapid-pvst

switchD(config)# spanning-tree mode rapid-pvst

MST – Multiple Spanning Tree – It can be thought of as RSTP version 2. Known as 802.1s, this version of spanning tree takes 802.1w and builds on the standard. MISTP allows you to selectively map/group multiple vlans to a single instance of spanning tree.

For Example: There are 10 vlans defined in the network, instead of having 10 instances of spanning tree running (using PVST), you can shrink it down to say two instances of spanning tree running on a switch by mapping half the vlans to one instance and the other half to the second instance. The biggest advantage is the reduced resource footprint on the switch, requiring less memory and processor utilization for the spanning tree process.

Configuration Example:

switchA(config)# spanning-tree mst configuration
switchA(config-mst)# name corpbuilding
switchA(config-mst)# revision 1
switchA(config-mst)# instance 1 vlan 1 - 5
switchA(config-mst)# instance 2 vlan 6 - 10
switchA(config-mst)# exit
switchA(config)# spanning-tree mst 1 root primary
switchA(config)# spanning-tree mst 2 root secondary
switchA(config)# spanning-tree mode mst

switchB(config)# spanning-tree mst configuration
switchB(config-mst)# name corpbuilding
switchB(config-mst)# revision 1
switchB(config-mst)# instance 1 vlan 1 - 5
switchB(config-mst)# instance 2 vlan 6 - 10
switchB(config-mst)# exit
switchB(config)# spanning-tree mst 1 root secondary
switchB(config)# spanning-tree mst 2 root primary
switchB(config)# spanning-tree mode mst

After some investigation, the traffic type in question is discovered to be multicast. Some run from this problem like the plaque, others will tell the installer of the new product they are out of luck, because multicast traffic is ‘not supported’. More commonly ‘bandaids’ are put in place to make the product work. The types of fixes implemented could be something like putting all the multicast ‘talkers’ on the same physical switch. Other accommodating changes could be more drastic, such as disabling important features that are enabled on catalyst switches by default.

Now that the picture has been painted, a little explanation:

IGMP is a protocol used by clients wanting to receive a multicast stream. The client sends an IGMP report message to a multicast router telling or confirming that it wants to receive a particular stream. An IGMP query message is used by the multicast router to ask clients if they want to receive a multicast stream. If there is not a client requesting or confirming it wants to receive a stream, the router will not forward the traffic, because it is not needed.

Catalyst switches have a feature called IGMP snooping. Basically the switch transparently listens for these IGMP query/report messages described above. If it does not detect any multicast traffic being requested, it shuts off any traffic from the stream to that switchport. This optimizes the traffic flow even more, since it operates at a switchport level. The reason why igmp snooping often causes issues is when there is no multicast router in place. In many cases there is good reason for this, if multicast across a routed network is not desired, there is no good reason to turn on multicast routing.

However, the problem comes in when snooping blocks a multicast stream on the uplink port (where it normally would receive IGMP query messages from the multicast router). This happens because the switch never sees any IGMP traffic on those ports, therefore it shuts down traffic on them. Therefore the IGMP request messages from the client are never received on a different switch that is connected to the multicast sender.

Many times after researching a similar problem, the resolution will be from the product vendor to disable IGMP snooping with the command ‘no igmp snooping’. If you disable IGMP snooping, all switches treat multicast traffic as broadcast traffic. This floods the traffic to all the ports in that VLAN, regardless of whether the ports have interested receivers for that multicast stream. Obviously, this is not the type of behavior desired in any network – let’s fix the issue properly so snooping can be left enabled.

Solution

Manually configure an mrouter port on each access switch, in the absence of a multicast router on the network. The assigned mrouter port should be the uplink port that connects the access switch to the distribution layer. The access switch will always forward IGMP messages on the mrouter port. Do not configure an mrouter port on the distribution switch. In this scenerio, when the client connected to an access switch requests a multicast stream the IGMP message will be forwarded out the uplink port to the distribution switch. When the distribution detects the IGMP messages from an access switch, it will put the uplink port in it’s IGMP snooping table, thus allowing multicast traffic on the port.

To manually configure an access switch with an mrouter port:

accessSwitch(config)#ip igmp snooping vlan 10 mrouter interface Gig 1/0/49

The previous example assumes all the hosts using multicast is on vlan10 and the access switch uplink port is Gigabit 1/0/49.

Now, when the security guys call and say their new Checkpoint firewalls running on that shiney new Nokia cluster doesn’t work – go armed with the fix. Many high availability/clustering applications use multicast for the heartbeat traffic, the Microsoft clustering built into Windows also uses it.

First, if we access the switch stack and issue a dir all-filesystems it will return something like:

Directory of flash:/

    2  -rwx         936   Jul 9 2007 14:40:47 -05:00  vlan.dat
    3  -rwx        1941   Jul 9 2007 14:49:22 -05:00  private-config.text
    5  -rwx       10144   Jul 9 2007 14:49:22 -05:00  config.text
    6  drwx         192   Mar 6 1993 16:38:47 -06:00  c3750-ipbasek9-mz.122-35.SE2

15998976 bytes total (5792256 bytes free)
Directory of system:/

    3  dr-x           0                    <no date>  memory
    1  -rw-       10144                    <no date>  running-config
    2  dr-x           0                    <no date>  vfiles

No space information available
Directory of nvram:/

  499  -rw-       10144                    <no date>  startup-config
  500  ----        1941                    <no date>  private-config

524288 bytes total (512151 bytes free)
Directory of flash2:/

    2  -rwx         936   Jul 9 2007 14:40:51 -05:00  vlan.dat
    3  -rwx       10144   Jul 9 2007 14:49:22 -05:00  config.text
    4  -rwx        1941   Jul 9 2007 14:49:22 -05:00  private-config.text
    6  drwx         192   Mar 6 1993 16:42:54 -06:00  c3750-ipbasek9-mz.122-35.SE2

15998976 bytes total (5792256 bytes free)

Notice in the above output that there is a flash: and a flash2. Flash would belong to switch 1 (master) and flash2: would be the internal flash belonging to switch 2 in the stack. Also notice that the images are underneath the directory name that matches the image file name. This is something that I am not very fond of. I like the image to be in the root of the flash, instead of buried in a directory. Cisco starting doing this when the switches first provided an HTML interface. So, all the files needed for the built-in web server would also be under this directory structure. Since I do not use the web interface to configure access switches, nor do I desire for them to have that ability – we will delete the directory structure and replace with a single image file.

switch#del /force /recursive flash:c3750-ipbasek9-mz.122-35.SE2
switch#del /force /recursive flash2:c3750-ipbasek9-mz.122-35.SE2

Let’s take another look at the storage on both switches:

switch#dir all-filesystems
Directory of flash:/

    2  -rwx         936   Jul 9 2007 14:40:47 -05:00  vlan.dat
    3  -rwx        1941   Jul 9 2007 14:49:22 -05:00  private-config.text
    5  -rwx       10144   Jul 9 2007 14:49:22 -05:00  config.text

15998976 bytes total (15984640 bytes free)
Directory of system:/

    3  dr-x           0                    <no date>  memory
    1  -rw-       10144                    <no date>  running-config
    2  dr-x           0                    <no date>  vfiles

No space information available
Directory of nvram:/

  499  -rw-       10144                    <no date>  startup-config
  500  ----        1941                    <no date>  private-config

524288 bytes total (512151 bytes free)
Directory of flash2:/

    2  -rwx         936   Jul 9 2007 14:40:51 -05:00  vlan.dat
    3  -rwx       10144   Jul 9 2007 14:49:22 -05:00  config.text
    4  -rwx        1941   Jul 9 2007 14:49:22 -05:00  private-config.text

15998976 bytes total (15984640 bytes free)
switch#

Now that there is room for the image, transfer the new IOS to the first switch:

switch#copy tftp flash:
Address or name of remote host [10.1.2.21]?
Source filename [c3750-ipbasek9-mz.122-37.SE.bin]?
Destination filename [c3750-ipbasek9-mz.122-37.SE.bin]?
Accessing tftp://10.1.2.21/c3750-ipbasek9-mz.122-37.SE.bin...
Loading c3750-ipbasek9-mz.122-37.SE.bin from 10.1.2.21 (via Vlan2): !!!!!!!!!!!![OK - 8199380 bytes]
8199380 bytes copied in 138.210 secs (59326 bytes/sec)
switch#

Next, copy the image from switch1 to switch 2 using the copy command:

switch#copy flash:c3750-ipbasek9-mz.122-37.SE.bin flash2:c3750-ipbasek9-mz.122-37.SE.bin

The switch settings can be viewed by running the show boot command:

switch#sh boot
BOOT path-list      : flash:c3750-ipbasek9-mz.122-35.SE2/c3750-ipbasek9-mz.122-35.SE2.bin
Config file         : flash:/config.text
Private Config file : flash:/private-config.text
Enable Break        : no
Manual Boot         : no
HELPER path-list    :
Auto upgrade        : yes
Auto upgrade path   :
-------------------
Switch 2
-------------------
BOOT path-list      : flash:c3750-ipbasek9-mz.122-35.SE2/c3750-ipbasek9-mz.122-35.SE2.bin
Config file         : flash:/config.text
Private Config file : flash:/private-config.text
Enable Break        : no
Manual Boot         : no
HELPER path-list    :

Auto upgrade        : no
Auto upgrade path   :
switch#

As you can see from the output above, the switches are still set to look for the old filename at startup. Set the new boot statement in all of the switch stack members at one time by using the following command:

switch(config)#boot system switch all flash:c3750-ipbasek9-mz.122-37.SE.bin

Once the boot command is set, let’s look at the boot variables once more:

switch#sh boot
BOOT path-list      : flash:c3750-ipbasek9-mz.122-37.SE.bin
Config file         : flash:/config.text
Private Config file : flash:/private-config.text
Enable Break        : no
Manual Boot         : no
HELPER path-list    :
Auto upgrade        : yes
Auto upgrade path   :
-------------------
Switch 2
-------------------
BOOT path-list      : flash:c3750-ipbasek9-mz.122-37.SE.bin
Config file         : flash:/config.text
Private Config file : flash:/private-config.text
Enable Break        : no
Manual Boot         : no
HELPER path-list    :

Auto upgrade        : no
Auto upgrade path   :
switch#

You will notice that both switches show they are booting from flash: as apposed to switch 2 showing flash2. This is because flash: is what the storage is known as to each access switch, so consider this normal.

The only thing left is to copy the running configuration to startup and reboot the switch.

If the mac-address of a the device is known, then skip this first step of determining the mac-address from the IP address.

From the layer 3 device directly connected to the subnet containing the device to be found, ping the IP address of the host. From a cisco device the process will look like the following:

bna-lan-01#ping 10.120.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.120.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

It’s always a good idea to ping the device first. Otherwise, if there has been no recent communication to/from the device trying to be located, it will not appear in the arp table. Therefore, ping the device to ensure the mac address will be in the arp table. To locate the device, issue a show arp command with a pipe that includes the IP address of the host.

bna-lan-01#sh arp | inc 10.120.2.100
Internet  10.120.2.100            0   000d.23e4.1f20  ARPA   Vlan2
bna-lan-01#

The output of the show arp command will include the mac address along with what vlan the device resides in.. Now that the mac address of the host has been obtained, next issue the show mac-address command on the switch at the core of your network: In this example, the layer 3 device and the core switch is the same Cisco 6500 switch, with the name bna-lan-01.

bna-lan-01#sh mac-address-table address 000d.23e4.1f20
Legend: * - primary entry
        age - seconds since last seen
        n/a - not available

  vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
Supervisor:
*  2     000d.23e4.1f20  dynamic  Yes      80               Gi1/8

After issuing the show mac-address command, we see that the mac address was learned via Gigabit 1/8. From here, let’s assume the network is an all Cisco network and CDP is still running on the uplink ports. The next bit of information needed is what is connected on the other end of Gig1/8. Let’s do a show cdp nei to obtain that information:

bna-lan-01#sh cdp nei detail Gi1/8
-------------------------
Device ID: bna-asw-01
Entry address(es):
  IP address: 10.1.0.21
Platform: cisco WS-C3750-48TS,  Capabilities: Router Switch IGMP
Interface: GigabitEthernet1/8,  Port ID (outgoing port): GigabitEthernet1/0/49
Holdtime : 124 sec

Version :
Cisco Internetwork Operating System Software
IOS (tm) C3750 Software (C3750-I9-M), Version 12.1(19)EA1d, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 05-Apr-04 22:40 by antonino

advertisement version: 2
Protocol Hello:  OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=0FF0000
VTP Management Domain: 'BNA-NET'
Native VLAN: 257
Duplex: full

The downstream access switch is a 3750 with a management IP address of 10.1.0.21. The next step is to access this switch and issue the show mac address command on it.

bna-asw-01#sh mac-address-table address 000d.23e4.1f20
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 2      000d.23e4.1f20    DYNAMIC     Gi1/0/4

The output shows the host connected to the port Gigabit 1/0/4. If there had been another switch in between bna-asw-01 and the host, we would just do the same thing as previously – which is issue the show cdp neighbor command and find the management IP of the next access switch.

Let’s start with an example macro for the configuration of workstation connected switch ports. This particular macro is called workstation and contains the commands you would typically use on the interface configuration for connecting standard PC’s. The macro can also contain comments, which are defined with the pound sign. Any line starting with # will simply be ignored by the macro, however they can be of big help when reviewing the contents of the macro to understand what each command is intended for. Also, you will notice that the first two lines after the macro name are comments that tells what to use this macro for and how to run it on a switch port

@
macro name workstation
# Configure port for standard workstation connectivity
# Usage: macro apply workstation $vlan "vlan number"
description Accounting Department PC
switchport access vlan $vlan
switchport mode access
# Configure portfast
spanning-tree portfast
# Speed and Duplex
speed auto
duplex auto
# Turn off CDP on user port
no cdp enable
# In case the port is disabled
no shutdown
# Remove the reference to the macro that was ran on this interface
no macro description
@

Let’s say we want to configure a switch port for connecting to a workstation and it will reside in vlan 10. To apply the previous macro, you would do the following:

switch(config)#interface Gig1/0/1
switch(config-if)#macro apply workstation 10

It’s always best practice to have all non-connected ports in a shutdown state. The following macro will reset an interface back to a default state and disable the port.

@
macro name portniu
# Unassign a switch port
# Usage: macro apply portniu
shutdown
description NIU
no switchport
switchport
no spanning-tree portfast
speed auto
duplex auto
no macro description
@

When creating your own macros, keep in mind the following guidelines:

• When creating a macro, all CLI commands should be in the same configuration mode.
• When a macro is applied globally to a switch or to a switch interface, all existing configuration on the interface is retained. This is helpful when applying an incremental configuration.
• If you modify a macro definition by adding or deleting commands, the changes are not reflected on the interface where the macro was originally applied. You need to reapply the updated macro on the interface to apply the new or changed commands.

The switches that support macros also have a few already built in, which may do everything you need. The six default macros are:

cisco-global
cisco-desktop
cisco-phone
cisco-switch
cisco-router
cisco-wireless

The default macros will not show up in the running configuration. However, any custom macros that are created will show up near the top of the switch’s running configuration. To view the contents of each default macro, use the following command:

switch#show parser macro

Macros are a huge time saver, consider using them in your next deployment.

The stack master is the single point of stack-wide management. From the stack master, you configure:

- System-level (global) features that apply to all stack members
- Interface-level features for each stack member

All stack members are eligible stack masters. If the stack master becomes unavailable, the remaining stack members participate in electing a new stack master from among themselves. A set of factors determine which switch is elected the stack master. One of the factors is the stack member priority value. The switch with the highest priority value becomes the stack master.

A higher priority value for a stack member increases its likelihood to be elected stack master and to retain its stack member number. The priority value can be 1 to 15. The default priority value is 1.

The stack master contains the saved and running configuration files for the switch stack. The configuration files include the system-level settings for the switch stack and the interface-level settings for each stack member. Each stack member has a current copy of these files for back-up purposes.

You manage the switch stack through a single IP address. The IP address is a system-level setting and is not specific to the stack master or to any other stack member. You can manage the stack through the same IP address even if you remove the stack master or any other stack member from the stack.

A switch stack has up to nine stack members connected through their StackWise ports. A switch stack always has one stack master.

Command Usage Notes:

You can display the stack member number by using the user EXEC command:

Switch#show switch

You can manually change the stack member number by using the global configuration command:

Switch(Config)#switch (current-stack-member-number) renumber (new-stack-member-number)

The new number goes into effect after that stack member resets.

A single switch can be reset in the stack by using the privileged EXEC command:

Switch#reload slot (stack-member-number)

You can change the priority value for a stack member by using the global configuration command:

Switch(Config)#switch (stack-member-number) priority (new-priority-value)

To manually upgrade a stack member using the IOS from another stack member:

Switch#archive copy-sw /destination-system (destination-stack-member-number)
/force-reload (source-stack-member-number)

To run a command (such as show version) on a single switch in the stack:

remote command (stack-member-number) show version

Valid values for stack-member-number are 1-9

Goal:

Workstations configured for vlan 10 and Servers configured for vlan 11 are connected to a Cisco Switch. Another switch has to be added for capacity reasons, however it is a 3com. Additional Workstations and Servers need to be connected to the new 3com switch, using the same vlan separation configured on the Cisco access switch. The workstations in vlan 10 must communicate to each other across both switches. The Servers must also communicate across switches, which are in vlan 11.

In this example:

• The Cisco switch is connected to the 3com switch using port 1 on each side.
• Create two vlans locally on each switch
  • Vlan 10 (for Workstations)
  • Vlan 11 (for Servers)
• Configure port 1 on each switch for 802.1q trunking

Cisco switch configuration:

vlan 10
 name Workstations
vlan 11
 name Servers

interface FastEthernet0/1
description Connected to 3com switch
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/2
description Workstation
switchport access vlan 10

interface FastEthernet0/3
description Server
switchport access vlan 11

3com SuperStack III configuration steps:

Select menu option (bridge/vlan): create
Select VLAN ID (2-4094)[3]: 10
Enter VLAN Name [VLAN 10]: Workstations

Select menu option (bridge/vlan): create
Select VLAN ID (2-4094)[3]: 11
Enter VLAN Name [VLAN 11]: Servers

Select menu option (bridge/vlan/modify): add
Select VLAN ID (1-2,116,120)[1]: 10
Select bridge ports (AL1-AL4,unit:port...,?): 1:2
Enter tag type (untagged, tagged): untagged

Select menu option (bridge/vlan/modify): add
Select VLAN ID (1-2,116,120)[1]: 11
Select bridge ports (AL1-AL4,unit:port...,?): 1:3
Enter tag type (untagged, tagged): untagged

Select menu option (bridge/vlan/modify): add
Select VLAN ID (1-2,116,120)[1]: 10-11
Select bridge ports (AL1-AL4,unit:port...,?): 1:1
Enter tag type (untagged,tagged): tagged

1. Running switch management traffic over Vlan1. This is when an IP address is configured on Vlan1 in order to access the switch for management purposes. Every access switch comes with vlan1 in the default configuration, which makes it very easy to configure an IP address on it, in order to telnet to the switch for management.
2. Running user traffic over Vlan1. This happens typically in smaller networks where a switch is installed and the default port setup is used. The default configuration for all access switch ports is to run user traffic in this vlan.
3. Running native vlan traffic on trunk ports over vlan1, please see this remedy for that issue.

All three of these issues largely exist because of the default IOS configurations that Cisco defines for the switch. The defaults are designed for small networks and/or junior administrators so that they can get switches up and on the network quickly and easily. You are expected by Cisco to know when to change the defaults, however this commonly does not what happen, even in larger scale implementations.

This article will only focus on abuse number 1. There are other solutions to numbers 2 and 3, which is talked about separately.

Now, to be fair, back in the ‘early’ days, the ‘Management Vlan’, as it’s commonly referred as, couldn’t be changed. So if you were going to manage a switch over the network, the IP address had to be configured on Vlan1. This has long been remedied and really leaves little to no excuse for still using it.

Before showing how to change this, here are just a few facts about what vlan1 is used for that can’t be changed (thus the reason to leave it only to do these things).

• Cisco Discovery Protocol (CDP)
• Vlan Trunking Protocol (VTP)
• Port Aggregation Protocol (PAgP)
• Dynamic Trunking Protocol.(DTP)

In order to change the management vlan, you must first decide on a (preferably dedicated) vlan number to use. Once this is decided, connect to the conolse port of the switch and perform the following configuration:

Switch#config t
Switch(Config)#interface Vlan1
Switch(Config)#no ip address
Switch(Config)#shutdown
Switch(Config)#interface VlanX
Switch(Config)#ip address x.x.x.x y.y.y.y
Switch(Config)#no shut

After performing this configuration, you will be able to access the switch from the new vlan. As for access to this vlan, you must either have the host you are accessing from in the same vlan as the management, or have some type of layer3 interface in the management vlan. The benefits to having a layer3 interface in the management vlan allows you to use a firewall or an access list on a router interface to limit access to the devices.