Tuesday, May 30, 2017

Cisco 1532i PoE+ vs. UPoE

 

Many times when researching product information, we come up with multiple documents that sometimes state conflicting information. 

The point of writing this is simple.  If you are a networking professional, know what you are deploying.  Reading product documentation is not enough - we must thoroughly test the product for the environment we are going to use it in.  If you want  to deploy the latest Meraki access point, ask them and they will send it to you - if you don't want it, they'll let you send it back. 

Here is an example of finding conflicting information about a product, and verifying what's going on under the hood. 

When deploying the Cisco 1532 series access points, you should determine what the power requirements are.   Let's start searching.

The first document can be found here:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/b_1532_dg/b_1532_dg_chapter_01.html

The AP 1532 series is an ultra low-profile outdoor access point. This AP has two models, an internal antenna model and an external antenna model.

If you look closely, you will find that these access points are not the same AP with the exception of external and interal antennas.  The 2.4 GHz radios are different on the two access points.  The 1532i has a 3x3:3, and the other is a 2x2:2.  The 1532i  requires UPoE, while the other requires the lower wattage 802.3at power.  That makes sense - if there are more transmitters in the access point with internal antennas, it would require more power.  This might translate into needing different PoE switches (PoE+, UPoE) depending on which models you are deploying around your facility.

If you don't know what that means, no worries.  This graphic will better show you a 2x2:3 has two transmitters, and a 3x3:3 has three transmitters.

 

The number of transmitters relates to the number of available data rates.  More transmitters = more bandwidth.  For simplicity, we are going to say that 1x1 - 65Mbit/s, 2x2 = 130 Mbit/s, and 3x3 = 195 Mbit/s.

Our research so far states that the 1532i needs UPoE, and the 1532e needs PoE+, and the internal access point is capable of 195 Mbit/s, and the 1532e is capable of 130 Mbit/s.

Another document we found states that both access points can  be powered up using PoE+ switches, but the 1532i will power off one of the 2.4 GHz transmitters.  That might not make sense to someone not familiar with 802.11n.

 

http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1530-series/guide-c07-729725.pdf

Another way to say that would be, "when the Cisco 1532i is powered using PoE+, the access point will automatically turn off one of the 2.4GHz transmitters and the AP will be reduced to a 2x3:2 (130 Mbits/s) from a 3x3:3 (195 Mbit/s) capable access point, and the 5GHz radio is not affected).

One thing to note is the 1532e series access point is capable of 2x2:2 on the 2.4GHz radio.  Powering the 1532i with a PoE+ switch effectively makes both of the access points capable of the same data rates - though the 1532i still has three receivers and the 1532e has two.

After digging and deciphering the information ourselves, we stumble across another document that states the above facts more eloquently.

http://www.cisco.com/c/en/us/td/docs/wireless/access_point/1530/installation/guide/1530hig/1530_ch2.html#24750

If the 1532I is powered by a PoE+ (802.3at power) switch port or the AIR-PWRINJ-30= power injector, then the access point will automatically disable one of the 2.4 GHz transmitters and the radio will operate in 2x3 MIMO mode.

 

Now we have it figured out.  If the AP will meet our requirements as a 2x2:3 access point, then it is okay to use it on PoE+ switches.  It might be a good idea to know for sure, so we'll open up our protocol analyzer and double check.  We see the appropriate number of MCS rates per the  quantity of spatial streams per the document we found.

 

 

These "baseline" protocol captures might also come in handy in the future.  After an operating system upgrade, your roaming or some other functionality might seem to change behaviour, and it might come in handy to have a baseline capture of when your system was working well.