(03) Foundation: What Is BGP? When Do I Use It? (Part 2)

Well, it took an entire Nugget just to define what BGP really is. This huge exterior gateway protocol that is able to route a routing table the size of the internet. So what I want to do as we continue that discussion is talk about when we don't use BGP, which is almost as important as when we do use BGP. And then finally, look at BGP, the resume, meaning here's essentially the basics of how BGP really works. Why not to use BGPSo let's talk about first, why would you not want to run BGP? Well, let me boil it down to, I would say, the number one reason. Reason #1: You are only connected to ONE External AS (ISP)It's actually the second reason on my list. You're only connected to one external autonomous system, or one external ISP. So this is the vast majority of organizations out there. Let's say you've got a router, or two, or three, or 90, that are all connected up to a single ISP. This is not a scenario for BGP. There's really no reason to, because it doesn't matter how many routes you receive from that ISP. There's only one path to go on anyway to get out. So there's no reason to receive 200,000, 300,000 routes of the internet routing table, when all of them are going to be pointing so this ISP as the next hop. This goes even further. You could have one router. You could have a pair of redundant routers to the same ISP, connected to a pair of redundant routers at the ISP. Multiply that 90 times over, and there's always a better way than using BGP to maintain that connection. You could use floating static routes. Or you could use internal routing protocols to communicate which one is active, which one's up, which is preferred over that. Again, if you don't have to run BGP, then don't, because it's adding a lot of complexity and a lot of load to your router.Exception of Reason #1 Now I will say, here's one common use that I have seen people do in the real world, is a lot of times, the router is not able to detect-- I'll just put kind of a mysterious question mark cloud right here-- is not able to detect if the ISP router is really online or offline. For instance, if this guy's maybe connection failed, for some reason, it doesn't register on this side. Let me just give you a common one. Let's say you've got a cable modem connection. Cable modems have really made their way into the business market. And so, you've got this cable modem that bridges your connection to your ISP. Well, the ISP could go up in flames, and not be working at all. They're all down. This whole connection's down. But the cable modem provides a link up-- I'll just put L up-- active status right here to the router, so it never knows to failover, for instance, if you have a backup connection going to the same ISP, or a different ISP, or something like that. So a lot of people will say, well, that would be good to-- I've got to get my finger off that button. It would be good to run BGP between these guys, because BGP will provide a keep alive. And that is true. I will not argue that. BGP will give you a keep alive to tell you if that peer really is online or not. But nowadays, I would say within the last eight years, it's been awhile since this feature's come out. Nowadays, I would pretty much point everybody to a feature called IP SLA. It used to be called, I believe it was Cisco RTR, the round trip responder. Essentially, this is a feature allowing you to define probes. That sounds creepy. But little probe packets that will go out and access whatever end device you would like to access. So you can have it ping the default gateway of your ISP 10 times every, I don't know, second, or 30 seconds, or 50 seconds. Whatever you like to do. And if that guy stops responding, then you can have it automatically remove a default route. You can define these things called track objects and so on. But not to get heavily into IP SLA. But what I'm saying is there's a much easier, less configuration-centric. Less hassle than running BGP. And that would be IP SLA. So I would say, if you're connected one external source, then that is definitely not a reason to run BGP. Reason #2: You Dont have beefy (Robust) Router.Second reason. Look at the top one. You don't have beefy routers. Meaning BGP literally will drop 300 some thousand routes. If you receive the whole internet routing table, 300 some thousand routes onto your router. Now if you go to take the route series from CBT Nuggets, or you start learning routing protocols, one of the big things is like, aw, you need summarization, because we got to take that hundred routes and get it down to two or three. We're really about saving the routing table. But when you would start receiving BGP, and they're like, OK, here's 300,000 routes. Have your try at that one. I mean, it's kind of like, well, good grief. What are you going to do? I mean, first off, you might say, well, what do you mean by a beefy router, Jeremy? Let me just slide this over. This is from Cisco's frequently asked questions on BGP. It says, well, how much memory-- let's focus on memory, because that's the number one resource that's used by BGP. Well, first off, it says, it depends. Which is, you can absolutely answer every question that way. But Cisco finally says, well, we recommend typically, if you're going to receive the global internet routing table from one peer, which if you are running BGP, you usually have more than one peer, but look at that. Minimum of 512 megabytes of RAM. Now, comparing to our computer standard-- I just built a computer for myself-- it was kind of cool. I built a computer for myself with 16 gigs of RAM. I'm like, aw, this will be like, an awesome virtualization box and all that. But when you move to the router world, 512 megabytes of RAM, it's like wow. That's a decent chunk. I mean, modern routers typically ship with 128 Megs, or 256 Megs of RAM. So immediately, you're already a step beyond that, to store just in pure memory. That's not counting processor. And I would say at that point, I would fall right into Cisco's "it depends" answer. Because you're going to be filtering. You're going to be choosing different routes. There's a whole lot of criteria of, how does that BGP table impact you? Reason #3: You Dont have Enough Bandwidth to Receive updates.Also, I'll go right along with this. You don't have enough bandwidth to receive updates. Nowadays, looking at this, this is from the RFC standard. Link bandwidth and CPU recommendation. Don't you love RFCs? They're like, actually, you can calculate bandwidth by using O times N plus M times A. I mean, it's like, OK. Yeah. That's what RFC standards are meant to be. But I love-- thank you, thank you, BGP RFC standard writer. Has come in and said, well, if you're going to receive 100,000 routes, that's about 520,000 bytes of bandwidth that's going to come in. Now remember, this RFC was written back in 1991. You might be like, wow, that sounds like a lot. Well, that's half a megabyte. So in 1991, half a megabyte was a lot more than it is today. But if you have to have links, if you have areas of your network that have slow internet connections, you need to make sure you're able to handle that. But also remember, when you receive 100,000, or 200,000, or 300,000 routes, you're really going to be receiving 300,000 routes the router has to process through, and churn through, and say, which is the best? Which goes in the routing table? All of that. So it's really going to be a lot more impactful on your processor, your memory, of your router. And they're continually updating. BGP will update about once every 30 seconds by default. Receive a whole batch of updates of things that have changed. So it's going to constantly be processing, moving things in and out of the routing table all the time. So I would say these first three are the hard facts. You got to have this stuff in order to run BGP. And then this is the soft one. Reason #4: You Dont Fully understand BGP.You don't fully understand BGP. When you open those flood gates of BGP, it's very easy to accidentally blow up a router. I mean, first off, you're receiving a massive routing table. One of the things that we're going to get into is it's very common for people to start redistributing portions of the BGP table into their interior gateway protocol and vice versa, to where they send OSPF routes into BGP and vice versa. BGP into OSPF. But when you're doing that, you've got to be very careful, because whoops, I just sent 300,000 routes into OSPF and pow. Smoke begins pouring out of all of the routers throughout your entire enterprise. It's something that doesn't just take out one. It can take out the entire group of routers. So you want to just be careful when you're getting into BGP, because you are dealing with kind of big picture things.

Why to use BGPReason #1: You need High-Availability through Multiple ISPs.Now that we've talked about when not to use BGP, let's talk about the usage scenarios. The number one, from an enterprise customer perspective, is you need a high availability through multiple ISPs. Meaning you reach a point where the resources that you're running at your location become so critical that you say, well, we need not one, but two ISPs. So you have a connection up here through, we'll say, CenturyLink and Cox. That was my scenario before. To where now, you've got your network-- we'll say it's the 200.1.1.0 network-- inside, which can be reached from both of those. So whatever server that you're running internal to your organization is reachable no matter what happens. Now you've got look at the signs of the times. Look around at our industry. If you were to say, what is the number one buzzword in the IT community right now? What would it be? Cloud. I can say that. It would be, everything is cloud-based. And everybody's running to say, oh, it's in the cloud. It's in the cloud. I brought this up last time-- Hang on. I think I still have it on my cell phone. OK. Here it is. Move this over. And I know. It's showing a Juniper ad in a training series for Cisco. But forgive me. I just thought it was funny. It said, "Cloud Schmoud, the cloud is nothing without the data center." That was actually in an airport that I was in-- where was I? California or something. It was a connecting flight, and I was just walking around. But anyway, the point is a lot of times, people are like, oh, it's in the cloud. Well, remember, the cloud is nothing more than essentially moving this to a place that has a lot of connectivity, a data center. So now, instead of this being on-site, we now have the bandwidth, we now the connectivity, to where people are saying, well, let's move this off to a data center. But it's still the same thing. I mean, take this picture and just say, OK, well, we're at the data center now. It's the same design. Same kind of concepts, to where now, just instead of them having to trench cable to your site, just down the hallway, you have a direct fiber optic connection from CenturyLink, from Cox, from Sprint. From all the ISPs. Essentially in a data center, you have this cross connect room, where all the service providers bring in their fiber optic cable. And then you have all of the customer racks essentially. Here's a big old room where customers get. And they got all the retinal scans and all that. And all they do is run fiber optic cable, and you pay the service router. You say, OK, well, I want a connection from Cox and from CenturyLink that is able to come over here to them to my rack. So it's the same exact thing. It's just now, you're running via fiber instead of via whatever kind of lines and cables they've run to your customer premise. So whether it's going to be in the cloud, meaning at a data center, or whether it's going to be on-site, this is one of the reasons to run BGP, is you need that multiple ISP connectivity. Reason #2: You are a Service Provider.A second reason is you are as a service provider. You are one who provides service to others, or essentially, your name is a transit autonomous system. Meaning let's say, you are a cloud, and people are passing through you to get other things. That's another reason to run BGP. Take a small service provider. There's a ton of them out here in Arizona. I'll just say, small ISP. At a minimum, a small ISP would want to consider at least two uplinks to larger ISPs. Your larger-- I'll just put LG-- LG ISPs that they're going to run. So they will run full BGP from their premises to these larger ISPs. They will have their own autonomous system number. They will get, we'll say, a class-- let's just say it's a small ISP, so we'll just say they get a class-- we'll say it's a class B block of address. And so, they chop that up for all of their customers. So you have all these customers of that small ISP that comes in. The small ISP receives all of their routes, and takes their class B, and chops it up for all of them using subnetting, and then advertises their class B route through these larger ISPs. And then, the world comes in through these larger ISPs Let me change colors here. Comes in through these larger ISPs to reach all of that smaller ISP's customers via that. That's a typical transit autonomous system, or the paper definition of a service provider. Reason #3: Extremely Large Networks with Demarc Points to other Divisions or Partners.

The last one, and this is one that is kind of outside the box a lot of times, is extremely large networks with demarc points, or divisions, or partners. Things where there's lines to be drawn. I've actually taught the BGP class many times in front of students in a live training environment. And I will say by far, there's a specific company-- I'm not going to tell you their name-- but a specific, large financial institution that has literally bought out my classes, to where they will send 20, 30 people just to learn all about BGP. And this financial institution essentially has a core network that runs every routing protocol under the sun. I mean, you've got like, OSPF running in one portion of the network. I mean, they're huge. If I said their name, you would immediately go, oh well, duh. It's a huge financial institution. They've got EIGRP at one part of the network. They even have RIP. You might say, well, what for? Mainframes. A lot of the mainframes run RIP. And they RIP essentially as a default to get a default route to get out of the network. So they have all these protocols running. And then they have all these partner institutions. Mean, when you're talking about financial firms that are this large, you have a lot of people that, for instance, process credit cards. So you have like, credit card processing. You've got partner or organizations that you receive and transmit background checks. All kinds of wacky stuff that financial institutions-- links to the government. Government reporting entities have to be managed. So you have all these protocols running, and then you have what I would call these little demarc points to where it's like, OK, well, we've got the credit card processing, which needs to reach a portion of this. And we need to reach a portion of them. But I don't want to send my whole internal network, or nor allow them to send their whole internal network to me. Well, that's a perfect point where BGP comes in, to where it says, OK, now here's the line. Here's where the BGP relationship begins, and you get to choose exactly what routes you send to them, and you get to choose exactly what routes they can send to you. Same thing with these partners. Same things with the government, is you have BGP, which kind of acts as a demarc to kind of say, OK, this is where their network ends, and ours begins. But let's transmit some of the routes between us.

Another big one will be MPLS. MPLS is kind of like, Frame Relay used to be this darling of the world to where it's like, oh, Frame Relay. I can get multiple WAN connections through one serial interface. Well, now with MPLS, you can come in and get full mesh connectivity between all of your sites using this kind of WAN less cloud. Literally with MPLS, they can do any to any. This guy can come in using Frame Relay. This guy can come in using Ethernet. And this guy can come in using-- I don't know-- dial-up. Whatever. And MPLS kind of decodes those, is the best way I can say it. It kind of blends them all onto the one big mush cloud, where everybody feels like they're fully connected. So much so that this guy can peer with a router here that's running a little virtualization, I guess you could call it, kind of like router virtualization here, to where the service provider pretends as if it's your network, as in you can fully exchange your routing table here. And the service provider will take it through their network and exchange it over here. And it peers and fully exchanges is here to where literally your private routes-- like, let's say this is the 10.1.1 network up here-- I can advertise that into the service provider, and they will pass it through And this guy will be like, oh yeah, I know about the 10.1.1 network. This private network through this private cloud that you have between your sites. Well, a lot of service providers will do that for you, but they will choose-- you probably are guessing it-- BGP as their protocol. So what you'll do is you'll have OSPF running at all your sites. Here's all your OSPF networks. And you will translate those or redistribute those fully into BGP, which allows you to give it to the service router. Then the service router will transmit it through the rest of the cloud and let everybody else receive those routes. That's what I'm talking about, where you have these demarc points with the service providers. Now I will say, some service providers will even let you-- they'll say, hey, we'll run OSPF with you. It's just from the service provider perspective, it's a little riskier to do that. And it takes a little more resources on their devices to run a protocol like OSPF rather than BGP.

All right. Now let's dive into some of the more technical details of BGP. Kind of what I've created as BGP's resume. First off, its mission statement is to exchange routes between autonomous systems. You're always supposed to start a resume with that personal goal. That's its goal. 1. Reliable Updates (TCP-Based, Port 179)Now to get into the nitty gritty of how it does that, first off, BGP runs on top of TCP. Now it's a little different from all the major internal routing protocols that we discussed, like OSPF, and ISIS, and EIGRP. Those are all their own protocol. They don't use TCP or UDP. They have their own reliability mechanism that they've designed, because they had to be able to tune it really low to where I can send hello's once every 200 milliseconds, or something like that, as you get into the some of the super high speeds. Well, DCP, you remember me saying, it's not designed for mean, green speed between the devices. So it's totally content to rely on the TCP protocol doing keep alives. So when it says it's reliable, it's not because of any kind of acknowledgement that's custom designed. It's just the normal TCP acts that we've come to know and love through our windowing. And I've sent five packets, and you acknowledge that using sequence numbers and all that. So that's all BGP uses. 2. Triggered Updates only (5 Secs Interval for iBGP, 30 Second eBGP, External)BGP uses triggered updates to where, instead of-- let me compare that to event-based updates. To where, internal protocol, if this network fails, it's going, hey, network down. Immediately, event-based update is sent. Whereas BGP, I mean, thousands of networks worldwide are going up and down all the time. That's just the day in the life of a network the size of the internet. So what BGP will do is, let's say this is your connection to an ISP. What they'll do is once every 30 seconds-- it's going to be an external, an EBGP relationship. Every 30 seconds, they're going to take all the updates that they've received from all of their peers and upstream routers and batch them to you, and say, hey, over the last 30 seconds, we received 182 updates. These networks are now available or unavailable. All that kind of stuff. Internal peers, like let's say this is all within your organization. We'll talk about IBGP and EBGP later on. Those peers are going to receive updates once every five seconds, because they're usually considered higher speed connections. 3. Complicated Metric for Finding the Best Route.Now BGP, when you say, what is the metric of BGP? That's like, a total loaded question. It's like, uh, yes. Yes, there is a metric for BGP. But it's not so much a metric-- with OSPF, we go, oh, OK, that's cost. Which is, you guys remember that, 100 divided by bandwidth in megabits per second will give you the cost for OSPF. It's very simple. Even EIGRP has this complex k value formula, but that totally pales in comparison to BGP. BGP is somewhere around, I believe off the top my head, I think its 13 different attributes that it goes through. So instead of saying, there's one metric, it's more of a, let's find out what's the first thing that makes this better than the other. So for instance, it'll say, OK, attribute number one, which happens to be the weight. And we'll learn all of these. It says, OK, is there one that has two routes come in from two different sources to a router? I drew that picture totally wrong. So let's say it comes into that router right there. And it says, OK, which one should I choose? Which is best? So the first thing it's going to say is, is there a higher weight? If so, then that's what decides it. Lets go that route. He has a higher weight. If not, let's go to the next one, which will be local preference. And then, let's go to the next one, and the third, and the fourth, and the fifth. It will go until eventually something will say, item number six breaks the tie. And it says, OK, that's the best route. And I'll say, this will probably be one of the most important things for you to learn, is the BGP path selection tree, I'll call it. That would be BGP's metric-- it's complicated-- for finding the best route. 4. All the Neighbors are Manually Setup.All the neighbors in BGP, again looking at is resume, all of them are manually set up different from OSPF and EIGRP, where neighbors just kind of auto discover, they form relationships using the hello protocol. Well, BGP doesn't have a hello protocol. The closest thing it has a something called open. And that's the type of message that it send. It says, hey, I'd like to start a connection with you. And the only way that that open message will be sent is if you-- this is a picture of you-- get on that router and manually configure that router for that neighbor. You say, I want to be a neighbor with 10.1.1.1. And on the other side, an administrator, you or somebody else, gets on there and says, OK, I'm expecting a neighbor connection from 1.1.1.2. So let's prepare ourselves for that. Let's have all the criteria set up. There's no Auto-Discover for neighbors. So, no hello packets. No open messages that are sent without you getting involved and saying, I want to open a connection to that guy.

5. Complex Filters are Typically Used.Complex filters are typically used with BGP. Because literally, the sheer amount of routes that you will receive via BGP will be overwhelming. So you will typically want to put filters on there to either limit that, or market with certain attributes which will control the metric. I can say, OK, well, I want routes coming in from that guy, or these kind of routes that are coming in, to be tagged with this. And I'll tell you what. That's where BGP gets cool. Aw man, when you get into BGP, and you start learning route maps and all the ways to set criteria and learning regular expressions, you're going to feel cool. I know it sounds funny to say it that way, but there's no other way. You're going to be like, I can do anything. I don't know why this came into mind, but you know those little orbs they used to sell at like, Spencer's Gift, where it's like electric power? Like, you're going to feel like one of those electric powers when you touch the ball. It's like bzzz. You're like, I can do anything on the router. That's kind of what you're going to do. Because you're going to set up filters, which are literally kind of like programming. It's like a programming language for a router, would be the best way that I can describe it. Which I know some of you go, whoa, I didn't sign up for that. But it's, I'll say, basic programming, where you can do almost anything with the advertisements that are coming in.

The last thing I want to leave you with as we wrap up this Nugget is what I call the golden rule of BGP. Then I decided to throw the RFC number in there so that you could reference this. Because I'm going to refer back to this rule again and again and again throughout the series. This is kind of a disheartening rule, but it makes sense. Let me read it to you from the RFC, and then translate it. RFC says, "BGP does not enable one autonomous system to send traffic to a neighbor autonomous system intending that the traffic take a different route from that taken by the traffic originating in the neighbor autonomous system." Man. People who write RFCs are skilled at nonsense. I'm like, I could have totally found a better way to word that thing, but with linguistics and white paper writing being the way it is. I mean, if you read that maybe three times, you'll be like, oh, OK. I get what it's saying. But once over? No way. Unless you're better than me. It took me a few times. My translation is you can't tell someone else what to do with their traffic. That's how they should have written it in the BGP RFC 1771. So here's what that means. You only have control over your autonomous system. Actually, let me draw my cloud a little different. Actually, it kind of looks like a three-dimensional sheep. Kind of from a top view. Maybe here's the tail and all that. Well, actually, that could look like at kinds of things. So we've got our little sheep cloud. Autonomous system, let's say 40, that is going out and connecting to other service providers. Now here's the ISP. You might get a full BGP connection. You might see, and you'll be able to see using BGP, that this guy is directly connected to, we'll say, an autonomous system right here that has a server that you're trying to reach. Inside of that autonomous system is a server. You might send it out to that BGP autonomous system, and they decide to route it up here. And then, through 50 other autonomous systems, that ends up wrapping back around and reaching in here. Now you might call them up. You might do something. Tell them and say, hey, I'm trying to send it. This group over here tells me they have a direct connection to you, but they're seeing the traffic go all the way around the world before it gets. It's causing some issues with our voiceover IP, because the delay is so long. You're wondering to yourself, how do I manipulate it to where they will send it out here? And the truth is, you. Can't there's nothing that you can do. That's what I'm saying. You can't tell someone else what to do with their traffic, or even your traffic once it leaves your autonomous system. Because then, as soon as your packets get in their autonomous system, it's not your traffic anymore. It's they're traffic. They can drop it if they want to, because you're in their network. And it makes sense. I mean, you wouldn't want this server provider contacting you and saying, well, I want you to route my packets going this way. You'd be like, no, it's my network. You can't tell me that. So, it sounds obvious. But there's going to be a lot of times where you wish that this weren't the golden rule. You will you want to wish that I could tell this ISP to maybe not route so much traffic in through them. Can I load balance a little, and have you send some over here, and do that? I mean, there will be ways that you can try to work with that. I'm going to show you ways that you can kind of, under the radar, sort of send updates that maybe don't look as good as others, and try and manipulate that incoming traffic yourself. But there's no real way-- I mean, if this service provider says, well, I don't want to send traffic to you, then I'm sorry, they're not going to. It's their autonomous system. It's their traffic. So a lot of times, BGP turns into a people game, where you have to call different places and say, hey, I noticed traffic coming this way. Is there a way that you could make your routing table do this? And most of the time, I'll be honest, they'll say, no, I don't want to do that, because it's getting into custom policies and complex stuff. So we are going to see a lot of stuff in this series where you can manipulate your traffic, and ways to tweak your traffic, so it make your decisions of which way it's going out. And I'll show you some stuff where you can try to manipulate other people to where you can say, well, I really prefer this way. But when it all comes down, the golden rule says, they have the end say. Well, this puts the cap on the opening to BGP. Looking at when not to use it, meaning primarily if you have one ISP connection. Looking at when to use it when you have multiple ISP connections, or you're a service provider, or you're an enterprise class customers with partner relationships and things like that. And then, finally looking at some of the core facts of BGPs that we're only going to expand on as we move on further. I hope this has been informative for you, and I'd like to thank you for viewing.