|
0:00:13
|
In this section, we're gonna look at how RIP
|
|
0:00:20
|
And this is simply based on a hop count,
|
|
0:00:23
|
where each interface or each device
|
|
0:00:28
|
where 16 is the maximum value.
|
|
0:00:32
|
So, this means that for RIP network end-to-end,
|
|
0:00:38
|
To modify this, we can use the off-set
|
|
0:00:43
|
where we could do this for all routes,
|
|
0:00:48
|
This also can be done inbound as the updates
|
|
0:00:55
|
So first, let's look at what is the default
|
|
0:01:00
|
If we look at our topology here,
|
|
0:01:04
|
let's track the...
|
|
0:01:07
|
VLAN 10 interface that switch 4 is originating.
|
|
0:01:11
|
So, from switch 4, we should see
|
|
0:01:15
|
As we go to switch 2,
|
|
0:01:19
|
switch 2 says that "This destination
|
|
0:01:22
|
Then likewise, from router 5's
|
|
0:01:26
|
from 3's perspective, that is 4.
|
|
0:01:31
|
which means that from switch 3's
|
|
0:01:36
|
So, if we look at switch 3,
|
|
0:01:39
|
and look at the Show IP
|
|
0:01:46
|
which is the...
|
|
0:01:50
|
actually, not 8.8, it would be...
|
|
0:01:54
|
10.10.
|
|
0:02:00
|
It says, "The metric is 5 to reach
|
|
0:02:05
|
Now, there was a question that
|
|
0:02:09
|
"When you send a RIP update, does RIP
|
|
0:02:14
|
or when the receiving router gets it in?"
|
|
0:02:17
|
Now, the way that we could quickly verify this...
|
|
0:02:20
|
would be to look between
|
|
0:02:23
|
Let's say, between switch 1 and switch 3,
|
|
0:02:26
|
and see what they say about the update going
|
|
0:02:32
|
So, on switch 1 and switch 3,
|
|
0:02:39
|
Debug IP RIP.
|
|
0:02:40
|
And specifically, we are gonna look...
|
|
0:02:44
|
for that prefix that is the 155.10.10.0/24.
|
|
0:02:54
|
So, on switch 1, it says that we are...
|
|
0:02:58
|
sending the update out VLAN 67,
|
|
0:03:05
|
As it goes out to router 6,
|
|
0:03:11
|
So now, we need to know,
|
|
0:03:14
|
was it received as 4, or was it received as 5?
|
|
0:03:21
|
So, let's see where...
|
|
0:03:25
|
the updates were received.
|
|
0:03:29
|
So, they're coming in from router 3.
|
|
0:03:32
|
Router 3 says that the hop count
|
|
0:03:40
|
Now, if we look at the routing table of router 3,
|
|
0:03:44
|
and see what does it have installed,
|
|
0:03:48
|
That's gonna tell us whether the value is set
|
|
0:03:53
|
So, if we look at router 3's table,
|
|
0:04:05
|
and Show IP Route 155...
|
|
0:04:09
|
.10.10.0.
|
|
0:04:11
|
Router 3 sees this as a metric of 3.
|
|
0:04:14
|
But since the other end of the link
|
|
0:04:23
|
And you can see, it's kind of hard to
|
|
0:04:27
|
There's so many routes that are
|
|
0:04:32
|
So, this is an outbound update.
|
|
0:04:36
|
I want to see the one that was received.
|
|
0:04:44
|
From router 3.
|
|
0:04:46
|
So, as it came inbound, it was 4.
|
|
0:04:50
|
So, router 3 sent it in the table is 3.
|
|
0:04:52
|
We're receiving it has 4.
|
|
0:04:54
|
Now, I wanna know, when I advertise it,
|
|
0:04:58
|
Or am I advertising it as 5?
|
|
0:05:01
|
So, as the update now goes out
|
|
0:05:07
|
It says that this is a metric of 5.
|
|
0:05:09
|
So, what this shows us is that the router is
|
|
0:05:15
|
not as the prefix is received.
|
|
0:05:18
|
Now, we can increment the hop
|
|
0:05:24
|
if we were to use the offset list.
|
|
0:05:26
|
And we'll see that there's mainly two
|
|
0:05:29
|
We can either use it for the
|
|
0:05:33
|
If we wanted to prefer one path over another,
|
|
0:05:36
|
or we could use it for filtering by setting the
|
|
0:05:47
|
So, if we go above 16, whether this is for
|
|
0:05:53
|
this could not be installed in the RIP database,
|
|
0:05:56
|
which means likewise, it cannot be
|
|
0:06:00
|
So, let's look at this now from a
|
|
0:06:04
|
From...
|
|
0:06:06
|
switch 3's perspective,
|
|
0:06:09
|
let's see how are we actually
|
|
0:06:12
|
So, the prefix in question again is the 155.10.10.0/24.
|
|
0:06:19
|
So, from switch 3, let's do a traceroute and
|
|
0:06:27
|
Well say, Trace 155.10.10.10.
|
|
0:06:33
|
Now, the packets are going from us to switch 1.
|
|
0:06:37
|
To router 3, to router 5.
|
|
0:06:40
|
Then, down towards the final destination.
|
|
0:06:42
|
So, the packets are going here, here,
|
|
0:06:49
|
But let's say now that we want to change this path.
|
|
0:06:53
|
Instead of using the
|
|
0:06:56
|
we want the traffic to go this direction.
|
|
0:07:04
|
So, this means that from router 5's perspective,
|
|
0:07:08
|
when we are advertising this prefix out,
|
|
0:07:10
|
if we set it to be much higher on the frame-relay
|
|
0:07:14
|
versus the point-to-point link to router 4,
|
|
0:07:18
|
then, it should imply that when we
|
|
0:07:21
|
the other devices would prefer to use the
|
|
0:07:28
|
Now, as long as we make sure that
|
|
0:07:32
|
because again, if it gets to 16,
|
|
0:07:37
|
So, on router 5,
|
|
0:07:40
|
let's go under the RIP process,
|
|
0:07:43
|
and apply an offset list.
|
|
0:07:46
|
We can use an access list here if we
|
|
0:07:52
|
networks that we are modifying, in this case,
|
|
0:08:01
|
The metric is gonna be at an outbound.
|
|
0:08:04
|
And I'll add let's say...
|
|
0:08:07
|
10.
|
|
0:08:10
|
As it goes out serial 0/0/0.1234,
|
|
0:08:20
|
Now, once everyone converges,
|
|
0:08:23
|
and it's gonna take a little bit of time here,
|
|
0:08:28
|
Then, we should see that the path
|
|
0:08:31
|
Now, we could potentially speed this
|
|
0:08:35
|
Clear IP Route Star (*).
|
|
0:08:37
|
This is gonna force RIP to do a triggered update,
|
|
0:08:40
|
which means that now, router 5 is
|
|
0:08:47
|
If we now look at the result of this on switch 3,
|
|
0:08:51
|
and look at the Traceroute,
|
|
0:08:54
|
we could see now, actually, there's a
|
|
0:09:02
|
Which eventually will work itself out,
|
|
0:09:05
|
but this is one of the disadvantages
|
|
0:09:11
|
that we have what is known as a "Transient Loop".
|
|
0:09:15
|
So, a Transient Loop is a temporary situation
|
|
0:09:19
|
where the devices on the topology do not
|
|
0:09:24
|
Which is what we had here, because router 4's
|
|
0:09:31
|
So, router 5 was actually learning...
|
|
0:09:35
|
If we look at the topology, router 5 was learning
|
|
0:09:44
|
And the result of that is that the traffic bounces
|
|
0:09:51
|
But eventually, this is gonna settle down and now,
|
|
0:09:56
|
So now, the packets are going
|
|
0:10:02
|
So, they're going this way. Then from
|
|
0:10:10
|
So, we see, we can modify the metric value,
|
|
0:10:13
|
but when we do this most of the time, you're
|
|
0:10:18
|
Unless you flush out all the old
|
|
0:10:23
|
So, if I said Clear IP Route Star (*)
|
|
0:10:27
|
But until that point, then, we're gonna start
|
|
0:10:34
|
If we look at the result to this
|
|
0:10:37
|
in the RIP database of let's say, router 3,
|
|
0:10:42
|
and we Show IP RIP Database.
|
|
0:10:46
|
We should see that we have multiple possible paths
|
|
0:10:50
|
for these different routes now, where
|
|
0:10:58
|
frame-relay, some of them are gonna
|
|
0:11:03
|
So, if we look at that prefix in question,
|
|
0:11:06
|
router 3 says that my current route to this
|
|
0:11:09
|
is via router 1, with a hop count of 5.
|
|
0:11:13
|
If we look at the Debug IP RIP,
|
|
0:11:17
|
we should see the update coming in from router 5
|
|
0:11:22
|
with the added hop values.
|
|
0:11:37
|
So, we can see, we're receiving
|
|
0:11:41
|
All of its routes have the original hop counts.
|
|
0:11:44
|
Plus the offset value added on to that.
|
|
0:11:47
|
So, its whatever 5 had to start with, plus 10.
|
|
0:11:49
|
So, it means that 5 would have seen this ones as 2.
|
|
0:11:54
|
These ones as 1,
|
|
0:11:55
|
these ones as 3, etc.
|
|
0:11:58
|
So, we're not replacing the metric value
|
|
0:12:01
|
we're just adding it on to what normally we
|
|
0:12:10
|
So, likewise, we can see that this is applied to all routes
|
|
0:12:14
|
that router 5 is advertising, because I used
|
|
0:12:19
|
If I were to use an access list here,
|
|
0:12:26
|
Now, we can also use this for filtering.
|
|
0:12:29
|
If we set the metric value so large that certain devices
|
|
0:12:40
|
which means that we can filter routes coming in
|
|
0:12:46
|
And we can also potentially do some sort of
|
|
0:12:53
|
to limit exactly where it is going to be advertised to.
|
|
0:12:59
|
So, let's say from...
|
|
0:13:01
|
switch 3's perspective, we're advertising
|
|
0:13:06
|
I want this to go to switch 1 and to router 6,
|
|
0:13:12
|
and from switch 1 to router 3, but I don't
|
|
0:13:19
|
So, technically, what I can do is
|
|
0:13:24
|
that when the update is received by switch 1,
|
|
0:13:28
|
it is seen with a hop count of 14.
|
|
0:13:32
|
Then, when it's received by router 3 and router 6,
|
|
0:13:37
|
it's seen with a hop count of 15,
|
|
0:13:39
|
which means, once it goes one hop beyond this,
|
|
0:13:43
|
the other neighbors would see it as 16, which is
|
|
0:13:51
|
And let's say we wanna do this just for the VLAN 9,
|
|
0:13:59
|
The first step then would be on switch 3,
|
|
0:14:03
|
We look at the Show IP Route Connected.
|
|
0:14:07
|
This VLAN 9 is 155.10.9.0/24.
|
|
0:14:13
|
Now, since the offset list is only
|
|
0:14:19
|
it means that the RIP process cannot
|
|
0:14:25
|
that have the same prefix, but different lengths.
|
|
0:14:30
|
So, this means that on switch 3,
|
|
0:14:33
|
if I actually had two separate routes that
|
|
0:14:46
|
or anything greater than that,
|
|
0:14:53
|
the RIP process would not be able to
|
|
0:14:57
|
At least from a filtering point of
|
|
0:15:00
|
Because the standard access list is
|
|
0:15:06
|
of the route, it's not matching on the prefix length.
|
|
0:15:12
|
So, we'll see when we do route
|
|
0:15:16
|
the preferred methodology would be to
|
|
0:15:23
|
because the prefix list is matching on both
|
|
0:15:29
|
Whereas the standard access list can only match
|
|
0:15:41
|
So now, on switch 3, we will match the prefix.
|
|
0:15:45
|
We'll say, Access List 1 is for the route 155.10.9.0.
|
|
0:15:55
|
Then, under the RIP process,
|
|
0:15:59
|
For the routes matched in Access List 1.
|
|
0:16:02
|
I'll do this outbound.
|
|
0:16:05
|
And now, I need to figure out what
|
|
0:16:09
|
Now, on the other end of the link
|
|
0:16:16
|
for 155.10.9.0,
|
|
0:16:20
|
switch 1 is currently receiving this with a metric value of 1.
|
|
0:16:25
|
So, if I want is installed as 14 in switch 1's table,
|
|
0:16:30
|
then, it should mean on switch 3 that
|
|
0:16:40
|
It should be offset to 30.
|
|
0:16:43
|
So, assuming that we take the previous
|
|
0:16:47
|
if that is true, then, we should see
|
|
0:16:50
|
14 in switch 1's table.
|
|
0:16:56
|
Now, notice I didn't referenced an interface, this means
|
|
0:17:02
|
It's gonna be offset by an additional 13.
|
|
0:17:04
|
So now, if we look at switch 1 and look at the result,
|
|
0:17:08
|
now, the metric is 14.
|
|
0:17:11
|
Which then in turn means that on router 3 or 6 is 15.
|
|
0:17:22
|
So, both 3 and 6, they're saying this is a metric of 15.
|
|
0:17:26
|
And if we go one hop beyond them, if we go to
|
|
0:17:36
|
it says the metric is inaccessible.
|
|
0:17:39
|
So, right now, this prefix is aging out of the table.
|
|
0:17:43
|
Once it goes and pass the flush
|
|
0:17:47
|
And if we actually try to send packets there,
|
|
0:17:51
|
we can still use the route until it is flushed out.
|
|
0:17:56
|
But once we go beyond that
|
|
0:18:01
|
then, the routes is gonna be removed.
|
|
0:18:03
|
Now, if we clear the routing table,
|
|
0:18:08
|
And then, we'll see now, router 4 no longer
|
|
0:18:18
|
So, this feature then essentially has dual functionality.
|
|
0:18:21
|
We could use it for traffic engineering,
|
|
0:18:23
|
but we could also use it for route filtering
|
|
0:18:26
|
based on the fact that a metric of 16 is
|