A Few Sweepstakes Going On

A few days ago, both Cisco Press and VMware Press announced a few opportunities to win a few goodies via Facebook.  Details below:

 

 

VMware Press Launches Sweepstakes!

VMware Press, the official publisher of VMware books and training materials, has launched a 60 day Facebook sweepstakes beginning May 1 and running through June 30^th. Prize offerings include a $100 Amazon gift card and three VMware Press books of the winner’s choice; nine second prize winners will win an eBook of their choice.

http://ow.ly/aBkvE

 

 

Cisco Press Offers Free Trip to Cisco Live!

The official publisher of Cisco launched the annual Cisco Press Facebook sweepstakes today, offering free to Cisco Live 2013 including travel ($1,000 American Express gift card) and registration and a choice of three Cisco Press print or eBooks! Nine second prize winners will also win three print or eBooks of their choice for a total of 10 winners in all. The Cisco Press Sweepstakes begin May 1 and run through June 30^th http://ow.ly/aBv08.

 

.

Book Review: IPv6 for Enterprise Networks

I just finished reading “IPv6 for Enterprise Networks”, published by Cisco Press.   All I can say is that unless you have the hots for IP protocol discussions, this book will not rock your world.   It’s not that it is a poorly written book, it’s just that I don’t find IPv6 to be exciting.   That being said, the authors do a very good job in covering the material.

As is typical of tech books, we start with the obligatory history lesson.  Why should we transition to IPv6?  Simple, we are running out of IPv4 addresses.  Lesson over.  There is more to it in the book, but let’s be real here:  The largest driver is the lack of IPv4 addresses.

With that chapter out of the way, the book covers the basics of network design.  This is a chapter that appears in a number of Cisco Press books.  It’s a good reinforcement of network design principles that we should all do well to remember.

Now that two basic chapters are out of the way, the authors delve into IPv6 itself, how it is different from IPv4, and how to get from here to there.  This is where the book shines.  It’s a great reference for making the transition from IPv4 to IPv6.

As part of making the transition, the authors discuss the pros/cons of many of the various migration strategies such as running a dual protocol stack, running a hybrid network, and more as they relate to the different types of networks (campus, branch, data center, and so on).  It should be noted that each network type has its own chapter.  There is simply too much information that the readers need to be aware of that it would be a disservice to cover them together.

The authors simply could have ended the book there, but that would have made for incomplete book in my opinion.  Thankfully, they kept going and included a chapter on managing an IPv6 network.  While much remains the same, there are differences that may arise that readers should be aware of.  In some cases, it’s just how to enable the monitoring/reporting capabilities of the equipment.  In other cases, IPv6 just handles things differently.

As with most Cisco books, there are plenty of screen shots, command lines, and such given that the reader should be able to copy from to get from point A to point B.  I like this.  Far too many books out there have too few examples.

The last item covered turns out to be my favorite: setting up a lab.  While it is not a monkey script type of chapter (type this, click this) it still gives the reader enough detailed information to be successful.  Personally, I think that if you need a monkey script, then maybe this is one area where you shouldn’t be working.  What really surprised me in this chapter was the inclusion of screenshots from an ESXi host showing how to configure it for IPv6.  Talk about timely and relevant.

Would I recommend this book?  Yes.  While not exactly a page turner for most people (again, we are talking IPv6 here), it is a very good reference guide for making the transition from IPv4 to IPv6.

Book Review: PKI Uncovered, Certificate-based Security Solutions for Next-Generation Networks

How do you rate/review a technical book?    I could go on and on about different methodologies, but basically, I think a technical book is good if I can read it without having to take a ton of breaks, if I walk away with an understanding of the technology, and if it meets the needs of why I read it in the first place.

What makes me take breaks?  Really dry, super-down-in-the-weeds writing.  I am not a PhD candidate, nor do I live for reading IEEE RFCs.  It’s been said that if you want to write for the masses, it has to be at an 8^th grade level  (I may be wrong, it could be 6^th or 10^th grade).    Techies are generally not “the masses”, but we still don’t want to be bored.   Nor do we want to see if you can use every word in the dictionary that has more than six syllables.

Even when writing at a level that the masses can follow, a good technical writer still needs to be able to impart the desired information in such a way that it can be retained and be of value.   Good writers provide clear examples, use analogies when appropriate, and know when enough is enough.

One could argue that if I end up with an understanding of the technology, then it is a good book regardless of how hard it was to read.   But since this my blog and I am writing the review, my rules win.

Now on to the review…

I just finished reading PKI Uncovered: Certificate-Based Security Solutions for Next-Generation Networks from Cisco Press.  All-in-all, it’s a decent book.  Just for grins, I read the intro/preface to see who was the intended target audience and I think it misfired in that sense.  It’s not technical enough for the die-hard techies (thankfully – see above about taking breaks) and it’s too technical for the C-level (and other managerial types) it listed.

This book follows a traditional chapter layout approach: theory, examples, troubleshooting, and integration with other products.

The first chapter is a refresh on cryptography.  It explains what it is, characteristics, and the major components.  I would have liked more info in this chapter, but it really is just meant to be a quick refresh before delving into PKI.

The next few chapters focus on components of a public key infrastructure, how to set it up, troubleshooting, and design.

The final chapters deal with integrating PKI with other Cisco technologies/product such as VPNs, Unified Communications, and such.  As mentioned on the back cover, the book “offers specific, detailed guidance on using PKI with Cisco ..” products and it does not disappoint.

So what did I like about this book?  I really liked the fact that this book has plenty of examples and screen shots.  Being Cisco-centric, this book does a great job of explaining how to setup PKI on Cisco gear.  There is also a very good chapter on how to troubleshoot your public key infrastructure.  The authors provide numerous process flow charts, log parsing examples, and more to help troubleshoot a technology that can be very cryptic (no pun intended) to figure out.  If you are a Cisco shop, consider certain aspects of this book to be like a cookbook: follow the examples shown, you should end up with a working public key infrastructure.

This is also the book’s downside.  Once you get past the first few chapters, this book is heavily Cisco focused. This isn’t a problem if you know that before purchasing.  After all, it is a Cisco Press book.  I’ve only read about 10 Cisco Press books and I read them because I wanted to know about Cisco product.  And to be fair, the back cover does state that the book is for “Cisco customers”.

Another positive quality of this book is that it provides some very good design principles, such as having multiple/redundant certificate servers (in the proper hierarchy).  Too many times I’ve seen tech books provide designs that have many built-in single points of failure.  This isn’t one of those books.

In my opinion, there are only two areas for improvement: writing style and technical depth.  The writing style is dry.  If you’ve read some of my other blog posts, you will undoubtedly have noticed that I’m very informal most of the time.  I also like to inject some humor into my writings every now and then.  That being said, this book could use some could use some lightening up.

As for technical depth, I would have liked a bit more on just a few topics.  Not super-techie, but a bit more.  For example, the book mentions Diffie-Hellman but doesn’t get into the workings of it.  Same can be said for a few other items.  I figure if you are going to mention something, then do it justice and not just cover it in a line or two.  I would hazard a guess that D-H isn’t discussed in much detail because it really isn’t germane to the book’s topic.  For those topics that are germane, the authors do a good job.  Deep enough, but not so deep as to put the average techie to sleep.

So would I recommend this book?  If you are a Cisco shop looking to implement PKI, then most definitely.   If you are not a Cisco shop, then half of this book may not be of value.  For theory and principles, I think you would see value in it.  It’s a judgment call at this point.  As for myself, I would consider this book a good buy just for the first few chapters.  The rest of it is bonus material.

Guest Post on “Define the Cloud”

I haven’t posted anything in a while, but not because I have been lazy…well, maybe a little bit, but the main reason is that I have been working on a guest post over at DefinetheCloud.net.   It’s a good site with a lot of great technical info.  A direct link to my post can be had here. Enjoy the read.

 

Use Cases for Cisco UCS Network Isolation

Based on my last post, a couple of people have emailed me asking, “what is the value of keeping UCS links alive when the network has gone down?”  The answer is: It Depends.  It depends on your applications and environment.  In my case, I have a number of multi-tiered apps that are session oriented, batch processors, etc.

The easiest use case to describe involves batch processing.  We have a few applications that do batch processing late at night.  It just so happens that “late at night” is also the window for performing network maintenance.  When the two bump (batch jobs and maintenance), we either reschedule something (batch or maintenance), take down the application, or move forward and hope nothing goes awry.  Having these applications in UCS and taking advantage of the configuration in my previous post  means I can do network maintenance without having to reschedule batch jobs, or take down the application.

I could probably achieve similar functionality outside of UCS by having a complex setup that makes use of multiple switches and running NIC teaming drivers at the o/s level. However, some of my servers are using all of their physical NICs for different uses, with different IP addresses.  In these cases, teaming drivers may add unnecessary complexity.  Not to mention that the premise of this use case is the ability to do network maintenance.  Any way to avoid relying on the network is a plus in my book in regards to this use case.

Now let’s consider session oriented applications.  In our case, we have a multi-tiered app that requires that open sessions are maintained from one tier to the next.  If there is a hiccup in the connection, the session closes and the app has to be restarted.  Typically, this means rebooting.  Fabric failover prevents the session from closing so the app keeps running.  In this particular case, UCS isolation would prevent this app from doing any work since no clients will be able get to it.  Where it helps us is in restoring service faster when the network comes back due to removing the need for a reboot.

I am going to guess that this can be done with other vendor’s blade systems, but with additional equipment.  What I mean is that with other blade systems, the unit of measure is the chassis.  You can probably configure the internal switches to pass traffic from one blade to another without having to go to another set of switches.  But if you need a blade in chassis A to talk to a blade in chassis B, you will probably need to involve an additional switch, or two, mounted either Top-of-Rack or End-of-Row.  In the case of UCS, the unit of measure is the fabric.  Any blade can communicate with any other blade, provided they are in the same VLAN and assuming EHV mode.  Switch mode may offer more features, but I am not versed in it.

I hope this post answers your questions.  I am still thinking over the possibilities that UCS isolation can bring to the table.  BTW, I made up the term “UCS isolation”.  If anyone has an official term, or one that better describes the situation, please let me know.