 All right. Hello, everybody. My name is Fred Hsu. I'm a technical marketing engineer at Arista Networks and what I'd like to talk about today is Arista's integration with the Red Hat OpenShift. So our agenda, we're just gonna quickly go over Arista for those of you who may not be familiar with what Arista does. Then we'll go into the problem that we're trying to solve with OpenShift. We'll explain a little bit about what OpenShift STN looks like and then we'll propose the solution for our problem with OpenShift. Then open it up for Q&A after that. So for those of you who are unfamiliar with Arista, we're a data center networking company where we have 15% of market share with a number two data center networking equipment maker right after Cisco. We have over 15 million ports shipped and we have over 26 new products introduced over the last year. If you look here at the Gartner Magic Quadrant, you can see that Gartner's ranked Arista pretty favorably. We're up there on the top right. So we're both the leader and a visionary. What we recently introduced last year was the AnyCloud platform. So that's taking the same operating system that we have on Arista Switches and putting that into a virtual appliance. So this is providing virtualized routing and switching for different applications such as cloud-native applications. That's what we'll be talking about here is how we can integrate the EOS, our virtual EOS system with OpenShift. So the problem we're trying to solve with OpenShift here is when customers are deploying multiple clusters, how do they interconnect the different clusters together? So these clusters could be spread across different clouds. They could be spread across data centers. And what we want to provide is a way for customers to access resources across clusters without necessarily having to go through NAT gateways or change their IP addresses. We want pods and services to be able to use the private IP addressing and the cluster IPs to contact each other. So just to kind of give you a little bit of detail on to how OpenShift's SDN platform works so that we can talk about how we address the problem. If you look at how we have inner pod communication within OpenShift, right now that's done through a VXLAN overlay. So when you're talking from one pod to another pod within the same cluster, that goes over your VXLAN tunnels. Now once you're trying to talk to something outside of your cluster, you go through a tunnel interface. So it's called ton zero on your host and that's how you speak to the outside world. It's going to get NATed or go through an egress and get out to the outside world. So your IP address is going to change as soon as you want to talk to something that's not within your OpenShift cluster. But what we want to do is allow those pods to talk to other OpenShift clusters without changing their IP address. So we want to retain the identity of the source pods IP address as it tries to communicate to another cluster. So this is just a quick kind of high level diagram of what we're putting together here. Here we have two different clouds, AWS and Azure. We have your private data center and we have the US router stitching together these clusters in disparate systems, right? So I have a cluster running in Amazon, I have a cluster running in Microsoft and I have my own private cluster and I want to stitch all these things together. So the first phase of this is we're going to leverage Ansible playbooks to automate and deploy the clusters as well as deploy the routing policies in order to interconnect these clusters. So what you're going to see in the demo is how these Ansible playbooks can be deployed and how we can deploy these configurations automatically allowing these clusters to interoperate. So there's two different playbooks that will be instantiated. The first one is when you're standing up a new cluster, we run a specific playbook that will stand up OpenShift and stand up VEOS. Then once you're going to add a new cluster onto this, then we'll have a different playbook that you run that will take care of all the configuration to interstitch the two different clusters together. So it looks a little bit like this. So we have our two clusters. We have Ansible in the middle orchestrating things both on the OpenShift cluster host and on the VEOS router. To give you a little bit more details to what happens is when we have the Ansible playbook run, it actually inserts rules into both the routing table of the host and the IP tables rules of the host. So we're going to insert a rule that says to reach the second cluster, you're going to go through your VEOS gateway. As well as we're going to insert some rules into the IP tables chain so that we can say, well, for the traffic that's going to our different cluster, we're not going to now. We're going to insert this rule before the net rule takes place. So as I said, what we're going to actually have is a GRE tunnel to connect between the host and the VEOS router. So that's how we're going to get traffic from your hosts to the VEOS router. When the new cluster is routed, we do the modifications that I pointed out on the earlier slide. So we'll modify the routing table and we'll modify the IP tables rules. For your inter-cluster traffic, it's actually going to exit ton zero, go over the GRE interface. For your inter-cluster traffic, you're still going to go over your VXLAN overlays. So the same mechanisms that you use for your pod-to-pod traffic within a cluster, that still remains. For your outbound traffic that's not destined for a remote cluster, that's going to go out your tunnel zero and it's going to get netted just as usual. There's been no modification whatsoever to the standard OpenShift SDN platform in this case. So we'll take you just through a really quick demo. I apologize for the small font here. Oops, let's click this. Let's see if I can get this to play. So this is just running through the Ansible playbook that will connect the two different clusters together and modify all their appropriate rules. So you see that we're going to run the playbook against my inventory of hosts and we want to connect the different clusters. And so we will post this YAML file to GitHub. So if later on you guys want to take a look at what the YAML file looks like, you can see that. So you can see that it's going through the different tasks now. First off, it's adding the different IP routing rules to the different OpenShift hosts to point to the VEOS router for the remote cluster. Then we're modifying the IP tables rules. So we're inserting that rule before the NAT rules so that we don't NAT the traffic. And then finally, we'll make the changes into the VEOS router. So we're leveraging the Ansible module of VEOS to insert rules into the VEOS router to also route the traffic appropriately between the clusters. And we're going to do with this on both sides of the cluster, or on both sides of the connections, so on the local cluster as well as the remote cluster. And when all that's done, now we've got our inner cluster traffic. If pod1 is talking to service B in the other cluster, that is going through without having to NAT or do anything.