|
0:00:15
|
In our next section of BGP, we're gonna look at the specifics of doing IBGP peerings.
|
|
0:00:20
|
Some of the different design choices that we can use
|
|
0:00:23
|
either of having a full mesh of peerings using route reflection or using confederation.
|
|
0:00:28
|
Now again, the key design point to keep in mind here with IBGP
|
|
0:00:34
|
is that by default, anytime we learn a route from an IBGP neighbor,
|
|
0:00:38
|
we will not advertise it on to another IBGP neighbor.
|
|
0:00:42
|
So, the default implication of this means that there has to be a full mesh of peerings between all of the devices.
|
|
0:00:48
|
Now, as I mentioned previously, this would give the routers the most diverse view of BGP topology.
|
|
0:00:56
|
Then, have them enable to choose
|
|
0:00:58
|
whatever particular path that they want to out of the network.
|
|
0:01:02
|
But it's gonna be at the sacrifice of the...
|
|
0:01:04
|
amount of overhead in the control plane.
|
|
0:01:07
|
So, if we're looking at this from the perspective of the global BGP table,
|
|
0:01:11
|
for every EBGP peer that we have,
|
|
0:01:13
|
there's gonna be somewhere around 3 to 400,000 routes.
|
|
0:01:17
|
Then, if we are peering with every single internal to our network,
|
|
0:01:21
|
it means that we have to send those 3 to 400,000 update messages out to each of those peers.
|
|
0:01:29
|
So, it will give us the most options for path selection,
|
|
0:01:33
|
but again, it's gonna be at the sacrifice of the amount of control plane overhead.
|
|
0:01:40
|
So, in our next example, we're gonna look at all of the devices inside of the...
|
|
0:01:45
|
the internal network here, inside the same autonomous system.
|
|
0:01:49
|
Where this AS is going to be 100.
|
|
0:01:53
|
So first, I'm going to establish the EBGP peerings
|
|
0:01:57
|
from router 4 and 6 to AS 54.
|
|
0:02:02
|
Then, from router 2 to AS 254.
|
|
0:02:07
|
So, those are gonna be the external peerings where we are learning routes
|
|
0:02:10
|
from outside of our autonomous system.
|
|
0:02:12
|
Then, our ultimate goal is to take these routes and pass them to the internal neighbors.
|
|
0:02:18
|
So first, let's start on router 4 and router 6
|
|
0:02:22
|
who are on the network edge.
|
|
0:02:23
|
And from router 4's perspective, we should be establishing a peering with the address 204.12.28.254,
|
|
0:02:32
|
which is BB3's address.
|
|
0:02:34
|
Now, before we even do this, we could do a basic low level connectivity test in BGP
|
|
0:02:40
|
to figure out if we have transport to that address,
|
|
0:02:45
|
and whether or not that remote neighbor is going to accept the BGP peer from them.
|
|
0:02:51
|
The way we can do this is to try a telnet
|
|
0:02:56
|
going to the particular address using port 179.
|
|
0:03:02
|
Now, we could see on router 4, we did get an open message back from the telnet,
|
|
0:03:07
|
which essentially means that just in a basic Layer 4 point of view,
|
|
0:03:12
|
this remote neighbor is listening for BGP session to come in from router 4.
|
|
0:03:19
|
Now, if the remote neighbor is not configured
|
|
0:03:22
|
with the peering session on the way back,
|
|
0:03:24
|
then, we would see that the connection is simply gonna be refused.
|
|
0:03:28
|
So, for example on router 4, if I were to telnet to...
|
|
0:03:34
|
let's say, router 6's loopback
|
|
0:03:37
|
at port 179,
|
|
0:03:40
|
I could telnet to router 6's loopback on its own.
|
|
0:03:42
|
So, this tells me, I do have basic connectivity.
|
|
0:03:45
|
But if I were to try to do this at 179,
|
|
0:03:48
|
the connection is refused,
|
|
0:03:50
|
because when I send the syn packet to 6,
|
|
0:03:53
|
6 is not running the BGP process yet with router 4.
|
|
0:03:56
|
So, it replies with a reset.
|
|
0:04:00
|
So, as we could tell where the first telnet to the remote neighbor opens,
|
|
0:04:05
|
the second telnet to router 6 is denied.
|
|
0:04:07
|
It means that this particular neighbor is configured within BGP session back to us.
|
|
0:04:12
|
So, for some reason, we're having problems establishing the session,
|
|
0:04:16
|
that would be a good Layer 4 test
|
|
0:04:19
|
to see if whether just the BGP process is configured,
|
|
0:04:22
|
and we don't have any type of Layer 2 or Layer 3 filtering issues on the network.
|
|
0:04:28
|
So next, let's actually configure the BGP process.
|
|
0:04:32
|
This is router BGP 100 on router 4.
|
|
0:04:35
|
And we'll peer with 204.12.28.254.
|
|
0:04:39
|
Their AS number is 54.
|
|
0:04:44
|
Now, these values, this is not something that we could guess in the topology.
|
|
0:04:48
|
We'd have to be provided with whatever the address is that we're trying to peer with,
|
|
0:04:52
|
and whatever the autonomous system number that they have configured is.
|
|
0:04:57
|
Likewise, on router 6, if we look at the Show IP Route Connected,
|
|
0:05:02
|
our link to BB1 is 54.28.1 and their address is .254.
|
|
0:05:10
|
So on router 6, we'll configure BGP 100.
|
|
0:05:15
|
And we have the neighbor 54.28.1.254.
|
|
0:05:20
|
They are in AS 100.
|
|
0:05:27
|
On router 2's connection,
|
|
0:05:29
|
actually, no, they are not in 100. They are in 54.
|
|
0:05:34
|
So, we see, the notification message there,
|
|
0:05:36
|
that means that I've configured the wrong autonomous system number.
|
|
0:05:40
|
So, they should be in...
|
|
0:05:43
|
54.
|
|
0:05:49
|
And we should see the BGP peering come up here.
|
|
0:05:56
|
Which we have. Now, on router 2,
|
|
0:06:00
|
it's connection is gonna be to 192.10.28.254,
|
|
0:06:07
|
which we do have connectivity to.
|
|
0:06:09
|
But in this particular design,
|
|
0:06:12
|
BB2 is configured to peer with router 2 using AS number 200.
|
|
0:06:19
|
So, in most of our examples, you would see that
|
|
0:06:21
|
whoever is attached to BB2 actually would have the BGP process configured as 200,
|
|
0:06:27
|
because this is what the neighbor statement is pre-configured on the backbone router.
|
|
0:06:32
|
Now, there can be certain designs
|
|
0:06:35
|
where the BGP neighbor do not agree on the AS numbers and it's still correct to have that.
|
|
0:06:41
|
Typically, in a real world design, it's when you're doing an AS migration
|
|
0:06:45
|
from an old autonomous system number to a new autonomous system number.
|
|
0:06:49
|
And this is what under the BGP process,
|
|
0:06:53
|
the neighbor...
|
|
0:06:58
|
So, they are gonna be in...
|
|
0:07:00
|
remote AS 254.
|
|
0:07:03
|
Then, our command to change our local autonomous system,
|
|
0:07:08
|
this is when we send the BGP open message.
|
|
0:07:12
|
This is the value that we're gonna use in that particular communication.
|
|
0:07:17
|
So normally, the local autonomous system number is gonna come from whatever we have configured globally.
|
|
0:07:23
|
But in the case where the global AS number doesn't agree with what that particular neighbor is listening for,
|
|
0:07:29
|
we can use a different value for the local AS.
|
|
0:07:34
|
Now, if you look at the specific options in this command, there's some other...
|
|
0:07:38
|
features for the configuration
|
|
0:07:41
|
depending on the version, the no-prepend here,
|
|
0:07:43
|
it means that we will not add the AS number 200
|
|
0:07:49
|
as the routes are coming in from the neighbor.
|
|
0:07:53
|
Then, replace AS,
|
|
0:07:56
|
dual AS...
|
|
0:07:58
|
would allow us to support configuration where BB2
|
|
0:08:03
|
is migrating its neighbor statement or currently, it's gonna say, Neighbor...
|
|
0:08:09
|
whatever router 2's address is.
|
|
0:08:11
|
Remote AS 200.
|
|
0:08:15
|
But then, in the future, it's gonna update this command. So, it says that the remote AS is 100.
|
|
0:08:21
|
That's what the dual AS support is for.
|
|
0:08:27
|
So again, the design about this would be that
|
|
0:08:29
|
AS 100 has just acquired AS 200.
|
|
0:08:33
|
While all of the remote peers are waiting to update their configurations,
|
|
0:08:37
|
we can do a kind of a hack on the process
|
|
0:08:40
|
that's a temporary band-aid for the configuration.
|
|
0:08:43
|
But router 2 says that "I send my updates out to BB2,
|
|
0:08:46
|
I'm gonna tell them that I'm in AS 200."
|
|
0:08:50
|
Now, if I know that some time down the road,
|
|
0:08:52
|
they're gonna update their configuration to point at 100,
|
|
0:08:55
|
but I don't exactly know when,
|
|
0:08:58
|
then, router 2, with the dual AS support
|
|
0:09:01
|
would be able to offer them whichever value that they want.
|
|
0:09:05
|
So, it essentially sends two separate open messages: one for AS 100; and one for AS 200.
|
|
0:09:10
|
Then, they're gonna accept whichever one that they have configured on their side.
|
|
0:09:18
|
So, once we have this configured, if we look at the Show IP BGP Summary,
|
|
0:09:25
|
we should ideally see that the peering comes up.
|
|
0:09:29
|
Now, from this output, in Show IP BGP Summary, what we wanna look at here
|
|
0:09:33
|
is that there's some timer value that's associated with the neighbor.
|
|
0:09:37
|
And the state here doesn't have either active or idle.
|
|
0:09:41
|
It should be some numerical value.
|
|
0:09:45
|
So, any integer zero or above,
|
|
0:09:48
|
that's gonna show us how many particular routes we are receiving from that neighbor.
|
|
0:09:52
|
Where in this case, it says that the neighbor is active.
|
|
0:09:57
|
It means that there's something wrong in the peering.
|
|
0:10:01
|
Now, to figure this out, sometimes, there'll be issues where you can't actually see it from the debug,
|
|
0:10:07
|
but when we look at router 2 and look at the Debug IP BGP,
|
|
0:10:13
|
let's see if we received an open message in from...
|
|
0:10:20
|
backbone 2.
|
|
0:10:22
|
Now again, this should be the correct address, if we ping...
|
|
0:10:27
|
to that neighbor. Okay, we do have connectivity.
|
|
0:10:38
|
Then, let's look at the Debug IP Packet.
|
|
0:10:42
|
But I'm gonna look at this just for...
|
|
0:10:47
|
just for BGP traffic.
|
|
0:10:50
|
So, I'll say, Access List 100 Permit TCP Any Equal to...
|
|
0:10:56
|
BGP Any,
|
|
0:10:58
|
and Any Any Equal to BGP.
|
|
0:11:01
|
Because again, I need to account for either source port 179 or destination port 179.
|
|
0:11:08
|
Then, I'll say, Debug IP Packet Detail 100.
|
|
0:11:16
|
Now, I may not be able to see this particular...
|
|
0:11:21
|
output on router 2 what the problem is,
|
|
0:11:24
|
but specifically in this case, BB2 is configured to accept an authenticated session from router 2.
|
|
0:11:32
|
Where router 2, I haven't configured it with a password.
|
|
0:11:35
|
So, it's not going to be able to establish the session.
|
|
0:11:39
|
We should see though if I Clear IP BGP,
|
|
0:11:41
|
we should see router 2 trying to send the packets and then getting the session denied.
|
|
0:11:48
|
Unless I'm not logging...
|
|
0:11:52
|
No, I'm logging to the console, because it does show the...
|
|
0:11:56
|
the output there. Let's try this, let's Show Run Section Router BGP.
|
|
0:12:10
|
So, it is the correct value here. Let's try this. Let me remove the BGP process.
|
|
0:12:22
|
And then, I'll reconfigure it. So, BGP 100.
|
|
0:12:26
|
I have that particular neighbor.
|
|
0:12:28
|
So, we should see router 2...
|
|
0:12:35
|
send the packets out locally,
|
|
0:12:41
|
but it's not generating them.
|
|
0:12:43
|
So, what this means is that...
|
|
0:12:48
|
I'll see, this is on a connected link.
|
|
0:12:50
|
The neighbor that's not doing the authentication,
|
|
0:12:53
|
there's really nothing the debug that's gonna show us that.
|
|
0:12:56
|
Now, if we did configure the authentication and the password was wrong,
|
|
0:13:02
|
we will get a log message saying that the MD-5 hash is incorrect.
|
|
0:13:06
|
So, if I say, "For this neighbor, the password is ABC",
|
|
0:13:11
|
we'll see that once we try to establish the session,
|
|
0:13:13
|
we're gonna get a log message back in saying that the MD-5 digest is incorrect.
|
|
0:13:20
|
Which essentially just means that the password is wrong.
|
|
0:13:33
|
So, let's try Clear IP BGP.
|
|
0:13:35
|
And like I mentioned before, a lot of this is really slow to converge.
|
|
0:13:38
|
So, if there is a problem in the establishment,
|
|
0:13:41
|
it may take a while to even figure out what the problem is to begin with.
|
|
0:13:51
|
So, let's let this debug run for a little bit.
|
|
0:13:53
|
And let's move on to the other peerings.
|
|
0:13:56
|
Now, what I'm gonna do here is that
|
|
0:13:59
|
without having to do route reflection or confederation,
|
|
0:14:01
|
it means that we're gonna need a full mesh of peerings in the topology.
|
|
0:14:06
|
So, configuration wise, it means that each router
|
|
0:14:09
|
would need 9 neighbor statements pointing to all of the other devices in the topology.
|
|
0:14:15
|
Which is feasible. It's not that bad to maintain just 10 peerings.
|
|
0:14:19
|
But if there's a hundred, or a thousand routers in the network,
|
|
0:14:22
|
then, a lot of times, doing the full mesh is not gonna be feasible.
|
|
0:14:26
|
Now, one way I can simplify this...
|
|
0:14:29
|
is to take the IBGP peers,
|
|
0:14:31
|
and put them into a template of configuration that is called the Peer Group.
|
|
0:14:35
|
So, when I'm going to create the peer group, I'm going to apply different attributes on to it
|
|
0:14:39
|
like the remote AS number, the update source,
|
|
0:14:43
|
maybe if I'm doing some sort of route map filtering.
|
|
0:14:46
|
I could apply it on to the peer group,
|
|
0:14:48
|
then, put the actual neighbor's address into the peer group,
|
|
0:14:52
|
in which case, they are going to inherit all of that configuration.
|
|
0:14:57
|
Now, the peer group configuration will also be an optimization
|
|
0:15:01
|
of the actual update state machine.
|
|
0:15:07
|
Because there is one update that is sent to the entire peer group
|
|
0:15:12
|
as opposed to the individual updates that are sent to the neighbors.
|
|
0:15:16
|
So, it essentially means that if I have 10 neighbors in the peer group,
|
|
0:15:19
|
the best path selection is only run once for all 10 of those neighbors
|
|
0:15:23
|
as opposed to run 10 separate times depending on their individual policies.
|
|
0:15:29
|
So, to do this, we'll start the BGP process. BGP 100.
|
|
0:15:34
|
I'll specify a neighbor, and give it a name. I'll say that this is my IBGP peers.
|
|
0:15:39
|
And this is a peer group.
|
|
0:15:42
|
The neighbor IBGP peers,
|
|
0:15:44
|
everyone in it is gonna be in AS 100.
|
|
0:15:48
|
The update source is gonna be my loopback.
|
|
0:15:51
|
So, I'm assuming up to this point, I already have connectivity between all of the loopbacks.
|
|
0:15:57
|
Then, I would need to specify for the actual neighbor addresses,
|
|
0:16:02
|
150.28.2.2, it's part of the peer group, IBGP peers.
|
|
0:16:11
|
Then, 3.3.
|
|
0:16:14
|
4.4., etc. for all of the addresses.
|
|
0:16:18
|
So, what makes it easier about this configuration now,
|
|
0:16:22
|
not only is it an optimization behind the scenes of how the update process works,
|
|
0:16:26
|
it makes it easier that I can just apply this template on to all of the routers.
|
|
0:16:31
|
So now, I could go to our no path configuration,
|
|
0:16:35
|
and simply say that "I'm gonna take this same type of template,
|
|
0:16:39
|
and then, basically apply it to everyone."
|
|
0:16:43
|
So, I have peers 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10.
|
|
0:16:56
|
Now, depending on where we're referencing this configuration from,
|
|
0:17:00
|
one of the commands is gonna get kicked-out,
|
|
0:17:03
|
because it's not possible to peer with your own local address.
|
|
0:17:06
|
So, when I apply this configuration on router 1,
|
|
0:17:09
|
it's gonna tell me I can't peer with my own local address.
|
|
0:17:13
|
Okay, which is fine, because the parser it's just going to ignore that command.
|
|
0:17:19
|
But now, I can't take this template of config, and basically apply it on everyone,
|
|
0:17:24
|
and I should see the full mesh of peerings come up.
|
|
0:17:28
|
So, I'll do this just on the access server, I'll say, Send Star (*).
|
|
0:17:34
|
And then I have all 10 of these peerings.
|
|
0:17:36
|
Now, you could see, the send command, it didn't read the entire buffer.
|
|
0:17:41
|
So, probably some of the commands were taken, but not all of them. So, I need to cut down a couple of these lines.
|
|
0:17:50
|
I mean, it may need to send this in two separate groupings. Let's do this.
|
|
0:17:56
|
So first, we'll send the peer group config.
|
|
0:18:06
|
Then, the second portion, that is the neighbor statements.
|
|
0:18:11
|
So essentially, this would be the same as going to each of the consoles and just pasting the syn,
|
|
0:18:15
|
but doing it from the access server is gonna save a little bit of the time here.
|
|
0:18:24
|
So now, if we were to look at router 1,
|
|
0:18:28
|
we could see, did it take all of that configuration,
|
|
0:18:30
|
but except for my local loopback,
|
|
0:18:32
|
I can't configure myself as a neighbor.
|
|
0:18:35
|
Which is fine. Like I said, the parser is just going to ignore that command.
|
|
0:18:39
|
So now, for everyone else, if we look at the Show IP BGP Summary,
|
|
0:18:44
|
we should see that all of the peers are up,
|
|
0:18:48
|
and that we are learning routes from the border routers,
|
|
0:18:51
|
which in this case are router 4 and router 6.
|
|
0:18:55
|
Now, router 2's configuration,
|
|
0:19:01
|
it's still not showing me this debug message. So, let's just change it to the correct config.
|
|
0:19:06
|
Okay, it should be that this neighbor
|
|
0:19:09
|
is using the...
|
|
0:19:12
|
password CISCO. I would be able to go to the other side on BB2, and see with the error message.
|
|
0:19:19
|
The problem with this though is that in the lab exam,
|
|
0:19:21
|
you're not gonna be able to see what's going on in the backbone routers.
|
|
0:19:25
|
So, if we actually look at,
|
|
0:19:27
|
let's go under...
|
|
0:19:28
|
let's go to BB2.
|
|
0:19:36
|
And look at what its configuration actually reads.
|
|
0:19:53
|
So, under BGP,
|
|
0:19:57
|
there is the peer group configured. It says that...
|
|
0:20:01
|
"Those neighbors are in AS 200.
|
|
0:20:03
|
The password is supposed to be CISCO and these are the individual addresses."
|
|
0:20:08
|
And my AS number is 254.
|
|
0:20:10
|
Again, the problem with this, there's no way to really infer what this configuration is
|
|
0:20:15
|
without actually looking at on the other side.
|
|
0:20:19
|
Now, on our racks, if you're practicing these...
|
|
0:20:23
|
these excercises later, you can go to the access server and log in to BB1, BB2 and BB3.
|
|
0:20:30
|
Then you'll see, you can run different Show Commands, like Show IP BGP.
|
|
0:20:35
|
But in the actual exam, you're not gonna be able to do that.
|
|
0:20:38
|
So, ideally, you would wanna stay away from these verifications.
|
|
0:20:41
|
But it's kind of last ditch effort if you can't figure out what's going on,
|
|
0:20:44
|
then you can use the backbones for somebody's basic checks.
|
|
0:20:51
|
Okay, so now, let's look at the rest of our network.
|
|
0:20:55
|
So, we essentially have a full mesh of peerings
|
|
0:20:58
|
inside AS 100.
|
|
0:21:00
|
Plus the peerings that are going to the EBGP neighbors.
|
|
0:21:04
|
So, as the result of this, what we should see,
|
|
0:21:07
|
is that for every peer that is talking to router 6,
|
|
0:21:12
|
we should see that the EBGP update that came in,
|
|
0:21:19
|
was then passed along to these IBGP neighbors.
|
|
0:21:25
|
However, once the IBGP neighbors receive them,
|
|
0:21:28
|
so for example, when the update goes from BB1 to router 6,
|
|
0:21:32
|
6 sends it to router 5.
|
|
0:21:34
|
5 is not gonna send this back to any of it's peers.
|
|
0:21:39
|
Because the normal behavior is that you filter out those updates between the IBGP neighbors.
|
|
0:21:45
|
So, without route reflection, you cannot exchange any IBGP learned routes to other IBGP neighbors.
|
|
0:21:54
|
So, if I were to go to router 5,
|
|
0:21:56
|
and look at the Show IP BGP Summary,
|
|
0:21:59
|
if the network is configured correctly,
|
|
0:22:02
|
the only neighbors that I should be receiving updates from
|
|
0:22:05
|
should be routers 2, 4 and 6.
|
|
0:22:08
|
Because these are the edge routers that are learning their prefixes from EBGP.
|
|
0:22:16
|
Which is what I do see.
|
|
0:22:19
|
So, we have router 2. We're learning three routes.
|
|
0:22:23
|
Routers 4 and 6,we're learning ten routes.
|
|
0:22:25
|
Because both of these are coming from the same remote autonomous system.
|
|
0:22:31
|
Now, if we look at the actual result of this from the Show IP BGP,
|
|
0:22:37
|
this is gonna show us the actual table about what those particular prefixes are.
|
|
0:22:45
|
Now, as a quick review on how to read this output,
|
|
0:22:48
|
what we're going from the left to the right,
|
|
0:22:51
|
between the asterisk and the lower case i,
|
|
0:22:55
|
or it could be a null value there, it depends on who are learning the update from.
|
|
0:22:59
|
We normally should be receiving or seeing the greater than sign.
|
|
0:23:04
|
Which means that the route is a best route.
|
|
0:23:08
|
The best route is the one that is candidate to be installed in the routing table.
|
|
0:23:12
|
And the one that we're gonna advertise to our other peers.
|
|
0:23:14
|
So, it's essentially the winner of the best path selection.
|
|
0:23:18
|
In this case, I don't see the greater than sign on any of these.
|
|
0:23:21
|
So, it's gonna tell me, there's some problem in the selection process.
|
|
0:23:25
|
So, we'll come back to this in a second when we look at the actual routes.
|
|
0:23:30
|
Okay, next to where the greater than sign normally would be,
|
|
0:23:34
|
this lower case i, it means that it came from an internal BGP peer.
|
|
0:23:40
|
So, for any of the edge routers, like if I were to go to router 2,
|
|
0:23:46
|
and Show IP BGP,
|
|
0:23:48
|
we see that some of these routes
|
|
0:23:51
|
came from IBGP peers.
|
|
0:23:54
|
Some of them came from an external peer.
|
|
0:23:58
|
Next we have the actual prefix,
|
|
0:24:01
|
where if teh subnet mask doesn't show up here,
|
|
0:24:04
|
where we see /24 and then nothing for these routes,
|
|
0:24:09
|
it means that they have the classful mask.
|
|
0:24:12
|
Whereas the prefix is 112, 113, 114, 115, etc.
|
|
0:24:16
|
Those are class A networks.
|
|
0:24:18
|
So, it means they have the mask of /8.
|
|
0:24:22
|
Anything that is a subnet or an aggregate is gonna show the actual mask value there.
|
|
0:24:27
|
Like these two /24s.
|
|
0:24:30
|
Next, we have the next hop value.
|
|
0:24:33
|
This is what we need to know via IGP
|
|
0:24:36
|
in order to actually use the prefix.
|
|
0:24:40
|
Now, as we see for these particular next hop values,
|
|
0:24:44
|
when router 2 is learning the routes from routers 4 and 6,
|
|
0:24:49
|
these values have not been modified.
|
|
0:24:53
|
So, when router 6 is receiving the update in from BB1,
|
|
0:25:00
|
BB1 says, "The next hop value is whatever you're peering with here."
|
|
0:25:04
|
When router 6 sends this down to 2,
|
|
0:25:07
|
the next hop value is not changed.
|
|
0:25:10
|
This would then mean, router 2 needs a route to get to this next hop
|
|
0:25:15
|
in order toactually use the route.
|
|
0:25:18
|
We'll also see this is one of the first pre-requisites of running the best path selection process.
|
|
0:25:23
|
If for some reason, I don't actually have a route to the next hop value,
|
|
0:25:27
|
then the route is not valid and I cannot actually use it.
|
|
0:25:35
|
Next field would be the multi-exit discriminator,
|
|
0:25:38
|
which is a non-transit of attribute.
|
|
0:25:41
|
So, it's gonna be only locally significant between me and my directly connected AS.
|
|
0:25:47
|
The local preference is 100 by default.
|
|
0:25:50
|
The weight value is zero for anything that's not locally originated.
|
|
0:25:54
|
Then we have the AS path followed lastly by the origin code.
|
|
0:25:59
|
Where I for IGP is gonna be better than the question mark for incomplete.
|
|
0:26:05
|
So, like we talked about before in redistribution,
|
|
0:26:08
|
anytime we redistribute a route into BGP,
|
|
0:26:11
|
it's gonna get the origin code incomplete.
|
|
0:26:14
|
So, this would be less preferred than a route
|
|
0:26:16
|
that was originated with the network statement under the BGP process.
|
|
0:26:26
|
Now, there's a question.
|
|
0:26:28
|
"Can we use the next type self command?"
|
|
0:26:30
|
This would be one of the possible design solutions for this.
|
|
0:26:34
|
So, we'll look at a couple of different options on how to solve this issue.
|
|
0:26:38
|
But on router 2, if we were to look at the Show IP Route Output,
|
|
0:26:43
|
or actually, let's say Show IP Route BGP, to cutdown on the output a little bit.
|
|
0:26:48
|
We can see that router 2 is installing the prefixes learned from its EBGP neighbor.
|
|
0:26:53
|
But not any of the prefixes learned from the IBGP neighbors.
|
|
0:26:58
|
And the reason why it's gonna be that issue with the next hop reachability.
|
|
0:27:03
|
Now, the way that we can specifically verify this
|
|
0:27:06
|
is if we were to say Show IP BGP, followed by the longer prefix.
|
|
0:27:11
|
Let's say 118.0.0.0
|
|
0:27:16
|
We see in this output, it says that, "There is no best path."
|
|
0:27:22
|
Which means it cannot be advertised to any peer.
|
|
0:27:26
|
Specifically, the reason why there is no best path
|
|
0:27:29
|
is that the next hop values are inexcessible.
|
|
0:27:35
|
So, on router 2, if I were to say Show IP Route 54.28.1.254,
|
|
0:27:42
|
I don't have a route to that exit point.
|
|
0:27:46
|
Likewise, I don't have a route to 204.12.28.254
|
|
0:27:54
|
So, since I don't know how to get towards the next hop value,
|
|
0:27:57
|
it means that if I were to try to install the route into the routing table,
|
|
0:28:02
|
the route recursion process will ultimately fail
|
|
0:28:05
|
and I won't be able to switch the traffic out the correct interface.
|
|
0:28:10
|
Because remember what we talked about before in the routing process.
|
|
0:28:13
|
The goal of the Layer 3 routing process is to figure out
|
|
0:28:16
|
what is the outgoing interface.
|
|
0:28:19
|
Once we figure that out, then we send a packet to the switching process
|
|
0:28:23
|
to actually move it between the links.
|
|
0:28:26
|
Then finally, we goto the encapsulation where we're actually building the Layer 2 header.
|
|
0:28:29
|
But if the routing process doesn't know the outgoing interface,
|
|
0:28:34
|
then the switching is gonna fail and then ultimately the encapsulation is gonna fail.
|
|
0:28:40
|
So, in BGP, we have this automatic check built in.
|
|
0:28:43
|
That says, "If you can't do route recursion, I'm not gonna consider the route."
|
|
0:28:47
|
"Because I know that I'm gonna cause a traffic blackhole for this destination
|
|
0:28:51
|
if I actually install it or advertise it to other peers."
|
|
0:28:57
|
Now, the solution to this design problem is pretty straightforward.
|
|
0:29:01
|
The issue is that we're learning routes
|
|
0:29:03
|
that we don't know how to get to the next hop for.
|
|
0:29:06
|
So, there's only two possible solutions for this.
|
|
0:29:09
|
Either we give them the route to that next hop.
|
|
0:29:14
|
So, if router 2 actually knew how to get to the frame-relay interface between router 6 and BB1,
|
|
0:29:20
|
and knew how to get to the LAN interface between router 4 and BB3,
|
|
0:29:24
|
then we wouldn't have this problem in the first place.
|
|
0:29:28
|
The other option would be to change the next hop
|
|
0:29:32
|
to something router 2 does have reachability to.
|
|
0:29:35
|
Now, whether that would be the actual address that we're peering with on router 6 and router 4,
|
|
0:29:40
|
whether it'd be the interface address of the Ethernet of router 4 or 6,
|
|
0:29:45
|
it doesn't really matter what it is.
|
|
0:29:47
|
As long as it points us towards the correct exit point
|
|
0:29:50
|
and it's something we already have in the IGP table,
|
|
0:29:53
|
that's really what the ultimate goal is here.
|
|
0:29:56
|
So, we could change the next hop by either using the next hop self command
|
|
0:30:01
|
or we could do this manually under the route map.
|
|
0:30:03
|
As long as we address the problem somehow,
|
|
0:30:06
|
that's really what the ultimate design goal is.
|
