I don't believe we have documented this anywhere since AR workaround itself is inetrnal functionality, specific to iWAN workflow. Sincere apologies on documentation gap and I'll see what I can do in the best of my capacity here.
The purpose is to function in situations of Asymmetric Routing (AR) by creating GRE tunnels (hard coded as Tunnel47233, similar to hardcoded Loopback47233 for iWAN across all workflows) between hub devices.
Having said that, we have validation procedures in place to detect things like Loopback47233 and flag them back to user as must-fix errors/warnings since we will be provisioning them anyway and don't want any conflicts with our provisioning. Unfortunately, detection of Tunnel47233 and use of subnet 192.168.2 (which will be used for IP assignments on AR Workaround tunnels) are not part of these validations either. May be in the interim we can think of adding them from engineering as a quick-fix. I say interim because -
1. There's already a feature request to remove hard coding of IP subnet to be used for AR Workaround tunnels. We may provide this IP assignment as user input from IP Address Pool creation page and use the IPs from this pool appropriately. As of now, I'm not sure of the priority of this request to definitely say which release it will make it to.
2. In subsequent release (not the immediately upcoming one) AR Workaround as a solution itself will go away and alternate method to work with Asymmetric Routing might be in place. This is in works in longer terms.
In summary,
1. We should have documented this better. Let me check what we can do from engineering side for it.
2. Add validations for detecting presence of Tunnel47233 and usage of IP addresses from 192.168.2 subnet on other interfaces of the device. This might be doable for upcoming release but again, as an engineer I can't speak for marketing when it will come to feature request prioritization.
There's a tab called "I wish this page could have..." in APIC-EM. May be you can provide your input/feedback through it.
For now to work with your existing deployment, I'd suggest removing 192.168.2 network from your own IP assignments and work with another subnet. I'm not sure how difficult that would be but this is where we stand with AR as of now.
