How does a bridge reduce the size of the collision domain?

bbugyi200

Hello Everyone,


I was hoping that someone with a little more knowledge can take a look at this next paragraph and judge its accuracy:


The bridge, a predecessor to today’s Ethernet LAN switch, uses logic so that the frames in
one CD do not collide with frames in the other CD. The bridge forwards frames between its
two interfaces, and unlike a hub, a bridge will buffer or queue the frame until the outgoing
interface can send the frame. For example, Fred and Betty can both send a frame to Barney
at the same time, and the bridge will queue the frame sent by Betty, waiting to forward it to
the CD on the left, until the CD on the left is not busy.


I have taken this paragraph straight out of Wendell Odom's ICND 100-101 Guide. From my understanding of CSMA/CD (which hubs use) shouldn't a hub always check the line before sending out a frame? I thought it was only when two frames were sent at the exact same time that a collision occurred. If I am correct, then how does adding a bridge to a network of hubs decrease the size of the collision domain exactly?



Thanks for taking your time on this

tomtom1

A hub has a larger broadcast domain, since every frame it receives gets forwarded to all ports on the hub. Remember that the hub is a really stupid device, not understanding anything of the information it gets in the L2 frames.

A switch / bridge on the other hand is more clever. It is able to look at the source and destination MAC addresses in the frame, and once it sees the destination MAC address in its MAC address table, it forwards the frame only out (egress) the interface associated with the MAC address. The switch / bridge builds it's MAC address table by looking at the source MAC address on frames it receives on that port.

There is one exception though, once the switch / bridge receives a frame and the destination MAC address is not listed in the mac address table, flooding occurs. The switch / bridge will then forward the frame out every interface except the one it came in on. Eventually, the host or device that is associated with the destination mac address will respond with a frame of it's own. That is also the moment that the switch learns the port associated with that mac address.

Hope this helps,

mikerodriguez

Mmm, let me see if I can answer your question. Remember that the concept of having different collision domains is so no collisions occur AT ALL. You can look at the hub as a repeater, it forwards packets out all interfaces making collisions possible, hence "collision domain". In the case of the bridge, both interfaces are separate collision domains, so 1 collision domain on one side, 1 collision domain on the other so frames do not collide with one another. A hub does not have the physical nor the logical properties to break up a collision domain.

bbugyi200

tomtom1 wrote: »

A hub has a larger broadcast domain, since every frame it receives gets forwarded to all ports on the hub. Remember that the hub is a really stupid device, not understanding anything of the information it gets in the L2 frames.

A switch / bridge on the other hand is more clever. It is able to look at the source and destination MAC addresses in the frame, and once it sees the destination MAC address in its MAC address table, it forwards the frame only out (egress) the interface associated with the MAC address. The switch / bridge builds it's MAC address table by looking at the source MAC address on frames it receives on that port.

There is one exception though, once the switch / bridge receives a frame and the destination MAC address is not listed in the mac address table, flooding occurs. The switch / bridge will then forward the frame out every interface except the one it came in on. Eventually, the host or device that is associated with the destination mac address will respond with a frame of it's own. That is also the moment that the switch learns the port associated with that mac address.

Hope this helps,

I was not aware that a bridge has a MAC address table just like a switch does. This is exactly the information I needed for a better understanding.

Thanks for the help.

Jon_Cisco

bbugyi200 wrote: »

From my understanding of CSMA/CD (which hubs use) shouldn't a hub always check the line before sending out a frame?

I am not sure that hubs use CSMA/CD.
I believe that it is the computers checking the line and a hub would simply retransmit the jamming frequency to all devices.

[Deleted User]

Bridges are basically an older implementation of switches and recall that switches by default break up collision domains. Review the OSI model. Also, bridges are not used much in today's networks. Sometimes switches can be called bridges (the term is sometimes interchangable).

StonedHitman

tomtom1 wrote: »

A hub has a larger broadcast domain, since every frame it receives gets forwarded to all ports on the hub. Remember that the hub is a really stupid device, not understanding anything of the information it gets in the L2 frames.

A switch / bridge on the other hand is more clever. It is able to look at the source and destination MAC addresses in the frame, and once it sees the destination MAC address in its MAC address table, it forwards the frame only out (egress) the interface associated with the MAC address. The switch / bridge builds it's MAC address table by looking at the source MAC address on frames it receives on that port.

There is one exception though, once the switch / bridge receives a frame and the destination MAC address is not listed in the mac address table, flooding occurs. The switch / bridge will then forward the frame out every interface except the one it came in on. Eventually, the host or device that is associated with the destination mac address will respond with a frame of it's own. That is also the moment that the switch learns the port associated with that mac address.

Hope this helps,

Hey, sorry for asking a ? in op's thread but I just need a clarification on something. I understand that a frame destined for an unknown mac address is flooded, and not out the interface it came in on. But I thought that it's only flooded out all interfaces not currently in the mac address table? I don't see why it would flood the frame out an interface that it's clearly not destined for.

xnx

StonedHitman wrote: »

Hey, sorry for asking a ? in op's thread but I just need a clarification on something. I understand that a frame destined for an unknown mac address is flooded, and not out the interface it came in on. But I thought that it's only flooded out all interfaces not currently in the mac address table? I don't see why it would flood the frame out an interface that it's clearly not destined for.

This is the process where it's sending out an ARP request to the broadcast address of FF:FF:FF:FF:FF:FF asking for the MAC Address of a particular IP Address

cygnus21

StonedHitman wrote: »

Hey, sorry for asking a ? in op's thread but I just need a clarification on something. I understand that a frame destined for an unknown mac address is flooded, and not out the interface it came in on. But I thought that it's only flooded out all interfaces not currently in the mac address table? I don't see why it would flood the frame out an interface that it's clearly not destined for.

I think the reason for this is that the switch doens't know that there is ONLY 1 device connected on that port. For instance there can be another switch. So it floods the frame out all of the ports. This way even if it knows one MAC associated with that port it will still reach other devices that may be connected there.

cygnus21

For the OP you can think of a Bridge as a 2 port switch. Collisions stop at the bridge therefore the collision domain is split into 2 separate collision domains.

StonedHitman

cygnus21 wrote: »

I think the reason for this is that the switch doens't know that there is ONLY 1 device connected on that port. For instance there can be another switch. So it floods the frame out all of the ports. This way even if it knows one MAC associated with that port it will still reach other devices that may be connected there.

Ah, yes that makes sense, thank you