Submit a ticketCall us

Webinar: Web Help Desk for HR, Facilities and Accounting Departments
This webinar will focus on use cases for HR, Facilities and Accounting.

Having a unified ticketing and asset management system for all the departments in your company can provide end-users with a seamless experience and make things easier for your IT team. Yet, with different business tasks and objectives, many departments don’t fully understand the capabilities of Web Help Desk and how the software can be customized for effective use in their departments.
Register Now.

Home > Success Center > Kiwi CatTools > Kiwi CatTools 3.11 Administrator Guide > Devices > Device specific information > Connecting via a session

Connecting via a session

Table of contents
No headers
Created by Caroline Juszczak, last modified by Caroline Juszczak on Jun 28, 2016

Views: 45 Votes: 0 Revisions: 1

 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:

A Cisco 6509 has a firewall service module that you want to backup. The 6509 is CatOS and the FWSM is Cisco IOS.

 

First you create a device called My 6509 that would be defined as a Cisco.Switch.CatOS with all the necessary username and password information. The Host Address is the IP of the device, the Connect Via field is Direct Connect and the Method in this example is Telnet.

 

Next you create a second device called My FWSM defined as a Cisco.Switch.IOS. The Connect Via option is then set to be My 6509 and the Method as Session. In the Host Address field you enter the command that is necessary to access the module. In this example it is Session Slot 4 Proc 1.

Any necessary login details are entered on the Passwords tab.

 

Finally to backup the FWSM you would create a backup activity and assign My FWSM to it. When CatTools runs the backup activity it identifies that to get to My FWSM it needs to go through My 6509 and so logs into that device first. It then issues my custom command to establish the connection and then finally backs up the device as defined by the Cisco.Switch.IOS device type.

 

 

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.

Last modified
07:19, 28 Jun 2016

Tags

Classifications

Public