In this post, we pull back the curtain on this new NXOS EVPN Hybrid mode and understand how it enables interoperability with Asymmetric VTEPs.
Cisco gave this a fancy name - EVPN Hybrid mode. Or you know, maybe just call it Asymmetric IRB? Because that's what it is behind the scenes.
In this post, we'll start designing the building blocks for our data center deployment with Juniper Apstra. We'll look at how to design a rack.
Designing a rack is a fairly involved process. To be completely thorough, we're going to define new logical devices, create interface maps for these and then put it all together to build a rack. Naturally, some of these terms (logical devices, interface maps and so on) are Apstra specific - not to worry, we'll break it all down and understand what these are and how they are used.
Before we dive into this, I'd like to talk about why Apstra does things this way and what the methodology is. Why build these abstracted models? Why racks?
When you're building out a data center (physically), you'd know that there are a lot of things that simply repeat. Racks are usually identical - or at best you have a few types of racks servicing specific things, and those types of racks repeat. This can include how many leafs per rack, the redundancy model is usually common across the organization, how many servers and so on. You're typically buying identical physical racks as well (like a 42RU rack) and so on.
With this post, we kick off a new series based on Juniper Apstra. This post serves as an introduction to Apstra - we'll look at what a true IBN system is, how relational and graph databases are different (and why graph databases are ideal for network infrastructure), concluding with some general workflows in Apstra.
It's that time again - time for a new series! And I am really excited for this one. I am going to be kicking off a Juniper Apstra series with this first post. This post will look at what Intent Based Networking truly is, and what an Intent Based Networking System (IBNS) looks like.
We'll then take a bit of a detour and talk about databases - I felt it was important to (at minimum) gain a basic understanding of relational and graph databases and why one is better suited than the other for network infrastructure. Graph databases form a crucial pillar of Apstra.
Finally, we'll close this out by looking at some generic workflows within Apstra - I've broken this down into simple, high level flows without going into too much detail. Not to worry, the details will come in subsequent posts.
Let's get started!
Disclaimer
As a disclaimer, I'd like to say that a lot of what I've written about IBN and IBN systems here, comes from reading papers and book(s) written by the fantastic Jeff Doyle. There is no intent to plagiarize his work.
In this post, we deploy a multivendor EVPN L2 overlay fabric, with BGP in the underlay as well. The entire fabric deployment is automated with Ansible, and Containerlab is used to define and deploy the actual topology.
This post continues to build and showcase the power of containerlab. In this post, we will create a multivendor EVPN topology for L2 overlays. The vendors included are Arista (vEOS), Juniper (vQFX), Cumulus (Cumulus VX) and Cisco (N9Kv). Every piece of software used here is free (some might be behind a login, so you'll have to register to get access to image downloads).
The topology is as follows:
In this post, we look at BGP on Junos OS and a typical BGP configuration for the underlay, for a 3-stage Clos fabric. We also introduce BGP unnumbered, which is a great way of building the underlay, without the need of any IP addressing.
The goal of these introductory Junos posts is to get familiar with some basic configuration for commonly used protocols, since it may be a bit of a transition if you're coming from the Cisco/Arista world. BGP is a big one, especially on the Data Center front - it is most often used as the underlay and overlay (for EVPN). To that end, it is extremely important to understand how to configure and process BGP on Junos OS.
We're going to be working with the following topology for this post:
This is a typical 3-stage Clos design, with T0 being the leaf layer and T1 being the spine layer.
In this post, we take an introductory look at the operating system used in Juniper platforms, called Junos OS. This post serves as an introduction to the CLI. We also cover basic bridging.
As a new user of the Junos OS, I thought I'd take this opportunity to blog about what I generally start with when learning a new platform/OS. It's important to understand the basics before moving onto the more complicated technologies. For me, the basics have always included L2 protocols like STP, some form of link aggregation (LAG), at least one IGP, and then finally, understand the tools available to troubleshoot a problem on the platform. Naturally, you also need to get comfortable with navigating the CLI.
To that end, here's the topology that we'll be using for this post. The devices in use are Juniper Networks vQFXs.
In this post, we look at how Containerlab can be used to quickly spin up vQFX topologies for network validation and testing. We'll walk through the entire process - how to build docker images from vQFX images, what happens behind the scenes when bringing these containers up and how to build/verify your topology.
Containerlab is an open source, network validation/testing platform that allows you to easily spin up network labs and manage end to end lab life cycle. It supports several network operating systems, across many vendors. As of this writing, it supports Nokia SR Linux, Juniper cRPD, Cumulus VX, Arista cEOS. Outside of these natively containerized operating systems, it also supports VM based devcies like Junipers vQFX and vMX, Nexus 9000v, IOS XRv, Arista vEOS and so on.
More information can be found on their homepage - https://containerlab.srlinux.dev/
In this post, we look at why BSR and Auto-RP do not work with a SD-Access fabric.
This is the topology that we'll be working with for this blog post:
In this post, we look at how an ARP packet flows within a SD-Access fabric.
This probably should have been one of my first posts for SDA but here we are. I've recently come to realize that there is a lot of misconception about how ARP works within the SDA solution - the defacto answer appears to be that it is a part of BUM traffic (broadcast, unknown unicast, multicast), and thus, it will be flooded (implying that there is a dependency on some form of replication, either head-end or via an underlay multicast infrastructure).
This is not true and it's time to bust that myth! We will continue to use the same topology, only this time, Host1 and Host2 are part of the same subnet (192.2.11.0/24) and the same VN - Corp_VN.
In this post, we take a detailed look at the L2 handoff feature in Cisco's SD-Access.
Fair warning - this is going to be a long, long post. Get yourself some coffee because you're going to be here for a while!
We're going to continue working with the following topology for this post, with a legacy network added to the existing infrastructure:
