To allow more flexibility in matching the customer’s IP interface data to actual IP topology, the XD Topology Adapter provides for an interface lookup script. This is an ASL script to allow a customer or professional services to develop custom rules for locating interface objects by, for example, looking up an interface based on the interface DisplayName.

This script is executed by adding the -DAMHookScript=<script.asl> parameter in the command invoking the adapter. The XD topology adapter passes a table to the IP interface lookup script, <script.asl>. The IP interface lookup script may put data back into the table to point to the matching interface. The table contains keys with the value <aRouter>|<aRouterIf>|<zRouter>|<zRouterIf>. The script uses these values to find the actual interface instance in the IP topology. When this instance is found, new values are inserted into the table in the same format: <newARouter>|<newARouterIf>|<newZRouter>|<newZRouterIf>.

The following example will show how the interface lookup script might work.

The customer’s provisioning system data contains the interface DisplayName field instead of the instance name field. In this example, the customer’s cross-domain data contains interface DisplayNames Se1.0 for router1 and Se2.0 for router2 while the actual interface instance names are IF-router1/2 and IF-router2/5. The standard, built-in XD Manager lookup tries to use the interface DisplayName data to match the interface instance name in the topology. When the match is not found, the corresponding record is not processed.

Alternatively, the -DAMHookScript=rules/icxd-ao/otm-ip-if-hook.asl parameter is used to invoke the interface lookup script. The existing sample otm-ip-if-hook.asl script, provides a complete example for lookup based on matching the DisplayName field of interfaces on the specified Router (or Switch). Simple modifications may be made to this script to change lookup to a different field in an interface. Use sm_edit to edit the otm-ip-if-hook.asl file. (For information on using the sm_edit utility, see Appendix B, “Understanding the sm_edit Utility,”)

The FIND_ROUTER_IF rule looks like this:

// Sample find logic to match the interface by the interface
// display name.
FIND_ROUTER_IF(router_name, if_name) do {
  if (router_obj->isNull()) {
  if (!router_obj->isNull()) {
     foreach interface (router_obj->ComposedOf) {
        if_obj = object(interface);
        if (if_obj->isInstanceOf("ICIM_NetworkAdapter")) {
           disp_name = if_obj->DisplayName;      
           logDebug("Checking if: ".if_name." ".disp_name);
           if (if_name == disp_name) {
              logDebug("Found if: ".if_name." ".disp_name);
              return if_obj;
  return object();

The script iterates through all interface instances in router1 to look for an interface with the DisplayName of Se1.0 and through all interface instances in router2 to look for an interface with the DisplayName of Se2.0. Once these are found, the lookup script table is updated to indicate that the Se1.0 interface is actually named IF-router1/2 and Se2.0 is actually named IF-router2/5. Then subsequent XD logic easily locates the correct interface and can process the XD entry.

The rule FIND_ROUTER_IF may be customized easily to change the logic to compare the data to the Description field of an interface instead, for example.

If you decide to create a new script instead of editing the existing one, the logic must follow the conventions of the sample, in that the script is passed a table with keys. The result table must be populated with the instance names of the interface objects, as explained above.