### Template for ATM Virtual Connection

- Example - Overview
- Understanding the working of the example
- Making it Work
- Sample Output

Example - Overview

This example (ATM_Virtual_Connection.xml), will cover the setup of an ATM end-to-end connection, where one customer port on one switch (we will call it source) is connected to another customer port on another switch (we will call it destination). This template is an ATM VC example, where we configure an ATM virtual connection using the capabilities of ATM MIB defined in IETF RFC 1694.

Understanding the working of the example

Before invoking this example, we need to understand the working of this example template in more detail. To setup an ATM virtual connection, the ATM switch network is assumed to be setup and available. Certainly for this example, it is assumed that the ATM switches fully support the ATM MIB (RFC 1694), or at least the parts that we are going to use.

The model and operation followed in this example template may not be appropriate for all ATM connection configuration and is only an example, e.g. we decided to configure the VP and VC together in one operation, which may not be the most common usage. Actual usage may vary in the choices, of what data to collect from users, making users verify more of the data, etc.

The ATM MIB defines VP and VC link and cross connect tables, which we will use to setup the end-to-end connection in the network. In this example, it is assumed that the trunks between switches are already setup and operational, and we will configure end-to-end connections that use these trunks. To keep this example simple, it is assumed that every switch in the network is connected to every other switch with a direct trunk. The configuration activity essentially involves setting up VP and VC cross connects on each switch, i.e. the source and destination switches.

The configuration commands would create new rows in four separate tables on each switch :

- VP Link Table: We need to configure two new entries in this table on each ATM switch, one for each VP end point on the switch.
- VP Cross Connect Table: We need one entry for the VP cross connect on each ATM switch.
- VC Link Table: We need to configure two new entries in this table on each ATM switch, one for each VC end point on the switch.
- VC Cross Connect Table: We need one entry for the VC cross connect on each ATM switch.

That is a total of twelve new rows for the two switches.

From studying this operation, and from looking at the MIB, we realize the need for specific data from multiple sources to execute this configuration. We will be using the templates ability to parameterize the Web NMS configuration engine XML, to accomplish the task. We need data from the inventory database, data from the network, and data from the operator to do this operation.

The list of data we need is as follows :

- Source ATM Switch Hostname - This is specified before the operation begins as a template parameter, e.g. from the map node that is selected. We will call it Source, i.e. it will be substituted for $TemplateParam$Source.
- Destination ATM Switch Hostname - This is specified before the operation begins as a template parameter, e.g. from the map node that is selected. We will call it Dest, i.e. it will be substituted for $TemplateParam$Dest.
- Source ATM Switch Community - This is collected from the network inventory database. It will be substituted for $InventoryInput$scommunity.
- Destination ATM Switch Community - This is collected from the network inventory database. It will be substituted for $InventoryInput$dcommunity.
- Source ATM Switch SNMP Port - This is collected from the network inventory database. It will be substituted for $InventoryInput$ssnmpport.
- Destination ATM Switch SNMP Port - This is collected from the network inventory database. It will be substituted for $InventoryInput$dsnmpport.
- Interface Index on Source Switch of Trunk connecting Switches - We will require this data on the trunk between any two switches be collected as part of the auto-discovery process. This data is assumed to be stored as a dynamic (user) property in the switch managed object, in the form Remoteswitchname-port=index. Then it is collected from the network inventory database. It will be substituted for $InventoryInput$strunk.
- Interface Index on Destination Switch of Trunk connecting Switches - This is collected from the network inventory database. It will be substituted for $InventoryInput$dtrunk.
- The next index for the atmVpCrossConnectIndex on Source switch to use when adding a new VP cross connect entry in the VP Cross Connect table. This must be obtained from the device SNMP agent. It will be substituted for $NEInput$ atmVpCrossConnectIndexNext1.
- The next index for the atmVcCrossConnectIndex on Source switch to use when adding a new VP cross connect entry in the VC Cross Connect table. This must be obtained from the device SNMP agent. It will be substituted for $NEInput$ atmVcCrossConnectIndexNext1.
- The next index for the atmVpCrossConnectIndex on Destination switch to use when adding a new VP cross connect entry in the VP Cross Connect table. This must be obtained from the device SNMP agent. It will be substituted for $NEInput$ atmVpCrossConnectIndexNext2.
- The next index for the atmVcCrossConnectIndex on Destination switch to use when adding a new VP cross connect entry in the VC Cross Connect table. This must be obtained from the device SNMP agent. It will be substituted for $NEInput$ atmVcCrossConnectIndexNext2.
- The source switch port, i.e. the customer port that is the ingress. This is obtained from the operator via user forms. It will be substituted for $UserInput$sport.
- The VPI to use on the source switch for the ingress port. This is obtained from the operator via user forms. It will be substituted for $UserInput$svpi.
- The VCI to use on the source switch for the ingress port. This is obtained from the operator via user forms. It will be substituted for $UserInput$svci.
- The receive traffic class for the VPI and VCI. To reduce complexity in the example, we use same traffic parameters for VP and VC entries across the board on the same switch. The convention we will use is that these apply to receiving at the ingress port on the source switch, and transmit from the ingress port on source switch. This is obtained from the operator via user forms. It will be substituted for $UserInput$srdesc.
- The transmit traffic class for the VPI and VCI. This is obtained from the operator via user forms. It will be substituted for $UserInput$stdesc.
- The destination switch port, i.e. the customer port that is the ingress. This is obtained from the operator via user forms. It will be substituted for $UserInput$dport.
- The VPI to use on the destination switch for the ingress port. This is obtained from the operator via user forms. It will be substituted for $UserInput$dvpi.
- The VCI to use on the destination switch for the ingress port. This is obtained from the operator via user forms. It will be substituted for $UserInput$dvpi.
- The receive traffic class for the VPI and VCI. Although unlikely to be different from the source switch version, we leave the option of having different parameters on this switch. This is obtained from the operator via user forms. It will be substituted for $UserInput$drdesc.
- The transmit traffic class for the VPI and VCI. This is obtained from the operator via user forms. It will be substituted for $UserInput$dtdesc.

Making it Work

> Prerequisite

- An ATM network supporting the ATM MIB, or a simulation of such a network should be available.
- Auto-discovery supporting collection of the trunk information between switches, or manual addition of the trunk information described earlier to each of the switches.

Testing the Template

Here is the procedure for testing this template in a simulated environment. AdventNet provides Agent Simulation Toolkit for simulating agents. It can be downloaded from the following

> > URL http://www.adventnet.com/products/simulator/index.html

After downloading and extracting it, please follow the steps given below for starting the ATM-MIB simulated SNMP agent.

This template requires two ATM Switches for testing. The two ways of simulating two ATM Switches are:

- Running SNMP agent simulator in two machines that are connected together to a network.
- Running two SNMP agent simulators in the same machine.

I. Running SNMP agent simulator in two machines that are connected together to a network

- Launch the SimulationToolkit script present in the AdventNet/simulator directory of AdventNet Agent Simulation Toolkit
- AdventNet Simulation Toolkit UI will appear
- Start the SNMP Agent Simulator in XML Mode.
- AdventNet SNMP Agent Simulator UI will appear.
- Copy the ATM-MIB present in <Web NMS Home>/mibs directory to the AdventNet/simulator/mibs directory.
- Click the "File" --> "Load Mib File" in the AdventNet SNMP Agent Simulator UI and open the ATM-MIB.
- Click the "Settings" --> "General Settings" in the AdventNet SNMP Agent Simulator UI and configure the SNMP version type and SNMP port etc. as you wish.
- The next step will be configuring the index values to use for the cross connect tables.
- For changing the atmVpCrossConnectIndexNext and atmVcCrossConnectIndexNext to linear one,

- Select atmVpCrossConnectIndexNext by traversing through the ATM-MIB as follows : ATM-MIB --> mib-2 --> atmMIB --> atmMIBObjects.
- Change the Simulation Type present in the right side to LINEAR.
- Specify the value of 'm' and value of 'c' as 1.
- Similarly select atmVcCrossConnectIndexNext by traversing through the ATM-MIB as follows : ATM-MIB --> mib-2 --> atmMIB --> atmMIBObjects.
- Change the "Simulation Type" option present in the right side to LINEAR.
- Specify the value of 'm' and value of 'c' as 1.

- Now SNMP agent is ready to run.
- Click "Operations" --> "Start Agent" for starting the SNMP Agent.
- Please repeat the steps 1 - 7 for starting the ATM-MIB simulated SNMP Agent in the second machine also.

Now we successfully started ATM SNMP agents in two different machines.

II. Running two SNMP agent simulators in the same machine

This template needs two ATM Switches for testing. With only one machine, we can achieve this by configuring one Virtual IP Address in the machine. The Virtual IP Address is considered as the second ATM Switch by giving entries in <Web NMS Home>/conf/seed.file.

Please refer the AdventNet/simulator/help/start/Configuring_Virtual_IP_Addresslink.html page for configuring the Virtual IP Address in Windows/Linux machine. After creating the Virtual IP Address, please run two ATM-MIB simulated SNMP Agents in two different ports.

Now we are ready with the SNMP agents, to test this example. Please follow the steps mentioned below for testing this example.

- For quick discovery of the machines in which SNMP Agent is running and for specifying the SNMP agent port, please edit the following entries in <Web NMS Home>/conf/seed.file appropriately.

> > <TO_DISCOVERIP>
> > <ip NODE_ID="IPAddress of first machine" NETMASK="net mask" SNMPAGENTPORT="port at which Simulated SNMP Agent running" COMMUNITY="SNMP Agent community"/>
> > <ip NODE_ID="IPAddress of second machine/Virtual IP Address of the machine" NETMASK="net mask" SNMPAGENTPORT="port at which Simulated SNMP Agent running" COMMUNITY="SNMP Agent community"/>
> > </TO_DISCOVERIP>

> - Once the ATM Switches are discovered, start Web NMS Client and choose the Provisioning node from the tree view.
> - Select the ATM_Virtual_Connection template from the RHS panel and invoke the same to provision the end-to-end connection.

Sample Output