Switching and Routing: Core Configs and Redundancy

This course covers the core building blocks of enterprise switching and routing: VLANs, 802.1Q trunking, inter-VLAN routing with router-on-a-stick, Layer 2 redundancy through Spanning Tree Protocol (STP) and Link Aggregation Control Protocol (LACP), and dynamic routing with OSPF. Each module combines conceptual explanations with full, hands-on Cisco IOS command-line walkthroughs and verification steps so that the underlying mechanics of each technology are clearly demonstrated end to end.

Table of Contents

• Module 1: VLANs, Trunking, and Inter-VLAN Routing
  • Lab Scenario Overview
  • Configuring VLANs on a Cisco Switch
  • Configuring an 802.1Q Trunk Between Two Switches
  • Configuring Inter-VLAN Routing with Router-on-a-Stick
  • Verifying the Router-on-a-Stick Configuration
  • Verifying VLAN Isolation Without a Router
• Module 2: Layer 2 Redundancy, Spanning Tree Protocol, and Link Aggregation
  • The Problem: Why Redundant Layer 2 Links Cause Loops
  • Solving Loops with Link Aggregation (LACP)
  • Configuring LACP EtherChannel
  • Verifying LACP EtherChannel
  • STP Port States and Root Bridge Election
  • Configuring and Verifying Spanning Tree Protocol
• Module 3: Dynamic Routing with OSPF
  • Distance-Vector vs. Link-State Routing Protocols
  • How Link-State Routing Works
  • OSPF Lab Scenario
  • Configuring IP Addressing on the Routers
  • Configuring OSPF on Cisco IOS Routers
  • Verifying the OSPF Configuration
  • Static vs. Dynamic Routing Protocols
• Summary
• CLI Quick-Reference Cheat Sheet

Module 1: VLANs, Trunking, and Inter-VLAN Routing

Lab Scenario Overview

The goal of this module is to build a small but complete switched/routed topology consisting of one router (Router 1), two switches (Switch 1 and Switch 2), and two end devices (PC1 and PC2). By the end of the module, PC1 and PC2 will live on two different VLANs, and traffic between them will be routed by Router 1 acting as a router-on-a-stick.

flowchart LR
    PC1["PC1<br/>VLAN 10 - Sales"] ---|Access Port Gi0/1| SW2["Switch 2"]
    PC2["PC2<br/>VLAN 20 - Marketing"] ---|Access Port Gi0/2| SW2
    SW2 ===|802.1Q Trunk Gi0/0| SW1["Switch 1"]
    SW1 ===|802.1Q Trunk Gi0/1| R1["Router 1<br/>Router-on-a-Stick"]
    R1 -.->|Fa0/0.1 - VLAN 10 - 10.10.10.1/24| VL10[VLAN 10 Subinterface]
    R1 -.->|Fa0/0.2 - VLAN 20 - 10.20.20.1/24| VL20[VLAN 20 Subinterface]

The design breaks down as follows:

• Switch 2 connects directly to the two end devices. Interface Gi0/1 is configured as an access port on VLAN 10 (Sales), carrying PC1’s traffic, and interface Gi0/2 is configured as an access port on VLAN 20 (Marketing), carrying PC2’s traffic. Tagging the traffic on separate VLANs creates Layer 2 segmentation: broadcast domains for the Sales and Marketing departments are kept isolated from one another.
• Switch 2 to Switch 1 is connected via a trunk port. A trunk link is a mode that allows the traffic of multiple VLANs to travel across a single physical link between two switches, tagging each frame with its VLAN ID as it crosses the link.
• Switch 1 also needs VLAN 10 and VLAN 20 defined locally. Because this course does not cover VLAN Trunking Protocol (VTP) — the protocol that can propagate VLAN definitions automatically from one switch to another — VLANs 10 and 20 are created manually on Switch 1.
• Switch 1 to Router 1 is also a trunk port.
• Router 1 is configured with two subinterfaces on the physical interface connecting to Switch 1: one subinterface tagged for VLAN 10, and one for VLAN 20. When a device on VLAN 10 needs to communicate with a device on VLAN 20, the frame is sent to Router 1, which performs the inter-VLAN routing between the two subnets. This router-on-a-stick pattern allows a single physical router interface (via subinterfaces) to serve as the default gateway for multiple VLANs.

Configuring VLANs on a Cisco Switch

Work begins on Switch 2, where VLAN 10 (Sales) and VLAN 20 (Marketing) are created and then assigned to the access ports connecting to PC1 and PC2.

Switch2> enable
Switch2# show vlan

Before any configuration, all interfaces — including Gi0/1 (connected to PC1) and Gi0/2 (connected to PC2) — belong to the native VLAN, VLAN 1.

Creating the two VLANs:

Switch2# configure terminal
Switch2(config)# vlan 10
Switch2(config-vlan)# name Sales
Switch2(config-vlan)# exit
Switch2(config)# vlan 20
Switch2(config-vlan)# name Marketing
Switch2(config-vlan)# exit

Running show vlan again confirms that VLAN 10 (Sales) and VLAN 20 (Marketing) are both active, but no ports are yet assigned to either of them.

Assigning the access ports — remember that any interface connected directly to an end device must be configured as an access port on the appropriate VLAN:

Switch2(config)# interface gigabitEthernet 0/1
Switch2(config-if)# switchport mode access
Switch2(config-if)# switchport access vlan 10
Switch2(config-if)# exit
Switch2(config)# interface gigabitEthernet 0/2
Switch2(config-if)# switchport mode access
Switch2(config-if)# switchport access vlan 20
Switch2(config-if)# end

Verification:

Switch2# show vlan

Expected output (summarized): Gi0/1 has moved from the native VLAN 1 to VLAN 10 (Sales), and Gi0/2 has moved to VLAN 20 (Marketing).

Switch2# show interfaces gigabitEthernet 0/1 switchport
Switch2# show interfaces gigabitEthernet 0/2 switchport

The switchport keyword on show interfaces reports whether the port is static access or trunk, and both interfaces confirm Operational Mode: static access on their respective VLANs. This completes the VLAN configuration on Switch 2.

Configuring an 802.1Q Trunk Between Two Switches

With the VLANs and access ports in place on Switch 2, the next step is to form the trunk link between Switch 2 and Switch 1 over interface Gi0/0.

Switch2# show vlan
Switch2# configure terminal
Switch2(config)# interface gigabitEthernet 0/0
Switch2(config-if)# switchport mode trunk

By default this shows as an auto negotiation state, meaning the switch will auto-negotiate a trunk encapsulation with its neighbor. The trunk encapsulation is essentially the “language” that the two switches use to tag VLAN traffic across the trunk. The default and open-standard trunk encapsulation is 802.1Q (dot1q), which works across all vendors, not just Cisco. Cisco previously had its own proprietary trunk protocol, ISL (Inter-Switch Link), but ISL is discontinued and should never be used anymore. The encapsulation should therefore be hard-coded explicitly rather than left to negotiate:

Switch2(config-if)# switchport trunk encapsulation dot1q
Switch2(config-if)# switchport mode trunk

Saving the configuration and verifying the trunk on Switch 2:

Switch2(config-if)# end
Switch2# copy running-config startup-config
Switch2# show interfaces gigabitEthernet 0/0 switchport
Switch2# show vlan
Switch2# show interfaces gigabitEthernet 0/0 trunk

show interfaces gigabitEthernet 0/0 switchport confirms both the administrative mode and operational mode are trunk, using dot1q. show vlan confirms that Gi0/0 has been removed from the VLAN 1 listing, since it is now a trunk port carrying multiple VLANs. show interfaces gigabitEthernet 0/0 trunk confirms 802.1Q trunk operation.

The same configuration is then applied on Switch 1, which also needs VLAN 10 and VLAN 20 created locally (since VTP is not being used) and two trunk ports: one facing Switch 2 (Gi0/0) and one facing Router 1 (Gi0/1).

Switch1# configure terminal
Switch1(config)# interface gigabitEthernet 0/0
Switch1(config-if)# no shutdown
Switch1(config-if)# switchport trunk encapsulation dot1q
Switch1(config-if)# switchport mode trunk
Switch1(config-if)# exit
Switch1(config)# interface gigabitEthernet 0/1
Switch1(config-if)# no shutdown
Switch1(config-if)# switchport trunk encapsulation dot1q
Switch1(config-if)# switchport mode trunk
Switch1(config-if)# exit
Switch1(config)# vlan 10
Switch1(config-vlan)# name Sales
Switch1(config-vlan)# exit
Switch1(config)# vlan 20
Switch1(config-vlan)# name Marketing
Switch1(config-vlan)# exit
Switch1(config)# end
Switch1# copy running-config startup-config

Verification on Switch 1:

Switch1# show vlan
Switch1# show interfaces gigabitEthernet 0/0 trunk
Switch1# show interfaces gigabitEthernet 0/1 switchport

show vlan confirms Sales and Marketing are present (with no ports assigned to them yet, since no end devices are directly connected to Switch 1 at this stage). Both Gi0/0 and Gi0/1 confirm as trunk ports. The trunk connection between Switch 1 and Switch 2 is now successfully established.

Configuring Inter-VLAN Routing with Router-on-a-Stick

With VLANs and trunking in place, Router 1 is configured to perform inter-VLAN routing using the router-on-a-stick technique. In this design, if PC1 (VLAN 10) wants to communicate with PC2 (VLAN 20), the traffic is sent to Router 1’s VLAN 10 subinterface. Router 1 consults its routing table, recognizes that the destination belongs to the VLAN 20 network, and routes the packet out its VLAN 20 subinterface — and vice versa for return traffic.

sequenceDiagram
    participant PC1 as PC1 (VLAN 10)
    participant SW as Switches 2 & 1 (Trunk)
    participant R1 as Router 1 (Router-on-a-Stick)
    participant PC2 as PC2 (VLAN 20)
    PC1->>SW: Frame tagged VLAN 10
    SW->>R1: Trunked frame VLAN 10 -> Fa0/0.1
    R1->>R1: Consult routing table<br/>(10.10.10.0/24 -> 10.20.20.0/24)
    R1->>SW: Route out Fa0/0.2, tagged VLAN 20
    SW->>PC2: Frame tagged VLAN 20

Router 1 connects to Switch 1 on interface FastEthernet0/0. The physical interface is first verified and brought up:

Router1# show ip interface brief
Router1# configure terminal
Router1(config)# interface fastEthernet 0/0
Router1(config-if)# no shutdown

Two subinterfaces are then created — one per VLAN — each with its own 802.1Q encapsulation and its own IP address, which will serve as the default gateway for devices on that VLAN:

Router1(config-if)# exit
Router1(config)# interface fastEthernet 0/0.1
Router1(config-subif)# encapsulation dot1Q 10
Router1(config-subif)# ip address 10.10.10.1 255.255.255.0
Router1(config-subif)# exit
Router1(config)# interface fastEthernet 0/0.2
Router1(config-subif)# encapsulation dot1Q 20
Router1(config-subif)# ip address 10.20.20.1 255.255.255.0
Router1(config-subif)# end

Verification:

Router1# show ip interface brief
Router1# show ip route
Router1# show running-config interface fastEthernet 0/0.1
Router1# show running-config interface fastEthernet 0/0.2
Router1# copy running-config startup-config

show ip interface brief confirms that the physical interface FastEthernet0/0 and both subinterfaces (.1 and .2) are up. show ip route shows two directly connected (C) routes — one per VLAN subnet — confirming that Router 1 now knows how to reach both networks. This completes the router-on-a-stick configuration.

Verifying the Router-on-a-Stick Configuration

To validate the whole topology end to end, IP addresses are assigned on PC1 and PC2, and connectivity is tested.

On PC1 (VLAN 10):

PC1> show ip
PC1> ip 10.10.10.2/24 10.10.10.1
PC1> show ip

PC1 receives the address 10.10.10.2/24 with default gateway 10.10.10.1 (Router 1’s VLAN 10 subinterface).

On PC2 (VLAN 20):

PC2> show ip
PC2> ip 10.20.20.2/24 10.20.20.1
PC2> show ip

PC2 receives the address 10.20.20.2/24 with default gateway 10.20.20.1 (Router 1’s VLAN 20 subinterface).

Connectivity is then verified in three progressive steps from PC2:

PC2> ping 10.20.20.1

Expected result: Success. Confirms PC2 can reach its own gateway, meaning the access port, trunk ports, and VLAN tagging are all functioning correctly, since traffic from PC2 is tagged VLAN 20 at Switch 2, trunked to Switch 1, and delivered to the VLAN 20 subinterface.

PC2> ping 10.10.10.1

Expected result: Success. Confirms the router-on-a-stick is routing correctly: PC2 reaches its own gateway (10.20.20.1), and Router 1 routes the request to the VLAN 10 gateway address and returns the reply.

PC2> ping 10.10.10.2

Expected result: Success. Confirms full end-to-end reachability: PC2 (VLAN 20) can now reach PC1 (VLAN 10) through Router 1’s inter-VLAN routing.

Finally, a trace confirms the actual path the traffic takes:

PC2> trace 10.10.10.2

Expected result: The trace first hops to PC2’s default gateway (10.20.20.1), then to the destination 10.10.10.2, confirming that Router 1 performs the routing hop between the two VLANs.

flowchart TD
    A[PC2 pings 10.20.20.1 - own gateway] -->|Success| B[PC2 pings 10.10.10.1 - other VLAN gateway]
    B -->|Success - routed by Router 1| C[PC2 pings 10.10.10.2 - PC1]
    C -->|Success| D[trace confirms hop via gateway 10.20.20.1 then destination]

Verifying VLAN Isolation Without a Router

A second demo reinforces the concept by removing Router 1 from the topology entirely and adding two more end devices directly on Switch 1: PC3 on VLAN 10 and PC4 on VLAN 20. PC1 and PC2 remain connected to Switch 2 as before, and the trunk between Switch 1 and Switch 2 is unchanged.

flowchart LR
    PC1["PC1 - VLAN 10<br/>10.10.10.2/24"] --- SW2["Switch 2"]
    PC2["PC2 - VLAN 20<br/>10.20.20.2/24"] --- SW2
    SW2 ===|802.1Q Trunk| SW1["Switch 1"]
    SW1 --- PC3["PC3 - VLAN 10<br/>10.10.10.3/24"]
    SW1 --- PC4["PC4 - VLAN 20<br/>10.20.20.3/24"]

With this design, if the configuration is correct, PC1 and PC3 (both VLAN 10) should be able to communicate, and PC2 and PC4 (both VLAN 20) should be able to communicate — but devices on different VLANs should not be able to reach each other, since there is no router present to perform inter-VLAN routing.

Configuration on Switch 1:

Switch1# show ip interface brief
Switch1# configure terminal
Switch1(config)# interface gigabitEthernet 0/3
Switch1(config-if)# switchport mode access
Switch1(config-if)# switchport access vlan 10
Switch1(config-if)# exit
Switch1(config)# interface gigabitEthernet 1/0
Switch1(config-if)# switchport mode access
Switch1(config-if)# switchport access vlan 20
Switch1(config-if)# end
Switch1# show vlan
Switch1# copy running-config startup-config

show vlan confirms Gi0/3 and Gi1/0 are now correctly assigned to VLAN 10 and VLAN 20 respectively.

IP addressing on the new PCs (no default gateway is configured, since there is no router in this topology):

PC3> show ip
PC3> ip 10.10.10.3/24
PC3> show ip

PC4> show ip
PC4> ip 10.20.20.3/24
PC4> show ip

Connectivity tests from PC4:

PC4> ping 10.20.20.2

Expected result: Success — PC4 and PC2 are on the same VLAN (20), so they can communicate directly at Layer 2.

PC4> ping 10.10.10.2

Expected result: Failure (“no gateway found”) — PC1 is on a different VLAN (10) and there is no router to perform inter-VLAN routing, and no gateway is even configured.

PC4> ping 10.10.10.3

Expected result: Failure — even though PC3 and PC4 are physically connected to the very same switch (Switch 1), they are on different VLANs, so Layer 2 segmentation still prevents them from communicating. VLAN membership, not physical proximity, determines reachability.

flowchart TD
    A[PC4 - VLAN 20] -->|ping PC2 - VLAN 20| B[Success: same VLAN]
    A -->|ping PC1 - VLAN 10| C[Failure: different VLAN, no gateway]
    A -->|ping PC3 - VLAN 10, same switch| D[Failure: different VLAN, physical proximity irrelevant]

This confirms that VLANs correctly segment the Layer 2 broadcast domains, and that inter-VLAN communication requires a Layer 3 device — such as the router-on-a-stick configured in the previous section — to perform routing between them.

Module 2: Layer 2 Redundancy, Spanning Tree Protocol, and Link Aggregation

The Problem: Why Redundant Layer 2 Links Cause Loops

Redundancy on a switched (Layer 2) network is always recommended, since it prevents a single link failure from isolating parts of the network. However, naively adding redundant physical links between switches introduces serious problems if left unmanaged.

Consider a simple, non-redundant topology: PC1 — Switch 1 — Switch 2 — PC2, connected by a single cable at each hop. Traffic flows in only one path in each direction. If any one of those links fails, communication between PC1 and PC2 stops entirely.

The instinctive fix is to add a second cable between Switch 1 and Switch 2 for redundancy — if one link fails, the other can carry traffic. Unmanaged, however, this creates two serious problems.

Problem 1: Duplicate frames. When PC1 sends a frame to Switch 1, Switch 1 forwards a copy out both redundant links toward Switch 2. Switch 2 then forwards both copies on to PC2, which ends up receiving two copies of the very same frame.

sequenceDiagram
    participant PC1
    participant SW1 as Switch 1
    participant SW2 as Switch 2
    participant PC2
    PC1->>SW1: Frame to PC2
    SW1->>SW2: Copy 1 (Link A)
    SW1->>SW2: Copy 2 (Link B)
    SW2->>PC2: Frame (received via Link A)
    SW2->>PC2: Duplicate frame (received via Link B)
    Note over PC2: PC2 receives two copies<br/>of the same frame

The result is application malfunction and general network instability.

Problem 2: Broadcast storms. Say PC1 wants to communicate with PC2 but does not yet know PC2’s MAC address, so it issues an ARP request, which is a Layer 2 broadcast. Switch 1 floods the broadcast out every port except the one it was received on — meaning out both redundant links toward Switch 2. Switch 2 also floods what it receives out every port except the one it arrived on. Because Switch 2 received the broadcast on both of its uplinks, each copy is re-flooded back out the other uplink toward Switch 1, which repeats the same behavior back toward Switch 2. This cycle never naturally terminates.

flowchart TB
    PC1["PC1 sends ARP broadcast"] --> SW1["Switch 1"]
    SW1 -->|Link A| SW2["Switch 2"]
    SW1 -->|Link B| SW2
    SW2 -->|Re-floods on Link B| SW1
    SW2 -->|Re-floods on Link A| SW1
    SW1 -.->|Loop continues indefinitely| SW1

Unlike Layer 3 packets, Layer 2 frames have no Time-to-Live (TTL) field, so a broadcast storm does not naturally expire — it persists indefinitely, consuming all available bandwidth and driving switch and end-host CPUs to 100% utilization, rendering the network completely non-functional.

The solution to both problems is the Spanning Tree Protocol (STP). STP logically disables one of the redundant links (it is not physically removed — the cable stays connected, but the port stops forwarding traffic). All traffic then flows only through the remaining active (forwarding) link. If the active link later fails, STP detects the failure and re-enables the previously blocked port so that traffic can resume flowing.

flowchart LR
    PC1 --- SW1["Switch 1"]
    SW1 ===|Forwarding link| SW2["Switch 2"]
    SW1 -.->|Blocked link - STP| SW2
    SW2 --- PC2

Solving Loops with Link Aggregation (LACP)

A second solution for a redundant Layer 2 network is link aggregation, sometimes called link bonding. Rather than disabling one of the redundant links as STP does, link aggregation bonds the two physical interfaces between Switch 1 and Switch 2 so that each switch perceives them as a single virtual link instead of two separate physical ports.

flowchart LR
    subgraph Physical["Physical Interfaces"]
        L1["Gi0/0"]
        L2["Gi0/1"]
    end
    SW1["Switch 1"] --> Physical
    Physical --> SW2["Switch 2"]
    Physical -.->|LACP bundles into| PO["Port-Channel 1<br/>(single logical link)"]

The open-standard protocol used for this bundling is LACP (Link Aggregation Control Protocol), which — unlike Cisco’s proprietary alternative — works across all vendors.

With link aggregation in place, both physical links can be used simultaneously: traffic from PC1 can be sent to Switch 1 and then out either the top or bottom physical link, since the Spanning Tree instance on the switches perceives only a single logical link, not two redundant ones. As a result:

• There are no Layer 2 loops, because STP sees only one (aggregated) link rather than two.
• Both physical links are actively used for traffic, rather than one being blocked, so total throughput and effective bandwidth are improved compared to the STP-blocked scenario.

Configuring LACP EtherChannel

The lab scenario for this section connects two switches via two links: Gi0/0 and Gi0/1 on each side. These will be bonded into a single EtherChannel using LACP — also referred to as link bonding or EtherChannel.

Before configuring the channel, both recommendations must be checked: the ports on both sides of each link must use the same speed and the same duplex setting, and if the ports are access ports they must be on the same VLAN on both switches (or, if trunk ports, both sides must be trunk).

Switch1# show interfaces gigabitEthernet 0/0
Switch1# show interfaces gigabitEthernet 0/1
Switch2# show interfaces gigabitEthernet 0/0
Switch2# show interfaces gigabitEthernet 0/1

All four interfaces confirm 1 Gbps bandwidth and full duplex.

Configuration begins on Switch 1:

Switch1# configure terminal
Switch1(config)# interface gigabitEthernet 0/0
Switch1(config-if)# channel-group 1 mode active
Switch1(config-if)# exit
Switch1(config)# interface gigabitEthernet 0/1
Switch1(config-if)# channel-group 1 mode active
Switch1(config-if)# end
Switch1# copy running-config startup-config

Cisco supports three EtherChannel negotiation mechanisms, selected via the mode keyword:

Switch 1 is configured with mode active on both interfaces, meaning it will actively attempt to negotiate the EtherChannel. Until Switch 2 is configured, the channel shows the member port as suspended, since LACP has not yet been enabled on the remote side.

Configuration on Switch 2, using the interface range shortcut and mode passive (it is sufficient for one side to be active and the other passive):

Switch2# configure terminal
Switch2(config)# interface range gigabitEthernet 0/0 - 1
Switch2(config-if-range)# channel-group 1 mode passive
Switch2(config-if-range)# end

It may take a short amount of time for the EtherChannel to fully form on Cisco hardware — this is expected and not a failure. Once formed, the interfaces come up and the EtherChannel becomes operational.

Verifying LACP EtherChannel

Several commands confirm the health and state of the EtherChannel from Switch 1:

Switch1# show etherchannel summary

This shows a Po1 (Port-channel 1) entry flagged S (Layer 2) and U (in use), with protocol LACP, and both member interfaces flagged P (bundled in the port channel).

Switch1# show etherchannel 1 port-channel

This confirms the protocol in use is LACP and that both physical interfaces are active members of the port channel.

Switch1# show interfaces gigabitEthernet 0/0 etherchannel

This reports detailed local and partner information for the bundled interface, including local port and partner port details.

Note: A single EtherChannel/LACP bundle supports a maximum of 8 active physical links bundled together on Cisco switches.

STP Port States and Root Bridge Election

The second mechanism for avoiding Layer 2 loops is Spanning Tree Protocol itself. Consider three switches, all interconnected — Switch 2 can reach a network on Switch 3 either directly, or indirectly via Switch 1, providing redundancy.

By default, Cisco switches run Per-VLAN Spanning Tree (PVST). Every switch sends a BPDU (Bridge Protocol Data Unit) to its neighbors. The most important piece of information carried in a BPDU is the Bridge ID, which consists of a priority value and the switch’s MAC address. All switches compare Bridge IDs: the switch with the lowest priority wins; if priorities are tied (the default is 32768, commonly shown as 32769 with the extended system ID), the switch with the lowest MAC address becomes the root bridge.

Conceptual example (three switches, MAC prefixes represented as AAA, BBB, and CCC for illustration): all three switches share the same default priority, so the tiebreaker is the MAC address. Switch 1 (AAA) has the lowest MAC address of the three, and therefore wins the election, becoming the root bridge.

flowchart TD
    A["Compare Bridge Priority"] -->|Equal priority| B["Compare MAC Address"]
    A -->|Lower priority wins outright| ROOT["Elected Root Bridge"]
    B -->|Lowest MAC address wins| ROOT

Once a root bridge is elected, all of its ports become designated ports — meaning they always forward traffic, since the root bridge is effectively the “king” of the Layer 2 topology and all traffic must ultimately pass through it.

The two non-root switches (Switch 2 and Switch 3 in this example) then determine their own port roles based on cost, which is derived from link bandwidth. On Gigabit links, each hop has a cost of 4. Switch 2 can reach the root bridge (Switch 1) directly at a cost of 4, or indirectly via Switch 3 at a cost of 8 (4 + 4) — so Switch 2 selects its directly connected interface as its root port (the port that is closest, cost-wise, to the root bridge and is always forwarding). Switch 3 does the same on its own directly connected interface.

That leaves the last segment — the link directly between Switch 2 and Switch 3 — where one port must become the blocking port to prevent a loop. This is again resolved via Bridge ID comparison: whichever switch has the lower Bridge ID wins that segment and its port becomes designated; the other switch’s port on that same segment becomes blocking.

Rule: Every network segment must have exactly one designated port. A segment between two non-root switches will therefore always resolve to one designated port and one blocking (or root) port.

If a forwarding link later fails — for example, if Switch 2’s root port goes down — the previously blocked port on the alternate switch (Switch 3, in this example) transitions to forwarding, restoring connectivity. This failover is not instantaneous: the port must progress through the STP port states, a process that can take up to ~50 seconds with classic (802.1D) Spanning Tree.

stateDiagram-v2
    [*] --> Blocking
    Blocking --> Listening: Max age timer expires (~20s)
    Listening --> Learning: ~15s - listens for MAC addresses only
    Learning --> Forwarding: ~15s - learns MAC addresses, still not forwarding
    Forwarding --> [*]: Now forwarding traffic and learning addresses

Configuring and Verifying Spanning Tree Protocol

The hands-on lab uses the same three-switch redundant topology. The plan is to inspect each switch’s Bridge ID, determine which switch will become the root bridge, and predict which ports will end up designated, root, and blocking — before confirming the result on the command line.

Switch1# show spanning-tree | begin Bridge ID
Switch2# show spanning-tree | begin Bridge ID
Switch3# show spanning-tree | begin Bridge ID

Cisco switches always run Spanning Tree by default, and it runs per VLAN (PVST) — meaning that if more than one VLAN exists, each VLAN can have its own independent Spanning Tree instance and topology. In this lab only VLAN 1 is in use.

The collected Bridge IDs are:

All three switches share the same priority (32769), so the election comes down to the MAC address, compared byte by byte in hexadecimal. Comparing the first differing hex digit: Switch 2 (0c93) is lower than both Switch 1 (0cd7) and Switch 3 (0cc7), since in hexadecimal 9 is less than both c and d. Switch 2 is therefore elected the root bridge.

Because Switch 2 is the root bridge, both of its interfaces (Gi0/0 toward Switch 1, and Gi0/2 toward Switch 3) become designated ports. Switch 1 and Switch 3 each calculate the lowest-cost path back to the root: both can reach Switch 2 directly at a cost of 4, versus 8 via the alternate two-hop path, so each selects its directly connected interface as the root port.

For the final segment — directly between Switch 1 and Switch 3 — the Bridge IDs are compared again: Switch 3 (0cc7) is lower than Switch 1 (0cd7), since c is less than d. Switch 3’s interface on that segment therefore becomes designated, and Switch 1’s corresponding interface becomes the blocking (alternate) port.

flowchart TB
    SW2["Switch 2 (Root Bridge)<br/>MAC starts 0c93"]
    SW1["Switch 1<br/>MAC starts 0cd7"]
    SW3["Switch 3<br/>MAC starts 0cc7"]
    SW2 ===|Gi0/0 Designated - Gi0/0 Root Port| SW1
    SW2 ===|Gi0/2 Designated - Gi0/2 Root Port| SW3
    SW1 -.->|Gi0/1 Blocking - Gi0/1 Designated| SW3

Verification confirms this calculation exactly. On Switch 2 (the expected root bridge):

Switch2# show spanning-tree

The Bridge ID matches the Root ID, and the output explicitly states “this bridge is the root.” All of Switch 2’s interfaces show as designated and forwarding.

On Switch 3 (expected non-root, with Gi0/2 as root port and Gi0/1 as designated):

Switch3# show spanning-tree

The output confirms Switch 3 is non-root (it reports the root’s Bridge ID, matching Switch 2), Gi0/2 shows as the root port, and Gi0/1 shows as designated.

On Switch 1 (expected non-root, with Gi0/0 as root port and Gi0/1 as blocking/alternate):

Switch1# show spanning-tree

The output confirms Gi0/0 as the root port (forwarding), and Gi0/1 as the alternate (blocking) port — exactly matching the manual calculation.

Module 3: Dynamic Routing with OSPF

Distance-Vector vs. Link-State Routing Protocols

Routing is the core function of a router: it allows a packet to move from one path — one network — to another. Before configuring OSPF, it is important to understand where it fits among the broader categories of routing protocols.

Routers within a single Autonomous System (AS) — a set of routers under one administrative authority — communicate using an Interior Gateway Protocol (IGP). Communication between two different Autonomous Systems (for example, two separate ISPs) requires the Border Gateway Protocol (BGP), the only protocol classified as an Exterior Gateway Protocol (EGP) and the routing protocol that underpins the global internet.

flowchart LR
    subgraph AS100["Autonomous System 100"]
        R1a["Router A"]
        R1b["Router B"]
        R1c["Router C"]
        R1a --- R1b
        R1b --- R1c
        R1c --- R1a
    end
    subgraph AS200["Autonomous System 200"]
        R2a["Router D"]
        R2b["Router E"]
        R2c["Router F"]
        R2a --- R2b
        R2b --- R2c
        R2c --- R2a
    end
    AS100 <-->|BGP - Exterior Gateway Protocol| AS200

IGPs are further categorized into two families:

How Link-State Routing Works

Since OSPF is a link-state routing protocol, understanding the general link-state mechanism is essential before configuring it. In a link-state network, every router shares a Link-State Advertisement (LSA) with all other routers. Each LSA describes, at minimum, the router’s own links (interfaces) and the state/description of how each is connected to its neighbor. LSAs are flooded to every router within the same area (an area being a defined set of routers that share link-state information with one another).

sequenceDiagram
    participant R1 as Router 1
    participant R2 as Router 2
    participant R3 as Router 3
    R1->>R2: LSA (my links and interfaces)
    R1->>R3: LSA (my links and interfaces)
    R2->>R1: LSA (my links and interfaces)
    R2->>R3: LSA (my links and interfaces)
    R3->>R1: LSA (my links and interfaces)
    R3->>R2: LSA (my links and interfaces)
    Note over R1,R3: Every router assembles an identical<br/>Link-State Database (the "topology table")
    R1->>R1: Run SPF (Dijkstra) algorithm
    R2->>R2: Run SPF (Dijkstra) algorithm
    R3->>R3: Run SPF (Dijkstra) algorithm

As each router collects LSAs from every other router in the area, it assembles a Link-State Database (LSDB), referred to on Cisco routers as the topology table. Since every router collects the exact same set of LSAs, every router ends up with an identical topology table — a full, shared picture of how the entire area is connected, conceptually similar to a map.

From this shared topology table, each router independently runs the Shortest Path First (SPF) algorithm, also known as the Dijkstra algorithm (after its creator), to compute the best (shortest) path to every known destination network. The best path discovered by SPF is installed into the router’s routing table. If an alternate path to the same destination also exists, it is retained in the topology table (not the routing table) as a backup; if the primary route is later lost, SPF re-runs and the alternate path is promoted into the routing table.

OSPF Lab Scenario

The hands-on lab configures OSPF across three routers, all within a single OSPF Area 0 — the mandatory backbone area in OSPF, through which all inter-area traffic must eventually pass in multi-area designs. Within Area 0, all routers exchange LSAs and run SPF to compute reachability to every advertised network.

As a general design guideline, if a single OSPF area grows to more than roughly 80 routers, it is recommended to split the network into multiple areas so that LSA flooding and the link-state database remain manageable per area.

flowchart LR
    subgraph Area0["OSPF Area 0 (Backbone)"]
        R1["Router 1<br/>Router ID 1.1.1.1<br/>Lo0: 1.1.1.1/24"]
        R2["Router 2<br/>Router ID 2.2.2.2"]
        R3["Router 3<br/>Router ID 3.3.3.3<br/>Lo0: 3.3.3.3/24"]
        R1 ---|192.168.12.0/24| R2
        R2 ---|192.168.23.0/24| R3
    end

The addressing plan for the lab:

The two loopback interfaces (1.1.1.1 on Router 1 and 3.3.3.3 on Router 3) represent simulated end-device networks. The goal of the lab is for the 1.1.1.1 network to reach the 3.3.3.3 network — and vice versa — purely through OSPF, with no manual/static routing involved.

Configuring IP Addressing on the Routers

IP addressing is configured first on Router 1:

Router1# configure terminal
Router1(config)# interface fastEthernet 0/0
Router1(config-if)# ip address 192.168.12.1 255.255.255.0
Router1(config-if)# no shutdown
Router1(config-if)# exit
Router1(config)# interface loopback 0
Router1(config-if)# ip address 1.1.1.1 255.255.255.0
Router1(config-if)# end
Router1# show ip interface brief
Router1# copy running-config startup-config

Then Router 2, with two physical interfaces:

Router2# configure terminal
Router2(config)# interface fastEthernet 0/0
Router2(config-if)# ip address 192.168.12.2 255.255.255.0
Router2(config-if)# no shutdown
Router2(config-if)# exit
Router2(config)# interface fastEthernet 0/1
Router2(config-if)# ip address 192.168.23.2 255.255.255.0
Router2(config-if)# no shutdown
Router2(config-if)# end
Router2# show ip interface brief
Router2# copy running-config startup-config

Then Router 3, including its own loopback:

Router3# configure terminal
Router3(config)# interface fastEthernet 0/1
Router3(config-if)# ip address 192.168.23.3 255.255.255.0
Router3(config-if)# no shutdown
Router3(config-if)# exit
Router3(config)# interface loopback 0
Router3(config-if)# ip address 3.3.3.3 255.255.255.0
Router3(config-if)# end
Router3# show ip interface brief
Router3# copy running-config startup-config

Basic IP reachability is confirmed with direct-neighbor pings:

Router3# ping 192.168.23.2
Router2# ping 192.168.12.1

Both succeed (the very first ping may show a dropped packet while ARP resolves, which is expected).

However, pinging between the two loopback networks fails at this point, since no routing protocol has been configured yet and neither router has a route to the other’s loopback network:

Router1# ping 3.3.3.3 source 1.1.1.1

Expected result: Unreachable. Once OSPF is configured in the next step, this same ping will succeed automatically.

Configuring OSPF on Cisco IOS Routers

OSPF is now enabled on all three routers. On Router 1:

Router1# show ip interface brief
Router1# configure terminal
Router1(config)# router ospf 1
Router1(config-router)# router-id 1.1.1.1
Router1(config-router)# network 192.168.12.0 0.0.0.255 area 0
Router1(config-router)# network 1.1.1.0 0.0.0.255 area 0

Several important details apply here:

• The 1 after router ospf is simply a locally significant process ID and has no bearing on adjacency formation with other routers.
• The Router ID identifies the router uniquely within the OSPF process. If not explicitly set, Cisco IOS will default to the highest IP address on any active loopback interface, or, absent a loopback, the highest IP address on any active physical interface. It is best practice to hard-code the Router ID explicitly, as done here (1.1.1.1 on Router 1), so that it is predictable and easy to recognize.
• The network command requires a wildcard mask, not a subnet mask. The wildcard mask is the inverse of the subnet mask — computed by subtracting the subnet mask from 255.255.255.255. For a /24 network (subnet mask 255.255.255.0), the wildcard mask is 0.0.0.255.
• The area 0 keyword places the advertised network into the OSPF backbone area.

The same pattern is applied on Router 2, which advertises both of its connected networks:

Router2# configure terminal
Router2(config)# router ospf 1
Router2(config-router)# router-id 2.2.2.2
Router2(config-router)# network 192.168.12.0 0.0.0.255 area 0
Router2(config-router)# network 192.168.23.0 0.0.0.255 area 0
Router2(config-router)# do copy running-config startup-config

As soon as the 192.168.12.0 network is advertised on Router 2, the OSPF adjacency with Router 1 immediately transitions to Full, confirming successful neighbor formation. The do keyword lets a privileged-exec command (such as copy) be run directly from within a configuration submode, without first exiting back to exec mode.

Finally, Router 3:

Router3# show ip interface brief
Router3# configure terminal
Router3(config)# router ospf 1
Router3(config-router)# router-id 3.3.3.3
Router3(config-router)# network 192.168.23.0 0.0.0.255 area 0
Router3(config-router)# network 3.3.3.0 0.0.0.255 area 0
Router3(config-router)# do copy running-config startup-config

Note that Router 3’s Router ID would in fact default to 3.3.3.3 even without the explicit router-id command, because that is the highest IP address on an active loopback interface — but hard-coding it remains best practice for clarity and predictability.

Advertising 192.168.23.0 on Router 3 forms the OSPF neighbor relationship with Router 2. All three routers are now configured for OSPF, and the configuration is complete — only verification remains.

Verifying the OSPF Configuration

Neighbor adjacency is checked first on each router using the OSPF neighbor table:

Router1# show ip ospf neighbor

Router 1 shows a single neighbor with Router ID 2.2.2.2 (Router 2), confirming the adjacency.

Router1# show ip ospf database

This displays the link-state database (topology table) — the shared set of LSAs from which every router computes its SPF results.

Router2# show ip ospf neighbor

Router 2 shows two neighbors: Router 1 (1.1.1.1) and Router 3 (3.3.3.3), since Router 2 sits in the middle of the topology.

Router2# show ip ospf database

The link-state database on Router 2 is identical to the one seen on Router 1, confirming that all routers in the area share the same topology view.

Router3# show ip ospf neighbor

Router 3 shows a single neighbor, Router 2 (2.2.2.2).

Routing table entries learned via OSPF are then confirmed:

Router1# show ip route ospf

This shows the O (OSPF) flag on the route to 3.3.3.3, with the next hop pointing to Router 2’s address — confirming Router 1 dynamically learned this route via OSPF.

Router1# show ip route

This displays the full routing table, including both connected (C) and OSPF-learned (O) routes.

Router3# show ip route ospf

This confirms that Router 3 has also learned the 1.1.1.1 network via OSPF.

Finally, the earlier failed ping between loopbacks is retried:

Router1# ping 3.3.3.3 source 1.1.1.1

Expected result: Success — the ping from 1.1.1.1 now reaches 3.3.3.3.

Router3# ping 1.1.1.1 source 3.3.3.3

Expected result: Success — confirming full, bidirectional, dynamically routed reachability between the two loopback networks, achieved entirely through OSPF with no manual/static routing configuration.

flowchart TD
    A["Router 1 pings 3.3.3.3 (source 1.1.1.1) - BEFORE OSPF"] -->|Fails: no route| B["Configure OSPF on R1, R2, R3"]
    B --> C["OSPF adjacencies form: R1-R2 Full, R2-R3 Full"]
    C --> D["show ip route ospf confirms learned routes"]
    D --> E["Router 1 pings 3.3.3.3 (source 1.1.1.1) - AFTER OSPF"]
    E -->|Succeeds| F["Router 3 pings 1.1.1.1 (source 3.3.3.3) - Succeeds"]

Static vs. Dynamic Routing Protocols

Everything covered so far in this module relates to dynamic routing via OSPF, but routes can also be configured statically — manually, by the administrator — rather than being discovered automatically by a routing protocol.

Consider a simple topology of three routers, where LAN A (connected to Router 1) needs to reach LAN B (connected to Router 3). Router 1 could send traffic to LAN B either via Router 2 or via Router 3 directly. If the administrator chooses to route via Router 3, a static route must be manually configured on Router 1 pointing toward Router 3 for the LAN B destination. But that alone is not enough — LAN B must also be able to respond back to LAN A, which requires a corresponding static route on Router 3 pointing back toward Router 1 (or via Router 2, in which case Router 2 also needs its own static route). Every router along every possible path — in both directions — needs its own manually configured static route.

This complexity multiplies quickly as the network grows. Consider a larger example: LAN A and LAN B are now separated by five routers, connected as Router 1 — Router 3 — Router 5 (one path) or Router 1 — Router 2 — Router 4 — Router 3 — Router 5 (an alternate path). Just for the shorter three-hop path, four static routes are required (two in each direction, at Router 1/Router 3 and Router 3/Router 5). For the longer four-hop path, the count increases similarly, hop by hop, in both directions.

flowchart LR
    LANA["LAN A"] --- R1["Router 1"]
    R1 --- R2["Router 2"]
    R1 --- R3["Router 3"]
    R2 --- R4["Router 4"]
    R3 --- R5["Router 5"]
    R4 --- R5
    R5 --- LANB["LAN B"]

Even in this modest topology, the number of static routes required — one per hop, in each direction, for every possible path — becomes significant. Since administrators are human and prone to mistakes, an incorrectly configured static route (a wrong next-hop, a typo, or a forgotten return path) breaks connectivity. This is precisely the class of problem that dynamic routing protocols such as OSPF are designed to solve: routers discover routes and next hops automatically, and automatically discover an alternate/failover path if the primary one is lost, all without manual intervention.

As a network grows in size and in the number of routers, the amount of manual static-routing work required grows dramatically, while dynamic routing protocols like OSPF continue to scale simply by advertising new networks — making dynamic routing the clearly preferred approach for anything beyond the smallest topologies.

Summary

This course walked through the essential building blocks of a resilient, well-architected enterprise switching and routing environment:

• VLANs and trunking segment a Layer 2 network into isolated broadcast domains. Access ports carry traffic for a single VLAN to end devices, while 802.1Q trunk ports carry tagged traffic for multiple VLANs between switches. Because VTP was intentionally left out of scope, VLANs must be created manually and consistently on every switch that needs them.
• Router-on-a-stick allows a single physical router interface, divided into per-VLAN subinterfaces, to provide inter-VLAN routing between segmented networks — without router-on-a-stick (or another Layer 3 device), devices on different VLANs simply cannot reach each other, regardless of physical proximity.
• Layer 2 redundancy without protection creates duplicate frames and unbounded broadcast storms, since Ethernet frames have no TTL. Spanning Tree Protocol resolves this by electing a root bridge (via the lowest Bridge ID: priority, then MAC address) and logically blocking redundant ports, at the cost of unused bandwidth and a multi-second (up to ~50s) failover. LACP link aggregation instead bundles redundant physical links into a single logical link, eliminating the loop risk entirely while keeping all bundled links actively in use.
• OSPF, a link-state IGP, builds a shared, identical link-state database (topology table) across all routers in an area by flooding LSAs, then independently computes best paths with the SPF (Dijkstra) algorithm. This stands in contrast to distance-vector protocols like RIP, which exchange full periodic routing-table updates and lack full topology visibility.
• Dynamic routing (OSPF) versus static routing: static routes require manual, per-hop, per-direction configuration that becomes unmanageable and error-prone as a network grows, whereas dynamic routing protocols automatically discover routes and failover paths, scaling cleanly to large, evolving networks.

Together, these technologies form the foundation of a scalable, redundant, and correctly segmented enterprise network core.

CLI Quick-Reference Cheat Sheet

VLANs and access ports

vlan 10
 name Sales
interface gigabitEthernet 0/1
 switchport mode access
 switchport access vlan 10
show vlan
show interfaces gigabitEthernet 0/1 switchport

802.1Q trunking

interface gigabitEthernet 0/0
 switchport trunk encapsulation dot1q
 switchport mode trunk
show interfaces gigabitEthernet 0/0 trunk
show interfaces gigabitEthernet 0/0 switchport

Router-on-a-stick (inter-VLAN routing)

interface fastEthernet 0/0
 no shutdown
interface fastEthernet 0/0.1
 encapsulation dot1Q 10
 ip address 10.10.10.1 255.255.255.0
interface fastEthernet 0/0.2
 encapsulation dot1Q 20
 ip address 10.20.20.1 255.255.255.0
show ip interface brief
show ip route

LACP EtherChannel

interface gigabitEthernet 0/0
 channel-group 1 mode active
interface gigabitEthernet 0/1
 channel-group 1 mode active
! remote side: channel-group 1 mode passive
show etherchannel summary
show etherchannel 1 port-channel
show interfaces gigabitEthernet 0/0 etherchannel

Spanning Tree Protocol

show spanning-tree | begin Bridge ID
show spanning-tree

Look for: Bridge ID (priority + MAC), This bridge is the root, port roles (Root, Designated, Alternate/blocking), and port state (Forwarding).

OSPF

router ospf 1
 router-id 1.1.1.1
 network 192.168.12.0 0.0.0.255 area 0
 network 1.1.1.0 0.0.0.255 area 0
show ip ospf neighbor
show ip ospf database
show ip route ospf
ping 3.3.3.3 source 1.1.1.1

General verification and persistence

show ip interface brief
copy running-config startup-config

Search Terms

switching · routing · core · configs · redundancy · networking · fundamentals · systems · security · configuring · verifying · ospf · lacp · aggregation · cisco · configuration · dynamic · etherchannel · inter-vlan · layer · link · link-state · loops · protocol