Configuration Guide v.04

Printer-friendly versionPDF version

Introduction

iTransformer is a product for network transformation. It consists of three major components iDiscover, ResourceManager and iTopologyManger.  Together they enable network architectrute discovery, topology display, network diff and network state change. The current guide provides information to network engineers and developers on how to configure iTransformer v.04.

Note that you have two options to change the configuration - on a project level or on a global level.

If you change the configuration on a global level it will be applied to all new projects if you change it into the project folders after the project has been created your changes will have local to the project effect. 

Note: Do not assume that if you change a configuration in a file on a global level it will automatically be populated to all projects. It won't!

ResourceManager

ResourceManager - manages network protocol connection parameters in xml based inventory file. Currently two resource manager files are avaliable:

  • resourceManger\conf\xml\resource.xml - used for the Network transformation steps.
  • iDiscover\conf\xml\discoveryResource.xml - used for the discovery process (could be configured also through the GUI interface)

Each Resource has a name and parameters that describes it. Based on those the right resource is selected. The resource also contains several types of connection parameters. Each type specifies certain protocol. Each protocol might have parameters such as login data, port, timeouts and credentials information.

<resource name="cisco">
        <param name="deviceType">CISCO</param>
         <connection-params connection-type="ssh">
        <param name="username">user</param>
            <param name="password">pass</param>
            <param name="enable-password">pass</param>
            <param name="timeout">3000</param>
            <param name="retries">3</param>
        </connection-params>
        <connection-params connection-type="telnet">
        <param name="username">user</param>
            <param name="password">pass</param>
            <param name="enable-password">pass</param>
            <param name="timeout">3000</param>
            <param name="retries">3</param>
        </connection-params>
    </resource>

resource.xml - Resource definition

In this case the resouce will match all devices with deviceType=CISCO.It contains two connection-parameter groups. The first one is used for ssh connections and the second one is for telnet.

iDiscover

iDiscover has two configuration files. Both could be found at iDiscover\conf\xml in your project folder.

discoveryManger.xml

This is the main iDiscover configuration  file. It has two major sections - discovery-helper and discovery-manager-listeners.

<discovery-manager>
    <discovery-helper class="net.itransformers.idiscover.discoveryhelpers.xml.XmlDiscoveryHelperFactory">
        <parameters>
            <param name="fileName">iDiscover/conf/xml/discoveryParameters.xml</param>
            <param name="resourceXML">iDiscover/conf/xml/discoveryResource.xml</param>
        </parameters>
    </discovery-helper>
    <discovery-manager-listeners>
        <discovery-manager-listener class="net.itransformers.idiscover.discoverylisteners.DeviceFileLogger">
            <param name="path">network</param>
        </discovery-manager-listener>
        <discovery-manager-listener class="net.itransformers.idiscover.discoverylisteners.XmlTopologyDeviceLogger">
            <param name="xslt">iDiscover/conf/xslt/transformator-undirected2.xslt</param>
            <param name="path">network</param>
            <param name="type">undirected</param>
        </discovery-manager-listener>
        <discovery-manager-listener class="net.itransformers.idiscover.discoverylisteners.XmlTopologyDeviceLogger">
            <param name="xslt">iDiscover/conf/xslt/transformator-directed.xslt</param>
            <param name="path">network</param>
            <param name="type">directed</param>
        </discovery-manager-listener>
    </discovery-manager-listeners>
</discovery-manager>

DiscoveryManager.xml

Discovery-Helper

Discovery-helpers  configuration have two parameters that point to two important files discoveryParameters.xml (used to describe the parameters required in order the discovery Process to discover the network) and discoveryResource.xml which describes the ResourceManager configuration file used for the discoveryProcess.

Discovery-Manager-Listerners

This section describes the implementation of different discovery event listerners. Discovery event listeners are trigered once a device is discovered.

  • com.discovery.discoverylisteners.DeviceFileLogger - has a single parameter that specifies where raw-data and device xml file will be stored by iDiscover.
  • com.discovery.discoverylisteners.XmlTopologyDeviceLogger - Creates graphml topology files from the device xml files. It has two parameters:
  • Xslt - specifies the xslt transformator file used to perform the transformation from device.xml to a graphml.
  • Path - specifes where the generated graphml files have to be stored.

Note that iDiscover has two XmlTopologyDeviceLogger - one is used for generation of directed view graphml files and the other for undirected one.

discoveryParameters.xml

discoveryParameters.xml contains discovery-helper and discovery algorithm stop criteria configuration options. 

Discovery-helper allows customization of iDiscover SNMP requests for each deviceType that might be found in the network. The current discovery process retrieves device hostname and type. Once it knows the type it can choose the rest of the request. If the device is from an unknown type it will always assemble the “Default” request. Current discovery support Cisco, Juniper, Huawei, HP, and Tellabs devices.

Each device section has several subsections. Discovery users might delete some of the SNMP requests from some of the sections or the whole section completely but can not change section names. For example if ARP requests are not needed for certain deviceType has to be delete ipNetToMediaTable from PHYSICAL discovery section. This way of configuration allows network administrator really to fine tune iDiscover requests towards the network depending of the specific device capabilities.

<discovery-helper>
    <device type="DEFAULT" xslt="iDiscover/conf/xslt/transformator.xslt">
        <!-- Contain snmp oid names needed for general device description -->
         <general>ifIndex,ifDescr,ifOperStatus,ifAdminStatus,ifNumber,ifPhysAddress,ifType,dot1dTpFdbAddress,system,ipAddrTable,ifIndex, ifName
        </general>
<!-- Contain parameteters needed for physical description of the device and physical discovery methods -->
 <discovery-method name="PHYSICAL">  dot1dBaseBridgeAddress,dot1dStpDesignatedRoot, dot1dStpPortEntry,dot1dTpFdb,dot1dTpFdbStatus,dot1dTpFdbPort,dot1dBasePort,dot1dBasePortIfIndex,ipNetToMediaTable,lldpRemoteSystemsData,cdpCacheDevicePort,cdpCacheDevicePlatform,cdpCacheDeviceId,cdpCacheIfIndex,cdpCachePrimaryMgmtAddrType,cdpCachePrimaryMgmtAddr, dot1qVlanStaticEntry
        </discovery-method>
        <!-- Contain request parameters needed for next-hop discovery methods -->
        <discovery-method name="NEXT_HOP">
            ipRouteIfIndex, ipRouteNextHop
            inetCidrRouteType, inetCidrRouteIfIndex, inetCidrRouteNextHop, inetCidrRouteProto, inetCidrRouteNextHopAS
        </discovery-method>        
        <!-- Contain request parameters needed for OSPF discovery methods -->
        <discovery-method name="OSPF">ospfRouterId,ospfNbrEntry,ospfAdminStat,ospfVersionNumber,ospfAreaBdrRtrStatus,ospfASBdrRtrStatus,ospfAreaTable,ospfIfEntry
        </discovery-method>
        <discovery-method name="BGP">
            bgpLocalAs,bgpPeerEntry
        </discovery-method>
        <discovery-method name="ISIS">
            isisISAdjIPAddrEntry
        </discovery-method>
        <discovery-method name="RIP">
            rip2IfConfTable,rip2IfStatTable
        </discovery-method>
        <discovery-method name="ADDITIONAL">
            mplsVpnVrfName,mplsVpnVrfRouteDistinguisher,mplsVpnVrfRouteDistinguisher,
            dot1dBaseNumPorts, dot1qVlanStaticTable
        </discovery-method>
         <discovery-method name="IPV6">
            ipv6Forwarding, ipv6IfIndex, ipv6AddrEntry,ipv6NetToMediaEntry,ipv6RouteEntry
         </discovery-method>
    </device>
</discovery-helper>

DiscoveryParameters xml

To add new device just add a new devicetype section to the file and specify a xslt transformator file that will transform the raw data xml gathered from the devices with that type.<device type="NEW_DEVICE" xslt="iDiscover/conf/xslt/transformator.xslt"/>

Config Example 3 Adding new device to DiscoveryParameters xml

Each discoverytype contains a general section that contains SNMP OID names general device parameters and several other discoverymethods. If you want to customize discovery methods just add your SNMP OIDS to the current one. If those are not enough and a new method has to be implemented add a new discovery-method section to the deviceType that might support the method.

<discovery-method name="NEW_METHOD">       
        SNMP_OID_NAME_1, SNMP_OID_NAME_X….
</discovery-method>

DiscoveryParameters.xml - Adding new discovery method to certain device in l

Note that adding the new devices still does not work as expected due to some initial bad design. If you want support for your kind of devices please let us know at info@itransformers.net. Currently if your device is not among the list of Vendors it will still be discovered by the DEFAULT parameters section of DiscoveryParameters xml.

Discovery stop criteria

discoveryParameters.xml describes a set of rulls known as stop criteria. They specify what to be discovered and what to not be discovered in your network.
For example if all devices with hostnames starting with CE shall not be discovered the stop criteria has to match the hostname with a regex match.
If iDiscover should not to discover devices from sertain IP range the match rule has to regex that ip range. An interesting combination is the regex “.*” - this one is a "Match rule for all ip addresses”. 
<match property="host">CE*</match>
<match property="ipAddress.ipAddress">.*</match>
<match-not property="ipAddress.ipAddress">10\..*</match-not>
<match-not property="ipAddress.ipAddress">172\..*</match-not>
<match-not property="ipAddress.ipAddress">192\.168.*</match-not>
DiscoveryParameters xml-iDiscover Stop Criteria
In the example above the iDiscover process will run itself only againt the devices with private ip addresses.
Note:
Everything that has been matched will not be discovered and everything that has not been matched will be discovered.

Grap key metadata

iDiscover produces a set of graphml files that represent the network. The graphmls are stored in the version folders of your network project. Each of graphml contains nodes, edges and key network metadata that describes the architecture of your network. It is important to note that iDiscover is a tool not for network topology discovery but for architecture recreation in a data model from a life networks. The topology information is represented by the nodes and the edges part of the graph. The architecture significant network properties are represented as graph metadata. The key metadata later allows iTopologyManager to represent each node and edge with the correct icon and color, to filter correctly  the topology views and to apply network transformation steps against the life network.

   <graph edgedefault="undirected">
      <key id="hostname" for="node" attr.name="hostname" attr.type="string"/>
      <key id="deviceModel" for="node" attr.name="deviceModel" attr.type="string"/>
      <key id="deviceType" for="node" attr.name="deviceType" attr.type="string"/>
      <key id="nodeInfo" for="node" attr.name="nodeInfo" attr.type="string"/>
      <key id="deviceStatus" for="node" attr.name="deviceStatus" attr.type="string"/>
      <key id="ManagementIPAddress" for="node" attr.name="ManagementIPAddress"
           attr.type="string"/>
      <key id="geoCoordinates" for="node" attr.name="geoCoordinates" attr.type="string"/>
      <key id="site" for="node" attr.name="site" attr.type="string"/>
      <key id="diff" for="node" attr.name="diff" attr.type="string"/>
      <key id="diffs" for="node" attr.name="diffs" attr.type="string"/>     
      <key id="ipv4Forwarding" for="node" attr.name="ipv4Forwarding" attr.type="string"/>
      <key id="ipv6Forwarding" for="node" attr.name="ipv6Forwarding" attr.type="string"/>
      <key id="name" for="edge" attr.name="name" attr.type="string"/>
      <key id="discoveryMethod" for="edge" attr.name="discoveryMethod" attr.type="string"/>
      <key id="dataLink" for="edge" attr.name="dataLink" attr.type="string"/>
      <key id="ipLink" for="edge" attr.name="ipLink" attr.type="string"/>
      <key id="MPLS" for="edge" attr.name="MPLS" attr.type="string"/>
      <key id="ipv6Forwarding" for="edge" attr.name="ipv6Forwarding" attr.type="string"/>
      <key id="ipv4Forwarding" for="edge" attr.name="ipv4Forwarding" attr.type="string"/>
      <key id="localInterfaceName" for="edge" attr.name="localInterfaceName"
           attr.type="string"/>
      <key id="remoteInterfaceName" for="edge" attr.name="remoteInterfaceName"
           attr.type="string"/>
      <key id="localIPAddress" for="edge" attr.name="localIPAddress" attr.type="string"/>
      <key id="remoteIPAddress" for="edge" attr.name="remoteIPAddress" attr.type="string"/>
      <key id="edgeTooltip" for="edge" attr.name="edgeTooltip" attr.type="string"/>
      <key id="diff" for="edge" attr.name="diff" attr.type="string"/>
      <key id="diffs" for="edge" attr.name="diffs" attr.type="string"/>

Config Example 6  Key graphml graph meta data

Node metadata

Each Node is described by certain graph metadata with a set of dataKeys. Typical list might contain data keys as deviceModel, deviceType, deviceStatus, ManagementIPAddress, site, geoCoordinates,  deviceInfo, ipv4Forwarding, ipv6Forwarding.The complete list of node properties for any device could be reviewed from the graphml file for the particular device<node id="C7">

         <data key="hostname">C7</data>
         <data key="deviceModel">cisco2611</data>
         <data key="deviceType">CISCO</data>
         <data key="deviceStatus">discovered</data>
         <data key="ManagementIPAddress">10.11.222.2</data>
         <data key="site">Moskow</data>
         <data key="geoCoordinates">23.13661,12.687546</data>
         <data key="ipv6Forwarding">NO</data>
   <data key="deviceInfo"><![CDATA[ <html><b>Type: </b>CISCO <b>Model:</b> cisco2611 <b>Site:</b> C7<br><b>Mgmt IP address:</b> 10.11.222.2<br/><b>ipv6Forwarding:</b> NO<b>BGPLocalASInfo:</b> 0</html>]]></data>
</node>

Node metadata as discovered by iDiscover

Edge metadata

Each Edge(link) is described by certain graph metadata with a set of dataKeys. Typical list might contain data keys as deviceModel, deviceType, deviceStatus, ManagementIPAddress, site, geoCoordinates,  deviceInfo, ipv4Forwarding, ipv6Forwarding.The complete list of node properties for any device could be reviewed from the graphml file for the particular device.
 <edge id="R1 R3 &#xA;-&#xA;FastEthernet0/0 FastEthernet0/0 " source="R1" target="R3">
         <data key="edgeTooltip">&lt;p&gt;&lt;b&gt;R1&lt;/b&gt; FastEthernet0/0&lt;b&gt;&lt;/b&gt; ( 172.16.13.1 )
                | NEXT_HOP,ARP,CDP,OSPF,BGP&lt;/p&gt; </data>
         <data key="localInterfaceName">FastEthernet0/0</data>
         <data key="remoteInterfaceName">FastEthernet0/0</data>
         <data key="localIPAddress">172.16.13.1</data>
         <data key="remoteIPAddress">172.16.13.3</data>
         <data key="method">NEXT_HOP,ARP,CDP,OSPF,BGP,</data>
         <data key="ipLink">YES</data>
         <data key="dataLink">YES</data>
      </edge>
 Edge metadata as discovered by iDiscover

iTopologyManager

The main TopologyManager configuration file is iTopologyManager/topologyViewer/conf/xml/viewer-config.xml. It contains the configuration of the  node icons,  line types, topology filters and  node tooltips and node rightclick methods.

TopologyViewer

TopologyViewer previews the network topology in a graph style view and allows the Network Engineers to reason and analyze it. Each graph might be directed or undirected so the viewer supports directed graph views and undirected such.

Icon selection

Each device has to be correctly presented as a graph node with a specific icon. Icon selection is based on node data key match. The icon is choosen by one or more data keys of the node. The major rule is - first icon mathced is selected. That means icons that have more propperties have to be in configuration prior those that might mach on smaller number of properties. If no icon is matched a default icon will be used. Typically this is the case for all hosts that do not have any metadata or have such that could not be matched by the icon selection mechanism.

An example is presented bellow.

<icon name="/images/76xx_IPv6.PNG">
         <data key="deviceType">CISCO</data>
         <data key="ipv6Forwarding">YES</data>
</icon>
<icon name="/images/m320_IPv6.PNG">
         <data key="deviceType">JUNIPER</data>
         <data key="ipv6Forwarding">YES</data>
</icon>
<!--….. Output omited -->
<icon name="/images/76xx.PNG">
        <data key="deviceType">CISCO</data>
</icon>
<icon name="/images/m320.png">
        <data key="deviceType">JUNIPER</data>
</icon>
<!--….. Output omited -->
<!-- Default Icon-->
<icon name="/images/unknown_switch.PNG">
</icon>

viewer-config.xml-Icons Definition

Topology Filters definition

Each filter selects nodes and edges based on their data key properties. Simple filter definition is presented bellow. Each user might create its own filters specifing different dataKeys. Note that the first filter in the row is always used for initial network display.

<filter name="CISCO Devices">
        <include dataKey="deviceType" dataValue="CISCO" for="node"/>
        <include dataKey="method" dataValue="NEXT_HOP" for="edge"/>
        <include dataKey="method" dataValue="CDP" for="edge"/>
        <include dataKey="method" dataValue="LLDP" for="edge"/>
        <include dataKey="method" dataValue="Slash30" for="edge"/>
        <include dataKey="method" dataValue="Slash31" for="edge"/>
        <include dataKey="method" dataValue="MAC" for="edge"/>
        <include dataKey="method" dataValue="OSPF" for="edge"/>
        <include dataKey="method" dataValue="c_STATIC_ROUTE" for="edge"/>
        <include dataKey="method" dataValue="c_OSPF" for="edge"/>
        <include dataKey="method" dataValue="c_ISIS" for="edge"/>
        <tooltip dataKey="nodeInfo" for="node"/>
        <tooltip dataKey="edgeTooltip" for="edge" transformer="net.itransformers.topologyviewer.edgetooltip.HTMLCSVEdgeTooltipTransformer"/>
    </filter>

viewer-config.xml filter defininition

Tooltips definition

Each filter view allows the selection of a certain edge/node tooltip. If no tooltip is specified a default one is used.
<tooltip dataKey="method" for="edge" transformer="com.topolgyviewer.edgetooltip.CSVEdgeTooltipTransformer"/>

 <tooltip dataKey="deviceInfo" for="node"/>

viewer-config.xml default Tooltip defininition
 
If a specific tooltip has to be specified for certain filter the tooltip tag has to be added to the filter configuration.
<filter name="IPLinkLayer">
            <include dataKey="ipLink" dataValue="YES" for="edge"/>
            <tooltip dataKey="deviceInfo" for="node"/>
            <tooltip dataKey="localIPAddress" for="edge" transformer="com.topolgyviewer.edgetooltip.DashEdgeTooltipTransformer"/>
</filter>
viewer-config.xml Filter Tooltip defininition

Hops

TopologyViewer allows network topology to be redrawed around cetain node by a certain number of hops. That could be achieved by Redraw Arround button.

Note that each filter renders the topology based on a certain number of hops from the nodes seleted by the filter. That number and also the default number of hops used by Redraw Arround button are specified in topology-viewer xml file in the hops tag.  The selected number is the default number of hops used by the filter or by the button.

<hops selected="3">1,2,3,4,5,6,7,8,9,10</hops>

viewer-config.xml-hops parameter definition

RighclickHandlers

Rightclicks are methods available to the user once a righchlick is pressed on a device icon.  Each handler has to have a name and to point to a rightclick handler class. Then it might have one or more parameters. Simple rightcklick report handler is presented bellow.

<rightClickItem name="Device Neighbors" handlerClass="com.topolgyviewer.rightclick.impl.XsltReportCreator">
                    <param name="xsl_transformator">rightclick/conf/xslt/deviceNeighbors.xslt</param>
                    <param name="table_transformator">rightclick/conf/xslt/table_creator.xslt</param>
</rightClickItem>

viewer-config.xml-right click handler configuration example

Network transformation steps

The actions of the network transformation steps are invoked by the RighclickHandler. They fulfill different actions against the network. Therefore they are interchangabally known also as fulfillmentfactories. The actions could be invoked by two rightclicks - nodeActivation and pathActivation.

  • parameterFactoryXml - local path to ParameterFactory xml configuration file
  • resource - local path to Resource xml configuration file
  • fulfilment-factory - local path to fulfillment factory xml configuration file

 <rightClickItem name="nodeActivation" handlerClass="net.itransformers.topologyviewer.rightclick.impl.CmdRightClickHandler">
        <param name="parameterFactoryXml">iTopologyManager/parameter-factory/conf/xml/param-factory.xml</param>
        <param name="resource">resource-manager/conf/xml/resource.xml</param>
        <param name="fulfilment-factory">iTopologyManager/fulfilment-factory/conf/xml/fulfilment-factory.xml</param>
    </rightClickItem>

viewer-config.xml - nodeActivation rightclick configuration

A short demo showing how to configure network transoformation steps is shown here.

Binding resources, parameters and CLI templates

The binding between the ResourceManager, ParameterFactory and the Fullfillment factory templates is configured in iTopologyManager/fulfilment-factory/conf/xml folder.

First has to be configured a fullfilment factory type in fulfilment-factory.xml (resides in iTopologyManager/fulfilment-factory/conf/xml folder).  The type has a single parameter named "commands" that binds the type with a particular CLI template.

    <fulfilment-factory-types>
            <type name="ConfigureInterface" class="net.itransformers.topologyviewer.fulfilmentfactory.impl.TestFulfilmentImpl">
                   <param name="commands">iTopologyManager/fulfilment-factory/conf/txt/configureInterface.txt</param>
            </type>
    </fulfilment-factory-types>
fulfilment-factory.xml - fylfillment factory type
Then the has to be provided a binding  between the fulfillment-factory type a parameter-factory and resource. That binding has to be configured again in fulfilment-factory.xml file
    <fulfilment-factory name="ConfigureInterface" resourceName="cisco" type="ConfigureInterface" parameterFactoryName="ConfigureInterface"/>

CLI Templates

CLI templates typically reside in the following folder: iTopologyManager/fulfilment-factory/conf/txt.

Each template receives input parameters from the Parameter Factory. Then the parameters are passed to different command statements. Each template contains several read_until statements. Each read_until statement can match one regex statement. Once there is a a command is send to the device.

If certain regex statement has to be matched multiple times (typical example are the prompts after each CLI command) could be used a combination between start read_until and stop read_until. In between could be placed any combination of CLI commands. Each command could contain a String or a String input variables (those with the dollar sign $).  An example bellow.

### vars: hostname, username, password, firstFreeInterface, ipAddress, subnetMask
### read_until('(login:|user:|Username:)',3)
$username
### read_until('(Password:|password:)',3)
$password
### start read_until('.*#',3)
set cli  screen-length 0
configure terminal
intrface $firstFreeInterface
ip address $ipAddress $subnetMask
no shutdown
### stop read_until
exit
### stop read_until
### exit

Fulfillment factory config script

This template first automates the login

### read_until('(login:|user:|Username:)',3). If there is a match a $username is supplied.

### read_until('(Password:|password:)',3). If there is a match a $password is supplied.

Then follows a block of command statements and parameters.

### start read_until('.*#',3)
set cli  screen-length 0
configure terminal
intrface $firstFreeInterface
ip address $ipAddress $subnetMask
no shutdown
### stop read_until

Finally  there is an exit command from the device and also a ###exit statement in the template.

### stop read_until
exit
### stop read_until
### exit

ParameterFactory

ParameterFactory - has the responsibility to combine various parameters from iDiscover graph metadata model, device-xml files , Resources and parameters entered through manual entry.

<param-factory name="CISCO">
        <param-factory-element type="graphml">
           <param name="ManagementIPAddress"/>
           <param name="site"/>
        </param-factory-element>
        <param-factory-element type="manual">
            <param name="a"/>
            <param name="b"/>
        </param-factory-element>
        <param-factory-element type="deviceData">
            <param name="firstFreeInterface">//DiscoveredDevice/object[objectType='Discovery Interface'][1]/parameters/parameter[name='CableCut' and value ='NO']/../../name</param>
            <param name="InterfaceIPaddress">//DiscoveredDevice/object[objectType='Discovery Interface' and name='$a']/object[objectType='IPv4 Address']/parameters/parameter[name='IPv4Address']/value</param>
            <param name="MgmntInterfaceIPaddress">//DiscoveredDevice/object/object[objectType='IPv4 Address']/parameters/parameter[value='$ManagementIPAddress']/../../../name</param>
        </param-factory-element>
        <param-factory-element type="resource">
            <param name="username"/>
            <param name="password"/>
            <param name="enable-password"/>
        </param-factory-element>
    </param-factory>

viewer-config.xml-Param factory definition

In the example above “a” and “b” are manual input parameters, firstFreeInterface and InterfaceIPaddress are XPATH parameters that are evaluated against the device.xml file and username, password and enable-password are parameters evaluated against the resource xml file.

Configuring iTopologyManager additional RighClick items

iTopoManager RighClickHandlers configuration is part of  undirecte/directed.xml files. Each rightClick handler receives theree groups of parameters:

  • graphmParameters - associated with the current node.
  • rightClickParams - specified in the topology-viewer xml file.
  • deviceXML - path to deviceXML

More about RighClickHandler implementation could be found in the developer’s guide.

NewTab

NewTab opens the already loaded graphmls in a new topologyviewer tab. It does not need any aditional parameters so as configutation is enough just to be specified the class that handlers that.

           <rightClickItem name="NewTab" handlerClass="com.topolgyviewer.rightclick.impl.TabbedViewerOpener">

viewer-config.xml-New Tab rightclick

Connect Through

Connect Through is a submenu that contains several different rightclick handlers. Each of them allows the iTopoManager to connect to certain network resource<submenu name="Connect through">

  <rightClickItem name="HTTP" handlerClass="com.topolgyviewer.rightclick.impl.URLRightClickOpener">
        <param name="protocol">http</param>
        <param name="port">80</param>
  </rightClickItem>
  <rightClickItem name="HTTPS" handlerClass="com.topolgyviewer.rightclick.impl.URLRightClickOpener">           <param name="protocol">https</param>
         <param name="port">443</param>
  </rightClickItem>
  <rightClickItem name="putty" handlerClass="com.topolgyviewer.rightclick.impl.PuttyRightClickHandler">
        <param name="ssh_no_saved_session">../lib/putty/putty.exe -ssh -l %s -pw %s %s</param>
        <param name="ssh_saved_session">../lib/putty/putty.exe -ssh -l %s -pw %s -load %s %s </param>
        <param name="telnet_no_saved_session">lib/putty/putty.exe -telnet -l %s %s</param>
        <param name="telnet_saved_session">../lib/putty/putty.exe -telnet -l %s -load %s %s</param>
        <param name="resource">resource-manager/conf/xml/resource.xml</param>
        <param name="saved_session">saved_session</param>
  </rightClickItem>
</submenu>

viewer-config.xml - Connect through Rightclick handlers (HTTP/HTTPs and Putty) configuration

HTTP/HTTPS

HTTP/HTTPS open new http/https connection in a browser.They are built by the same URLRightClickOpener class. The main idea is to pass an URL string to a browser. The string is constructed as per the following rule:

<protocol>://<ManagementIPAddress>:<port>
Therefore it have two configurable parameters.

  • Protocol - specifies the protocol part of the URL that will be passed to the browser.

  • Port - specifies the port part of the URL.

Reports

Report plugins allows report creation. Each report is a basic html that is created by xslt transformation of the device xml output file. Each report has two parameters:

  • xsl_transformator - the xslt file used for the device xml transformation into a valid html report.
  • table_transformator - optional parameter that specifies the path to a xslt file that creates html table from a xml structure.

<submenu name="Reports">
            <rightClickItem name="Device Neighbors" handlerClass="com.topolgyviewer.rightclick.impl.XsltReportCreator">
                    <param name="xsl_transformator">rightclick/conf/xslt/deviceNeighbors.xslt</param>
                    <param name="table_transformator">rightclick/conf/xslt/table_creator.xslt</param>
            </rightClickItem>
            <rightClickItem name="Cable Cuts" handlerClass="com.topolgyviewer.rightclick.impl.XsltReportCreator">
                    <param name="xsl_transformator">rightclick/conf/xslt/cableCut.xslt</param>
                    <param name="table_transformator">rightclick/conf/xslt/table_creator.xslt</param>
            </rightClickItem>
            <rightClickItem name="IPv4 Address Space" handlerClass="com.topolgyviewer.rightclick.impl.XsltReportCreator">
                    <param name="xsl_transformator">rightclick/conf/xslt/IPv4.xslt</param>
                    <param name="table_transformator">rightclick/conf/xslt/table_creator.xslt</param>
            </rightClickItem>
            <rightClickItem name="IPv6 Address Space" handlerClass="com.topolgyviewer.rightclick.impl.XsltReportCreator">
                    <param name="xsl_transformator">rightclick/conf/xslt/IPv6.xslt</param>
                    <param name="table_transformator">rightclick/conf/xslt/table_creator.xslt</param>
            </rightClickItem>
            <rightClickItem name="MPLS L3 VPN" handlerClass="com.topolgyviewer.rightclick.impl.XsltReportCreator">
                    <param name="xsl_transformator">rightclick/conf/xslt/mplsL3VPN.xslt</param>
                    <param name="table_transformator">rightclick/conf/xslt/table_creator.xslt</param>
            </rightClickItem>
        </submenu>

 viewer-config.xml - Reports submenu configuration

ObjectTreeBrowser

Does not need any additional parameters just a reference to the building class.

<rightClickItem name="Object Tree Browser" handlerClass="com.topolgyviewer.rightclick.impl.XMLTreeViewHandler">

viewer-config.xml - ObjectTreeBrowser

Conclusion

iTransformer is a highly reconfigurable tool.  Please use it with care!

Tags: