As both @Flavio Miranda and @Ramblin Tech basically implied, it can be next to impossible without someone doing a visual inspection (no one at said datacenter capable of doing this and/or that you trust?), especially, as Jim mentions, if the interloping device truly wants to conceal itself.
Laugh - in one part of the network I was maintaining, I had a fiber link, where one side had SX optics and the other side LX optics! Huh???
Turned out there was an optical switch in between. Unknown to me, at the time, our company also maintained, in some portions of it, its own optical network. (Don't know how much you know about optical networks, but they deal with passing "light" about.) Point is, except for this clue, i.e. different optical transceivers on either end of "link", although there was an optical network between my sites, it was "invisible".
Oh, love Jim's suggestion of using TDR (for copper).
Regarding pulling a fiber connection, and see what happens on other side, reminds me, initially we found our fiber "p2p links" running across an optical network, didn't physically drop our interface when there was a drop in the transit optical network. I.e. we had to wait on timers, on devices, to detect lost loss of connectivity. Then, we found out, if we reminded the optical team, they could configure their equipment to "drop" our end connections if they did have an end-to-end path break (they might also have redundancy in paths, so logically, you didn't lose end-to-end connectivity, although latency might change). So, as Jim described, an optical loss of signal might not be fool proof either.
BTW, cannot say about ASAs, but overrun ingress errors, on Cisco routers, usually are due to the device cannot process the ingress at the rate it's being delivered.
This might be caused by two reasons. Physically, the device cannot physically keep up with the ingress rate by moving received frames out of the hardware receive buffer fast enough. This is unusual. Or, physically, the device cannot physically "process" received frames at the ingress rate, so it doesn't bother to clear them from the ingress queue/buffers. This is a subtle difference.
In the former, the platform is just incapable of physically dealing with the ingress rate
In the latter, much depends on what the ingress traffic contains, and the "work" needed to processed the received traffic.
Simple example, if an ingress interface has an ACL with 10,000 ACEs. In one case, all traffic gets a match on the 1st ACE, in another case, all traffic hits the final ACE. On many software based routers, same traffic, same ACL, but which ACE gets matched, may significantly impact throughput capacity.
So, is this problem recent? Any change to FW rule set? Any change to what rules traffic mix is hitting on now vs. "before"?
