separate self IP on GTM for Communication with Peer devices

If you are asking about running iQuery over the Mgmt interface, do NOT do it. Set up a self-IP for this communication. I normally do this on the same VLAN as the Listener.

I am also not sure about what you mean when you say you are setting up the GTM devices as ACTIVE/ACTIVE. That is usually a term used for HA configuration. I would advise you run all the GTM in Standalone mode, and not HA them, unless you have other requirements that dictate HA pairs of GTM devices (For instance if they are also performing LTM services). Just like you would DNS servers.

In regards to Prober Pools, I always try to get the bigip device closest to the resource being monitored, to do the monitoring. For instance, if I have a HA pair of LTM in a DC, and they can hit the resource I need monitored in that DC, I would put them in the Prober pool alone. I also tend to avoid having large prober pools, as I like probing to be as deterministic as possible, for ease of troubleshooting. I like to KNOW where the monitors are sourced from. Prober Pools are a big topic, and one you should really consider cautiously as you architect this. Consider where the Probers are, How they reach the resources being monitored, and what the consequences are as the probes move from one device to the other.

Personally, I use prober pools, NOT to LB the monitoring load, but to control where monitoring occurs. Not sure if that is the best philosophy, but it has been successful for me in large environments.

Best of Luck!

Appears you only have bigip devices in play, so you do not need Prober pools. The iquery between the GTM and LTM will do all you need. The LTM will provide VIP status via iQuery.

There are some caveats to this, such as VIPs that do not change state. Those would need monitors applied to the pools on the GTM, and those monitors would engage a prober for execution. But, if your VIPs go RED/GREEN you should be fine.

Hope it helps!