Cisco SD-WAN lab on VIRL complete!

Hello again,

Lately I have been working in my lab to create a Cisco SD-WAN deployment on top of Virtual Internet Routing Lab.  I just completed the deployment and I wanted to share some screenshots and my impressions on the deployment of a Cisco SD-WAN fabric.

I chose to use the feature and device templates as much as possible in my deployment and relied very little on the CLI other than bootstrap operations required for the virtual environment.  I wanted to understand the configuration through the feature templates and get a feel for how they could be used in day to day operations.

I have completed the deployment of 5 sites.  HQ,DR,CHI,SJC, and an Internet/Services POP.  I must say that it has all gone very smoothly.  This is a very elegant solution in many ways.   The more that I work with vManage, the more that I really like the power and visibility it gives you over the fabric.

Below is a view of the main Dashboard which has some great information.  One of my favorites is the aggregated transport health for each transport cloud where you can choose to graph latency, loss, or jitter:

Screen Shot 2018-05-24 at 3.24.13 PM

You can also expand that graph and dig in a bit, you can see that my “biz-internet” provider has more latency than my “mpls” provider:

Screen Shot 2018-05-24 at 3.27.23 PM

 

This is the Map that places your devices based on statically set coordinates or GPS.  You can also visualize the control and data plane connections for each node on this map:

Screen Shot 2018-05-24 at 2.38.18 PM

Below is a view from the device template screen.  I love that device templates are really just a combination of reusable feature template objects.  At one point in the deployment I just copied my existing single site template when I was ready to add a dual site template.  I changed the interface template to add VRRP, changed two variables and boom, done. Deployed the new template to both the primary and secondary router at the site and everything was pushed in about 30 seconds.

Screen Shot 2018-05-24 at 2.39.39 PM

As you go to deploy templates or policies, you can preview the CLI based configuration.  I like the warm/fuzzy I get from seeing the CLI, especially the built-in diff you can display before you deploy a template!  That feedback gives you a lot of confidence that you are getting the results you expect.

Screen Shot 2018-05-24 at 5.00.49 PM

 

 

Next image is the underlying VIRL topology in my lab.  The vManage, vSmarts, and vBond are hosted on esxi, but the rest is running inside of this VIRL simulation.  I am bridging the two together via the FLAT network connection on VIRL.  I really like that I can introduce latency, loss, and jitter on the links in VIRL to simulate brownout conditions on the underlying transport.  This allows me to test the App Aware routing capabilities by introducing problems that take my policy out of threshold.

Screen Shot 2018-05-24 at 2.42.12 PM

The most difficult piece of the whole deployment is dealing with certificates.  Most of that can be automated in a real world deployment and is not a concern.  I was forced to use my own Root Certificate Authority due to the lab setting and I did not have much luck with the recommended TinyCA.  Luckily, I already had a CA deployed on my Domain Controller.  I just used OpenSSL to convert the .p7b cert files to .pem for installation on the vEdge, vSmart, vBond, and vManage.

That is all for now.  I just wanted to share some of what I learned deploying Cisco SD-WAN in my lab.  There is a definitely a ton more to discuss with this solution as I am just now scratching the surface on the policy capabilities.  App Aware Routing, Arbitrary VPN topologies, Service-Insertion for FirePower :).  There is much to test and learn…

Thanks, and see you next time folks!!

The network IS the business.

As my IT career has developed and evolved, my outlook on what I do and why I do it has shifted dramatically.  After some bumps in the road and some deep introspection, I began to understand certain things about the high performers among us.  They may be “Technologists”, but they use technology to drive strategic business results.  I took some time recently to reflect upon what this business focus means for the guys and gals that are most near and dear to my heart, the Network Engineer.

 

This job is difficult and many folks in this line of work tend to focus on the complexity.  As the complexity of the network ramps up, an endless cycle begins and many among us have fallen victim, including myself.

cylce
Do you want an Endless Cylce…

The Network Engineering Trap:

  • focus on the devices
  • focus on the technology
  • focus on performance of the plumbing
  • availability is sacrificed for simplicity
  • flexibility is sacrificed for simplicity
  • services are delivered slowly and usually incomplete
  • challenges are solved with “comfortable” technology vs. the best solution
  • troubleshooting generally results in a band-aid
  • standards are not well-defined
  • culture of fear and mistrust of the business
  • intrinsically reactive
UpandRight
OR to go up and to the right???
The Network Engineer’s Opportunity:
  • understand that the network is the nervous system of a business
  • focus on business value of network services
  • focus on managing the network as a system
  • find feedback loops that provide insights into the business
  • focus on business policy and intent
  • focus on performance of the business
  • standards are defined
  • culture of trust and business enablement
  • intrinsically proactive
  • move from engineer to architect by delivering business value through a defined roadmap/plan!!

Please let me be clear, the technology itself is still very important and is still my passion.  I simply believe it is important to understand that technology does not live in a vacuum.  It exists to support the business, improve business processes, create new revenue streams, and secure the business’ critical data.

Thank you for taking the time to read, until next time…