EVPN-VXLAN | Layer 3 Gateway | IRB | JUNOS

I often get asked about EVPN Layer 3 gateway options. And more specifically, what are the differences between IRB with Virtual Gateway Address (VGA) and IRB without VGA. There are many different options and configuration knobs available when configuring EVPN L3 gateway. But I’ve focused on the 3 most popular options that I see with my customers in EVPN-VXLAN environments in a centralised model.

Each IRB option can be considered an Anycast gateway solution seeing as duplicate IPs are used across all IRB gateways. However, there are some subtle, yet significant, differences between each option.

Regardless of the transport technology used, whether it be MPLS or VXLAN, a layer 3 gateway is required to route beyond a given segment. I’m only covering the initial configuration required to get up and running. There are many different configuration knobs that are well explained in the following (thanks Luciano):

Comparing Layer 3 Gateway & Virtual Machine Traffic Optimization (VMTO) For EVPN/VXLAN And EVPN/MPLS

EVPN VXLAN Configuration Knobs and Caveats

This Week: Data Center Deployment with EVPN/VXLAN by Deepti Chandra provides in-depth analysis and examples of EVPN-VXLAN. I highly recommend reading this book!

IRB Option 1

Duplicate IP | Unique MAC | No VGA

IRB Option 1

JUNIPER QFX10K | EVPN-VXLAN | EVPN ANYCAST GATEWAY VERIFICATION

This article is the second post in a series that is all about EVPN-VXLAN and Juniper QFX technology. This particular post is focussed specifically on EVPN Anycast Gateway and how to verify control plane and data plane on Juniper QFX10k series switches.

Overview

In my first post, I explained how to verify MAC learning behaviour in a single-homed host scenario. This time we’re going to look at how to verify control plane and data plane when using EVPN Anycast Gateway. As explained in my previous post, verifying and troubleshooting EVPN-VXLAN can be very difficult. Especially when you consider all the various elements that build up the control plane and data plane.

So, what is EVPN Anycast Gateway?

JUNIPER QFX10K | EVPN-VXLAN | MAC LEARNING VERIFICATION | SINGLE-HOMED ENDPOINT

This article is all about EVPN-VXLAN and Juniper QFX technology. I’ve been working with this tech quite a lot over the past few months and figured it would be useful to share some of my experiences. This particular article is probably going to be released in 2 or 3 parts and is focused specifically on the MAC learning process and how to verify behaviour. The first post focuses on a single-homed endpoint connected to the fabric via a single leaf switch. The second part will look at a multihomed endpoint connected via two leaf switches that are utilising the EVPN multihoming feature. And, lastly, the third part will focus on Layer 3 Virtual Gateway at the QFX10k Spine switches. The setup I’m using is based on Juniper vQFX for spine and leaf functions with a vSRX acting as a VR device. I also have a Linux host that is connected to a single leaf switch.

Overview

When verifying and troubleshooting EVPN-VXLAN it can become pretty difficult to figure out exactly how the control plane and data plane are programmed and how to verify behaviours. You’ll find yourself looking at various elements such as the MAC table, EVPN database, EVPN routing table, inet0 routing table, BGP RIB-IN, BGP RIB-OUT, default-switch instance and so on. It can get a little overwhelming when trying to ascertain the significance of all these various components. My objective is to provide a set of verification steps to help make sense of it all.

EVPN-VXLAN INTER-TENANT ROUTING ON JUNIPER QFX / MX

I’ve recently started working on a project focused on EVPN-VXLAN based on Juniper technology. I figured I’d take the opportunity to share some experiences specifically around inter-VXLAN routing. Inter-VXLAN routing can be useful when passing traffic between different tenants. For example, you may have a shared-services tenant that needs to be accessed by a number of different customer tenants whilst not allowing reachability between customer tenants. By enabling inter-VXLAN routing on the MX we can use various route-leaking techniques and policy to provide a technical point of control.

To read the article then please head over to the iNET ZERO blog