The iBGP nuances don't just start
with how routes are advertised to and from each other.
iBGP best practices dictate several different things to us.
One of those best practices is that peer relationships,
neighbor relationships, can and should
be formed based on loopback addresses.
Let's jump on the whiteboard and let me show you what I mean.
Here's the scenario.
We are AS100.
These are all of our routers.
We've got four routers on the board here.
And we are going to form iBGP relationships between them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we are going to form iBGP relationships between them.
Now because these are also our routers,
we have an IGP already running in between them.
Maybe it's running something like OSPF.
So we have connectivity around the horn.
And they even know about each other's loopback addresses.
So R1 has a loopback of 1.1.1.1.
R2 has a loopback of 2.2.2.2.
R3 has a loopback of 3.3.3.3.
And R4 has a loopback of 4.4.4.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R1 can ping 3.3.3.3, 4.4.4.4, 2.2.2.2 and so on.
So here is what I want to do.
I want to form an iBGP relationship from R1 to R2.
And I want this relationship to exist between my loopbacks.
Basically what I'm saying is when I issue my neighbor
statement, I'm going to say 2.2.2.2,
then the remote AS of 100.
And on R2 I'm going to issue my neighbor statement of 1.1.1.1 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And on R2 I'm going to issue my neighbor statement of 1.1.1.1
and the remote AS of 100.
Can you see where the problem may come in here?
Recall, when R1 and R2 send each other open packets, meaning
let's open our TCP179 connection to each other,
let's open our BGP session, how did it
determine how to do that?
In this case R1 issued the 2.2.2.2 statement.
It looked in its routing table.
And it saw the exit interface right here.
So the source packet is going to be 17216121. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the source packet is going to be 17216121.
Now, when R2 receives that, it's expecting the source address
to be 1.1.1.1, not 17216121.
And the neighbor relationship doesn't come up.
Let's verify this by jumping in the virtual lab right now.
So the first thing I actually need to do in the virtual lab
is I need to up stand up OSPF between these devices
so they know how to reach each other, including
those loopbacks.
From R1 we'll go into configure terminal, router OSPF 1.
And we'll just say grab everything-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll just say grab everything--
0.0.0.0-- oops, too many zeros--
0.0.0.0, area 0.
Cool.
Then on R2 we'll do the same thing--
router OSPF 1 network 0.0.0.0 0.0.0.0 area 0.
Cool.
We'll give it just a moment to converge.
And there we go.
There is the syslog message that says that we've
gone from loading to full.
If I give do a show IP route, I can
see I can now access 1.1.1.1 from R2.
We'll ping 1.1.1.1 and verify.
Yep, there we go.
Round trip looks good. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Round trip looks good.
OK, let's start building our BGP neighborship with R1.
But we're targeting a neighbor of those loopback addresses.
So we'll say router BGP AS 100.
Neighbor is going to be 1.1.1.1.
Remote AS is 100.
I'll jump over to R1, issue effectively the same commands.
Let's exit out of router.
There we go.
BGP 100 neighbor is going to be 2.2.2.2.
Remote AS is 100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Remote AS is 100.
At this point you would have expected the neighbor
relationship to come up.
Jump back to privileged mode.
We're going to turn some debugging on.
We'll do debug BGP IPv4 unicast.
And just press Enter.
There we go.
We've got some activity opening here.
I'm going to do an undebug all--
undebug all.
And here's what we're seeing here.
This is some pretty interesting output.
Right here, this line, we've gone active.
We went from idle to active.
Active means it's actively trying to build a BGP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Active means it's actively trying to build a BGP
relationship to each other.
But it's failing because the source address that it's
coming from doesn't match what's in our BGP neighbor
relationship table.
We have to change the source address
that we're advertising from.
Just like everything else with BGP,
this is neighbor-specific stuff.
So what I can do is I can go into configuration mode router
BGP 100.
And we can say for neighbor 2.2.2.2 update source, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we can say for neighbor 2.2.2.2 update source,
meaning what is the source address that we
want to come from?
And we specify a specific interface, in this case,
loopback 1.
Over here on R2, I'm going to do the same thing.
I'm going to say neighbor 1.1.1.1 update
source, meaning change my source address to be loopback 1.
And while that's going on, I see the neighbor relationship
comes to life.
There we go.
I see the neighbor relationship comes up on both sides.
So why does this matter?
Why did we do this? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Why did we do this?
We now have an iBGP relationship from R1 to R2 thanks
to because we're using loopbacks and we've changed the update
source that it's coming from.
If we had done it based on these physical addresses right here,
this would have been cool and it would've been great
until this link died.
Then we'd be scrambling to rebuild an iBGP relationship.
But because we used loopback addresses, this link can die.
And the iBGP would tell us a new path
to go through the network to get to our BGP near. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to go through the network to get to our BGP near.
We wouldn't have to reconfigure BGP.
We would just have to wait for OSPF to reconverge, which
probably will happen in less than the time
that the whole timer will expire.
So that's been why we use and how
we use a new source address when building our neighbor
relationship.
I hope this has been informative for you.
And I'd like to thank you for viewing.