Network Device latency Report

Network latency isn't a metric that just exists that can be pulled into LM. It has to be actively measured, then it can be pulled into LM. Your decision about how to actively measure latency will determine how you create a report.

You need to make sure that those who are receiving the report understand the measurement's source and destination. This is latency may not be between two points of the infrastructure, rather it could be latency between the collector and the target in the infrastructure. The collector can change, if you have an ABCG or a failover defined. 

You say report, but you might mean dashboard. If you do, reply here and we can guide you through building a dashboard.

Method 1: Ping - this measures the latency between the collector and the device that is being monitored. This should be active for every device you're monitoring in LM, so it should be readily available. You should just build a Resource Metric Trend report using the Ping DataSource, "average" datapoint (which is in ms).

Method 2: IPSLA - this is my preferred way, which is why I mention it. You would need to strategize about the segments of your network across which you'd like to measure latency. You define IPSLA operations to cover those segments and LM pulls that data in. This is often more meaningful because it's measuring actual latency across your network instead of latency to something on the side (the collector). Once you have that data pulled into LM, you'd build a Resource Metric Trend report using the "Cisco SLA ICMP Echo-" DataSource with the RTTTime datapoint. This assumes you've setup the IPSLA operations to be ICMP Echo operations. There's also a DataSource for http, icmp jitter, jitter, and udpecho. They're not as fully fledged as other monitoring tool's IPSLA monitoring capabilities, but they get the job done.