Tuesday, 28 May 2013

Cisco ACS Policy Decisions Based on SSID Name

If you're using an authentication server (such as Cisco's ACS) to make policy decisions about wireless users, there may be times when you'd like to make a decision based on the name of the SSID that the user is joining. In this article, we'll look at how you can do this.

In this article, I'm going to assuming that we are using a Cisco wireless LAN controller, together with a flavour of Cisco ACS 5.x. I've seen this method used with Cisco ACS 4.x (see references at the bottom of this article) and wouldn't be surprised if you could modify the technique for other RADIUS servers. When Googling about this subject, I don't see any results that show how to do this in ACS 5.x, so thought it was worth a quick note.


In brief, when a wireless client is attempting to authenticate to an SSID on a Cisco WLC network, if 802.1x is being used to authenticate users, then various RADIUS attributes are sent to the RADIUS server (e.g. ACS) as part of the authentication handshake between the WLC and RADIUS server. One of the attributes that is sent forward to the RADIUS contains information about the source SSID. This attribute can be leveraged in the policy/decision process for authenticating users.

The attribute we are interested in is the DNIS (Dialed Number Identification Service). If we inspect this attribute in the ACS logs, we can see that the DNIS contains the MAC address of the RADIUS client (the WLC), together with the SSID name. Here is a screenshot that shows an authentication record for a client (the SSID is called "home-8021x")

Having the MAC address and SSID mixed together like this is not that useful, but by using a wildcard character to ignore the MAC address segment of the field, we can look at the SSID name. Luckily for us, the '*' character can be used to wildcard the leading part of the field (i.e. the MAC address) and allow us to just look at the SSID segment that we wish to use for our decision making process.

To be able to include the SSID in the decision making process, we have to create an End Station Filter within ACS that we can drop in to our policy rules. Here is the ACS page that we are interested in:

To match on our SSID of interest ("home-8021x"), we have to configure the end station filter as shown below (note the use of the "*" to act as a wildcard for the MAC address of RADIUS client):

Configuration Example

Once we have our End Station Filter in place, we can make some very granular decisions around authentication and authorisation of users trying to join the SSID. One area that this is very useful for is defining Service Policies. We can tie a service definition to a particular source SSID.

For reference, here is a screen-shot from the Cisco WLC GUI, showing the SSID name that we are using:

In the example below, we have a service policy called "Auth_Users_Select". You can see from the highlighted field that only authentication requests that are received from our sample SSID will hit this policy entry, as they must match the End Station Filter that contains the SSID information. 

If you are looking at your own copy of ACS whilst looking at the example shown above, you may not see all of the fields shown in this screen-shot. You may need to customize the fields shown by hitting the 'Customize' button shown at the bottom right of the screen-shot.


There are a couple of caveats to bear in mind:
  • SSID names are case sensitive. If you aren't hitting the policy line you expect, double check the case of the SSID name in your end station filter, compared to that on your WLC
  • Bear in mind that you are using a wild-card in the end station filter. If you have similar-named SSIDs, make sure you are not filtering out an important part of the SSID name inadvertently

Using End Station Filters in this way gives you a powerful way of making decisions around both authentication and authorization decisions.

Particularly when considering service policy decisions within ACS, being able to associate a service with a particular SSID is valuable - each service (e.g. Corporate-data, Corporate-voice etc.) may be authenticated by their own methods using this technique.

It's also worth noting that the same effect may be achieved using the WLAN-ID RADIUS attribute which provides the (numerical) index of the SSID (this is often suggested in other configuration examples I have seen). Although using the SSID index (via the WLAN-ID RADIUS attribute) is  a valid method, unless there has been a policy of assigning the same SSID to the same index on every WLC in the network, then this may not be a feasible approach.


The following documents provide some very valuable references, particularly if you are looking for the ACS 4.x version of this technique:

Wednesday, 22 May 2013

Aruba Tech Field Day - 802.11ac Product Announcement

Yesterday was the official launch of Aruba's journey in to the world of 802.11ac with their online (and real-world) Tech Field Day event where they presented their products and strategy for 11ac. I was a virtual participant, watching from over here in the UK. I have to say up-front that I do not currently supply or support Aruba products, but was very interested to hear more about their views on 802.11ac, together with their product offering. There was a lot of ground covered, but here a few (brief) notes of things that I found of particular interest for the sessions I managed to view.


There was a very informative and lengthy discussion around 802.11ac technology, together with the lessons learned by Aruba in their testing to date. I won't cover all points here, but the headlines that stuck in my mind were:

  • Smartphones/tablets will continue to be primarily single stream, capable of 80MHz bonded channel support
  • Although 11ac brings significant speed advances, it's not the speed itself which is the advantage, it's the increase in efficiency of the WLAN which is the big win. The faster a client can get on the WLAN, send its data, and then get off, the more clients will be able to use the WLAN (which remains a shared medium). This will help to meet the growing demand for WiFi capacity
  • The highest "headline" speeds of 802.11ac will only be achieved by clients being in close proximity to an AP. The more complex modulation and signal processing required means that excellent signal quality (e.g. through excellent SNR levels) to achieve the higher speeds.
  • Sticky clients continue to be an issue (see "ClientMatch" below), which can significantly impact the efficiency of a high density WLAN. As client speeds drop as they move away from an AP, causing a bottleneck for other clients on the same AP that they are "stuck" to.


A mentioned above, Aruba highlighted the ongoing issue with "sticky clients". These are clients that initially associate with an AP and then, despite 'better-choice' APs being available, remain associated as the client moves away from it. The issue with this is that the client speed will drop as the signal level falls, so that it is transmitting at lower speeds and impacting the efficiency of other clients using that same AP. If  clients can be made to prefer (and roam to) a more local AP, that will facilitate a better link speed and WLAN efficieincy, together with all of the efficiency gains that this will bring.

Aruba have a 'patented' technology, called ClientMatch which apparently looks at things from a client point of view and can 'steer' clients to better-choice APs. This technology can apparently work for all types of (legacy) client, but works best on more recent types of client that support newer 802.11 features such as 802.11k/v.

Reading between the lines, I think it analyses signal quality and signal levels from clients (at the AP end of things), together with 802.11k/v information to make some decisions about how things are looking from a client's point of view. Then, somehow (presumably through band steering and ignoring probes etc. from clients below pre-defined signal thresholds) it 'steers' them to a better AP.

We all know the types of information that are available to an AP from clients and the limited amounts of information that clients themselves will supply or act on. So, it's hard to see what there is here to actually patent. Unless there is some type of agent installed on the client (which there isn't in this case), what other unknown (patentable) mechanism could possibly be at work here? Apart from some 'secret sauce' decision making from the WLAN point of view, using known measurements and techniques, it's hard to understand what can be so unique about this. To be honest, without more information, I'm struggling with the concept of a unique offering here...

Access Points

Early on in the proceedings, Aruba presented their new 11ac access points: the AP220. There are two models, one with internal and one with external antennas. The units they had on display at the event were very impressive looking. They looked relatively light-weight (judging by the way they were being handled) and they appeared pretty sleek, as they have now dispensed with the usual air-vents to meet the 'wipe down' needs of the healthcare sector.

The AP has 2 Gigabit Ethernet ports to cater for the theoretical throughput speeds that can achieved by an AP with 2 radios (1 x 5GHz 11ac & and  1 x 2.4GHz 11n). I didn't quite get the information around the power requirements (i.e. 802.3af vs 802.3at), but looking at the datasheet, it looks like it can run in an 'Efficient Mode' with an 802.3af POE port and full funtionality mode with an 802.3at POE port. The detail on how the 2 gigabit Ethernet ports will be used (i.e. load balancing or a true trunk) was also unclear (this is still TBA on the datasheet I am looking at...).

The guys from Aruba pointed out that the AP uses less power than 'other solutions which require a plug in module' (i.e. Cisco). But, from what I see so far, both solutions require a full 3at POE port to operate with full functionality, so, I don't really see an advantage there..?

They also said that in their experience to date, you can pretty much do a one for one swap out of 11n APs for 11ac, as the general coverage patterns were broadly similar.


A Microsoft representative provided an excellent presentation around the Microsoft Lync product, which was fascinating for those of us (OK, maybe just me) who aren't that familiar with Lync. He described the challenges of trying to prioritise the different traffic flows that originate from a Lync client.  

The Lync client itself may be a number of form factors (laptop, tablet, phone), which may be the source of data, voice or video traffic. Trying to configure the QOS requirements for just those traffic types is a challenge, but throw in the fact that there is signalling traffic, some traffic is encrypted and some protocols do not use well known port ranges, and you have a whole heap of trouble.

He then went on to describe how Aruba have become a certified Microsoft Lync partner, allowing them to have access to an API that is made available from a Lync server. Having access to the API means that the Aruba wireless LAN controller can exchange information and drill down in to the detail of each Lync session, allowing decisions (such as QOS prioritisation) to be made as required. Apparently, Aruba and Microsoft have invested a lot of time in testing this exchange of information across the API, which allows better decisions to be made by the wireless network and provides much richer information to be made available on the wireless management platform.

This foray in to the Lync API was described as Aruba's move in the to brave new world of SDN: the application providing information for the network fabric to provision the resources required for an application. Exciting stuff!!! It certainly sounds like a good strategic move for both organisations. but I wonder if an open, standards-based API would be a better way to go long term (...imagine an unique API for every different application)? This (SDN) isn't an area of expertise for me, so please excuse any comments which seem mis-guided and please attribute them to my technical ignorance :)


Finally, I have to say thanks to Aruba, Microsoft and Gestalt IT for providing such open access to this event. The information presented was both valuable and fascinating. 

The event itself was very well organised (as you might expect from those Tech Field Day boys), with a great deal of both vendor material (from Aruba/Microsoft), together with the opportunity for some challenging questions from vendor-neutral folks as well. I think this open-forum approach really shows that Aruba is ready to listen, as well as very generously share, which really raises my opinion of them significantly (...not that it was low before, :) I've had no previous dealings with Aruba) .

I believe that Aruba are also going to make some of the material available from the presentations, in the form of videos and some of the slide decks - I particularly look forward to the recommended Lync QOS settings that were shared :)  I also strongly recommend that you review some of the great material that Aruba have made available about 802.11ac and their products.

This has been another very interesting and exciting chapter in the unfolding 802.11ac - thanks to Aruba, Microsoft & Gestalt IT.


Tuesday, 21 May 2013

Aerohive BR200-WP 3G/4G Backup Testing

This is just a quick note about some interesting things I found out about the Aerohive BR200-WP today when I was having a look at our demo kit for a possible customer solution. 

The BR200-WP is a great little branch router/switch/AP platform. It boasts a single AP radio (5GHz or 2.4GHz, 3x3:3!!!) and has 5 x 1Gbps switched Ethernet ports (one is the WAN uplink). If you throw-in in the fact that its cloud managed and has all of the usual powerful HiveOS features (VPN, firewall, AVC, airtime fairness...etc,. etc.), you've got a great branch-router platform. (Oh yes, I forgot to mention that it has 2 x POE ports too!)

But in addition to the mass of great features outlined above, the BR200-WP has one more trick up its sleeve: 3G/4G backup. The unit has a USB 2.0 port which can be used to attach a 3G/4G dongle to provide WAN backup in the event that the main WAN link should fail. This was the area I was interested in taking a look at in my testing.

You'll have to excuse my ignorance in the area of 3G/4G backup in this article. There are probably a few things in here which may be very obvious to most folks, but I hadn't really come across them before.

I connected my BR200-WP up to an ADSL connection and gave it a basic configuration (via HMOL). This gave me an SSID to attach to and some basic Internet connectivity via a test wireless client. I configured the interfaces to (hopefully) provide a resilient WAN link.

My first action (like most engineers) was to insert my existing 3G dongle in to the USB port of the BR200WP and see 'what would happen'. Unfortunately, not too much did happen. I got the standard WAN (ADSL) connection up and working, but when I failed it, the 3G backup didn't kick in - back to the drawing board (well, time to read the manual actually).

After checking the datasheet, I realised that not all 3G dongles are created equal. Only certain models of dongle are supported for use with the BR200-WP. Apparently, different dongles use different command sets, which makes universal support tricky. So, I got on to Amazon and bought myself an unliocked Huawei E220 3G dongle. There are a range of 3G and 4G dongles that are supported by the BR200-WP, but I'll leave you to check them out on the datasheet (as the range of supported dongles will no doubt extend over time).

Once I had my supported (E220) dongle, I switched my SIM card across to in to the E220 to try the 3G backup again. (Quick note: I didn't know you could switch SIMs around like this to put them in to a supported card. Prior to being told this, I spent a lonnnnnnng time looking at cell phone web sites trying to get a supported dongle-type to buy a new one - very embarrassing in retrospect

Unfortunately, I still didn't have any success when I failed the main WAN link and had to do a little more digging. Again, my ignorance of 3G backup shone through, and after a little Googling it became apparent that I had to configure the correct dial-up parameters in the BR200-WP for my 3G dongle provider. In my case, as I use Vodafone here in the UK, my parameters are:
  • APN: internet
  • Dialup number: ATD*99#
  • User ID: web
  • Password: web
These parameters will vary from provider to provider. If they aren't 100% correct, things won't work. I found a great site with the correct  strings for many 3G/4G providers and their various data plans here in the UK, which you may find useful if you are going through a similar exercise:


Now that I had the correct type of dongle and the correct dial strings etc., I was ready to roll! I'm pleased to report that things actually worked pretty smoothly once I had this all figured out. I fired up my test wireless client and connected to the Internet via my usual DSL connection. Then, I failed the DSL connection and after a few seconds, the 3G link kicked-in and I carried on working.

I took a screen shot of the AP configuration so that you can see how I had it all configured to provide the 3G WAN backup. I've highlighted the important areas with red boxes:

Just to run through the 5 highlighted areas:
  • WLAN interface: not really related to 3G backup at all (sorry), but still very interesting. I found out that the way you switch between 2.4GHz and 5GHz is by changing the radio profile - that isn't immediately obvious (I never even realised you could switch to 5GHz until I read the data sheet!)
  • Eth0 - Set this interface to a priority of primary (this is the default) - this will ensure that the WAN link connected via this port is used for all traffic during normal (non-failure) operation
  • USB - Set the priority to Backup1 (this is the default) - this will ensure that this interface is used when the main WAN link (Eth0) fails
  • Wireless USB Modem Settings - Connect As Needed: this will ensure that the 3G link only comes up when the WAN links fails, rather than being permanently dialled up.
  • USB Modem - ensure that the various 3G modem strings are entered as per your 3G provider requirements
One area that I struggled with was getting the 3G dialler parameters (APN, User ID etc.) correct. This was quite difficult and time-consuming to resolve by the usual method of making a change via HMOL and then pushing the change out. So, I improvised slightly and connected my console cable to the BR200-WP. I made a few small config changes to the BR200-WP configuration via the CLI to test the effect of various changes in real-time. I used the following CLI commands:

usbmodem modem-id huawei_e220 apn internet
usbmodem modem-id huawei_e220 dialup-number ATD*99#
usbmodem modem-id huawei_e220 dialup-password web
usbmodem modem-id huawei_e220 dialup-username web

Once I'd got them right via the CLI, I configured them on HMOL and pushed out the final, correct config. Making CLI changes isn't really generally recommended, but in this case, it saved me a lot of time!

One other area I became very familiar with when trying to get this going is the debugging available from the CLI of the AP. If you're trying to set this up and are having difficulties, it's well worth enabling some debugging to see what's going on. I used the following command (which gives you more information than you really need):

debug console all

This gave a log on my terminal screen of everything going on, but allowed me to see the BR200-WP attempting to dial up the 3G connection when the WAN link failed. Here is a partial dump of the log showing a successful fail-over to the 3G connection, which may be useful (I've changed a few IP addresses etc. for security reasons):

2013-05-21 16:49:42 info    registering with PM for pid=2576 name=[mod_name_pppd_mod_id_64] cmdline=[/sbin/pppd noaccomp nopcomp novj nobsdcomp noipdefault noauth defaultroute replacedefaultroute usepeerdns lock crtscts persist ah-pppousb linkname usb_modem0 ipparam 115200 /dev/ttyUSB0 user web password web connect  USE_DIALUP_NUM=ATD*99# USE_APN=internet /sbin/chat -t5 -v -E -f /etc/chatscripts/3g.chat]
2013-05-21 16:49:42 notice  pppd[2576]: pppd 2.4.3 started by root, uid 0
2013-05-21 16:49:43 info    chat[2583]: abort on (BUSY)
2013-05-21 16:49:43 info    chat[2583]: abort on (NO CARRIER)
2013-05-21 16:49:43 info    chat[2583]: abort on (ERROR)
2013-05-21 16:49:43 info    chat[2583]: report (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 5 seconds
2013-05-21 16:49:43 info    chat[2583]: send (AT&F^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: AT&F^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATE1^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATE1^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (AT+CGDCONT=1,"IP","internet"^M)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 10 seconds
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: AT+CGDCONT=1,"IP","internet"^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATD*99#^M)
2013-05-21 16:49:43 info    chat[2583]: expect (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATD*99#^M^M
2013-05-21 16:49:43 info    chat[2583]: CONNECT
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send ( ^M)
2013-05-21 16:49:43 info    pppd[2576]: Serial connection established.
2013-05-21 16:49:43 warn    mDNSResponder: interface change, mdnsd refresh interface list and service!!!
2013-05-21 16:49:43 info    kernel: [systop]: initializing AH dev for ifp ppp0!
2013-05-21 16:49:43 info    kernel: [mpi]: drop unsupported event 0x5 from ppp0
2013-05-21 16:49:43 info    pppd[2576]: Using interface ppp0
2013-05-21 16:49:43 notice  pppd[2576]: Connect: ppp0 <--> /dev/ttyUSB0
2013-05-21 16:49:44 info    pppd[2576]: CHAP authentication succeeded
2013-05-21 16:49:44 notice  pppd[2576]: CHAP authentication succeeded

2013-05-21 16:49:44 warn    pppd[2576]: kernel does not support PPP filtering
2013-05-21 16:49:47 warn    pppd[2576]: Could not determine remote IP address: defaulting to 10.x.x.x
2013-05-21 16:49:47 info    amrp2: receive kevent KEVT_IF_CHG type IF_UP from ppp0 index 20
2013-05-21 16:49:47 warn    ah_dcd: Interface ppp0 is up.
2013-05-21 16:49:47 info    ah_dcd: access interface ppp0 is up now
2013-05-21 16:49:47 info    capwap: CAPWAP receive kevent KEVT_IF_CHG, eventid = 16, size = 36
2013-05-21 16:49:47 info    kernel: [mpi]: drop unsupported event 0xd from ppp0
2013-05-21 16:49:47 info    kernel: [mpi]: ppp0 notify kevent KEVT_IF_CHG, type IF_UP(1)
2013-05-21 16:49:47 info    capwap: receive event vpn report responce capwap: eventid = 103: length = 30
2013-05-21 16:49:47 info    capwap: CAPWAP: receive vpn report responce capwap event!, length:30
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4135), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters, ifname
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4136), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters, ifname
2013-05-21 16:49:47 debug   ah_brd: WANFO: Added event BACKUP_WAN_CONNECTED
2013-05-21 16:49:47 debug   ah_brd: WANFO WANFO SM Engine: @ state:NOWAN + event:BACKUP_WAN_CONNECTED [0x3]

So, there you have it, a quick look at setting up the 3G backup on the BR200-WP. 

It's worth bearing in the mind the limitations of 3G connectivity as a backup medium. You're realistically limited to downstream connectivity speeds of around 2 to 4 Mbps, depending on your signal strength, with upload speeds being just a few hundred kbps. It's not going to provide you lightning connectivity, but it will keep you going. It will be fascinating to see how a 4G connection performs, potentially providing several tens of mbps in each direction (providing you can get the coverage!). The possibilities for the BR200-WP certainly increase significantly if a good cellular WAN speed can be achieved.