Wireless Access

I have a powered IAP-175 that is in a freezer. The unit has been working fine until recently I got a report that the IAP was not functioning. I logged onto the VC and noticed the AP was missing. On the switch I see the AP connected and via ARP I can see it is getting an address via DHCP. I can't ping the AP by that address, which made me question what was going on.

I looked at the switch port and the output shows there are "unkown protocol errors". I reset the interface to see if the errors kept occurring and they have. I cleared the configuration on the switchport and told it to do nonnegotiate. The errors keep occurring. Cisco says the unknown protocol errors have to know with lets say one device talking cdp and the other not. Anyways below is the output and the switchport config.

Any advice or suggestions?

GigabitEthernet1/0/44 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is f029.29d5.0cac (bia f029.29d5.0cac)
  Description: AP-14
  MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 10Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:07, output 00:00:01, output hang never
  Last clearing of "show interface" counters 2d00h
  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 0 bits/sec, 0 packets/sec
  5 minute output rate 1000 bits/sec, 3 packets/sec
     211275 packets input, 23549727 bytes, 0 no buffer
     Received 211260 broadcasts (5837 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 5837 multicast, 0 pause input
     0 input packets with dribble condition detected
     683436 packets output, 67277126 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     5815 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

interface GigabitEthernet1/0/44
 description AP-14
 switchport access vlan 20
 switchport mode access
 switchport nonegotiate
 switchport voice vlan 11
 spanning-tree portfast

If you issue no cdp enable on that port and then clear counters, do you still see the unknown protocol errors?

It is also interesting that it is negotiating 10M full. What happens if you hard set the speed to 1000 full ?

I did the no cdp enable command, shut the port down, cleared the counters and the issue persisted. I then shut the port down, cleared the counters and hard coded the speed to 1000, the AP doesn't come up. When I hard code it to 100 it appears to keep rebooting as I can get to a ssh prompt but never can login and it constantly goes up and down. I'm wondering if it is a nic is bad. I don't believe it is cabling because I'm not seeing any input or CRC errors.

I'm not in the same location as the AP or I would take it down and perform some tests.

Is there someone on site that can try a different switch port?

I finally found the combination that makes the device work. I set the speed to 100 and cycled the port a couple of times and it finally came up. I'm going to try another switchport for the heck of it because I want the full gig speed. If that doesn't work, I'll open a TAC case. Take advantage of the warranty.

I think Cisco may be not giving you the attention to the problem you need.  Firstly if CDP frames were being sent to the AP, I see no reason why this would increment the unknown errors counter - rather this counter increment on the cisco should be a reflection on traffic te cisco recieves - and not transmits.

I would firstly suggest checking this error against any other APs connected to your ciscos - as I imagine you use cisco as a switch standard.  See if these errors increment to the same degree.  Does this stand out?  Is it unusual?

Perhaps move the switchport and check if the increment of unknown errors follow the port, or if this stays were it is.

Perhaps your cisco  can run a TDR test, whereby you can test wiring continuity and validate for any shorts in the pairs in the cabling - this is intrusive and may bounce the AP:

      test cable-diagnostics tdr interface (whatever the switchport is)

Then review results:

      show cable-diagnostics rdr interface (whatever the switchport is)

Check or terminated results - and look for the cable distance returned on the TDR check.  Make sure your distances are right.

Given the freezer location - you may be getting cross talk (unlikely), or interference if you are using unshielded cabling that, may be introducing problems (unshielded cabling runs near flourcent lights?).  Maybe?

A more probable cause - I believe will be the switchport counter more likely to be receiving ADP frames (arubas layer 2 identification) - perhaps if you really want to, you could look to disable this - perhaps?  But why would you?  

Other than that (I think the unknown error could be a red herring IMHO)  - I would look for cable distance, and get an idea of a loss of continuity on some of the pairs - if you do not have all four pairs wired I belieive gig may not be possible.  

Any chance you could change the AP round with one you know to be in good working order?

Cheers.

Thanks for the reply. I thought about running the diagnostics test but I was concerned with the unknown protocol drops and I eventually got it working again. So I thought....

Again it keeps power cycling and I'm moving my attention away from the protocol drops. I checked our different sites and all of the Aruba APs have that counter on the switchports. I ran the cable test and there is an open pair. Thanks for the suggestion.

cool! :smileyvery-happy: