Hi there,

we are using serval Mikrotik AccessPoint in our Company. Alle AcessPoint are used in CAP-mode in serveral lokations.
CAPSMAN and most of the AccessPoints are working without problems.

Alle APs are connectet through HP Procurve Switches (29 Series, 26 Series, 25 Series and 54 Series) and are powered by pe directly from the Switch.

Now we have to accesspoints, where the software on the Switch get stuck if a AP is connected. The APs have got the same configuration as any other of our APs.
If we disconnet the AP the switch runs normal again.

I'm not exactly shure, but could this beheavior a result of a Spanning-Tree configuration on the switch or the AccessPoint?

Port config on a running Switch:
Port config on a Switch which get stuck: Both switches and all APs uses the same version of RouterOS / HP Procurve Firmware.

If I use a AP in default config ( Routing between WLAN and LAN, DHCP and so on) the Switch doesn't get stuck.

Can someone verify my guess?

Best Regards
David Lausch

I‘ve done some test this evening,...
The STP config on the port dosen‘t have some insect of the switch and AP Problem.

I figured out also that the switch doesn’t get stuck but it looses alle connections to the ip net, the connected clients also.
Connection via serial Console already works...

It doesn’t matter in which VLAN the AP is connected, if routeros is up an running, the switch looses all connection.

Turned MSTP off on the Switch side, same situation.

Some Ideas?

Further tests:

Reset wAP to factory default, connect AP to the switch, everything is fine...

If I do System —> reset configuration—>> enable CAPS mode, AP reboot and after RouterOS is up, Switch looses Connectivity...

APs RouterOS Version 6.43.14 also board firmware

HP procurve 5406 zl Firmware version 16.02.xxx

There are also no usefull Logs on the Switch, only Port online and port offline.....

As STP as such is unable to deal with some unusual breakdowns in the network, some vendors add proprietary protocols which address these cases, and as these efforts are not coordinated, sometimes equipment from one vendor misinterprets packets from other vendors and disconnects ports or does even weirder things. But this does not seem to be your case as from what you wrote I understood that the switch doesn't just block the port to which the cAP is connected (which is what usually happens in these cases) but you lose IP access to the management of the switch while the switch continues forwarding other traffic, is that right?

If so, would suspect some MAC address or IP address conflict, causing the switch to start sending responses to management requests to the cAP rather than to its regular gateway or to the management server. So my first test would be to permit management access to the switch from an IP address in the same subnet as the own management IP address of the switch, set that address on a PC connected directly to the switch, and once you check that this management connection (which uses neither the default gateway nor the IP address of the central management workstation) works, connect the cAP and see whether you lose the access from that PC or not.

If you lose access to IP management of the ProCurve upon connection of the cAP even in the arrangement above, it is also possible that the CPU of the switch is overloaded or just confused with some traffic coming from the cAP. Switches normally continue forwarding even if their management CPU is not in perfect shape. So if management from LAN fails as well when you connect the cAP, take a dumb switch, connect the cAP to it and run packet sniffer on the cAP to see what it sends (sniff to a file and then use Wireshark to analyse that file). Sniff for, say, 30 seconds while the cAP is only connected to the dumb switch, and then connect the dumb switch to the ProCurve and continue sniffing for another 30 seconds.

Good Morning Sindy,

thank you for your reply...

... I understood that the switch doesn't just block the port to which the cAP is connected (which is what usually happens in these cases) but you lose IP access to the management of the switch while the switch continues forwarding other traffic, is that right?...

The Switch doesn't block the port is right, but not only the managemant of the switch is dead. All connectet Clients (Computers, printers, Phones and so on) are loosing connectivity to network. It looks like the switch disables the uplink ports...

What I will check when I'm well again is, if the wAP is plugged in, can I connect the switch form a lokal client without using the uplink from the core switch. I hope to find out, if this is a problem with a misconfigurated Uplink or the Switch itselfes.
Unfortunately, I can only test this in the evening, because the productive operation is running during the day.

Thank you
David

The Switch doesn't block the port is right, but not only the managemant of the switch is dead. All connectet Clients (Computers, printers, Phones and so on) are loosing connectivity to network.

Okay, so I've misunderstood what you wrote earlier:

I figured out also that the switch doesn’t get stuck but it looses alle connections to the ip net, the connected clients also.

I've concentrated on the "IP" part, not on the "connected clients also" which I now understand to mean "other devices connected to the ProCurve lose their network connections as well".

That information changes the perspective, so yes, it is more likely that it is an L2 issue, and it is not excluded that some frames sent by the Mikrotik in cAP mode (can you provide the export of the cAPs configuration following the guidelines in my automatic signature?) are forwarded by the ProCurve (because it doesn't recognize them as local link messages which should not be forwarded) and confuse not the ProCurve itself but the switch to which it is connected.

So first show us the export of the configuration of the cAP, and if you can, also the file from the sniffer taken while the "dangerous" cAP is connected only to a dumb switch, not to the ProCurve directly or indirectly, so you can run the sniffer during business hours (post the file downloaded from the cAP somewhere and provide a link to it here).

My first suspicion would be that when the Mikrotik is in cAP configuration, it connects to the ProCurve via a member port of /interface bridge with protocol-mode set to rstp which is the default, and that for some reason the ProCurve does not identify the RSTP frames as STP ones and handles them as any other L2 frame with an unknown destination MAC address, i.e. broadcasts them to all ports although the destination MAC address is one of the "link-local" ones so the frames should not be forwarded. But as this would be a significant bug, and as you say that other cAPs have an identical configuration and don't cause the same issue, it is nothing more than a working hypothesis. But to be sure, please check also that the RouterOS version and firmware version is the same on the "good" and "bad" Mikrotik devices, and also on the "affected" and "unaffected" ProCurve devices.

Thinking back to when I had a lot of procurve switches, there is a separate "loop-protect" feature which may help protect against some network loops separately from spanning tree. We used this to protect against loops on mac-auth edge ports, which doesn't sound anything like your case, but it might help regardless...

syntax was something like

loop-protect 1-24
loop-protect disable-timer 86400

and we used this on the same series switches as you (35xx, 38xx, 54xx etc).

Problem solved...

Inspired by the post of sindy

My first suspicion would be that when the Mikrotik is in cAP configuration, it connects to the ProCurve via a member port of /interface bridge with protocol-mode set to rstp which is the default, and that for some reason the ProCurve does not identify the RSTP frames as STP ones and handles them as any other L2 frame with an unknown destination MAC address, i.e. broadcasts them to all ports although the destination MAC address is one of the "link-local" ones so the frames should not be forwarded. But as this would be a significant bug, and as you say that other cAPs have an identical configuration and don't cause the same issue, it is nothing more than a working hypothesis. But to be sure, please check also that the RouterOS version and firmware version is the same on the "good" and "bad" Mikrotik devices, and also on the "affected" and "unaffected" ProCurve devices.

I checked the complete STP configuration on all involved switches.

Core SW1 -->TRUNK--> Edge Sw --> wAP-AccessPoint

STP was disabled/not configured on the EdgeSwitch. So if the wAP was connected to the EdgeSwitch all STP Packages were forwarded to the CoreSW. The CoreSW disabled by STP the Ports for the trunk. That was the result why the EdgeSw lost all connections.

spannting-tree xy admin-edge
spannting-tree xy pvst-filter bpdu-filter root-guard

diden't solved the problem
The packages were also forwarded and processed by the CoreSW.

Now I Enabled MSTP at the Edge Switch. The EdgeSwitch is now processing the STP packages and doesn't forwared it to the CoreSW.
This solved the problem.

Thanks to all who helped me on the way to the solution.
Have nice eastern...