EMEA Airheads - Aruba Remote Access Point (RAP) Troubleshooting
•Descargar como PPTX, PDF•
2 recomendaciones•5,732 vistas
In this presentation, we will be debugging Aruba RAP commands, run through troubleshooting and logs and tackle RAP clusters. Check out the webinar recording where this presentation was used: http://community.arubanetworks.com/t5/Wireless-Access/Technical-Webinar-Recording-Slides-Aruba-Remote-Access-Point-RAP/td-p/310448
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a EMEA Airheads - Aruba Remote Access Point (RAP) Troubleshooting
Similar a EMEA Airheads - Aruba Remote Access Point (RAP) Troubleshooting (20)
Más de Aruba, a Hewlett Packard Enterprise company
Más de Aruba, a Hewlett Packard Enterprise company (18)
Último
Último (20)
EMEA Airheads - Aruba Remote Access Point (RAP) Troubleshooting
- 1. ARUBA REMOTE ACCESS POINT (RAP) TROUBLESHOOTING Technical Climb Webinar 10:00 GMT | 11:00 CET | 13:00 GST October 17th, 2017 Presenter: Pravin Kumar Pravin.kumar2@hpe.com
- 2. 2 Welcome to the Technical Climb Webinar Listen to this webinar using the computer audio broadcasting or dial in by phone. The dial in number can be found in the audio panel, click additional numbers to view local dial in numbers. If you experience any difficulties accessing the webinar contact us using the questions panel.
- 3. 3 Housekeeping This webinar will be recorded All lines will be muted during the webinar How can you ask questions? Use the question panel on your screen The recorded presentation will be posted on Arubapedia for Partners (https://arubapedia.arubanetworks.com/afp/)
- 4. RAP SUPPORT IN 8.X
- 5. 5 Agenda • Introduction • RAP support in clustering • Terminology • Configuration • Troubleshooting and Logs • Debugging commands • Limitations
- 6. 6 Introduction Without Cluster: • RAP should terminate on VRRP-IP or needs to configure lms & bkp-lms for redundancy • Client will deauth when AP fail over to other controller • Client traffic is interrupted during failover • RAP needs to download entire config on every rebootstrap/failover With Cluster (8.x): • Classic cluster controller supports redundancy for both Aps and clients • Dormant(standby) entry will be created for wireless users on standby controller • RAP will establish tunnel with all cluster members with same inner-ip for easy of management. • Cluster is limited to max 4 nodes in case of RAP
- 7. RAP SUPPORT IN CLUSTERING
- 8. 8 Terminology A-AAC Active AP anchor controller, role given to AP where it is terminated. Config will be download from A-AAC controller. S-AAC Standby AP anchor controller, role given to AP where standby tunnel is established on controller. When active goes down Standby controller becomes active
- 9. 9 Terminology Contd.. UAC User Anchor Controller, a role given to a controller from individual User perspective. UAC handles all the wireless client traffic, including association/disassociation notification, authentication, and all the unicast traffic between controller and the client. The purpose of UAC is to fix the controller so that when wireless client roams between APs, the controller remains the same within the cluster. S-UAC Standby Controller from the User perspective User fails over to this controllers on Active UAC down
- 10. 10 Clustering overview Clustering for Mission Critical Networks 1 Seamless Campus Roaming Clients stay anchored to a single MD when roaming across controllers 3 Client Load Balancing Users automatically load balanced across cluster members 2 Hitless Client Failover User traffic uninterrupted upon cluster member failure Mobility Master/Standby MCMC MC
- 11. 11 Clustering Highlights 1 Available ONLY with Mobility Master 2 Only among Managed Devices (not MM) 3 No License needed MC MC Mobility Master/Standby Headquarter MC
- 12. 12 Clustering Highlights 1 Available ONLY with Mobility Master 2 Only among Managed Devices (not MM) 3 No License needed MC MC Mobility Master/Standby Headquarter 4 CAP, RAP and Mesh AP support MC
- 13. 13 Clustering Highlights 5 72xx, 70xx and VMC supported 721 0 7240 7220 7205703 0 70 24 70 10 70 05 70 08 VMC- 50 VMC- 250 VMC- 1k
- 14. 14 70 24 Clustering Highlights 5 72xx, 70xx and VMC supported All Managed Devices need to run the same software version 6 721 0 7240 7220 7205703 0 70 10 70 05 70 08 8.0. 0 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 8.0. 1 VMC- 50 VMC- 250 VMC- 1k
- 15. 15 Clustering Cluster Capacity 1 Up to 12 nodes in a cluster when using 72xx devices 7240 7205 7220 7205 7220 7205 7210 7205 7240 7205 7240 7205
- 16. 16 Clustering Cluster Capacity 1 Up to 12 nodes in a cluster when using 72xx devices 2 Up to 4 nodes in a cluster when using 70xx devices 7010 7005 7030 7024
- 17. 17 Clustering Cluster Capacity 1 Up to 12 nodes in a cluster when using 72xx devices VMC- 50 VMC- 250 VMC- 1k 2 Up to 4 nodes in a cluster when using 70xx devices 3 Up to 4 nodes in a cluster when using VMC devices VMC- 1k
- 18. 18 Clustering Key Considerations 1 Clustering and HA-AP Fast Failover mutually exclusive 2 Cluster members need to run the same firmware version 3 Size of Cluster terminating RAPs limited to 4 4 Mix of 72xx and 70xx devices in a cluster not recommended
- 19. 19 Clustering AP Anchor Controller (AAC) AAC S-AAC Mobility Master/Standby 1 AP sets up Active Tunnels with its LMS (AAC) 2 S-AAC is dynamically assigned from other cluster members 3 AP sets up Standby Tunnels with S-AAC Active Tunnel Standby Tunnel
- 20. 20 Clustering AAC Failover AAC S-AAC Mobility Master/Standby 1 AAC fails and Failure detected by S-AAC 2 AP tears tunnel and S-AAC instructs AP to fail over Active Tunnel Standby Tunnel AAC
- 21. 21 Clustering AAC Failover AAC S-AAC Mobility Master/Standby 1 AAC fails and Failure detected by S-AAC 2 AP tears tunnel and S-AAC instructs AP to fail over 3 AP builds Active tunnels with new AAC Active Tunnel Standby Tunnel AAC AAC 4 New S-AAC is assigned by Cluster Leader S-AAC
- 22. 22 CLI Configuration • Create rap pool on MM/mynode node • lc-rap-pool cluster-rap-pool <StartAddress> <EndAddress> Configure cluster profile at node (Aruba) [cluster2] (config) #lc-cluster group-profile 72xx (Aruba) [cluster2] (Classic Controller Cluster Profile "72xx")#controller 10.29.163.2 (Aruba) [cluster2] (Classic Controller Cluster Profile "72xx")# controller 10.29.163.3 (Aruba) [cluster2] (Classic Controller Cluster Profile "72xx")# #redundancy (Aruba) [cluster2] (Classic Controller Cluster Profile "72xx")# #write memory • Enable cluster membership on all nodes (Aruba) [cluster2] (config) #change-config-node /md/cluster2/00:1a:1e:01:2f:58 (Aruba) [00:1a:1e:01:2f:58] (config) #lc-cluster group-membership 72xx (Aruba) [00:1a:1e:01:2f:58] (config) #write memory
- 25. 25 Config verification (ArubaMM2)#show lc-cluster group-membership (ArubaMM3)#show lc-cluster group-membership
- 26. 26 Config verification (ArubaMM2) #show ap database (ArubaMM3) #show ap database
- 27. 27 Config verification (ArubaMM2) #show whitelist-db rap (ArubaMM3) #show whitelist-db rap
- 28. 28 Troubleshooting commands (ArubaMM2) #show crypto isakmp sa (ArubaMM3) #show crypto isakmp sa
- 29. 29 Troubleshooting commands To check cluster IP entries, execute below command and it will work only on MM. (Aruba) [mynode] (config) #show crypto isakmp clusterIP
- 30. 30 Troubleshooting commands (ArubaMM2) #show user-table (ArubaMM3) #show user-table standby
- 31. 31 Troubleshooting commands (ArubaMM2) #show datapath station (ArubaMM3) #show datapath station
- 32. 32 Troubleshooting commands (ArubaMM2) #show gsm debug channel user (ArubaMM3) #show gsm debug channel user
- 33. 33 Troubleshooting commands (ArubaMM2) # show aaa cluster essid-all users (ArubaMM2) #show aaa cluster essid-all bucketmap
- 34. 34 Troubleshooting commands (ArubaMM3) # show aaa cluster essid-all users (ArubaMM3) #show aaa cluster essid-all bucketmap
- 35. 35 Logging and Debugging commands logging security level debugging logging security level debugging process crypto show ap remote debug bucketmap datapath ap-name <ap_name> show ap remote debug bucketmap sapd ap-name <ap_name> show ap remote debug bucketmap stm ap-name <ap_name> show cluster-tech-support <filename> CLI to show Active/standby Users: show aaa cluster essid-all users <<< shows the active users for all the available essids show aaa cluster essid-all users standby <<< shows the dormant users for all the available essids show aaa cluster essid <essid> users <<< shows all the active users for a given essid show aaa cluster essid <essid> users standby <<< shows all the dormant users for a given essid
- 36. 36 Limitations Cluster is not supported for PSK-RAPs RAP whitelistdb entry should be configured only on MM-M. Cluster is not supported for external whitelilstdb Cluster supports only for Cert-based RAPs
- 37. 37 Questions ?
- 38. THANK YOU!
Notas del editor
- Current Aruba’s Move Architecture and what is the current challenge in this. Network Access: Layer 1 Access(AP’s) - Innovation from .11b to .11ac – Wireless or RF optimization – Client Match - Hardware changes Aggregation: (Local controllers or Mobility Controllers) All the client tunnel to the controller – AppRF – WCC - Wireless CP/DP – Not good for resilient – Upgrade and not good for failover – Load sharing is not possible Network Services: (Master Controllers or Master Mobility controller) Central mgmt – WMS + N+1 redundancy – No support for SDN(Software Defined Networking) or Open flow controllers– No Global view/visibility like topology, all AP’s. Airgroup - Need more scale and push for more intelligence or more memory.
- The AOS 8 Clustering feature was designed primarily for mission critical networks. Its goal is to provide full redundancy to APs and Wifi clients alike in case of a malfunction of one or more of its cluster members. Here are the benefits that could be immediately obtained from deploying on campus Aruba Mobility controllers as Managed Devices in a cluster configuration: Seamless Campus Roaming: The fact that clients remain anchored to a single controller (cluster member) throughout their roaming on campus, no matter which access point they connect to, makes their roaming experience seamless since their L2/L3 information and sessions remain on the same controller. Hitless Client Failover: Thanks to the full redundancy within the cluster, in the event of a cluster member failure, its connected clients are failed over to a redundant cluster member without disruption to their wireless connectivity, nor to their existing high value sessions. Client Load Balancing: The clients are automatically load balanced within the cluster. When clients are moved among cluster members, the move is done in a hitless manner.
- Here are highlights of the Clustering feature: 1. The Clustering feature is only available in deployments with the Mobility Master, as opposed to standalone controller deployments. 2. Cluster members can only be Mobility Controllers. In other words, we cannot at this time have Mobility Masters in a cluster. 3. There is no license required to turn on the Clustering feature.
- Here are highlights of the Clustering feature: 1. The Clustering feature is only available in deployments with the Mobility Master, as opposed to standalone controller deployments. 2. Cluster members can only be Mobility Controllers. In other words, we cannot at this time have Mobility Masters in a cluster. 3. There is no license required to turn on the Clustering feature. 4. Cluster members can terminate Campus APs (CAP), Remote APs (RAP) and Mesh APs.
- The following Mobility Controllers are supported: &2xx, 70xx and Virtual Mobility Controllers (VMC)
- The following Mobility Controllers are supported: &2xx, 70xx and Virtual Mobility Controllers (VMC) All Managed Devices are required to run the same ArubaOS version (8.0 and higher)
- Cluster capacity per platform: Up to 12 Mobility Controllers when using 72xx
- Cluster capacity per platform: Up to 12 Mobility Controllers when using 72xx Up to 4 Mobility Controllers when using 70xx
- Cluster capacity per platform: Up to 12 Mobility Controllers when using 72xx Up to 4 Mobility Controllers when using 70xx Up to 4 VMs when using the Virtual Mobility Controller (VMC)
- It is important to keep in mind several key considerations: The Clustering feature and the HA AP Fast Failover feature are mutually exclusive. Cluster members are required to run the same ArubaOS version. When the cluster is terminating Remote APs (RAPs), the size of the cluster is reduced to 4. A mix of hardware (7xxx) and x86 Mobility Controllers in the same cluster is NOT supported A mix of 72xx and 70xx Mobility Controllers in the same cluster is not recommended, not to mention the fact that the number of cluster members is reduced to 4.
- The AP Anchor Controller (AAC) is a role given to a cluster member Mobility Controller from an AP perspective. The AAC is actually the AP LMS controller. In other words, an AP that belongs to a given ap-group will get assigned its AAC through the lms-ip option in the ap system profile. The AAC is responsible for the handling of all the management functions of an AP and its radios. Here are examples of the AAC tasks: AP image upgrade CPSEC tunnel setup Config download to the AP With redundancy enabled, Cluster Manager dynamically assigns another cluster member as a Standby AAC (S-AAC) to the AP. The AP in turn builds standby tunnel(s) to the S-AAC
- In the event of an AAC failure: The S-AAC detects the failure within a very short time thanks to the inter-controller heartbeats The S-AAC instructs the AP to failover immediately
- In the event of an AAC failure: The S-AAC detects the failure within a very short time thanks to the inter-controller heartbeats The S-AAC instructs the AP to failover immediately The AP tears down its tunnel with the AAC, and changes the status of its tunnel with the S-AAC from standby to active The S-AAC becomes the new AAC for that AP, and the Cluster Leader promptly assigns a new S-AAC among the remaining cluster members