7-2 Project Two Submission: Network Diagram And Rationale: Exact Answer & Steps

Have you ever stared at a blank screen and thought, “What the heck is a network diagram?”
You’re not alone. Whether you’re a student juggling a 7-2 project two submission or a budding network engineer, the idea of drawing a diagram that captures every device, link, and protocol can feel like a mountain.
But here’s the thing: a solid network diagram is more than a pretty picture. It’s the blueprint that keeps everyone on the same page, saves time, and prevents costly mistakes And that's really what it comes down to..

What Is a 7-2 Project Two Submission

When the syllabus says “7-2 project two submission: network diagram and rationale,” it’s asking for two things:

1. A visual map that shows how every component of your network fits together.
2. A written explanation that justifies your design choices and links them back to the project requirements.

Think of it as a two‑part report. The diagram is the “what” and the rationale is the “why.” Together, they convince your instructor that you understand the theory and can apply it in practice.

The Diagram Part

• Nodes: routers, switches, firewalls, servers, wireless access points, etc.
• Links: copper, fiber, wireless links, VPN tunnels.
• Labels: IP ranges, VLAN IDs, bandwidth, redundancy status.
• Topology: star, mesh, hybrid—whatever your design uses.

The Rationale Part

• Design goals: performance, cost, security, scalability.
• Constraints: budget, existing infrastructure, regulatory compliance.
• Trade‑offs: why you chose a dual‑stack IP over IPv4‑only, why you added a DMZ, why you opted for a redundant core.

Why It Matters / Why People Care

You might wonder, “Why do I need to spend time on a diagram and a rationale?”
Because in the real world, a network diagram is the single document that can prevent weeks of troubleshooting. It’s also the first thing a stakeholder sees when they ask, “Can this network handle 10,000 users?

Real‑World Consequences

• Deployment delays: A missing link or mislabeled port means a technician will waste hours on the floor.
• Security gaps: Without a clear visual, you might overlook a misconfigured VLAN or an exposed management interface.
• Budget overruns: A diagram that shows redundant paths can justify buying extra hardware, while a poor one might lead to under‑provisioning.

In short, the diagram and rationale are the bridge between concept and execution. They’re the single source of truth for everyone involved.

How It Works (or How to Do It)

Step 1: Gather All the Facts

• Inventory: List every device, port, and cable.
• Requirements: Pull the project brief, SLA expectations, and any regulatory checks.
• Existing Infrastructure: If you’re extending an existing network, map out what’s already there.

Step 2: Choose Your Tool

• Free: Microsoft PowerPoint, LibreOffice Draw, draw.io (now diagrams.net).
• Professional: Visio, Lucidchart, or even network‑specific tools like SolarWinds Network Topology Mapper.
• Tip: Start with a simple tool; you can always export to PDF or SVG later.

Step 3: Sketch the Core

• Place the core router or switch in the center.
• Add top‑level connections: WAN links, core‑to‑distribution, distribution‑to access.
• Keep the layout clean—avoid crossing lines wherever possible.

Step 4: Add Layers

• Access Layer: End‑user devices, wireless APs.
• Distribution Layer: Layer‑3 switches, routing protocols.
• Core Layer: High‑speed spine, redundancy.

Step 5: Label Everything

• IP Scheme: Show subnets, gateway addresses.
• VLAN IDs: Highlight which ports belong to which VLAN.
• Link Types: Fiber, copper, wireless.
• Redundancy: Mark active‑standby pairs or link aggregation.

Step 6: Validate the Diagram

• Cross‑check with your inventory.
• Run a quick ping test in your lab to ensure the logical topology matches the physical.
• Ask a peer to walk through the diagram—fresh eyes catch hidden mistakes.

Step 7: Write the Rationale

1. State the objective: “The network is designed to support 200 concurrent users with 99.99% uptime.”
2. Explain the topology choice: “A three‑layer design provides scalability and fault isolation.”
3. Justify device selection: “We chose the Catalyst 9200 for its PoE+ support and built‑in security features.”
4. Address constraints: “Budget limits forced us to use a single 10G uplink; however, we mitigated risk by adding a secondary 1G link.”
5. Highlight future growth: “The design includes spare uplink ports for a 50% traffic increase in the next 3 years.”

Common Mistakes / What Most People Get Wrong

1. Over‑complicating the diagram

   • Reality: A cluttered map is harder to read than a simple one.
   • Fix: Use layers in your tool; hide lower‑level details until needed.

2. Ignoring the rationale

   • Reality: A diagram alone doesn’t convince anyone.
   • Fix: Tie every decision back to a requirement or constraint.

3. Under‑labeling

   • Reality: Missing IP addresses or VLAN IDs turns a diagram into a guessing game.
   • Fix: Double‑check each element against your inventory.

4. Skipping validation

   • Reality: A diagram that looks good on paper can be wrong in the lab.
   • Fix: Test connectivity in a sandbox environment first.

5. Using the wrong tool

   • Reality: PowerPoint might be quick, but it lacks network‑specific symbols.
   • Fix: Pick a tool that supports standard networking icons and export options.

Practical Tips / What Actually Works

• Use color coding: Green for active links, red for failover, blue for management interfaces.
• Keep a legend: Especially if you use custom icons or abbreviations.
• Version control: Save incremental drafts (v1, v2) to track changes.
• use templates: Many diagram tools offer network templates—start there, then customize.
• Document assumptions: In the rationale, note any assumptions (e.g., “Assuming a 1 Gbps uplink is available”).
• Include a risk matrix: Highlight potential failure points and mitigation strategies.
• Add a “next steps” section: Outline the deployment plan, including procurement and testing phases.

FAQ

Q: Can I use a generic diagram template?
A: Yes, but personalize it. Replace generic icons with your actual device models and label real IP ranges.

Q: How detailed should the diagram be for a class submission?
A: Show enough detail to prove you understand the topology, but avoid unnecessary depth. Include core, distribution, and access layers; skip individual end‑device connections unless required Easy to understand, harder to ignore. Still holds up..

Q: What if I can’t get all the hardware specs?
A: Use placeholders and note that the final device choice will be confirmed during procurement. In the rationale, explain the criteria for selecting the final hardware.

Q: Is it okay to use a free tool like draw.io?
A: Absolutely. As long as the diagram is clear, properly labeled, and exportable to a high‑resolution PDF, the tool matters less than the content Most people skip this — try not to..

Q: How long should the rationale section be?
A: Aim for 300–500 words—concise but thorough. Cover objectives, design choices, constraints, and future considerations.

So there you have it.
A network diagram and its accompanying rationale are the two halves of a well‑rounded project submission. Treat them like a pair of shoes: they look better together, and they keep the whole outfit—your project—on point. Dive in, map it out, justify every line, and you’ll walk into that final exam or client meeting feeling confident and ready to deploy Most people skip this — try not to. That alone is useful..