the worlds gone mad

The majority of Cisco SD-WAN guides and posts I have found use static routing rather than routing protocols on the transport-side. Static routes are all very well for SD-WAN tunnel traffic but I was wanting to understand how you equate for DIA traffic in a more real-life situation where address ranges are advertised via BGP.

The Cisco documentation about this call it Inter-AS Option B with the use case being to extend LSPs between sites over the one link. As Option B is the only MPLS-VPN method supported by Cisco SD-WAN I wanted to get a better understanding of how it works aswell as see if it could be used to extend multi-VRF prefixes between edge routers and a core switch within the same AS (rather than using Option C with LDP).

This post goes through how to configure MPLS VPN on the service-side of a Cisco SD-WAN edge device, so the south-side towards non-SD-WAN devices. What I am trying to achieve is to advertise the differing SD-WAN VPN (VRF, why Cisco have to call these VPNs beats me) prefixes to a core switch (using a ASR in the lab) directly connected to the SD-WAN router. This could be accomplished using per-VRF interfaces (or sub-interfaces) and BGP peerings, but a neater solution is to pass all the routing information over one the BGP MPLS VPNv4 peering.

Over the years I have built numerous IPsec VPNs on ASAs using crypto maps and an ACL for the interesting traffic. For a simple solution to join small sites with no need for routing these work great and keep the complexity down to a minimum. For more complex environments or cloud connectivity you are probably going to need to use VTIs, this post goes through the process of building VTI VPNs between an ASR and ASA.

The 6th post in the ‘Automate Leaf and Spine Deployment’ series goes through the validation of the fabric once deployment has been completed. A desired state validation file is built from the contents of the variable files and compared against the devices actual state to determine whether the fabric and all the services that run on top of it comply.

The 5th post in the ‘Automate Leaf and Spine Deployment’ series goes through the deployment of the services that run on top of the fabric. These services are grouped into 3 categories, tenant, interface and routing. Services are configured only on the leaf and border switches, the spines have no need for them as they just route the VXLAN encapsulated packets with no knowledge or care of what is within them.

The 4th post in the ‘Automate Leaf and Spine Deployment’ series goes through the creation of the base and fabric config snippets and their deployment to devices. Loopbacks, NVE and intra-fabric interfaces are configured and both the underlay and overlay routing protocol peerings formed leaving the fabric in a state ready for services to be added.

The 3rd post in the ‘Automate Leaf and Spine Deployment’ series goes the through the variables from which the core fabric declaration is made and how this transposes into a dynamic inventory. This uses only the base and fabric roles to create the fabric ready for the service sub-roles (tenant, interface and route) to be deployed on top of the fabric at a later stage.

The 2nd post in the ‘Automate Leaf and Spine Deployment’ series describes process used for validating the variable files format and content. The idea behind this offline pre-validation is to catch any errors in the variable files before device configuration is attempted. Fail fast based on logic instead of failing halfway through a build. It wont catch everything but will eliminate a lot of the needless errors that would break a fabric build.

This series of posts will describe the process of deploying a NXOS Leaf and spine fabric in a declarative manner using Ansible. This came from my project for the IPSpace Building Network Automation Solutions course and was used in part when we were deploying leaf and spine fabrics in our Data Centers. I originally only planned to build tenants and do fabric validation but over time this has morphed into a full blown fabric deployment.