Monday, November 9, 2015

Spine and Leaf Nodes

This drawing (or one resembling it) seems to keep popping up in Spine and Leaf discussions.  This is an incomplete view of the mechanism of the art.  The Spine and leaf architecture is certainly compelling for a variety of good reasons, not the least of which is a horizontal scaling model that far exceeds more traditional methods of networking.

See  sdxcentral article

The actual story of this design model may actually much more interesting to the network developer.  If this model were the sole construct of the network design, it wouldn't be, necessarily, special.

But if the design model indicated a requirement for redundancy in the Top of Rack (ToR) or if there was a special need physical configuration like a 3-cabinet-wide Logical Rack, those may also be supported by the Spine and Leaf Network model, fairly simply in the guise of a Leaf Node arrangement.

That's not all though.  To scale above the reasonable size of a traditional network, it may be necessary to start thinking about the routing protocol, in order to avoid those pesky all encompassing broadcast domains, delivering what is largely L3 all the way down to the host.

Then topping it off with a healthy dose of the art of the possible, utilizing the routing protocol constructed in the previous model to create a delivery platform for logically isolated networks utilizing VxLAN.  Also, when you get to this size, don't forget to add the Management Network VRF, need a way for those 1000's upon 1000's of physical systems to get back to the monitoring and management.

Hopefully you can recognize the original drawing in the last drawing.  It's still there, but nothing like the switched network of old.

Tuesday, November 3, 2015

Book Review - The Unwritten Laws of Engineering by W.J. King

I was intrigued enough by a twitter conversation about this book that I purchased a copy online.

Over my career, should I have written down things that apply to engineers, I've a feeling that many of the topics in this book would have made it into my notes.

As an example, and relevant to me this very day, "Cultivate the habit of seeking other peoples' opinions and recommendations."

Had I not asked "Jerry" to review some materials I was working on, I would not have known that a partial solution was already completed and those materials were available to me to extend the work of a predecessor(s).  I would have liked to have my name on the total solution, but as it turns out, the solution was expedited by days if not weeks.

The reason this one thing seems so difficult for engineers to understand is that it isn't a sign of weakness or lack of knowledge or how to apply response to problem.  It's more about understanding the background of the issue and acting with more relevant information.

This book is replete with examples such as this one that may well be applied to engineers in all professions on a daily basis.

If you're in the mood for some truths, if not entirely Laws of Engineering, I recommend you pick up this book.