Books for the NOC guys...

This morning I went digging for a book to recommend that someone in
our NOC read in order to understand at a high level how Internet
infrastructure works (bgp, igps, etc) and discovered that the old
standbys (Huitema, Halabi, Perlman) have all not been updated in a
decade or so.

On the one hand, they're all still quite relevant since there hasn't
been anything really earth-shattering in that department, but they are
all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation.

So, what are you having your up-and-coming NOC staff read?

Thanks,

-r

<http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365/ref=sr_1_2?ie=UTF8&s=books&qid=1270210783&sr=8-2>

<http://www.amazon.com/Practical-BGP-Russ-White/dp/0321127005/ref=sr_1_1?ie=UTF8&s=books&qid=1270210821&sr=1-1>

<http://www.amazon.com/TCP-Guide-Comprehensive-Illustrated-Protocols/dp/159327047X/ref=sr_1_1?ie=UTF8&s=books&qid=1270210859&sr=1-1>

<http://www.amazon.com/TCP-Illustrated-Volumes-1-3-Boxed/dp/0201776316/ref=sr_1_1?ie=UTF8&s=books&qid=1270210884&sr=1-1>

So, what are you having your up-and-coming NOC staff read?

In an attempt to wean them off of unmanageable PERL scripts
<http://www.complete.org/FoundationsOfPythonNetworkProgramming&gt;

There are tons of tutorials and articles on the web, often with links
to other useful stuff
<http://www.howstuffworks.com/internet-infrastructure.htm/printable&gt;
<http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/troubleshooting/&gt;

And let's not forget all of the NANOG presentations. Sometimes the slides are
quite good on their own but if not, the audio is there too.
<http://www.nanog.org/meetings/nanog29/presentations/smith.pdf&gt;

I would encourage them to download PDFs, videos and websites for future
reference and to share with colleagues.

Also, set up a wiki, and ask them all to record any useful bits of info there
and to track Recent Changes every week or so to see what colleagues are
sharing.

--Michael Dillon

So, what are you having your up-and-coming NOC staff read?

While not specifically a NOC book, we find that it lays a great foundation
to build from (if, perhaps, a bit basic in certain areas):

Network Warrior by Gary A. Donahue

This is a great book with an easy to read style.

Tom Walsh

This morning I went digging for a book to recommend that someone in
our NOC read in order to understand at a high level how Internet
infrastructure works (bgp, igps, etc) and discovered that the old
standbys (Huitema, Halabi, Perlman) have all not been updated in a
decade or so.

[...]

So, what are you having your up-and-coming NOC staff read?

That is an excellent question Rob. I still recommend and prefer to use
Radia's book when I teach networking classes. There are lots of books
that regurgitate the specs or spend a fair amount of time on the
core algorithms and mechanisms, but few go into the "why" and "what if"
like she does that makes it so exceptional and particularly relevant
from an operations perspective.

I often will play a clip or two from past meetings like NANOG and
discuss that in class to make up for the lack of reference and
discussion material elsewhere. Perhaps point them at a few of your
favorite presentations on a particular operationally relevant topic
you want them to know more about?

John

There is not, and there never will be, a useful programming language that
makes it the least bit difficult to write totally abominable creeping-horror
unmaintainable code in.

The ability of a programmer to write totally obtuse code is entirely
orthogonal to the choice of implementation language. Some people just don't
have good taste, and will produce train wrecks in any language. Remember that
it's possible to write Fortran-IV code in any language. :slight_smile:

Unless you teach them stuff like "Document the sources and expected types of
input data", "add useful comments that explain your choice of algorithms rather
than "a++; /* Add one to A */", and "If the language supports operator
overloading, don't be a bozo and abuse it", the code will be unmaintainable.

"Teach them". Train them. Have standards. Enforce them (pay according
to compliance).

What a concept! We did that using Autocoder and COBOL.

What next? "Manage" them? Is that even legal?

I just show them this:

http://warriorsofthe.net/

  -Scott

It kind of depends on what you want from your NOC folk and (at least a little bit) which "level" NOC people need the resource.

In addition to the ones already listed, we encourage Tier 1 and Tier 2 people to read and understand these two books:
T1: A Survival Guide
http://www.amazon.com/T1-Survival-Guide-Matthew-Gast/dp/0596001274/ref=sr_1_1?ie=UTF8&s=books&qid=1270216284&sr=8-1

Network Maintenance and Troubleshooting Guide
http://www.amazon.com/Network-Maintenance-Troubleshooting-Guide-Solutions/dp/0321647416/ref=sr_1_1?ie=UTF8&s=books&qid=1270216655&sr=1-1

We find these are both pretty solid resources, especially for our Tier 1 folks. Since much of what they eventually deal with are Layer 1 problems, having resources that focus on Layer 1 helps get their mind moving that direction. If we have a routing problem, that generally needs to get bumped up anyway since it means somethings misconfigured or a routing protocol is acting up.

"Robert E. Seastrom" <rs@seastrom.com> writes:

So, what are you having your up-and-coming NOC staff read?

<Amazon.com;

I think it's quite good and covers many "modern" topics. One drawback:
It mentions ethereal and not wireshark. At the time of writing ethereal
must have been dead for about 2 years.

Jens

Practice of System and Network Administration by Limoncelli, Hogan, and Challup. I may be biased, being married to Hogan.

Eliot

The Limoncelli etc book is brilliant.

There's phil smith and barry greene's old "Cisco ISP Essentials" too.
Very good if somewhat outdated

And then there's this if you just want security -
http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365/ref=sr_1_1?ie=UTF8&s=books&qid=1270223489&sr=1-1

Heh.. GUIs they come and GUIs they go... tcpdump works forever.

Owen

+1 Network Warrior.

-B

+1 on PSNA. I like it as much for its non-technical content as for its
technical content (a similar book, by Limncelli, "Time Management for System
Administrators" is also on my shelf, with great non-technical content, and
should be a must-read for any technical personnel, IMO).

+1 also on Network Warrior, although not for everything.

I also have 'Cisco Network Professional's Advanced Internetworking Guide' by
Patrick J. Conlan, published by Sybex. Comes with the full text on CD in PDF
form, too. The URL is pretty long, so use the search on sybex.com to find it.
Here's the ToC:

1. Enterprise Network Design.
2. Switching.
3. Spanning Tree Protocol (STP).
4. Routing Concepts and Distance Vector Routing Protocols.
5. Advanced Distance Vector Protocols.
6. Link State Routing Protocols.
7. Exterior Routing Protocols.
8. Multicast.
9. IP Version 6.
10. Redundancy Protocols.
11. WAN and Teleworker Connections.
12. Virtual Private Networks (VPN).
13. Device Security.
14. Switch Security.
15. Cisco IOS Firewall.
16. Cisco IOS IPS.
17. Voice.
18. DiffServ Quality of Service (QOS).
19. Wireless Devices and Topologies.
20. Wireless Management and Security.

Which pretty much, I think, covers the bases asked about in the OP. The
copyright is May 2009, so it's not too bad out of date.

+n

"Whatever language you write in, your task as a programmer is to do the
best you can with the tools at hand. A good programmer can overcome a poor
language or a clumsy operating system, but even a great programming
environment will not rescue a bad programmer". (Kernighan and Pike)

Although language zealots are loth to admit it, certain languages are
better suited to some things than to others. Perl's syntactical support
for text processing are second to none, but for web stuff, it's hideous.
PHP stinks on the command line and text processing, yet its web integration
makes it a good candidate for small web projects. Shell scripts are
designed specifically for command line tool management, pipes and all that
sort of thing, and just because other languages support popen() and system,
that doesn't necessarily make them good choices for stuff which involves
unix scripting. I write readable and maintainable code in all three.

Java elicits strong reactions. No doubt, you can use Java plumbing
libraries to scale to impressively large systems. On the other hand, Cisco
Configuration Professional (the new SDM) provides an excellent example of
how badly you can screw up a good idea by using the wrong tool - I'm not
interesting in using or recommending a desktop tool which takes 2 minutes
to start on a fast computer.

You can write unimaginably awful code in python and ruby, and irrtoolset's
code is a prime example of what you can do with c++. Yet, we all
acknowledge that python, ruby and c++ are high quality languages.

In short: less zealotry, more pragmatism and a realisation that each
language has its own strengths and weaknesses. Bad code is bad code in any
language.

Nick

All true, but I'd still say there's a special rung in hell for bad perl.

Mike

Once upon a time, Michael Thomas <mike@mtcc.com> said:

All true, but I'd still say there's a special rung in hell for bad perl.

Ehh, bad perl is still more readable than good APL. At least I can
reformat the perl! :slight_smile:

Well, speaking as one who wrote an ISP-specific, although not NOC-specific book about a
decade ago, it doesn't seem as if there is a commercial motivation to update them. For the
record, it's _Building Service Provider Networks_ (Wiley, 2001), and I'm proud of it.

Nevertheless, I'm not opposed to trying to create updated open-source guidance. I do a
good deal of work with http://en.citizendium.org, a real-name Wiki that is trying to reach
critical mass. Anybody interested in collaborating?

I'd actually started more on RPSL and peering than first-tier ops, but hadn't done
anything more for lack of activity there. Certainly, I could port some of my NANOG
tutorials, not that I have the PPT for many but just the PDF.

In my experience bad perl usually consists of using system() a lot to
run shell commands and read the input. Creative well-written perl, now
there's something unreadable and unmaintainable! :slight_smile:

-B