(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 BGP

So 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 BGP

Reason #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.