It has the capability of listening a handful of ports (16992 and 16993, to be specific) on an IP address it shares with the operating system. (either by snooping DHCP requests or issuing its own; I'm not sure, but either way it uses a shared MAC address in this mode)
I have it running on a separate IP address, because I'm worried about one potential use case: how does AMT prevent the host network stack from conflicting with it?
In other words, the Intel management software is now listening [at least] two TCP ports, out-of-band and without the operating system's knowledge. Let's say I initiate a TCP connection to a remote host, and the host stack chooses 16992 or 16993 as the local port to listen on [for packets coming back to the box].
Won't packets returning from the remote host get "blackholed" and never reach the OS? Or is there some preventative measure, like an Intel driver in the Linux kernel knowing that TCP should avoid port 16992? (seems unlikely since this is an OS-agnostic feature.) Or maybe the management interface can forward traffic sent to port 16992 that doesn't belong to a known management session back to the host stack?
Either way, I'm reluctant to use this for network-intensive loads until I understand how this works. I searched the Intel documentation and couldn't find anything there either.
I suppose this could be tested by initiating around 30,000 TCP connections, and checking if connectivity works even if the port overlaps. But I haven't had a chance to do that yet.
(Footnote: I realize this question is similar to How does an Intel vPro based computer maintain IP connectivity?, but that questions addresses connectivity in general, not connectivity to the specific TCP ports that overlap with the host stack.)