Intermediate

Cisco Enterprise Networks - Design

Prerequisites: CCNA-level networking skills, including familiarity with routing protocols (OSPF, EIGRP, BGP basics), switching, VLANs, and subnetting.

Table of Contents


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:

  1. Physical network designs and traffic patterns — how topology choices affect throughput, reliability, and cost.
  2. Layer 2 topologies — how VLAN scope and routing placement affect stability and performance.
  3. 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 devicesSets the upper limit on network scale
Traffic patterns (path bits physically take)Affects throughput, reliability, stability
Maximum throughputBandwidth ceiling for the entire network
Reliability and stabilityRedundancy paths and failure domains
Minimum cost floorPhysical infrastructure is the biggest capital expense
Flexibility for future logical changesA 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:

PatternAlso CalledTypical LocationDescription
Client-to-ServerNorth-SouthCampus networksUsers (North) accessing resources in a data center or Internet (South)
Server-to-ServerEast-WestData center networksServers 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 ScaleArchitecture
Small campus1 core + 1 distribution block
Medium campus1 core + 2–4 distribution blocks
Large campus2+ 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

AdvantageDetail
Lower costFewer switches to purchase and manage
Simpler managementFewer devices, fewer configurations
Good for stable networksWhen network size is fixed

Disadvantages

DisadvantageDetail
Poor scalabilityGrowth requires more core switches or migration to three-tier
No modularityNo replicable access-distribution blocks
No isolation layerNo buffer between access layer and core
VLAN traverses coreExtending VLANs requires them to traverse the core; misconfiguration can cascade
Change control riskEven 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

FeatureSpine and LeafTwo-Tier Collapsed Core
Top switches connected?No — spine switches are NOT interconnectedYes — core switches are connected
Inter-switch linksAll routed — no STP, no VLAN trunksMay include Layer 2 trunks
Server redundancyDual-connected to 2 leaf switchesVariable
Hop count between any two serversAlways equal (2 hops: leaf → spine → leaf)Variable
Traffic type optimized forEast-WestNorth-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

AspectDetail
Massive bandwidthECMP across all spine-leaf links
High reliabilityMultiple equal paths, no single point of failure
Predictable latencyAlways 2 hops between any two servers
No spanning treeAll inter-switch links are routed
CostExpensive; every leaf connects to every spine
Scalability ceilingEach new leaf needs a port on every spine; each new spine needs a port on every leaf — links grow exponentially

Module 2 Summary

ArchitectureBest ForKey AdvantageKey Disadvantage
Three-TierCampus, North-South trafficScalable, modular, VLAN isolationExpensive (core switches)
Two-Tier Collapsed CoreSmall/stable, budget-constrainedLower cost, simplerPoor scalability, core VLAN risk
Spine and LeafData center, East-West trafficMaximum bandwidth, ECMP, no STPExpensive, exponential link growth

Key takeaways:

  1. Always start with the physical design — it constrains everything else.
  2. Networking is inter-process communication. Understand how applications use the network before designing it.
  3. Select the physical architecture based on the expected traffic pattern.
  4. Layer 1 and Layer 2 are tightly coupled — physical changes affect Layer 2 topology.
  5. 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:

  1. 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?
  2. 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
FeatureSwitched InterfaceRouted Interface
IP addressNot directly (use SVI)Assigned directly
VLAN membershipYes (access or trunk)No
Spanning TreeYesNo
Frame forwardingYes (floods unknown unicast)No (discards non-self MACs)
Bridging loops possible?YesNo
Use caseEnd-device connectivity, VLAN extensionInter-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.

TypeDescriptionSpanning Tree Role
LoopedRedundant Layer 2 links; STP prevents bridging loopsCritical — must prevent loops
Loop-freeNo redundant Layer 2 links; bridging loops cannot occurFail-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.

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

TopologyVLAN Spans Multiple Switches?STP RoleFHRP Needed?Bandwidth Efficiency
Loop-Free VNo (1 VLAN per access switch)Fail-safe onlyYesHigh — all links active
Loop-Free UYes (max 2 switches)Fail-safe onlyYesMedium — horizontal traffic
Loop-Free Inverted UYes (max 2 switches)Fail-safe onlyYesMedium — 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

FeatureRouted AccessSwitched Topologies
Convergence speedFast (routing protocols)Slower (STP re-convergence)
Load balancingECMP across all routed linksSTP blocks some links
Bandwidth efficiencyAll links activeSome links blocked
Bridging loop riskNone (no L2 links)STP required
ScalabilityHighLimited by VLAN size
StabilityHighSTP instability risk
Configuration effortMore (routing on each access switch)Less
Hardware costRequires L3 access switches (more expensive)L2 switches cheaper
VLAN spans multiple access switchesNoYes

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:

  1. Where to do IP routing — pushing routing toward the edge improves performance and stability but adds cost and configuration complexity.
  2. How large to make subnets — larger VLANs spanning many switches are convenient but create spanning tree risk and scale poorly.

Full topology comparison:

TopologyRouting LocationVLAN ScopeSTP CriticalityFHRP NeededBandwidthBest Use Case
Looped TriangleDistribution + CoreMulti-switchCriticalNoSTP blocks someConvenient multi-VLAN extension
Looped SquareDistribution + CoreMulti-switchCriticalNoSTP blocks horizontalLarger VLAN extension
Loop-Free VDistribution + CoreSingle switchFail-safeYesAll links activeCisco recommended loop-free
Loop-Free UDistribution + CoreTwo switchesFail-safeYesHorizontal trafficTwo-switch VLAN extension
Routed AccessAccess + Distribution + CoreSingle switchFail-safeNoAll links activeMission-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:

MethodPackets Sent/Second by SourceNetwork Load
Unicast1,000 (one per receiver, each unique dst IP)High — repeated copies on every shared link
Multicast1 (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)

BlockRangeDescriptionRouted?
Local Network Control224.0.0.0/24Link-local; routing protocol addressesNo — stays in broadcast domain
Internet Control224.0.1.0/24IANA-assigned; publicly routableYes
Administratively Scoped239.0.0.0/8Private use (multicast RFC 1918 equivalent)No — not publicly routable

Common Local Network Control Addresses

AddressProtocol/Purpose
224.0.0.1All systems on this subnet (IGMP query destination)
224.0.0.2All routers on this subnet
224.0.0.5All OSPF routers
224.0.0.6OSPF designated routers
224.0.0.9RIPv2
224.0.0.10EIGRP
224.0.0.13PIM 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:5E for 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 AddressSecond DigitValueType
00:1A:2B:3C:4D:5EA10 (even)Unicast
0A:00:00:00:00:00A10 (even)Unicast
01:00:5E:07:07:0711 (odd)Multicast
07:00:00:00:00:0077 (odd)Multicast
0B:00:00:00:00:00B11 (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.1 and 225.1.1.1 both map to 01: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 MessageSent ByDestinationPurpose
Membership QueryRouter224.0.0.1Who wants multicast? (every 60 seconds)
Membership ReportHostMulticast group addressJoin a multicast group
Leave GroupHost224.0.0.2Leave a multicast group

IGMP Versions

VersionSource FilteringDefault?Notes
IGMPv2No — receives all traffic for the groupYes (most systems)Most widely deployed
IGMPv3Yes — requests traffic from specific sourcesLess commonSource-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.13 using 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"]
MessageDirectionMeaning
PruneDownstream → Upstream”Stop sending group traffic to me”
GraftDownstream → 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.

ModeBehaviorRP RequiredRFC
DenseFlood + Prune (push)No3973
SparseJoin + Prune (pull)Yes7761
Sparse-DenseDense by default; sparse if RP configuredOptional

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 FormatNameCreated When
(*, G)Star-comma-GRouter receives a packet for group G, receives an IGMP membership report, or receives a PIM Join/Graft for group G
(S, G)S-comma-GRouter 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

LayerTechnologyFunction
Layer 2Ethernet multicastFrames to multicast MAC; flooded within broadcast domain
Layer 3IP multicastPackets to multicast IP; routed between subnets
TogetherIP over EthernetIP 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

ConceptKey Points
Multicast paradigmOne-to-many; source sends 1 packet; network delivers to all receivers
vs. UnicastUnicast = one-to-one; sender sends N packets for N receivers
IP multicast range224.0.0.0/4224.0.0.0 through 239.255.255.255
Local Control block224.0.0.0/24 — not routed; routing protocol hellos
Administratively Scoped239.0.0.0/8 — private; safe for internal networks
LAN multicast MAC01:00:5E:xx:xx:xx; lower 23 bits of IP → last 23 bits of MAC
MAC identificationSecond hex digit from left is odd for all multicast MACs
MAC ambiguity32 IP addresses share one MAC (5 IP bits discarded)
IGMPReceiver signals next-hop router to join/leave multicast groups
IGMPv2Joins all traffic for group (no source filtering); default
IGMPv3Source-specific multicast (SSM); selective source filtering
IGMP SnoopingSwitch inspects IGMP; limits multicast flooding in the VLAN
PIMMulticast routing protocol; builds multicast distribution tree
PIM Dense ModeFlood and prune (push); Prune/Graft messages; RFC 3973
PIM Sparse ModeJoin and prune (pull); requires RP; RFC 7761
Rendezvous Point (RP)Central hub for sparse mode; all traffic passes through
Sparse-Dense ModeDense by default; sparse when RP configured for group
RPF CheckMulticast ingress interface must match unicast path to source
(*, G) entryRouter is aware of group G (placeholder)
(S, G) entryRouter has received traffic from source S for group G

Quick Reference Tables

Architecture Selection Guide

ConditionRecommended Architecture
Campus network, users accessing servers or InternetThree-Tier or Two-Tier Collapsed Core
Budget-constrained, fixed-size campusTwo-Tier Collapsed Core
Data center, intensive server-to-server trafficSpine and Leaf
Maximum bandwidth and no spanning treeSpine and Leaf (all routed links, ECMP)

Layer 2 Topology Selection Guide

PriorityRecommended Topology
Maximum performance, zero STP risk, mission-criticalRouted Access
All links active, best Cisco practice for campusLoop-Free V (with FHRP)
Need VLAN spanning exactly two access switchesLoop-Free U
Need VLANs across many access switches, accept STPLooped Triangle
Port conservation on distribution switchesLooped Square

PIM Configuration Quick Reference

CommandPurpose
ip multicast-routingEnable IP multicast routing globally
ip pim sparse-dense-modeEnable PIM sparse-dense on interface
ip pim sparse-modeEnable PIM sparse mode on interface
ip pim dense-modeEnable PIM dense mode on interface
ip pim rp-address <ip>Statically configure a Rendezvous Point
show ip mrouteDisplay the full multicast routing table
show ip mroute <group>Show mroute entries for a specific group
show ip pim neighborShow PIM adjacencies
show ip pim interfaceShow PIM-enabled interfaces and DR election status
mtrace <src> <dst> <group>Trace multicast path from source to destination

IGMP Configuration Quick Reference

CommandPurpose
ip igmp join-group <group>Configure interface to join a multicast group
ip igmp version 3Set IGMP version to 3 on interface
show ip igmp groupsDisplay IGMP group memberships
show ip igmp interfaceShow IGMP interface state and version
show ip igmp snoopingShow IGMP snooping status and groups (switch)

Multicast IP Address Reference

AddressProtocol/Use
224.0.0.1All systems on this subnet (IGMP query destination)
224.0.0.2All routers on this subnet
224.0.0.5All OSPF routers
224.0.0.6OSPF DR/BDR
224.0.0.9RIPv2
224.0.0.10EIGRP
224.0.0.13PIM (Hello messages)
224.0.1.xIANA-assigned, publicly routable
239.0.0.0/8Administratively scoped (private use)

OSI Layer Reference for Network Design

LayerNameKey TechnologiesDesign Implication
7ApplicationHTTP, SSH, FTP, DNS, SNMPIdentifies what the network must support
4TransportTCP, UDP, port numbersReliability requirements; application port needs
3NetworkIP, OSPF, EIGRP, BGP, PIMRouting boundaries; IP addressing plan; multicast routing
2Data LinkEthernet, VLANs, STP, 802.1Q, IGMP SnoopingVLAN design; spanning tree risk; multicast control
1PhysicalCabling, NICs, transceivers, opticalPhysical 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

Interested in this course?

Contact us to book it or get a custom training plan for your team.