Skip Headers
Oracle® Communications IP Service Activator User's Guide
Release 7.2
E35290-01
Go to Documentation Home
Home		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
PDF · Mobi · ePub

7 Checking Device Status and Capabilities

This chapter describes how to:

Viewing the Status of a Device or Interface

While a device is managed by Oracle Communications IP Service Activator, the proxy agent polls it regularly to check that it is still running. A device's status, as reported in the IP Service Activator client, may change as a result of polling. For example, if a device fails, its status is changed to Unreachable. The device is still polled and will be reset when it recovers. If the problem fails to reset, however, or if a critical fault is raised on a device, the status is changed to Intervention Required until the problem is resolved.

Figure 7-1 shows the range of device states and the transitions between them.

Note that initial discovery of a device may be by any of the following routes:

  • Discovering or creating the device through the client. See "Running Device Discovery" for information.

  • Discovering or creating the device via the OSS Integration Manager (OIM) – see IP Service Activator OSS Integration Manager Guide.

You can check the status of the devices and interfaces within a domain by viewing the topology map in status context. Every device and interface state is represented by a display color in the map.

See "How Objects are Represented" for more information.

Figure 7-1 Device States and Transitions

Description of Figure 7-1 follows
Description of "Figure 7-1 Device States and Transitions"

To access a device or interface's properties dialog box:

  1. Right-click the object, either on the network map or Topology tab, and select Properties.

If the selected object is a device or an interface, the information displayed in the Capabilities property page is particularly important. It summarizes the support that the client provides for QoS mechanisms, VPN capabilities, policy rules and SLA monitoring. You should be aware of these capabilities when planning services and policies. See "Checking Capabilities" for more information about interface capabilities.

Viewing a List of Interfaces on a Device

You can list the interfaces that are available on a device by double-clicking the device in the Hierarchy pane. IP Service Activator lists the selected device's interfaces in the Details pane.

You can also list a device's interfaces on the Interfaces property page on the Device dialog box.

For each interface on the device, the Interfaces property page displays the information in Table 7-1.

Table 7-1 Interfaces Property page

Information Displayed Description

Description

A description of the connection. This is the SNMP ifDescription parameter.

Number

The number of the interface.

IP Address

IP address of the interface. (If the interface has multiple IP addresses, this is the first address.) The IP Address field accommodates both IPv4 and IPv6 addresses.

State

Status of the interface (Up, Down, Shutdown or Unknown). For virtual interfaces, the state is always Unknown.

Type

The type of interface, such as Ethernet, point-to-point. This is the SNMP ifType parameter.

Role As

The policy role assigned to this interface, such as Core, Local, Access, None or Disabled.

Note:

Double-clicking on an interface in the Description column opens the properties dialog box for that interface.

Checking Capabilities

IP Service Activator displays information about the capabilities of devices, interfaces, sub-interfaces, and VC endpoints. Being aware of each device and interface's capabilities is an important factor in developing and applying policies and services because they indicate the VPN service, policy, and measurement types that are supported. In addition, if capabilities are not known, rules, PHB groups, and some measurement types cannot be applied to that network component.

Capabilities are obtained as part of the device discovery process. However, if IP Service Activator is unable to obtain the capabilities, for example because the device's security settings are incorrect, you can request the capabilities later.

IP Service Activator derives interface and sub-interface capabilities from the device's operating system, device type, and interface name. VC endpoint capabilities also take account of the interface type.

IP Service Activator stores capability details for devices, interfaces, sub-interfaces, and VC endpoints.

Device-level Capability Categories

A device may have any of the following capabilities:

  • SAA support: indicates the maximum number of SAA probes (operations) supported and which SAA operations are supported – ICMP Echo, UDP Echo, Jitter or TCP Connect

  • NetFlow support: indicates in which versions of UDP format NetFlow data may be exported from the device – Version 1, Version 5 or Version 8

These capabilities are listed on the Capabilities property page of the device's properties dialog box.

If the words ’Capabilities not obtained' are displayed on this page, IP Service Activator has not obtained the relevant information from the device. This may be because IP Service Activator could not communicate with the device, because the security parameters are incorrect (for Cisco devices) or because the device's operating system is not supported.

Interface-level Capability Categories

An interface, sub-interface, or VC endpoint may have any of the following capabilities:

  • Access: indicates that you can implement access rules.

  • ATM: indicates that you can implement PHB groups using the ATM mechanism.

  • CCC: indicates support for CCCs (Circuit Cross Connects).

  • Class-based queuing: indicates support for CB-WFQ.

  • Classification: indicates that you can implement classification rules.

  • FRTS: indicates that you can implement PHB groups using the Frame Relay Traffic Shaping mechanism.

  • Martini: indicates support for Layer 2 Martini VPNs

  • MQC: indicates support for Modular QoS CLI on Cisco devices.

  • Policing: indicates that you can implement policing rules.

  • Priority Queuing: indicates that you can implement PHB groups using the Priority Queuing mechanism.

  • Rate Limiting: indicates that you can implement PHB groups using rate limiting.

  • Virtual Circuits: indicates a Frame Relay or ATM VC.

  • VPN: indicates that this interface supports VPNs.

  • WFQ: indicates that you can implement PHB groups using the WFQ queuing mechanism.

  • WRED: indicates that you can implement PHB groups using the WRED queuing mechanism.

  • WRR: indicates that you can implement PHB groups using the WRR queuing mechanism.

These capabilities are listed on the Capabilities property page of the Interface dialog box.

If the words ’Capabilities not obtained' are displayed on this page, IP Service Activator has not obtained the relevant information from the device. This may be because IP Service Activator could not communicate with the device, because the security parameters are incorrect (for Cisco devices) or because the device's operating system is not supported.

If no text is displayed in a field, it indicates that the interface does not support any IP Service Activator features or the device or interface are not supported. If the device or interface are not supported, an error message is displayed in the current faults pane.

You can find out more detailed information about most of the capabilities listed on the Capabilities property page by double-clicking on the icon next to the capability. The details are displayed beneath the capability.

The details displayed vary depending on the capability type. The ways in which the interface can identify and classify traffic is specified for rule and queuing capabilities, while for queuing mechanisms, the number of queues that can be handled by the interface is specified.

Refetching Device Capabilities

If IP Service Activator is unable to discover capabilities during the discovery process – for example, because the device's security settings are incorrect – you can request the capabilities at a later point.

In addition, if the device capabilities have changed – for example, as a result of an operating system upgrade – you can refresh capabilities by resetting and remanaging the device.

Note:

Changes made to the capabilities files do not take effect in the system until the fast start process has completed. Erratic behavior might occur if there is any attempt to re-fetch capabilities while the proxy agent and/or device driver is in the start-up process. Wait until the message Driver is up and running appears in the Current Faults Pane before rediscovering capabilities.

Although the network processor does not include a fast-start process, you must wait for startup to complete before re-fetching capabilities. Network processor start is indicated in an information message in the Current Faults Pane.

To discover unknown device capabilities:

  1. From the Discover menu, select Discovery.

    The Discovery dialog box opens.

  2. Select Fetch Capabilities from the Discovery Type drop-down.

  3. Click OK or Apply.

IP Service Activator attempts to discover capabilities for all devices that have not had capabilities returned. It does not rediscover capabilities where they have already been reported.

To update previously found device capabilities:

  1. Unmanage the device ensuring IP Service Activator configuration is left on the device:

    1. Open the device's property pages and select the Management property page.

    2. Ensure that Inherit System Action is set to Leave.

    3. Click the Unmanage button.

    4. Click OK to close the dialog box.

    5. Commit the transaction.

  2. Reset the device capabilities:

    1. Open the device's properties dialog box and select the Discovery property page.

    2. Click on the Reset Device Capabilities button.

    3. Click OK.

    4. Commit the transaction.

  3. Fetch the updated capabilities:

    1. From the Discovery menu, select Discover.

      The Topology Discovery dialog box opens.

    2. In the Discovery Type field, select Fetch Capabilities.

    3. Click OK.

    4. Commit the transaction.

  4. Remanage the device:

    1. Open the device's properties dialog box and select the Management property page.

    2. Click the Manage button.

    3. Click OK.

    4. Commit the transaction.

Modifying Device/Interface Capabilities

You can modify the interface capabilities of devices configured by a specific cartridge unit by modifying the capabilities file registered to that cartridge unit. For more information, see the cartridge guide that applies to your IP Service Activator installation.

Note:

You can modify the device and interface capabilities only for devices configured by a network processor cartridge.

The MIPSA_registry.xml file lists information about the cartridge units in a vendor-specific cartridge family. It names the cartridge unit name, driver type, device type, OS type, some service model/device model/CLI transforms, and the applicable capabilities file. A sample entry follows:

<!-- Cisco 3640 devices with IOS 12.2(8)T4 -->

<cartridgeUnit>

    <name>com.metasolv.serviceactivator.cartridges.cisco.units.cu1.3640.         12.2(8)T4</name>

    <driverType>cisco</driverType>

    <deviceType>Cisco 3640</deviceType>

    <osRegex>.*12\.2\(8\)T4.*</osRegex>

    <smToDmQuery>com/metasolv/serviceactivator/cartridges/cisco/units/cu1/         sm2dm.xq</smToDmQuery>

    <dmValidation>com/metasolv/serviceactivator/cartridges/cisco/units/cu1/         dmValidation.xq</dmValidation>

    <dmToCliQuery>com/metasolv/serviceactivator/cartridges/cisco/units/cu1/         annotatedDm2Cli.xq</dmToCliQuery>

    <capabilities>com/metasolv/serviceactivator/cartridges/cisco/capabilities/         cisco_3640_12.xml</capabilities>

</cartridgeUnit>



In the above sample, MIPSA_registry.xml defines a cartridge unit used to configure Cisco 3640 devices running the 12.2(8)T4 IOS. It names the capabilities file cisco_3640_12.xml.


Each capabilities file consists of sections, including the following:


    

  • 

    device capabilities
    

    • 

  • 

    interface capabilities, inbound and outbound sections
    

    • 

  • 

    sub-interface capabilities, inbound and outbound sections
    

    • 

  • 

    virtual circuit capabilities, inbound and outbound sections
    

    • 



In file cisco_3640_12.xml, for example, you can reference the enumerated types listed in Table 7-2 to add Classification and Marking capabilities on interfaces:




Table 7-2 Enumerated Types Referenced in cisco_3640_12.xml








Enumerated Types
Description








SRC_IP




Source IP address








DST_IP




Destination IP address








SRC_PORT




Source port








DST_PORT




Destination port








IP_PROTO




Internet Protocol








DIFFSERV




Differentiated Services








IPv4PRECEDENCE




IP version 4 precedence bits








IPv4TOS




IP version 4 type-of-service byte (octet)








URL




Universal Resource Locator








MIME




Multipurpose Internet Mail Extensions








APP_PROTO




Application protocol








APP_NAME




Application name








DOMAIN_NAME




Domain name








IEEE_802_1_PBITS




IEEE 802.1P priority field








MPLS_EXP




Multi-Protocol Label Switching experimental value








MPLS_EXP




Multi-Protocol Label Switching experimental value








FR_DE




Frame Relay discard eligibility bit








ATM_CLP




Asynchronous Transfer Mode cell loss priority bit








CLASS_MAP




Class map








MATCH_ANY




Match any








ALCATEL_INTERNAL_QUEUE




Alcatel internal queue








TCP_HEADER_OPTIONS




Transmission Control Protocol header options








EXCLUDE_CLASSIFICATION




Exclude classification













Code Sample


Sample code excerpts follow. (Entries removed are implied by three stacked periods, for the sake of brevity.)


<caps:capabilities xmlns:caps="http://www.metasolv.com/serviceactivator/capabilities"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <caps:device>
  ...
    <caps:ipsec_support>
      <caps:esp_algorithms_supported>0</caps:esp_algorithms_supported>
      <caps:ah_algorithms_supported>0</caps:ah_algorithms_supported>
      <caps:compression_algorithms_supported>0</caps:compression_algorithms_supported>
      <caps:ipsec_modes_supported>0</caps:ipsec_modes_supported>
    </caps:ipsec_support>
    ...
  </caps:device>
  <caps:interface>
    <caps:ifType>32</caps:ifType>
    <caps:inbound>
      ...
      <caps:service_rule_support>
        <caps:rules_supported>0</caps:rules_supported>
        <caps:mark_codepoints_supported/>
        <caps:limits_supported>0</caps:limits_supported>
        <caps:guarantees_supported>0</caps:guarantees_supported>
        <caps:limits_and_guarantees_supported>0</caps:limits_and_guarantees_supported>
        <caps:classification_supported/>
      </caps:service_rule_support>
      <caps:policing_rule_support>
        <caps:policing_supported>7</caps:policing_supported>
        <caps:classification_supported>
          <caps:supported>SRC_IP</caps:supported>
          <caps:supported>DST_IP</caps:supported>
          <caps:supported>SRC_PORT</caps:supported>
          <caps:supported>DST_PORT</caps:supported>
          <caps:supported>IP_PROTO</caps:supported>
          <caps:supported>APP_PROTO</caps:supported>
        </caps:classification_supported>
        <caps:classification_queues_supported>7</caps:classification_queues_supported>
        <caps:mark_codepoints_supported>
          <caps:supported>SRC_IP</caps:supported>
          <caps:supported>DST_IP</caps:supported>
          <caps:supported>SRC_PORT</caps:supported>
        </caps:mark_codepoints_supported>
      </caps:policing_rule_support>
      ...
    </caps:inbound>
    <caps:outbound>
      ...
      <caps:service_rule_support>
        <caps:rules_supported>0</caps:rules_supported>
        <caps:mark_codepoints_supported/>
        <caps:limits_supported>0</caps:limits_supported>
        <caps:guarantees_supported>0</caps:guarantees_supported>
        <caps:limits_and_guarantees_supported>0</caps:limits_and_guarantees_supported>
        <caps:classification_supported/>
      </caps:service_rule_support>
      <caps:policing_rule_support>
        <caps:policing_supported>7</caps:policing_supported>
        <caps:classification_supported>
          <caps:supported>SRC_IP</caps:supported>
          <caps:supported>DST_IP</caps:supported>
          <caps:supported>SRC_PORT</caps:supported>
          <caps:supported>DST_PORT</caps:supported>
          <caps:supported>IP_PROTO</caps:supported>
          <caps:supported>APP_PROTO</caps:supported>
        </caps:classification_supported>
        <caps:classification_queues_supported>7</caps:classification_queues_supported>
        <caps:mark_codepoints_supported>
          <caps:supported>SRC_IP</caps:supported>
          <caps:supported>DST_IP</caps:supported>
          <caps:supported>SRC_PORT</caps:supported>
        </caps:mark_codepoints_supported>
      </caps:policing_rule_support>
      ...
    </caps:outbound>
    <caps:subInterface>
      <caps:inbound>
      ...
      </caps:inbound>
      <caps:outbound>
      ...
      </caps:outbound>
    </caps:subInterface>
  </caps:interface>
</caps:capabilities>


























Go to previous page

Previous		
Go to next page

Next		











Go to Documentation Home

Home		
Go to Table of Contents

Contents		
Go to Feedback page

Contact Us