Table of Contents
- Module 1: Course Overview
- Module 2: Physical Network Design
- Module 3: Layer 2 Design
- Module 4: IP and LAN Multicast
- Introduction
- IP Multicast Addressing
- LAN Multicast and MAC Address Derivation
- Internet Group Management Protocol (IGMP)
- Protocol Independent Multicast (PIM)
- Configuring PIM (Lab)
- Simulating a Multicast Source
- Reverse Path Forwarding (RPF)
- Configuring a Multicast Receiver
- IP Multicast and Ethernet Integration
- Module 4 Summary
- Quick Reference Tables
Module 1: Course Overview
A poorly designed network cannot be fixed with just configuration commands. This course covers how to design reliable and scalable Cisco enterprise networks across three main topics:
- Physical network designs and traffic patterns — how topology choices affect throughput, reliability, and cost.
- Layer 2 topologies — how VLAN scope and routing placement affect stability and performance.
- IP and LAN multicast — how one-to-many delivery works at layers 2 and 3.
Prerequisites: CCNA-level networking skills, including familiarity with routing protocols (OSPF, EIGRP, BGP basics), switching, VLANs, and subnetting.
Module 2: Physical Network Design
Module 2 Introduction
Network design is unavoidable. Even when expanding an existing network to a new branch, you are doing design — the existing network constrains your choices, which can make design feel trivial. But when you must design from scratch, or when you need to justify or change an existing design, a solid understanding of theory is essential.
The most important insight is that networking is inter-process communication. The primary purpose of any network is to allow applications running on different systems to communicate. Every design decision should ultimately serve that goal.
Most “design work” in practice is copying what already exists. That is not inherently wrong, but it means most engineers never deeply understand why a design works — or why it breaks under different conditions.
The OSI Model Is Not What You Think
The Open Systems Interconnection (OSI) reference model is widely misunderstood. It is not an outdated relic, nor is it replaced by TCP/IP. TCP and IP are protocols that implement the OSI model; they are part of it, not an alternative to it.
The fundamental concept: networking is inter-process communication — a process on one device communicating with a process on another device.
In the late 1970s, writing a new networking application was extremely difficult. You had to customize it for each individual network type. The OSI working group created the 7-layer model to solve this: define a standard set of interfaces between layers so that any layer can be swapped out without affecting the others.
The 7 OSI layers:
flowchart TB
L7["Layer 7 — Application\nHTTP · SSH · FTP · Telnet · DNS · SNMP · SMTP"]
L6["Layer 6 — Presentation\nData encoding · Encryption · Compression"]
L5["Layer 5 — Session\nSession establishment · Maintenance · Termination"]
L4["Layer 4 — Transport\nTCP (reliable) · UDP (unreliable)\nPort numbers: SSH=22, HTTP=80, HTTPS=443"]
L3["Layer 3 — Network\nInternet Protocol (IP)\nRouting between subnets"]
L2["Layer 2 — Data Link\nEthernet · MAC addresses · VLANs · MTU\nPPP · HDLC"]
L1["Layer 1 — Physical\nNIC hardware · Cables · Connectors\nElectrical/optical signals"]
L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1
Key insight: Layers 5 and 6 (Session and Presentation) are rarely discussed independently in modern implementations because modern application protocols typically handle session and presentation concerns internally. The layers that matter most for network design are 1, 2, 3, and 4.
Why this matters for design: Because the layers are independent, a physical topology decision (Layer 1) constrains what is possible at Layer 2, which in turn constrains Layer 3. You cannot fix a bad physical design with clever routing configuration.
Layers of Networks
All networks are virtual and software-defined. The only physical aspect of a network is the physical media and interfaces. Everything else is virtual. When you design a network, you are never designing just one network — you are designing multiple layered networks simultaneously.
Protocol Stack on a Single Host
flowchart TB
App["Application Layer\nHTTP, SSH, FTP, Telnet\nLayer 7 protocols tied to TCP/UDP port numbers"]
Transport["Transport Layer\nTCP and UDP\nImplemented by the OS kernel"]
Network["Network Layer\nInternet Protocol (IP)\nImplemented by the OS — no separate installation needed"]
DataLink["Data Link Layer\nNIC driver\nMAC addresses · VLAN tags · MTU sizes"]
Physical["Physical Layer\nNetwork Interface Card (NIC)\nPhysically connects to the network medium"]
App --> Transport --> Network --> DataLink --> Physical
Note: IP and TCP/UDP are implemented directly by the operating system. There is no separate “IP module” to install — they come with every modern OS.
How Layers Span Across the Network
Consider two hosts, Host A in subnet 192.168.1.0/24 and Host B in subnet 10.0.0.0/24. They cannot communicate at Layer 2 (different broadcast domains). They must communicate at Layer 3 using IP. A router at Layer 3 forwards packets between subnets by decapsulating the Layer 2 frame, reading the IP destination, and re-encapsulating into a new Layer 2 frame on the outbound interface.
Layer 2 (Ethernet) specifics:
- Every Ethernet segment is a shared medium — historically a physical coaxial cable, today replaced by VLANs.
- A VLAN = broadcast domain = subnet. It is the modern shared medium.
- Two routers connected to the same VLAN can communicate at Layer 2 even if not physically connected to each other.
- Ethernet uses MAC addresses to identify interfaces. IP addresses also identify interfaces, not hosts. This is a design decision from early IP development, and it is one reason IP mobility is difficult today.
Layer 4 (Transport) specifics:
- Moving data from one interface to another is not enough. A process needs to indicate which process it wants to talk to on the remote end.
- Layer 4 solves this with port numbers. An SSH client connects to port 22; an HTTP client connects to port 80.
- Without port numbers, a host receiving a TCP segment would not know which application to deliver it to.
Start with the Physical Topology
Networking professionals gravitate toward Layers 2 and 3 because that is where configuration happens and results are predictable. But for network design, always start at Layer 1.
Physical layer reality:
- Rats chew cables. Lightning fries switch ports. Someone connects a rogue access point. Someone accidentally connects a hub.
- Layer 1 is unpredictable — you cannot plan for every physical-world eventuality.
- You cannot realistically simulate a production network.
Why the physical topology is foundational:
| Physical design determines… | Why it matters |
|---|---|
| Maximum number of supported devices | Sets the upper limit on network scale |
| Traffic patterns (path bits physically take) | Affects throughput, reliability, stability |
| Maximum throughput | Bandwidth ceiling for the entire network |
| Reliability and stability | Redundancy paths and failure domains |
| Minimum cost floor | Physical infrastructure is the biggest capital expense |
| Flexibility for future logical changes | A bad physical topology cannot be “configured around” |
Core principle: The physical design is the most significant limiting factor of the network. It puts an upper bound on flexibility, speed, and reliability, and a minimum bound on cost. Everything at Layer 2 and above is either enabled or hindered by the physical topology.
Also remember: Layer 1 and Layer 2 are tightly coupled. Any physical change immediately affects the Layer 2 topology (VLANs, spanning tree, MAC tables).
Traffic Flow Patterns
The expected traffic flow pattern should be one of the biggest determining factors of your network design. A traffic flow pattern describes the path that packets tend to take through the network.
There are two dominant traffic patterns:
| Pattern | Also Called | Typical Location | Description |
|---|---|---|---|
| Client-to-Server | North-South | Campus networks | Users (North) accessing resources in a data center or Internet (South) |
| Server-to-Server | East-West | Data center networks | Servers communicating with each other within the data center fabric |
Why “North-South” and “East-West”?
These terms come from how network engineers historically draw diagrams. The campus or user side is drawn at the top (North); the data center or Internet is at the bottom (South). Servers within the same tier are shown side by side (East-West).
flowchart TB
subgraph Campus["Campus Network (North)"]
direction LR
C1[Client 1]
C2[Client 2]
C3[Client 3]
end
subgraph DC["Data Center (South)"]
direction LR
S1[Server A]
S2[Server B]
S3[Server C]
S1 <-->|"East-West"| S2
S2 <-->|"East-West"| S3
end
Campus -->|"North-South\nClient-to-Server"| DC
Campus -->|"North-South"| Internet[Internet/WAN]
Design implication:
- Mostly North-South → use the Three-Tier or Two-Tier Collapsed Core architecture.
- Mostly East-West → use the Spine and Leaf architecture.
The Three-Tier Architecture
The three-tier architecture has been the standard for campus networks for decades. Its key advantage is scalability through a modular, building-block approach.
The Three Layers
flowchart TB
subgraph Core["Core Layer — always routed"]
CW1[Core Switch 1]
CW2[Core Switch 2]
CW1 <-->|"Routed link"| CW2
end
subgraph DB1["Access-Distribution Block 1"]
D1[Distribution Switch 1]
D2[Distribution Switch 2]
D1 <-->|"Routed link"| D2
A1[Access Switch 1]
A2[Access Switch 2]
D1 --- A1
D1 --- A2
D2 --- A2
end
subgraph DB2["Access-Distribution Block 2"]
D3[Distribution Switch 3]
D4[Distribution Switch 4]
D3 <-->|"Routed link"| D4
A4[Access Switch 4]
A5[Access Switch 5]
D3 --- A4
D3 --- A5
D4 --- A5
end
CW1 -->|"Routed"| D1
CW1 -->|"Routed"| D3
CW2 -->|"Routed"| D2
CW2 -->|"Routed"| D4
Core Layer
- The nexus of the network. Interconnects distribution blocks (and campuses, if multiple sites exist).
- All inter-switch links are always routed — no Layer 2 trunks, no spanning tree instances.
- Core switches have high port density and are therefore extremely expensive.
- Access VLANs never reach the core — the core sees only routed traffic.
Distribution (Aggregation) Layer
- Aggregates access switches and connects them to the core.
- Provides a layer of isolation: problems in the access layer cannot propagate to the core.
- Together with the access layer, forms the repeating Access-Distribution Block.
Access Layer
- Where end devices connect: workstations, phones, printers, access points.
- VLANs are defined here.
Scalability Model
The access-distribution block is the repeating module:
| Network Scale | Architecture |
|---|---|
| Small campus | 1 core + 1 distribution block |
| Medium campus | 1 core + 2–4 distribution blocks |
| Large campus | 2+ core switches + many distribution blocks |
Constraint: Adding distribution blocks requires ports on core switches. Core switches are extremely expensive — this is the main scalability cost.
The Two-Tier Collapsed Core
The two-tier collapsed core is the budget option. It flattens the distribution and core layers into a single collapsed core layer.
flowchart TB
subgraph CollapsedCore["Collapsed Core (Distribution + Core merged)"]
CC1[Collapsed Core Switch 1]
CC2[Collapsed Core Switch 2]
CC1 <-->|"Connected (unlike Spine-Leaf)"| CC2
end
A1[Access Switch 1]
A2[Access Switch 2]
A3[Access Switch 3]
A4[Access Switch 4]
CC1 --- A1
CC1 --- A2
CC2 --- A2
CC2 --- A3
CC1 --- A4
Advantages
| Advantage | Detail |
|---|---|
| Lower cost | Fewer switches to purchase and manage |
| Simpler management | Fewer devices, fewer configurations |
| Good for stable networks | When network size is fixed |
Disadvantages
| Disadvantage | Detail |
|---|---|
| Poor scalability | Growth requires more core switches or migration to three-tier |
| No modularity | No replicable access-distribution blocks |
| No isolation layer | No buffer between access layer and core |
| VLAN traverses core | Extending VLANs requires them to traverse the core; misconfiguration can cascade |
| Change control risk | Even routine VLAN changes touch the core |
Critical difference from three-tier: In the three-tier architecture, access VLANs never reach the core. In the two-tier collapsed core, VLANs may traverse the core switches — a mistake can bring down the entire network.
Spine and Leaf Architecture
The spine and leaf architecture has all but replaced the three-tier and two-tier architectures in data center networks. It is optimized for East-West (server-to-server) traffic.
flowchart TB
subgraph Spine["Spine Layer — NOT directly interconnected"]
SP1[Spine Switch 1]
SP2[Spine Switch 2]
end
subgraph Leaf["Leaf Layer"]
L1[Leaf 1]
L2[Leaf 2]
L3[Leaf 3]
L4[Leaf 4]
end
SP1 --- L1
SP1 --- L2
SP1 --- L3
SP1 --- L4
SP2 --- L1
SP2 --- L2
SP2 --- L3
SP2 --- L4
SV1[Server 1] --- L1
SV2[Server 2] --- L2
SV3[Server 3] --- L3
SV4[Server 4] --- L4
Key Structural Differences vs. Two-Tier Collapsed Core
| Feature | Spine and Leaf | Two-Tier Collapsed Core |
|---|---|---|
| Top switches connected? | No — spine switches are NOT interconnected | Yes — core switches are connected |
| Inter-switch links | All routed — no STP, no VLAN trunks | May include Layer 2 trunks |
| Server redundancy | Dual-connected to 2 leaf switches | Variable |
| Hop count between any two servers | Always equal (2 hops: leaf → spine → leaf) | Variable |
| Traffic type optimized for | East-West | North-South |
Equal-Cost Multi-Pathing (ECMP)
Because all links are routed and hop counts are equal, every server-to-server flow can leverage ECMP — multiple equal-cost paths simultaneously. This multiplies effective bandwidth without spanning tree.
Server A → Leaf 1 → Spine 1 → Leaf 3 → Server C
Server A → Leaf 1 → Spine 2 → Leaf 3 → Server C
(Both paths equal cost — ECMP uses both simultaneously)
Advantages and Disadvantages
| Aspect | Detail |
|---|---|
| Massive bandwidth | ECMP across all spine-leaf links |
| High reliability | Multiple equal paths, no single point of failure |
| Predictable latency | Always 2 hops between any two servers |
| No spanning tree | All inter-switch links are routed |
| Cost | Expensive; every leaf connects to every spine |
| Scalability ceiling | Each new leaf needs a port on every spine; each new spine needs a port on every leaf — links grow exponentially |
Module 2 Summary
| Architecture | Best For | Key Advantage | Key Disadvantage |
|---|---|---|---|
| Three-Tier | Campus, North-South traffic | Scalable, modular, VLAN isolation | Expensive (core switches) |
| Two-Tier Collapsed Core | Small/stable, budget-constrained | Lower cost, simpler | Poor scalability, core VLAN risk |
| Spine and Leaf | Data center, East-West traffic | Maximum bandwidth, ECMP, no STP | Expensive, exponential link growth |
Key takeaways:
- Always start with the physical design — it constrains everything else.
- Networking is inter-process communication. Understand how applications use the network before designing it.
- Select the physical architecture based on the expected traffic pattern.
- Layer 1 and Layer 2 are tightly coupled — physical changes affect Layer 2 topology.
- Once the physical design is locked in, all subsequent decisions are logical configurations that are either enabled or hindered by the physical topology.
Module 3: Layer 2 Design
Module 3 Introduction
Despite the name, Layer 2 design inherently involves Layer 3 decisions. How you design your VLANs determines where and how you configure IP routing. Layer 2 design comes down to two questions:
- Where should IP routing take place? In the three-tier architecture, the core is always routed — but what about the distribution layer? The access layer?
- How large should your VLANs/subnets be? Should a VLAN span multiple access switches, or just one?
These questions interact with trade-offs in convenience, cost, scalability, reliability, and performance. There is no universally “correct” answer — the right design depends on the specific network requirements.
Switched and Routed Interfaces
Understanding the difference between switched (Layer 2) and routed (Layer 3) interfaces is fundamental to Layer 2 topology design.
Switched Interfaces (Switchports)
A switchport operates at Layer 2. It can be:
- An access port — single VLAN
- A trunk port — multiple VLANs tagged with 802.1Q
When a switch receives an Ethernet frame on a switchport:
- Destination MAC in MAC address table → forward to the appropriate port.
- Destination MAC unknown → flood out all ports in the same VLAN.
Switchports cannot have an IP address assigned directly. To give a VLAN an IP address on a multilayer switch, create a Switched Virtual Interface (SVI):
! Create SVI for VLAN 10 (acts as the default gateway for the subnet)
interface Vlan10
ip address 192.168.10.1 255.255.255.0
no shutdown
! Place a physical port into VLAN 10 (access mode)
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
! Configure a VLAN trunk (carries multiple VLANs)
interface GigabitEthernet0/2
switchport mode trunk
switchport trunk allowed vlan 10,20,30
Routed Interfaces (Layer 3)
A routed interface has an IP address assigned directly. Used when the switch performs IP routing with a directly connected device.
A routed interface:
- Does NOT forward Ethernet frames → bridging loops are impossible
- Is not a member of any VLAN
- Does not participate in spanning tree
- On receipt of a frame: if destination MAC != interface MAC → discard; if destination MAC == interface MAC → decapsulate the IP packet and route it
! Convert a switchport to a routed (Layer 3) interface
interface GigabitEthernet0/3
no switchport
ip address 10.0.12.1 255.255.255.0
no shutdown
| Feature | Switched Interface | Routed Interface |
|---|---|---|
| IP address | Not directly (use SVI) | Assigned directly |
| VLAN membership | Yes (access or trunk) | No |
| Spanning Tree | Yes | No |
| Frame forwarding | Yes (floods unknown unicast) | No (discards non-self MACs) |
| Bridging loops possible? | Yes | No |
| Use case | End-device connectivity, VLAN extension | Inter-switch/inter-router routing |
Switched Topologies
In a switched topology, the access-distribution layer uses Layer 2 switching (switchports and VLANs). The core layer always uses routed links.
Why use a switched topology?
- Convenience: A VLAN can span multiple access switches — printers scattered across different access switches can share the same VLAN; moving them requires no IP address changes.
- Easy management: Adding a switch to the topology is straightforward.
Trade-off: Broadcast domains do not scale indefinitely. As more devices join a VLAN, unknown unicast flooding and misbehaving NICs create performance problems.
Best practice: Keep VLANs to fewer than 100 devices.
| Type | Description | Spanning Tree Role |
|---|---|---|
| Looped | Redundant Layer 2 links; STP prevents bridging loops | Critical — must prevent loops |
| Loop-free | No redundant Layer 2 links; bridging loops cannot occur | Fail-safe only |
Looped Topologies
Looped Triangle
The most common looped topology. Distribution switches are directly connected; each access switch connects to both distribution switches, creating Layer 2 loops in every VLAN.
flowchart TB
subgraph Distribution["Distribution Layer"]
D3["Dist Switch 3"]
D4["Dist Switch 4"]
D3 <-->|"L2 Trunk\nVLAN 10+20"| D4
end
A5["Access Switch 5"]
A6["Access Switch 6"]
D3 -->|"VLAN 10 BLOCKED\nVLAN 20 forwarding"| A5
D4 -->|"VLAN 20 BLOCKED\nVLAN 10 forwarding"| A5
D3 --- A6
D4 --- A6
Spanning tree behavior:
- STP blocks specific VLANs on specific ports (not entire ports).
- Switch 5, link to Distribution 3: VLAN 10 blocked, VLAN 20 forwarding
- Switch 5, link to Distribution 4: VLAN 20 blocked, VLAN 10 forwarding
- Result: Switch 5 actively uses both uplinks (one per VLAN)
Problem: Link failure triggers STP re-convergence — can take several seconds, dropping traffic.
Port consumption: Each access switch uses two ports on the distribution layer (one per distribution switch).
Looped Square
Access switches connect to only one distribution switch each. Access switches are also connected to each other horizontally for redundancy; spanning tree blocks the horizontal link.
flowchart TB
D3["Dist Switch 3"] <-->|"Trunk"| D4["Dist Switch 4"]
A5["Access Switch 5"] -->|"Single uplink"| D3
A6["Access Switch 6"] -->|"Single uplink"| D4
A5 <-->|"STP BLOCKS this link"| A6
Advantage: Fewer ports consumed on distribution switches (one uplink per access switch).
Advantage: The ring can be extended — add more access switches in the chain.
Disadvantage: If an uplink fails, traffic flows horizontally through adjacent access switches. One distribution uplink may carry traffic from multiple access switches, creating a bottleneck.
Loop-Free Topologies
Loop-free topologies have no Layer 2 redundant links. Bridging loops cannot occur. Spanning tree runs as a fail-safe but is never the primary resiliency mechanism. First-hop redundancy protocols (HSRP, VRRP, GLBP) provide gateway redundancy instead.
Loop-Free V (Cisco Recommended)
Each access switch has two uplinks to the distribution layer, but the distribution switches have no direct Layer 2 connection to each other. Visually resembles a “V”.
flowchart TB
subgraph Distribution["Distribution Layer — No L2 link between them"]
D1["Dist Switch 1\n(HSRP Active)"]
D2["Dist Switch 2\n(HSRP Standby)"]
end
A1["Access Switch 1\nVLAN 10 only"]
A2["Access Switch 2\nVLAN 20 only"]
D1 -->|"Uplink (active)"| A1
D2 -->|"Uplink (active)"| A1
D1 -->|"Uplink (active)"| A2
D2 -->|"Uplink (active)"| A2
Characteristics:
- All links are simultaneously active — no STP-blocked ports, no wasted bandwidth.
- Resiliency via FHRP (HSRP/VRRP) at the distribution layer.
- No direct Layer 2 connection between distribution switches → no Layer 2 loops.
Critical constraint: Do NOT extend a VLAN to more than one access switch. Doing so either creates a Layer 2 loop (breaking the loop-free property) or leaves an access switch with no redundant path to the distribution layer.
Loop-Free U
Similar to the V but access switches are also connected to each other horizontally. Looks like a “U” or smiley face.
Problems:
- Traffic flows horizontally through access switches → inefficient, taxes access switches.
- Still requires FHRP at the distribution layer.
- Only justified when you need a VLAN to span exactly two access switches.
- Extending VLANs beyond two access switches forces traffic through multiple chained access switches — increasingly inefficient.
Loop-Free Inverted U
A mirrored version of the loop-free U. Same inefficiency problems. Only use when a VLAN spanning two access switches is unavoidable.
Loop-Free Topology Comparison
| Topology | VLAN Spans Multiple Switches? | STP Role | FHRP Needed? | Bandwidth Efficiency |
|---|---|---|---|---|
| Loop-Free V | No (1 VLAN per access switch) | Fail-safe only | Yes | High — all links active |
| Loop-Free U | Yes (max 2 switches) | Fail-safe only | Yes | Medium — horizontal traffic |
| Loop-Free Inverted U | Yes (max 2 switches) | Fail-safe only | Yes | Medium — horizontal traffic |
Routed Access Topology
The routed access topology is the highest-performing option. All links in the access-distribution block are routed (Layer 3). There are no Layer 2 links, no spanning tree, and no VLAN trunks in the access-distribution block.
flowchart TB
subgraph Core["Core Layer (Routed)"]
CW1[Core Switch 1]
CW2[Core Switch 2]
CW1 <-->|"Routed"| CW2
end
subgraph Dist["Distribution Layer (Routed)"]
D1[Dist Switch 1]
D2[Dist Switch 2]
end
subgraph Access["Access Layer (Routed — requires L3 switches)"]
A1["Access Switch 1\nDefault GW for VLAN 10\n192.168.10.1/24"]
A2["Access Switch 2\nDefault GW for VLAN 20\n192.168.20.1/24"]
end
Hosts1["Hosts\nVLAN 10\n192.168.10.0/24"]
Hosts2["Hosts\nVLAN 20\n192.168.20.0/24"]
CW1 -->|"Routed"| D1
CW2 -->|"Routed"| D2
D1 -->|"Routed"| A1
D2 -->|"Routed"| A1
D1 -->|"Routed"| A2
D2 -->|"Routed"| A2
A1 --- Hosts1
A2 --- Hosts2
Key Properties
- Each access switch is the default gateway for its locally defined VLANs.
- A VLAN can exist on only one access switch — no VLAN trunking needed.
- No Layer 2 links anywhere in the access-distribution block → bridging loops are architecturally impossible.
- All convergence uses Layer 3 routing protocols (OSPF, EIGRP) → fast convergence.
! Routed access switch — VLAN 10 locally only
ip routing
! SVI for VLAN 10 (default gateway for subnet)
interface Vlan10
ip address 192.168.10.1 255.255.255.0
no shutdown
! Routed uplink to Distribution Switch 1
interface GigabitEthernet0/1
no switchport
ip address 10.0.1.2 255.255.255.252
ip ospf 1 area 0
no shutdown
! Routed uplink to Distribution Switch 2
interface GigabitEthernet0/2
no switchport
ip address 10.0.2.2 255.255.255.252
ip ospf 1 area 0
no shutdown
Advantages and Disadvantages
| Feature | Routed Access | Switched Topologies |
|---|---|---|
| Convergence speed | Fast (routing protocols) | Slower (STP re-convergence) |
| Load balancing | ECMP across all routed links | STP blocks some links |
| Bandwidth efficiency | All links active | Some links blocked |
| Bridging loop risk | None (no L2 links) | STP required |
| Scalability | High | Limited by VLAN size |
| Stability | High | STP instability risk |
| Configuration effort | More (routing on each access switch) | Less |
| Hardware cost | Requires L3 access switches (more expensive) | L2 switches cheaper |
| VLAN spans multiple access switches | No | Yes |
Recommendation: For mission-critical networks, use routing everywhere. Bridging loops have taken down countless networks. No matter how carefully spanning tree is configured, a misconfiguration can cause catastrophic failure. With routed access, bridging loops are architecturally impossible because a VLAN can exist on only one access switch. This also makes troubleshooting far simpler.
Module 3 Summary
Layer 2 design fundamentally trades off:
- Where to do IP routing — pushing routing toward the edge improves performance and stability but adds cost and configuration complexity.
- How large to make subnets — larger VLANs spanning many switches are convenient but create spanning tree risk and scale poorly.
Full topology comparison:
| Topology | Routing Location | VLAN Scope | STP Criticality | FHRP Needed | Bandwidth | Best Use Case |
|---|---|---|---|---|---|---|
| Looped Triangle | Distribution + Core | Multi-switch | Critical | No | STP blocks some | Convenient multi-VLAN extension |
| Looped Square | Distribution + Core | Multi-switch | Critical | No | STP blocks horizontal | Larger VLAN extension |
| Loop-Free V | Distribution + Core | Single switch | Fail-safe | Yes | All links active | Cisco recommended loop-free |
| Loop-Free U | Distribution + Core | Two switches | Fail-safe | Yes | Horizontal traffic | Two-switch VLAN extension |
| Routed Access | Access + Distribution + Core | Single switch | Fail-safe | No | All links active | Mission-critical networks |
Module 4: IP and LAN Multicast
Module 4 Introduction
Multicast refers to any form of one-to-many communication: one sender, multiple receivers, one packet sent, network delivers copies to all interested receivers.
Why Multicast? Efficiency Comparison
Consider streaming audio to 1,000 hosts at one packet per second:
| Method | Packets Sent/Second by Source | Network Load |
|---|---|---|
| Unicast | 1,000 (one per receiver, each unique dst IP) | High — repeated copies on every shared link |
| Multicast | 1 (to multicast group address) | Low — routers replicate only as needed |
The source sends one packet to a single multicast IP address. Routers replicate and distribute it only to hosts that have requested it via IGMP.
The Multicast Trade-Off
Multicast has no mechanism for retransmitting dropped packets. Like broadcast radio: if you miss the broadcast, it’s gone. Suitable for:
- Audio/video streaming
- Stock ticker feeds
- One-to-many software distribution
Not suitable for applications requiring guaranteed delivery.
IP Multicast Addressing
An IP multicast packet is a standard IP packet addressed to a multicast IP address.
Multicast IP range: 224.0.0.0/4 — covers 224.0.0.0 through 239.255.255.255
Any IP address with a first octet of 224 through 239 is a multicast address.
Multicast Address Categories (RFC 5771)
| Block | Range | Description | Routed? |
|---|---|---|---|
| Local Network Control | 224.0.0.0/24 | Link-local; routing protocol addresses | No — stays in broadcast domain |
| Internet Control | 224.0.1.0/24 | IANA-assigned; publicly routable | Yes |
| Administratively Scoped | 239.0.0.0/8 | Private use (multicast RFC 1918 equivalent) | No — not publicly routable |
Common Local Network Control Addresses
| Address | Protocol/Purpose |
|---|---|
224.0.0.1 | All systems on this subnet (IGMP query destination) |
224.0.0.2 | All routers on this subnet |
224.0.0.5 | All OSPF routers |
224.0.0.6 | OSPF designated routers |
224.0.0.9 | RIPv2 |
224.0.0.10 | EIGRP |
224.0.0.13 | PIM routers (Hello messages) |
Note: All local network control addresses are link-local — they are never routed beyond the broadcast domain.
Lab Addressing
The lab examples use 239.7.7.7 — from the administratively scoped block, appropriate for internal/private networks.
LAN Multicast and MAC Address Derivation
IP multicast always implies LAN multicast. Whenever a source sends a multicast IP packet, it encapsulates it in an Ethernet frame with a multicast MAC address as the destination.
Unlike unicast, where MAC addresses are independent of IP addresses, multicast MAC addresses are derived from multicast IP addresses.
Multicast MAC Address Format
- IANA assigned the OUI
01:00:5Efor IPv4 multicast Ethernet frames. - Full format:
01:00:5E:xx:xx:xx - The lower 23 bits of the multicast IP address map to the last 23 bits of the MAC.
- The high bit of the 4th IP octet is always set to 0 in the MAC (this means 32 different IP addresses can map to the same MAC — 5 high bits are ignored).
How to Identify a Multicast MAC
The second hexadecimal digit from the left (i.e., the lower nibble of the first byte) of a multicast MAC address is always odd.
This is because the least significant bit of the first byte is set to 1 for all multicast/group addresses. That bit is always in the lower nibble of the first byte, making the second hex digit odd.
| MAC Address | Second Digit | Value | Type |
|---|---|---|---|
00:1A:2B:3C:4D:5E | A | 10 (even) | Unicast |
0A:00:00:00:00:00 | A | 10 (even) | Unicast |
01:00:5E:07:07:07 | 1 | 1 (odd) | Multicast |
07:00:00:00:00:00 | 7 | 7 (odd) | Multicast |
0B:00:00:00:00:00 | B | 11 (odd) | Multicast |
Derivation Example: 239.7.7.7 → MAC
Multicast IP: 239 7 7 7
Binary: 11101111 00000111 00000111 00000111
Lower 23 bits (ignore the high bit of the 4th octet):
_0000111 00000111 00000111
= 0x07 0x07 0x07
Multicast MAC: 01:00:5E:07:07:07
MAC Ambiguity
Only 23 IP bits map to the MAC (32 – 9 = 23 usable bits, 5 bits discarded). This means 32 multicast IP addresses share the same multicast MAC. For example:
224.1.1.1and225.1.1.1both map to01:00:5E:01:01:01(differ only in bits discarded during MAC derivation).
A host may receive multicast frames for groups it has not joined. The IP layer must verify the destination IP address after decapsulating to confirm relevance.
Multicast Frame Behavior at the Switch
- A switch treats multicast frames like unknown unicast: floods to all ports in the VLAN.
- IGMP snooping (enabled by default on Cisco switches) inspects IGMP membership reports and adds targeted entries to the CAM table. This limits multicast flooding to only ports with interested receivers.
Internet Group Management Protocol (IGMP)
IGMP is the protocol a receiver uses to tell its next-hop router which multicast groups it wants to receive traffic for.
Purpose
Without IGMP, a router would forward multicast traffic to all hosts on all attached subnets. IGMP allows routers to forward multicast packets only to hosts that have requested them.
IGMP Operations
sequenceDiagram
participant Host as Receiver Host
participant Router as Next-Hop Router
participant Network as Multicast Network
Router->>Host: IGMP Membership Query<br/>(to 224.0.0.1, every 60s)<br/>"Does anyone want multicast traffic?"
Host->>Router: IGMP Membership Report<br/>(to group address 239.7.7.7)<br/>"I want to join group 239.7.7.7"
Note over Router: Adds host's port to multicast group
Network->>Router: Multicast traffic for 239.7.7.7
Router->>Host: Forwards multicast to host
Host->>Router: IGMP Leave Group<br/>(to 224.0.0.2)<br/>"I no longer want 239.7.7.7"
Note over Router: Stops forwarding that group to host
| IGMP Message | Sent By | Destination | Purpose |
|---|---|---|---|
| Membership Query | Router | 224.0.0.1 | Who wants multicast? (every 60 seconds) |
| Membership Report | Host | Multicast group address | Join a multicast group |
| Leave Group | Host | 224.0.0.2 | Leave a multicast group |
IGMP Versions
| Version | Source Filtering | Default? | Notes |
|---|---|---|---|
| IGMPv2 | No — receives all traffic for the group | Yes (most systems) | Most widely deployed |
| IGMPv3 | Yes — requests traffic from specific sources | Less common | Source-Specific Multicast (SSM) |
Both IGMPv2 and IGMPv3 use IP protocol number 2.
IGMP Snooping
IGMP snooping (default on Cisco switches) inspects IGMP reports and maintains per-port multicast entries in the CAM table. This limits multicast flooding to only ports with interested receivers, dramatically reducing unnecessary traffic.
Protocol Independent Multicast (PIM)
IGMP handles receiver-to-router communication within a subnet. PIM handles multicast routing between routers across the network.
Why PIM Is Needed
When a receiver sends an IGMP Membership Report, its next-hop router must request multicast traffic from its upstream routers, which in turn request from their upstream routers, and so on. Each router builds a multicast routing table associating:
- An upstream (incoming) interface facing the source.
- One or more downstream (outgoing) interfaces facing receivers.
Key difference from unicast: Unicast routing is destination-based — a router forwards regardless of whether the destination wants traffic. Multicast routing is receiver-driven — routers only forward traffic when downstream receivers have requested it.
Why “Protocol Independent”
PIM is protocol-independent because it uses the existing unicast routing table (from OSPF, EIGRP, BGP, etc.) to make forwarding decisions. It does not maintain its own separate unicast topology.
PIM Adjacency
PIM version 2 routers:
- Send Hello messages every 30 seconds to
224.0.0.13using IP protocol 103. - Elect a Designated Router (DR) on each subnet — responsible for sending IGMP joins upstream (analogous to OSPF’s DR/BDR).
PIM Dense Mode (RFC 3973)
Push behavior: flood everywhere first, then prune where there are no receivers.
flowchart LR
Source["Multicast Source"] -->|"Floods to all"| R1
R1 -->|"Floods"| R2
R1 -->|"Floods"| R3
R2 -->|"Prune message upstream\n(no receivers)"| R1
Note["Dense Mode: PUSH\nFlood first, prune later\nPrune = stop sending\nGraft = start sending again"]
| Message | Direction | Meaning |
|---|---|---|
| Prune | Downstream → Upstream | ”Stop sending group traffic to me” |
| Graft | Downstream → Upstream | ”Start sending group traffic to me again” |
PIM Sparse Mode (RFC 7761)
Pull behavior: do not forward by default; send traffic only when explicitly requested.
- Host sends IGMP Membership Report → router sends PIM Join upstream toward the Rendezvous Point (RP).
- When host leaves → router sends PIM Prune upstream.
Rendezvous Point (RP)
In sparse mode, the RP is a PIM router acting as a hub/meeting point for a multicast group:
flowchart TB
Source["Multicast Source"] -->|"Registers traffic"| RP["Rendezvous Point (RP)"]
RP -->|"Distributes"| R1["PIM Router 1"]
RP -->|"Distributes"| R2["PIM Router 2"]
R1 -->|"Delivers"| Recv1["Receiver Group A"]
R2 -->|"Delivers"| Recv2["Receiver Group B"]
Why use an RP? When many sources exist, centralizing traffic prevents it from flooding everywhere. All PIM routers send Join/Prune messages toward the RP. The RP is typically placed at a central location in the network.
Sparse-Dense Mode
A hybrid mode where routers default to dense mode unless an RP is configured for a specific group, in which case they use sparse mode for that group.
| Mode | Behavior | RP Required | RFC |
|---|---|---|---|
| Dense | Flood + Prune (push) | No | 3973 |
| Sparse | Join + Prune (pull) | Yes | 7761 |
| Sparse-Dense | Dense by default; sparse if RP configured | Optional | — |
Configuring PIM (Lab)
Lab Topology
flowchart LR
R7["R7\nMulticast Source\n(no PIM)"]
R2["R2\nPIM router\ngi0/2 facing R7\ngi0/0 facing R1\ngi0/1 facing R3"]
R1["R1\nPIM router\ngi0/0 facing R2\ngi0/1 facing R3"]
R3["R3\nPIM router\ngi0/0 facing R4\ngi0/1 facing R2\ngi0/2 facing R1"]
R4["R4\nMulticast Receiver\n(no PIM)\ngi0/0 facing R3"]
R7 -->|"10.0.27.0/24"| R2
R2 <-->|"10.0.12.0/24"| R1
R2 <-->|"10.0.23.0/24"| R3
R1 <-->|"10.0.13.0/24"| R3
R3 -->|"10.0.34.0/24"| R4
Enabling IP Multicast Routing on R2
R2# configure terminal
R2(config)# ip multicast-routing
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip pim sparse-dense-mode
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip pim sparse-dense-mode
R2(config)# interface GigabitEthernet0/2
R2(config-if)# ip pim sparse-dense-mode
Enabling IP Multicast Routing on R1
R1# configure terminal
R1(config)# ip multicast-routing
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip pim sparse-dense-mode
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip pim sparse-dense-mode
Enabling IP Multicast Routing on R3
R3# configure terminal
R3(config)# ip multicast-routing
R3(config)# interface GigabitEthernet0/0
R3(config-if)# ip pim sparse-dense-mode
R3(config)# interface GigabitEthernet0/1
R3(config-if)# ip pim sparse-dense-mode
R3(config)# interface GigabitEthernet0/2
R3(config-if)# ip pim sparse-dense-mode
Lab note: No RP is configured. In sparse-dense mode without an RP, routers operate in dense mode by default — flooding and pruning.
Simulating a Multicast Source
R7 acts as the multicast source. It sends ICMP Echo Requests to 239.7.7.7:
R7# ping 239.7.7.7
No reply is expected — multicast is one-way. This simply generates multicast IP packets that R2 receives on GigabitEthernet0/2.
Verifying the Multicast Routing Table on R2
R2# show ip mroute 239.7.7.7
(*, 239.7.7.7), 00:01:23/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Dense, ...
GigabitEthernet0/1, Forward/Dense, ...
(10.0.27.7, 239.7.7.7), 00:00:05/00:02:54, flags: T
Incoming interface: GigabitEthernet0/2, RPF nbr 10.0.27.7
Outgoing interface list:
GigabitEthernet0/0, Forward/Dense, ...
GigabitEthernet0/1, Forward/Dense, ...
Multicast Routing Table Entry Types
| Entry Format | Name | Created When |
|---|---|---|
(*, G) | Star-comma-G | Router receives a packet for group G, receives an IGMP membership report, or receives a PIM Join/Graft for group G |
(S, G) | S-comma-G | Router receives multicast traffic from source S for group G |
Reverse Path Forwarding (RPF)
RPF is a loop-prevention and anti-spoofing mechanism for multicast routing.
The RPF Principle
The interface on which a multicast packet arrives (ingress) must be the same interface that unicast traffic toward the multicast source would use according to the unicast routing table.
The path that multicast traffic takes from source to a router is the reverse of the unicast path from that router to the source.
RPF Check on R1
R1# show ip mroute 239.7.7.7
(10.0.27.7, 239.7.7.7), ...
Incoming interface: GigabitEthernet0/0, RPF nbr 10.0.12.2
R1 expects multicast from source 10.0.27.7 (R7) to arrive on gi0/0 (facing R2 at 10.0.12.2).
Verify unicast path in CEF:
R1# show ip cef 10.0.27.7
10.0.27.0/24, version 6, epoch 0, cached adjacency 10.0.12.2
nexthop 10.0.12.2 GigabitEthernet0/0
CEF outgoing interface = gi0/0, next-hop = 10.0.12.2 — matches the multicast RPF interface and RPF neighbor. ✅ RPF check passes.
flowchart LR
R7["Source R7\n10.0.27.7"] -->|"Multicast arrives gi0/2"| R2
R2 -->|"Forwarded gi0/0\n(next-hop 10.0.12.2)"| R1
R1_note["R1 RPF Check:\nUnicast path to R7 = via R2 on gi0/0\nMulticast ingress = gi0/0\nRPF neighbor = 10.0.12.2\nResult: MATCH — packet accepted"]
R1 -.- R1_note
Why RPF matters: If a malicious host forges a multicast packet claiming to be from a different source, the packet would arrive on the wrong interface and fail the RPF check → dropped.
mtrace Command
R3# mtrace 10.0.27.7 10.0.34.4 239.7.7.7
! Traces: R7 (source) → R2 → R3 → R4 (receiver)
Configuring a Multicast Receiver
R4 joins the multicast group 239.7.7.7 on its gi0/0 interface (facing R3):
R4# configure terminal
R4(config)# interface GigabitEthernet0/0
R4(config-if)# ip igmp join-group 239.7.7.7
This sends an IGMP Membership Report for group 239.7.7.7 from R4 toward R3.
Verifying Traffic Delivery on R3
R3# show ip mroute 239.7.7.7 10.0.27.7
(10.0.27.7, 239.7.7.7), ...
Incoming interface: GigabitEthernet0/1, RPF nbr 10.0.23.2
Outgoing interface list:
GigabitEthernet0/0, Forward/Dense, ... ! facing R4 — forwarding
R3 forwards multicast to R4 via gi0/0. Delivery confirmed.
Verifying Pruning on R2
R2# show ip mroute 239.7.7.7 10.0.27.7
(10.0.27.7, 239.7.7.7), ...
Incoming interface: GigabitEthernet0/2, RPF nbr 10.0.27.7
Outgoing interface list:
GigabitEthernet0/1, Forward/Dense, ... ! facing R3 — forwarding
GigabitEthernet0/0, Pruned/Dense, ... ! facing R1 — PRUNED
R2 prunes the interface toward R1 because R1 has no receivers — no IGMP join was received via R1. PIM dense mode prunes the unnecessary branch.
Final Delivery Path
flowchart LR
R7["R7\nSource\n10.0.27.7"] -->|"gi0/2"| R2["R2\nPIM Router"]
R2 -->|"gi0/1 FORWARD"| R3["R3\nPIM Router"]
R2 -.->|"gi0/0 PRUNED\n(R1 has no receivers)"| R1["R1\nPIM Router"]
R3 -->|"gi0/0 FORWARD"| R4["R4\nReceiver\nIGMP joined 239.7.7.7"]
IP Multicast and Ethernet Integration
The Relationship
| Layer | Technology | Function |
|---|---|---|
| Layer 2 | Ethernet multicast | Frames to multicast MAC; flooded within broadcast domain |
| Layer 3 | IP multicast | Packets to multicast IP; routed between subnets |
| Together | IP over Ethernet | IP multicast packet encapsulated in Ethernet multicast frame |
Ethernet multicast requires no IP routing or addressing — two hosts in the same broadcast domain can exchange multicast Ethernet frames without any IP. IP multicast builds on top of Ethernet multicast.
Scenario 1: Same Subnet
Source → IP packet to 239.7.7.7
→ encapsulates: dst MAC = 01:00:5E:07:07:07, src MAC = source unicast MAC
→ switch floods frame within VLAN
Receiver (same VLAN):
→ receives frame
→ checks dst MAC (second digit = 1, odd → multicast)
→ decapsulates, checks dst IP (239.7.7.7)
→ matches joined group → processes
No router involvement. Pure Layer 2 multicast delivery.
Scenario 2: Different Subnets (Source in VLAN 10, Receiver in VLAN 20)
Source (VLAN 10) → IP packet to 239.7.7.7
→ encapsulates: dst MAC = 01:00:5E:07:07:07
→ flooded in VLAN 10
Router (has interface in VLAN 10):
→ receives frame, decapsulates IP packet
→ checks multicast routing table: (S,G) entry for 239.7.7.7
→ re-encapsulates with new Ethernet header
→ forwards out VLAN 20 interface: dst MAC = 01:00:5E:07:07:07 (same)
→ frame flooded in VLAN 20
Receiver (VLAN 20):
→ receives frame
→ verifies dst MAC and dst IP (239.7.7.7)
→ processes
The router re-encapsulates but uses the same multicast MAC 01:00:5E:07:07:07 on both sides.
Module 4 Summary
| Concept | Key Points |
|---|---|
| Multicast paradigm | One-to-many; source sends 1 packet; network delivers to all receivers |
| vs. Unicast | Unicast = one-to-one; sender sends N packets for N receivers |
| IP multicast range | 224.0.0.0/4 → 224.0.0.0 through 239.255.255.255 |
| Local Control block | 224.0.0.0/24 — not routed; routing protocol hellos |
| Administratively Scoped | 239.0.0.0/8 — private; safe for internal networks |
| LAN multicast MAC | 01:00:5E:xx:xx:xx; lower 23 bits of IP → last 23 bits of MAC |
| MAC identification | Second hex digit from left is odd for all multicast MACs |
| MAC ambiguity | 32 IP addresses share one MAC (5 IP bits discarded) |
| IGMP | Receiver signals next-hop router to join/leave multicast groups |
| IGMPv2 | Joins all traffic for group (no source filtering); default |
| IGMPv3 | Source-specific multicast (SSM); selective source filtering |
| IGMP Snooping | Switch inspects IGMP; limits multicast flooding in the VLAN |
| PIM | Multicast routing protocol; builds multicast distribution tree |
| PIM Dense Mode | Flood and prune (push); Prune/Graft messages; RFC 3973 |
| PIM Sparse Mode | Join and prune (pull); requires RP; RFC 7761 |
| Rendezvous Point (RP) | Central hub for sparse mode; all traffic passes through |
| Sparse-Dense Mode | Dense by default; sparse when RP configured for group |
| RPF Check | Multicast ingress interface must match unicast path to source |
| (*, G) entry | Router is aware of group G (placeholder) |
| (S, G) entry | Router has received traffic from source S for group G |
Quick Reference Tables
Architecture Selection Guide
| Condition | Recommended Architecture |
|---|---|
| Campus network, users accessing servers or Internet | Three-Tier or Two-Tier Collapsed Core |
| Budget-constrained, fixed-size campus | Two-Tier Collapsed Core |
| Data center, intensive server-to-server traffic | Spine and Leaf |
| Maximum bandwidth and no spanning tree | Spine and Leaf (all routed links, ECMP) |
Layer 2 Topology Selection Guide
| Priority | Recommended Topology |
|---|---|
| Maximum performance, zero STP risk, mission-critical | Routed Access |
| All links active, best Cisco practice for campus | Loop-Free V (with FHRP) |
| Need VLAN spanning exactly two access switches | Loop-Free U |
| Need VLANs across many access switches, accept STP | Looped Triangle |
| Port conservation on distribution switches | Looped Square |
PIM Configuration Quick Reference
| Command | Purpose |
|---|---|
ip multicast-routing | Enable IP multicast routing globally |
ip pim sparse-dense-mode | Enable PIM sparse-dense on interface |
ip pim sparse-mode | Enable PIM sparse mode on interface |
ip pim dense-mode | Enable PIM dense mode on interface |
ip pim rp-address <ip> | Statically configure a Rendezvous Point |
show ip mroute | Display the full multicast routing table |
show ip mroute <group> | Show mroute entries for a specific group |
show ip pim neighbor | Show PIM adjacencies |
show ip pim interface | Show PIM-enabled interfaces and DR election status |
mtrace <src> <dst> <group> | Trace multicast path from source to destination |
IGMP Configuration Quick Reference
| Command | Purpose |
|---|---|
ip igmp join-group <group> | Configure interface to join a multicast group |
ip igmp version 3 | Set IGMP version to 3 on interface |
show ip igmp groups | Display IGMP group memberships |
show ip igmp interface | Show IGMP interface state and version |
show ip igmp snooping | Show IGMP snooping status and groups (switch) |
Multicast IP Address Reference
| Address | Protocol/Use |
|---|---|
224.0.0.1 | All systems on this subnet (IGMP query destination) |
224.0.0.2 | All routers on this subnet |
224.0.0.5 | All OSPF routers |
224.0.0.6 | OSPF DR/BDR |
224.0.0.9 | RIPv2 |
224.0.0.10 | EIGRP |
224.0.0.13 | PIM (Hello messages) |
224.0.1.x | IANA-assigned, publicly routable |
239.0.0.0/8 | Administratively scoped (private use) |
OSI Layer Reference for Network Design
| Layer | Name | Key Technologies | Design Implication |
|---|---|---|---|
| 7 | Application | HTTP, SSH, FTP, DNS, SNMP | Identifies what the network must support |
| 4 | Transport | TCP, UDP, port numbers | Reliability requirements; application port needs |
| 3 | Network | IP, OSPF, EIGRP, BGP, PIM | Routing boundaries; IP addressing plan; multicast routing |
| 2 | Data Link | Ethernet, VLANs, STP, 802.1Q, IGMP Snooping | VLAN design; spanning tree risk; multicast control |
| 1 | Physical | Cabling, NICs, transceivers, optical | Physical topology; cable runs; port density; cost |
Physical Architecture vs. Traffic Pattern
flowchart TD
Start["What is the dominant\ntraffic pattern?"]
NS["North-South\n(Client-to-Server)"]
EW["East-West\n(Server-to-Server)"]
Budget{"Budget\nconstrained?"}
ThreeTier["Three-Tier Architecture\n(Core + Distribution + Access)\nBest scalability"]
TwoTier["Two-Tier Collapsed Core\n(Collapsed Core + Access)\nLower cost, less scalable"]
SpineLeaf["Spine and Leaf\n(All routed, ECMP)\nMaximum bandwidth"]
Start --> NS
Start --> EW
NS --> Budget
Budget -->|No / scalability needed| ThreeTier
Budget -->|Yes / fixed size| TwoTier
EW --> SpineLeaf
Layer 2 Topology Decision Tree
flowchart TD
Start["Layer 2 Topology Selection"]
Q1["Is mission-critical\nstability required?"]
Routed["Routed Access Topology\nBest choice for critical networks"]
Q2["Can VLANs be\nlimited to 1 access switch?"]
LoopFreeV["Loop-Free V\nCisco recommended\nuse FHRP for redundancy"]
Q3["Extend VLAN to\nexactly 2 access switches?"]
LoopFreeU["Loop-Free U\nCisco recommended for 2-switch VLANs"]
Q4["Need VLANs across\nmany access switches?"]
Triangle["Looped Triangle\nSTP critical, port-intensive"]
Square["Looped Square\nSTP critical, fewer uplink ports"]
Start --> Q1
Q1 -->|Yes| Routed
Q1 -->|No| Q2
Q2 -->|Yes| LoopFreeV
Q2 -->|No| Q3
Q3 -->|Yes| LoopFreeU
Q3 -->|No| Q4
Q4 -->|Yes, need max switches| Triangle
Q4 -->|Yes, conserve uplinks| Square
Search Terms
cisco · enterprise · networks · design · networking · fundamentals · systems · security · multicast · layer · pim · topology · igmp · loop-free · mac · reference · routing · address · architecture · network · protocol · advantages · core · disadvantages