There are several reasons for wanting to exclude device-access interfaces from the discovered topology, foremost of which is to limit the interfaces that are discovered for access devices. An access device is a network device that contains interfaces (also known as access ports) that provide connections for end users or node devices, such as routers or servers. Devices that are certified as access devices are identified in the IP Certification Matrix.

To exclude interfaces for a discovered device, create an interface-matching filters for the device and adds the filters to the tpmgr-param.conf file. The filters are based on the following interface table (ifTable) objects of the device’s MIB:

  • ifIndex

  • ifDescr

  • ifType

    The object identifier (OID) paths to these objects in the Internet-standard MIB-II are shown in OID-tree view of the MIB-II ifTable’s ifIndex, ifDescr, and IfType objects.

    Figure 1. OID-tree view of the MIB-II ifTable’s ifIndex, ifDescr, and IfType objects

    For a device that is using a private MIB, the OID paths to the ifIndex, ifDescr, and ifType objects all begin with the prefix 1.3.6.1.4.1. As shown in OID-tree view of the MIB-II ifTable’s ifIndex, ifDescr, and IfType objects, a prefix of 1.3.6.1.4.1.<number> points to the objects in an enterprise’s private MIBs.

    The following display is an example of a set of interface-matching filters that are created for a Redback SMS 1800 Router device.

    The Key part of an interface-matching filter specifies the interface pattern type (IFIndex, IFDescr, or IFType) for the device, where the device is identified by its system object identifier (sysObjectID). (The sysObjectID for a Redback SMS 1800 Router is 1.3.6.1.4.1.2352.1.3.) The Value part of an interface-matching filter specifies the interface-matching pattern for the filter’s interface pattern type.

    Any interface retrieved from the target device that matches any interface-matching pattern for any interface pattern type for the device is included in the discovered topology. Conversely, any interface retrieved from the target device that does not match any of the interface-matching patterns is excluded from the discovered topology.

    As indicated in the example, a set of interface-matching filters for a device consists of three different interface pattern types:

  • IFIndexPattern pertains to the ifIndex MIB object type.

  • IFDescrPattern pertains to the ifDescr MIB object type.

  • IFTypePattern pertains to the ifType MIB object type.

    The default value (interface-matching pattern) for IFIndexPattern is “~*”, the default value for IFDescrPattern is “~*”, and the default value for IFTypePattern is “*”. As examples:

  • IFIndexPattern-.1.3.6.1.4.1.164.6.1.3.183 ~*

  • IFDescrPattern-.1.3.6.1.4.1.164.6.1.3.183 ~*

  • IFTypePattern-.1.3.6.1.4.1.164.6.1.3.183 *

    The “*” wildcard pattern matches anything, and the “~*” wildcard pattern matches nothing because of the leading tilde. Refer “Terminology” on page 251 for more information on wildcard syntax.

    Each pattern type and its value is considered an interface-matching filter.

    The interface-matching filters for a device are inclusive, meaning that if an interface that is retrieved from the target device matches just one of the matching patterns that are specified for IFIndexPattern, IFDescrPattern, or IFTypePattern, the interface will be included in the discovered topology. So, by default, because of the “*” in the IFTypePattern, all of the interfaces that are retrieved from the target device are included in the topology.