Doing Infrastucture-as-Code (IaC) with Ansible has given me a headache – so I’ve recently been playing around with Terraform as an alternative to Ansible for certain tasks that require Cloud IaaS interactions.
The goal of this blog post is to build an HA-VPN solution between GCP and an on-premises Cisco IOS-XE device (CSR) using Terraform. BGP will be established over the VPN in order to exchange routes dynamically. GCE compute instances will be deployed in GCP for testing connectivity over the VPN.
Ansible, Nornir, and other automation frameworks are excellent for generating and deploying configurations in an automated fashion. In Ansible, you can run a playbook, loop through hosts in your inventory file, and deploy configurations with host-specific information by leveraging host_vars and group_vars. Unfortunately, as your automation environment starts to grow and become more critical, you’ll find that managing inventory files and host variables in multiple tools becomes cumbersome and prone to errors. Is ServiceNow correct or Ansible? Is SolarWinds correct or Cloud Vision Portal? Does my Ansible inventory include all of my Data Center switches or did we add any new ones since I last executed this playbook? Was this spreadsheet ever merged with our IPAM, and which is accurate? Why is my production switch configured for a VLAN not documented anywhere else? Inconsistencies in critical data like this is a thorn in an engineers life – causing issues, wasting time and resources, and resulting in inefficiencies by requiring duplicate manually-entered data across disparate systems. Enter NetBox.
We often compare ourselves to others around us. We are impressed with the skills others possess, the content others produce, the appearances others maintain, the successes others have achieved, the feats others have conquered. This constant comparison can lead to melancholic states of ambivalence, and sometimes depression due to the artificial expectations of who we think we should be. Society celebrates particular definitions of success, revolving around money, status, and work ethic. We could argue what is or is not wrong with such a desire for this prescribed success – but we’d be wasting our time. What is important to discuss are the essential components of success, measured by an individual and not others. What is essential in your life, in your work, in your short existence here on this planet? What may seem like a simple question can lead to a revelation.
Matt D’Avella, director of Minimalism, recently interviewed Greg McKeown, author of Essentialism: The Disciplined Pursuit of Less. Greg cuts straight into the heart of a problem people are dealing with in a society of constant comparison and artificially high tenets of success. “We’re busy because other people are busy,” he proclaims. He’s absolutely right. When asked how you’re doing, most people respond with “busy.” It’s my knee-jerk response as well, because it’s true. As a worker in the tech industry, expectations are high. I find myself sacrificing my nights and weekends to sharpen my skills or learn new ones, preparing content for the following week’s meetings, wittling away at project tasks with approaching deadlines, conceptualizing ideas for future client work, supporting after-hour deployments, and memorizing insignificant bits of information that I hope will be enough to pass another certification exam.
Architecting for the cloud is becoming a highly desired skill set. Working as a consultant, I’m often in situations where clients are overwhelmed with questions about the cloud. How do I migrate my applications? How do I secure everything? How does it integrate with LDAP and DNS? What’s the best way to connect to the cloud? Will I need to rewrite my applications? How do I manage costs? While some of these vague questions can be answered with regurgitated marketing material, I feel a sense of duty to understand and explain these concepts at a deeper level. Some clients I work with already have a significant presence in the Cloud. Other clients have various pools of cloud resources and are looking to rationalize or provide a strategy around optimizing the sprawling resources. Because of recent exposure to cloud over the past couple of years, and due to the demand for practical knowledge of cloud architecture, a rigorous education program became an obvious next step for my career. At the beginning of 2019, I made a goal to become an AWS Certified Solutions Architect Associate. As of May 3rd, 2019 – that goal is achieved!
In the previous two blog posts, I covered the concepts of EVPN and shared a detailed configuration example on Arista EOS. In this blog post, I’ll be covering how to automate the deployment of EVPN in a lab environment. After deployment, I want to run validations to make sure my intent is being met. Lastly, I’ll play around with a few scripts to deploy L2 and L3 VXLAN services.
When studying this technology and demonstrating it to clients, I chose to use GNS3 because it’s nice to visualize the topology, easily perform packet captures, and I can share the project file with fellow co-workers using a GNS3 Server. I could have chosen Vagrant for this, but since my topology has 10 vEOS devices, I found the boot time to be too long (although I hear if I use KVM I can boot the nodes in parallel). I chose 8 leafs because it gave me the most flexibility to demonstrate VXLAN Bridging, VLAN Routing, Border Services (such as segmentation or traffic engineering), and so on. You could probably get away with fewer leafs depending on your preference. That said, my topology in GNS3 looks like this:
This is a follow-up to my previous article, Arista BGP EVPN Overiew and Concepts. In the previous article, I discussed some terminologies and behavior of EVPN and the reason why EVPN is valuable in Data Center and Campus networks. Since then, I’ve learned how valuable it is in Service Provider networks as well, but I’ll save that for another day. In this article, I want to walk through a configuration example.
In this topology, we have 2 Spines and 8 Leafs. Each pair of Leafs will form a VXLAN Tunnel Endpoint (VTEP). We will start with the initial configuration of underlay components, such as MLAG and underlay BGP. Next, we’ll configure the EVPN overlay and VTEPs. Lastly, I’ll give an example configuration of L2VXLAN (EVPN Type-2) and L3VXLAN (EVPN Type-5). While most of this configuration will function in production networks, I highly advise first building something out virtually to do testing (GNS3, Vagrant, what-have-you). I won’t be covering special use cases or every possible configuration parameter, but hopefully this is a good start to get you going on to super deep dives.
I’ll have a complete configuration workbook attached at the end of this blog.
Traditionally, Data Centers used lots of Layer 2 links that spanned entire racks, rows, cages, floors, for as far as the eye could see. These large L2 domains were not ideal for a data center, due to the slow convergence, unnecessary broadcasts, and difficulty in administering. To optimize the data center network, we needed to reduce the use of and reliance on layer 2 protocols such as Spanning Tree. The challenge, however, is the fact that Data Centers need Layer 2 stretching from rack to rack, row to row, sometimes from data center to data center, not only for application requirements but also for fault tolerance and workload mobility. Numerous technologies have come forth to battle this limitation, such as TRILL, FabricPath, and VXLAN. Of these three, it is Virtual Extensible LAN (VXLAN) that has seen rapid adoption in modern data centers. (more…)
TREZOR is a hard wallet for securely storing crypto assets such as Bitcoin, Ethereum, and Litecoin. Protection mechanisms like a mnemonic recovery seed, PIN, and encryption passphrase safeguard your assets (private keys) by requiring your physical interaction in order to make transactions.(more…)
A colleague recently asked me if SD-WAN could be leveraged to expedite network integration as a result of a merger or acquisition. His thoughts were that this could potentially provide a means to securely integration networks in a short amount of time. At first I thought this made no sense — SD-WAN is not related to this challenge whatsoever. However, the idea stuck in my head like a bad catchy tune. I started thinking… maybe in certain circumstances this could work? This post is a collection of some ideas I’ve been brewing with respect to the secure and timely integration of disparate networks using over-the-counter SD-WAN.(more…)