| Question |
Why is my new Cluster unable to form a VPN tunnel while existing one works? |
| Environment |
Any IAP Cluster which was created by moving an IAP from existing Cluster to create a new one and VPN tunnel being setup to Controller. |
When a Cluster is originally created; the Master AP dynamically creates an VC key. When we setup VPN tunnel; the VC key / Branch key is used by Aruba Controller to uniquely identify the cluster. The key is distributed by Master to all Slave APs so all APs share the same VC key. In case of master failover; the new master would still be able to identified as part of same cluster and can form a tunnel to the controller.
When the VC sets up the tunnel; it sends a Registration message which includes the vc key / branch key. The controller would check it's database to confirm if the branch key is already in use. If confirmed to be not active; it would create a new Branch ID to the VC.
With logging enabled for IAP Manager; we would be able to get details of the registration in System log message (logging level debugging system process iapmgr)
show log system 30 | include 'IAP manager Pro'
Aug 6 18:38:02 IAP manager Process[3491]: <342006> <DBUG> |IAP manager Pro| papi_rcv_cb, Recvd auth Message
Aug 6 18:38:02 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| handle_iap_up:66 !!!new IAP branch up with inner IP 1.1.1.1
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| register_iap_bid:123 Received from IAP - key='eb79d8220178bdda4697fd05a22f419b7d5e62bc44abeb8db8'; ip='1.1.1.1'; mac_addr='6cf37fc40b6a'; subnet_count='1'; subnet='Centralized,L2-1'; bid='-1'; max branch='32768'; back_up='no'
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| register_iap_bid:183 Adding in inrIPandBrnchID ip 1.1.1.1 brkey eb79d8220178bdda4697fd05a22f419b7d5e62bc44abeb8db8
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| register_iap_bid:199 creating branch with key eb79d8220178bdda4697fd05a22f419b7d5e62bc44abeb8db8
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| register_iap_bid:301 adding to perSubnetInfo 32768 subnet name Centralized,L2-1
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| register_iap_bid:349 calling get free index
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| get_free_index:499 Looking for free bid in branch_bit_map
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| get_free_index:510 in free index 0
Aug 6 18:38:06 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| register_iap_bid:405 bid for 'Centralized,L2-1' subnet = 0
When a new cluster is created by moving an AP from existing cluster; the VC key is carried over. The new branch would have the same key as the other branch from which it was created.
If the new branch VC tries to setup a tunnel; Controller would notice that the branch key is already in use for a different branch and wouldn't allow the new branch to setup tunnel.
show log system 30 | include 'IAP manager Pro'
Aug 6 19:10:52 IAP manager Process[3491]: <342006> <DBUG> |IAP manager Pro| papi_rcv_cb, Recvd auth Message
Aug 6 19:10:52 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| handle_iap_up:66 !!!new IAP branch up with inner IP 1.1.1.5
Aug 6 19:11:38 IAP manager Process[3491]: <342006> <DBUG> |IAP manager Pro| papi_rcv_cb, Recvd auth Message
Aug 6 19:11:38 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| handle_iap_up:66 !!!new IAP branch up with inner IP 1.1.1.6
Aug 6 19:11:44 IAP manager Process[3491]: <342006> <DBUG> |IAP manager Pro| papi_rcv_cb, Recvd auth Message
Aug 6 19:11:44 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| handle_iap_up:66 !!!new IAP branch up with inner IP 1.1.1.7
Aug 6 19:12:12 IAP manager Process[3491]: <342006> <DBUG> |IAP manager Pro| papi_rcv_cb, Recvd auth Message
Aug 6 19:12:12 IAP manager Process[3491]: <342005> <DBUG> |IAP manager Pro| handle_iap_up:66 !!!new IAP branch up with inner IP 1.1.1.8
To avoid this situation; we should reset an AP (if it was part of a cluster) before creating a new cluster. This would ensure a new VC key is generated.