Wireless Access

last person joined: 16 minutes ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

RAP failover

Jump to Best Answer
  • 1.  RAP failover

    Posted Nov 14, 2018 09:24 PM

    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?

     

     



  • 2.  RE: RAP failover

    Posted Nov 15, 2018 09:28 AM

    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?



  • 3.  RE: RAP failover

    Posted Nov 15, 2018 10:03 AM

    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



  • 4.  RE: RAP failover

    Posted Nov 15, 2018 10:15 AM

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

     

    Screen Shot 2018-11-15 at 10.13.45 AM.pngScreen Shot 2018-11-15 at 10.04.37 AM.png



  • 5.  RE: RAP failover

    Posted Nov 15, 2018 10:44 AM

    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


  • 6.  RE: RAP failover

    Posted Nov 15, 2018 11:01 AM

    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.



  • 7.  RE: RAP failover

    Posted Nov 15, 2018 11:11 AM

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

     show whitelist-db rap 


  • 8.  RE: RAP failover

    Posted Nov 15, 2018 11:12 AM

    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


  • 9.  RE: RAP failover
    Best Answer

    Posted Nov 15, 2018 11:23 AM

    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.



  • 10.  RE: RAP failover

    Posted Nov 15, 2018 01:25 PM

    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?)



  • 11.  RE: RAP failover

    Posted Nov 15, 2018 01:32 PM

    It works, it was pool,

    Thanks, good catch



  • 12.  RE: RAP failover

    Posted Nov 15, 2018 02:10 PM
    No worries! Glad to hear it is sorted!

    Sent from my iPhone


  • 13.  RE: RAP failover

    Posted Feb 14, 2019 09:00 AM

    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?



  • 14.  RE: RAP failover

    Posted Feb 14, 2019 09:19 AM

    How are you making the RAP failover to the local?



  • 15.  RE: RAP failover

    Posted Feb 14, 2019 10:37 AM

    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.



  • 16.  RE: RAP failover

    Posted Feb 16, 2019 10:15 AM

    Any idea, what I am doing wrong?



  • 17.  RE: RAP failover

    Posted Feb 16, 2019 11:13 AM

    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]


  • 18.  RE: RAP failover

    Posted Feb 16, 2019 03:14 PM

    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?

     

     



  • 19.  RE: RAP failover

    Posted Feb 19, 2019 10:17 AM

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



  • 20.  RE: RAP failover

    Posted Mar 02, 2019 01:01 AM

    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)?

     



  • 21.  RE: RAP failover

    Posted Mar 02, 2019 06:29 AM

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



  • 22.  RE: RAP failover

    Posted Mar 02, 2019 06:37 AM

    @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



  • 23.  RE: RAP failover

    Posted Mar 02, 2019 12:40 PM

    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



  • 24.  RE: RAP failover

    Posted Mar 02, 2019 02:09 PM

    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.