Driver Support Document
| SYSOID Mapping | ||
| SYSOID | MODEL | OS VERSION |
| 1.3.6.1.4.1.45.3.46.1 | BayStack470-48T | 3.1.4.10, 3.6 |
| 1.3.6.1.4.1.45.3.52.1 | BayStack5510-24T | 5.1.3.025, 6.0.0.005, 6.2.0.201 |
| 1.3.6.1.4.1.45.3.53.1 | Baystack5510-48T | 5.1.1.017, 4.2.2.012, 4.0.2.02, 6.1.0.006 |
| 1.3.6.1.4.1.45.3.54.1 | BayStack470-24T | 3.7.1 |
| 1.3.6.1.4.1.45.3.59.1 | BayStack5520-24T-PWR | 6.0.1.003s, 6.0.3.008, 6.0.3.009s, 6.2.1.003 |
| 1.3.6.1.4.1.45.3.59.2 | BayStack5520-48T-PWR | 4.2.5.003, 5.1.1.017 |
| 1.3.6.1.4.1.45.3.63.1 | BayStack470-24T-PWR | 3.6.2.04 |
| 1.3.6.1.4.1.45.3.64.1 | BayStack470-48T | 3.7.3.13 |
| 1.3.6.1.4.1.45.3.65 | BayStack5530-24T/TFD | 5.1.1.017, 6.2.1.003 |
| 1.3.6.1.4.1.45.3.71.1 | 4548GT | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.2 | 4548GT-PWR | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.3 | 4550T | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.4 | 4550T-PWR | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.5 | 4256FX | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.6 | 4256GTX-PWR | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.8 | 4254GT | 5.0.1, 5.2.0.063, 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.9 | 4526T-PWR | 5.1.2.004 |
| 1.3.6.1.4.1.45.3.71.10 | 4526T | 5.7.0.009 |
| 1.3.6.1.4.1.45.3.71.11 | 4524GT-PWR | 5.6.1.053 |
| 1.3.6.1.4.1.45.3.71.13 | 4550T-PWR+ | 5.6.0.15 |
| 1.3.6.1.4.1.45.3.74.1 | 5698TFD-PWR | 6.1.4.011, 6.2.0.008 |
| 1.3.6.1.4.1.45.3.74.2 | 5698TFD | 6.2.4.011 |
| 1.3.6.1.4.1.45.3.74.3 | 5650-TD-PWR | 6.3.1.039, 6.6.0.007 |
| 1.3.6.1.4.1.45.3.74.4 | 5650-TD | 6.3.1.039, 6.6.0.007 |
| 1.3.6.1.4.1.45.3.74.5 | 5632FD | 6.2.4.011 |
| 1.3.6.1.4.1.45.3.78.1 | 4826GTS-PWR+ | 5.8.0.1 |
| 1.3.6.1.4.1.45.3.78.2 | 4850GTS-PWR+ | 5.6.1.053 |
| 1.3.6.1.4.1.45.3.78.3 | 4826GTS | 5.6.3.024 |
| 1.3.6.1.4.1.45.3.78.4 | 4850GTS | 5.6.1.053 |
| 1.3.6.1.4.1.45.3.79.1 | VSP 7024XLS | 10.1.0.001, 10.2.1.049, 10.3.0.011 |
| 1.3.6.1.4.1.45.3.80.2 | 3526T-PWR+ | 5.2.2.003 |
| 1.3.6.1.4.1.45.3.80.3 | 3524GT | 5.2.2.003 |
| 1.3.6.1.4.1.45.3.80.4 | 3524GT-PWR+ | 5.1.1.017 |
| 1.3.6.1.4.1.45.3.80.5 | 3510GT | v5.2.2.003 |
| 1.3.6.1.4.1.45.3.80.6 | 3510GT-PWR+ | 5.2.0.005 |
| 1.3.6.1.4.1.45.3.81.2 | 5928GTS-PWR+ | 7.2.0.213 |
| 1.3.6.1.4.1.45.3.81.4 | 5952GTS-PWR+ | 7.0.0.319 |
| 1.3.6.1.4.1.45.3.82.4 | 4950GTS-PWR+ | 7.3.0.241 |
Occasionally, if the device is not accessed regularly it will fail to respond to telnet sessions. If this behavior manifests itself, we recommend creating a simple command script to "wake up" the device on a regular basis.
Create a new command script that sends an arbitrary command to the device. In the event of a snapshot failure you can run this command script a few times to "wake up" the device, or you can set up the script to run on a regular basis to limit occurances of this device failure. If you schedule it to run on a recurring basis, it should be set up to run as often as you poll devices on your network.
The command script to create for this purpose should have the following information defined:
Name: Wake Up BayStack
Description: Script to wake up BayStack device(s)
Mode: Baystack initialization
Driver: {select either the BayStack 470 driver or "All applicable drivers"}
Script: show banner
While most supported device models do not require an Enter when answering the Ctrl-Y login prompt, some models have been shown to require it, particularly those running OS versions 5.8 and 10.3. Devices running those versions will receive an extra Enter after the Ctrl-Y, unless the device access variable "skip_enter" is set to "true".
Device seems to report its spanning-tree and QOS information differently via the CLI and TFTP.
Large configuration deployments on OS version 4.x using SSH might fail due to SSH buffer overflow limitations. Telnet should be used instead of SSH.
If you are using OS versions 6.x, the device supports primary and secondary software image deployment. After a successful secondary software image deployment, the device automatically sets the software image to primary.
If the device is running a 6.x OS image on the primary slot, and the secondary slot is empty, the Update Device Software task updates the software image on the primary slot, however and the secondary slot remains empty.
Workaround: Manually populate a software image on the secondary slot and then run the Update Device Software task. As a result, the Update Device Software task will deploy a software image on the secondary slot as well as on the primary slot.
Discovery tasks for Javascript drivers handle More prompts by using timeouts, which can cause problems with the third-party SSH client code, which interprets the timeout as a disconnection. There are two options to work around the problem. Setting the RCX option [<option name="Driver/Discovery/UsePollRead">true</option>] in site_options.rcx will effect the workaround for all affected devices. Alternatively, it could be applied to a single device by setting the device access variable "PollRead" to "true".
Discovery tasks for Javascript drivers use wakeup characters are sent during device connection, to ensure that the device is responding. Normally, these characters do not echo to the console, but some devices may echo them. In this case, this causes the prompt detection phase to fail, which in turn can cause More prompts to not be handled properly, and discovery may fail. If these characters are echoed from the device [check the session log to see this], then set the device access variable "skip_ctrl_u" to skip the sending of the wakeup characters. Note that setting this option on a previously working device could cause discovery tasks to fail, but it only affects CLI discovery. SNMP discovery is unaffected.