iWAN Hub Site tunnel IP overlapping

• Trying to deploy IWAN in a lab environment and successfully deployed the hub site except one thing..
• Apparently, while assigning IP address to Tunnel int47233 (Hub1), it tries to assign 192.168.2.1/30. The Hub LAN ip address is 192.168.2.1/24 and because of this, tunnel IP is overlapping with my HUB1 LAN IP.  It is successfully deployed with tunnel int 47233 IP unassigned and hence the tunnel is down.

Tunnel47233 is created programatically for AR workaround and hence the IP for the same is reserved programatically from 192.168.2 network. would suggest excluding 192.168.2 network from your own IP assignments to avoid conflict.

 AR workaround itself is inetrnal functionality, specific to iWAN workflow.

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.

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, 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.Regarding documentation

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 .

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.