This article discusses how UDT conducts context-based polling against routers and switches for VLAN-based endpoints at a layer 2 level, and IP-based information from ARP entries on a configured VRF at a layer 3 level.
UDT 2 and later
Standard UDT-based polling gathers information for endpoints (both MAC and IP) through the SNMP polling of Bridge MIB based OIDs located (STUB LINK).
However, standard OID polling for that information is not applicable to endpoints that are on a VLAN or a VRF. For this, UDT uses a context SNMP request against a device to gather information specifically for those VLANs and VRFs. This method allows for it to gather information specific to only a particular VLAN or VRF from a device that a standard poll will not grab.
For SNMPv2, this is conducted by adding the context at the end of the community. For example, when attempting to query a device using a community of public against the OID of 1.3.6, it will return standard information for all of the OIDs present in that directory. However, if you add the VLAN or VRF at the end of the community, public@103 for example, then the walk or application is specifically asking just for information on those OIDs relevant to that VLAN/VRF.
For SNMPv3, it works similarly with SNMPv2 but not through a community. The following shows the actual context method available in the walk:
Refer to SNMPv3 Bridge-MIB commands need to be added to Cisco devices to set up the ability to allow context polling in SNMPv3.
With context polling, UDT will then attempt to poll for all the VLAN and VRF data for the endpoint information located on ports attached to a VLAN. This context polling is conducted on 5 OIDs: 3 specific to Layer 2, 2 specific to Layer 3.
Using the UDT Compatibility Checker tool, you can see the results of this context polling:
In some cases however, gathering VLAN information is not possible. Refer to the following for similar scenarios: