Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm structuring a series of training sessions designed to eliminate overall knowledge gaps in network troubleshooting and administration.

Of the following topics, in what order would you cover them for the best chance of "getting it" and having things click? What topics would you change?

  • General OSI Model (Application / Presentation / Session / Transport / Network / Data Link / Physical)
  • Firewalls
  • NAT
  • STUN / P2P
  • TCP and UDP
  • HTML (build a simple web site in notepad kinda thing)
  • Application Security (HTTPS vs. HTTP for example)
  • Performing a Wireshark Trace
  • Active Directory / LDAP / Group Policy
  • DNS
share|improve this question

closed as primarily opinion-based by masegaloeh, Scott Pack, 84104, Katherine Villyard, MadHatter Apr 18 at 5:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This would be better as a wiki. –  Troggy Aug 4 '09 at 17:52
Wiki - Done! :) –  Brandon Aug 4 '09 at 17:54

3 Answers 3

up vote 1 down vote accepted

I've taught some network courses myself, and I think it's really useful to start with a general presentation of the different layers in a network stack, because lots of people are totally unaware of how protocols stack on top of each other and what are differences and relationships between "Internet Explorer", "HTTP", "TCP", "IP", "Ethernet" and so on; just don't stick too much to the ISO/OSI model, because, as everyone knows, it's more useful in a "general" sense than as an accurate model of how things work today.

My second step would be a THOROUGH dwelling into TCP/IP (with added UDP and ICMP, of course), because is one of the most misunderstood area for wannabe network admins; almost everybody can type and IP address in a network settings window, but a suprisingly low number of people know what it actually means and what a subnet mask and a routing table are; routing and NAT of course will be coming soon after. These are the most important topics of all: if you don't get them right, there's no point in talking about firewalls (I once met a guy who wanted me to run a firewall by simply connecting it to the network, because it just didn't know it has to sit between two places if it needs to filter the traffic between them; but that guy was probably more lacking common sense than network knowledge).

DNS is the obvjous next step, as you will of course need something a little more friendly to remember than those pesky numbers; this pretty much ends the "pure networking" sections, and if you want to share some historic knowledge you can of course drop some bits about things having been much, much more chaotic in the past, with different proprietary protocols and so on.

Next I would talk about the most common application protocols (HTTP/S, SMTP, FTP, etc.), without too many gory details, but with enough of them to make people understand why you just can't have two SSL web sites on the same IP address and port, or why e-mail was never designed to be 100% reliable and so you shouldn't start screaming if your message needs more than one minute to get delivered; and, of course, why FTP is the worse dream a firewall can have.

What comes next depends on the specific O.S. you're dealing with.

Windows administrators need of course to focus on Active Directory (and boy, there's PLENTY of it to talk about!), and then of course IIS; I'd leave out Exchange and SQL Server as they're pretty cumberstome beasts for a basic course, and I'd also leave out ISA Server, which is the firewall solution when Microsoft is involved, but can get quite complex to understand at times; if you need some routing/firewall capabilities to play with in a test lab, every Windows release since 2000 had built-in Routing and Remote Access which can do awesome things in simple setups.

I'm not really into Linux administration, but I'm sure other people around can give you some hints about that; IPTABLES of course is a must, and some Apache knowledge isn't probably going to hurt anyone.

share|improve this answer

We should wiki this, really.

I'd add something more theoretical about security; it's the one area which trips people up and where a lot of really serious misunderstandings exist. For example, people might tend to forget that as well as keeping the bad guys out, the primary purpose of security is also to let the good guys in (my guess is that this is where 99% of botched overly-complex security models come from).

I'd also add in some basic (lower-case "b") programming; every network person should possess some knowledge of how to program (what's a variable, flow control, input and output, etc) for writing scripts and homegrown mini-tools.

Not sure how relevant the OSI model is these days; unless you're delving deep into actual architecture you'll probably not need it (although being aware that it exists and having a general idea of what each layer is for never hurts).

In fact, dividing the list into two - (1) network architecture, and (2) network applications seems to me to be a better idea (with some overlap between the two, of course).

And oh yeah - you forgot backups. Bottom of the class. :)

share|improve this answer

I'd get rid of anything to do with the OSI model. It was a pointless, design by committee, non-implemented standard that Europeans (yes I am one) tried to force on the world. This sums it up nicely.

My one bit of advice is to read Radia Perlman's Interconnections book to ge a good grounding in the subject.

share|improve this answer
Re: OSI, I'd argue it's useful enough to have a very basic knowledge of the layers, so that - for ex - you know what a "layer 3 switch" is when you come across one (and also know why it's different to a regular switch). Deep knowledge of it though is not really relevant; it describes a theoretical idealised setup moreso than anything you'll encounter in the real world. –  MFAH Aug 4 '09 at 18:19
It is useful to know only to show the wrong way to implement a standard, i.e. write a standard and then expect people to implement it. Compare it to than the IETF Internet Standards Process. This works very well and as a result we have something tangible to show for it. –  goo Aug 4 '09 at 18:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.