I'm going to prefix this with "may have missed something obvious" and "I might be a complete idiot" as this all feels way to weird to be real, but here goes (it's a bit wordy - apoligies)...

I've recently had some strange occurrences with HP switches and MT APs, specifically the cAP Lite and the wAP. I'm not doing anything particularly clever - I'm not using CAPsMAN, just a stand-alone unit. Using RouterOS v6.41 and ProCurve firmware P.2.22 (full version string is "HP ProCurve 1810G - 24 GE, P.2.22, eCos-2.0, CFE-2.1").

Scenario:

Switch - reset to defaults, three vLANs created (vLAN tags 1 (default - already present), 2 and 3), switch IP set to 192.168.99.2/24. Ports 1 and 2 are set to vLAN tag vLANs 1,2 and 3. No untagged traffic on those ports. Port 3 is an untagged port for vLAN 1, into which a laptop is plugged with an IP of 192.168.99.99/24. vLAN 1 is the admin vLAN.

So far so good - I can ping and manage the switch via its web interface.

wAP - reset to defaults with no default config, i.e. MAC-winbox access only. Configured to have a vLAN interface "vl-admin" on the ethernet interface, and an IP address of 192.168.99.3/24 is attached to the vLAN interface.
This too is good - no problems - I attach the wAP to port 1 of the switch (which has vLANs 1,2 and 3 tagged) and from an untagged port, can happily ping or ssh to 192.168.99.3 from my laptop. Excellent - all working as planned.

Then I add a second vLAN interface:
Fine, still working. So now a bridge
Again, fine. Now add the vlan interface to the bridge...
A couple of seconds after doing that, the entire switch stops passing traffic. No response to the switch management interface, no traffic to the wAP, nothing... Physical links are still there, but no traffic passing.

If I unplug the wAP, everything comes back to life. Plug it in, and after ethernet has negotiated, it goes down again.

Plug the wAP directly into the laptop, it works fine if I create a vLAN interface to talk to vLAN1 - I can log in and everything looks fine. If I remove the vlan port from the bridge and plug it back into the switch's tagged port, it works fine again until I re-add the vlan interface to the bridge.

Even if I remove all IP addresses from the wAP and use MAC telnet to manage the wAP, the moment the vLAN interface is attached to the bridge, the entire switch goes out to lunch.

This sounds completely braindamaged to me and unless I'd seen it with my own eyes, I wouldn't have believed it.

My only guess is something like LLDP or spanning tree is doing something weird, but I have no evidence to support this - logs from the wAP and switch do not show anything useful so far.

Does anyone have any ideas or am I going mad?

I'd say that it's a RSTP/MSTP issue.
Try adding the bridge w/o RSTP:
And/or set this port to edge manually in the switch.

-Chris

Deeper into detail, various loop protecting mechanisms are used by different vendors and even product lines of the same "vendor" which often happens because different product lines sold under the same brand have different OEMs.

Often the protective mechanism consists in shuting down a port if a BPDU (xSTP message) comes in through it when unexpected, i.e. if that port is deemed an edge one. What you describe (everything works until you interconnect the bridge on the routerboard with the Ethernet port) matches this behaviour, but I am a bit surprised that you say that the whole switch stops forwarding. Normally, only forwarding to/from the affected port alone is disabled, not the whole machine. I would start packet sniffing into a file on the RouterBoard before adding the vlan interface as a port of the bridge, and when the switch stops working, I would connect directly to the RouterBoard and hopefully see in the capture file (using Wireshark) what was going on there. I'm just afraid that the sniffing may stop automatically as soon as the management session breaks, but at least the beginning of the issue should be visible.

Try adding the bridge w/o RSTP:

Good call - that prevented the bridge pulling the switch over.

Often the protective mechanism consists in shuting down a port if a BPDU (xSTP message) comes in through it when unexpected, i.e. if that port is deemed an edge one. What you describe (everything works until you interconnect the bridge on the routerboard with the Ethernet port) matches this behaviour, but I am a bit surprised that you say that the whole switch stops forwarding.

Hehe you and me both! I could understand it perhaps isolating the port or a vLAN, but the whole thing goes out to lunch.

I would start packet sniffing into a file on the RouterBoard before adding the vlan interface as a port of the bridge, and when the switch stops working, I would connect directly to the RouterBoard and hopefully see in the capture file (using Wireshark) what was going on there.

It is indeed the first STP packet that kicks this off. Downing the port brings functionality back. Downgrading either the switch firmware image a few revisions or RouterOS to 6.39 prevents it from happening. P.2.22 switch with RouterOS >=6.40 causes the problem.

In my application STP is not (yet) required, so I'm happy to change the defaults on the bridges. Remembering to do so is the hard part!

Many thanks for your help, folks - much appreciated.

If you have any kind of feedback channel to HPE, I think they'd appreciate to learn this, it simply cannot be an intended behaviour.

If you have any kind of feedback channel to HPE, I think they'd appreciate to learn this, it simply cannot be an intended behaviour.

At least one of the switches involved has a valid support contract, so I'll stuff it in as a support ticket tomorrow. Given previous experience with HPE, I shall not be holding my breath however! Glad we caught it now as we're going to be deploying a Wireless Wire within the next couple of weeks and having just tested it, the same behaviour is present. Dodged a bullet there I think...

Sorry to bring up a old post but I stumbled across the same problem with a similiar setup. Curios to hear if you got any reply from HP?

My workaround is to configure STP (since RSTP breaks everything) on the HP switches but would of course like to use RSTP.

The HP1810G switch used by the OP didn't implement any spanning tree, but apparently violates network standards by passing BPDUs - see https://support.hpe.com/hpsc/doc/public ... -c02597134. I've used HP1810G v2 models which do support spanning tree correctly.

The mishandling, together with the Mikrotik configuration sending tagged BPDUs, is likely to have triggered the problem - see https://wiki.mikrotik.com/wiki/Manual:L ... idged_VLAN

To prevent Mikrotiks from violating network standards with regard to spanning tree the best option is to use a single VLAN aware bridge. Otherwise, if you have multiple bridges, ensure that the bridge to which the native ethernet interfaces are attached has spanning tree enabled, AND any other bridge to which ethernet VLAN (child) interfaces are attached have spanning tree disabled - I've successfully done this before VLAN aware bridges were implemented in RouterOS interworking with HP switches.