Up until this point, we've talked
a lot about how carriers would connect
BGP instances to each other.
We had a scenario where maybe AT&T would connect to Verizon.
And they would say what each other's remote autonomous
systems are, and what the remote IP addresses are.
The neighbor relationship would come up.
And they would share networks back and forth.
We demonstrated that in the last Nugget,
when we jumped in the virtual and did it.
But what's actually really common
is that a carrier may form BGP sessions within itself.
It may have routers all across the world WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It may have routers all across the world
in its own autonomous system.
And it would want BGP sessions existing by itself.
So here's the real kicker, though.
When we form a relationship to a other institution--
outside of our autonomous system--
BGP behaves one way, so to speak.
When we form a relationship within our own autonomous
system-- when we have BGP peers within an autonomous system--
BGP behaves differently.
And that's what we're talking about when WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's what we're talking about when
we say the difference between external BGP and internal BGP.
Let's jump on a whiteboard real quick.
When we talk about the difference between a BGP
and iBGP, we are really digging into what
are the nuances of BGP.
In the last few Nuggets, we looked at this scenario right
here, when R2 peered with R4.
And this was AS 100 versus AS 200.
When we were on R2, and we typed router BGP 100,
R2 became aware that its autonomous system was 100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R2 became aware that its autonomous system was 100.
And when we typed the neighbor command neighbor
IP remote AS 200, R2 was smart enough
to see that this 200 wasn't its own autonomous system.
Therefore, this must be an eBGP connection.
Let's now pretend we wanted to build a peering right here,
between R1.
R2 enters router BGP 100-- again,
knowing that its autonomous system is 100.
We would type in the neighbor command IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We would type in the neighbor command IP
address remote AS again.
But this time we would type remote AS 100.
And because R2 is so clever, it knows that this 100--
for the remote autonomous system--
matches its own autonomous system.
Therefore, it's going to form an iBGP connection.
This really is the first nuance to eBGP
verse iBGP, is just knowing how it recognizes it's
an eBGP versus iBGP scenario. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
an eBGP versus iBGP scenario.
R2 can recognize its own autonomous system
versus what the neighbors' autonomous
systems are, and determine if it's
an eBGP or an iBGP session.
So before we dig any more into the nuances of eBGP verse iBGP,
let's jump back into the virtual lab.
And using some muscle memory here,
we're going to configure the eBGP instance to AS 200,
and the iBGP instance within AS 100.
So I fired up the virtual lab.
I'm on R2.
Going to jump into configuration mode, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Going to jump into configuration mode,
so that I can configure BGP--
so that I can configure eBGP.
Let's configure the eBGP session first.
I'll go into router BGP 100, because that's
my own autonomous system.
I'm going to try and connect to our neighbor again,
with 100.100.24.4.
The remote autonomous system across the way is 200.
Jumping over to R4, I'll go into configuration mode.
I'll go into router BGP 200, because that's R4's autonomous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll go into router BGP 200, because that's R4's autonomous
system, and I'm going to configure my neighbor
relationship with 100.100.24.2.
The remote autonomous system is 100.
After just a moment, I see the neighbor relationship
has come up.
If I give it a show IP BGP neighbors,
in the very first section, I can see
this is using an external link.
I know this is an eBGP instance.
Now I want to configure my iBGP instance between R1 and R2.
If I give this a do show IP interface brief, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I give this a do show IP interface brief,
R1 is configured off of gigabit ethernet 0 0.
The format, again, is 172.16.
12 here represents the link between R1 and R2.
And 2 here represents the router number, in this case, R2.
So R1's IP address is going to be 172.16.12.1.
I'll specify I want my neighbor to be R1--
172.16.12.1.
And the remote AS is not really remote at all. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the remote AS is not really remote at all.
It's my own autonomous system, which is 100.
Now let's jump over to R1 and get that neighbor relationship
stood up.
Jumping into config mode, we'll say
router BGP 100 neighbor 172.16.12.2 remote AS again,
100.
Doesn't take very long for that relationship to come up.
If I hit end, and then say show IP BGP neighbor-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I hit end, and then say show IP BGP neighbor--
got to type correctly.
I see we've got here an internal link, knowing
that this is an iBGP session.
So now it's time to introduce the next nuance of iBGP
versus eBGP, and that's how routes are actually
advertised back and forth.
What I'm going to do is I'm going to jump over to R4.
I'm going to jump into router BGP 200.
And if I'd give it a do show IP interface brief,
we can see there's a loopback here-- loopback 4.4.4.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can see there's a loopback here-- loopback 4.4.4.4.
Let's pretend for a moment there I want AS 100--
our eBGP peer-- to be able to access loopback one--
4.4.4.4.
So you would think, cool.
Just to get this route into AS 100,
I'll just specify network 4.4.4.4
with a mask of 255, 255, 255, 255
since the loopback addresses are 32-bit mask.
Awesome.
Let's jump over to R2.
I'll jump out of configuration mode,
and I'll give it a show IP BGP.
And I see the 4.4.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I see the 4.4.4.
address.
Can I ping 4.4.4.4?
Yep.
There we go.
Roundtrip.
That's great.
So it's not a stretch to think, then, that R2 would then
send this network on to R1.
From R2, I can also give it a show IP route.
Let's just cut right to the chase.
And I see 4.4.4.4 was learned via BGP.
I'll also point out that it has an administrative distance
of 20, which is the AD of external BGP.
Let's jump over to R1 for a second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's jump over to R1 for a second.
From privilege mode, I'll give it a show IP route.
No 4.4.4.4.
You see I've got R2 which is connected to R1.
And this is forming our iBGP session.
And I've got R4 up here, advertising its loopback.
This is our eBGP session.
Well, R2 clearly has the connectivity to the loopback.
It knows of the route.
And the next hop on that route to loopback one was
100.100.24.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
100.100.24.4.
It's not a stretch to think that R2 then advertised that route
R1, don't you think?
Let's take a look at what were the routes
that we've learned from BGP so far, was show IP BGP.
Oh well, that's interesting.
The route is there.
But there's one very important symbol
missing from show IP BGP, and that is this symbol right
here--
the best route.
You see, we see that it is a valid route.
And we see that it came to us internally.
There's the little i there.
But there is no best. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But there is no best.
And why?
It's because of this right here.
That next hop address is still R4's address.
And as we see in the routing table above,
there is no route to this next hop address.
Let me just draw R1 and R2.
This is the next nuance of iBGP versus eBGP,
and it's setting up the next Nugget, which is,
how do we solve this problem.
When this route came in from eBGP, the advertising router--
in this case, R4--
set the next hop to be its own IP address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set the next hop to be its own IP address.
eBGP advertised routes changed the next hop address
to be its own IP address.
But routes that are forwarded through iBGP
never change the next hop address.
So the only way for R1 to have installed the route to 4.4.4.4
in its routing table, is if it could
reach the next hop address, in this case, R4's address.
How do we fix this problem?
That's what the next Nugget is all about. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's what the next Nugget is all about.
In the meantime, this is setting up
building an iBGP session versus an eBGP session,
and validating what's really going on under the hood.
I hope this has been informative for you.
And I'd like to thank you for viewing.