Review of Enterprise Network Testing: Testing Throughout the Network Lifecycle to Maximize Availability and Performance

I have recently finished reading the new Cisco Press book Enterprise Network Testing: Testing Throughout the Network Lifecycle to Maximize Availability and Performance by Andy Sholomon and Tom Kunath.  Prior to reading this book I will admit that my only experience with network testing has been much more adhoc than the structure they present.


The first section of the book is devoted to learning about the methodologies, tools and types of network testing.  This section discusses how to test networks and where in the lifecycle testing should take place.  It also builds a case for why network testing is important and how to get funding and management support for testing.  If you don't get anything else from this book, that chapter is probably the most important.  Getting budgets for testing capital expenses (lab gear, space, testing tools) and operational expenses (labor, power, cooling) require showing the return on investment that can be had from preventing downtimes later.


The second section of the book looks at how testing of various types has helped real world businesses.  These case studies give the reader a good idea of tangible benefits of network testing.  Most of this section reads more like a business textbook than a technical guide which should help network engineers bridge the gap to the holders of the purse strings.  As network engineers, we have to come out of our geek world and explain to non-geeks why what we do matters to them and to them business matters.


Finally in the last section the authors explore various network projects and the test plans used to verify their operation.  For someone like me with no formal network testing training or experience, this section is an invaluable resource.  The test plan examples are very thorough and will be a great reference for building your on test plans.


I highly recommend this book, although it may not be as sexy as say a book on the Nexus 7000 or FCoTR it provides useful skills for a network engineer to improve their network.

Fun with Port-Channels

This week I did what I've done hundreds of times before.  I configured a new port-channel on a Cisco switch for a server.  In doing so I ended up with two new scenarios that I had never seen before.


The first issue was more of a head scratcher than a production problem, but nonetheless it caused me to stop and wonder why.

PAHA-1A-6509E-SW1#show etherchannel 403 summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      N - not in use, no aggregation
        f - failed to allocate aggregator

        M - not in use, no aggregation due to minimum links not met
        m - not in use, port not aggregated due to minimum links not met
        u - unsuitable for bundling
        d - default port

        w - waiting to be aggregated
Number of channel-groups in use: 34
Number of aggregators:           35

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
403    Po403(SD)       LACP
403    Po403A(SU)      LACP      Gi1/3/45(P)    Gi1/4/14(P)    Gi2/3/45(P)

Last applied Hash Distribution Algorithm: Fixed

Obviously it's not exactly normal to see a port-channel identifier listed twice with one of them having an alphabetic character on the end.  Digging around on the Internet I finally found a document on Cisco's support community that explained the issue. What I had done was create the port-channel with Gi1/3/45 and Gi2/3/45.  Later when the server guys had asked me to add Gi1/4/14 I added it to the port-channel before making the configuration identical.  The document's resolution of shutting down the ports and defaulting the configurations and then recreating them did remove the crazy A from my show commands.

My second issue was that a server connected to a port-channel was disabling one of the NICs saying that it was faulted.  Again defaulting the configurations and recreating the port-channel cleared up that issue.  

The moral of my story is that even though your configuration may be 100% correct, you may have confused IOS so try starting over.