Collision Domain and Broadcast Domain

Collision Domain and Broadcast Domain are two fundamental concepts in Ethernet network design and troubleshooting. A Collision Domain is the portion of a network where packet collisions can occur, while a Broadcast Domain is the portion where broadcast frames are flooded to all devices. Cisco switches separate Collision Domains but not Broadcast Domains (unless VLANs are used), whereas routers separate both. This article explains these concepts in detail, their behavior in Cisco switches and routers, and practical examples.

Collision DomainBroadcast DomainCisco Switch Router

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۲۳ فروردین ۱۴۰۵

Introduction

In Ethernet networks, two key concepts are essential for understanding network performance and design: Collision Domain and Broadcast Domain. These concepts directly affect network efficiency, security, and scalability. Cisco devices such as switches and routers behave differently regarding these domains.

What is a Collision Domain?

A Collision Domain is a segment of the network where if two devices transmit data at the same time, a collision occurs. In old hub-based networks, all ports shared one single Collision Domain.

Main characteristics:

  • Occurs in Half-Duplex mode
  • Managed by CSMA/CD
  • Almost eliminated in modern Full-Duplex networks

What is a Broadcast Domain?

A Broadcast Domain is the portion of a network where broadcast frames (such as ARP requests) are flooded to all devices. Any device that receives a broadcast frame belongs to the same Broadcast Domain.

Cisco Switch Behavior

Cisco switches:

  • Create a separate Collision Domain for each port (micro-segmentation)
  • By default, all ports belong to one single Broadcast Domain
  • Can separate Broadcast Domains using VLANs

Example on a Switch

A 24-port switch without VLANs:

  • Number of Collision Domains = 24 (one per port)
  • Number of Broadcast Domains = 1

Cisco Router Behavior

Cisco routers:

  • Each interface creates its own Collision Domain and Broadcast Domain
  • Do not forward broadcast frames from one interface to another
  • Act as a natural boundary for Broadcast Domains

Example on a Router

A router with 3 active interfaces:

  • Number of Collision Domains = 3
  • Number of Broadcast Domains = 3

Comparison Table: Switch vs Router

DeviceCollision DomainBroadcast Domain
HubAll ports sharedAll ports shared
Switch (no VLAN)One per portAll ports shared
Switch with VLANOne per portOne per VLAN
RouterOne per interfaceOne per interface

Checking and Configuring in Cisco IOS

Viewing Collision and Broadcast Information

Switch# show interfaces GigabitEthernet0/1
Switch# show vlan brief

Creating VLAN to Separate Broadcast Domains

Switch(config)# vlan 10
Switch(config-vlan)# name Sales
Switch(config-vlan)# exit
Switch(config)# interface range Gi0/1 - 8
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10

Important Design Considerations

  • The more Collision Domains you have, the fewer collisions occur (this is why switches are better than hubs).
  • Smaller Broadcast Domains mean less unnecessary traffic and better network performance.
  • Routers and Layer 3 switches are the best tools for separating Broadcast Domains.
  • In large networks, use VLANs, VTP, and inter-VLAN routing.

Conclusion

Understanding Collision Domain and Broadcast Domain is essential for designing efficient and trouble-free networks. Switches separate Collision Domains per port and use VLANs to separate Broadcast Domains. Routers naturally separate both domains. Mastering these concepts helps you design better Cisco networks, troubleshoot effectively, and optimize performance.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه