Archive

Archive for the ‘cisco’ Category

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 30th. 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 30th http://ow.ly/aBv08.

 

.

Advertisements
Categories: cisco, VMware Tags: ,

Book Review: IPv6 for Enterprise Networks

April 27, 2011 Leave a comment

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 8th grade level  (I may be wrong, it could be 6th or 10th 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.

Categories: Book Reviews, cisco Tags: ,

Guest Post on “Define the Cloud”

December 8, 2010 Leave a comment

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.

 

Categories: cisco Tags: ,

Use Cases for Cisco UCS Network Isolation

October 4, 2010 Leave a comment

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.

Categories: cisco, UCS Tags: , ,

Can UCS Survive a Network Outage?

September 29, 2010 1 comment

Part of our UCS implementation involved the use of Cisco Advanced Services (AS) to help with the initial configuration and testing.  Do to our integration issues, time ran out and we never completed some items related to our implementation plan.  AS was back out this week for a few days in order to complete their portion of the plan.    Due to timing, we worked with a different AS engineer this time.  He performed a health-check of our UCS environment and suggested a vSphere configuration change to help improve performance.

Before I get into what we changed, let me give a quick background on our vSphere configuration.  We are using the B250-M2 blade with a single Palo adapter.  We are not taking advantage of the advanced vNIC capabilities of the Palo adapter.  What I mean by that is that we are not assigning a vNIC to each guest and using dVswitches.  Instead, we are presenting two vNICs for the Service Console, two vNICs for the VMkernel, and two vNICs for virtual machines and using them as we would if we were on a standard rackmount server.  Each vswitch is configured with one vNIC from fabric A, one vNIC from fabric B, and teamed together in an active/active configuration.

Recommended Change: Instead of active/active teaming, set the service console and VMkernel ports to active/standby.  When doing this, ensure that the active NICs are all on the same fabric interconnect.  This will keep service console/VMkernel traffic from having to hit our northbound switches and keep the traffic isolated to a single fabric interconnect.

.

Here is where it gets interesting.

Once this was done, possibilities came to mind and I asked the $64,000 question.  “Is there a way to keep everything in UCS up and running properly in the event we lose all our northbound links”?  It’s was more of a theoretical question, but we spent the next 6hrs working on it anyway.  🙂

Disclaimer: not all of what you are about to read is fully tested.  This was a theoretical exercise that we didn’t finish testing due to time constraints.  We did test this with two hosts on the same subnet and it worked as theorized.

Here’s what we came up with:

First of all, when UCS loses its northbound links it can behave in two ways.  Via the Network Control Policy – see screen shot below  – the ports can be marked either “link-down” or “warning”.  When northbound ports are marked” link-down”, the various vNICs presented to the blades go down.   This will kick in fabric failover as well if enabled at the vNIC level.  If you are not using the Fabric Failover feature on a particular vNIC, you can achieve the same functionality by running the NIC Teaming drivers at the operating system level.   We are using NIC Teaming at the vswitch level in vSphere and Fabric Failover for bare metal operating systems.

Setting the Network Control Policy to “warning” keeps the ports alive as far as the blades are concerned and no failovers take place.  The beauty of this policy is that it can be applied on a per vNIC basis so you can cherry pick which vNIC is affected by which policy (Link-down or warning).  Using a combination of the Network Control Policy settings and vswitch configurations, it’s possible to keep workloads on UCS up and running, with all servers (virtual or otherwise) communicating without having any external connectivity.  This could be used to prevent massive outages, boot storms due to outages, etc.  In our case, since the bulk of our data center will be on UCS, it basically prevents me from having to restart my datacenter in event of a massive network switch outage.

Here is a table detailing our vSphere switch configuration:

Port Group Service Console NIC1 Service Console NIC2 VMkernel NIC1 VMkernel NIC2 Virtual Machine NIC1 Virtual Machine NIC2
Fabric A B A B A B
Teaming Config Active Standby Active Standby Active Active
Network Control Policy (in UCS) Link-Down Warning Link-Down Warning Link-Down Warning
Network Failover Detection (at vSwitch level) Link Status Only Link Status Only Link Status Only Link Status Only Link Status Only Link Status Only

As far as bare metal blades, go:

NIC1 NIC2
Fabric A B
Teaming Config Active Active or Standby (depends on app)
Network Control Policy (in UCS) Link-Down Warning

Digression: This looks like we are heavily loading up Fabric A, which is true from an overall placement point of view.  However, most of our workloads are in vm, which is configured for active/active, thus providing some semblance of load balancing.  We could go active/active for bare metal blades since the operative feature for them is the Network Control Policy.  With vSphere, we are trying to keep the Service Console and VMkernel vNICs operating on the same fabric interconnects in order to reduce northbound traffic.  Not so with bare metal systems.

Back on track: As previously stated (before tables),   what all this does in affect is to force all my blade traffic onto a single fabric interconnect in case I lose ALL my northbound links.  Since the ports on fabric B are not marked “link-down”, the blades do not see any network issues and continue communicating normally.

.

And now the “BUT”: But this won’t work completely in my environment due to the fact that I am connected to two disjointed L2 networks.  See Brad Hedlund’s blog and The Unified Computing blog for more details.  In order for this to completely work, I will need to put in a software router of some sort to span the two different networks (VLANS in this case).

.

So what do you think?  Anyone out there with a lab that can fully test this?  If so, I would interested in seeing your results.

.

My Thoughts on Our Cisco UCS Sales Experience

August 31, 2010 2 comments

This is a topic that when I think about it, I jump around in my head from subtopic to subtopic.  To make things easier on myself, I am going to write a bunch of disjointed paragraphs and tie them together in the end.

Disjoint #1

I’ve never worked on Cisco gear in the past.  Everywhere I worked where I had access to network/server equipment, Cisco was not a technology provider.  I don’t know why, other than I’ve heard Cisco had the priciest gear on the market.  I’ve also heard/read that while Cisco is #1 in the networking gear market, their products are not necessarily #1 in performance, capacity, etc.  Throw in the perception of the 800lb gorilla and you get a lot of negative commentary out there.

Disjoint #2

When I was 19, I started my career in the technology field as a bench tech for a local consumer electronics store.  The owner (Ralph) was a man wise beyond his years. He saw something in me and decided to take me under his wing, but because I was 19, I did not understand/appreciate the opportunity that he was bestowing upon me.

While I learned some of the various technical aspects of running a small business, I did not do so well on the human side of it.  I was a brash, cocky 19yr old who thought he could take over the world.  However, there is one thing Ralph said that I remember very well and that is, “If no one has any problems, how will they ever find out what wonderful customer service we have”.

It’s not that he wanted people to have problems with the equipment they purchased.  He knew that by selling thousands of answering machines, telephones, T.Vs, computer, etc there would be some issues at some point and he felt that he  should do his best to make amends for it.

Ralph truly believed in customer service and would go out of his way to ensure that all customers left feeling like they had been taken care of extremely well.  If there was poster child for exemplary customer service, it would be Ralph.

Disjoint #3

A number of vendors with broad product lines have somehow decided that the SMB market does not need robust, highly available (maybe even fault tolerant) equipment.  Somehow, company size and revenue have become equated with technical needs.  Perceptions of affordability have also played into this, meaning, if you can’t afford it, then you don’t need it.

Why do I bring this up?  Way back in one of my earlier posts, I mentioned that we had a major piece of equipment fail and received poor customer service from the vendor.  The vendor sales rep kept saying that we bought the wrong equipment.  We didn’t buy the wrong equipment, we bought what we could afford.   In hindsight it wasn’t the equipment that failed us, but the company behind it.

.

Tieing all this together…

When we first started looking at UCS, some folks here had trepidations about doing business with Cisco.  There were preconceived notions of pricing and support.  Cisco was also perceived to have a reputation of abandoning a market where they could not be number one in sales.

I must also admit that there are technical zealots in my organization that only believe in technical specifications.  These folks try to avoid products that don’t “read” the best on paper or have the best results in every performance test.

However, my team diligently worked to overcome these objections one by one and we couldn’t have done it without the exceptional Cisco sales team assigned to us.

In the early part of the sales process, we pretty much only dealt with the Product Sales Specialist (PSS) and her System Engineer (SE).  The rest of the account team entered the picture a month or so later.

These two (PSS and SE) had the patience of Job.   The sales team took copious amounts of time meeting with us to explain how UCS was different from the other blade systems out there and how it could fit into our environment and enable us to achieve our strategic goals.  All questions were answered thoroughly in a timely manner.  Not once did I ever get the feeling that they (Cisco) felt they were wasting their time.

When the infamous HP-sponsored Tolly report (and other competing vendor FUD) came out, Cisco sales took the time to allay our concerns.   As we read and talked about other competing products, not once did they engage in any negative marketing.  Cisco took the high road and stuck to it.

We had phone calls with multiple reference accounts.  We had phone calls with product managers.  We had phone calls with the Unified Computing business unit leaders.   We had phone calls with…you get the idea.  Cisco put in a great amount of effort show us their commitment to be in the server business.

On top of all this, there was no overt pressure to close the sale.  Yes, the sales team asked if they could have the sale.  That’s what they are supposed to do.  But they didn’t act like car salesman by offering a limited duration, once in a lifetime deal.   Instead, they offered a competitive price with no strings attached. (Disjoint #1)

Needless to say, we bought into UCS and have transitioned to the post sales team.  This means we now interact more with our overall account rep and a generic SE rather than the PSS and her SE.  I call our new SE generic because he is not tied to a particular product but represents the entire Cisco product line.  He’s is quite knowledgeable and very helpful in teaching the ways of navigating Cisco sales and support.

So has everything gone perfectly?  No. We’ve had a few defective parts.  If you have read of my other posts, you know that we have had some integration issues.  We’ve also found a few areas of the management system that could use a bit more polish.  So in light of all this, do I regret going with UCS?  Not at all.  I still think it is the best blade system out there and I truly think the UCS architecture is the right way to go.

But with defective parts, integrations issues, etc…”Why do I still like Cisco?” you ask.  For starters, I don’t expect everything to be perfect.  That’s just life in the IT field.

Second, go re-read Disjoint #2.   Cisco must have hired Ralph at some point in time because their support has been phenomenal.    Not only do the pre and post sales teams check in to see how we are doing, any time we run into an issue they ask what Cisco can do to help.  It’s not that they just ask to see if they can help, they actually follow through if we say “yes”.  They are treating us as if we are their most important customer.

Finally, to tie in Disjoint #3, any time we run into something where other vendors would say we purchased the wrong equipment, Cisco owns the issue and asks how they can improve what we already have purchased.   It’s not about “buy this” or “buy that”.  It’s “How can we make it right?”, “What can we do to improve the product/process/experience?”, and “What could we have done differently?”   These are all questions a quality organization asks themselves and their customers.

I don’t know what else I can write about my Cisco sales experience other than to say that it has become my gold standard.  If other vendors read this post, they now know what standard they have to live up to.

To other UCS customers: What was your sale experience like?

.