|
|
2.1(1) Software Release Note
The 2.1(1) software release supports the existing Catalyst 3000 series and CPW1601, and introduces and supports the following features:
 | Caution If you are upgrading an existing system which is running a pre-2.0 software release, you MUST upgrade the bootcode first. If you do not, the system will not boot when restarted. |
CPW 16 and Catalyst 3x00 series switches must have 8 Megabytes of RAM in order to run software release 2.1(1).
The following is a list of certain system configuration limitations when using 2.1(1) software.
Currently, there is no support for the LES, BUS and LECS MIBs in software release 2.1(1). CiscoWorks version 1.2 does offer support for the majority of the features in this release. Support for these MIBs will occur in a future maintanence release of software.
The following are known conditions in this version of the software release. It is not known at this time whether these conditions will be fixed in the next release of software.
Remote Console Restriction For Router Configuration Screen (CSCdi70791)
In stack configurations composed of a mix of Catalyst 3000 and 3200 switches, Some of the configuration parameters for an installed router card may not be modifiable from a remote console port in the stack. The work around for this problem is to use a local console connection when it necessary to modify the configuration of a router card.
Detection of Error During Boot Process (CSCdi66888)
In rare circumstances, the system may detect an error during the boot process. The system will switch to VTP transparent mode and reboot in this mode to preserve known VLAN information.
WS-X3002 Module Diagnostic LED Turned Off (CSCdi73577)
The diagnostic LED on the WS-X3002 four port 10BaseT module is turned off before the system powerup diagnostic test for this module is actually ran. This is cosmetic in nature and does not affect the effectivity of the diagnostic test.
LECS Timeout Warning Message (CSCdi80313)
The message "LECS warning: interface KAS ATM Interface( x ):ILMI timeout getting LECS addresses" may be generated several times under certain conditions on the console of a Catalyst 3x00 switch configured as a LECS. This message is cosmetic and does not indicate any sort of functional problem with the LECS or any other component of your ATM network.
Using Escape Key To Clear Console Message May Cancell Download (CSCdi80377)
If a console informational warning message appears while a TFTP download is in progress, pressing the escape key several times to clear the console warning may result in the cancellation of the TFTP download also. If a informational warning message does appear while a TFTP download is in progress, wait until you are sure the download is complete before pressing escape to clear the message. If you are not sure whether the download is complete, Wait 10 minutes or so to allow ample time for the download to complete before pressing escape to clear the message.
Port Statistics Menu Overwriting Other Screens (CSCdi71685)
After exiting the Port Statistics menu, the screen may still refresh itself when the switch is under heavy traffic. To solve this problem, re-enter the menu and exit it again.
Learn And Lock Addresses And Their Deletion From Address Tables (CSCdi76624)
With the Learn And Lock feature, if an address is learned for a specific port, moving this address to another port would result in a communications failure. Learn And Lock does not allow an address to be moved from one port to another without clearing the address from the previous port (see the Learn and Lock section in the software release 2.1 customer documentation for more info).
SNMP Queries of VLAN Statistics (CSCdi
VLAN Statistics have not been implemented. SNMP queries on VLAN Statistics will return zero.
If you are concerned with preserving your existing VLAN/Domain configuration in a VTP environment, review the section "Preserving a VTP Configuration" at the end of this document.
If you download the 2.1(1) image to an existing system without first upgrading the bootcode, the system will fail to boot when you reset the box. All new boxes shipping with 2.1(1) will have the new bootcode; the problem applies only to boxes being upgraded in the field.
To avoid the problem, the bootcode on existing boxes must be upgraded before upgrading the main image to 2.1(1).
There is a hidden option in the tftp download menu which allows tftp download of the bootcode. This feature was added in the 1.1.3 and 9.1 versions; it is NOT in the 9.0 version of the code. If you are running something earlier than 9.1 or 1.1.3, this technique will not work. Upgrade to one of those versions first.
Make sure you have the following files from CCO or from the upgrade 3.5 disk:
| UNIX | DOS |
|---|---|
| c3000-main-2_1_1.gz | C3K_211.GZ |
| c3000-boot-2_1_1.ima | C3K_BOOT.IMA |
| c3000-mib-2_1_1.mib | C3K_211.MIB |
| c3000-schema-2_1_1.schema | C3K_211.SCH |
| c3000-readme-2_1_1.txt | README.TXT |
Use the following steps to upgrade the bootcode:
Step 1 Enter the Download/Upload menu
Step 2 Enter the TFTP Download/Upload... menu
Step 3 Enter your TFTP Server Address, Download VLAN
Step 4 Enter the Main Image Download... menu
Step 5 Download the image. If in a Stack , select "Execute Main Image Stack Network Download"
You can now use the same menu to download the 2.1(1) main image in the normal way. Reset the box after both images are downloaded and the system will come up running 2.1(1).
If you loaded the new 2.1(1) image without the new boot image and reboot the system, then the boot process will fail and you will need to do a serial download of the new bootcode to recover. Serial download is a slow process, but it is the only option available in this case. The following are screen captures of the boot process and the necessary information on how to load the new boot image after the system has been restarted.
Cisco Catalyst Boot Firmware P/N 57-1327-02, Copyright 1995
- Initiating bootstrapping sequence.
- Boot image integrity check...Passed.
- Control transferred to boot process.
- Relocating main image to DRAM.................
Select option 1 from the menu display. The following message will be displayed:
SysReq: Beginning Xmodem download of boot image.
SysReq: Waiting for binary file...
Once this is displayed, follow the directions below based on the type of computer you are initiating the serial download from:
~c (tilde and lowercase 'c')
This will give you a [cd] prompt. Enter the proper path to the directory containg the boot image. press carriage return.
SysReq: Waiting for binary file...
~C (tilde and uppercase 'C')
The foillowing string should appear on the screen:
~CLocal command?
sx C3KBOOT.IMA (or the proper name of the boot image)
The system will download the specified image and will reboot automatically when finished.
Once the download of the boot image is complete, the system will reboot automatically with the new bootcode.
Once the Download of the boot image is complete and the system has rebooted, the following information should be seen on the screen:
Cisco Catalyst Boot Firmware P/N 57-1327-02, Copyright 1995
- Initiating bootstrapping sequence.
- Boot image integrity check...Passed.
- Control transferred to boot process.
Boot Firmware (Phase II) v2.1(1)
- Relocating main image to DRAM..................Done.
- Main image integrity check...succeeded.
- Control transferred to main process.
System Software Version 2.1(1) (1), Copyright 1994-1996.
System started on Xxx. Xxx x, xxxx xx:xx:xx
8 Megabytes System memory
2 Megabytes Network memory
- Initialization started
- File system initialized
- System temperature is within safe operating levels
- Checking file system integrity
- Warmboot initialization started
- LAN ports detected:
- 10Base-T: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
- StkPort : 25
- CPU Network memory test...
- CPU Network memory test...Passed
- Initializing Ports: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 25
- Initializing system address table
- System entering stand-alone mode
- System initialization complete
- Starting SNMPv1 agent task
- Enabling port: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 25
Press RETURN key to activate console...
The new bootcode will support all previous versions of the main image, including 9.0, 9.1, 1.1.3, and 1.3. It is recommended that you upgrade the bootcode on all the systems, even if you are not planning to upgrade them to 2.1(1) immediately, since the problem with the existing version of the bootcode will continue to occur with all future releases (2.1(1), 2.2, etc.).
The following sections explain how to preserve an existing VTP/VLAN configuration.
As dictated by the VTP specification, the configuration of ports onto old EtherSwitch domains is now constrained by VTP as long the switch is participating in VTP (that is, as long as it isn't in VTP Transparent mode). This means that a local port cannot be assigned to any VLAN which is not configured via VTP. Thus, what used to be called Domain Port Configuration is now essentially VTP VLAN Configuration and the selections available to the user now consist of those defined in VTP rather than the switch's constant 64 choices. When a VTP VLAN is deleted and removed from the database for the administrative domain, all local ports assigned to it automatically become unassigned. An unassigned port does not belong to any VLAN and does not forward packets.
Besides local ports, IP, SNMP, Spanning Tree, and TFTP choices which were previously dependent upon the old domain context are now dependent on the VTP VLAN context. For instance, an IP address configured for the switch is now defined in a VTP VLAN and only applies to IP packets received on that VLAN, whether over a trunk or a local port. When a VTP VLAN is deleted all such parameters are permanently lost. If you don't want to lose the old parameters, you have the option of using the following procedures to reconfigure your switch after you download the 2.1(1) switch Software Release
In the 2.1(1) Release, the VTP and VLAN configuration replaces the current domain configuration. After the switch software reads the pre-2.1(0) configuration database, the 2.1(1) release code then modifies it to create a valid 2.1(1) configuration database. The result of this is a new VTP database which will be the one implemented locally after the initialization is complete.
This database places the local Stack in VTP Transparent mode in order to give you the opportunity to complete the necessary manual steps of the upgrade procedure. In Transparent mode, all VTP configuration propagation packets are transparently forwarded to other trunks and are not used for local configuration. Until the Stack leaves Transparent Mode, all VLAN configuration is entirely under local control.
The initial VTP database will contain 68 VLANs: 64 Ethernet VLANs which are created to represent the 64 pre-2.1(1) Virtual EtherSwitches (what were formerly called Domains in some places) and the four VTP-mandatory non-Ethernet default VLANs which exist in all VTP databases.
The first of the 64 Ethernet VLANs corresponds to the VTP-mandatory default Ethernet VLAN and also to the pre-2.1(1) default Virtual EtherSwitch. The names of the other Ethernet VTP VLANs should correspond to the names of the Virtual EtherSwitches they replaced. Ports should be assigned to VLANs corresponding to the Virtual EtherSwitch to which they had previously been assigned.
IP, Spanning Tree, SNMP, and TFTP configuration parameters which had previously specified a Virtual EtherSwitch(es) now specify the corresponding VLAN(s)
In order to integrate into a VTP-controlled VLAN database environment, it is necessary to leave Transparent Mode and allow the global VTP database to overwrite the local one.
Before you do this, it is important to understand the consequences of this so you can take the necessary steps to prepare the local configuration.
When a device receives a new VTP database which supersedes its existing one, it implements the new database locally as appropriate. If new VLANs (as identified by their VLAN id number) are defined in the new database, then they are created locally. This allows the assignment of local ports to these new VLANs.
Regardless of whether the local device has begun running VTP or not, the trunk mapping of VLANs will occur as specified in the VTP database using VLAN id for ISL trunks and VLAN name for LANE trunks. Whether or not this mapping is appropriate for your configuration depends on which ports on a local Stack need to be members of the same VLAN (with other local assigned ports that exist on remote devices across the trunk and beyond).
To insure that the local VLAN port and parameter assignments resolve correctly and do not get deleted (once they are controlled by VTP):
For example, after the upgrade procedure, Virtual EtherSwitch 5, named Engineering, with five ports and an IP address of 192.5.5.5, will be changed to VLAN Engineering VTP id number 5 with the same port/IP assignments.
If you need to move VLAN Engineering from VTP id number 5 to another global VLAN with different VTP id number, follow the instructions in the Moving Local VLAN Assignments section.
If, in the example in the previous section, the user determines that the ports and address in local VLAN 5 need to be assigned to global VLAN 281 (because this will allow desired connectivity to other ports in global VLAN 281) the VLAN will need to be moved.
First of all, VLAN 281 needs to exist in order to move ports and parameters there. (The VLANs corresponding to the pre-2.1(1) database created are assigned id numbers 1 through 64 and the mandatory non-ethernet default VLANs are assigned id numbers 1002 through 1005.)
Step 1 The VLAN 281 must be created using the VTP VLAN Configuration Sub-menu (under the VLAN and VTP Configuration Menu.) If integration into the global database is imminent, there is no need to be concerned with most of the VTP parameters assigned to VLAN 281 in the local database since these will ultimately be overwritten by the global database. However, since there is a limit of 68 VLANs on a local device, one of the existing VLANs will need to be deleted to make room for VLAN 281. Use the delete function in this menu to remove a VLAN that is not needed.
Step 2 Add VLAN 281 using the Add function in the VTP VLAN Configuration menu. The parameters that need to be configured are:
The last two values will default as desired (Ethernet type/1500 MTU) when using this function in the VTP VLAN Parameter Configuration Menu. (As covered in a later section, the new VLAN need not and probably should not be made Preferred in the Local Preferred VLANs Configuration menu.)
Step 3 Once VLAN 281 is created, ports and local parameters may be moved from VLAN 5 to VLAN 281. To move a local VLAN in a single step, use the Reassign Ports in Local VLAN sub-menu under the VLAN and VTP Configuration menu.
Step 4 The Reassign Ports in Local VLAN menu has four selectable items:
Step 5 In this example, the source VLAN would be VLAN 5 and the destination VLAN would be VLAN 281. Select the Execute Reassignment function to complete the move. Check that all local static ports and parameters have been moved from VLAN 5 to VLAN 281.
After all local VLAN moves have been executed and the local VLAN configuration appears correct, integrate this information into the global VTP environment. This procedure must be performed carefully since it may have a drastic effect on local configuration. Use the following steps for this procedure:
Step 1 Do a TFTP save of the configuration database. To do this, go to the Downloads/Upload menu and the TFTP Download/Upload sub-menu.
Step 2 To allow access to the system from the outside, go to the VTP Administrative Configuration menu.
Step 3 Set the Local Mode parameter to either Server or Client mode. If the global VTP database contains no secret value (password) and assuming the local environment has only one VTP administrative domain, this is the only necessary procedure you need to do. However, if you have set a secret value, it also will need to be set in the VTP Administrative Configuration menu
The local device learns the administrative domain name from the first peer to subsequently advertise it to the rest.
Step 4 If necessary, the local mode may be reset to Transparent mode and the configuration uploaded back into the device. Do not simply reload the configuration database without resetting the local VTP mode.
Step 5 After a period of time (normally not exceeding five minutes), the global VTP configuration should be received over the default Ethernet VLAN of any ISL or LANE trunk from a VTP peer (not itself in Transparent mode).
Step 6 The local VTP configuration should now be identical to the global one. If the VLAN moves have been done correctly all the ports and parameters should be assigned as desired and connected to ports in remote devices on their corresponding VLANs.
A preferred VLAN is a VLAN that contains configuration parameters such as IP/port assignments. A non-preferred VLAN does not have any local configuration parameters.
The source of a local VLAN move must be a preferred VLAN. This is because only preferred VLANs contain local port and (non-default) parameter assignments.
It is preferable to have the destination of a VLAN move be a non-preferred VLAN with no locally configured parameters.
However, if the destination VLAN of the move has configured values, you can perform one of the following actions:
A further selection on the VLAN and VTP Configuration menu will allow you to choose which of the two VLAN's local IP and Spanning Tree parameters are kept (assigned to the destination VLAN) and which are discarded.
This display is used to move a fully configured Stack into a pre-existing VTP administrative domain.
The following database (Table 1) assumes you would like to integrate the ports on the VLANs named local-(appropriate name) on the Stack being upgraded to 2.1(1), using VTP, into the corresponding global VLANs name global-(appropriate name). For instance, it is desired that ports 2, 4, and 8 (which originally belonged to local-W on the local Stack will ultimately become members of the VLAN named global-W.
| Local VTP Database | Global VTP Database | |||
|---|---|---|---|---|
| VLAN ID # | VLAN Name | Ports | VLAN ID# | VLAN Name |
| 1 | default | 1, 3, 15 | 1 | default |
| 2 | local-w | 2, 4, 8 | 2 | global-A |
| 3 | local-x | 5, 10, 16 | 3 | global-B |
| 4 | local-y | 6, 12, 14 | 4 | global-C |
| 5 | local-z | 7, 9, 11, 13 | 5 | global-W |
| 6 | VLAN 5 | 6 | global-D | |
| 7 | VLAN 6 | 8 | global-E | |
| 8 | VLAN 7 | 12 | global-X | |
| 9 | VLAN 8 | 25 | global-F | |
| 10 | VLAN 9 | 67 | global-Y | |
| 11 | VLAN 10 | 281 | global-Z | |
| . | ||||
| . | ||||
| . | ||||
| . | ||||
| 64 | VLAN 63 | |||
As an alternative, you could swap VLANs 2 and 5 first, thus moving the ports and parameters of local-z to local-w and vice versa. (Note that the names do not move.) Then move VLAN 2 to VLAN 281.
After this has been done (and sufficient time has passed such the configuration has propagated from a neighboring device or Stack running VTP), the Local database should go away completely and the user will see the Global database implemented on the upgraded Stack . All the ports and parameters should have survived the move, however, and will be found in the VLANs they were assigned to by VLAN id number before the mode was changed.
For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your product.
For service and support for a product purchased directly from Cisco, use CCO.
CCO is Cisco Systems' primary, real-time support channel. SMARTnet customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
Please use CCO to obtain general information about Cisco Systems, Cisco products, or upgrades. If CCO is not accessible, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.
|
|