Cisco’s “Enterprise Networks Core and WAN Exam”

Cisco’s partner program currently contains four specializations. Besides having multiple individuals owning certain “regular” certifications like a CCNP or CCIE, also additional exams are required to fulfill certain roles and achieve the specialization.

One of those additional exams is called “Enterprise Networks Core and WAN Exam (ENCWE)” with number 500-452. Besides the blueprint itself and a full-blown training Cisco does not provide specific content for this exam.

I have recently passed this exam and, without breaking the NDA, I highly recommend you to watch and study the materials presented in the following two Cisco Live sessions:
BRKCRS-2002 IWAN Design and Deployment Workshop
BRKARC-2091 Emerging Trends in Branch Office Architectures

Doing so, in addition to a quick refresher on the CCDP content, was sufficient for me to pass this exam. Good luck with your studies!

Cisco 3702 on (regular) PoE

It has almost been one year since my last post, so it is really time to write something again 🙂 .

The transmit power of a radio within an access-point is being represented based on power-levels within the Cisco controller world. I have already written a post about these power-levels and how the configured gain of the antenna is related in the past. But did you know that besides the gain, the regulatory domain and specific channel also the input power of the access-point itself might influence the actual transmit power?

With the 3800 serie access-points the radios cannot be enabled when the run on regular PoE, this behavior is different with the 3700 serie. The 3700 access-point will work, but with one receive and one transmit antenna disabled. Besides that also the transmit power changes. Below some calculation examples based on an 3702I-E access-point. So, my advice is to always verify on the cli of the controller with the “show advanced 802.11x txpower” so you can, besides the power-levels, also see the dBm values which the represent.

Input power Antennas Channel Max. EIRP PL1 PL2 PL3 PL4 PL5 PL6 PL7 PL8
PoE Rx: 3, Tx: 3 36 23 dBm 17 dBm 14 dBm 11 dBm 8 dBm 5 dBm 2 dBm
132 30 dBm 17 dBm 14 dBm 11 dBm 8 dBm 5 dBm 2 dBm
PoE+ Rx: 4, Tx: 4 36 23 dBm 18 dBm 15 dBm 12 dBm 9 dBm 6 dBm 3 dBm
132 30 dBm 23 dBm 20 dBm 17 dBm 14 dBm 11 dBm 8 dBm 5 dBm 2 dBm

Deny traffic on autonomous APs

There are quite a few methods to filter certain kinds of traffic on Cisco’s autonomous access-points. This post gives a overview of the different methods and how to use them based on use cases.

Use case Configuration
Deny wireless client to associate with AP access-list 700 deny 1c1d.862c.70f0 0000.0000.0000
access-list 700 permit 0000.0000.0000 ffff.ffff.ffffdot11 association mac-list 700
Deny wireless client to associate with specific SSID access-list 700 deny 1c1d.862c.70f0 0000.0000.0000
access-list 700 permit 0000.0000.0000 ffff.ffff.ffffinterface Dot11RadioX.X
bridge-group x input-address-list 700
Deny wireless client to client traffic interface Dot11RadioX.X
bridge-group x port-protected
Deny wireless to wired IPv4 traffic ip access-list extended ACL-IPV4-DENY
deny icmp any any
permit ip any anyinterface Dot11RadioX.X
ip access-group ACL-IPV4-DENY in
Deny wireless to wired IPv6 traffic ipv6 access-list ACL-IPV6-DENY
deny icmp any any
permit ipv6 any anyinterface Dot11RadioX
ipv6 traffic-filter ACL-IPV6-DENY in

Note: it is possible to apply this ACL on a sub interface as well (just as with IPv4), however this does not have any effect on the traffic. See also bug CSCva17063.

Deny wired to wireless IPv4 traffic ip access-list extended ACL-IPV4-DENY
deny icmp any any
permit ip any anyinterface gigabitEthernetX.X
ip access-group ACL-IPV4-DENY in
Deny wired to wireless IPv6 traffic ipv6 access-list ACL-IPV6-DENY
deny icmp any any
permit ipv6 any anyinterface gigabitEthernetX
ipv6 traffic-filter ACL-IPV6-DENY in

Note: it is possible to apply this ACL on a sub interface as well (just as with IPv4), however this does not have any effect on the traffic. See also bug CSCva17063.

WLC management authentication based on RADIUS

This post is a quick reference for configuring management authentication with RADIUS for AirOS and IOS-XE based WLCs.

Platform RADIUS server configuration
AirOS Protocol: PAP_ASCII
Match on: Radius Service-Type equals “Nas Prompt”
Return back: Radius Service-Type = Administrative (full access)
Return back: Radius Service-Type = Nas Prompt (read-only access)
Return back: Radius Service-Type = Call-Back Administrative (lobby admin)
Match on: Radius NAS Port id contains “tty” (for CLI)
Match on: Radius NAS Port Type “Virtual” (for GUI)
Return back: Cisco cisco-av-pair = shell:priv-lvl=15

Cisco ONE licensing and 5508 WLC

When new licensing models are being published the first thing that vendors release are the marketing brochures. Due to this is selling the new “stuff” usually not the biggest problem (except when certain features have been moved to another “level”, but how often does that happen.. right?..). The more difficult part is finding out how the new process works and which codes, files and/or commands need to be entered on the box to get it running. This post is about Cisco ONE licensing in conjunction with the 5508 WLC to help fellow engineers 🙂 .

Regular licensing for the 5508 WLC is pretty straightforward: you buy a 5508 with a certain amount of AP licenses on it and you can upgrade this amount if needed up to 500 AP licenses. It gets a little more complicated if you add HA SSO in the mix: the primary 5508 needs to have a permanent license (12 AP licenses is enough), the secondary 5508 needs to be at least licensed with 50 AP licenses or needs to be a dedicated HA SKU unit (which is just as expensive as a regular 5508 with 50 AP licenses).

With Cisco ONE the idea is that you always buy controllers (C1-AIR-CT5508-K9) with zero AP licenses and depending on your needs you buy a certain amount of C1 licenses. The nice part with those C1 licenses is that also node licenses for Prime Infrastructure, MSE and ISE are included so you don’t need to order them separately anymore. When you order the controllers and C1 licenses you will receive a eDelivery link to download the PAK codes. Those PAK codes can be registered on the Cisco website and will give you for the 5508 controller regular LIC files which you need to upload to the controller. Nice detail: the C1-AIR-CT5508-K9 controller without any licenses can function as a HA SKU as well, which is a much cheaper solution comparing to the regular licensing.

What about mixing this new license model with install base? This is the tricky part. The official statement that I received from Cisco is that mixing the old and new licensing model is not supported and the install base should be migrated to the new form of licensing. From my own testing I can say that you can pair a regular licensed 5508 with an C1 controller as secondary unit in HA SSO setup without any problems. Same goes for upgrading the AP licenses of regular licensed controllers with C1 licenses. Official documentation regarding this is simply not available but I don’t think that Cisco wants you do to that…

Hopefully this information helps with your first Cisco ONE implementation 🙂

Advanced roaming features

Disclaimer: I did not test all the below described features in a production network. Some features require support/feedback from the client itself which is not always there or clients are getting confused by enabling this features with a bad user experience as result. Always make sure to monitor the impact of your changes and test upfront as much as possible. Keep in mind that a good wireless infrastructure starts with a good RF design and multiple validation site surveys. These features can only help to further optimize.

There are quite a few features available on the AirOS controllers and access-points which are (indirect) related to roaming. Some of them are Cisco proprietary and some are based on industry standards, but all of them share the goal to use the RF as efficient as possible and positive influence the user experience.

For my CCIEW studies I created the list below with relevant features based on 8.0 version of AirOS code.

Feature Client support required Description
Rx SOP No Force clients to roam or leave the WiFi network by ignoring frames on the radio level with a certain signal strength.

Rx SOP Configurations are supported on AP1600, AP2600, AP2700, AP3500, AP3600, AP3700 and AP1550 only.

RSSI Low Check No Motivate clients to use another access-point or leave the WiFi network by denying clients with a certain signal strength to associate.
Optimized roaming No Motivate clients to use another access-point by disassociate clients with a certain signal strength.

Optimized roaming uses some of the values configured within the coverage hole detection mechanism.

Aggressive load balancing* No Clients are being motivated to use another access-point.

APs in local mode will send a code 17 (AP busy) message, with Flexconnect APs the client is being de-authenticated.

Band select No Motivate dual-band clients to use 5 Ghz instead of 2.4 Ghz by delaying probe responses on the 2.4 GHz.
Assisted roaming (802.11k)* Yes Inform clients about alternative APs to limit the need for active and passive scanning on the client when it wants to roam. After a certain amount of denied association responses the client will be allowed.

The prediction part of the Cisco implementation is not based on 802.11k and does not require client support.

Fast Transition (802.11r) Yes Introduces a concept of roaming where the initial handshake with the new AP is done even before the client roams to the target AP.
CCX Client Roaming Yes Provide CCXv4 enabled clients with roaming configuration parameters to direct influence the roaming behavior.

*: Because both load balancing and assisted roaming are designed to influence the AP that a client associates with, it is not possible to enable both the options at the same time on a WLAN.

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

CAT1(config)#aaa new-model
CAT1(config)#radius server AAA-RADIUS-ISE01
CAT1(config-radius-server)#address ipv4 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
Authentication policy
Authorization policy

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

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     5247    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          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.


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 – and MA (CAT2 –

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

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 and multicast group 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 :

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.


4. Multicast traffic between MCs (in different mobility domains)
In this scenario both CAT1 ( and CAT2 ( 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
CAT1(config)#wireless mobility group member ip group MC2
CAT1(config)#wireless mobility group multicast-address MC2 ip
CAT2(config)#wireless mobility controller
CAT2(config)#wireless mobility group name MC2
CAT2(config)#wireless mobility multicast ip
CAT2(config)#wireless mobility group member ip group MC1
CAT2(config)#wireless mobility group multicast-address MC1 ip

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.