Physical vs. logical diagrams, topologies, data flow — and the Cisco structured process for tracking down what broke.
A physical network diagram shows the actual physical arrangement of the components that make up the network, including cables and hardware. It typically gives a bird's-eye view of the network in its physical space — like a floorplan.
| Aspect | Detail |
|---|---|
| Shows | Actual physical arrangement of devices, cables, and hardware |
| Perspective | Bird's-eye view of the network's physical space — like a floorplan |
| Objective 6a | Given a scenario, develop a Network Physical Diagram (≤2 instructor assists) |
Physical topology refers to the physical interconnection of network devices. A physical diagram will reflect one of these arrangements (or a hybrid of them).
| Topology | Description | Trade-offs |
|---|---|---|
| Bus | All nodes connect to a central medium (the "bus") that has exactly two endpoints | Easy to configure, less cable needed; if the bus fails, the whole network fails and the problem is hard to isolate |
| Star | Central hub or switch through which all data passes; peripheral nodes connect to that central node | Reliable — one machine crashing doesn't affect the rest; but if the hub/switch fails, no connected node can communicate. Cable costs run higher |
| Full Mesh | Each node is directly connected to every other node | Maximum redundancy of direct links |
| Partial Mesh | Nodes are connected only to the nodes they interact with most | Less cabling than full mesh |
| Tree | Combines bus + star: groups of star-configured workstations ("segments") connect to a linear bus/backbone | A main trunk with multiple branches, like a tree |
| Hybrid | Any combination of topologies that isn't simply a bus-and-star (tree) combo | Most real-world networks are hybrids |
Physical diagrams can also capture cabling type/distance, port assignments, and connector types — details that matter when installing or troubleshooting the physical layer.
| Item | Detail |
|---|---|
| Cable choice | Twisted pair (e.g. CAT5e, CAT6) or fiber optic (single-mode or multimode) |
| CAT5e max distance | 100 meters (328 feet) between devices before signal degradation |
| Standards | TIA standards ensure the proper cable type and distance are used (see Unit 12, Cable Management) |
| Item | Detail |
|---|---|
| Ports | Physical ports on network devices where cables plug in — not the same as the virtual ports covered in Unit 5. Diagrams may label port numbers |
| RJ45 | Common connector type used in networks |
| RS232 | Another connector type used in networks |
| Fiber optic connectors | Several different connector types exist; covered under TIA standards |
A logical network diagram describes the way information flows through a network. It typically shows subnets (including VLAN IDs, masks, and addresses), network devices like routers and firewalls, and routing protocols.
| Aspect | Detail |
|---|---|
| Shows | Subnets (VLAN IDs, masks, addresses), routers/firewalls, routing protocols |
| OSI correlation | Correlates with Layer 3 (Network layer) info — packet forwarding through intermediate routers |
| Compare | Layer 2 shows data links between adjacent nodes; Layer 1 shows the purely physical layout/topology |
| IP addressing | IP addresses and subnets are laid out in logical diagrams — useful for configuring devices and for looking up addresses while troubleshooting. Addresses are typically written in CIDR notation |
| Objective 6b | Given a scenario, develop a Network Logical Diagram (≤2 instructor assists) |
Logical topology is how information is actually passed through the network — it's bound to network protocols, as opposed to physical topology, which is just the physical layout. The logical and physical topology of a network may resemble each other, or be entirely different: a twisted-pair Ethernet network is physically a star but follows the bus topology logically. The logical bus is the most common logical topology for wired networks — a sending device broadcasts to the entire network, and other devices check whether the data is addressed to them.
Ethernet is the best-known example of a logical bus topology and is associated with physical bus, star, and tree topologies. Ethernet is contention-based — devices contend (compete) for the right to transmit. All systems listen to the cable, waiting for an opportunity to gain access; if more than one device transmits at once, a collision occurs and both devices wait a random amount of time before retransmitting. This access method is Carrier Sense Multiple Access with Collision Detection (CSMA/CD).
| Letters | Meaning |
|---|---|
| CS | Carrier Sense — all devices listen to the line before transmitting |
| MA | Multiple Access — multiple devices can access the network |
| CD | Collision Detection — rules for managing data collisions (defined in IEEE 802.3) |
| OSI origin | Originates at the Data Link layer, implemented at the Physical layer |
Data flow diagrams (DFDs) are a network representation of a system and the cornerstone of structured systems analysis and design. They use just four symbols to represent a system at any level of detail.
| Symbol | Represents |
|---|---|
| Data flows | Movement of data in the system |
| Data stores | Data repositories for data that is not moving |
| Processes | Transforms of incoming data flow(s) to outgoing data flow(s) |
| External entities | Sources or destinations outside the specified system boundary |
| Not Shown | Why |
|---|---|
| Decisions / control | DFDs present all possible paths — which path is actually selected is not shown |
| Timing of events | There's no start/stop point or timing — the data path simply exists because it will be needed, like a road on a map |
| Repetition | How many times or when a procedure runs is not included |
| Volumes / frequency | Not represented at any level of the diagram |
A DFD is analogous to a road map — a network model of all possibilities, with different levels of detail shown at different hierarchical levels. Representing different levels of detail is called leveling (or partitioning): a state road map can be drilled into a city, then into a single street network, without becoming unusable.
| Objective 6c | Given a scenario, develop a Network Data Flow Diagram (≤2 instructor assists) |
Troubleshooting is a methodical process that resolves a problem in the most efficient manner. Often the person solving an issue isn't the person who discovered it, so a structured, repeatable process matters. This same process applies whether you're troubleshooting a switch or a router.
| Step | What Happens |
|---|---|
| 1. Define Problem | Know the specific problem. "The internet is out" isn't descriptive enough — "this one PC can't get online" is a starting point |
| 2. Gather Information | Collect info from multiple sources — starting with the person who reported it, then "show" commands, ping requests, and telnet attempts |
| 3. Analyze Information | Look at everything gathered — even data that doesn't seem useful yet, since you can't be sure until the process is over |
| 4. Eliminate Possible Causes | Rule out what can't be the problem — e.g., if only a few users are affected, it can't be a cause common to all users |
| 5. Propose Hypothesis | Use experience and knowledge to propose the most likely cause |
| 6. Test Hypothesis | Testing validates (or disproves) the hypothesis |
| 7. Implement and Document | Make the corrections and document the work |
There are several ways to work through isolating a problem across the OSI model. (Note: in the study guide's illustration, the Presentation and Session layers are combined with the Application layer for simplicity.)
| Approach | When to Use |
|---|---|
| Bottom-up | Useful when the fault is localized at a network edge — e.g., all users can't reach the internet but every other network resource is available. You start at Layer 1 with this approach (a router sits at the network edge and connects users to the internet) |
| Top-down | Useful when the fault reported is at the top of the OSI model — e.g., users are unable to reach a specific web page |
| Divide-and-conquer | Quickly eliminates part of the OSI model, letting the technician solve the issue more efficiently |
Troubleshooting is an art, not a science — there is no single "right" way to troubleshoot everything. With experience, the process becomes automatic and more efficient.
| Objective | Detail |
|---|---|
| 7a | Given necessary materials, troubleshoot a switch (≤2 instructor assists) |
| 7b | Given necessary materials, troubleshoot a router (≤2 instructor assists) |
| Measurement | Both objectives are measured during the final block, at the Capstone |
| Key takeaway | A switch and a router use the same troubleshooting process — learning the techniques minimizes the impact of operational failures, which are a reality for just about any enterprise |