Watch / Tutorial On demand
Overview

About this video

What You'll Learn

  1. Explain how BGP routes traffic between autonomous systems using advertised prefixes.
  2. Configure BIRD to announce a service prefix from servers in multiple metros.
  3. Verify anycast failover with curl, traceroute, and locoping while stopping one node.

Rawkode and Jeremy Tanner introduce BGP, covering autonomous systems, prefixes, anycast routing and CDN failover. They then deploy NGINX across two Equinix Metal metros, configure the BIRD daemon, and verify anycast routing with curl, traceroute and Locoping.

Chapters

Jump to a chapter

  1. 0:00 <Untitled Chapter 1>
  2. 1:55 Introduction & Welcome
  3. 2:24 Guest Introduction (Jeremy Tanner)
  4. 6:10 How Does this Course Work
  5. 9:02 Introduction to BGP: The Problem it Solves
  6. 11:08 Discussing Network Basics (DNS, IPs, Latency)
  7. 11:13 What Problem Does Bgp Actually Solve
  8. 12:09 A Dns Request
  9. 12:51 How Does the Internet Work
  10. 15:51 Latency
  11. 18:02 Why BGP is Needed: Global Scale & CDNs
  12. 20:40 How BGP Routing Works (Autonomous Systems, Prefixes, Hops)
  13. 20:44 How Bgp Works
  14. 21:06 Autonomous System
  15. 22:52 Global IP and Equinix Metal's Role
  16. 23:06 Illustrating BGP Routing with Diagrams
  17. 24:28 Anycast BGP Explained
  18. 25:36 BGP Attacks & Network Reliability (Failover)
  19. 26:50 Bgp Attacks
  20. 27:42 Part 2: Practical Demonstration Setup
  21. 27:45 Deploy Our First Servers
  22. 27:50 Requesting a Global IP (Equinix Metal Console)
  23. 29:24 Deploying Servers in Multiple Metros
  24. 30:51 Preparing Servers (SSH & Software Installation Plan)
  25. 33:51 Configuring Servers: Network Interfaces & Software
  26. 37:48 Enabling BGP on Device & Getting Peer Info (Metadata Service)
  27. 37:49 Metadata Service
  28. 42:13 Configuring & Starting BERT (BGP Daemon)
  29. 42:41 Adding the Roots
  30. 44:36 Configuring NGINX Index Pages (Adding Location Info)
  31. 45:40 Testing BGP Routing with Curl
  32. 46:32 Testing Network Path with Traceroute
  33. 49:02 Testing Routing with Locoping (Third-Party Tool)
  34. 50:48 Testing Failover by Stopping BERT/NGINX
  35. 52:26 Summary of Demonstration & BGP Benefits
  36. 53:24 Conclusion & Preview of Next Session
Transcript

Full transcript

Generated from the English captions. Timestamps jump the player to that moment.

Read the full transcript

1:55 Introduction & Welcome

1:55 Hello, and welcome back to the Rawkode Academy. My name is David Flanagan, although I also go by the hand of Rawkode. Go figure. And today is the launch of our third course at the academy, and we're taking a look at BGP. BGP is a a really cool technology that probably does provide the foundation of scaling your applications to the edge and globally. Alright. For today's first session, we're doing things a little bit different, and we do have a guest. I can't find my mic. There we go. And if you enable that option where you kinda spiral it around and

2:24 Guest Introduction (Jeremy Tanner)

2:35 it goes pulsedly big, but, anyway, that's for another day. Yeah. We're doing things a little bit differently. I'm John Beck's friend and former colleague, Jeremy Tanner. Hey. How's it going? Not bad at all. Good afternoon to you. Good morning to me. Alright. Well, I mean, thank you for joining me today. It's nice that we get to do something together. You know, full disclosure, Jeremy and I worked together at Equinix. So we have done plenty of streams together. We met up recently in Austin, which was awesome. But I was in CD con. So nice to see you again.

3:11 Yeah. Absolutely. I am I'm ready to hear more about about BGP and BGPN and Equinix Medal. I got up Well, I was gonna say got some coffee, but first, I went and looked and I was like, do the thing that everyone needs to do, which is follow Rawkode Academy on LinkedIn. All of the socials. All of the socials. Like, that's where the stream needs to go. But, you know, for so long And then coffee. Yeah. Yeah. For so long, I've always just streamed to YouTube. But I think for course material, I wanna push it a bit broader and wider,

3:47 especially as what I'm saying is I'm having to update some of the older videos, and YouTube really doesn't like it when you have to do that. We're gonna just digress though for the first five minutes. So what I wanna do is just, you know, livestream it to multiple places. We're out on LinkedIn. We're out on Twitter. We're out on YouTube. And then what we'll do is I'm gonna edit this back. I'm gonna stick it on Vimeo, and I'm gonna make it a web available on the new Rawkode Academy website, which will be launching next week. So trying to

4:12 do things a little bit differently as I've done for the last eighteen months and just experiment. And yeah, this is the first course I'm gonna do it with, but it should be good. Alright. Perfect. Back on topic. For anyone who is not familiar with you, can you just give us the TLDR of who is Jeremy Tanner? Excellent. I like motorcycles and mountains, and I have two small copies of myself, but you're probably really looking for, have been helping people understand bare metal and bare metal accessories at Equinix Metal. Inside Equinix, the world's digital infrastructure company, and now,

4:48 based in Austin, Texas. And, yeah, certainly open to questions, meeting new friends, and and today hearing about BGP. Yeah. I mean, I hope you're prepared to slide because I haven't. Uh-oh. Well, here's my first favorite feature of LinkedIn streaming. LinkedIn user says hello there. Hello, LinkedIn user. I'm assuming we don't get that name on the API, but we do have the regulars. We have no hey, no. Russell. Hey, Russell. Another LinkedIn user saying LinkedIn is slow on the uptake. Well, yeah, they don't have username. So I guess that'll come in the future. That's a premium feature.

5:33 Stefan, human. Hello to both. It's all very kind. A good morning from Steve. Hey, Steve. Alright. So people must be wondering. The LinkedIn user is Chris. Well, yes. LinkedIn users, if you are watching, feel free to stick your name and a colon at the start of every message, which is pretend that that's gonna work for today. Know there's too many comment. I'm okay. I'm only gonna show two more comments. We're we're gonna stop BGP now. Please tell us about more cycles. Yeah. We will be getting another stream for that. I I reckon Jeremy could go on for a while. Cool.

6:10 How Does this Course Work

6:10 Alright. How does this course work? Well, much like the other two courses, if you go to the Rawkode Academy, Github page at github.com/rockwoodacademy, there is a courses page. As you'll see, we have our influx DB, our Telco course, and our global reach with BGP. Now, of course, we're going to be spinning up some bare metal for this course so that we can actually use BGP and route traffic to it. So this is not like the other courses where you could just run a container with the software. Unfortunately, BGP requires hardware and other stuff, but it

6:47 is invaluable to learn. So we have with Equinix metal a code here of Rawkode, really difficult to remember. But if you go to the Equinix metal website by clicking the link, you can click get started twice. And there's a coupon code thing here. Let me make that bigger. It's like Rawkode in that box, fill in the rest of your details. No credit card is required, and you'll get $200. I just clicked my browser. Oh, it's alright. You get $200 of credit. So that $200 is going to do you well. I'm just gonna go to the console now.

7:35 We'll get you $200 of credit. I think you can get four hundred hours of compute for that. I think the c three smalls are about 50¢ an hour. Jeremy can correct me if he wishes. So, yeah, four hundred hours for you to experiment with. Yeah. Most recently variable depending on where you are, more in some places, less in others, but more for larger machines, less for smaller, but certainly in that ballpark. Alright. Can't believe I closed that window. See, I I was saying just before we went live, I I I was considering a 3PM coffee. I feel like I made the

8:16 wrong decision by not having that coffee. Well, we're gonna move on. Okay. So step one well, step one is sign up. Use the coupon. Make sure you get those credits. And now today, we're gonna do the first two parts of this course. So we're gonna do a bit of a conversation between Jeremy and I where we talk about what is BGP, how the written works, all the stuff that you kinda need to know before you start deploying it. And then in the latter part of the stream, we'll actually do our first BGP deployment. So we will deploy multiple servers in multiple

8:47 regions. And what we're gonna show you is how the routing works, the latency is kept low, and this is how you scale your application globally or to use that wonderful word of the moment edge or at least as close to the edge as we're gonna get. Alright. Introduction to BGP. Yeah. Just absolute cop out here. Right? Just stick in the Wikipedia definition and then just ask people to read it. I actually read the Wikipedia definition. I was like, that is super complicated. Like, does that really tell people what BGP is? Is that for people that already know

9:02 Introduction to BGP: The Problem it Solves

9:24 BGP, but what primer? Like, for people that don't know BGP, it's just it really I I don't think it's that great. However, what I did know, here's a cool trick. Are you aware of Wikipedia Simple? I assume you are. No. No. I've not run across it. Alright. So you can do Wikipedia. Let's just go to the BGP page. Right? And sometimes you just get all this nonsense and you're like, border gateway protocols, the standardized exterior gateway protocol to send to exchange written blah blah blah blah. Right? Doesn't always help you. Right? Especially when you get into more

9:57 some of the more, like, complicated mathematical or physics topic, which I randomly do because I just get too curious. But you can swap out the language, e n, for simple. And usually, it's not great in this case, but usually, you get a very simplified definition of the thing that you're looking at. That's a cool wee trick. There's also a Scots language one, but I doubt there's a Scots language for BGP. Oh, does it have to be localized into simple? I don't know what I did there. Is that just simple to okay. Oh, yeah. Hold on.

10:36 I replaced too much. So simple counts simple counts as a language Yeah. And just like French, Italian, or Scots. Okay. Well, apparently, Scots doesn't work in. But there is a Scots version. There. Small digression again. I suspect that's why I don't have I'm not joined by people. It's too easy for us to go down another path. But a comment there from Pavan, today I learned Wikipedia is simple. Yeah. It's a cool trick, especially for those more complicated things. Glad I could help. Okay. So rather than I was reading in verbatim that Wikipedia description, people can read it

11:08 Discussing Network Basics (DNS, IPs, Latency)

11:10 if they want. I figured you and I could just talk about what problem does BGP actually solve. Like, people are here because they wanna learn the technology, but they probably wanna learn it because they have a problem to solve. And I figured we could just kind of roughly explain that. And what I've done in this README document is try to in a simple fashion, describe what happens when you request a website on a browser. So maybe we can just kinda go over this so we can add extra flavor details to better on how we feel. Good to go?

11:13 What Problem Does Bgp Actually Solve

11:42 Sure. Cool. So what I've said here is let's consider what happens when a request for a website is made from your machine. This is high level. I know that people get asked this and, like, interview questions, and people have failed it because they didn't talk about electrons and electricity and all that stuff. I guess interview people, they take it too far. I just said you need to do it in three steps. I probably failed the Amazon interview or whoever asked this. But first, we got a DNS request. So when we type in console.equinox.com, Google Com, whatever,

12:09 A Dns Request

12:16 those words really mean nothing to the Internet. What we need to do is the DNS lookup to get some sort of IP address, which is how all the magic of Internet work. Our browser will then send an HTTP request to the IP address, and it uses a host header. I don't know why I included that detail. I mean, it's correct, but, you know, probably not pertinent to this conversation. However, that server will eventually respond back with some HTML or browser renders it, and then you're happy. Alright. Jeremy, how does the Internet work? So the the first thing I would like

12:51 How Does the Internet Work

12:58 so the IP given by the DNS the IP address given by the DNS system, first of all, can be one of multiple IP addresses, but you can't which one is given isn't determined by on any sort of basis. It can be, it can be either at random or semi random, but you're not, I don't think you're segmenting by, by anything there. Additionally, I suppose it's important to say that you need to be able to reach your your DNS server, and your DNS server is in your settings as an IP address. So how do you make the DNS request

13:38 to the DNS server at the DNS' IP address? Well, things just got made up very quickly. Yeah. I think, actually, it before we're this is actually part three of the courses where we're gonna implement our our own globally distributed kind of DNS lookup. We won't go into that in too much detail. But you're right. Your DNS server has an IP address, and we have to route that and answer that as quickly as possible and keep our latency low. So it's a really good use case for BGP. Alright. What waffles I have next? That's me. Oh, yeah. There's a lot of DNS servers.

14:14 Your ISP is gonna bunch have a couple. It's all distributed. It's all cached, all this other stuff. And then I include some latency figures. Alright. These figures I got from wonder network, which is a really cool website I wasn't familiar with, But you can actually add all your own cities, which I thought was nice. You're in Austin. Yep. I'm in Glasgow. I don't know if there'll be a Glasgow. I guess we'll do London. And there we can drop Barcelona. Don't know why I'm going through all this effort just to show our ping times, but you know.

15:08 There we go. So not bad considering, you know, our connections are governed by the laws of physics and the speed of light, a connection latency between our two cities is only a hundred and eighteen milliseconds. Very good. Make can make that error so slightly larger? Know. The monitor is small. I'm not sure what sort of sort of death star readout there is in a Oh, you can right click on it and control and then full screen it if you want. I should have touched that before we went live. But yeah. So I didn't easy mode. That's good. So

15:43 I sent this website just while I was putting stuff together for this course. And it's a really good way to understand the latency between you and your customers. And let's talk about latency. Latency is just the amount of time that is required for all requests to happen. So while the latency of a hundred and eighteen milliseconds seems quite small, if your web page is making tens, hundreds, thousands, tens of thousands of connections to resources, at least when the connection has to be opened, etcetera, It can add up really, really quickly, which is why, you know, if you Google

15:51 Latency

16:18 for why does Australia have slow Internet, it's because all the products that they're using are in San Francisco and Europe, etcetera. So, you know, maybe the I'm sure there are lots of Australian data centers, but we all use products from American companies and and European companies as well. So they notoriously have quite bad speeds with some of our services, which is why we need to decrease that latency. You can see London to New York is only 70. LA and Austin are around that mark. Tokyo and then Sydney. So it just keeps growing again, but it is governed by the law.

16:57 Is that best case or worst case? So so the so a lot of those were maybe, like, IBX to IBX or data center to data center more so than you're going to probably have more hops in there depending on if you're resident on a residential Internet plan or your business or whatever. It's unlikely that you're right in the data center where, where those pages or services are hosted. Yeah. We've not even talked about hops. You know, when we do some trace routes later, we can definitely break that down. But to answer your question, it looks like this website does 30 pings

17:36 to the destination. It displays the average, and then it's got some extra scores for lowest average ping, etcetera. So the details are there if you really, really wanna get into it. What this means that I think, you know, I think what I'm trying to highlight I mean, I wrote the damn doc. I should know what I'm highlighting. But is that if you want if you're building a product that is global scale and that means customers and and and users of your service, then you need to improve the performance of people and the farthest parts from your servers.

18:02 Why BGP is Needed: Global Scale & CDNs

18:12 And that just means deploying to more locations, but not just deploying to more locations is that you then have to be able to route the traffic to those locations when the customers are in those locations. Like, you don't wanna go to a central location and then redirect them, which we used to see a lot in the twenty tens, early '20 tens is that you would go to not gonna say Google. I don't think they ever did this, you know, Yahoo or something. You go to Yahoo.com and then you're redirected to eu.Yahoo.co.uk or whatever like that. And that was all

18:43 just handled that way. So that was a simple way of doing it. BGP is is much nicer solution. Alright. So yeah. Well, that's why we have CDNs. Now I'm assuming anyone watching this course is probably familiar with a CDN. The idea being that, you know, we host static websites as an example on s three bucket or even just NGINX servers, but then we stick something in front of it, like Cloudflare, CloudFront, Fastly. There are others. They cache all of those stuff. Those have their proxies running in many, many locations around the world. And your customers help them instead of your centralized

19:27 server and proven their performance. And how these CDNs work is all BGP. Go figure. The third part no. The fourth part of this course is we will be implementing and building our own CDN. So after today, we'll do our own DNS servers with BGP. We'll build our own CDN with BGP. And the last part of this course will be building our own edge functions, so your own edge Lambda product using BGP as well. Anything you wanna add? I don't think so. The yep. CDN's good. CDN's closer to CDN's closer to user. And, yes, I mean, I ran into this when,

20:14 I think we ran into each other previously in, in Spain during conference time, and I was having really having a really slow time because I was using the VPN that's in California, which is not close to which is not close to Spain at all. And so if I I switched it for the week to to Madrid, all good again. Cool. Alright. The last part of this document before we actually do something interesting with this is just to kinda talk about how BGP work. So when we want to send a request to an IP address, we

20:44 How Bgp Works

20:54 the Internet, the mystical Internet, has to route that traffic for you. What typically happens is your browser makes a request to your ISP. I was in the ISP. There's likely an autonomous system. Autonomous systems are essentially that know how to route traffic within their own network, but they do this based on prefixes. So we got an example here as this router or autonomous system will say, hey. I know all of these prefixes, 123Dot0Slash24, and it keeps the traffic within the autonomous system. If there is a prefix that it doesn't understand, it's going to reach out to its

21:06 Autonomous System

21:35 peers and say, do you know this prefix? And when those peers come back and say, oh, yeah. I I'm responsible for this prefix that will rip the traffic to there, or it may say, oh, I know someone else is responsible for this prefix. And it starts to route the traffic through all of these autonomous system until eventually you get to the server. And what you want is a company which has a very intelligent backbone with a good number of peers where those prefixes could be resolved and as many not as many. And as less or little hops

22:09 as possible because the less hops that you do, the faster or the less the latency will be. And that's where Equinix comes in. Equinix has one of probably the most substantial Internet backbone in the world. I I can't think of another. So and that's because Equinix works with Google, Amazon, Cloudflare, all these other people too, I believe. Don't quote me on that. You can quote Jeremy on that if he agrees, but not I was gonna say, I'm not sure there's anybody that we don't, but partner partner team is standing by. Yeah. Equinix is the Internet. So

22:50 they have a good network for this. So what we're gonna do today is set up a global IP, which just means it's an IP address that Equinix will broadcast to us within all the autonomous systems that they own and peer with, and we should be able to see some traffic. Now I know this is a lot of words, and I decided to do some diagrams to try and show how this works. Now what this diagram assumes is that your application has a EU server, a US server, and an Australian server. And what happens is our clients make requests

23:06 Illustrating BGP Routing with Diagrams

23:22 in The UK and Germany to their ISP. Their ISP either has their own autonomous system or peers with other autonomous systems that are already within the EU because our infrastructure providers such as Equinix Medal is advertising our prefix to these autonomous systems, we get directed we get routed directly to the EU server. And the same works within The US. You can have customers within New York and Los Angeles who go through their own ISP. It's likely there's a ton of systems in New York and Los Angeles, and they can all route to the same US server or maybe you're going

24:03 full hawk here and you have servers on the East Coast and the West Coast, and those will be routed appropriately as well. And then the same happens for Australia. Which is one extra example here is that, you know, Japan, there may not be you may not run any infrastructure in the Japan or China or everything like that, but we still want to see as few hops as possible to get it across for that Australian server. Those diagrams make sense? You happy with that? I think so. The and the the IP address will be the same IP

24:28 Anycast BGP Explained

24:37 for all of like, there's one IP that's then being announced from each announced from each place. Right. Is the same Yeah. Yeah. I should have I should have asked for the diagram. All clients, we can request for eight dot eight dot eight dot eight or one two three four or whatever. But, yeah, you're right. All these clients are using the same IP address to reach different servers around the world. Excuse me. Which is what makes BGP so cool. You don't have to have overly complicated DNS setups. You don't need to have well, in fact, yeah, it would just be DNS

25:13 that you've done this any other way, but that can be rather complex. Multiplexing, multicasting, your BGP are a very clean way to do that. Alright. And and that's what's called Anycast? Yeah. Yeah. Anycast BGP. I I said multiplex, didn't I? Anycast BGP. There we go. How does that go wrong? What happens if so is the are each of the servers themselves, announcing the route to get to them, or is that something that happens at the provider? Or what happens when one of the servers turns off? Well, I mean, we can speak from the Equinix metal perspective, and as we're gonna

25:36 BGP Attacks & Network Reliability (Failover)

26:04 show how that works here. So Oh. Oh, we we we probably should head to the lab, but okay. Well, you know, it's not anybody can just start announcing or advertising BGP routes. Right? You can run your own autonomous system for sure. But if nobody peers with you, those routes don't reach the global network. This is where Equinix come in. Equinix have probably one of the best peer networks in the world, which means if you're able to advertise your IP address to them, it's gonna go to hopefully most of the autonomous systems on the Internet and give you that

26:44 quick, fast, low hop routing that you really want. But we do see a lot of BGP attacks on the Internet as well. I don't know if that's where you were going with your question, but, you know, people autonomous systems could and there's a prefix that they don't actually or can't actually and this is usually when you see has to go down. It's usually misconfiguration for BGP. Right? Like, every time a CDN network like Fastly or Cloudflare go down, it's either, yeah, a typo on their BGP prefix and the traffic is routed to the to nowhere.

26:50 Bgp Attacks

27:22 But with Equinix and Equinix metal, they're tighter controls. They're passwords on the BGP servers. You can only broadcast global IPs. I think we just show how it works, and then hopefully that makes more sense because I'm just gonna start waffling otherwise. Nope. That's that'll work. Alright. So we're gonna move on to part two. We're gonna deploy our first servers. So we're just gonna keep this nice and simple for today. Deploy two NGINX servers in two different metros within the Equinix metal network and configure our BGP. If you get stuck, there's a video. Hey. That's this video, which you're probably watching

27:50 Requesting a Global IP (Equinix Metal Console)

28:01 right now. So remember to use the code Rawkode for your credit and start by browsing to the Equinix middle console and requesting our first global IP. So we can do that now. But from your project, we go to IPs and IPs, request, and you have two options. You've got your public IPv4 or the global IPv4. So it is a bit more expensive, but it's totally worth it if you wanna keep that latency down all around the world, You can select how many you need. For today, we just need one. I'll just put course as a tag

28:45 and we'll submit our request. If those buttons are not Yeah. I I didn't go. Yeah. No. I suppose that stands to highlight definite in in this interface anywhere on the global being on the right side there. Otherwise, BGP, you can use locally to inside your inside a single metro or location to swap IPs around machines. But if you're looking to be routable from outside, then Yeah. Gotta go global. Alright. Let's refresh this page. And I now have my global IP address. Now if any of those options are not there, what you need to do is go

29:24 Deploying Servers in Multiple Metros

29:27 to BGP and there's a button to enable it here. I already have it enabled. But if you don't see the global option, you have to come here and turn it on. Next, we're gonna spin up to servers. So we're going to use on demand servers. You know, if you're just playing around, just pick the smallest instance available within the metro. You don't need anything demanding or powerful for this. And just make sure you deploy Ubuntu because all the commands below are for Ubuntu or Debian machine. All right. So let's do I'll do Amsterdam. Ubuntu and

30:13 go. Got a a favorite region in The US you would like me to deploy to? I think the closest is gonna be Dallas. Dallas. We can do Dallas. And they've also got c three small and go. Alright. Those will take two to three minutes. Oh, go back to server page. There we go. Yep. Those will take two to three minutes. So we'll maybe I should have done that at the start and then went back to the introduction. That's all good. So once those come up, we're gonna SSH onto them. We're gonna run a few commands.

30:51 Preparing Servers (SSH & Software Installation Plan)

30:55 Our goal is we are going to run NGINX on Dallas machine and the Amsterdam machine, and we'll run curl request locally, which should give us some simple stats about how long the command took to open the connection, get the first pay, etcetera. We'll also run a trace route so you can actually see the hops that the request for my machine takes to get to the server. What we what we would expect to see is that I hit the Amsterdam server. We can modify the HTML just so that prints out, hi. I'm Amsterdam and hi. I'm Dallas.

31:34 But we should see that always hit the Amsterdam server. After that, we'll use or, I mean, we could curl from the Dallas machine, but I guess that's not gonna be very interesting from a written perspective. But there's a website listed here too after we get past all this stuff called loco ping. I have a computer. I'm in Texas. I'll give it a look. Yeah. Yeah. We can do it from your machine too if you're happy to share your screen, but I I didn't want to assume. We can also use local ping, which will show gives us a web interface to trace route

32:09 as well. And I think we can select the location that it runs from. So, hopefully, we'd be able to experiment and see where that alright. The way that we're configuring BGP today is through a piece of software called BERT. This just does does this handles the BGP advertising from each of our machines to the top of rack switches within Equinix metal. Those can then publish it to the Equinix network, and then all the written happens and get spread to the Equinix peers. We should see this happen really, really quickly. What also may be cool to do because

32:44 I'm trying to go to off script in our demo today, is we should be able to shut down BERT on one of the machines. And within a minute, probably quicker, we'll actually see that our prefix will no longer be advertised within that region, and then it will shut down Amsterdam. And what should happen is I get redirected to Dallas. So we'll see the latency increase, but I'm not losing access to the service. So kinda That's where I was going. Alright. Cool. I didn't pick up on that, but there we go. I'm glad we got there.

33:18 I'm glad I got there in the end. You just need to you'd give me more heads. That's all. Alright. Like I said, I never had that 03:00 coffee. Yeah. Let's let's go see where we are with these machines. Alright. We've got one. So we can start with Amsterdam First. We're hopefully gonna be able to SSH on, click the button on my watch. Nice. Probably just do these at the same time. We don't really need to configure both, right? Let's see if they have an IP address yet. Yeah. All right. Won't be able to SSH just

33:51 Configuring Servers: Network Interfaces & Software

34:05 yet, I don't think. But I yeah. I'll wait till I'm on it and then I can broadcast my input to both. Nobody wants to see me input and solve these things twice. Let's see. How far are we? It could be another minute. Okay. We'll just start. I will do it twice. Maybe the first couple of Oh, that'll allow you to that'll allow you to make the do a quick twiddle of a so you don't have to change both of the NGINX hello pages. You'd only have to change one of them. Because if the other one was the default,

34:49 then you'd know. Yeah. Sure. Okay. So at update and then after install BERT and NGINX, we're going to install one more package. Equinix metal make this really, really easy for us. I don't know why I've not got the link. I'll need to add that. I'll edit that after. So the network help us or an open source repository on the Equinix GitHub just in Python scripts that configure BERT for you using the metadata service. So you don't even really need to hand draw your own BERT config, which is pretty nice. Alright. Last try before I broadcast my input.

35:25 Oh, alright. Okay. I can zoom in or I can change my text size. We're on this profile. We'll do app install nginx for that oh, no. I have to clone the network helpers, but I do need Python. So I'll grab these two back. Yeah. You have the you have the link down there in configuring a in the configuring bird section. Alright. Let's just do Python three. Much better. The Dallas box is taking a wee bit extra time. Cool. Now we can jump over here and run this. I'll run through these commands in a second. Let's just rate the file

36:28 first. And then we'll open this up because we need to do a small copy or a small substitution. So what you have to do with BGP addresses is bind them to the look back device on your Linux machine. We have to paste in our address here, which we're gonna get from the Equinix page. Okay. Let's do that there. So we go to our IP address and we copy our global one. And we drop it in. The netmask is there and we save. And we should be able to just run Come on, David. What I get wrong there?

37:20 That's my guide. Cool. IP ADR. We have our BGP address. Now you can just ignore the the warning errors here. Those are collateral damage. But we do have this, which I think is correct. But next, we are gonna use the metadata service to pull down some peer information. I'm just gonna copy this. So in fact, let's just show how this works. Alright. So when you're on Equinix metal devices, you can hit this endpoint. Can't type. Did I spell something wrong? Oh, yeah. And you get this big massive JSON blob. Pivot through I don't have JQ.

37:49 Metadata Service

38:35 Pivot through JQ, and you get all this metadata from the device. This is all your network information, but more importantly, it has our BGP information. So grep for peer. Why does not work? It doesn't matter. Yeah. That's a built in. You there at the very least. I'm assuming j q maybe spits out the text as standard. No. It doesn't. It was standard though. Yeah. I don't know. I think it should be it should be pretty maybe it be printed. But There's no clear information here. So we've missed a step. Let's make sure BGP is enabled on our

39:25 device. Disabled. There we go. So I'll add that to the guide as well and I'll enable it on our Dallas server. Cool. So you have to enable BGP. And that should be almost instantaneous. So yep. There we go. So if we do the JQ Grep again, you'll see that we have a peer autonomous system ID 65530, And then our peer IPs are listed as an array afterwards. And if we take off the grid, it should still be relatively visible. Here. There we go. So we've got our BGP neighbors configuration now. You can see all of this stuff.

40:24 So we've got everything that we need. We also have access to the server now. So let's get caught up so that I don't have to type everything twice. Update install. Yeah. Get type three, hyphen three, put. And the interface. Mars has a nice tech to use dash dash raw with j q. Cool. Oh, yeah. That'll work. Alright. So we need to drop in our BGP address again. All right. I think we're in the same place. So I'm gonna broadcast this to all. Okay. Back to my guide. So what are we doing with that metadata? I think this command is actually doing much

42:13 Configuring & Starting BERT (BGP Daemon)

42:15 reset for showing us stuff. So let's just run that. I don't have to queue another machine. The joys. Alright. Yes. So this curl is just going to j q and pulling out information that we need. So we've got IP addresses, autonomous systems, and we've got the peer IP addresses. These are the things that we need. Next we're adding the routes. So let's just do the curl first. So if we paste this, we get a gateway that we need to route our traffic through. And if we run IP route, think it's handled for us already on these

42:41 Adding the Roots

43:06 machines. But sometimes what you'll get with depending on the metro facility, I can't remember how this works, maybe even the IPX that you will have to add that route manually. But if you see your gateway list is an IP route table, then you're okay. So we can skip that step. Next, we wanna configure birds. So let's just do this couple commands at a time. We're creating a directory under opt and cloning our network helper. We could see the Internet and install our dependencies. Hopefully, it just work. We can run a configure script, which is also gonna write and show us the failures

43:43 in the t command. Whole bunch of stuff there that configures our BGP neighbors based on that metadata that we already seen through the curl j two command. And next, we can restart or start BART in this case. If we run a system CTL status, we can see that it's running. And we'll ignore that error, I don't think that is an issue. Confirm this works, Bart provides a console where we can run this command and looks good. We have our address, the autonomous system, things should be cool. Drop it. All right, testy test time. Let's modify

44:36 Configuring NGINX Index Pages (Adding Location Info)

44:38 var w. Is that a thing? Oh, is on one of them. Did I I forget NGINX on the first machine? Oh, no. I'm still in BERT. Alright. Then I need someone to type for me. HTML. Oh, no. I don't have it. Bar. Oh, there we go. Okay. Default NGINX page, and we'll just change the welcome text. We'll stop the broadcast for a moment. So this first one is Amsterdam. The second one is Dallas. And then go back to broadcast. Oh, we don't need to broadcast now because we're we've done all the the work as it were.

45:40 Testing BGP Routing with Curl

45:40 And in theory, and I'm a bit nervous to go running this now, this should work. Let me open it in the right profile. We should be able to do a curl no. It should be a to our IP address. Well, is it working? No spoilers. It is working. Oh, I haven't restarted it today. Oh, no. I shouldn't have to restart it today. I get I get welcome to Dallas welcoming me in 14775408. Hey. Look at that. So I am continuously Amsterdam. Wow. We may actually finish this stream on time. I was getting a bit nervous there.

46:31 Alright. Let's run our trace route to our IP address. I really need to copy that thing. I'm gonna copy again now because I'll need a few things. Alright. Traceroutes can take a little bit of time, especially as I go through my ISP's network, which does not respond to ICMP pings, which is what those stars mean. It slows down the entire traceroute because it's gonna do it three times before it gives up. And I think it's gonna do that a bunch of times. Is there a command with traceroute to just do one thing and give up? I don't

46:32 Testing Network Path with Traceroute

47:11 know. One ping only? I believe so. I I can't remember what it is offhand. But Yeah. I'm not oh, yeah. Dash q queries. Let's try speeding this up then. I'm about one. And if that does these stars, I'll be making you unhappy. Let's set us back a bit twice sec. Good. That'll speed up a little bit until we get outside of my very opaque ISP five g network. Has the Trisher are you doing our Trisher too? Same. Alright. I'm getting about getting about eight and a half milliseconds over here. Alright. I mean, that looks like we hit the

48:12 network. So what's it done there? I don't know. Alright. 15 hops. You're fight can you fire off ping first? I I went ping first, which gave me the which gave me the yeah. So 12 hops over here. Cool. So we got our hops. We can see the trace route. Actually thought we'd see some of the normally, when I wrote a trace route, we see some of the IPX information. Like, oh, you've hit Dallas and you've gone through this metro facility. But not today, but that's okay. But we got nice little ping, and it works. So

48:55 before I go shutting down barge on Amsterdam, let's try locaping and see what this gives us. Cool. So we can drop in our IP address and let's hit this from somewhere that might be yeah. I don't know where Singapore or Hong Kong will route to. Oh, this isn't gonna show us the HTML. So who knows? Oh, no. We we can see. It gives us country information. Is it finished? Yeah, went to Dallas. There we go. Although it's in New York, but I assume Dallas. All right. Let's try that again from France. See if it's different.

49:02 Testing Routing with Locoping (Third-Party Tool)

49:52 Oh, it's doing it from both. Oh, that's cool. Well, we hit Dallas again over here. It looks like the one on the right is finished. Alright. Let's enable a few more. Screw it. Spain, Italy, Netherlands, USA. Cool. Right. So Dallas at Dallas really quickly. Amsterdam is in America. Interesting. Oh, they're all going there. Oh, no. Except Milan went to. Yeah. Maybe that website works. I'm not sure. Let's do another test. Let's shut down bird. Stop. Let's shut down NGINX too. But we should have nothing run-in here. And if we do a curl, I have Dallas.

50:48 Testing Failover by Stopping BERT/NGINX

51:16 I was just making more things go Yeah. The I was trying to I was trying to figure out exactly what would happen, then if it would immediately, fail over and send you to the, the correct one or if any, any additional intervention would be required. No. No intervention should be required because when Bart stops advertising, the autonomous system in that region will just drop the prefix. It's really quick. I remember Dan doing some tests with his open source project Oh. KubePit. Oh. I think he said he got it he said it was, like, three seconds for

51:57 the failover and the prefix to be dropped. So it's it's super fast. And the fact that I could just curl and even though it's a bit longer to Dallas, you know, we're seeing the hundred and thirty two milliseconds ping instead of the thirty milliseconds ping. At least I'm still getting a service. So what we're seeing is BGP is great for globally written traffic to your customers, at least to a data center or server as close to your customers as possible. But as a happy side effect of this, should you happen to lose any of those

52:26 Summary of Demonstration & BGP Benefits

52:30 advertisements, the global network can reroute you to somewhere else. Maybe a good experiment for this if we ever do a rerecord of the first part would be to do three or four servers and shut them down strategically to see where I'm gonna be routed through. But I think for today, this is a success. So we'll jump back. It should go like, it should continuously go from wherever you are to next fastest or fewest or fewest tops. But, yeah, it'll be a yeah. It'll be a you know, fun experiment. Yeah. If I can't be routed to Amsterdam,

53:03 I would like they route me to Germany if I had one there. If there was nothing in Germany, maybe it would go to the next yeah. The the the network handles this for you, especially this is why it's important to be in a network like Equinix where they have these peers. They have the backbone, and the intelligent written should be there for you. I hope people find us useful. Feel free to jump on the Discord if you need any support, advice, or questions. Thank you, Jeremy, for joining me today. We've got one minute left. Any last words?

53:24 Conclusion & Preview of Next Session

53:36 Absolutely. Thanks for absolutely. Thanks for having me, and I look forward to the the following portions of the following portions of the course. Yep. The next part of this course will be back next week. We're going to deploy core DNS globally using the same setup. We're gonna do this three times with three different pieces of software just to show you why it's important, how to keep those lenses down, and scale with your customers. So tune in then. We'll see you all soon. And thanks again, Jeremy. I'll catch you in a bit. Absolutely. Bye.

Meet the Cast

Weekly Cloud Native insights

Stay ahead in cloud native

Tutorials, deep dives, and curated events. No fluff.

Comments, transcript, and resources