You're actually going to get a two for one in this Nugget.
There's two major nuances that differentiate eBGP from iBGP
And that's what we're going to cover in this Nugget.
The first nuance that we're going to talk about
is how eBGP shares learned routes versus how
iBGP shares learned routes.
And then that will feed into a discussion
about what's called multi-hop.
Let's jump on a whiteboard and I'll draw it up for you.
How eBGP and iBGP share learned routes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
How eBGP and iBGP share learned routes
is a critical functionality to master, where it's one
that you're going to be caught off
guard majorly when it comes time to implement
a network that runs BGP.
To refresh your memory, you can see here
that we have an eBGP link from AS 200 to AS 100.
So as R4 is advertising routes towards AS 200,
because it's an eBGP relationship,
it's changing the next hop address.
So as a route leaves an AS, it changes the next hop address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as a route leaves an AS, it changes the next hop address.
But as a route gets shared within an autonomous system,
the next hop address doesn't change.
That was a pretty major nuance when
we looked at the difference between eBGP and iBGP.
Now we need to talk about when a route is even
advertised in the first place.
When it comes to eBGP, routes get
advertised in a couple different situations.
So here I'm going to write eBGP, a little underline,
and we'll say number one is when we use a network statement. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we'll say number one is when we use a network statement.
If we use a network statement, we are telling our router,
you need to advertise this network.
So maybe R4 here has a loopback of 4.4.4.4.
We use a network statement to advertise it.
It will advertise it out it's eBGP link down to AS 100.
And, of course, it will set the next hop address towards that.
The second time that networks get
advertised out eBGP links is when
we've received a valid NLRI.
Remember, that is a prefix as well as path attributes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Remember, that is a prefix as well as path attributes.
So regardless of where R4 learns about its network,
maybe it receives one coming in from an eBGP link coming
from this way, or it receives a network coming in from iBGP.
It's going to advertise it out the eBGP link
unless we have a policy that stops it from doing that.
iBGP is a little bit different and in a pretty major way.
Now, pretend for a moment that R1 has a loopback of 1.1.1.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, pretend for a moment that R1 has a loopback of 1.1.1.1.
And we issue the network statement on that device.
Well, the first thing, the network statement
here means that we're going to advertise
this towards all peers, regardless of eBGP or iBGP.
But the next spot is where it gets really important.
R2 receives a valid route towards R1.
And with no policies, it will forward it out the eBGP link.
But it will not forward it to other iBGP peers.
So I'm going to put two here and say, only eBGP for valid NLRIs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to put two here and say, only eBGP for valid NLRIs.
This is a major nuance between iBGP and eBGP.
The fact that you can learn an iBGP route from a peer,
but you will not forward it to any other iBGP peers.
It will only ever get forwarded out to eBGP,
unless we set up some other things, like, route reflectors.
And that's what we're going to talk about later.
For now, this sets up the conversation WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For now, this sets up the conversation
about how do we then get R3 and R11 to learn about 1.1.1.1?
R1 here has issued the network statement 1.1.1.1.
So the next solution to make sure they learn about this
is to build peering relationships
to each of these devices.
In fact, we need to mention this right now.
The only way that you can get full connectivity
in this autonomous system using BGP is if you had a full mesh. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in this autonomous system using BGP is if you had a full mesh.
Yeah, you see all of these links?
All of a sudden they're going everywhere?
That's right.
And that's going to play a bigger factor
when we get down the road.
But let's talk about this for a second, which
brings up our next major nuance between eBGP and iBGP.
In order for R1 to connect to R3 and form a BGP relationship,
first of all, we have to have routability between them.
So either static routes, or more likely
an IGP will be running, like, OSPF or EIGRP.
So the next thing we need to think about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the next thing we need to think about
is the actual mechanisms that take place.
When you issue the neighbor statement, what happens?
Pretend we're on R1 for a second.
And we issue the neighbor statement for R3.
R1 is building a packet, sourced out of gig 1/0
here, destined for R3.
And it's going towards TCP port 179.
As the packet leaves R1, it's going to arrive on R2.
R2 goes up to layer 3, looks at its routing table, says,
I know how to get to R3.
And forwards it along.
It never looks at layer 4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It never looks at layer 4.
And it doesn't care that there's a BGP relationship going
on on the other sides of it.
It's just a transit router at this point.
But what also goes on in a TCP header
is something called the TTL, the time to live,
a fancy way of saying how many hops can this packet go
before we determine that this packet is dead?
And this is the next major difference
between eBGP and iBGP.
The screen is getting a little messy.
So at this point, I'm going to clear it.
And we're going to say, when R1 wants to communicate to R2 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're going to say, when R1 wants to communicate to R2
and then to R3 to form its BGP relationship with R3,
this TTL will need to be big enough
to allow these hops to occur.
In iBGP, the TTL is set to 255.
So our open packet, when we try to form a BGP session,
is allowed to hop from one device
to the next device in an iBGP session.
In an eBGP session, the TTL is set to zero.
That's right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's right.
eBGP sessions by default have to be directly connected.
Even if R2 wanted to peer with the loopback address of R4,
let's call that 4.4.4.4, that would
be a hop to this interface and then routed to R4.
This is called multi-hop.
And knowing the difference between an iBGP multi-hop
scenario-- basically, multi-hop is allowed--
versus an eBGP multi-hop scenario-- basically,
multi-hop is not allowed-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
multi-hop is not allowed--
is going to be important for you to understand, too.
So what we're going to do now is we're
going to jump in the virtual lab and we are
going to build this topology.
We're going to build a full mesh AS 100.
And then we're going to build a multi-hop connection
to the loopback address on R4.
Let's get going.
Now to reemphasize some of the key topics
here that we covered in the previous section
when we were setting up the basics of BGP,
I'm going to build a topology where there's
R1, R2, R3, and R11 down here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R1, R2, R3, and R11 down here.
These are all within AS 100.
And I'm going to build this full mesh topology.
So R1 will have a connection here.
R1 will have a connection here.
R2 is already pretty well meshed.
And R3 just needs a connection to R11 at this point.
But I'm going to build this so that it's peered
based on loopback addresses.
Immediately that should be signaling
that this is going to be a multi-hop situation because we
have to hop to get to even the closest loopback address.
Because iBGP allows that, I'm not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because iBGP allows that, I'm not
going to run into any issues.
Where I'm going to run into an issue
is when we get up here to R4 and I
want to peer with the loopback address of 4.4.4.4.
Now, typically, you would not peer with a remote device's
loopback address.
This is just to setup how eBGP multi-hop really works.
So my challenge to you is fire up the Virtual Lab
and get AS 100 all ready, up and running and configured,
then we can start talking about the eBGP multi-hop.
WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And after just a few moments I have my AS 100 topology
completely stood up.
I ran OSPF to bring all the interfaces and routability
in to AS 100.
That way there's an IGP running.
And everybody can reach everybody.
Then I was able to issue my neighbor commands.
I went into the address family configuration
mode, activated them, made sure I did the update
source to loopback one.
Now I can do show BGP IPv4 unicast summary. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now I can do show BGP IPv4 unicast summary.
I've got to use an M there.
And now I see that I've got my neighbor relationships right up
here on R11.
They aren't sharing any prefixes at this point.
That's fine.
We're just showing that multi-hop worked perfectly fine
in an iBGP scenario.
So now what we need to do is we need to jump over to R2
and make sure we get into router BGP 100
and start to try to bring up the BGP relationship with R4's
loopback address, 4.4.4.4.
If I say neighbor 4.4.4.4 remote AS of 200, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I say neighbor 4.4.4.4 remote AS of 200,
it instantly knows this is an eBGP relationship.
It also doesn't have a route to 4.4.4.4 currently.
So it's immediately not even trying
to form that relationship.
I will go into address family IPv4
and activate this relationship.
We'll say neighbor 4.4.4.4 activate.
And then I'll exit out of router configuration mode
and quickly give myself a static route to 4.4.4.4 going out
that outbound interface, just like that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that outbound interface, just like that.
So at this point our router is trying to reach 4.4.4.4,
sourcing the TCP packet from 100.100.24.2.
See, now it's looking in the route table for 4.4.4.4
and it sees that it's outbound towards this locally connected
interface.
So R4, when we issue the neighbor statement,
would be expecting a neighbor of that IP address.
Let's go try to bring that neighbor relationship alive.
We'll go to router BGP 200. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll go to router BGP 200.
And we'll say our neighbor is going to be 100.100.24.2
in the remote AS of 100.
Now, here's the thing.
We would expect this neighbor relationship
to come to life at this point.
See, I can ping the remote address here.
Looks good.
And from R2, I can ping the loopback address.
So there's reachability, there's connectivity.
But it's not coming to life because eBGP multi-hop
stops this from happening.
So what we have to do to make this work
is we have to configure eBGP multi-hop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is we have to configure eBGP multi-hop.
So I'll jump back into router configuration mode.
And I'll specify for my neighbor a 4.4.4.4.
There are a couple options that we have here.
The first one is disable connected check.
This allows for a one-hop away eBGP peer
using a loopback address.
There's also eBGP multi-hop, allow eBGP neighbors not
on directly connected networks.
So I'm going to do disable connected check first.
Then for neighbor 4.4.4.4-- and look at that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then for neighbor 4.4.4.4-- and look at that.
That's all it took to make this neighbor relationship come
to life.
For good measure, though, I can also run the command 4.4.4.4
eBGP multi-hop.
And then the next thing it asks for, is,
what is the time to live?
How many hops are we going to allow for this packet?
I'll put something, like, 10 for now,
even though the neighbor relationship is up and running.
So if I say end and now I do a show
BGP IPv4 unicast summary, there.
Now I see I'm peered with the loopback address eBGP AS 200. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now I see I'm peered with the loopback address eBGP AS 200.
So that's the nuance, the difference,
between eBGP and iBGP when it comes to multi-hop.
But this sets up the real scenario
that we're here to talk to.
We did this with only four routers.
How many BGP sessions are actually active right here?
The formula is the number of routers
times the number of routers minus 1 divided by 2.
In this case, that's 4 times 4 minus 1 divided by 2.
So we've got 12 divided by 2, there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we've got 12 divided by 2, there
are six BGP sessions active right now.
Imagine for a second, now, that there are 10,000 routers.
Yeah, you get the idea.
The number of BGP sessions that we're working with here
is now absolutely astronomical.
We're looking at hundreds of thousands of BGP sessions.
And all of a sudden this full mesh topology to make iBGP work
is not scalable.
This is too many BGP sessions.
How we fix the iBGP full mesh scalability problem, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
How we fix the iBGP full mesh scalability problem,
we can do it, first, with something
called route reflectors.
And that's what the next Nugget is all about.
In the meantime, that's been setting up
multi-hop and the scaling issue that we're trying to solve.
I hope this has been informative for you.
And I'd like to thank you for viewing.