2

If a switch doesn't have a destination in its table it floods to all (but the sending) ports. Why doesn't it always do this if it can, since it would be faster than doing a look up in a table? I guess it has to do with collision: when 2 nodes transmit on the same medium simultaneously. But collisions can always happen anyways, and can be fixed using CSMA. I guess CSMA is slow and wants to be avoided?

It would be nice if we had tags for hubs and flooding.

  • Switches are purpose built from the ground up to perform those lookups at little to no latency. – Ryan Foley Nov 20 '14 at 13:40
  • 1
    If you feel there are tags missing and you can't create them, you can always post a comment to your question or ask on meta. A mod or someone who can create tags will typically be more than happy to do so if appropriate. – YLearn Nov 23 '14 at 19:49
11

cpt_fink and Shane already gave good answers, but I will add $0.02...

Let's assume you flood every frame that comes into a switch, you're essentially turning what we know as switches into a hub. That causes problems with:

  1. Security / Privacy: IP networks are largely unencypted. Flooding packets shares private information with everyone in that broadcast domain... DNS lookups, FTP passwords, websites you're visiting. All I need is wireshark on a flooded network, and I know a lot about what is happening. It's much easier to hijack TCP sessions if you know the TCP sequence numbers in use.
  2. End user count: If we flooded packets for every user to every other user, there is a much lower limit for how many users we can pack into one switch, because every user consumes the other user's bandwidth (see next bullet). Ultimately, this means you're spending a lot more money on network administrators, network infrastructure, vendor support costs, power, rack space, cooling, etc...
  3. User throughput: If any user on the switch sends line-rate traffic (i.e. no faster than 1Gbps on a GigabitEthernet link), we are flooding that line-rate traffic to every other user in the switch (as well as the broadcast domain). This is terribly inefficient. Mac-learning is much better than flooding

FYI: YLearn provided some practical examples of how flooding causes problems in wired networks.

A final thought:

If switches always flooded instead of learning mac-addresses, switched topologies would no longer be viable in modern networks. Engineers would resort to routing as quickly as possible because the three issues listed above are deal-killers for many wired network designs.

Interestingly enough, wireless 802.11 only implements privacy and security from the list above; otherwise wifi has the aforementioned problems with "flooding" non-broadcast traffic to all hosts (technically it isn't flooding, but the result is the same). 802.11's privacy and security measures make wifi at least a viable option.


EDIT:

In a comment, Celeritas said:

... you say that switches are more secure, but I seriously doubt that people choose a switch over a hub because they want security, security would be built at a different level. Also it would be nice if the answers didn't use too much jargon, for example what is "linerate"?

I am afraid you have misunderstood why people choose switches over hubs. People choose switches instead of hubs, because all three disadvantages listed above are a problem for wired networks.

802.11 wifi has two of the three problems that hubs have; however, the privacy and security measures built into wifi make it a feasible choice in some situations.

Apologies for confusing you with the term "line-rate". Line-rate means you're sending traffic as fast as the wired NIC can. On gigabit ethernet links, line-rate depends on the packet size you send, but line-rate cannot exceed the transmit speed of a GE NIC, which is 1,000,000,000 bits per second.

| improve this answer | |
7

You're arguing that it's better to flood, limiting the total throughput the switch to effectively the bandwidth of its slowest link, to avoid a few nanoseconds consulting a MAC address table?

I'd argue that you're looking at it wrong - switching provides much better performance than flooding, at an extremely minimal cost of a lookup table, which is done in hardware for speed in most cases. The performance trade-off is most definitely in favor of switching over flooding.

| improve this answer | |
  • "limiting the total throughput the switch to effectively the bandwidth of its slowest link" why would it be limited to the slowest link? – Celeritas Nov 20 '14 at 10:16
  • @Celeritas Because all the traffic is going out all the links. To push 1gbps to a given port, you're pushing 1gbps to all ports, which means none of those other ports would have bandwidth free to get any of their own traffic. The amount of traffic from the switch that will be relevant to the recipient port will be, in total for all ports, 1gbps, since that 1gbps is effectively shared. – Shane Madden Nov 20 '14 at 18:07
  • I guess I should have known this but it was never explained to me: switches can handle multiple connections simultaneously right? For example if computer A is transmitting to computer B and computer C is transmitting through computer D, both connections can go through one switch at the same time, right? But not a hub, is that what you're arguing? – Celeritas Nov 23 '14 at 0:29
  • 1
    @Celeritas The whole switch, the "backplane", has more bandwidth than the links, yes. A hub must transmit all traffic down all links, so there's no point in having it be able to handle more traffic than that, because where would it send it when the links are already saturated. – Shane Madden Nov 23 '14 at 21:27
  • 1
    @Celeritas The switch can process more traffic than it could possibly send through a single interface. So, to directly answer if computer A is transmitting to computer B and computer C is transmitting through computer D, both connections can go through one switch at the same time, right? Yes, thousands of times over. – Shane Madden Nov 23 '14 at 22:04
3

Mike has posted a great answer, but let me provide some examples to illustrate the problems inherent in flooding all traffic.

Imagine you have a switch with 24 1000baseT ports (i.e. capable or running at 1000 Mbps - while not really achievable in the real world, for simplicity let's say we can). Ports 01-20 have computer/workstations connected to them, ports 21-23 are connected to servers, and port 24 is connected to the "internet gateway."

Computer01 starts pushing raw video footage to Server21. Server21 is capable of taking a full 1000Mbps of raw video footage and encoding it into a specified format and returns it in "real time" to the host that upload the raw footage. So Computer01 sends 150Mbps of raw footage to Server21 which then returns a 10Mbps stream of data.

With data being flooded, there is now 160Mbps of data being sent out all ports on the switch. No performance problem at this point, but Computers02-20, Server22-23, and the Gateway are all also receiving 160Mbps of data that they each have to process to the point of knowing it isn't meant for them and then drop the traffic.

Computer02-06 also start pushing raw video footage to Server21.

With five more computers, we have now hit 960Mbps of traffic being flooded out all ports. Again, this is below our 1000Mbps per second limit, but not by much. Again, most of the devices on the network will be receiving this traffic and have to process it to some degree.

With only 6 active computers and one server, we have almost reached the capacity of the flooded network. There is almost no capacity left for the remaining devices on the network, say if Computer07 wants to start an FTP download from Server22.

What happens when we hit that 1000Mbps limit? Which traffic doesn't get flooded? How does that impact performance?

Now imagine this on a fully populated 48-port switch (i.e. more computers/servers/end points). How about with a stack of 7 48-port switches? An enterprise network with 1000's of switch ports?

Or, take a mixed environment where you may have 10baseT, 100baseTX, and 1000baseT ports all on the same network. Computer01 above would fully saturate a slower device on the network all by itself.

Computer10 starts exporting a patient list from Server23 and downloading it as an XML file.

This may not take up much bandwidth, and while normally a network device will drop traffic not addressed to itself, this is not always the case. On this network, Computer 15 has been compromised and it now watching all the traffic it receives and now is able to also "download" the XML file containing the patient list as well.

To protect against this, you now require that all internal traffic be encrypted or protected by some means. This takes resources to develop, resources to verify everything is secure, and resources on the end points themselves to encrypt/decrypt everything.

So, back to your original question, "Why doesn't it always do this if it can, since it would be faster than doing a look up in a table?" Most switches utilize specialized hardware that does these look ups very, very quickly. This isn't measured in microseconds, but rather in nanoseconds (and won't reach the double digits at that). It is also not tied to CPU or memory resources.

Compare this to the amount of processing required by each station as it inspects and drops all the unnecessary traffic (also typically measured in nanoseconds, but it needs to be done by each device and not just the switch).

Or the time it takes to time out and re-transmit a frame when the network is congested (which may be measured in seconds).

Or the time it takes to establish some sort of encryption between each set of two devices that want to communicate in a secure fashion (which can easily introduce microseconds of delay). In addition, this may require additional traffic (such as a SSL/TLS exchange, etc).

Flooding all traffic is simply unfeasible on a network with more than a handful of devices.

| improve this answer | |
2

Short answer - Flooding doesn't scale as the bandwidth and user count increases.

| improve this answer | |
  • 2
    short answer = -1 – Celeritas Nov 20 '14 at 7:49
  • 3
    Ask a better question, get a better answer? – cpt_fink Nov 20 '14 at 23:01
  • @cpt_fink, FYI... perhaps you could elaborate – Mike Pennington Nov 23 '14 at 0:10
  • I'd be happy to elaborate. First of all I thought 2 or 3 word answers are discouraged on stackexchange sites, hence the reason for minimum length requirement. Also my comment explained why I downvoted: it was too short (by admission of the answerer). Saying something doesn't scale is not a very good explanation because scaling is a large and broad topic and could be applied to just about anything. For example if asking when to use x over y if one says "x doesn't scale" without explanation it's not very helpful. – Celeritas Nov 23 '14 at 0:39
  • @cpt_fink if somethings unclear about the question than comment so – Celeritas Nov 23 '14 at 20:19
0

Switches (I mean Ethernet at least) generally work in Fill-Duplex mode, where CSMA not used. Anyway Ethernet switch split Collision domain to each Half-Duplex segment. Then collision anymore not a problem for all network, only for small part of it where Half-Duplex is used (usually one link).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.