Lesson 3 — Physical Interfaces & Cabling
Week 1 outline
- Week 1 overview
- Lesson 1What Is a Network?
- Lesson 2How Two Devices Actually Communicate
- QuizNetwork Foundations & Traffic Flow
- Lesson 3Physical Interfaces & Cabling (current step)
- Lesson 4Ethernet, MAC Addresses & ARP
- QuizLocal Delivery: Cabling, Ethernet & ARP
- LabARP & ICMP on the LAN
- Lesson 5TCP vs UDP
- Lesson 6IPv4 Addresses & Private Ranges
- CheckpointWeek 1 Checkpoint
Physical Interfaces & Cabling
Choose the right cable and media for a connection, read an interface's two-part status line, and isolate the physical-layer faults behind a dead or degraded link.
Lesson orientation
What you'll learn (5 objectives)~8 min: video → lesson → check → apply → lab prep
Learning objectives
- Select copper or fiber, and straight-through or crossover, for a given connection
- Explain what Auto-MDIX changes about the classic cable rules
- Describe console access as out-of-band management, independent of network configuration
- Interpret the two-part interface status shown by show ip interface brief
- Diagnose the common Layer 1 and interface faults — wrong cable, admin-down, duplex mismatch
Terms you will see
Time breakdown
- Read the notes6 min
- Pause and predict2 min
Assigned video

Free CCNA | Interfaces and Cables | Day 2 | CCNA 200-301 Complete Course
By Jeremy's IT Lab · Opens externally on YouTube
Watch time not yet confirmed for this video — the notes below cover everything this lesson requires.
The link opens in a new browser tab. Return here when you finish watching.
Watch for these concepts
- What the inside of a twisted-pair cable actually looks like
- The difference between the two fiber types and when each is used
- Which cable goes between which pair of devices
- How an interface reports its own status
Go beyond the video
The assigned video introduces the idea. CCNA Practice Labs completes the learning path: clarify core concepts, explore how each device behaves, visualize the communication path, check your understanding, and prepare for hands-on lab work.
Watch the concept → understand it → visualize it → practice it → apply it.
Why this layer is worth your attention
Lesson 2 gave you a checking order for faults and told you to start at Layer 1. This is that layer. A large share of real network outages are physical — a cable in the wrong port, a port that was never switched on, an optic that does not match the fiber. They are also the fastest faults to confirm or rule out, which is exactly why they come first.
Copper and fiber
Copper cabling in an office is almost always UTP — unshielded twisted pair — terminated in the familiar RJ-45 plug. It is cheap and easy to work with, and it has two limits worth memorising: a single run tops out at 100 metres, and because it carries electricity it is vulnerable to electromagnetic interference, the electrical noise thrown off by motors, fluorescent lighting, and power cabling.
Fiber sends pulses of light down a glass core instead. Light does not care about electrical noise, and it travels much further before it degrades. Two kinds matter for CCNA. Multimode fiber has a wider core, is cheaper to drive, and covers hundreds of metres — the usual choice inside a campus or data centre. Single-mode fiber has a very narrow core, costs more, and reaches many kilometres — the choice for long building-to-building runs and WAN links.
Which cable goes where
A straight-through cable connects pin 1 at one end to pin 1 at the other. A crossover cable deliberately swaps the transmit and receive pairs. The classic rule is about what sits at each end: unlike devices take a straight-through, like devices take a crossover.
| Connection | Classic cable | With Auto-MDIX | Why |
|---|---|---|---|
| PC ↔ Switch | Straight-through | Straight-through | Unlike devices |
| Switch ↔ Router | Straight-through | Straight-through | Unlike devices |
| Switch ↔ Switch | Crossover | Straight-through works | Like devices |
| PC ↔ PC | Crossover | Straight-through works | Like devices |
| Anything ↔ device console port | Rollover | Rollover | Out-of-band management |
| Run longer than 100 m | — | Single-mode fiber | Beyond copper's distance limit |
Console access is different
Every other connection in this lesson carries network traffic. The console port does not. It is a dedicated management port that you reach with a rollover cable or a USB cable, and it works even when the device has no IP address, no working configuration, and no network at all. That property is what out-of-band means: the management path does not depend on the thing you are managing.
The default console settings are worth committing to memory, because you will be asked for them: 9600 baud, 8 data bits, no parity, 1 stop bit — written 9600 8-N-1 — with no flow control. This is how you talk to a switch fresh out of its box.
Reading the two-part interface status
When you want to know whether an interface is working, one command answers it. The output shows two separate status columns, and they mean different things: the first is the physical link, the second is the protocol running over it. Layer 1, then Layer 2.
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/1 10.1.1.1 YES manual up up
GigabitEthernet0/2 unassigned YES unset administratively down down
GigabitEthernet0/3 10.1.2.1 YES manual up down| Status / Protocol | Meaning | What to do |
|---|---|---|
| up / up | Healthy — link and Layer 2 are both good | Nothing; look elsewhere for the fault |
| administratively down / down | The port was never switched on | Enable it with no shutdown |
| down / down | A Layer 1 problem — unplugged or faulty cable, wrong media, or the far end is off | Check the cable and the device at the other end |
| up / down | The physical link is fine but Layer 2 is not — for example a mismatched setting on a serial or WAN link | Compare the Layer 2 configuration on both ends |
When a link is up but still broken
Duplex describes whether an interface can send and receive at the same time. Full duplex can; half duplex must take turns, which is why the old shared-Ethernet world had collisions at all. Modern switched links run full duplex, and both ends have to agree — if one end is full and the other is half, the link still comes up, traffic still passes, and the connection is quietly broken.
The symptom is a slow link rather than a dead one, along with rising late collisions. A late collision is one detected after the point where a collision should ever be possible, which is the fingerprint of exactly this mismatch: the full-duplex side sends whenever it likes, and the half-duplex side sees that as a collision arriving too late to be normal. The fix is to make both ends match — either set speed and duplex explicitly at both ends, or let both autonegotiate.
What you should retain
- UTP copper: RJ-45, 100 m maximum, vulnerable to electrical interference.
- Fiber: multimode for campus distances, single-mode for kilometres; both immune to electrical noise.
- Straight-through for unlike devices, crossover for like devices — Auto-MDIX usually hides the difference.
- Console access is out-of-band: rollover or USB, 9600 8-N-1, works with no network at all.
- Status pairs: up/up healthy · administratively down needs no shutdown · down/down is Layer 1 · up/down is Layer 2.
- A duplex mismatch leaves the link up but slow, with late collisions. Match both ends.
Before you read on
Two switches are cabled correctly. Both interfaces show up/up. But the link is slow, and the interface counters show late collisions climbing. What is the likely cause — and why does the link still appear healthy?
Section quiz follows Lesson 4. It covers Lessons 3 and 4 together and gates the ARP & ICMP lab — a Week 1 milestone tracked separately from this lesson.
Study deeper
Topic guides extend this lesson — they do not replace the first-party walkthrough above.
Network Devices & Cabling
For the full copper and fiber interface reference — connector types, distance limits, and transceiver detail beyond the selection table above
