Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Search for | Example | Results |
---|---|---|
A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Search for | Operator | Example |
---|---|---|
Two or more words in the same topic |
|
|
Either word in a topic |
|
|
Topics that do not contain a specific word or phrase |
|
|
Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
A combination of search types | ( ) parentheses |
|
- Layer2 Discovery
- Overview
- Supported Devices
- How to Discover Layer2 Objects
- How to Discover Layer2 Connections Using Saved Files
- How to Discover Layer2 Connections Using CDP or LLDP MIB
- How to Discover Layer2 Topology by Shell
- Layer2 Topology Bridge-based by SNMP Job
- Layer2 Topology by Shell Job
- Layer2 Topology CDP-LLDP based by SNMP Job
- Layer2 Topology VLAN-based by SNMP Job
- Process Layer2 Saved Files Job
- Merge VLANs by Ports Job
- Report Linux with Duplicated MAC Layer2 Job
- VLAN ports by SNMP Job
- VLANs by SNMP Job
- L2 Bridge by SNMP Adapter
- Layer2 Topology by Shell Adapter
- CDP/LLDP Neighbors Layer 2 Devices by SNMP Adapter
- L2 VLAN by SNMP Adapter
- Merge VLANs Adapter
- Process Layer2 Collected Files Adapter
- VMS Catalyst by SNMP Adapter
- Catalyst Vlans by SNMP Adapter
- Relationships
- Layer2 Discovery Flow
- Layer2 Discovery Troubleshooting and Limitations
Layer2 Discovery Troubleshooting and Limitations
This section describes troubleshooting and limitations for Layer2 discovery.
-
If the results of the discovery return empty, verify that you have access to the discovered SNMP agent (or to the SNMP agent using the special community authentication) and that all the requested MIB tables are responding to SNMP requests from the Data Flow Probe machine. For details on the MIB tables, refer to the appropriate script.
-
In cases where the reported bridge MAC address is
000000000000
, "", ornull
, the adapter does not report results. -
If the retrieved basic bridge MAC (retrieved from the
1.3.6.1.2.1.17.1.1
table) is not the same as the givenbridgeId
in the destination data, the adapter returns zero results.
In the case of SNMP_Dis_L2_Bridge,bridgeId
is set by bridge_basemacaddr.
In the case of SNMP_Dis_L2_VLAN,bridgeId
is set byvlan_bridgemac
.
Layer2 Discovery Troubleshooting
In general, the following types of issues might occur in the Layer2 discovery:
Most of Layer2 discovery jobs are SNMP-based, you must meet the following conditions to perform the actual discovery:
- Device must support the used Management Information Bases (MIBs).
- Discovery user (or community if talking about SNMP v1-v2) must have read permission for the required Object Identifiers (OIDs). The list of used OIDs is specified in the Required Permissions section of the corresponding adapter and in the HPE Universal CMDB Discovery and Integration Content Permissions.
To identify whether you deal with a permission issue, you should examine the communication log and check the fetched results. If SNMP does not clearly state that you are not allowed to get some data, and it returns nothing or claims that "required OID doesn't exist", it is strongly recommended that you use the snmpwalk tool to manually check if the data is reachable.
-
Problem: The Layer2 Topology VLAN-based by SNMP job is missing triggers for a particular switch.
Cause: The VLANs by SNMP or VLAN ports by SNMP job fails to consistently run against the Switch.
Solution:
- Check the corresponding communication logs if the permissions are set correctly.
- If that is SNMPv3, the Content Pack version is prior to CP17, and those are Cisco devices, it is a limitation because "
snmp v3 vlan context handling in CISCO style
" is not supported. This issue is solved in CP17. - On some SNMP agents, there is a bug for SNMPv2 for "Community Postfix" and interface state related MIB, the relevant requests will return nothing even though the permissions are set correctly. This issue can be solved by the agent upgrade.
-
Problem: The Layer2 Topology VLAN-based by SNMP or Layer2 Topology Bridge-based by SNMP job has run but no Switch-to-Switch relationships are present.
Solution: Run the Process Layer2 Saved Files job.
-
Problem: Some particular switch port is connected to a server or another switch but the required Layer2 Connection CI is not there in UCMDB.
Solution:
- If talking about the Layer2 Topology CDP-LLDP based by SNMP job, you can simply check the communication logs and find out what data is fetched for the problematic port.
-
If this is the default flow, do the following:
-
Prerequisites – the following information is required:
- Switch Interface MAC address
- Switch Interface VLAN if any
- Which Data Flow Probe has performed the discovery and has access to its File System
- Go to the Data Flow Probe File System and locate the l2process folder.
-
Search the file context using the OS native search to look for the files coating the specific MAC address (file names should be in hexadecimal format without extensions)
-
Among the found files, pick up the one whose first line looks like the following:
<The MAC address that you look for >:::<Interface Name>:::<digits>:::<digits>:::<digits>:::<digits>:::<digits>:::<Name>:::<Your VLAN ID or None>
This file contains the interface data in the first line, and the ARP cache for the interface in the specific VLAN.
-
Check how many MAC addresses are present in the second line and if the server side MAC address is present there. As a rule, the referenced MAC address is present but along with other MAC addresses, which prevents the job from creating a Layer2 relationship because it is considered to be a Switch-to-Switch relationship.
-
If the second attached device is also a switch, you must repeat the above-mentioned steps to find the file for that interface. In case of the Switch-to-Switch relationship, the issue might appear only if those switches and the relevant topology are discovered by different Data Flow Probes. Therefore, the Process Layer2 Saved Files job does not simply have all the required information in one place.
To fix this issue, copy the content of the l2process directory to a single Data Flow Probe and run the Process Layer2 Saved Files job. Such copy must be done on a scheduler basis. This is the limitation of this Flow.
-
If the second attached device is a server, it means that one of the following happens:
-
There is some other network device in the middle that is not discovered.
Solution: Find out what it is and discover it if possible.
- The remote box is some kind of virtualization solution box, such as X-Frame, or VMware ESX Server. The default flow does not support the virtualization solution hardware boxes. This is a limitation.
-
In addition to the real MAC address, some virtual ones are visible from that server. It might happen for some Microsoft based Cluster heartbeat virtual interfaces.
Solution: Filter out the virtual MAC address to keep only one physical MAC address present.
-
-
Problem: Layer2 Connection CI is reported but the following reconciliation error occurs "CIs were ignored due to Multiple Match ...
".
Cause: This issue occurs if UCMDB fails to properly identify one of the reported nodes. Most often, this issue occurs when the Layer2 Topology VLAN-based by SNMP job runs. The fact is that the only thing that is known about the remote server is the MAC address, which means that if there are more than one interface with such a MAC address in UCMDB, the reported Layer2 topology will fail to reconcile.
Possible Solution: Run the Report Linux with Duplicated MAC Layer2 job if the "remote" server is Linux and it is discovered. Another option to get the ignored relationship back is to run the Build Layer 2 CIs using PortNextMAC enrichment rule, which will report the same topology but based on CI IDs thus solving the reconciliation problem.