- Now that we understand some fundamental information
about BGP, including the different states
and timers involved, let's configure BGP,
and take a look at neighbor formation.
We've got a very basic topology here.
We have router one in autonomous system 65100,
and we have router two in autonomous system 65200.
Let's start our configuration on router one,
and our interfaces are already configured
with IP addressing.
The first thing we need to do is initialize the BGP process.
We'll go under global configuration mode
on router one and say router BGP,
followed by the autonomous system number.
And locally you can see from our topology that is 65100.
So we'll hit Enter for that.
And once we do that
you can see we're now in BGP configuration mode.
An optional step here is to define the BGP router ID.
And we discussed in a previous video with our BGP theory
that this is a unique 32-bit number to identify
our BGP router in the advertised prefixes.
We can set that manually
or we can allow that to be dynamically assigned.
If we allow it to be dynamically assigned,
the highest IP address for any loopback interface
in the upstate is going to be assigned as the router ID.
If we don't have a loopback address,
then it's going to fall back to the highest IP address
for any active interface.
And we can use any IP version four address
when we're manually assigning those.
It doesn't have to be an address configured
on any of the router interface.
Cisco actually tells us that it's a best practice
to manually assign the router ID.
So let's do that.
We'll say, BGP router-id,
and I'll make that 1.1.1.1 since we're on router one.
Next, we want to identify the remote BGP peer
by IP address and autonomous system number.
So we'll say, neighbor and we'll follow that
by the IP address on the remote peer
to which we are connected which you can see is 10.1.1.2.
Then we want to say remote-as
to identify the autonomous system
in which that remote peer is in.
And that is of course 65200.
Another step which is optional
is to specify the source interface for our BGP session.
Now, why would we want to do that?
Well, let's say we have multiple paths for redundancy
between two autonomous systems.
This would allow us to choose a loopback interface
on router one as the source for our BGP session.
Now in our case with only two routers
and a single connection between them,
this obviously isn't necessary, but just for completion,
I want to show you how we could do that.
We would say neighbor, we would say 10.1.1.2,
which again is router two's IP address
followed by the update-source keyword.
And then most typically you can see the options here.
We would identify one of our interfaces.
For example, loopback zero.
That's pretty common thing to do is to set the loopback
as the update source.
Again, it's redundant in our case so I'm going to skip that.
One other thing we can do
is manipulate our BGP timers, those being the keep-alive
and the hold-timers .
By default, our hold-time is set to 180 seconds
or three minutes.
And that means that our BGP session requires a packet
to be received at least every three minutes
in order to maintain that session.
The keep-alive message is going to be sent by default
every 60 seconds
or in other words 1/3 of the hold-timer.
And this one to three ratio is actually recommended
in the BGP RFC.
So it's not recommended that we would set that
to a ratio that's larger than 1/3.
So for example one half, that would not be ideal.
But we can set it to one quarter
and that will still be acceptable.
Now, three minutes, that's a long time
to keep sending traffic to a dead router.
If you work for an ISP and you have a three minute outage,
that's going to seem like way longer than three minutes.
There's lots of things that can go wrong
in that three-minute window.
So let's say this to something more convenient.
We can do that by saying, "Timers BGP,"
and if we look at contextual help
the very first one we can set is the keep-alive timer.
So I'm going to set that to every five seconds.
And if we check out our contextual help once more,
the second value is going to be the hold-time.
So I'll set that to 20.
So again, the first number we put in
is the keep-alive interval,
the second number is the hold-time.
Next we going to initialize an address family
between our peers.
Since BGP carries all kinds of diverse routed protocols,
we need a way to tell BGP which address families
should be exchanged with a neighbor.
Now, in our case this is again something
that would be redundant, but I do want to show you
how to do that for completion.
If we want to exchange IP version four routes
with a neighbor, which we do from router one.
We can say address-family,
and if we look at our contextual help options
the one we want is IP version four
and you can see the different options
that we have available to us in there.
We could also say IP version six, if we wanted to do that.
But, in our example again, we want IP version four.
We also have the option to append
what's called a Subsequent Address Family Identifier,
or an S-A-F-I.
If we look at contextual help, you can see those here.
Examples would be multicast or unicast.
Now in our case,
we want all IP version four route information
to be exchanged.
So we can simply hit Enter here without adding a qualifier
at the end.
Notice we're now under address family configuration mode.
And from here we need to identify the peer
that we want to activate for this address family.
So let's say neighbor 10.1.1.2
and the key word activate to finish that.
Now we looked at using that address family command,
but I'll also point out
that if we don't explicitly configure this,
for IP version four as we just did
this is actually the default assignment within Cisco iOS.
BGP is going to implicitly assign all defined neighbors
to an invisible address family section
and that will show up in your running output.
So again, this wasn't necessary in our case,
but I did want you to be aware of that
in case you wanted to define something different
such as IP version six or a VPN version four, for example.
Now we can optionally enable BGP authentication.
Let's back up a step,
so that we're back under BGP configuration mode
and not under address family configuration mode.
This is going to use an MD5 hash
to prevent the manipulation of our BGP packets.
Otherwise it would be easy to spoof
or manipulate BGP packets
that are being transmitted between our peers.
Now you are likely aware that MD5 has a known weakness
and it isn't the best algorithm out there
but that's all we have in BGP.
And so that's at least better
than sending our information in clear text.
So again, let's say neighbor 10.1.1.2,
followed by the keyword password.
And I'll set that to Cisco one, two, three.
With all that in place let's jump over to router two
and let's do something very similar.
We'll go under a global configuration mode.
We'll say router BGP 65200 this time
because that's the autonomous system number
that we're in.
BGP router-id.
I'll make that 2.2.2.2.
We want to identify our neighbor, which is 10.1.1.1
in this case router one
and remote-autonomous system is 65100.
Let's set our authentication
by saying neighbor 10.1.1.1 password Cisco one, two three.
And then of course we can set our timers, timers BGP.
I set that to five and 20.
And you'll notice that we have formed a neighbor adjacency.
We got a message in our console
so that's a really good sign.
We'll skip the manual address family configuration here
since I already explained that this is the default behavior.
So there we go.
Let's do some verification.
Let's jump back over to router one now.
I'll point out here
that you'll notice we had some bad authentication messages
because we had not yet defined the password.
The authentication password on router two.
We entered that first neighbor command
to try and form a neighbor adjacency here.
But until we had actually put in that password
we were getting some authentication errors
but our adjacency did come up so that looks good.
Let's break out of here.
And let's say show BGP, we'll say IP version four
and you can see the options under there.
I'm going to say unicast summary.
And if we do that, you'll notice that we do see router two
as our neighbor at 10.1.1.2.
We see the BGP version under the V,
which is using BGP version four.
You can see that highlighted here.
We see the autonomous system number of our neighbor,
which is 65200.
We can see the count for the messages received and sent,
and we can see the length of time that our BGP session
was in the upstate.
We see the status for that.
We can use another verification command
to see neighbor session information
and that is show BGP, IP version four neighbor.
Actually, we need this also say unicast here neighbor.
And if we hit Enter with that,
we get lots of information here.
If we look through this information
we can see our neighbors IP address.
We let it finish the output.
Okay, I'll scroll back up a bit.
And we see the session to 10.1.1.2,
which is of course router two.
We can see if we go up some more.
We can see again our remote autonomous system number.
We can see we're using BGP version four.
We see the router ID of our neighbor, which is 2.2.2.2.
And of course we see that this is established
and in the upstate,
we also see where we configured our hold
and keep-alive timers.
So everything that we've configured here is good.
We see everything that we would expect to see.
If we scroll down we'll also find ,
if you remember this uses TCP port 179.
And we can see right here, the foreign port is 179.
So everything looks exactly as we would want to see.
That's the default TCP port for BGP.
So that's a look at creating a BGP neighbor adjacency.