Hello loyal blog readers. Over the last few weeks I have been busy working on a network assessment for one of our fantastic customers. One of the areas we look at when assessing a customer’s network is how they are protecting/restricting access to the management plane of their network infrastructure.
This blog follows on from my last post and continues the discussion on how to integrate a single/pair of SD-WAN routers into our existing branch site topology. If you missed that last blog, then you can check it out here. Don’t worry I’ll be right here waiting for you.
In this edition of our SD-WAN series I’m going to take a step away from our lab environment and attempt to address a question I get a lot from our customers. “How do we integrate a SD-WAN router or pair of SD-WAN routers into our current environment?” Well the answer I’m afraid is the networking consultants classic line of “It depends”. And it really does, Cisco’s SD-WAN solution was created by engineers with a background in routing and this routing foundation really gives us a lot of flexibility when positioning our SD-WAN routers into our existing environment.
In my last post we looked at the steps that a vEdge goes through to bring up its control plane connections and authenticate itself onto the fabric. In this post we will follow on from where we left off and see how we use these control plane connections to exchange topology information, WAN policies and security keys via OMP.
Hello, my loyal blog post readers, in this my third installment of our SD-WAN series I am going to walk you through how our vEdge router locates, communicates and authenticates itself onto our SD-WAN fabric. Along the way we will take a look at a few packets captures and command line output to see what is going on under the hood.
In my last post in the series I introduced you to the four architectural components that control and enable our SD-WAN fabric. In that post I had promised that in our next installment we would take a closer look at our fabric bring up sequence, but if you will indulge me I would like to hold off on that topic for the next post. In its place I would like to use this post to introduce you to the lab environment that I have built for this series and take you through the process of deploying and registering a virtual vEdge router into our lab.
Over the past year I have been fortunate enough to work on several Cisco SD-WAN (formally Viptela) deployments. These projects have ranged from small three or four site implementations here in the bay area, right through to large scale international rollouts incorporating hundreds of sites spread-out across the globe with regional POPs providing branch services and backbone connectivity.
Last year, the hot topic taking over the IT space was Software Defined Wide Area Network, or SD-WAN. It simplifies WAN management, connects enterprise networks, and provides aggregation of WAN bandwidth, centralized control and policy enforcement, and visibility into network traffic.
Happy New Year loyal LP blog readers, and what a start to the year we have had. Unless you have had your head in the sand for the last week you cannot help but have heard all the buzz around the latest two high profile security vulnerabilities to hit our networks. I am of course referring to the infamous Spectre and Meltdown flaws. Cue dramatic music “Dun Dun Duuuun!!!!”
I have recently been working with a customer on designing and building out a new Data Center. This task is something that is not as common as it once was, with many of our customers adopting a cloud first methodology (AWS, Azure etc.) when it comes time for a DC refresh. Since it’s a been a while since I have dived into DC technology I figured it was about time that I take another look at Cisco SDN data center offering ACI. Below are some notes that I have made while researching this solution.
Subscribe to the informative Newsletter to be Notified Updates in the Technology world.