In the "show snmp" traps are being generated, 13 of them, and you have snmp-server enable traps syslog set.
Few things you can do is add a logging ip address if one doesn't already exist or an additional address and throw up a simple syslog server and do a few things to generate traps like conf t or add a vlan and delete a vlan as you have these set to trap. If you don't to use vlans then add a loopback and shut/no shut it a few times.
Appears you are dealing with these remotely. I always open two sessions to the box. Session one, I execute "no debug all" then arrow up then switch to the other session and do term mon and then debug snmp packet. The first session is a failsafe so I can turn off debugging with hitting return if for some reason debug is taxing the box. School of remote access hard knocks.
While debug is running do conf t and exit a few times and/or add delete vlans and you will see the traps being generated and if they are pointing to the desired ip.
Should see something similar to these below.
6506E#term mon
6506E#debug snmp packet
SNMP packet debugging is on
6506E#sh run
Building configuration...
...
6506E#
19:24:18: SNMP: Queuing packet to 10.198.28.80
19:24:18: SNMP: V3 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 6981747
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.100 = 1
!--- 1 -> commandLine. Executed via CLI.
ccmHistoryEventEntry.4.100 = 3
!--- 3 -> running
ccmHistoryEventEntry.5.100 = 2
!--- 2 -> commandSource. Show command was executed.
6506E#conf t
Enter configuration commands, one per line. End with CNTL/Z.
6506E(config)#exit
22:57:37: SNMP: Queuing packet to 10.198.28.80
22:57:37: SNMP: V3 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 8261709
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.108 = 1
In our shop we only use PI for wireless management controllers and users, not switches. Third party and open source for switches. We have logging for all available traps to dual syslog servers for compliance and redundancy so I understand your frustration when traps aren't working as expected.
Also if you aren't are the latest patches in the 2.0 train I would highly recommend it. 2.0 is not the most stable from our experience until the patches are added. fwiw
Best Answer
For those interested : the problem was resolved by migrating the core network from an old C6006 to a brand-new Catalyst 6807XL. I guess the polling of ARP information was failing on the old cores. Since migrating every IP for every client has been pulled up, without changing anything to the Prime Infrastructure config.
HTH
Jeremy