|
Home > Archive > CCNA > November 2003 > 2 hubs into a switch, is it really any better?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
2 hubs into a switch, is it really any better?
|
|
| DSComputers 2003-11-23, 12:39 pm |
| I was studying and came upon two senarios. One was 2 hubs, connected to a hub. The other was 2 hubs connected to a bridge.
First glance you would think the 2nd one is better because you now have two collision domains, rather than one big one. But after thinking about it, I don't see how that helps at all. Since all traffic on a hub is broadcast, and a bridge doesn't break up broadcast domains, I don't think having more than one collision domain helps at all.
Am I missing something or is my thinking right?
Here's a quote from my sybex 607 book
quote:
Let's say that you ahve 40 users plugged into 4 hubs, 10 users each. At this point the hubs are all connected together so that you have one large collision domain and one large broadcast domain. If you can afford to buy just one switch and plug each hub into a switch port, as well as the servers into the switch, then you now have four collision domains and one broadcast domain. Not great, but for the price of one switch, you network is much better.
I don't see how that makes the network any better, except the part about the servers also being on the switch. Anything sent from one user on one hub is going to go to all the users on all hubs, including the servers now on the switch. | |
| dmaftei 2003-11-23, 3:39 pm |
| It seems you are missing something: a switch breaks a collision domain, while a hub doesn't. Connecting things to a hub is pretty much like soldering wires together: when you put a signal somewhere on the wire, the signal propagates, mindlessly, throughout the wire.
The switch is a bit different: when you connect stuff to a switch, the switch doesn't "solder" the wires. Rather, it acts like a, well, switch...  When you put a signal on some wire, that signal will reach the switch, then the switch will figure out whether or not the signal should propagate to another wire. If the signal should propagate, then the switch "closes" the "switch", and the signal will be "copied" to the other wire. If the signal should not propagate, then the "switch" inside the switch remains "open", so the signal doesn't propagate further. That's how the switch breaks the collision domain.
The broadcast domain is a different business... With respect to the broadcast domain there's no difference between a hub and a switch -- unless you put VLANS on the switch. | |
| DSComputers 2003-11-23, 5:22 pm |
| Right, so if it doesn't break up the broadcast domain, what good is it?
I understand the benefit in a fully switched network or if the switch was connecting to a router separating it from another like network (breaking up broadcast domains), but not in this situation since hubs can't do anything but broadcast.
__hub1__------_switch_------__hub2__
Lets say you have users 1-10 on hub one, and users 11-20 on hub 2.
If user 1 wants to talk to user 2 in this situation, users 1-20 are all going to receive the information. So what did that switch do for me? | |
|
| she answered it in the first sentence and that seem, as stated, to be the concept you are missing because you do not mention it even in the 2nd post.
collision domain, specifically, what excessive collision does to an ethernet network.
ie, 2 collision domain of 10 users each, or 1 collision domain of 20 users.
the book you quoted said much of the same thing.
if you can see this in practice, or have a network modeling software, you can see how busy a ethernet network can be and how reducing the amount of collision by creating separate collision domains can increase network efficiency... even when it is under the same broadcast domain. Try to see it beyond the 10/20/30 users... think hundreds of computers with collisions... that would make this more apparent. | |
| dmaftei 2003-11-23, 6:00 pm |
| quote:
Originally posted by DSComputers
Right, so if it doesn't break up the broadcast domain, what good is it?
It breaks the collision domain, that's why it's good. I mean no offense, but I have a feeling you don't quite get the difference beteen collision and broadcast domain...
10 hosts per hub1, 10 hosts per hub2:
__hub1__------_hub_------__hub2__
One broadcast domain, one collison domain with 20 hosts. When host1 (hub1) sends to host2 (hub1), all 20 hosts will see what host1 sends.
__hub1__------_switch_------__hub2__
One broadcast domain, two collision domains, with 10 hosts each. When host1 (hub1) sends to host2 (hub1), only hosts 1 through 10, attached to hub1, will see what host1 (hub1) sends. Hosts 11 through 20 (attached to hub2) don't see anything (unless host1 sends a broadcast, which is a different business).
Makes more sense now?
And, BTW, hubs do not broadcast; hubs are layer 1 (physical) devices, and as such are too dumb to know about broadcasts (which, depending on what you're looking at, are layer 2 or layer 3 concepts). Hubs and repeaters are pretty much the same thing; they get something on one port and they "repeat" it, mindlessly, on all the other ports. | |
| dmaftei 2003-11-23, 6:01 pm |
| quote:
Originally posted by mikop
she answered...
He. | |
|
| why did I get the impression you were a she... I could swear in reading back old posts you were always refered as she. my bad. | |
| DSComputers 2003-11-23, 6:15 pm |
| Hrm, I guess I don't fully understand some things I thought I did. I fail to see how a separate collision domain would help in a situation where 2 devices can't do anything but broadcast. In a switch, one port can send directly to another port, while others can talk without any knowledge or interruption from the other computers...very nice. If port 1 and 3 on a switch have a collision, port 2 talking to port 4 doesn't give a shit. With the hubs, they're all broadcasting. If there is a collision anywhere, whatever collided must be resent(broadcast). If its from one hub to another port on the same hub where the collision occured, I guess only those connected to the hub with the collision would have to wait to retransmit. But since its in one broadcast domain, and hubs can do nothing but broadcast, that seems like a bad thing that could lead to more collisions between the 2 hubs.
If anybody knows how to explain this that will get it through my thick head, I'd love to hear it. Otherwise i'll prolly get that "OH, ofcourse" thing in the next few days while brushing my teeth or whatever...
Edit: i started this, before the above posts, after mike's last, let me read them b4 you tar and feather me 
Edit2: ok, now I read the above posts...
OH Thanks very much for the info. I cannot believe I got this far with such a misunderstanding of how a hub works. I thought each transmission was broadcast, when really its just repeated to all ports within the same collision domain. So once the information gets to the switch, and it sees that the MAC it is addressed for isn't on the other hub, it just drops it.
I can easily see how I thought that based on how the working of a hub was explained to me...but wow, I feel a bit silly now, but very glad I understand.
And if i'm really thickheaded and still am seeing it wrong, please correct
Thanks again for the info. | |
|
| i won't tar and feather, but think of this scenario
using hte set up above (too lazy to detail it again).
2 pc on one hub is doing a file transfer, 50 terabyte of stuff... what does that do for the network... no one can talk right?
if you separate it into 2 collision domain, and the 2 pc doing the transfer are on the same collision domain, all the pcs on that domain can't do sh*t and all the pc on the other collision domain can still do stuff right?
so as all books would like to point out... your network capacity has double... ;/
edit: wrote this b4 your edited your post
the 2nd time.
edit2: dmaftei's edit about layer 1 and broadcast is really good... wish I could've explained it like that. | |
| DSComputers 2003-11-23, 6:28 pm |
| Yup yup, atleast I understood collision domains just not the damn hubs, hehe. I can say it one more time..."damn physical layer...gets me every time!"
We'll see if I really meet my goal of ccna by x-mas  | |
| dmaftei 2003-11-23, 8:02 pm |
| So why don't you share with us your understanding of collision domain and broadcast domain? Not necessarily definitions; examples would be fine. I'll keep the tar and feathers handy, just in case. | |
| DSComputers 2003-11-23, 8:31 pm |
| Hehe, putting me on the spot there, dmaftei
I hope I already answered it in my other post
"In a switch, one port can send directly to another port, while others can talk without any knowledge or interruption from the other computers...very nice. If port 1 and 3 on a switch have a collision, port 2 talking to port 4 doesn't give a shit. With the hubs, they're all broadcasting. If there is a collision anywhere, whatever collided must be resent(broadcast). If its from one hub to another port on the same hub where the collision occured, I guess only those connected to the hub with the collision would have to wait to retransmit."
The above is still a bit wrong since I hadn't "got it" yet when I typed that.
Basically it'd be who all can talk at the same time. In a hub, only one can talk at the same time, where a switch, pretty much everybody could be talking so long as they weren't talking to any of the same computers, which would happen so you still have some potential for collision, but ya know...in a perfect world
My confusion earlier was the thinking that hubs actually broadcast, so even if they were on separate collision domains, only one device could talk at a time. But now I see that hubs don't actually broadcast in the sense I was thinking of, so transmissions between users within the same hub wouldn't travel across the switch into the separate collision domain.
Edit: spelling | |
| dmaftei 2003-11-23, 9:26 pm |
| I guess that pretty much sums it up. Good luck to you. | |
|
|
| edmonds_robert 2003-11-25, 1:58 pm |
| The thing to remember here is when they say "broadcast," they are referring to traffic destined for the broadcast address, namely the mac address ffff.ffff.ffff (or ff-ff-ff-ff-ff-ff if you prefer the Microsoft way). Dmaftei was right on in his explanation of broadcast. Don't get repeating and broadcasting confused, and you'll do much better. | |
| Demijohn 2003-11-25, 2:26 pm |
| Well, sometimes when they say "broadcast" they are referring to the broadcast address for the IP subnet, which is not the same as the MAC broadcast. Cisco frequently equates the term "broadcast domain" with "ip subnet". | |
| edmonds_robert 2003-11-26, 11:52 pm |
| quote:
Originally posted by Demijohn
Well, sometimes when they say "broadcast" they are referring to the broadcast address for the IP subnet, which is not the same as the MAC broadcast. Cisco frequently equates the term "broadcast domain" with "ip subnet".
Yes, but I didn't want to complicate things even more. One layer of the OSI model at a time, please. |
|
|
|
|