SNMP – Understanding ipNetToPhysicalEntry OID Transmission

In addition to Ricky's answer, you can also use the snmptranslate utility to dump information about SNMP tables and how table entries are indexed, etc. The -Tp -IR flags will tell snmptranslate to print a tree view of the table. A very useful (and overlooked) utility IMO.

Here's the output for ipNetToPhysicalTable (which is the table object to which ipNetToPhysicalEntry belongs):

jjensen@VA1-NETOPS-DEV-01:~/.snmp$ snmptranslate -M +mibs -m +ALL -Tp -IR ipNetToPhysicalTable
+--ipNetToPhysicalTable(35)
   |
   +--ipNetToPhysicalEntry(1)
      |  Index: ipNetToPhysicalIfIndex, ipNetToPhysicalNetAddressType, ipNetToPhysicalNetAddress
      |
      +-- ---- Integer32 ipNetToPhysicalIfIndex(1)
      |        Textual Convention: InterfaceIndex
      |        Range: 1..2147483647
      +-- ---- EnumVal   ipNetToPhysicalNetAddressType(2)
      |        Textual Convention: InetAddressType
      |        Values: unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4), dns(16)
      +-- ---- String    ipNetToPhysicalNetAddress(3)
      |        Textual Convention: InetAddress
      |        Size: 0..255
      +-- CR-- String    ipNetToPhysicalPhysAddress(4)
      |        Textual Convention: PhysAddress
      |        Size: 0..65535
      +-- -R-- TimeTicks ipNetToPhysicalLastUpdated(5)
      |        Textual Convention: TimeStamp
      +-- CR-- EnumVal   ipNetToPhysicalType(6)
      |        Values: other(1), invalid(2), dynamic(3), static(4), local(5)
      +-- -R-- EnumVal   ipNetToPhysicalState(7)
      |        Values: reachable(1), stale(2), delay(3), probe(4), invalid(5), unknown(6), incomplete(7)
      +-- CR-- EnumVal   ipNetToPhysicalRowStatus(8)
               Textual Convention: RowStatus
               Values: active(1), notInService(2), notReady(3), createAndGo(4), createAndWait(5), destroy(6)

Now you can see how an entry in the table is supposed to be indexed, and also the OIDs that make up the table. The first 3 entries are the indexes. Each entry in the table is going to have these 3 indexes - essentially ipNetToPhysicalIfIndex + ipNetToPhysicalNetAddressType + ipNetToPhysicalNetAddress. Then subsequently there are 5 "columns" in a row of this table:

1. ipNetToPhysicalPhysAddress
2. ipNetToPhysicalLastUpdated
3. ipNetToPhysicalType
4. ipNetToPhysicalState
5. ipNetToPhysicalRowStatus

Here's an example from one of my devices:

IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."10.200.17.34" = STRING: 74:8e:f8:62:59:41

So think of this like a row entry in the table, and we've picked out column 1 from the row, which is ipNetToPhysicalPhysAddress. So in this particular entry, the .1.ipv4."10.200.17.34" part is the index of the entry. The 1 is the ifIndex of the interface that the ARP entry is learned on, 'ipv4' is the ipNetToPhysicalNetAddressType which is one of these: unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4), dns(16) and finally, the IP address of the ARP entry, 10.200.17.34. These three things make up the index for that entry. Then the value for ipNetToPhysicalPhysAddress at that specific index is the MAC address 748e.f862.5941.

but when i read this OID over, lets say snmpwalk, i don´t get everything whats inside my Routers Neighbor Cache and ARP Cache.

This could very well be an issue with the SNMP implementation of your device (which you've given us zero information about by the way). It would be useful if you could edit your original question to include this information, as well as output from snmpbulkwalk against the ipNetToPhysicalTable table. Also, you could try doing an snmpbulkwalk against ipv6NetToMediaTable to see if you get results from that.