Slashdot Mirror


Book Review: Networking For System Administrators

Saint Aardvark writes Michael W. Lucas has been writing technical books for a long time, drawing on his experience as both a system and a network administrator. He has mastered the art of making it both easy and enjoyable to inhale large amounts of information; that's my way of saying he writes books well and he's a funny guy. Networking for System Administrators, available both in DRM-free ebook and dead tree formats, is his latest book, and it's no exception to this trend. Keep reading for the rest of Saint Aardvark's review. Networking for Systems Administrators author Michael W. Lucas pages 206 publisher Tilted Windmill Press rating 9/10 reviewer Saint Aardvark ISBN 0692376941 summary Explains networking to sysadmins - both juniors new to this career, and those who have been around for a while Like the title suggests, this book explains networking to sysadmins — both juniors new to this career, and those who have been around for a while but don't understand how those network folks live or what they need to do their job. If you're one of the latter, you might think "Oh I've read 'TCP/IP Illustrated' — I don't need another networking book." And it's true that there is overlap between these two books. But Lucas also explains about how to work with network folks: dealing with areas of shared responsibility, how to understand where your side ends, and how to talk to a network admin so that everyone understands each other — and more importantly, is both able and happy to help the other. This is something that is out-of-scope for a network textbook, and it's valuable.

So what's in this book? Lucas takes us through all the network layers, explaining how everything fits together. From physical ("If you can trip over it, snag it, break the stupid tab off the plastic connector at its end, or broadcast static over it, it's the physical layer.") to transport and application, he shows practical examples of how the OSI model maps (or doesn't) to the world of TCP/IP. He shows the happy path and the sad path at each layer, explaining how to understand what's going on and troubleshooting failures. This is the part with the strongest overlap with those other network textbooks. If system administration is a side gig (maybe you're a developer who has to maintain your own server), you'll have enough in this book to deal with just about anything you're likely to trip over. But if you're early in your sysadmin career, or you find yourself making the jump to Ops, you will want to follow it up with TCP/IP Illustrated for the additional depth.

Since you'll be troubleshooting, you'll need to know the tools that let you dump DNS, peer into packets, and list what's listening (or not) on the network. Lucas covers Linux and Unix, of course, but he also covers Windows — particularly handy if, like me, you've stuck to one side over the course of your career. Tcpdump/Windump, arp, netstat, netcat and ifconfig are all covered here, but more importantly you'll also learn how to understand what they tell you, and how to relay that information to network administrators.

That thought leads to the final chapter of this book: a plea for working as a team, even when you're not on the same team. Bad things come from network and systems folks not understanding each other. Good things — happy workplaces, successful careers, thriving companies and new friends — can come from something as simple as saying "Well, I don't know if it is the network's fault...why don't we test and find out?"

After reading this book, you'll have a strong footing in networking. Lucas explains concepts in practical ways; he makes sure to teach tools in both Unix/Linux and Windows; and he gives you the terms you'll use to explain what you're seeing to the network folks. Along the way there's a lot of hard-won knowledge sprinkled throughout (leave autonegotiation on — it's a lot better than it used to be; replace cables if there's any hint of flakiness in a server's network connection) that, for me at least (and be honest, you too) would have saved a lot of time over the years.

Who would I recommend this book to?
  • If you're a sysadmin at the beginning of your career, this book is an excellent beginning; take it, read it, and build on it — both with practical experience and further reading.
  • If you're coming into system administration the back way (as a developer who has to manage their own server, say, or who shares responsibility for a networked service with other admins), I can't think of a better single source for the practical knowledge you need. You'll gain an understanding of what's going on under the hood, how to diagnose problems you encounter, and how to talk to either system or network administrators about fixing those problems.
  • If you're a manager or senior sysadmin, buy this book and read it through before handing it to the juniors on your team, or that dev who keeps asking questions about routing and the firewall; you may learn a few things, and it's always good to read fine technical writing.

You can purchase Networking for Systems Administrators from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.

33 comments

  1. How many times .... by khasim · · Score: 2, Interesting

    If there really is a "network problem" then it won't be just your machine that cannot connect to some other machine.

    It would be lots of people and/or machines that would not be able to talk to lots of other machines and/or people.

    And the network rarely experiences "problems" that only show up after you've applied a patch.

    Bad things come from network and systems folks not understanding each other.

    As a network engineer, I can quote almost EXACTLY what the sysadmin will say. Understanding them is easy.

    Communicating something they do not want to hear is the issue.

    1. Re:How many times .... by Anonymous Coward · · Score: 0

      amen..... how many times do you hear your coworker sysadmin throw the issue over the fence with "It must be a networking problem, yeah... confirmed it" before it's pretty obvious it's not communication that is the problem. It's that magic "oh, dump this on his lap and I don't have to work on it anymore" mindset that makes us network admins and engineers distance ourselves from sysadmins.

    2. Re:How many times .... by Anonymous Coward · · Score: 3, Funny

      Being both a sysadmin and a network admin, both my personalities get in huge fights over this!

    3. Re:How many times .... by Anonymous Coward · · Score: 1

      except for when the router/firewall rules have been changed and the network guys told no one ahead of time. Oops, you were using that Port? not our fault.
      Seen that too often.

    4. Re:How many times .... by Anonymous Coward · · Score: 3, Insightful

      If there really is a "network problem" then it won't be just your machine that cannot connect to some other machine.

      Sure, if your network is just a couple of dumb switches and a single rule "Drop Inbound" firewall, but if that's the case you probably don't even have a Network Administrator to talk to. But if your network has dozens of VLANs, multiple gateways and complex firewall rules, it very well could be a network issue that so far only you have experienced. Sure, the problem is probably not Machine X can't connect to Machine Y, and more likely to be VLAN 17 can't initiate a connection to VLAN 56 over port 8080, but maybe you're the only one at your company who needs to make that particular connection at that time. And the basic idea of the book is to give sysadmins some ability to differentiate between application issues and network issues. In my example, if VLAN 17 and VLAN 56 are QA networks, there's a reasonable chance your network team won't give a shit and it'll take them a week to even take a look, so it's probably worthwhile as a sysadmin to make sure that A) Machine X is actually sending the data out the network interface and B) Machine Y isn't receiving the data and just discarding it.

    5. Re:How many times .... by Anonymous Coward · · Score: 0

      I recently (last year) was cut over from AT&T to Frontier (or "sold off" would be more appropriate").
      *3 days* after Frontier took over, my network was crap, dropping continually, etc.
      They insisted "nothing changed". I found a firmware flash for my modem and suddenly it was all fine again.

      Now, arguably I should have kept up on the firmware, but I've had that modem for *10 years* with a rock-solid connection (barring a few storms where lines came down, power was out, etc). You can't tell me nothing changed on their end, it's ludicrous that my firmware update fixed it but "nothing changed" on their end.

    6. Re:How many times .... by Obfuscant · · Score: 1

      If there really is a "network problem" then it won't be just your machine that cannot connect to some other machine.

      It certainly can be. There's a lot of "if you can trip over it" stuff between some of the systems I administer and the network they connect to.

      I've had a wonderful fiber to cat5 converter that decided it would not pass any packets larger than about 128 bytes. Ping worked great. You could initiate all kinds of TCP connections, like the initial SSH handshaking. It was fascinating to see how the network reacted to different ping packet sizes while tracking this down. Make them small enough, the destination was alive. Make them one byte too large, the destination was offline.

      That was a network problem. It was isolated by pinging various controlled devices on that network and seeing what things stopped answering when the packet got too big.

    7. Re:How many times .... by khasim · · Score: 2, Insightful

      Sure, the problem is probably not Machine X can't connect to Machine Y, and more likely to be VLAN 17 can't initiate a connection to VLAN 56 over port 8080, but maybe you're the only one at your company who needs to make that particular connection at that time.

      And you call it in and the network engineer will ask some questions:

      a1. Has this ever worked in the past? (they will always answer "yes")
      a2. When was the last time you know it was working? (50% "yesterday" 50% "last week")
      a3. Has anything changed on the boxes or were they moved? (100% no nothing same as always)

      b1. Is this a new install? (95% of the time this will be the problem but they will only admit it 1% of the time)

      But if your network has dozens of VLANs, multiple gateways and complex firewall rules, it very well could be a network issue that so far only you have experienced.

      And the change control logs should IMMEDIATELY show you where the problem is, in that case.

      In my example, if VLAN 17 and VLAN 56 are QA networks, there's a reasonable chance your network team won't give a shit and it'll take them a week to even take a look, so it's probably worthwhile as a sysadmin to make sure that A) Machine X is actually sending the data out the network interface and B) Machine Y isn't receiving the data and just discarding it.

      That's the problem. Change control shows no changes on 17 or 56 in the last 6 months.

      The alarm systems show no changes.

      I can pull up the data on the ports X & Y are using in 30 seconds. No errors showing.

      In another 30 seconds I can check all the stats for 17 & 56.

      The network is SIMPLE! It really is. Troubleshooting a connection issue takes a few minutes at most.

      In your example, the sysadmin will just say "the network is the problem" when the REAL PROBLEM is that the LATEST UPDATE of his app means it now listens on 443 instead of 8080.

      And a quick Google search will bring up page after page of references to that just using the app name and the app version number.

    8. Re:How many times .... by Anonymous Coward · · Score: 0

      > If there really is a "network problem" then it won't be just your machine that cannot connect to some other machine.
      > It would be lots of people and/or machines that would not be able to talk to lots of other machines and/or people.

      You might want to read the chapter on about working together. The symptoms of a "Administratively down" interface would look like "Your machine that cannot connect to some other machine."

    9. Re:How many times .... by Anonymous Coward · · Score: 0

      First of all, I'm sorry. So so so so very sorry.

      While I'm fairly sure that even Frontier could not fuck up a network that badly in 3 days, your initial suspicions are not unfounded.

      Just give them time. Their level of service will inevitably sink to below even your worst expectations. Sooner, rather than later probably.

      Again, sorry.

      Hint: If ATT is selling off an unprofitable network, what makes you think a notoriously shitty CLEC (yeah, thats redundant) can run it without cutting corners?

    10. Re:How many times .... by Bigbutt · · Score: 2

      Yea, a1 is the one that's probably the most annoying. I get regular (daily) data from this server. I have monitoring agents in place to notify me if the system goes off line or even has a bad afternoon.

      "Has this ever worked?"

      Are you fucking kidding me? Here are the tcpdumps from the system showing the packet loss. Here's the output of ifconfig showing the interface as down. Here's ethtools showing no link. Here are the configuration files from yesterday showing it was on line yesterday. Here is the monthly consolidation file showing it's been configured for years. The shit I gave you when I opened the ticket in the first place!

      "Did something change in the data center?"

      Nothing we've done. It's a remote site and we don't manage the data center. Maybe it's a cable that went bad, someone tripped over, a switch configuration change due to a reboot, a firewall change?

      Data Center Manager: "In my experience, cables don't go bad. Are you sure the system was working yesterday? I tend to believe the Networking folks over you sysadmins."

      Ultimately it turns out the cable went bad. Replaced the cable and all was well again.

      But damn, "was it working yesterday" really is a pisser.

      [John]

      --
      Shit better not happen!
  2. Pfft.... by Etherwalk · · Score: 1

    Why would you need a book? Just read the TCP/IP Kernel code for open-source operating systems.

    I especially liked reading the the TCP code in OS/X which had been modified from the code of the early 90s and helpfully preserved the now wildly inaccurate original comments in case you felt the need to explore what it would really feel like to drink a Pan-Galactic Gargle Blaster.

  3. MS has taught us by Anonymous Coward · · Score: 0

    for any problem please contact your network administrator

    1. Re:MS has taught us by skids · · Score: 1

      That's because Microsoft's definition of "Network Adminstrator" is someone who administers AD servers.

  4. weird title? by cherouvim · · Score: 2

    Like saying "programming for programmers".

    1. Re:weird title? by Anonymous Coward · · Score: 0

      You are thinking of "Networking for Network Administrators". This is "Networking for System Administrators". See the difference?

    2. Re:weird title? by HornWumpus · · Score: 3, Insightful

      The network is part of the system.

      SAs had better understand networking, I don't expect/demand Cisco certs, but basic understanding of networking is a requirement of the job.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    3. Re:weird title? by Obfuscant · · Score: 2

      No, like "writing compilers for programmers". System administration is a different job than network administration, even though the person doing the jobs may be the same and the responsibilities overlap.

    4. Re:weird title? by H0p313ss · · Score: 1

      The network is part of the system.

      SAs had better understand networking, I don't expect/demand Cisco certs, but basic understanding of networking is a requirement of the job.

      I deal with systems administrators of large corporations on a daily basis, there are lots of really excellent administrators who really know their stuff and frequently teach me something when we interact.

      However, and unfortunately, there is also a significant group who don't know TCP from UDP (etc.). This is the group this book is for.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    5. Re:weird title? by Anonymous Coward · · Score: 0

      Make up your mind. Either all sysadmins should be network experts or not.

    6. Re:weird title? by HornWumpus · · Score: 1

      You do understand it is possible to understand TCP and not know how to configure a router? One is general knowledge, one is specific's of an implementation.

      Sysadmins don't have to know how to fix every network issue. They should know how to traceroute, find the problem area and communicate; rather than give 'network is broken' type diagnostics.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    7. Re:weird title? by Enry · · Score: 3, Insightful

      They shouldn't be SAs then. As GP said, I don't expect Cisco certification, but there is a level of knowledge of networks that a competent SA should have.

    8. Re:weird title? by H0p313ss · · Score: 1

      Which is why they need a book.

      Is this so hard to understand? They're in over their heads and they need a hand.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    9. Re:weird title? by skids · · Score: 1

      They shouldn't be SAs then

      If they keep the email flowing and the databases up, I don't care that much that the SA's cannot tell the difference between a UUID and an IPv6 address. It's my job to do the latter.

    10. Re:weird title? by dbIII · · Score: 1

      Maybe they are evolving from being the Pimply Faced Youth (from BOFH) to a sysadmin. I know when I went from being an engineer to sysadin I read the crab book (TCP/IP) and armadillo book (Essential System Administration), as well as a lot of hands on stuff before I became anything close to a reasonable sysadmin. I've met a few people who have made newbie mistakes in production that could benefit from such a book even though they are already in the role.

    11. Re:weird title? by Anonymous Coward · · Score: 0

      I've found many network folks to be somewhat arrogant toward sysadmins. It doesn't work (types in the background, "try it again"). No, it works now. What did you do?

      Oh, nothing.

  5. Information huffing -- wtf? by Anonymous Coward · · Score: 1

    Inhaling large amounts of information? Do you get high? I've huffed kittens, and glue, but never information. If I had a book, I'd try doing it right now. But after huffing the glue, my mind is fried. I only see sounds now.

  6. Subneting made easy by CycloneGT · · Score: 3, Interesting

    Everyone should learn how to subnet. I was working tech support that mostly included unix admin activities. Then they told me to get my CCNA. Glad I did. Just the simple act of learning how to subnet ip addressing has made all of the difference in the world. Its kind of like learning the alphabet, it just make so many other things easier.

    1. Re:Subneting made easy by Bigbutt · · Score: 1

      Yea, got my CCNA and CCNP over 10 years ago and it's really been a benefit in general networking knowledge. Same with starting off 35 years ago as a programmer. Programming and networking really helps in being a sysadmin.

      [John]

      --
      Shit better not happen!
    2. Re:Subneting made easy by skids · · Score: 1

      Skip the CCNA and just read some topical books. I've been working networks my entire career and every time I crack a CCNA book, I get 2 chapters in and decide to go read something that is actually useful instead. Most of the things CIsco seems to think every network admin needs to know are job-specific skillsets you'll probably never use and can be picked up when and if they are needed as long as you've put in your time. Or whatever flavor of the month monstrosity they are pushing on their customer base as a "must have" just because they are the only ones who have it (though they seem to have stuck with IP SLAs longer than a month.)

      CCNA is basically a prerequisite for SE training, not really worth the time of anyone who doesn't have to answer questions all day from sundry customers. Also required for nwteork admins who for job-market reasons need to stoop to working for PHBs, but IMO you're better off working for an employer who waives that requirement when they see your years worked.

      Certainly CCNA is not the best thig for SAs in particular. Learn in this order: ARP, IP subnets, iptables, rudimentary tcpdump/tshark and VLANs, and you'll be more than capable of escalating tickets to networking competently.

  7. 206 pages? by Anonymous Coward · · Score: 0

    C'mon, you can't cover a topic of this size with any justice in less than 3 or 4 times that. And $22 plus tax is a lot to pay for programmer jokes.

  8. doing it wrong by Anonymous Coward · · Score: 0

    If you are a sysadmin, you should damn well already know this material. Otherwise, don't call yourself a sysadmin, call yourself a helpdesk analyst. That's all you are at that point.

    1. Re:doing it wrong by skids · · Score: 1

      Bull. I know plenty of very good sysadmins who have to google every time they need to use ifconfig. Just as there are plenty of BGP jockies that would't know the first thing about setting up dchp snooping. Their talents lie elsewhere, is all. There's a large variety of specialization in IT these days.