STP BPDU filtering - is it possible without bpdufilter?

[Alexey Stytsenko]

Good day, folks.

Recently i red document Port ACLs (PACLs) and VLAN ACLs (VACLs) which is the part of Catalyst 6500 Software Configuration Guide and noticed there following:

The PACL feature does not affect Layer 2 control packets received on the port.

but previosly i red in Petr Lapukhov blog (one of http://blog.ine.com posters) folowing:

The  IEEE STP BPDUs are sent to IEEE reserved multicast MAC address   “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP   and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2   filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value   of ”0×4242”).

And  now im a bit confused - STP BPDUs is not control traffic or Layer2  filtering meaned in Petr blog is not PACL (but what then - VACL???) ?

If smb can clarify those question i will higly appreciate this.

[Peter Paluch · Accepted solution]

Hello Alexey,

The ability or inability to filter the control traffic at the L2 is probably dependent on the hardware platform. I have went over the 2960 and 3560 configuration guides and there is no mention that PACLs do not apply to L2 control traffic. However, in the C6500 configuration guide at

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vacl.html#wp1039754

it is stated:

PACLs  cannot filter Physical Link Protocols and Logical Link Protocols, such  as CDP, VTP, DTP, PAgP, UDLD, and STP, because the protocols are  redirected to the switch processor (SP) before the ACL takes effect.

That would explain what you read in the other documentation.

ACLs are one of multiple things performed in hardware, and as each switching platform uses a different hardware, different limitations may apply. You always have to consult the appropriate documentation to see if there are any relevant restrictions.

Best regards,

Peter

[rsimoni · Accepted solution]

Hello,

I can also add to what Peter wrote some other info pertaining to cat6500 regarding this topic.

As Peter pointed out the BPDU's are always punted to the CPU at hardware level (referring to port ASIC level) before VACL or Mac ACL are applied as all ACL logic occurs at EARL level (PFC) but if a packet is punted to the CPU (the SP component) from the port ASIC it would not go through Earl at all.

The reason is that the MAC register component looks for the BDPU bit which is set to 1 for BPDUs (and for other L2 PDUs which must be sent to the SP all the time) and punts the frames with such bit to the SP right away.

On the contrary bpdufilter works at that level (MAC register level within port ASIC) and programs this level of hardware to drop frames with such bit set.

Riccardo

[Peter Paluch]

Riccardo,

You're bringing out some VERY nice and interesting info about the hardware processing of frames in C6k5 Thanks for that!

Best regards,

Peter

[rsimoni]

u r welcome buddy!

[Alexey Stytsenko]

As Peter pointed out the BPDU's are always punted to the CPU at  hardware level (referring to port ASIC level) before VACL or Mac ACL are  applied as all ACL logic occurs at EARL level (PFC) but if a packet is  punted to the CPU (the SP component) from the port ASIC it would not go  through Earl at all.

And one more nub question - what about for eg. RECEIVE adjacency in FIB, packets that fit these route  punted to RP from PFC level so PACL/VACL are normally aplied to this traffic cos routed to RP hapens latter than ACL checking - am i right?

[Alexey Stytsenko]

Tnx a lot for explanation. So possibility of filtering BPDU with PACL or VACL is platform-dependent, right?

Riccardo Simoni написал(а):
The reason is that the MAC register component looks for the BDPU bit which is set to 1 for BPDUs (and for other L2 PDUs which must be sent to the SP all the time) and punts the frames with such bit to the SP right away.
On the contrary bpdufilter works at that level (MAC register level within port ASIC) and programs this level of hardware to drop frames with such bit set.

Its great explanation, but for my level those things are completely new - my knowledge of input logic of packet threatment is smth like that - input queue ->pfc ->output queue (or MSFC), can u recommend any document for indepth research of process (googling for eg "MAC register component" returns nothing).

Besides "BDPU bit which is set to 1" its meaned fourh bit in most control messages multicast mac?

[rsimoni]

Hi Alexey,

yes every platform handles the feature differently and for the bpdu bit it is set by 6500 hw to make sure stp and cdp are always punted to the SP; that is why you did not find info in that sense.

About documentation I am afraid there is none that can be found on the internet as this refers to cisco architecture.

R

[Alexey Stytsenko]

One more question arised - in the same document Port ACLs (PACLs) and VLAN ACLs (VACLs) stays that

 The port ACL feature is supported only in hardware (port ACLs are not applied to any packets routed in software). 

Is this mean that any packets which matches receive, punt and glean andjacencies will pass PACL without checking?

Besides on following picture

shown that PACL applied before bridging and i can make assumption that decision to punt packet to RP or forward made after PACL aplied so how to distinct on this stage that packet will be afterwards punted to RP and pass it without checking against PACL? Or i made bogus assumption from this picture?

And i never think about this previously - is this any analogy of software switching for bridging packets? Control packets of L2 protocols which directed to device itself (CDP, DTP, STP and etc.) can it be said that those packets match receive adjacency or those terms only  can be applied to L3 packets? For eg. as you previously clarified to me Catalyst 6500 redirects those packets directly from port ASIC, but for those platforms having different architecture eg. 3560, 2950 -  them don’t punt control packets from MAC register level, than those control packets directed to some ASIC responsible for bridging (those ASIC use TCAM as i understand) and there in TCAM stays that those dest macs (01-00-0C-CC-CC-CC for eg.) matches smth like "receive adjacency" and from there those packets punted to SP?

Thanks in advance!