Submit a ticketCall us

Training ClassThe Orion® Platform Instructor-led Classes

Provided by SolarWinds® Academy, these trainings will introduce users to the Orion Platform and its features, management, and navigation. These courses are suitable for users looking to discover new tips, tricks, and ways to adapt their Orion products to better suit their monitoring needs:
Deploying the Orion Platform
Configuring Orion views, maps, and accounts
Configuring Orion alerts and reports

Reserve your seat.

Home > Success Center > Kiwi CatTools > Kiwi CatTools Documentation > 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: 305 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



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.










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