11-07-2018 06:50 AM - edited 03-08-2019 04:34 PM
I have a remote office and I have seen this problem constantly but I can't pin down why. We have a single AP connected to an 2960xr running 15.0(2)EX5 in a remote office in a country without the best wiring practices. However this problem seems to be specific to whatever port is connected to the AP which has already been replaced. The only thing I notice is that is auto negotiating to 100Mbps but not sure that would cause the port to constantly flap. Its an MR18 which is 10/100/1000 and when I hard code the port the AP doesn't come up so I just assume their is a dumb switch on the other end.
2960-3rdworld#show int gi1/0/47 GigabitEthernet1/0/47 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 8890.8dda.6eaf (bia 8890.8dda.6eaf) Description: ###access to ap-meraki18### MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/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:00, 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 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 3317664 packets input, 704875181 bytes, 0 no buffer Received 322826 broadcasts (197335 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 197335 multicast, 0 pause input 0 input packets with dribble condition detected 6176535 packets output, 2229684212 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 104351 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 2960-3rdworld#sho controllers e gi1/0/47 Transmit GigabitEthernet1/0/47 Receive 2229683065 Bytes 704874416 Bytes 3877481 Unicast frames 2994835 Unicast frames 2291990 Multicast frames 197333 Multicast frames 7050 Broadcast frames 125491 Broadcast frames 0 Too old frames 672434342 Unicast bytes 0 Deferred frames 22440476 Multicast bytes 0 MTU exceeded frames 9999598 Broadcast bytes 0 1 collision frames 0 Alignment errors 0 2 collision frames 0 FCS errors 0 3 collision frames 0 Oversize frames 0 4 collision frames 0 Undersize frames 0 5 collision frames 0 Collision fragments 0 6 collision frames 0 7 collision frames 683532 Minimum size frames 0 8 collision frames 1174545 65 to 127 byte frames 0 9 collision frames 967691 128 to 255 byte frames 0 10 collision frames 213871 256 to 511 byte frames 0 11 collision frames 80934 512 to 1023 byte frames 0 12 collision frames 197086 1024 to 1518 byte frames 0 13 collision frames 0 Overrun frames 0 14 collision frames 0 Pause frames 0 15 collision frames 0 Excessive collisions 0 Symbol error frames 0 Late collisions 0 Invalid frames, too large 0 VLAN discard frames 0 Valid frames, too large 0 Excess defer frames 0 Invalid frames, too small 2253782 64 byte frames 0 Valid frames, too small 1342884 127 byte frames 1088508 255 byte frames 0 Too old frames 275386 511 byte frames 0 Valid oversize frames 129972 1023 byte frames 0 System FCS error frames 1085989 1518 byte frames 0 RxPortFifoFull drop frame 0 Too large frames 0 Good (1 coll) frames 0 Good (>1 coll) frames Nov 7 12:41:31.876 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to down Nov 7 12:41:48.630 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to up Nov 7 12:41:49.633 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to up Nov 7 12:44:56.249 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to down Nov 7 12:44:57.249 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to down Nov 7 12:45:14.244 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to up Nov 7 12:45:15.243 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:02:53.214 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to down Nov 7 16:02:54.217 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to down Nov 7 16:03:11.012 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:03:12.012 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:12:48.670 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to down Nov 7 16:12:49.687 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to down Nov 7 16:13:06.430 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:13:07.430 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:14:59.395 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to down Nov 7 16:15:00.395 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to down Nov 7 16:15:17.312 GST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:15:18.316 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to up Nov 7 16:54:57.380 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to down
11-07-2018 06:54 AM
Hello,
just to be sure, are both ports configured as trunk ports ?
11-07-2018 06:58 AM - edited 11-07-2018 06:58 AM
Nah just access port on the cisco side and nothing on the Meraki side (no vlan tagging). I just removed the spanning-tree portfast command but not sure that would cause what I have been seeing?
interface GigabitEthernet1/0/47 description #apmr18# switchport access vlan 10 switchport mode accessspanning-tree portfast
11-07-2018 07:12 AM
Hello,
--> in a remote office in a country without the best wiring practices
Do you have someone available at the site who can connect the Meraki directly to the switch ?
11-07-2018 07:16 AM
11-07-2018 07:59 AM - edited 11-07-2018 08:02 AM
Hello
crc errors - L1 - check cabling
Dont forget meraki aps are poe check if it’s getting enough power
11-07-2018 08:02 AM
11-07-2018 08:11 AM - edited 11-07-2018 08:15 AM
Hello
yeap correct looking from phone so it truncated the output
This is a switch correct?
Do you have Cdp-lldp -DTP active if so try turning them off
int x/x
switchport mode access
no cdp run
no lldp run
11-07-2018 08:17 AM - edited 11-07-2018 08:17 AM
Layer 3 switch or layer 2 router whatever you want to call it. CDP is enabled.
What is odd is that on Meraki portal it shows the AP is constantly connected (all green) but I see it flapping in the wind.
Device ID Local Intrfce Holdtme Capability Platform Port ID 00180a7b5882 Gig 1/0/47 153 R S Meraki MR Port 0
11-07-2018 08:20 AM - edited 11-07-2018 08:22 AM
Hello
i would
1- not hardcore the port
2- turn off cdp - try lldp
3- check the power being supplied by the access port
4- change cabling
5- change port
11-07-2018 08:23 AM
2960-3rdworld#show power inline gi1/0/47 Interface Admin Oper Power Device Class Max (Watts) --------- ------ ---------- ------- ------------------- ----- ---- Gi1/0/47 auto on 15.4 Meraki MR18 Cloud M 0 30.0 Interface AdminPowerMax AdminConsumption (Watts) (Watts) ---------- --------------- -------------------- Gi1/0/47 30.0 30.0
1 - port is auto/auto but when I tried to hard code it it wouldn't come up
2 - why disable CDP?
3 - power is above
4 - will try another cable
5 - did this prior but the problem seem to follow the port, will try another port
11-07-2018 08:32 AM
Hello
Meant to say turn cdp off and try lldp
also has that ap firmware upto date ? Has it recently had an update ? If so try reverting the update and see if that helps or updating it if it hasn’t meraki are keen on pushing out updates and if you haven’t deferred it than it goes on regardless
11-07-2018 08:36 AM
11-07-2018 08:40 AM
Lldp is non vendor specific as aposed to cdp which is proprietary to Cisco
as meraki supports both worth a shot at llldp may help with those deferred drops
11-08-2018 05:53 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide