UserID Redistribution Filters working weirdly

[AndiTrautmann]

Hi there

I have a customer setup with a central "Hub"/HQ-Firewall (Pair) and a lot of smaller "Spoke"/Site firewalls connected via S2S Tunnels. Each Site and the HQ have local AD DCs and UserID-Agent Server to collect User/IP-Mappings locally. Also in some Sites and HQ ther is Global-Protect running (adds more mappings).

The customer needs all the user-ip-mappings in all the sites. So we have redistribution configured in both ways from each spoke to the hub. Obviously this leads to a load of redundant mappings floating and looping around.

So, I wanted to improve this by using Redistribution Filters (Include/Exclude Networks). I must say, the documentation about this feature is scarce... But I thought i understood what it did... but I was wrong: Since each Site has a /16 Network-Prefix, I just added this prefix as an include statement. My hope was, that this would lead the site to only send mappings of its own prefix back to the hub (and therefore stop the loops of the mappings).

What actually happened was that the site only learned mappings of the prefix in the inlclude statement... And I think (need to confirm) it also only redistributed those to the hub. So, If I got this right, the feature is nealy useless (for my case).

Does anyone have experience with this feature / behaviour of the feature?
How do you understand it works - from your experience?

Any idea how I could solve this problem (bearing in mind that mappings need to flow both ways)?
I have also a working instance of CIE in place. But this is thought as a backup-path. The customer does not want to rely on it a the primary path. 

thanks
Andreas

[AndiTrautmann]

Update:
I confirmed it now: The include/exlude Filters apply to both the "import" and "export" (terms borrowed from routing) of mappings to other firewalls.

So, it seems the filter do not allow me to build a design with redundancy / bi-directional flow of mappings without having a lot of duplicates flowing/looping around.
There is a limit of 10 hops for user-ip-mappings. But still this seems unfortunate.