C917X PoE 802.3at support mGig Speed ?

[ReFeeL]

I saw in this Cisco deployment guide that it states support for 2.5 Gig Ethernet speed with 802.3at starting from IOS-XE 17.15.3. I am currently using a C9176I with a C9800 running 17.15.3, but I noticed that the speed does not show as 2.5 Gbps. I’m not sure if I may have misunderstood the statement in the document or if there’s something I might have missed.

this is result on Switch, C9800 and AP

Switch#show power inline

Module Available Used Remaining
(Watts) (Watts) (Watts)
------ --------- -------- ---------
1 240.0 30.0 210.0
Interface Admin Oper Power Device Class Max
(Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi1/0/1 auto off 0.0 n/a n/a 30.0
Gi1/0/2 auto off 0.0 n/a n/a 30.0
Gi1/0/3 auto off 0.0 n/a n/a 30.0
Gi1/0/4 auto off 0.0 n/a n/a 30.0
Gi1/0/5 auto off 0.0 n/a n/a 30.0
Gi1/0/6 auto off 0.0 n/a n/a 30.0
Te1/0/7 auto off 0.0 n/a n/a 30.0
Te1/0/8 auto on 30.0 CW9176I 4 30.0
Switch#
Switch#
Switch#show interface te1/0/8
TenGigabitEthernet1/0/8 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is f0b2.e556.f008 (bia f0b2.e556.f008)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 100/1G/2.5G/5G/10GBaseT
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:20, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 5000 bits/sec, 1 packets/sec
5 minute output rate 5000 bits/sec, 9 packets/sec
1097566 packets input, 888313577 bytes, 0 no buffer
Received 33630 broadcasts (8168 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 8168 multicast, 0 pause input
0 input packets with dribble condition detected
1607257 packets output, 1162065108 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

[Saikat Nandy]

What is the switch model & version you are using and can we have a show run int <AP int>

[ReFeeL]

Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 12 WS-C3560CX-8XPD-S 15.2(7)E3 C3560CX-UNIVERSALK9-M

[Saikat Nandy]

Could you please test this is in a 9K and see if you experience the same? I know it works with 9300.

[ReFeeL]

Only 9300? Can I use 3850?

[Leo Laohoo]

Only if the 3850 has mGIG port(s) AND can support 60wac per port.

[ReFeeL]

802.3at (PoE+) is 60w per port ?

[Leo Laohoo]

802.3at is known as PoE+ and supports up to 30.0wac per port.

802.3af is also known as uPoE and support up to 60.0wac per port.

[ReFeeL]

Yes, 802.3at is known as PoE+ and supports up to 30.0W per port. According to the document, it specifies 802.3at, not 802.3bt (60w), so there’s no need to provide 60W, correct?

Also, 802.3af refers to PoE with 15.4W, not UPoE (which provides 60W). UPoE corresponds to 802.3bt.

[marce1000]

   @ReFeeL                    >....so there’s no need to provide 60W, correct?
                   FYI : https://documentation.meraki.com/MR/MR_Installation_Guides/CW9176I_Installation_Guide#Power_Source_Options

     M.

[ReFeeL]

What about this document?

https://www.cisco.com/c/en/us/td/docs/wireless/access_point/technical-reference/cw9176-dg.html#PowerOverEthernet

[Rich R]

It's possible that the Cisco version of the document is wrong but it's also possible that the Catalyst and Meraki software behaviour is different.

I think the only way to settle it is to open a TAC case and ask - referring to both documents.
But before doing that I suggest trying Leo's suggestion of switching from using CDP to using LLDP just to see what effect that has, if any since the numbers they quote are generally based on LLDP.
If TAC concludes the data sheet is wrong they'll raise a documentation bug to get the data sheet updated.

But - and I've highlighted this on multiple other posts previously - the PoE data on the AP data sheets has a history of being unreliable and when questioned with the Cisco Wireless BU they defend the incorrect numbers by saying that they show the actual AP power consumption, but that that does not necessarily correspond to the actual power the AP requests from the PoE power source which usually has around 10% added for line losses and other unspecified losses and then often gets rounded up by the software.  So take that data as a rough guide and always test for yourself to find the real numbers.  I gave up arguing this one with the BU, trying to explain the importance of accurate specifications for power budgets.  We now know that we have to just test ourselves when we get the first AP of each model.  Once we know the real power consumption we can set a static PoE limit on the AP ports (sometimes takes some trial and error) which allows the AP to operate at full power without allocating more power than it needs on the switch.  This makes the power budget go further than it otherwise would if they were just left to their own devices to reserve way more power than needed, meaning the switch power budget runs out much quicker than it should.

[Leo Laohoo]

---

@Rich R wrote:
If TAC concludes the data sheet is wrong they'll raise a documentation bug to get the data sheet updated.

---

LLDP was deliberately used because the power draw value is a lot LESS than CDP power draw values.  If the CDP power draw values were used in the Data Sheet it would have dissuaded some customers from buying the Cisco Cheetah-based APs.  

This line of reason came from both TAC and WNBU.  

[ReFeeL]

I believe the issue might be related to the software version on the C9800. When using Catalyst mode and joining the C9800 with versions 17.15.2, 17.15.3, and 17.17.1, it didn’t work. However, when I tested by converting to Meraki mode, I was able to achieve 2.5Gbps as expected.

[Leo Laohoo]

A new "undocumented feature".