CWNA – PoE – PD Classification and Usage

PD Classification

Advertisements

CWNA – PoE – PSE Power Chart

The things we have to memorize:

PSE Power Chart

ClearPass – How to setup a Generic RADIUS Catch-all Service

ClearPass – How to setup a Generic Radius Catch-all Service

One of the common questions that I am asked is “how do I know what attributes I can use to differentiate services in ClearPass.  My response is always “have you setup a generic RADIUS catchall service?”  Their response is usually “what is that?”  I wanted to take a few minutes to share this simple yet very valuable service on CPPM.

So why do we need to setup a Generic RADIUS catch-all service?  The purpose of the generic service is to give us visibility into any valid RADIUS request coming into CPPM from a known Network Device and allows us to use the incoming RADIUS attributes in those requests to customize our more specific services to trigger on a particular attribute.  Here is a quick example of the attributes that are passed in a RADIUS authentication request:

 Image

The first thing we need to do to create a new service. In CPPM select Configuration -> Start Here.  This will bring up the Service Template Options.  Scroll down and select RADIUS Enforcement (Generic).

 Image

This will bring up the Add Service Screen.  You will need to enter a name for the newly created service.  I like to call it Generic RADIUS Catch-all.  Do not add any Service Rules to this service.

 Image

Select Next.  This will take you to the authentication tab.  You will need to select any authentication method that will be used in your network.  I typically select EAP MSCHAPv2, EAP PEAP, EAP TLS, EAP TTLS, MSCHAP, CHAP, and PAP.  Under the authentication source drop down select Local User Repository. 

 Image

Select Next.  This will take you to the Roles Tab.  Since we are only using this service for visibility into the RADIUS attributes sent in a RADIUS request we do not need to perform any Role Mappings.

 Image

Select Next.  This will take you to the Enforcement Tab. Since we are only using this service for visibility into the RADIUS attributes sent in a RADIUS request we do not need to define a custom Enforcement Profile.  Leave the “Sample Allow Access Policy” as the defined Enforcement Policy.

Image

Select Next.  This will take you to the Summary tab.  You can review the service configuration on this tab.  Click Save.

Image

When you click Save you will be taken to the Reorder Service screen.  You need to make sure that the Generic RADIUS service that you just created is the LAST SERVICE in the list!!!  This will insure that it will not interfere with any customized RADIUS services.  With that being said, when you are ready to create the new customized services you need to make sure you reorder them as well so they are processed before the generic service. 

 Image

The next step is to add your controllers or switches to CPPM as valid NAD devices under Configuration->Network->Devices.

 Image

Once your network devices are added all incoming RADIUS Requests will trigger this service. Now you are ready to make a RADIUS user authentication request to see what information CPPM will receive.

IAP Client Troubleshooting

This post isn’t ACMX related but I thought someone might find it useful.  Today I spent a good part of the day diagnosing client connectivity issues to an Instant AP.  Here are a few commands that came in handy:

show clients: Displays basic information about all of the clients that are connected to the swarm.

show_clients

show clients status <mac of client>: Displays detailed information on a specific client device

show_client_status

And if you really want to get the details on a client:

show ap debug client-table | include <client mac>

sh_ap_debug_client-table

 

Now for the nerdy stuff.  The Instant CLI has the capability to do a packet trace on the console to dig into issues with the packet flow across the AP.  Here are the commands that you need to run:

debug pkt match <mac/ip/port/vlan> : this sets the value for the source of the traffic that we need to match on

debug pkt <mac/ip/port/vlan> <actual client mac/ip/port/vlan> : identifies the specific source that we are tracking

debug pkt type <arp/icmp/dhcp/tcp/udp/all> : identifies the traffic that we are tracking

debug packet dump: tells the IAP to dump the output to the console

 

Here is an example of troubleshooting a specific client’s tcp traffic:

debug pkt match mac

debug pkt mac 00:25:9c:f9:be:fc

debug pkt type tcp

debug pkt dump

iap_client_debugs

 

 

Yes I know these images suck.  I will try to get larger screen grabs tomorrow.  Now go have fun grabbing packets.

Add a Local Controller to an Existing Master

Once a network has scaled up beyond a single controller capacity, a master/local architecture is recommended.  This allows the master controller to handle configuration and correlation while the locals can be responsible for handling the user traffic. 

Steps to Add a local controller to an existing Master:

From the Master GUI:

Configuration -> Network -> Controller -> System Settings

–          Click New Local Controller IPSec Keys

–          Enter the IP Address of the local controller that you are adding

–          Enter an IPSec key

–          Re-Enter the IPSec key

–          Click Add

–          Click Apply (don’t forget)

–          Save Configuration

Or From the Master CLI:

localip <local ip address> ipsec <ipsec key>

 

From the Local GUI:

Configuration -> Network -> Controller -> System Settings

–          Select Controller Role Drop-Down and select Local

–          Enter the Master Controller IP (VRRP address if using master redundancy)

–          Enter IPSec Key  (Same key you entered on Master)

–          Click Apply

–          Reboot Controller

Or From the Local CLI:

masterip <master ip address> ipsec <ipsec key>

AP Troubleshooting

In order to make the WLAN function, the access points need connectivity to the controller.  Let’s review what an AP does during the boot process

Acquire IP address (can be static or acquired from DHCP)

  • IP address is required for communication with the controller using PAPI and GRE
  • To verify the access point properly acquires an IP you will need console access to the AP

Discover Controller

  • The AP goes through the following process in trying to discover a controller 
  1. Statically assigned
  2.  DHCP Vendor Option 43
  3. ADP Multicast: Group Address 239.0.82.11 (requires multicast routing to be enabled on infrastructure)
  4. ADP L2 Broadcast
  5. DNS (aruba-master.<localsuffix>
  • The AP will follow the sequence exactly as above.  Once the AP learns a controller address, it terminates the discovery process and attempts to communicate with the learned address.  If the AP doesn’t receive a response from the learned address, then the AP will initiate a full reboot and start the process again

Update Code if necessary

  • AP Compares the code level to the controller’s code level
  • If the code revision matches the AP will continue the boot process
  • If the code revision does not match the AP will obtain the new code from the controller using FTP (TFTP is used on the initial join or if the AP is purged
  • The AP will automatically reboot after the code upgrade/downgrade
  • “show ap database” shows the current status of each AP (will list if upgrading, rebooting, etc)

Obtain Configuration Information

  • Once an AP connects to a controller and has compatible code, it will receive its configuration over PAPI
  • “show ap config ap-name <ap-name>” will show the AP configuration being pushed to the AP

Build GRE Tunnel

  • GRE is used to carry all of the wireless traffic between the AP and the local controller
  • A GRE tunnel is created per SSID per AP
  • The AP System Profile Controller LMS-IP setting tells the AP which controller the AP should terminate with
  • Be sure to allow Protocol 47 between the controllers and APs
  • “show ap debug system-status ap-name <ap-name>” – shows the communication status between the controller and AP
  • “show datapath tunnel table”shows the GRE tunnels established with the controller (look for prt 47)
  • “show ap debug counters”shows how many times an AP has rebooted or bootstrapped

Enable Radio

  • Once the GRE tunnel has been established the Radios will become enabled
  • “show profile-errors” – shows the list of invalid user created profiles.  An invalid user profile could cause the AP not to broadcast its assigned SSIDs.  

Aruba – Network Ports Needed

Aruba - Network Ports Needed

Aruba – Network Ports Needed