- [Instructor] As we've already discussed,
neighbor adjacencies are necessary within BGP
if we want to exchange routing protocol information.
We know that we can use dynamic neighbor discovery
within a range of IP addresses,
but not in the same way that you may think
of with other routing protocols.
In other words,
broadcast or multicast messages
are not used to discover neighbors.
Instead, we manually configure a range
or a specific neighbor so that BGP
can use TCP port 179 for the connection.
Now again,
we can do dynamic neighbor formation
for a range of IP addresses
but this does work a bit differently from other protocols.
When BGP enabled routers are forming a neighborship,
we have six different states.
So let's examine each of those.
The first state is the idle state.
If we have two routers
and we're configuring BGP between those,
when we set that up locally
and enter a BGP neighbor command pointing
to a remote BGP router,
we go into the idle state,
where we're actively trying to establish a TCP connection
over port 179 to a BGP peer.
Also, we're listening for new connections
from a peer router.
Once our router is in the idle state
and we've tried to initiate a TCP connection,
our router moves to the connect state.
The connect state is where we're waiting
for the TCP connection to be completed.
So we have a three-way TCP handshake taking place.
Remember TCP uses a three-way handshake for communication.
We're going to wait in this connect state for 120 seconds,
which is what's called the ConnectRetry timer.
This is a value within BGP that is hard set
and we cannot change that.
Now depending on what happens with this timer,
we'll determine the next state that we move into.
Let's say for instance that we sit in the connect state
for 120 seconds and we have no successful TCP connection
and our retry timer reaches zero.
Now why might this TCP possibly fail?
Well, that could be from maybe a QoS rule.
Maybe we're dropping TCP traffic due to an ACL.
Maybe we've incorrectly configured a neighbor's IP address.
There are lots of things that can cause this.
But essentially if we have an error here
that allows our ConnectRetry timer
to decrement all the way to zero if 120 seconds go by,
then we move to the active state.
This is where the router will actively try
to establish another TCP connection with a peer.
This will last for an additional 120 seconds.
Now if we fail here,
we'll go back to the connect state
and we'll start this process over.
If we are successful,
then we move to the OpenSent state,
which we'll discuss in a bit.
So if we're having a TCP connection issue,
our states will just go in a loop
until we can correct that issue.
So I tend to think of these three initial states
as the TCP phase of BGP.
So I just mentally lump those together.
This helps me to remember that when I'm troubleshooting,
all of these work together.
So that's just a tip for you.
If you seem to be stuck in one of these three states
or if you're bouncing around between the states,
there's a good chance there's a TCP connection issue.
Let's say that our TCP connection is successful
from the active state.
As we said, we now move to the OpenSent state.
This is the first state where we actually start
to send BGP related messages.
So you can maybe see why I make a mental separation
between those first three states,
because they're solely reliant on TCP related information.
We send out now an open message
from our originating router to our remote BGP peer
and we're waiting to receive a similar open message back
from that remote peer.
These messages contain important BGP information
that will be compared between the two peers,
such as the BGP version,
the source IP address of the open message,
the autonomous system number,
the BGP RID,
and of course,
any security parameters such as the password.
If the initiating router receives an open message
from the remote peer that matches the local configuration,
then BGP will begin sending KEEPALIVE messages.
Those will make sure that the BGP session
remains established.
Now before we talk about the state
for successful communication,
let's look at what happens if we have a failure.
If the open message information received
from a remote peer does not match
what is expected on the initiating router,
then a notification will be sent to the peer
and this will signal the tear down of the BGP session.
This will take the router all the way back
to the idle state and will start over.
Now, it's worth noting
that we do not tear down the TCP connection.
We only tear down the BGP session.
So although we do go all the way back to the idle state,
we'll quickly move right back to the OpenSent state again.
So if you're bouncing in and out of the OpenSent state,
this is a really good indicator
that something in your BGP configuration
probably doesn't match between your local router
and your remote peer.
Now assuming everything does match,
assuming that we're able to establish a BGP session
and our open messages match,
we move into the OpenConfirm state.
In this state,
all we're waiting for are the KEEPALIVE messages
to be received.
Now if we do not receive those,
we'll again move back to the idle state
and we'll begin again.
If the peers exchange KEEPALIVE messages successfully,
we move to the state that we ultimately want
to see our BGP enabled devices in,
which is the Established state.
The Established state is where we send update messages
and KEEPALIVES between our peers.
This is where we finally exchange prefix information
through those update messages.
We also continue to exchange KEEPALIVE messages
to make sure the session remains established.
Again by default,
the KEEPALIVE interval is 60 seconds
and the hold time is 180 seconds.
Those can be changed if desired
but those are the default values which are in place.
Now as I do with the first three states,
I also categorize the last three together
as their own phase,
which I call the BGP phase.
So if we see our router stuck
in one of the first three states,
that would be idle, connect, or active,
we can consider that to likely be a TCP related issue
when troubleshooting.
But if we seem to be bouncing around
in these last three states which are OpenSent,
OpenConfirm, and Established,
then we want to start troubleshooting
the actual BGP configuration.