Wireless Access

My setup is MASTER LOCAL, all RAPs go to MASTER. I am trying to simulate failover so when master becomes unavailable RAP starts looking for secondary controller after reboot

My ap system profil has info about master IP and Secondary Master IP, Number of IPSEC retries is minimal, in my case 3 with Request Retry Interval 10 seconds.  My understanding is that if I simulate loss of contact with master IP, after certain time RAP will reboot and strat looking for a secodary master (local in my case). I did a test and created rule blocking all traffic going only into master but RAP is failing to show up in the second controller, why?

If you log into the backup controller and do a "show log all | include <rap name or mac>" do you see it trying to establish the IPSec connection? 

Do you see on your NAT device the AP hitting the secondary public IP?

I would have to replicate that to check.  I am sure that I did 2 rules on my firewall to block 1) all traffic going to master IP and 2) allow all traffic to backup IP controller and I see both hit

Nothing comes up on the secondary controller but firewall rules show hits

Packet capture from that RAP i am testing this

10:30:23.401391 IP 10.0.0.138.65111 > "MASTER IP".4500: UDP, length 390
10:30:28.469189 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3559, seq 0, length 64
10:30:28.469250 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3559, seq 0, length 64
10:30:29.467000 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3559, seq 1, length 64
10:30:29.467026 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3559, seq 1, length 64
10:30:29.758557 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 423
10:30:29.764305 IP "SLAVE IP".4500 > 10.0.0.138.65113: UDP, length 60
10:30:29.767486 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 451
10:30:29.774744 IP "SLAVE IP".4500 > 10.0.0.138.65113: UDP, length 525
10:30:31.863183 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.863402 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.863613 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.863824 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.864113 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 208
10:30:31.877364 IP "SLAVE IP".4500 > 10.0.0.138.65113: UDP, length 80
10:30:31.951673 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3594, seq 0, length 64
10:30:31.951727 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3594, seq 0, length 64
10:30:32.950762 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3594, seq 1, length 64
10:30:32.950786 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3594, seq 1, length 64
10:30:33.234251 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:30:38.242922 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:30:43.248930 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:30:48.253844 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:32:47.584365 IP 10.0.0.1 > 10.0.0.138: ICMP echo request, id 12343, seq 0, length 28
10:32:48.588391 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:32:48.594579 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:33:22.080852 IP 10.0.0.138.68 > 10.0.0.1.67: UDP, length 490
10:33:22.081163 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:33:23.756049 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:28.762417 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:33.768466 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:38.774495 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:43.853466 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2965, seq 0, length 64
10:33:43.853528 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2965, seq 0, length 64
10:33:44.851146 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2965, seq 1, length 64
10:33:44.851174 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2965, seq 1, length 64
10:33:45.144146 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:33:50.150658 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:33:55.154691 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:34:00.157949 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:34:05.225045 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 0, length 64
10:34:05.225104 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 0, length 64
10:34:06.221042 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 1, length 64
10:34:06.221070 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 1, length 64
10:34:06.523337 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 423
10:34:06.529398 IP "SLAVE IP".4500 > 10.0.0.138.60352: UDP, length 60
10:34:06.532534 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 451
10:34:06.540249 IP "SLAVE IP".4500 > 10.0.0.138.60352: UDP, length 525
10:34:08.629071 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.629292 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.629503 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.629714 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.630005 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 208
10:34:08.644193 IP "SLAVE IP".4500 > 10.0.0.138.60352: UDP, length 80
10:34:08.723568 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3034, seq 0, length 64
10:34:08.723629 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3034, seq 0, length 64
10:34:09.721737 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3034, seq 1, length 64
10:34:09.721764 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3034, seq 1, length 64
10:34:10.013730 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:34:15.020033 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:34:20.026057 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:34:25.032044 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:36:23.618483 IP 10.0.0.1 > 10.0.0.138: ICMP echo request, id 12343, seq 0, length 28
10:36:24.620345 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:36:24.629925 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:36:58.137257 IP 10.0.0.138.68 > 10.0.0.1.67: UDP, length 490
10:36:58.137576 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:36:59.813133 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:04.819681 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:09.823702 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:14.824977 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:19.893167 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2964, seq 0, length 64
10:37:19.893232 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2964, seq 0, length 64
10:37:20.889076 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2964, seq 1, length 64
10:37:20.889105 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2964, seq 1, length 64
10:37:21.176189 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:26.182709 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:31.188715 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:36.191999 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:41.259691 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 0, length 64
10:37:41.259752 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 0, length 64
10:37:42.257591 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 1, length 64
10:37:42.257615 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 1, length 64
10:37:42.543101 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 423
10:37:42.549202 IP "SLAVE IP".4500 > 10.0.0.138.56029: UDP, length 60
10:37:42.552281 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 451
10:37:42.559468 IP "SLAVE IP".4500 > 10.0.0.138.56029: UDP, length 525
10:37:44.648489 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.648730 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.648946 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.649187 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.649477 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 208
10:37:44.662920 IP "SLAVE IP".4500 > 10.0.0.138.56029: UDP, length 80
10:37:44.731249 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3032, seq 0, length 64
10:37:44.731312 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3032, seq 0, length 64
10:37:45.727136 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3032, seq 1, length 64
10:37:45.727162 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3032, seq 1, length 64
10:37:46.028464 IP 10.0.0.138.56031 > "MASTER IP".4500: UDP, length 423
10:37:51.033765 IP 10.0.0.138.56031 > "MASTER IP".4500: UDP, length 423
10:37:56.036321 IP 10.0.0.138.56031 > "MASTER IP".4500: UDP, length 423
10:38:01.039745 IP 10.0.0.138.56031 > "MASTER IP".4500: UDP, length 423
10:39:59.622973 IP 10.0.0.1 > 10.0.0.138: ICMP echo request, id 12343, seq 0, length 28
10:40:00.645893 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:40:00.654957 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300

Did you whitelist the RAPs MAC address on the local controller as well? Unless you run VRRP w/ database sync it won't automatically copy the MAC whitelist between master/local pair.

I did not whitelisted manually but this RAP is whitelisted autamatically, I verified this by

 show whitelist-db rap 

packet capture

10:30:23.401391 IP 10.0.0.138.65111 > "MASTER IP".4500: UDP, length 390
10:30:28.469189 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3559, seq 0, length 64
10:30:28.469250 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3559, seq 0, length 64
10:30:29.467000 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3559, seq 1, length 64
10:30:29.467026 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3559, seq 1, length 64
10:30:29.758557 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 423
10:30:29.764305 IP "SLAVE IP".4500 > 10.0.0.138.65113: UDP, length 60
10:30:29.767486 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 451
10:30:29.774744 IP "SLAVE IP".4500 > 10.0.0.138.65113: UDP, length 525
10:30:31.863183 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.863402 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.863613 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.863824 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 530
10:30:31.864113 IP 10.0.0.138.65113 > "SLAVE IP".4500: UDP, length 208
10:30:31.877364 IP "SLAVE IP".4500 > 10.0.0.138.65113: UDP, length 80
10:30:31.951673 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3594, seq 0, length 64
10:30:31.951727 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3594, seq 0, length 64
10:30:32.950762 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3594, seq 1, length 64
10:30:32.950786 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3594, seq 1, length 64
10:30:33.234251 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:30:38.242922 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:30:43.248930 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:30:48.253844 IP 10.0.0.138.65115 > "MASTER IP".4500: UDP, length 423
10:32:47.584365 IP 10.0.0.1 > 10.0.0.138: ICMP echo request, id 12343, seq 0, length 28
10:32:48.588391 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:32:48.594579 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:33:22.080852 IP 10.0.0.138.68 > 10.0.0.1.67: UDP, length 490
10:33:22.081163 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:33:23.756049 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:28.762417 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:33.768466 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:38.774495 IP 10.0.0.138.60348 > "MASTER IP".4500: UDP, length 390
10:33:43.853466 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2965, seq 0, length 64
10:33:43.853528 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2965, seq 0, length 64
10:33:44.851146 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2965, seq 1, length 64
10:33:44.851174 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2965, seq 1, length 64
10:33:45.144146 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:33:50.150658 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:33:55.154691 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:34:00.157949 IP 10.0.0.138.60350 > "MASTER IP".4500: UDP, length 423
10:34:05.225045 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 0, length 64
10:34:05.225104 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 0, length 64
10:34:06.221042 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 1, length 64
10:34:06.221070 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 1, length 64
10:34:06.523337 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 423
10:34:06.529398 IP "SLAVE IP".4500 > 10.0.0.138.60352: UDP, length 60
10:34:06.532534 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 451
10:34:06.540249 IP "SLAVE IP".4500 > 10.0.0.138.60352: UDP, length 525
10:34:08.629071 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.629292 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.629503 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.629714 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 530
10:34:08.630005 IP 10.0.0.138.60352 > "SLAVE IP".4500: UDP, length 208
10:34:08.644193 IP "SLAVE IP".4500 > 10.0.0.138.60352: UDP, length 80
10:34:08.723568 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3034, seq 0, length 64
10:34:08.723629 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3034, seq 0, length 64
10:34:09.721737 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 3034, seq 1, length 64
10:34:09.721764 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 3034, seq 1, length 64
10:34:10.013730 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:34:15.020033 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:34:20.026057 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:34:25.032044 IP 10.0.0.138.60354 > "MASTER IP".4500: UDP, length 423
10:36:23.618483 IP 10.0.0.1 > 10.0.0.138: ICMP echo request, id 12343, seq 0, length 28
10:36:24.620345 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:36:24.629925 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:36:58.137257 IP 10.0.0.138.68 > 10.0.0.1.67: UDP, length 490
10:36:58.137576 IP 10.0.0.1.67 > 10.0.0.138.68: UDP, length 300
10:36:59.813133 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:04.819681 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:09.823702 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:14.824977 IP 10.0.0.138.56025 > "MASTER IP".4500: UDP, length 390
10:37:19.893167 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2964, seq 0, length 64
10:37:19.893232 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2964, seq 0, length 64
10:37:20.889076 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2964, seq 1, length 64
10:37:20.889105 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2964, seq 1, length 64
10:37:21.176189 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:26.182709 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:31.188715 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:36.191999 IP 10.0.0.138.56027 > "MASTER IP".4500: UDP, length 423
10:37:41.259691 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 0, length 64
10:37:41.259752 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 0, length 64
10:37:42.257591 IP 10.0.0.138 > 10.0.0.1: ICMP echo request, id 2998, seq 1, length 64
10:37:42.257615 IP 10.0.0.1 > 10.0.0.138: ICMP echo reply, id 2998, seq 1, length 64
10:37:42.543101 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 423
10:37:42.549202 IP "SLAVE IP".4500 > 10.0.0.138.56029: UDP, length 60
10:37:42.552281 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 451
10:37:42.559468 IP "SLAVE IP".4500 > 10.0.0.138.56029: UDP, length 525
10:37:44.648489 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.648730 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.648946 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.649187 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 530
10:37:44.649477 IP 10.0.0.138.56029 > "SLAVE IP".4500: UDP, length 208
10:37:44.662920 IP "SLAVE IP".4500 > 10.0.0.138.56029: UDP, length 80

Check the traffic is reaching your standby controller with the following:

#show datapath session | include [RAP EXTERNAL IP]

Check any log entries for the RAP 

#show log all | include [RAP EXTERNAL IP]

Enable the debugs as per below:

https://community.arubanetworks.com/t5/Controller-Based-WLANs/How-do-I-troubleshoot-RAP-in-ArubaOS/ta-p/178634

Have you also created a RAP IP Pool on the standby controller? This sometimes catches people out since it not sync'd between controllers.

show datapath session | include external IP

and

show log all | include external IP

show nothing but

show log all 25

shows

Nov 15 10:16:09  isakmpd[4004]: <103061> <4004> <ERRS> |ike|    Unable to get get IP Address from pool
Nov 15 10:16:09  isakmpd[4004]: <103061> <4004> <ERRS> |ike|    Unable to get get IP Address from pool
Nov 15 10:19:45  isakmpd[4004]: <103061> <4004> <ERRS> |ike|    Unable to get get IP Address from pool
Nov 15 10:19:45  isakmpd[4004]: <103061> <4004> <ERRS> |ike|    Unable to get get IP Address from pool

and I just created pool for RAP on standby,  I wasnt aware of this

UPDATE:  I have noticed that standby did not saved my pool for RAP (it is different from original one, can it be that way?)

It works, it was pool,

Thanks, good catch

Hi again,

Now there is another problem connected with this setup. I know RAP failover works while both controllers are UP. I did a test and hard reset MASTER controller, SLAVE was still up but RAP did not connected as tested before just by "cutting off" master IP.  

Both controllers are in the same place and on the same subnet. Why it does not work now? Does this have sth to do with hearbeat, how to fix it?

How are you making the RAP failover to the local?

my master is x.x.x..54

my local is x.x.x..53

My RAPs are setup like that

setenv remote_ap 1
setenv master x.x.x..54
setenv serverip x.x.x..54

Then in the AP system I have LMS IP settings which I did not touched but contain both IPs .53 and .54

And they are triggered by Bootstrap threshold and max time, which works only in case I simulate master failure by firewall block of MASTER IP.

Any idea, what I am doing wrong?

There could be numerous reasons as to why the secondary RAP is not appearing on the standby controller (missing whitelist entry, RAP pool not configured etc). In the very first instance do you see the RAP traffic on the standby controller?

show data path session | include [RAP external IP]

Not sure what you mean by "standby controller" but my configuration is MASTER - LOCAL

1) Local does have copy of configuration from master synching in real time

2) RAP whitelist does include all RAP MACs like on master

3) local does have RAP pool - it works by what I mean RAP do failover to LOCAL if both controllers see each other meaning they are online connected to the same swtich/vlan

4) problem starts once MASTER is shutdown, no power

5) cant verify that now

show data path session

6) what I did notice is when I shutdown MASTER and waited 10 min, none of RAPs synched to LOCAL but if I made MASTER back up I realized some RAPs instatnly popup up on LOCAL which may prove there is some hartbeat issue in my setup. Is that possible?

Does that make any sense?  Is there a hearbeat existance in my setup?

Let me ask you like that:

1)  Will RAP redundacy work with MASTER/LOCAL setup only (No NAT)?

2)  Will RAP redundacy work with VRRP (MASTER ACTIVE / MASTER STANDBY) using 3 public IPs (no NAT)?

Please let us know what TAC says about your specific setup.  It is hard to understand what is going wrong just from your posts.

---

@mke81 wrote:

Let me ask you like that:

 

1)  Will RAP redundacy work with MASTER/LOCAL setup only (No NAT)?

2)  Will RAP redundacy work with VRRP (MASTER ACTIVE / MASTER STANDBY) using 3 public IPs (no NAT)?

 

---

1.  It should

2.  It should

Ok good to know. 

Now, do I always need FQDN pointing to both IPs or if VRRP 3 IPs in any of mentioned 2 setups knowing my controllers work on public IPs?

Just to be clear all my RAP are obviusly behind NAT

fqdn with an A-record returning both ip addresses or a round-robin dns is best.  That is because you are not guaranteed to always connect to the first ip address when you cold boot.  If you do not connect to a single ip address, you cannot obtain and use the redundant address.  With dns this is possible.