The tpmgr-param.conf file also contains other interface-limiting parameter types, most of which are listed in Other interface-limiting parameter types. The table includes an example, the default value, and the definition of each parameter type. Several parameter types in Other interface-limiting parameter types are interface-matching filters that are also based on the ifIndex, ifDescr, and ifType objects. However, they have slightly different interface-matching pattern names and employ slightly different syntax than the standard interface-matching filters previously discussed.

Table 1. Other interface-limiting parameter types

Parameter type

Default value

Definition

IFTypePatternIFExt<sysObjectID> <interface type pattern>

Example (in tpmgr-param.conf file):

  • IFTypePatternIFExt.1.3.6.1.4.1.119.1.3.13.4 39|53|1

    where:

    sysObjectID is the NEC Bluefire 5003 Switch; and Interface types are 39 => sonet, 53 => ds3, and 1 => other (generic).

    For any discovered device that matches the sysObjectID, the filter will override the 30|37|134 default interface type pattern with 39|53|1. Only the interfaces that have an ifType value of 39, 53, or 1 will be created.

30|37|134

A filter that restricts the creation of interfaces (ports) for a specific device based on a specific interface type pattern.

The IFTypePatternIFExt filter, as well as the IFDescrPatternIFExt and IFIndexPatternIFExt filters, apply to some of the first Cisco, Fore, Huawei, NEC, and Riverstone devices that were certified for the IP Manager. The default values for these filters are:

  • IFIndexPatternIFExt defaults to ~*

  • IFDescrPatternIFExt defaults to ~*

  • IFTypePatternIFExt defaults to 30|37|134

IFTypePattern-SwitchPort[sysObjectID] <interface type pattern>

Example (in tpmgr-param.conf file):

  • IFTypePattern-SwitchPort.1.3.6.1.4.1.119.1.14.8 37

    where:

    sysObjectID is the NEC Bluefire 8000 series 2.5G ATM Switch; and Interface type is 37 => atm.

    For any discovered device that matches the sysObjectID, the filter will override the 6|26|62|69|117 default interface type pattern: Only the interfaces that have an ifType value of 37 will be created.

6|26|62|69|117

A filter that restricts the creation of interfaces (ports) for a specific device based on a specific interface type pattern.

The IFTypePattern-SwitchPort filter, as well as the IFDescrPattern-SwitchPort and the IFIndexPattern-SwitchPort filters, apply to some of the first Cisco, NEC, and Lucent devices that were certified for the IP Manager. The default values for these filters are:

  • IFIndexPattern-SwitchPort defaults to ~*

  • IFDescrPattern-SwitchPort defaults to ~*

  • IFTypePattern-SwitchPort defaults to 6|26|62|69|117

IFDescrPattern-SwitchPort[sysObjectID] <interface description      pattern>

Example (commented out in tpmgr-param.conf file):

  • #IFDescrPattern-SwitchPort.1.3.6.1.4.1.9.1.501 Vlan888

    where:

    sysObjectID is the Cisco C4507-with-Sup Switch.

    For any discovered device that matches the sysObjectID, the filter will override the ~* default interface description pattern: Only the interfaces that contain Vlan888 in their ifDescr descriptions will be created.

~*

A filter that restricts the creation of interfaces (ports) for a specific device based on a specific interface description pattern.

When this filter is used, the associated IFTypePattern-SwitchPort filter is typically set to “~*”.

CiscoStackWithATM-Pattern <sysObjectID1>|<sysObjectID2>|     <sysObjectIDn>

Example (in tpmgr-param.conf file):

  • CiscoStackWithATM-Pattern      .1.3.6.1.4.1.9.5.7|.1.3.6.1.4.1.9.5.17|.1.3.6.1.4.1.9.5.34

    where:

    sysObjectID1 is the Cisco Catalyst WS-C5000 Switch; sysObjectID2 is the Cisco 5500 Switch; and sysObjectID3 is the Cisco Catalyst 5505 Switch.

    For any discovered ATM switch that matches any of these sysObjectIDs, ATM peer connections will be created between the ATM switch ports and the ports on the neighboring ATM switches.

.1.3.6.1.4.1.9.5.7,

.1.3.6.1.4.1.9.5.17,

.1.3.6.1.4.1.9.5.34

Identifies which devices are ATM switches so that ATM peer connections are created between the ATM switch ports and the ports on the neighboring ATM switches.

Layer3SwitchPattern <sysObjectID1>|<sysObjectID2>|      <sysObjectID3>|<sysObjectIDn>

Example (in tpmgr-param.conf file):

  • Layer3SwitchPattern      .1.3.6.1.4.1.9.1.400|.1.3.6.1.4.1.9.5.44|          .1.3.6.1.4.1.4641.1.*|.1.3.6.1.4.1.5567.1.1.*

    where:

    sysObjectID1 is the Cisco 6513 IOS Switch; sysObjectID2 is the Cisco 6509 Switch; sysObjectID3 is the Tellabs 8820 or 8860 Switch; and sysObjectID4 is the Riverstone Networks Procut Line of Multi Layer Switch Router.

    For any discovered Layer 3 device that matches any of these sysObjectIDs, WAN network connections will be created between the Layer 3 switch ports and the ports on the neighboring routers.

.1.3.6.1.4.1.9.1.400,

.1.3.6.1.4.1.9.5.44

Identifies which devices are Layer 3 switches so that WAN network connections are created between the Layer 3 switch ports and the ports on the neighboring routers.

If you comment out the default line for this parameter in the tpmgr-param.conf file, the IP Manager consults the rule set in the following file to determine how to create WAN network connections during the postprocessing phase of the discovery process:

BASEDIR/smarts/rules/discovery/ic-post-wan-link.asl

DisplayNameByIfDescr-<sysObjectID> TRUE|FALSE

Example (in tpmgr-param.conf file):

  • DisplayNameByIfDescr-.1.3.6.1.4.1.800.3.1.1.9 TRUE

    where:

    sysObjectID is the Alcatel OmniStack 6024 Switch.

    For any discovered device that matches the sysObjectID, any interface discovered without an ifName string will have its ifDescr description included in its display name.

FALSE

Controls how to name the interface of a specific device when no ifName string is discovered for the interface:

  • A value of TRUE indicates that the ifDescr description for the interface will be included in the display name for the interface.

  • A value of FALSE indicates that the DeviceID for the interface will be included in the display name for the interface. If the DeviceID is empty, the ifDescr description will be included in the display name.

    Note:

    ifName is a text string that contains the name that is used by the device to represent the interface.

    DeviceID refers to the device to which this interface belongs.

ERXIfExcludeSysPattern <name pattern>

Example (in tpmgr-param.conf file):

  • ERXIfExcludeSysPattern *

    Any discovered Juniper ERX device whose Name attribute string matches * (all discovered ERX devices will match this filter) will be subjected to the following two filters:

    ERXIfExcludeTypePattern

    ERXIfExcludeDescrPattern

*

Identifies through a name pattern filter which Juniper ERX devices are to be subjected to the following two filters:

  • ERXIfExcludeTypePattern

  • ERXIfExcludeDescrPattern

“Optimizing the discovery of ERX devices” on page 133 clarifies the use of this parameter.

Note:

The term “Juniper ERX device” or just “ERX device,” as used here, represents an instance of any discovered Juniper ERX main or virtual router.

ERXIfExcludeTypePattern <interface type pattern>

Example (in tpmgr-param.conf file):

  • ERXIfExcludeTypePattern 1|23|126|134

    where:

    Interface types are 1 => other (generic), 23 => ppp, 126 => ip, and 134 => atmSubInterface.

    For any discovered Juniper ERX device that matches the ERXIfExcludeSysPattern filter, any interface that has an ifType value other than 1, 23, 126, or 134 will be created.

1|23|126|134

A filter that restricts the creation of interfaces (ports) for the Juniper ERX devices that match the ERXIfExcludeSysPattern filter. The filtering is based on a specific interface type pattern.

Any interface type that matches the ERXIfExcludeTypePattern filter is excluded from the discovered topology, and any interface type that does not match the filter is included in the discovered topology.

“Optimizing the discovery of ERX devices” on page 133 clarifies the use of this parameter.

# ERXIfExcludeTypePattern 1|23|134

This modified pattern of the existing ERXIfExcludeTypePattern parameter enables the VRRP probe to discover IP interfaces on Juniper ERX devices that belong to a VRRP group. In cases where a VRRPGroup is configured as a member of a VRF, the ifType 126 should not be excluded. Use this pattern instead

# ERXIfExcludeTypePattern 1|23|134

1|23|134

A filter that enables the VRRP probe to discover IP interfaces on Juniper ERX devices that belong to a VRRP group.

ERXIfExcludeDescrPattern <interface description pattern>

Example (commented out in tpmgr-param.conf file):

  • #ERXIfExcludeDescrPattern      *ATM*<0-20>/<0-20>.<1800-900000>|          *LOOPBACK<200-10000>|*PPPOE*

    For any discovered Juniper ERX device that matches the ERXIfExcludeSysPattern filter, any interface that has an ifDescr description that matches any of these patterns will not be created, and any interface that has an ifDescr description that does not match any of these patterns will be created.

~*

A filter that restricts the creation of interfaces (ports) for the Juniper ERX devices that match the ERXIfExcludeSysPattern filter. The filtering is based on a specific interface description pattern.

Any interface description that matches the ERXIfExcludeDescrPattern filter is excluded from the discovered topology, and any interface description that does not match the filter is included in the discovered topology.

“Optimizing the discovery of ERX devices” on page 133 clarifies the use of this parameter.

ERXVRNonIfIPExcludeSysPattern <name pattern>

Example (commented out in tpmgr-param.conf file):

  • #ERXVRNonIfIPExcludeSysPattern *

    For any discovered Juniper ERX device whose Name attribute string matches * (all discovered ERX devices will match this filter), any IP address (discovered on the device) that is not related to interfaces will be excluded from the discovered topology.

~*

Identifies through a name pattern filter which Juniper ERX devices are to have all discovered IP addresses that are not related to interfaces excluded from the discovered topology.

IfVirtualTypePattern-<sysObjectID> <interface type pattern>

Example (commented out in tpmgr-param.conf file):

  • #ifVirtualTypePattern-.1.3.6.1.4.1.9.1.452 135|136

    where:

    sysObjectID is the Cisco WS-C3550-24Dc Switch; and Interface types are 135 => l2vlan and 136 => l3ipvlan.

    For any discovered device that matches the sysObjectID, the IP Manager will not create a “LayeredOver/Underlying” relationship between a virtual interface associated with ifType 135 or 136 and the underlying MAC address. Thus, only the “LayeredOver/Underlying” relationship between the underlying MAC address and the layered-over physical interface will exist for the MAC address.

    Accordingly, during the postprocessing phase of the discovery process, the IP Manager will create the network connection for the physical interface.

~*

For a specific device, enables the creation of a network connection for a physical interface that shares a physical MAC address with one or more virtual interfaces.

This parameter can be used for any device that has multiple interfaces (one physical and the others virtual) that share the same MAC address.

“Enabling the creation of a physical connection for a shared MAC address” on page 136 clarifies the use of this parameter.

ForceAgentAddressInListSysPattern <name pattern>

Example (in tpmgr-param.conf file):

  • ForceAgentAddressInListSysPattern *

    For any discovered device whose Name attribute string matches * (all discovered devices will match this filter), the IP address held in its SNMP agent’s AgentAddress attribute will be added to the list of IP addresses held in its SNMP agent’s AgentAddressList attribute.

*

Identifies through a name pattern filter which devices should have the IP address held in their SNMP agent’s AgentAddress attribute added to the list of IP addresses that are held in their SNMP agent’s AgentAddressList attribute.

The AgentAddress attribute holds the IP address that is used by the initial ICMP poll to reach the device, and the AgentAddressList attribute holds a list of IP addresses discovered on the device.

In general (but not always), rules are already in place that result in the AgentAddress IP being added to the AgentAddressList. The ForceAgentAddressInListSysPattern parameter provides a means to specify which devices should be forced to have their AgentAddress IP address added to their AgentAddressList.

CDPDeviceOIDs <sysObjectID1>|<sysObjectID2>|     <sysObjectIDn>

Example (in tpmgr-param.conf file):

  • CDPDeviceOIDs      ~.1.3.6.1.4.1.2467.4.*|~.1.3.6.1.4.1.9.9.368.4.*

    where:

    sysObjectID1 and sysObjectID2 together represent the Cisco CSS 11000 and 11500 Series Content Services Switches.

    For a Cisco CSS 11000 or 15000 Series Content Services Switch, no CDP connections are created for the interfaces on the switch.

    Conversely, for any discovered device other than a Cisco CSS 11000 or 15000 Series Content Services Switch, CDP connections are created for the interfaces on the switch.

(Identified in example)

Identifies which Cisco devices to which Cisco Discovery Protocol (CDP) connections should not be made.

This parameter is used to exclude network connections to Cisco devices (such as CSS 11000 and 11500 Series Content Services Switches) with a management interface.

Because CDP is used for some network management functions, any person on a directly connected segment to a Cisco CSS 11000 or 11500 series switch (for example) is able to perform CDP actions, actions that might include the gathering of sensitive information about the switch. This information could be used to design attacks against the switch.

For this reason, do not make CDP connections to Cisco devices that have a management interface.

CiscoIPPhonePattern

Cisco?IP?Phone*

Pattern to be used for omitting IP phone ports.

LinuxBondingInterfacePattern

bond*

Pattern to be used for including Linux bonded logical interfaces.

The EnableEthernetBonding parameter in the tpmgr-param.conf file must be TRUE (default) for this pattern to be used.

ERX-VRF-VRRPCommunities-Pattern

*brmgt*|*orfe*

This parameter limits the discovery of VRF interfaces on Juniper ERX devices that belong to a VRRP group to just the VRF interfaces on the ERX devices that have a community string that matches the specified pattern.

ShortDiscoveryInstrPattern

Card_Fault_CiscoONSCPU|Card_Fault_CiscoEntityFRU

Instrumentation class pattern to be included in short discovery. For cards, the pattern that is specified by “ShortDiscoveryInstrPattern” will be checked against the instrument class name of the card that is operationally down before proceeding with short discovery.

The autoReprobe_short parameter in the discovery.conf file must be TRUE for this pattern to be used.