The Cisco Best Practices Journey




We are going spend a lot of time together vetting out different configuration options, but before we get started with the configuration, which is the easy part, let’s cover a few design basics. Every successful implementation first starts with a solid plan. Throughout the various modular videos on demand (VODs) that I create and embed within technology relevant or module relevant blogs, we will consistently address the big picture "Why" (Architecture) that leads into our focus areas of the "How" (Design) and the "What" (Implementation).
It is critical that we reference best practices guidelines found in Cisco Validated Designs (CVDs) and other published Cisco best practices documentation in order to first begin with a solid foundation. A true understanding and use of this documentation will provide the necessary guiding principals and will act as a launchpad for eye opening discussion and healthy debate.

The days of working on an existing or new infrastructure without referencing or first creating the proper documentation are over. There is far too great of a reliance from the business on the network to perform consistently and flawlessly to risk unplanned downtime and poor performance resulting from not having invested the proper time for thorough preparation. Configuring a network without a plan doesn't scale and doesn't allow us to adequately consider all dependencies both current and future. Let's be clear, an idea in someones head doesn't equate to a plan. A proper plan is easy to execute upon, convenient to share with others and traditionally is documented in a blueprint like format. When focusing on the design and implementation phases associated with various modules of your infrastructure, consider how solution innovation, vendor relationships, partner project management and partner professional services can play a key role in executing on an agreed upon blueprint that is tried, true and tested.





With CVDs not everyone has to have an expert level certification to understand and implement Cisco best practices. This does not mean that one should forgo engaging a partner for professional services. Partner support services are a great value add to most projects as the experience and exposure of a partner's Engineering staff can't be substituted. I have personally seen countless times where experienced Field Engineers working in conjunction with the Customer Engineering staff were able to provide insight that ultimately led to avoidance of major stumbling blocks. It is important to note that these Engineers also have experience stabilizing the environment should things go wrong. In a worst case scenario, should successful deployment not be possible, these Engineers are expected to have developed the appropriate rollback strategy. It is simple, the more we do the same thing over and over again working with those that are more experienced than ourselves the more we learn and the easier it gets.

There are many ways to accomplish the same goal, but not all ways are created equal. As we design the infrastructure leveraging CVDs as a foundation, we will look to deliver solutions that empower us to realize the following design goals:
  • Ease of deployment 
  • Flexibility and scalability 
  • Resiliency and security 
  • Ease of management 
  • Ensuring that our deployments are advanced technology ready in order to prevent future redesign and to ensure maximum ROI

Let's take 4 minutes to learn more about Cisco Validated Designs and to understand what it means to 'Explore the New Frontier' together.
























Stay tuned for upcoming CVD breakdown blogs. Until then, have fun, learn all you can and look for ways to pay it forward.

Note: If you feel this blog is worthwhile, please share through your preferred social media channels.


Designing the Ultimate Network


Let's focus a little more on design independently before we get into joint design/implementation related blogs. There are many ways to go about designing a network, let alone the 'ultimate' network. Although methods may vary, the intent must not.



Network design has become more complicated than ever with the introduction of:

  • Private/Public Clouds 
  • Infrastructure as a Service (IaaS) 
  • Software as a Service (SaaS)
  • Hybrid Virtual/Physical Infrastructure 
  • Blended Hardware/Software Defined Networking (SDN) 

Most of us are asking the same types of questions:

  • How can I design it quickly?
  • How can I keep it simple?
  • How do I manage it?
  • How do I put it all together?
  • Which platforms should I choose?
  • What are the best practices?
  • How do I leverage what I already have in place?
  • How can I anticipate what the network might need to do in the future so I don't have to revisit my design and deployments?


Due to the many new innovations, some of which require a paradigm shift, it is critical that we don't lose sight of what really matters. The sole purpose of the network is to support the Business in achieving it goals:

  • Increasing revenue
  • Growing profit
  • Reducing both capital and operating costs
  • Expanding into new markets
  • Shortening development life cycles in order to introduce new products/services to market faster than the competition
  • Strengthening partnerships with ecosystem partners
  • Improving customer support and overall customer experience
  • Empowering employees with the right purpose, process and tools to drive greater efficiency and effectiveness
  • Enhancing communication capabilities

The network should be purposefully designed to support current and future application requirements. We don't have a clear view into the future, but we can follow trends to better understand what will be important as this will in turn empower us to make more informed investments allowing us to best prepare for current and future demands. User experience matters when it has a direct impact on levels of efficiency and effectiveness which result in lowered costs and increased profitability for the Business. One must consider how user groups, leveraging applications inside and outside of the private distributed corporate walls, access relevant data.

Many networks come into existence over time by focusing on one business project at a time or due to decisions being made based on perceived business constraints such as:

  • Lack of necessary budget
  • Limited staff or staff expertise
  • Conflicts in project scheduling and project dependencies
  • Layer 8 - Political environment and limiting policies

When designing the network it is important to set business constraints to the side up front and to focus specifically on what we are striving to achieve while never losing site of why this matters to the business. We can always come back to the design and challenge it with business constraints once we have a solid design and reference architecture documented. Approaching the design process in this way will allow us to determine what the Business is sacrificing by making potential changes and will enable us to discuss matters in a manner that is relevant.

In order to make the design opportunity or design challenge, depending on how you look at it, simpler, it is helpful to break the network down into smaller modules.




DATA CENTER CAMPUS BRANCH
Data Center Core Campus Core Branch Core
Data Center Distribution Campus Distribution Branch Distribution
Data Center Access Campus Wired Access Branch Wired Access
Data Center Interconnect Campus Wireless Access  Branch Wireless Access
Data Center WAN Edge Campus WAN Edge Branch WAN Edge
Data Center Internet Edge Campus Internet Edge Branch Internet Edge
Data Center Remote Access
Data Center Services



PUBLIC
Public Cloud IaaS
Public Cloud SaaS

As mentioned, start off with the 'ultimate' envisioned end state and then define the top 3 priorities for each module of the infrastructure:
  • Availability
  • Performance
  • Manageability
  • Flexibility/Adaptability
  • Scalability
  • Security
  • Affordability

Following the right design process and establishing success criteria early on will help us to minimize unexpected expenses, unplanned downtime and unforeseen complications. Although designing the 'ultimate' network might mean different things to different people or organizations, I am sure that there is some commonality in what we are striving to achieve and what the 'ultimate' end state will look like. Let's remember that physical hardware selection should not dictate logical design. Vendor innovations should be looked at as enablers of opportunities for operational impact and therefore these might give shape to the end to end design. Consider following one of the proven design methodlogies when designing the network:





Let's not forget to make our lives simpler by leveraging Cisco Validated Designs (CVDs) as our tested starting point. CVDs provide the foundation for systems design based on common use cases or current engineering system priorities. They incorporate a broad set of technologies, features, and applications to address customer needs. Each one has been comprehensively tested and documented by Cisco engineers to ensure faster, more reliable, and fully predictable deployment. 

Stay tuned for upcoming CVD breakdown blogs by module. Until then, have fun, learn all you can and look for ways to pay it forward.

Note: If you feel this blog is worthwhile, please share through your preferred social media channels.


CLI Style - Expression, Purpose or Both?

As I began screencasting while working behind the command line to build out the modular videos on demand (VODs), I couldn't help but be bothered by the lack of authenticity and the overly scripted nature of my recordings. I was typing out commands fully with no error and never using tab, question mark or abbreviations that are built into the command line interface (CLI) to make life simpler. My original thought was that I would provide you with the cleanest form of output to provide the most professional recording experience. What I quickly realized is that by doing this I was providing you with a disservice.

Typing in commands in this way is not only unrealistic, but extremely inefficient and perhaps in some cases less effective. Save the memorization of CLI syntax for the Cisco written exams (CCNA, CCNP, CCIE Written). We are going to focus on the practical application and I am going to showcase my personal style that you can either borrow from or ignore in favor of what works best for you.

Learning to maneuver behind the CLI is a lot like learning to walk. We often start off crawling trying to figure it out on our own and doing our best to get from point A to point B. Over time we mature, gaining more experience by stumbling and falling down frequently. Eventually we are fortunate enough to learn by watching and getting a little help from others. Before we know it we are not just walking, but rather running and again we trip and fall from time to time which is all part of the process.

For those of us who have been working with Cisco command line for a while, we end up developing a CLI style. Once again, this isn't too different than walking. During my teenage years my walk definitely was a tool for expression. As I got older the strut of my youth changed into more of a limp due to the arthritis setting in. I didn't have to worry about my sagging pants getting in the way any longer as my body did enough of that on its own. The purpose of my walk changed from expression to efficiency. I became a lot more careful of how I would step, where I would step and when I would step as I would proactively look ahead for potential challenges and look back to learn what caused the least pain. I would say that my current CLI style is a lot like this. Rather than showing off my lightning quick typing speed and my ability to memorize, these days I break out the CLI cane, crutches, walker and scooter.


Let me show you what I am talking about:



As you experiment and develop your own CLI style there really isn't a wrong or a right way of entering in command information. It's all about doing what works best and training yourself so that the most efficient, least error prone approach becomes natural. Whether you are walking with a strut, a limp, or running at full speed, learn all you can and look for ways to pay it forward. Stay tuned for upcoming CVD breakdown blogs by module. Until next time when we explore base configuration.

Note: If you feel this blog is worthwhile, please share through your preferred social media channels.



Design Framework & Basic Device Setup

When designing the the ultimate network it is important that we embrace an approach that follows validated best practices and that embodies a certain level of consistency necessary for current and future team collaboration. We are not the only ones that are going to be working on or reviewing our networks and therefore it is essential to ensure that it is easy for us to explain the logic that was leveraged for our design and that went into the deployment of the infrastructure.

Reference http://www.cisco.com/go/cvd as the foundation for developing your design framework.

We must address several areas of our design with purpose. Below is sample of some of the things that need to be considered when simply looking at things from a device configuration perspective: 
  • Naming conventions
  • IP address allocation
  • Port range utilization (router ports, switch access ports and switch trunk ports)
  • VLAN assignment
  • Loopback assignment
  • Base configuration
  • Management policy and framework
  • Overall device security
Let's focus our attention on defining a consistent base configuration that scales to provide simplified and secure management of the solutions within our infrastructure. There are features and services that are common across all devices or devices with a similar role in the infrastructure. The Cisco Validated Design (CVD) documentation does a good job of addressing the best practices associated with the majority of these features and services. Take for example the CVD WAN Module specific documentation which walks us through the following steps:

  1. Configure the device host name. This makes it easy to identify the device.
  2. Configure local login, password, enable passwords and password encryption services.
  3. Acknowledge that HTTPS leverages the enable password.
  4. Configure centralized user authentication. This is optional but highly recommended.
  5. Configure device management protocols such as HTTPS and SSH vs. HTTP and Telnet.
  6. Enable synchronous logging to avoid unnecessary disruptions.
  7. Enable Simple Network Management Protocol (SNMP) to allow the network infrastructure devices to be managed by a Network Management System (NMS).
  8. Add access-list controls to limit the networks that can access your device if operational support is centralized in your network.
  9. Configure a synchronized clock leveraging NTP.
  10. Configure an in-band management interface in the most resilient manner possible by using a Loopback.
  11. Bind the device processes for SNMP, Logging, SSH, PIM, TACACS+, RADIUS and NTP to the loopback interface address.

Let me provide a sample of basic router configuration setup leveraging some of what is covered within the CVD documentation:



As you navigate through the CVD documentation with the goal of defining your design framework, leverage as much of the content as possible to avoid recreating the wheel and navigating into uncharted territory. There will be times when you are required to depart from the CVD path, and in these cases take time to plan your approach carefully leveraging partner services for valuable insight and proven expertise. It's all about developing a design that provides the necessary scalability, flexibility, manageability, resiliency, performance and security to deliver applications to your users and services to your customers in a sustainable and deterministic manner. Stay tuned for upcoming CVD breakdown blogs by module. Until next time when we explore Core Enterprise Switching design and configuration.

Note: If you feel this blog is worthwhile, please share through your preferred social media channels.