[AUDIO LOGO]
So now that we have a game plan together,
our first step with configuration
is going to be to configure our iBGP peers in AS 65001
and 65002.
So that's what we're going to be doing in this video.
Let's once again bring up our topology
just as a reminder of what we're going to be building here,
and then we'll jump into the command line
and get these neighborships up and running.
So the part that we'll be setting up in this video
is we'll be neighboring up router 1 to router 2, router 1
to router 5, router 1 to router 4, and router 1 to router 3.
Then we'll jump over to AS 65002,
and we'll set up that neighborship between router 6
and router 7.
Keep in mind with this design of iBGP neighborships in 65001,
we're ultimately going to need router 1 to be a route
reflector.
This, of course, is because of BGP's rule of split horizon
where we can't take an update from an iBGP neighbor
and send it to another iBGP neighbor.
That's of course why iBGP normally has to be a full mesh,
and as we can see here, we're clearly not building
out 65001 as a full mesh.
So we're going to have to do more in that AS
as we go through our design here.
But for now, we want to leave it as it is.
In other words, just building the neighborships
so we can actually see the problems that
come up before we make router 1 a route reflector.
So again that will happen, but it
will happen a little bit later.
Now technically in 65002 we do have a full mesh
because there's only two routers and they're
going to peer with each other.
So 65002 is not going to have a problem, but 65001 will.
Just so we're aware of it going in, we're expecting that,
but we also want to examine it.
So now let's go ahead and jump into the command line
and get started.
We may as well begin on router 1 since clearly it has
the most amount of work to do.
So the first thing we have to do is create our process.
So it's going to be router BGP and, of course,
the AS here is 65001.
We'll set our router ID.
We'll just set it to its loopback address, which
is 10.1.1.1, and then we'll begin configuring our address
family IPv4 unicast.
Since router 1 is actually going to have a significant amount
of configuration here, let's go ahead
and use a neighbor group on router 1.
We'll call it iBGP_PEERS.
And since they're iBGP, that means
that they're going to be in the same remote AS.
We also said we were going to peer using our loopbacks,
so we'll set our update source to loopback 0.
And, of course, we want to activate the address family.
Next, let's configure our neighbors
to actually use this neighbor group.
So first we'll do neighbor 10.2.2.2,
And we'll say use neighbor-group,
and we'll put in our name iBGP_PEERS.
Now we're going to do the same thing for the other three
neighbors.
So let's just go ahead and change the addresses.
It's going to be neighboring up with 3, 4, and 5.
We'll commit our changes, and we'll exit configuration.
So next let's hop over and configure router 2.
Again, this is going to be in 65001.
We'll set its BGP router ID, enable our address family,
and here we'll just configure router 1.
Again, iBGP so it's the same AS number.
We'll set our update source, and activate our address family.
Exit configuration.
And we should see that neighborship come up.
So it got buried in the other console messages
there a little bit, but if we look at this line,
we can see that the neighbor did come up.
To make it easier, we'll do a show BGP summary,
and we can see that the neighborship with router 1
is in fact up.
It's been up for 17 seconds.
It hasn't exchanged any prefixes yet.
However, the fact that that is a number
indicates that it's actually up, even though that number is 0.
Next, we configure routers 3 and 4.
They get an identical configuration to router 2,
so we'll do a little bit of copying and pasting here,
but we will have to change the router ID.
So let's start off putting that configuration in Notepad.
So this is the configuration we're going to be using.
We just need to change our router ID here to be router 3.
Highlight everything and copy it.
And then back on router 3 we simply paste it.
We should see router 1 come up.
It did.
So then we can see that router 1 has been up for 4 seconds,
and now let's grab the config for router 4.
Again, we'll change the 3 to a 4.
Highlight everything, copy it, and paste it on router 4.
And again router 1 is up.
Now we can't exactly copy and paste directly onto router 5
just because it is iOS XE, so it's slightly different.
We'll just do that one manually.
Still, of course, we create the BGP process.
We'll still set the router ID, but here we go directly
to neighbor configuration.
So it's router 1.
And then, of course, the settings for those neighbors
actually go on the neighbor statements in iOS XE.
So we'll set the update source to loopback 0.
So here we can see that router 1 came up,
but we'll still do our show BGP summary.
And we can see that router 1 has been up for 22 seconds.
So that takes care of all of our neighborships in AS 65001.
Now let's go do AS 65002.
We'll just jump into router 6.
Again, this is 65002.
Well, of course, at the BGP router ID still,
and we'll set up router 7 as our neighbor of course
in the same AS since it's iBGP.
Update loopback 0, and we'll exit configuration.
It's going to be a very similar configuration on router 7,
but since we have to mirror 3 out of our 4 commands anyway,
it's not really necessarily worth using Notepad here.
So again, BGP process.
Set the router ID, the remote AS, and set the update source.
Now something to note here, see that our neighborship came up
before I even hit Enter on the update source
loopback 0 command.
The fact of the matter we're only creating a TCP session
to exchange our BGP updates, and that session only
has to happen between one pair of IP addresses.
You don't technically need the update source loopback 0
on both sites in a connection like this.
If you have it, what it'll do is it'll create two TCP sessions
and then tear one of them down, and at the end of the day,
you only have one session left.
Just like when my neighborship came up here,
it had only formed one TCP session.
And we know this because, of course,
BGP will only accept the TCP connection
from the neighboring address that
matches its neighbor statement.
So since router 6 was configured with a neighbor statement
of 10.7.7.7, it would not have accepted our neighborship
until we set the update source here.
However, here on router 7, I set the neighbor as 10.6.6.6
so I accepted its packets on TCP port 179,
and our neighborship was established,
and we came right up.
It only ever established that one TCP session,
but actually that's all we need.
So you might be looking at this and maybe you're
thinking to yourself, well, if we only
need update source loopback 0 on one side,
why do we always put it on both sides?
And the answer is honestly best practice.
It doesn't really have to be on both sides,
but we normally put it there anyway,
I just wanted to point that out so you
can understand why our neighborship came up here
before I even hit Enter on that update source loopback 0.
So after that whole discussion it
might be a little bit of a moot point,
but let's still just do our show BGP summary
just so we can verify that it is in fact up.
And after all that explanation I did,
it's actually been up 3 minutes now.
So now we have our four iBGP neighborships up on router 1,
and our one BGP neighborship up between routers 6 and 7
in AS 65002.
So in this video, we jumped into the command line
and we got our iBGP neighbors set up
in two ASs that need iBGP neighborships, AS 65001 and AS
65002.
Now, of course, we have to start setting up neighborships
between our confederations, and that's
exactly what we're going to do in the next video.
I'll see you there.
I hope this has been informative for you,
and I'd like to thank you for viewing.