Is there a way I can test PoE at the RJ45 connector?

[JWHolm81891]

So, I have an AP I took down because the light wasn't on. Consoled in and still dead, wouldn't populate on the controller either. Configured new AP C9115, and plugged it in to the mounting point and no light. It was fine when I configured it, but at this ceiling connection where it needs to be mounted, no life. I'm wondering if it's possible to test PoE at the connection here or if I have to do it some other way (never had to test for PoE before). 

I realize it could be the cable or the connector itself. I have no designs showing where this AP goes to. The closest switch stack isn't even on the diagram. I'd like to test to see if there's any juice before I start replacing cables or replacing connectors. 

[balaji.bandi]

Easy way, connect the Laptop to Ethernet cable, fnd the IP address and use that for MAC and port information

Take any spare AP near the stack port connect and see is the PoE able to power up AP ?

also check on switch any logs and have enough power to power on AP ?

[Leo Laohoo]

Depending on the model of the switch, TDR is not always "reliable" on IOS-XE.  I always tell people to take a VoIP phone whenever they troubleshoot cable faults.  

Our team have witnessed several IOS-XE cases where the TDR shows a fault, we got cablers in and tested, re-terminated the line but the IOS-XE switches still reports as fault on that particular port.  Move the patch cord to a different port (different switch member) and the port goes up.  

[Rich R]

@Leo Laohoo what models of switches did you see that on Leo?  And has it been raised with TAC?
Asking because we have 2 related cases open with TAC at the moment - not POE though - and TDR has produced some weird and wacky results, not even consistent from one test to the next on the same cable.

[Leo Laohoo]

---

@Rich R wrote:
what models of switches did you see that on Leo?

---

All or any switches that run on IOS-XE:  3650/3850, 9300.  I have do not have any 9200 & 9400 to test this on.

This was a common "behaviour feature" in 16.12.3, 16.12.4 and 16.12.5 (3850 & 9300).  I have recently recently found this problem has appeared on 17.3.4 and with an uptime of >20 weeks. 

This feature I have discussed is not to be confused with CSC vw97924.  This is a totally different bug/behaviour. 

---

@Rich R wrote:
And has it been raised with TAC?

---

No, it is a waste of time.  Because TAC's usual response is to reboot the switch as the "fix".

We have resigned to the fact that IOS-XE is so buggy we are starting to call it LOTUS, which stands for Lots Of Trouble, Usually Serious.  I do think the term is very apt.  

[JPavonM]

@Leo Laohoo do you have the bug id for this behaviour?

We are planning moving to 17.03.04 but if this defect is solved in 17.03.06 we will maybe wait for this to be released.

[Leo Laohoo]

---

@JPavonM wrote:
do you have the bug id for this behaviour?

---

I have not reported this to TAC and I have no intention to.  

I already have a good idea how TAC is going to "approach" this and it will go like this:  Reboot the offending switch member.  Did it fix the problem?  Good.  TAC Case close.  Thank you for calling.  

I cannot guarantee every firmware will have this bug.  Judging by the quality of the codes that is being churned out, I will treat every release as suspicious.  I have already stopped relying TDR results from IOS-XE as "accurate".  Troubleshooting steps are:

1. Get a known-working Cisco phone, connect at the end of the patch cable. 
2. If problem still exist, directly connect the phone to the switch port. 
3. If problem persist, directly connect the phone to another member of the switch.  
4. If Step 3 works, connect the remote end to the other switch member and then re-do only Step 1.  
5. If the phone works, the bug is now present and a reboot of the switch member will be a workaround.

Hope this helps.

[Rich R]

LOL thanks Leo.  We're seeing the funny stuff on C9300-48T running 17.6.2.
They haven't tried telling us to reboot - yet - but hey we're only a few months into the 1st case so far and achieved nothing after previous case closed due to older IOS (you know the upgrade to latest IOS "solution" of course).  We're seeing:
1. 1G copper port to Cisco UCS server suddenly drops to 100M
2. 1G copper port to Cisco UCS server suddenly stops forwarding traffic in 1 direction (black hole), no errors, ports up on both sides.
3. TDR returns strange results including often showing 65535 distance on pairs intermittently!

[Leo Laohoo]

---

@Rich R wrote:

3. TDR returns strange results including often showing 65535 distance on pairs intermittently!

---

Move the cable to another switch member and re-run the TDR test connect a known-working VoIP phone as a test.  Make sure the phone not just boots up but actually joins the UCM. This is the only indication that all 4 pairs are working.  

17.3.6 and 17.6.4 is about to drop (next few weeks).

[Rich R]

So after a lengthy WebEx with TAC and multiple tests they have concluded that multiple individual ports on multiple 9300's have gone faulty so they'll be RMAing all those 9300 chassis! They thought it might be an ASIC fault but 1 port faulty and others on the same ASIC working fine!

[Leo Laohoo]

Before you remove the switch from the stack, can someone please try and do a COLD reboot (completely power down the said stack member) and see if this "fixes" the issue. 

If this, indeed, fixes the issue and the output to the command "sh post" reveals no failed POST, then I have serious doubt this is an ASIC issue ... Unless this issue is caused by the two (related) MOSFET bugs:  CSCvj76259 & CSCvd46008.

[Rich R]

Thanks Leo.  TAC concluded not an ASIC issue when it was only a single port affected.
Those MOSFET bugs are specifically for POE and these are non-POE ports and we're running IOS which has both fixes so I don't think they apply in this case.

[ashish.kushwaha]

best way to connect ip phone quickly and check the POE is working or not.

[Leo Laohoo]

---

@ashish.kushwaha wrote:

best way to connect ip phone quickly and check the POE is working or not.

---

No, that is not correct.  Powering up a VoIP phone takes only one pair to achieve this.  What about the other three pairs? 

The correct method is to get a known, working phone and plug it into the same socket.  If the phone powers up AND joins UCM then it proves, at a minimum, 3 out of 4 pairs works and that is as good as it gets.