I would like to summarize few points before asking those doubts:1. STP is found to eliminate loops that may occur between switches in the broadcast domain.2. I assume we are all familiar with the Root Bridge election AND the Root and Designated ports election. My doubts is NOT about (how does STP work?) but (how should it work?) or (why is it working like that?)

I would like to ask my doubts one by one to avoid collusion.

FIRST DOUBT:--------------Why the non-DP (blocked) port does not forward regular data frames (the non-broadcasted one)?It can be much faster than sending them through the Root switch

If there isn't a port blocking a loop can occur. Do you have some switches to lab with? If so hook them up in a ring topology, turn of STP, and watch the show. Make sure you have a console connection, CPU is gonna spike so you won't get much else to work.

You are correct that the loop would not occour if the broadcasts would not be forwarded through the blocked port. But, if the switch allows normal frames, but not broadcasts, how would the switches learn wich clients is on the other switch? Broadcasting frames is an important way for switches to learn about client adresses.

For every complex problem, there is a solution thats simple, neat, and wrong.

obre wrote:You are correct that the loop would not occour if the broadcasts would not be forwarded through the blocked port. But, if the switch allows normal frames, but not broadcasts, how would the switches learn wich clients is on the other switch? Broadcasting frames is an important way for switches to learn about client adresses.

switches don't necessarily learn from broadcast frames per se but rather from Source MAC of the incoming frames (unicast/broadcast). Broadcast is more important to the clients where it has to send an ARP (broadcast) for the GW's MAC or another client's MAC on the same subnet.

obre wrote:You are correct that the loop would not occour if the broadcasts would not be forwarded through the blocked port. But, if the switch allows normal frames, but not broadcasts, how would the switches learn wich clients is on the other switch? Broadcasting frames is an important way for switches to learn about client adresses.

switches don't necessarily learn from broadcast frames per se but rather from Source MAC of the incoming frames (unicast/broadcast). Broadcast is more important to the clients where it has to send an ARP (broadcast) for the GW's MAC or another client's MAC on the same subnet.

When a switch doesn't know where to send a frame, it floods it, wich makes neighbouring switches aware of where to find the mac put in the source of this packet. So, if STP just blocked broadcasts on a link, and not normal traffic, how do you think the switches should learn wich addresses is at the neighbouring switch?

For every complex problem, there is a solution thats simple, neat, and wrong.

obre wrote:You are correct that the loop would not occour if the broadcasts would not be forwarded through the blocked port. But, if the switch allows normal frames, but not broadcasts, how would the switches learn wich clients is on the other switch? Broadcasting frames is an important way for switches to learn about client adresses.

switches don't necessarily learn from broadcast frames per se but rather from Source MAC of the incoming frames (unicast/broadcast). Broadcast is more important to the clients where it has to send an ARP (broadcast) for the GW's MAC or another client's MAC on the same subnet.

When a switch doesn't know where to send a frame, it floods it, wich makes neighbouring switches aware of where to find the mac put in the source of this packet. So, if STP just blocked broadcasts on a link, and not normal traffic, how do you think the switches should learn wich addresses is at the neighbouring switch?

Again, the broadcast frames are for the Client's benefit and not the switch. Switches can learn which address belongs to what port regardless if it's a unicast/broadcast/multicast frame by looking at the Source MAC. I'm not arguing anything here, I just wanted to make it clear(er).

How do you think the first packet is traversing the link, when none of the switches know any of the adresses to the other switch? Wich is the case before traffic is going.

I am not arguing that switches learn by unicast packets as well, but the first packet traversing a link between two switches is a broadcast, or a flooded unicast, as the switch still dont know any destinations on the other side of the link.

Am I making myself clear?

For every complex problem, there is a solution thats simple, neat, and wrong.

I think you are mixing terms here. True if a switch doesn't know the port for the destination MAC it will flood the packet out all ports in the same VLAN besides the originating port. However, that first packet can easily be a unicast. Even when it is flooded out a port to another switch, the second switch still sees it as a unicast.

It sounds like you are getting hung up the switch treating the first packet like a broadcast.

Thanks all for the reply ..And very sorry for being late .. I have really forgot that I have opened this thread, pardon me

Now, regarding the discussed issue ..Switches learn MAC from the incoming packet source MAC, if it does not know the destination MAC, it will flood. But how this is related to my doubt? I guess there is a miss-understanding

I said, we want to block the port only for broadcasting NOT for normal frames. So if the switch is broadcasting then it has to block the port otherwise it needs not. This what I meant to say, I did not meant to say that I want to stop flooding. Flooding is required at the beginning until the switch learns the MAC addresses, but after that it is not required unless there is a change in the MAC addresses and this rarely happened.

So why they are blocking this port entirely even though it is not required. In another words, why they do not have the case "Broadcast block" except of the normal "block".

It is really beneficial for the traffic NOT to have permanent "block". Consider the following topology, Imagine how long the normal traffic from C1 to C2 has to travel although they are very close!! And they will never cause loops, except for the first frame request and reply through which switches will learn their MAC addresses, the remaining 1000s of frames are directed NOT broadcasted and will never cause a loop. So why they have not addressed this issue?

Machines will broadcast constantly. If they don't know the MAC address of a host, they'll send a broadcast ARP request. This entry eventually ages out of the ARP table on the local machine after a period of no communication between the two. So the next time a conversation starts, it'll start with a broadcast again.

Also, the entires in the TCAM table on the switch will age out if they don't hear anything from the client as well. So if the client doesn't talk at all and it sends another packet after this time out, the switch floods it again.

Regarding blocking broadcasts, you may be able to create an ACL that is applied to each port that blocks broadcasts for the network/vlan/subnet it is assigned to. But as stated before, it's beneficial to the clients to allow broadcasts.

I recommend putting a small lab together with the design you have above and block the broadcasts and see what happens. If either of the hosts use DHCP addresses they won't be able to get an IP address either, as DHCP relies on broadcasts. Also, C1 will never learn the IP of C2 as the original ARP request would be blocked.

mynd wrote:I think you are mixing terms here. True if a switch doesn't know the port for the destination MAC it will flood the packet out all ports in the same VLAN besides the originating port. However, that first packet can easily be a unicast. Even when it is flooded out a port to another switch, the second switch still sees it as a unicast.

It sounds like you are getting hung up the switch treating the first packet like a broadcast.

Let me point out what I said:

obre wrote:How do you think the first packet is traversing the link, when none of the switches know any of the adresses to the other switch? Wich is the case before traffic is going.

I am not arguing that switches learn by unicast packets as well, but the first packet traversing a link between two switches is a broadcast, or a flooded unicast, as the switch still dont know any destinations on the other side of the link.

Am I making myself clear?

mustafa_kaiiali wrote:Thanks all for the reply ..And very sorry for being late .. I have really forgot that I have opened this thread, pardon me

Now, regarding the discussed issue ..Switches learn MAC from the incoming packet source MAC, if it does not know the destination MAC, it will flood. But how this is related to my doubt? I guess there is a miss-understanding

I said, we want to block the port only for broadcasting NOT for normal frames. So if the switch is broadcasting then it has to block the port otherwise it needs not. This what I meant to say, I did not meant to say that I want to stop flooding. Flooding is required at the beginning until the switch learns the MAC addresses, but after that it is not required unless there is a change in the MAC addresses and this rarely happened.

So why they are blocking this port entirely even though it is not required. In another words, why they do not have the case "Broadcast block" except of the normal "block".

It is really beneficial for the traffic NOT to have permanent "block". Consider the following topology, Imagine how long the normal traffic from C1 to C2 has to travel although they are very close!! And they will never cause loops, except for the first frame request and reply through which switches will learn their MAC addresses, the remaining 1000s of frames are directed NOT broadcasted and will never cause a loop. So why they have not addressed this issue?

You are right, you said only to block broadcasts, but i assumed you also meant the flooding of normal frames. The reason for that is that flooding of normal frames also makes an loop in your network, if none of the switches know where to find the destination. So, to prevent loops, you need to prevent broadcasts AND flooded unicasts. And if neither broadcasts nor flooded unicasts can traverse the link, how would switches learn to use this path?

For every complex problem, there is a solution thats simple, neat, and wrong.

Friends thanks for your replies, but there is a misunderstanding again..

I have never said that I want to block broadcasts. I said that we need a new state on the ports which is "Broadcast Block" and this means that this port is only blocked for broadcasted/flooded frames but it forwards for the normal frames.

Now regarding the age-out of the CAM table, it is an important point of course with regard to this discussion, however it does not eliminate the discussed issue for 2 reasons:1. It is rarely, nowadays, that an active machine never sends any packet out for 5 min (at least any messenger or background services would be checking the net periodicity)2. Even if we consider frequent age-out of CAM entries, flooding is required only for the first frame NOT for all the subsequent frames. That means all the subsequent frames (could be 1000s) are sent in the long way just to avoid the loop which may occur by the first frame!!! I find this way inefficient at all.

I'm not sure most people would. STP has been doing the job for nearly 30 years (with tweaks to help convergence times and such along the way). It's rock solid, vendor compatibility issues for the most part were solved a decade ago, and if you want to eliminate STP blocking there are proprietary MLAG options or vendor specific data center fabrics to choose from. I'm not seeing a reason to change anything...

I'm not sure most people would. STP has been doing the job for nearly 30 years (with tweaks to help convergence times and such along the way). It's rock solid, vendor compatibility issues for the most part were solved a decade ago, and if you want to eliminate STP blocking there are proprietary MLAG options or vendor specific data center fabrics to choose from. I'm not seeing a reason to change anything...

I did not say that I want to eliminate STP. But I said that when STP blocks a port, let it be Broadcast-Block NOT the permanent normal block. This is the only change that I am suggesting, NOT preventing broadcast, NEITHER eliminating STP.

I have not said that STP is not doing well, but I meant to say that with this modification it will do better. It is inefficient if we compare it to the new model (broadcast-block), however, it is still doing well even though it is causing longer trip for the frames. And this is because the upper switches are usually the core switches which are highly capable to switch a lot of traffic.

I know this little change requires subsequent modifications to be implemented and this is usual and applicable. If it is shown to be efficient, it will soon be standardized, no need to be worried about this issue, it'll be just a new version like any other protocols.

I think that is a bad idea. The first frame gets flooded, and such creates a loop if it is allowed over the "blocked" ports. How do you plan to stop this loop? Layer-2 do not have any TTL-mechanisms. If you say "sooner or later the switch will learn about the location of the destination", i would point out two things, that will make the switch to allways flood unicast packets: - If the destination is invalid. ie: it is not present anywhere. - If the communication is strictly one-way. Then switches will never see the returning frames, which will make them incapable of learning that address.

An also, to get over STP's drawbacks, in therms of non-optimal routes and such, there are being done great work in fields like TRILL, Fabric-path and simmilar technologies.

For every complex problem, there is a solution thats simple, neat, and wrong.

obre wrote:I think that is a bad idea. The first frame gets flooded, and such creates a loop if it is allowed over the "blocked" ports. How do you plan to stop this loop? Layer-2 do not have any TTL-mechanisms. If you say "sooner or later the switch will learn about the location of the destination", i would point out two things, that will make the switch to allways flood unicast packets: - If the destination is invalid. ie: it is not present anywhere. - If the communication is strictly one-way. Then switches will never see the returning frames, which will make them incapable of learning that address.

An also, to get over STP's drawbacks, in therms of non-optimal routes and such, there are being done great work in fields like TRILL, Fabric-path and similar technologies.

Thanks for your comments.Regarding the 2 cases where the switches will always flood, they are too rare. As an example, in one way communication, you also have to assume that the destination is not going to acknowledge any packet and it also not supposed to establish a connection with any third party.

Regarding stopping the loop, as I said, I will stop it by the regular STP. The only alteration here is that STP will mark the ports that may cause the loop by "broadcast block" NOT by "block". So if the switch is going to broadcast or flood, it is not going to sent anything through these ports as it is blocked for broadcast BUT if the switch is willing to send normal directed packets (which is the most popular case) he can use these ports

And how do you plan to predict if a packet has an invalid address, or an address not yet discovered, to know if the packet can be flooded over the "half-blocked" link?

If you never want to flood over the link, the switches WILL learn the suboptimal route to the other host (as with STP). If you flood a packet over the link, and the packet have an invalid destination, it WILL loop forever. L2 have no TTL to stop it, as it is in L3. (Unless you use TRILL, fabric-path, VCS, Q-fabric or simmilar).

For every complex problem, there is a solution thats simple, neat, and wrong.