|
Connecting via a session |
Top Previous Next |
|
The Session connection method was added to provide support for the many and varied methods by which interconnectivity can be achieved. Connections using this method can be achieved from one host device to any virtual device / blade / session or module.
To make use of this feature you need to setup two devices in CatTools. One that represents the parent device and one that represents the virtual device or session contained within it.
Connection to the parent device is as normal. To connect to the virtual device you need to implement the following three fields on the device form.
The Host Address field: This should be used to execute any command that may be necessary to connect to the next device. Examples include: Session 15 Changeto System Session slot 4 proc 1 Telnet
The ConnectVia field: This should be set to the device you need to connect to first in order to establish the session.
The Method field: This should be set to Session.
This feature is currently limited to the following device types. If you need it added to a device type that is not listed then please let us know.
Cisco.Router.General Cisco.Switch.IOS Cisco.Switch.CatOS Cisco.Firewall.ASA Cisco.Firewall.PIX Cisco.ACE 3COM.Switch.SSII
The following example illustrates how this concept works:
DISCLAIMER / WARNING: Normal communication between CatTools and the connected device is a process of sending commands and getting back known responses. We know what responses to expect because we know the OS of the device we are connected to. The Session connection method however can be used to connect from one device to another. In most cases these parent / child devices will be the same OS but in some cases they wont be. eg Cisco 6509. For that reason the logic behind this particular connection routine is different to all others. It works in reverse. As we do not know what a login prompt (if one even exists) might look like on the second device we can not use that as a known good response. Instead we look for the known bad responses of the first device at the time the connection command is issued. If anything other than a known error is received it is assumed that the response is the banner or login or prompt from the second device. At this point control is handed over to the script of the device-type of the second device to process authentication. It is possible that the connection will not be established and that an error message will be returned that is not trapped for. In this case CatTools will think that it is on the second device and start performing the activity scheduled. If the OS's are similar enough the commands may be valid ones and the instructions will be processed on the wrong device.
For this reason we strongly recommend that you thoroughly test all Session connections before putting them into production and that you monitor them closely.
|