cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4808
Views
6
Helpful
12
Replies

How to calculate Collusion and Broadcast Domain

denys96530510
Level 1
Level 1

Hello There,

I have a question how to calculate Collusion and Broadcast Domain

1.)without Vlan

2.)with nativ Vlan.

  • F6B3E7EE-5F6A-422D-852F-7AA620DA0CD4.jpeg

1 Accepted Solution

Accepted Solutions

Hello,

No reason to apologize!

We still don't match in the counts.

Let's compare our domains ignoring any VLANs, assuming there are no VLANs used.

Broadcast domains:

  1. Server0 - Router5
  2. Router5 - Router3
  3. Router3 - Router4
  4. Router3 - Router1
  5. Router1 - Router0
  6. Router1 - Router2
  7. Router0 - Router2
  8. Router0 - Cloud
  9. The entire switched network below routers 2, 1, 4

Collision domains: Every single link in your topology is a separate collision domain, including the one toward the cloud, hence 21.

So, where does your counting differ?

Best regards,
Peter

 

View solution in original post

12 Replies 12

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

Let's start by agreeing on the definition of a collision domain.

The collision domain is a bounded part of the network where there is a risk that if two or more hosts started sending data at the same time, they would cause a collision - an unallowed overlap of two or more transmissions. With repeaters, hubs, and wireless access points on their wireless part, all devices connected to the repeater/hub/wireless access point create a single collision domain. If you connected another hub or repeater to an existing hub or repeater, the collision domain would grow in size but there would still be a single domain. Switches, routers and firewalls create a boundary to a collision domain because instead of just transmitting electric signals right as they are received, they process the datagrams encoded in those signals first and buffer them before forwarding them. If the datagrams are corrupted by collisions, they won't even get forwarded. This is why a collision on one port of a switch, router or a firewall does not affect the other ports. So, on a switch, router or a firewall, every interface is a boundary to one standalone collision domain. For example, a switch with 5 connected ports itself delineates 5 collision domains.

A collision domain is a Layer 1 matter - it depends on the physical layer properties. VLANs have no influence on it. It is the other way around - if collisions disrupt the communication, it affects all VLANs stretched across the affected collision domain.

The broadcast domain is a bounded part of the network where a single broadcast frame would be delivered if it was sent by any station in that part of the network. Repeaters, hubs, access points, and switches all create one broadcast domain - repeaters and hubs do because they simply regenerate and send the received signals on all other connected ports anyway, all the time, while access points and switches flood such frames because they do their forwarding decisions based on the destination MAC addresses of the frames, and a broadcast frame must be flooded to everyone. However, routers and firewalls stop the flooding of broadcasts. Every connected interface of a router or a firewall is one broadcast domain.

Looking at your diagram, you don't have Ethernet hubs there. This makes counting the collision domains a little easier. I am not going to give you a solution but let me give you a few isolated hints:

  • The link between Switch0 and Switch1 is one standalone collision domain
  • The link between Router0 and Router1 is one standalone collision domain
  • The link between Router3 and Router4 is one standalone broadcast domain
  • The link between Router5 and Server0 is one standalone broadcast domain

So, putting all this together, can you continue counting the collision and broadcast domains in the diagram and tell us the numbers you have arrived to?

Feel free to ask further!

Best regards,
Peter

 

denys96530510
Level 1
Level 1

Thank you Sir for the answer, I have for

1) Collusion D. : 21

    Broadcast D.: 10

2) Collusion D. : 20 

    Broadcast D.: 10

Hello,

A small correction in vocabulary: It is collision ("i"), not collusion ("u").

Regarding the count of the collision domains - I agree with the number 21. But why do you think there is a difference based on the use of the native VLAN? The native VLAN influences the presence or absence of 802.1Q tags in Ethernet frames. But Ethernet frames travel across a medium, and that medium can be collision-free or collision-prone regardless of VLAN tags. As I explained earlier, collisions are Layer 1 matter and VLANs have no influence on the presence of collisions or collision domains. Can you explain how you arrived at a different number of collision domains in both cases?

For the broadcast domains - I can see 9, not 10. Can you list your broadcast domains individually, explaining what devices are part of each of the broadcast domains?

Best regards,
Peter

 

I calculate it again and in Broadcast they are 9. I add the connection from Router 0 to Cloud that why i get 10 and it was a mistake. And in native Collision Domain I subtracted one collision because i think in switch 3 are two PC in same Vlan. Sorry  for my bad English im from Germany. 

Hello,

No reason to apologize!

We still don't match in the counts.

Let's compare our domains ignoring any VLANs, assuming there are no VLANs used.

Broadcast domains:

  1. Server0 - Router5
  2. Router5 - Router3
  3. Router3 - Router4
  4. Router3 - Router1
  5. Router1 - Router0
  6. Router1 - Router2
  7. Router0 - Router2
  8. Router0 - Cloud
  9. The entire switched network below routers 2, 1, 4

Collision domains: Every single link in your topology is a separate collision domain, including the one toward the cloud, hence 21.

So, where does your counting differ?

Best regards,
Peter

 

Thank you now I understand this, the failure is, I don’t have a connection between:

Router 4 - Switch 0

Router 2 - Switch 3 

but I add it to my Collision Domain.

 

Hello,

Ah, okay - well, shutdown links are obviously not a part of any domain since for any practical purpose, they do not exist.

I have considered all the links as being up and active. If you know that some of them are shutdown, of course, the counts will be different. But I am quite sure that now you know how to count the domains

Good luck in your networking studies!

Best regards,
Petre

 

Joseph W. Doherty
Hall of Fame
Hall of Fame

BTW, one thing to note, in your diagram, there may be no, or zero, collision domains.

If you're thinking "say what!?", that's because since fastEthernet (although often retrofitted to 10 Mbps Ethernet), Ethernet can be "half duplex" or "full duplex".  The former has collision domains, the latter does not.

Further, although Peter is correct, in that switches buffer received frames, and a collision on the switch's port would not create a collision on any other port (as the corrupted frame is not forwarded), to be clear, it's possible a received frame, being transmitted to another port, or ports, could create a collision on another port, or ports.  (Again, the other port, or ports, would need to be in half duplex mode.)

The latter is true, again for half duplex ports, even with a L3 separation, between ports, too.

So, to recap, collision domains exist only on half duplex "shared" segments, where all NICs connected to it share a "common wire" for transmission and reception.  Do know, however, 10Base-T actually have two physical wires (which is what allowed the "creation" of full duplex.)

Hi Joseph,

Thanks for joining the discussion! : )

We've opened a can of worms here, didn't we? : ) My take is this one, and this is getting quite involved:

A collision is an undesirable superposition of electric signals from multiple senders on a transmission medium which makes it impossible for receivers to correctly decode the meaning of those signals.

In order for a collision like this to happen, we must
  • have a medium that uses the same physical path for both directions of data exchange (Tx, Rx), or
  • have a device (such as a hub) whose mechanism of operation inevitably implies that if it receives two simultaneous independent transmissions, it will forward them out in real time combined, thereby superimposing (even if level-limiting) them

Looking at switches interconnected with twisted pair cabling, none of these conditions is met. On 10Mbps and 100Mbps Ethernet, twisted pair cabling uses distinct wire pairs for Tx and Rx directions, making it impossible for a collision to occur on the medium itself. Moreover, switches interpret the received signals as frames and forward frames, not signals per se. If the signal is unintelligible, a frame cannot be reconstructed from it, and so the switch won't forward it.

To complete the thought, 1Gbps and faster Ethernet variants use all four wire pairs in the twister pair cable simultaneously for both Tx and Rx directions, and the devices use digital signal processing techniques to suppress their own signal from the signal superposition detected on the wires, yielding the signal sent by the other device.

The bottom line is: With switches and twisted pair cabling, there can be no physical collision per the definition above - it is principially impossible.

The "collisions" we truly talk about between switches and higher layer devices are not physical but rather logical - sending data when the other device is not prepared to receive them during its own transmission process. This can happen if the link operates in half duplex mode (or if there is a duplex mismatch). This "collision" is not a physical collision in terms of the signals getting unintelligibly superimposed, but rather a logical violation of the principle that there is only one speaking device on the medium at any moment.

Hence, while I follow your logic and can understand that we could declare there is no collision domain in the OP's network at all, I'd rather take a step back and say that there won't be any collisions - but that does not obviate the existence of the collision domains in the first place. I'm more inclined to say that they are there, just there are no collisions expected, assuming all links operate in full duplex mode.

I know, this is a topic with multiple possible points of view - I'm okay if this doesn't hit the nail for you.

Best regards,
Peter

 

(BTW, Peter, my prior post wasn't aimed at your post, but at the OP, to highlight the difference HD and FD can make in wired Ethernet, on the subject of collision domains. But yes, a can of worms has been opened. - laugh)

"I know, this is a topic with multiple possible points of view - I'm okay if this doesn't hit the nail for you."

Peter, actually I believe we're mostly (laugh) in full agreement. Likely a few of the points I made, were not made clearly.

I think we're both in 100% agreement, with full duplex, there are no "collisions". So, if the OP topology was all FD (likely in a modern/current wired Ethernet environment) there would be zero collision domains.

Ah, but that last part of my statement, ". . .there would be zero collision domains.", is likely a "point of view" difference.

If a collision is totally impossible, not ". . . just there are no collisions expected . . .", the former precludes, in my (not so) humble opinion, there being a collision domain. (NB: from a quick Google search, it appears, to me, most consider a collision domain only where collisions are possible.)

Rereading your posts in this discussion, and rereading an old discussion (https://community.cisco.com/t5/routing/does-collision-exists-in-switches/td-p/2603901), makes me wonder whether we have a different understanding about Ethernet HD operation, on, for example, twisted pair, where physical collisions cannot happen (between a pair of device!!!).

Using 10Base-T for discussion purposes, first we must understand, that between a host and a hub, or switch, there can be no physical collision. (Another point of agreement, I believe.)

On a hub, though, hosts transmitting at the same time can create a physical collision within the hub (ditto - agreement), so a way was needed to notify the hub connected hosts (possibly you overlooked, or the importance and/or implications of?). This was accomplished by having every host Ethernet NIC self loopback its TX with its RX, there by detecting a collision with another host.

On a switch, which can buffer frames, you can eliminate the possibility of collisions. And so, FD mode was created.

However Ethernet interfaces (including on switches, etc.), operating in HD, cannot assume/know there's not a hub on the other end! So, they continue to use self loopback to detect physical collisions within a possible hub (again, although not a potential issue for a switch).

In other words, if a switch and host are interconnected, using, for example, twisted pair, and even though a physical collision isn't possible, and both are in HD, if the switch and host transmit at the same time, they will both physically detect the overlap and treat it like a physical collision.

To eliminate collision "simulation", you need both a buffering device (e.g. switch) and FD. HD "simulates" collisions, when using switches, although switches, in some situations, still offer benefits that an actual hub would not.

For example, consider three hosts connected to a hub vs. switch, hosts in HD; host A sending to host B, host B sending to host C, host C sending to host A. On an actual hub, more than one host transmitting at same time creates a physical collision within the hub. On the switch, assuming unidirectional flows, there would be no "collisions" (because it would be like host A <hub1> host B, host B <hub2> host C, host C <hub3> host A). (Also, besides lack of "collisions", in this example with switch, you have 3x the "raw" bandwidth.)

So, Peter, does the above make any sense?

Hi Joe,

Thanks for the response!

It does appear indeed that we are in a major agreement, and in fact, I don't see anything substantial we would differ in. I am unsure if I can pinpoint what you believe me and you see differently. You mentioned this:

so a way was needed to notify the hub connected hosts (possibly you overlooked, or the importance and/or implications of?).

I am not aware that I have overlooked that, or that I gave off such an impression. It's quite clear to me that on a hub with three connected hosts, A, B and C, if A and B start sending data simultaneously, C will necessarily receive something that is a mix of both signals as processed by the circuitry of the hub. It won't break the signalling scheme on the wire with, say, double the normative voltage (since the bits are regenerated by the hub, not just naively amplified by it), but it won't make sense as far as the encoded information is concerned. That is why this collision is also called a "remote collision" as opposed to a "local collision" - it does not violate the encoding scheme.

If a collision is totally impossible, not ". . . just there are no collisions expected . . .", the former precludes, in my (not so) humble opinion, there being a collision domain.

I am compelled to approach this differently since I tend to treat a "domain" as a "bounded scope of impact", not a "bounded scope of occurrence". In other words, to me, a collision domain is the scope of the network affected by a collision if it occurred, but I am not really asking whether the collision can occur there. To me, it's the boundary that's the most interesting (and definitoric) thing, not the occurrence itself.

This is similar to IPv6 and broadcast domains. I've seen claims that "there are no broadcast domains in IPv6". My standpoint is: Well, a broadcast domain is a Layer2 matter, not a Layer3 matter, so IPv6 cannot really abolish a broadcast domain. The fact that IPv6 doesn't use broadcasts doesn't mean that there isn't an underlying broadcast domain - just that IPv6 doesn't make use of it.

Agreed, with full duplex everywhere, the collisions are principially impossible. I'd say that then, perhaps, it would be more proper not to discuss the collision domains at all - so instead of saying that there are 0 such domains there, we should say that the very notion of the collision domains does not apply.

Best regards and respects,
Peter

Peter, thanks for your new posting!

Again, yea, it looks like we have different view about what is, or is not, a collision domain. I believe I understand what you're stating, but again, how can there be a bound on something that cannot happen at all?  For example, we both agree two "shared wire" network segments, separated by, for example, a bridge, are indeed bounded by the bridge.  Yet, change those two network segments, into segments where collisions are impossible, what's there to bound?  Or, in other words, when you write ". . . I tend to treat a "domain" as a "bounded scope of impact", . . .", yet, again, if there is no possible impact, means, to me, you cannot define the scope.

Of course, laugh, perhaps you take more of a Calculus approach.  I know when introduced to Calculus, I wondered, then, and now, how you can compute an actual area of that's bounded by infinity.  I.e. the area is never "closed", because it's infinite, but when you get there, the area is exactly X.  Then there were also equations which you could solve for the surface area of a solid, but not its volume.  Oh, my, that still causes my head to hurt.

In this case, I think we'll agree to disagree on that, but not a disagreement that's of any concern, at least, to me.

Okay, regarding you providing a possible impression of overlooking, importance and/or implications, yes, I, at least got that impression.  (Oh, and as an aside, not any impression of lack of knowledge or understanding.)

What I've been trying to highlight is, shall we say, the "quirks" of Ethernet designed for connecting to hubs, vs. connecting same to switches.

You, yourself, in your last post explicitly mention 3 hosts connected to a hub, with two transmitting, cause an issue.  (You also correctly describe that physically, since a hub is a digital repeater, the "signals" on the wire would not be an analog mess as would be found on a real shared wire, like 10Base-2 or -5.)

What you didn't mention is two hosts would work just fine, transmitting concurrently, or could, but they won't!  This because of the self feedback designed for the 3 or more hosts case, causes the 2 host case to fail too.

The implications of this, on a switch, which is physically 2 hosts/NICs, it doesn't need to fail, but it does, to continue to work as it does, correctly, for 3 or more hosts on a hub.  This design causes "collisions" with switches, in HD mode, although they are not physically possible.

FD mode, basically, "informs" the connecting (2) hosts/NICs, they no longer need to self loopback avoiding "collisions" that are, already, not physically present.

It's this point, of, shall we also say, of "backward compatibility" that you appear to be overlooking (again, just to me, and further, something, I suspect you fully understand).

Conversely, when discussing HD and FD, you touch upon mixed (HD and FD) usage between two NICs, and or how switches would not forward corrupted frames (although do I recall [?] some cut-through switches can, to some degree do that).

Unfortunately, the written word, sometimes, does not exactly convey what the author intended.  (I know my poor prose often causes that.)

So again, to your statement "I am not aware that I have overlooked that, or that I gave off such an impression.", also again, to me you did, but such could be wholly my fault.  Conversely, what I've been trying convey, and (again, my impression) failing at, likewise, could totally be my fault.

In other words, other than our view of how to define a CD, we may be in 100% agreement.

 

As another aside . . .

I'm old enough to have lived through some major network technology changes, and their impact in large production environments.

For example, a couple of decades ago, I was working in a Fortune 100 company that was Big Blue, and for networking, still using token-ring.  Which, more-or-less they were happy with, but when TR NICs were still as expensive as current generation PCs, the latter including built-in 10/100 Ethernet NICs, they finally decided to upgrade from 4 Mbps TR to "faster" 10Base-T (on hubs).

I wasn't part of the Network group, but I convinced my group's management to "defer" upgrading their TR to Ethernet, which they accomplished.

Well, you should have heard the dismay, from other parts of the Enterprise, regarding the "lousy" network, at least on those parts "upgraded" to 10 Mbps Ethernet.

After enough of that, they upgraded to 10 Mbps switches.  I then recommended moving to it; which also removed all the performance complaints (except when they did have a duplex mismatched host/switch combination).  (BTW, for most user hosts, on a switch, performance didn't really matter, hugely, whether host/switch was HD/HD or FD/FD, as user hosts didn't generally have huge amounts of concurrent bidirectional data transfers.

Reason I mention this, I'm seen the actual impact, or not, of collision domains and HD and FD, hubs and switches.

Review Cisco Networking for a $25 gift card