(R)STP BPDU filtering

[André Beck]

Re,

I've seen several threads here which started on the problem of BPDU filters, but all ran out without a solution. This sounds like there is none for ProCurve hardware, or am I wrong?

I'm asking because I have a case of a somewhat larger ProCurve network (23 switches so far ranging from 25xx to 41xx, with the core beeing switched and routed by a pair of 3400s) running RSTP that connects to two legacy domains running STP. These connections are leafs, single links, of course no loops through the STP domains. Now RSTP has this problem that *every* flap of a non-edge port causes an RSTP-domain wide topology change and on TC all legacy STP ports go out for a full circle of listening and learning. But I cannot accept connectivity to the legacy domain to drop for half a minute whenever some switch somewhere in the topology gets a kicking. So I'd really like to do the equivalent to Cisco's "bpdufilter" on these ports. The devices on the other side can't do it (as said, really old legacy stuff). So is it possible to create the equivalent of a per-port BPDU filter on any ProCurve platform or should I abandon all hope?

[Ralph Bean_2]

Hello André -

Are you saying that you want to prevent xSTP TCN BPDUs from going from some of the xSTP switches to other xSTP switches in the topology?

Ral

[André Beck]

Ralph: No, I just want to have certain ports which create an STP domain delimiter by filtering all BPDUs that would try to pass them. This way neither domain would know of the other so no influence can occur. Of course this is required only on the two ports facing to old STP legacy stuff. And of course I'm aware that after such setup, someone running a wrong patch can cause full network meltdown.

I'll have a look into the docs, maybe I can just create an mcast ACL that filters the BPDU destination address. Should do the trick, but I never before tried ACLs on ProCurves.

BTW, Meta: Is there really no way in this forum to reply/followup to something else but the thread opener?

Thanks,
Andre.

[Ralph Bean_2]

Andre -

I don't think you will be able to do this sort of filtering with ACLs.

What sort of 802.1d switches are attached to the ProCurve RSTP switches (3400cls)? Are they ProCurve switches, by any chance?

Ralph

[André Beck]

Re Ralph,

the legacy equipment in question is a Digital Networks VN900CG and a Cisco 4908G-L3. Don't wonder about the latter, this is a bastard of a Cisco 8500 class blade with router IOS. It can be made into a switch somehow, but it will break if STP is disabled on it alltogether (I've tried that, it just stops to bridge) and is going away soon, anyway. What bothers me is the large cloud of Digital Networks equipment behind the VN900CG, there is a complete FDDI ring and whatnot, plus it runs LAT which is extremly picky on the timeouts caused by STP relearning. AFAIR there is no chance to create a BPDU filter on the VN900CG, but I'll have a look anyway.

Andre.

[Bruce Campbell_3]

The 5400zl series running K.11.41 or
later supports:

bpdu-filter

Stop a specific port or ports from transmitting BPDUs, receiving BPDUs, and assume a continuous fowarding state.

[Mohieddin Kharnoub]

Hi

What you can do if you want to ignore any topology change coming from the old legacy domains, consider the ports connecting to these domains as "edge-ports" like Port-Fast, so RSTP will transition these ports to forward mode, of course you should be sure that none of these ports is blocked by the Spanning-Tree.

Good Luck !!!

[André Beck]

Bruce,

yep, I've read that in the K-series release notes already and got the feeling of having been heard. The remaining question is if (and when) it ever hits other platforms. Having just replaced the 3400cl in question with 6200yl this is not directly a need here, but further feature diversification in the ProCurve line is the sure way to evil. Not that we weren't half there, with K-series needing an extra license for any decent routing (for whomevers sake it's at least inluded with the 6200yl) or, even better, now choking even on *original* *HP* SFPs if they happen to have the wrong letter on them (has someone in Europe already tried to sue HP for this market abuse?). Together with them beeing squashed entirely by simply running PCM+ trafficd against them, they make a really great field experience. I'm still trying to relax from the last three days...

Andre.