Day One: Deploying Basic QoS

I've always found that customers with whom I've worked have found QoS (and Junos CoS) to be one of the trickiest areas to understand and to implement well. It is probably one of the most changed aspects of each new Juniper Networks platform, so it can be challenging to follow the changes and variations, even for an employee. I knew that Miguel and Peter were writing a book on the subject that covered it in depth from a completely vendor agnostic perspective. With this book, I hoped to provide a more high level approach to get people to understand the steps to build a simple but functional CoS configuration in Junos.

This book is for Network Engineers and Architects who are new to QoS and/or new to Junos. It provides them with the basic tools and an explanation of what those tools are for. Equally, it is a useful high level explanation for anyone who may have inherited a network and wants to understand how the existing CoS should behave.

The reader should understand what behaviours they are trying to achieve and what tools are available to them to implement those desired behaviours.

I hope that the reader will gain an understanding of what QoS can and can't do, what are the functions of QoS in general and the Junos operating system's implementation in particular. I would also hope that the reader understands more clearly the generic aspects of Juniper Networks hardware architecture and how that impacts upon the QoS implementation. Ultimately, I hope that they go away and try this out in their labs and use the templates and examples to build a CoS configuration that enables them to operate their own networks more efficiently, offer new and innovative services and provide a great customer experience for their users.

Without question, once you've read this book there should be more questions in your mind :-) Many of the answers to those questions are likely to be in Miguel Barreiros and Peter Lundqvist's book "QoS Enabled Networks: Tools and Foundations" published by John Wiley and Sons. They take a much deeper look into many of the issues upon which I've merely touched.

I love to learn more "stuff". I work with an amazing group of people who are so smart and dedicated and by working with them, I am inspired to improve myself. I am very lucky to have been given the opportunity to expand into new technologies and to move outside my areas of traditional expertise while remaining at Juniper. I find being slightly uncomfortable or slightly out of your depth is a great way to avoid stagnation. Finding people who are better or stronger or smarter than you are and being able to learn from them is a fantastic way to learn and I'm always able to do that in my job here at Juniper.

Hmm, that's tricky. I tend to be hypercritical of my own work because there's nothing there I don't know. I guess if there's one tip that I use over and over with customers, it's to use behaviour names, not application names for forwarding-classes :-) It seems like a trivial little point, but it is one of those things that can cause (or save) huge confusion later on for those maintaining the configuration.