This right here is where BGP steps it up a notch.
How BGP handles incoming and outgoing routes
to and from which neighbor is kind of a big deal.
Understanding the process that BGP
takes towards bringing routes in and sending routes out
is going to be critical for you to master BGP.
So let's jump in a whiteboard, and let
me show you the diagram of how the roots flow through BGP.
At the end of the day, BGP does three things.
It brings routes ends.
It processes those routes, and it sends routes out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It processes those routes, and it sends routes out.
There's three databases, three separate databases,
that handle those three things.
I'm going to circle those three databases right now here
in blue.
This is the RIB-In.
This is the Local RIB.
You can see they call it BGP Database right here.
And then this is the RIB-Out.
These are the three databases.
There are show commands to view the Local RIB and the Rib-Out.
There is not a show command to view the RIB-In. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There is not a show command to view the RIB-In.
Why?
Because so many routes come in, and so many routes
are processed that, after the routes have been processed,
this table gets truncated or a fancy way of saying it's empty.
So you could run the show command,
but there wouldn't be anything there.
So this is where we're going to start.
We're going to start our journey.
I'm going to change my color here
so it doesn't get confused with the databases, starting
the journey right here with routs
that come in from up here.
This is either an iBGP or an eBGP here.
They've typed in the network command on their side, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They've typed in the network command on their side,
and they've sent us an NLRI.
Recall that's a prefix, as well as path attributes.
The NLRI is stored in the RIB-In,
and then inbound route policies are applied to the RIB-In.
You're going to learn a lot more about these policies
when we get towards filtering BGP.
These are primarily route maps, but they
can be distribute lists, prefix lists, and autonomous system
ACLs.
They could be filtering routes out, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They could be filtering routes out,
or they could be adjusting path attributes.
They could be setting a new weight
or a new local preference.
Once the inbound route policies have been applied,
they go into the local rib database.
You've seen this.
This is show ip bgp.
Remember, when we were troubleshooting,
why R1 couldn't reach R4?
It showed the route, but it wasn't
a best route because it had a next hop
path that we didn't understand. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
path that we didn't understand.
We were looking at this database right there.
Right here is why that route wasn't
installed in our routing table.
At the time, R1 couldn't reach 45
because R2 had sent us that prefix,
but didn't change the next hop address.
Because the next hop wasn't valid,
it never got sent down here to install routes
in the global routing table.
Remember, what we had to do is, on R2, we
had to change the next hop address with next-hop-self
because that's the behavior of iBGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because that's the behavior of iBGP.
Once we did next-hop-self, it past the next hop and validity
check and identified the best BGP path.
Well, there was only one path, and that was to AS200.
So the route was installed in the global RIB.
The flip side of that is we advertised the 1.1.1 address
over to R2 who then advertised it up
to R4 because there was no outbound policy stopping us
from doing that.
The route was installed into the outbound database
and then forwarded to appear. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then forwarded to appear.
Now, this show command is not one that we've seen yet.
Let me bring up the virtual app and show you
what that looks like.
From Privileged Mode, if you want
to see the routes that you're sending outbound
towards a neighbor, we can do show bgp ipv4
unicast because we are advertising an ipv4 unicast
address.
I'll give it a question mark, and we can specify our neighbor
right there by specifying neighbors,
so I'll say neighbors, 100.100.24.4 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so I'll say neighbors, 100.100.24.4
And then we can specify the property of advertised routes.
Look at that.
This is showing us the outbound database
for a specific neighbor.
Yes, there will be a separate database for every neighbor,
but it does show us what routes we are advertising
towards R4 in this case.
Now, that example was particularly interesting
because we learned about 1.1.1.1 from R1.
This was brought into the inside database.
There were no policies processing it out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There were no policies processing it out.
It was dumped into the BGP database.
We had a valid next hop.
The best path was identified because there was only one AS
to traverse.
We had no outbound policy stopping us
from sending it outbound, so we sent it outbound towards R4.
There we go.
What if we had issued our own network statement?
If you notice when we issue our own network statement,
it first checks to make sure that that network exists
in the routing table.
Remember, when we were specifying masks earlier,
we couldn't just specify a range of addresses. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we couldn't just specify a range of addresses.
We had to specify a specific address that we could send out.
We can only advertise networks that we actually do know about.
Once it validated that the routes that we were advertising
with the network statement were in the routing table,
it goes ahead and puts it into the local RIB database.
So none of this part is happening.
There is no RIB-In when we specify a network statement.
Why does this process matter?
Because you need to know when policies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because you need to know when policies
are going to be applied, and you also
need to know about these steps in order to troubleshoot things
that are going wrong with BGP.
Now you can look at what routes you've received
and figure out maybe why they're not in the routing table,
or you can validate that you did send a route to appear and have
them look into it, too.
This has been understanding the BGP
process, critical steps to understanding your BGP journey.
I hope this has been informative for you,
and I'd like to thank you for viewing.