Cisco access-point authorization

Besides doing (traditional) dot1X on the wired switchport on which a access-point is connected, it is also possible to let the wireless controller authorize access-points within the join process. This post gives the necessary configuration for the use of a external AAA RADIUS server (ISE) within this process for AirOS and IOS-XE wireless controllers.

1. AirOS
(2504) >config radius auth add 1 192.168.208.51 1812 ascii Pr3sh@r3dk3y
(2504) >config radius auth network 1 enable
(2504) >config macfilter radius-compat cisco
(2504) >config auth-list ap-policy authorize-ap username ap-mac
(2504) >config auth-list ap-policy authorize-ap enable

2. IOS-XE
CAT1(config)#aaa new-model
CAT1(config)#radius server AAA-RADIUS-ISE01
CAT1(config-radius-server)#address ipv4 192.168.208.51 auth-port 1812 acct-port 1813
CAT1(config-radius-server)#key 0 Pr3sh@r3dk3y
CAT1(config)#aaa group server radius AAA-GRP-ISE
CAT1(config-sg-radius)#server name AAA-RADIUS-ISE01
CAT1(config-sg-radius)#subscriber mac-filtering security-mode mac
CAT1(config)#ap auth-list ap-policy authorize-ap
CAT1(config)#aaa authorization network default group AAA-GRP-ISE

3. ISE
While I was performing some testing there where two things which caught my attention on the ISE logging:
1) By default IOS-XE will send a blank password which ISE does not understand (fix for this is the “subscriber mac-filtering security-mode mac” command)
2) In ISE the AirOS authentication requests showed up as MAB method, while the requests from IOS-XE used the PAP_ASCII method. Despite some research I was unable to find a way to change this on the IOS-XE side. I ended up with the following configuration to support both platforms within the same set of rules:

Allowed protocols
ISE
Authentication policy
ISE
Authorization policy
ISE

Cisco Converged Access multicast configurations

Within the Converged Access platform there are a few features which can benefit from the use of multicast traffic flows. In this post I discuss which these features are and how they need to be configured.

1. Generic multicast configuration
First of all some generic multicast configuration needs to be in place on which the other features rely. For this post I use two 3650 switches (CAT1 and CAT2) which are directly connected to each other. The wireless management interface is VLAN 601 for both switches. IP multicast routing will be enabled globally and for both switches one switch will be statically configured as as RP for PIM.

CAT1(config)#ip multicast-routing
CAT1(config)#ip pim rp-address 10.60.1.254
CAT1(config)#int vlan 601
CAT1(config-if)#ip pim sparse-mode

2. “Multicast-multicast” mode for client multicast traffic
To distribute the client multicast (and broadcast) traffic as efficient as possible between the switches and the access-points, we can use “multicast-multicast” mode. In this configuration the client traffic will be send to the access-points with multicast as well.

CAT1(config)#wireless multicast
CAT1(config)#ap capwap multicast 239.44.44.44

Once enabled you can see that a dedicated Capwap interface is being created, which is “Ca1” in this scenario with the SVI of the CAT1 switch as source IPv4 address.

CAT1#show capwap summary
Name   APName                           Type PhyPortIf Mode      McastIf
------ -------------------------------- ---- --------- --------- -------
Ca1    -                                mcas -         unicast   -
Ca2    3502I                            data Gi1/0/2   multicast Ca1
Ca3    2602E                            data Gi1/0/3   multicast Ca1

Name   SrcIP           SrcPort DestIP          DstPort DtlsEn MTU   Xact
------ --------------- ------- --------------- ------- ------ ----- ----
Ca1    10.60.1.254     5247    239.44.44.44    5247    No     1449  1

On layer 2 level we see that IGMP snooping is active for the two ports on which the access-points are connected.

CAT1#show ip igmp snooping groups
Vlan      Group                 Type        Version     Port List
------------------------------------------------------------------------
601       239.44.44.44          igmp        v2          Gi1/0/2, Gi1/0/3

So how does this looks like on the wire? In the red box in the picture below you see the actual multicast packet, the orange box is the encapsulated client (broadcast) traffic.

Wireshark

3. Multicast traffic within Switch Peer Group
Converged Access works with Mobility Controller (MC) and Mobility Agent (MA) roles in certain Switch Peer Groups (SPG). Those SPG should be designed around areas where extensive roaming is going to happen like one building or floors. Within a SPG you only have one MC but you can have multiple MAs which all need to communicate with each other. Some communication can be done with multicast as well which can be more efficient if you have a few MAs within the SPG. Below the configuration for the MC (CAT1 – 10.60.1.254) and MA (CAT2 – 10.60.1.250).

CAT1(config)#wireless mobility co peer-group MA
CAT1(config)#wireless mobility co peer-group MA member ip 10.60.1.250
CAT1(config)#wireless mobility co peer-group MA multicast ip 239.33.33.33
CAT2(config)#wireless mobility co ip 10.60.1.254

The multicast address configuration is being pushed by the MC to the MA:

CAT2#*Mar 19 21:33:30.843: *%MM-6-SOCK_SET_ADDRESS_OPTION: 1 wcm: Setting membership for interface IP 10.60.1.250 and multicast group 239.33.33.33 on the mobility sockets.

CAT2#show wireless mobility summary
Mobility Agent Summary:
Mobility Role : Mobility Agent
Mobility Protocol Port : 16666
Mobility Switch Peer Group Name : MA
Multicast IP Address : 239.33.33.33

So how does this looks like on the wire? Below you can see the messages being send by the MA when one clients roams between APs connected on CAT1 and CAT2.

Wireshark

4. Multicast traffic between MCs (in different mobility domains)
In this scenario both CAT1 (10.60.1.254) and CAT2 (10.60.1.250) are MCs and belong to different mobility domains. Again the use multicast to communicate with each other. Note: from my own testing I have seen that it is not required to use different multicast address for this.

CAT1(config)#wireless mobility controller
CAT1(config)#wireless mobility group name MC1
CAT1(config)#wireless mobility multicast ip 239.33.33.35
CAT1(config)#wireless mobility group member ip 10.60.1.250 group MC2
CAT1(config)#wireless mobility group multicast-address MC2 ip 239.33.33.36
CAT2(config)#wireless mobility controller
CAT2(config)#wireless mobility group name MC2
CAT2(config)#wireless mobility multicast ip 239.33.33.36
CAT2(config)#wireless mobility group member ip 10.60.1.254 group MC1
CAT2(config)#wireless mobility group multicast-address MC1 ip 239.33.33.35

Cisco WLC rate limiting

This time a short post about rate limiting on an Cisco AirOS WLC. Under the QoS tab of the SSID configuration you can find two categories of rate-limiting settings; per user and per SSID. For both categories you can specific UDP and TCP rates, however those settings are being applied on the specific radios of the access-point and not on the controller! Below two examples to illustrate what this means.

Two clients on the same AP and on the same radio
3Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 3359000 bits/sec, 300 packets/sec

6Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 6346000 bits/sec, 581 packets/sec

Two clients on the same AP and on different radios
3Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 6391000 bits/sec, 576 packets/sec

6Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 12325000 bits/sec, 1108 packets/sec

So if you expect an “global maximum per SSID” you will find that the configured value will not work with multiple access-points and clients. You have to really dive deep in the documentation from Cisco to find this. I guess Cisco had some complains about this as well because since software version 8.0 the related footnote (number 16) for this configuration item got changed. The added “Override Bandwidth Contracts parameters are specific to per Radio of AP.” Yeah, about time…

A better location for your traffic engineering is in my opinion somewhere on the next-hop router or firewall, the WLC is really not the device to do this. The (re)marking of traffic is fine, enforcing policies is another story.