MAC tagged frames with BPDU - generic question

[hostettle]

Hi,

Have you seen MAC tagged frames with BPDU ?

Normally, the tag is unuseless because these MAC frames are not relayed to another port in a switch. They are directly processed by a sublayer client of the MAC sublayer.

Thanks for your words,

Michel       

[Peter Paluch · Accepted solution]

Hi Michel,

What do you mean by "MAC tagged"? I do not know this term. Are you perhaps speaking about 802.1ah Provider Backbone Bridges, the MAC-in-MAC standard for Carrier Ethernet Networks?

Best regards,

Peter

[hostettle]

Hi Peter,

Happy to see you... euh!... just read you.

Sorry for my English. I meant a "MAC frame with a VLAN tag" or a C-VLAN, although it could be a PBB MAC frame.

But let's stay simple.

Is it common to have a MAC frame with a VLAN tag, carrying a BPDU unity ?

Best regards,

Michel

[Peter Paluch · Accepted solution]

Hello Michel,

Is it common to have a MAC frame with a VLAN tag, carrying a BPDU unity ?

It is common for Cisco's implementation of PVST+ and RPVST+. The per-VLAN (R)STP as implemented by Cisco tags the BPDUs for each VLAN with the corresponding VLAN tag. This way, it is both declared which STP instance on the receiving switch is supposed to process this particular tagged BPDU, and also, for switches that do not support the per-VLAN (R)STP, this frame is just a tagged frame flooded in the appropriate VLAN to those switches which actually can understand this kind of BPDU encapsulation.

It shall be noted that the decision whether to locally process or to flood a frame is made primarily by the destination MAC address. If the switch recognizes the destination MAC as one of the MAC addresses it listens on, it will process the frame, otherwise, it will just flood it. Whether the frame can or can not be tagged is basically dependent just on the specification of the protocol carried by that frame. Technically, though, even a BPDU can be tagged if there is an application that makes use of these tags. The per-VLAN (R)STP surely is one.

Best regards,

Peter

[hostettle]

Hi Peter,

Thanks for this talking.

> It is common for Cisco's implementation of PVST+ and RPVST+.

OK

> It shall be noted that the decision whether to locally process or to flood a frame

> is made primarily by the destination MAC address.

I don't know the Cisco process. For IEEE, the MAC frames carrying BPDU from STP, RSTP, MSTP or SPB are not flooded. They are frames from the control plane, with a reserved DA address, and not from the user plane. They are transmitted in a point-to-point mode (even if the address is multicast - due to an old reason of shared media).

> Technically, though, even a BPDU can be tagged if there is an application

> that makes use of these tags. The per-VLAN (R)STP surely is one.

In IEEE, the VLAN tag in the MAC frame is completely independant of the VLAN tags managed by MSTP. The MSTP sublayer is client of LLC that is client of MAC. These sublayers are not at the same level, and the MSTP sublayer process BPDUs which have no idea of the tag in the MAC sublayer.

Best regards,

Michel

[Giuseppe Larosa · Accepted solution]

Hello Michel,

what Peter was meaning is that PVST+ and Rapid PVST use a different multicast MAC address other then ones used by IEEE standards.

This is the reason why a third party switch treats these frames as user traffic frames and will flood them as user multicast traffic.

Edit:

from the field I have seen that Cisco switches compare the external Vlan tag with the vlan instance id that is internal to the PVST BPDU, if the two does not match an inconsistency is detected and the port is put in inconsistent state for the offending vlan(s) ( or totally blocked I' m not sure on this)

Hope to help

Giuseppe

[hostettle]

Hi Giuseppe,

> This is the reason why a third party switch treats these frames as user  traffic

> frames and will flood them as user multicast traffic.

Thanks for that information, I did't have imaginated that.

> from the field I have seen that Cisco switches compare the external Vlan  tag with

> the vlan instance id that is internal to the PVST BPDU, if the  two does not match

> an inconsistency is detected and the port is put in  inconsistent state for the

> offending vlan(s) ( or totally blocked I' m  not sure on this)

Also a very interesting information.

Best regards,

Michel

[Peter Paluch]

Hello Giuseppe and Michel,

@Michel:

For IEEE, the MAC frames carrying BPDU from STP, RSTP, MSTP or SPB are  not flooded. They are frames from the control plane, with a reserved DA  address, and not from the user plane. They are transmitted in a  point-to-point mode (even if the address is multicast - due to an old  reason of shared media).

This  is absolutely correct. However, notice that this is not in conflict  with what I indicated: I wrote that the switch logic has to recognize  the destination MAC and has to consider it one of the addresses it  listens on in order to process it locally. If a switch intercepts and  processes BPDUs even though they are multicast, it is because it is  listening on the MAC address to which the BPDUs are being sent. The MAC  address table on Catalyst switches is quite illustrative:

All    0180.c200.0000    STATIC      CPU

Though not always displayed or visible on all Catalyst  platforms, it nonetheless nicely indicates that frames addressed to  this particular MAC address shall be received and processed by the CPU.

In IEEE, the VLAN tag in the MAC frame is completely independant of the  VLAN tags managed by MSTP. The MSTP sublayer is client of LLC that is  client of MAC. These sublayers are not at the same level, and the MSTP  sublayer process BPDUs which have no idea of the tag in the MAC  sublayer.

I  am missing you here. MSTP BPDUs are not tagged with VLAN tags, and MSTP  does not manage VLAN tags. Perhaps you could reword this?

@Giuseppe:

what Peter was meaning is that PVST+ and Rapid PVST use a different  multicast MAC address other then ones used by IEEE standards.

Yes, exactly - thank you for completing my answer. A nice explanation can be found here:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic1

from the field I have seen that Cisco switches compare the external Vlan  tag with the vlan instance id that is internal to the PVST BPDU, if the  two does not match an inconsistency is detected and the port is put in  inconsistent state for the offending vlan(s) ( or totally blocked I' m  not sure on this)

Correct.  The (R)PVST+ BPDU contains a TLV at its very end containing the  originating VLAN. If the (R)PVST+ BPDU is received in a different VLAN  according to the 802.1Q tag than it was originated in according to the  TLV, the port will become PVID-Inconsistent for both these mismatched  VLANs and will be blocked. Other VLANs will remain unblocked (their  state on the port will be determined by normal STP rules).

Best regards,

Peter

[hostettle]

Hi Peter,

>> In IEEE, the VLAN tag in the MAC frame is completely independant of the  VLAN tags managed by MSTP.

>> The MSTP sublayer is client of LLC that is  client of MAC. These sublayers are not at the same level,

>> and the MSTP  sublayer process BPDUs which have no idea of the tag in the MAC  sublayer.

> I  am missing you here. MSTP BPDUs are not tagged with VLAN tags, and MSTP  does not manage

> VLAN tags. Perhaps you could reword this?

You're right, I try to reword that.

(1) In a MSTP region, it can be several MSTI (multiple spanning tree instance).

(2) Each instance of MSTI is identified by an identifier MSTID (12 bits).

(3) A MSTID can be assigned to several VLAN domains. For example, MSTID #4 could be assiged to VLAN #4, #5,  #10, #78

(4) If my calculation is correct, the MSTID is implemented in octet 104 and 105 of a MSTP BPDU.

(5) Coming back to my originated hypothesis, badly written, the MSTP BPDU could be carried in a MAC frame with the VLAN #7 for example, a VLAN not assigned to a MSTID. There is no opposition for that in IEEE, the MSTP sublayer is not aware of the VLAN number in the MAC sublayer.

Best regards,

Michel

[Peter Paluch]

Hello Michel,

Thank you for your patience with me.

(1) In a MSTP region, it can be several MSTI (multiple spanning tree instance).

Correct.

(2) Each instance of MSTI is identified by an identifier MSTID (12 bits).

Correct.

(3) A MSTID can be assigned to several VLAN domains. For example, MSTID #4 could be assiged to VLAN #4, #5,  #10, #78

I would put this the other way around. MST instances do not belong into VLANs, rather, VLANs belong into MST instances. You do not assign MSTIs to several VLANs, just the opposite - you assign several VLANs into a single MSTI.

It has also to be stressed at this point that we're slightly comparing something incomparable by nature - VLANs belong into the data plane (forwarding plane) of a switch while MSTIs are related to the control plane. VLANs do not really run "inside" MST instances and MSTIs are not carried within VLANs. MSTIs are simply abstract instances of a spanning-tree algorithm with no particular relation to VLANs whatsoever. It is just the logic of MST-capable switches that causes all VLANs formally mapped to a single MST instance in the control plane to adopt its topology and state - that is how the control plane decisions are translated into the data plane.

(4) If my calculation is correct, the MSTID is implemented in octet 104 and 105 of a MSTP BPDU.

The MSTID is a part of the Bridge ID, similar to Extended System ID, and yes, in the first instance record in an MSTP BPDU, the MSTID is between the 104th-105th octet. An instance record is 16 bytes long, so individual instance records start on the octets 103, 119, etc.

(5) Coming back to my originated hypothesis, badly written, the MSTP  BPDU could be carried in a MAC frame with the VLAN #7 for example, a  VLAN not assigned to a MSTID. There is no opposition for that in IEEE,  the MSTP sublayer is not aware of the VLAN number in the MAC sublayer.

Recall that a networking device is conceptually split into the data plane and the control plane. If an MSTP BPDU was tagged by, say, VLAN #7 then the data path would deliver the MSTP BPDU only within this VLAN. The question is, does the MSTP service (e.g., the MSTP process or driver running in IOS) listen for BPDUs in VLAN #7? If not, the data path would essentially prevent the MSTP from functioning properly. In the CCNP:TSHOOT course, there is a chapter that discusses the fact that the control plane signalling is done over the data plane, so if the data plane is broken, it also affects the operation of the control plane. Inappropriately tagging MSTP BPDUs with a VLAN may prevent them from being properly delivered to the MSTP process.

So one thing is whether MSTP is or should be aware of the VLAN numbers the BPDUs could be tagged with. It surely does not need to know it in order to perform its own operations. This is similar to, say, the IP driver not being concerned what was the destination MAC address of the frame that carried the delivered packet - as long as the IP packet arrives to the correct host, the IP driver can act upon it. But the appropriate delivery of BPDUs or IP packets to where the driver expects them is another issue, and that is strongly tied to the addressing on the lower layers. If the packet is misaddressed or misrouted, it can not be processed at the intended destination. If the MSTP BPDU is delivered in a VLAN where the MSTP does not expect it, it can not be processed appropriately. In OSI reference model terminology, this appropriate addressing is called Service Access Point - a conceptual point at the boundary of two layers where a higher service is reachable. Obviously, if the appropriate SAP is not correctly targeted, the message will not be processed by the correct service.

I see you like to think in clear, well-delineated and isolated layers. Strict layering is a matter of theory as it simplifies our way of seeing the processes in networks but in general, it is not as strictly followed in real implementations of networking hardware and software (see RFC 3439 that even has a chapter called Layering Considered Harmful). The boundaries between layers are much more blurry and the leaking/interdependence of higher and lower layer information tends to be more complex in real networking products than the puristic standards admit.

Please feel welcome to ask further!

Best regards,

Peter

[hostettle]

Hello Peter,

Thanks for all the good ideas you have written.

> You do not assign MSTIs to several VLANs, just the opposite - you assign

> several VLANs into a single MSTI.

You’re right, thanks for the correction

> in the first instance record in an MSTP BPDU, the MSTID is between the

> 104th-105th octet. An instance record is 16 bytes long, so individual instance
> records start on the octets 103, 119, etc.

I agree, a MSTP BPDU can includes several records

> MSTIs are simply abstract instances of a spanning-tree algorithm with no particular

> relation to VLANs whatsoever.

The MSTP BPDUs carry an implicit information of the VLAN in the “MST Configuration identifier”. There is a 16-octet Configuration Digest (octet 74 to 89) which is a MD5 hash signature from the MST Configuration Table. (from 802.1Q) "The MST Configuration Table defines, for each VID, the MSTID of the spanning tree instance to which the VID is allocated".

> VLANs belong into the data plane (forwarding plane) of a switch while MSTIs

> are related to the control plane.

You’re right. I would prefer complete by: VLANs belong to the “MAC forwarding plane” (I call it user plane) and MSTIs belong to the “MAC control plane”. There is the same relation between ARP and IPv4. ARP belongs to the “IPv4 control plane”, but to the “MAC forwarding plane”. The control plane is responsible for the connectivity configuration in the forwarding plane (in a given layer).

> In the CCNP:TSHOOT course, there is a chapter that discusses the fact that

> the control plane signalling is done over the data plane, so if the data plane is

> broken, it also affects the operation of the control plane.

Thanks for that recall. Perhaps, this is more explicit with ITU-T. See e.g. the G.8012 (08/2004) figure 6-8:

“Data (or User) Plane, optionally including a Data Communication Network (DCN) supporting management plane and control plane communications“.

So, if the user plane is in fault, the DCN cannot provide its functionnalities. So the control ad the management planes are out of service. The DCN is defined in G.7712 (06/2008), it is designed to support transport of distributed management communications.

> The question is, does the MSTP service (e.g., the MSTP process or driver running in

> IOS) listen for BPDUs in VLAN #7? If not, the data path would essentially prevent

> the MSTP from functioning properly.

You’re perfectly right. I corrected me !

> Strict layering is a matter of theory as it simplifies our way of seeing the processes

> in networks

We need that because we cannot say Elizabeth I of England was the wife of Gaius Julius Caesar.

The layering is showed by the relation between the data: e.g. the RSTP BPDU is encapsulated in the LLC unity. The LLC unity is encapsulated in the MAC frame. And, for example, the MAC frame is converted in a MAC packet, thus inserted, through an RS adaptation, in the PHY characters flow.

> but in general, it is not as strictly followed in real implementations of

> networking hardware and software (see RFC 3439…

I would not say that layering is theory. I prefer to say that it is a functional point of view, its guidance is given by the relations between the data. The hardware implementations are not partitioned by abstract architectural considerations.

Perhaps, it’s better to talk about the data architecture than the layer architecture. But it is less prestigious.

Thanks for the RFC reference, I note it.

> The boundaries between layers are much more blurry and the

> leaking/interdependence of higher and lower layer information tends to be

> more complex in real networking products than the puristic standards admit.

I prefer the IUT-T layering description (with mainly the network layers and the adaptation functions between 2 consecutive network layers) ) than the TCP/IP, OSI or IEEE models.

The boundaries between layers are solved by ITU-T with the adaptation functions. Each function includes the client specific processes, the common processes, the server specific processes.

Thanks for your bounces,

Best regards,

Michel