|
0:00:14
|
So, as we saw in our previous case here with RIP,
|
|
0:00:17
|
by default, we will be running version 1,
|
|
0:00:23
|
even if we enabled the version 2 process,
|
|
0:00:25
|
which means that we're listening for and
|
|
0:00:31
|
we still potentially have that problem
|
|
0:00:34
|
with the VLSM not being supported
|
|
0:00:38
|
So again, the easy solution for this is
|
|
0:00:44
|
with just the No Auto-Summary command.
|
|
0:00:50
|
Now, the next feature we have is Split Horizon,
|
|
0:00:54
|
which since RIP is a distance vector protocol,
|
|
0:00:57
|
it means that by default, when we
|
|
0:01:01
|
we are not gonna send it
|
|
0:01:06
|
In the vast majority of designs,
|
|
0:01:11
|
because if you are advertising a route to me,
|
|
0:01:13
|
I don't wanna advertise the same
|
|
0:01:17
|
We could then potentially end up
|
|
0:01:21
|
When a packet comes to me, I route it to you,
|
|
0:01:27
|
Now, the case where we do not want Split Horizon
|
|
0:01:30
|
would be if we are running RIP
|
|
0:01:36
|
So, for example, between routers...
|
|
0:01:40
|
5 as the hub of the frame-relay network.
|
|
0:01:46
|
And routers 4, 1, 3 and 2 as the spokes.
|
|
0:01:55
|
With Split Horizon on, we could potentially run into
|
|
0:02:02
|
but if Split Horizon is on, 5 is not gonna
|
|
0:02:07
|
Down to routers 1, 3, and 4.
|
|
0:02:11
|
Now, we'll see that by default,
|
|
0:02:13
|
with frame-relay main interfaces,
|
|
0:02:17
|
the Split Horizon process is disabled,
|
|
0:02:19
|
where it would be enabled on all other interfaces.
|
|
0:02:24
|
So this means in this design, if on router 5,
|
|
0:02:31
|
for frame-relay, and we were running RIP on it,
|
|
0:02:34
|
then, we would have a problem with the Split Horizon.
|
|
0:02:39
|
Now, we can verify this quickly,
|
|
0:02:42
|
and let's shutdown the serial 0/1 link.
|
|
0:02:46
|
Which means that router 2's
|
|
0:02:50
|
is only via the interface to router 5 over the frame-relay.
|
|
0:02:56
|
So on router 2, we'll go to...
|
|
0:03:00
|
interface serial 0/1 and simply disable this.
|
|
0:03:06
|
If we look at the result of this in the routing table,
|
|
0:03:10
|
we see that RIP routes are being received in the
|
|
0:03:17
|
So, even the routes that are
|
|
0:03:20
|
like the...
|
|
0:03:25
|
LAN interface of router 3,
|
|
0:03:29
|
and the...
|
|
0:03:32
|
the different loopback interfaces,
|
|
0:03:35
|
we can see that router 1's loopback, router 3,
|
|
0:03:39
|
So, this implies that Split Horizon is disable
|
|
0:03:45
|
So, on router 5, if we look at the
|
|
0:03:50
|
since this is the main interface in frame-relay,
|
|
0:03:54
|
if we look at the Show IP Interface Serial 0/0/0,
|
|
0:03:59
|
we see that Split Horizon is disabled.
|
|
0:04:04
|
Now again, the case where this would be a problem
|
|
0:04:08
|
is if we were to take this configuration,
|
|
0:04:14
|
a multipoint sub-interface as
|
|
0:04:18
|
then, Split Horizon will be enabled.
|
|
0:04:21
|
So, on router 5, let's say,
|
|
0:04:26
|
So, that's gonna remove all of
|
|
0:04:30
|
Next on the main interface,
|
|
0:04:36
|
The rest of the configuration is
|
|
0:04:42
|
So here, we have our IP address.
|
|
0:04:46
|
And we have the frame-relay mappings that
|
|
0:05:00
|
So, the IP address, and then,
|
|
0:05:02
|
Now, if we were to look at the
|
|
0:05:10
|
it says that "For this interface,
|
|
0:05:13
|
Split Horizon is enabled."
|
|
0:05:16
|
which means that an update
|
|
0:05:22
|
that would not be able to
|
|
0:05:25
|
So now, from router 2's perspective,
|
|
0:05:29
|
we should see that...
|
|
0:05:32
|
some of these routes, it depends on
|
|
0:05:41
|
but we may see that some of these are gonna
|
|
0:05:50
|
which means that...
|
|
0:05:52
|
These particular ones.
|
|
0:05:56
|
So, that are 33 seconds old and the
|
|
0:06:00
|
Eventually, these are gonna time out on router 2.
|
|
0:06:05
|
Once it goes and pass the 180-second threshold,
|
|
0:06:13
|
and by default, when they get into 240 seconds,
|
|
0:06:21
|
So, if we look at the result to this,
|
|
0:06:25
|
once we go beyond 3 minutes, it'll say
|
|
0:06:30
|
Which means that we can still
|
|
0:06:35
|
but once it goes beyond the 4-minute mark, then,
|
|
0:06:44
|
So, this problem would be very easy to verify just
|
|
0:06:50
|
If some of the routers are not
|
|
0:06:55
|
router 2 here and look at the Debug IP RIP.
|
|
0:07:00
|
And we should see, what are the updates
|
|
0:07:03
|
and what are the updates that
|
|
0:07:09
|
So, if we look at what we are receiving here...
|
|
0:07:15
|
So the update came in from router 5
|
|
0:07:19
|
This does not include everything in the network.
|
|
0:07:22
|
So, we see a bunch of the loopbacks are
|
|
0:07:28
|
And some of the other segments in the network.
|
|
0:07:30
|
So, it really depends on what interface
|
|
0:07:37
|
So, this means that if router 5 were using...
|
|
0:07:45
|
if router 5 were using this interface here
|
|
0:07:50
|
it would be valid for the update
|
|
0:07:56
|
and the go out the sub-interface to router 2.
|
|
0:08:01
|
So, the key point being here that sometimes,
|
|
0:08:06
|
where it looks like everyone has full reachability,
|
|
0:08:08
|
but based on different failure scenarios,
|
|
0:08:13
|
then, router 2 is not gonna
|
|
0:08:19
|
So again, for RIP, the key is that
|
|
0:08:24
|
for every interface except the main
|
|
0:08:28
|
So now, if we look at the result
|
|
0:08:34
|
we see that most of these networks
|
|
0:08:40
|
If we look at the time stamps
|
|
0:08:45
|
we would see that once they can pass the
|
|
0:08:49
|
it says, "They're going in the whole down,
|
|
0:08:51
|
and then, 60 seconds later, they eventually
|
|
0:08:56
|
So let's look at this, Debug IP RIP.
|
|
0:09:04
|
Then, Show IP Route RIP.
|
|
0:09:11
|
So, some of those are still listed as possibly down.
|
|
0:09:20
|
And actually, I may need to
|
|
0:09:24
|
Because Debug IP RIP is gonna show us
|
|
0:09:28
|
Debug IP Routing is gonna show us the
|
|
0:09:34
|
So now, we're deleting those routes.
|
|
0:09:37
|
This here, this is when they pass the flush timer.
|
|
0:09:41
|
Now, the timer values in RIP are
|
|
0:09:50
|
that much complexity to it,
|
|
0:09:53
|
but the thing is...
|
|
0:09:54
|
the way that this is documented
|
|
0:09:59
|
but the thing to remember is that all of the
|
|
0:10:06
|
Now, the update timer is 30 seconds by default.
|
|
0:10:09
|
So, this means simply, you're sending
|
|
0:10:13
|
Once I receive an update in,
|
|
0:10:16
|
the rest of my timers, which are the invalid,
|
|
0:10:22
|
these all start counting up.
|
|
0:10:26
|
So, from the last time that I received the update,
|
|
0:10:28
|
if I get to 180 seconds,
|
|
0:10:33
|
the route becomes invalid, and it goes into hold down.
|
|
0:10:38
|
Most of the time, the invalid and the
|
|
0:10:43
|
So, you would just set this to be in the same value,
|
|
0:10:46
|
but technically, they have two different purposes,
|
|
0:10:49
|
where the hold down says that "When I
|
|
0:10:55
|
I would only accept it if it had a
|
|
0:11:03
|
So, it means that we wanna make sure the routing information
|
|
0:11:07
|
Where the invalid is the one that says that
|
|
0:11:14
|
Then, the flush timer is 240 seconds by default.
|
|
0:11:17
|
So, once it goes beyond that threshold,
|
|
0:11:24
|
In some of the newer versions, if you configure
|
|
0:11:29
|
it will automatically convert this to the IP RIP
|
|
0:11:35
|
They're essentially going to
|
|
0:11:38
|
The only difference is that with the global command,
|
|
0:11:43
|
where the Interface Level command is obviously
|
|
0:11:50
|
In either case, when you look at the command line,
|
|
0:11:53
|
and we look at the Show IP Protocols,
|
|
0:11:57
|
this is gonna tell us what are the timers
|
|
0:12:00
|
So, the defaults here, we have 30 seconds as the update.
|
|
0:12:09
|
So, this would the imply for RIP
|
|
0:12:14
|
If we wanted to speed up the convergence,
|
|
0:12:17
|
it means that we would have
|
|
0:12:21
|
So, let's say that on everyone,
|
|
0:12:25
|
timer's basic, where the update interval is...
|
|
0:12:30
|
5 seconds.
|
|
0:12:32
|
The invalid is 20...
|
|
0:12:35
|
The hold down is 20, and then, the flush is 30.
|
|
0:12:41
|
So, you technically could set
|
|
0:12:43
|
If you set the hold down to zero,
|
|
0:12:45
|
it means that the route would
|
|
0:12:49
|
but it doesn't make sense that you're invalid or
|
|
0:12:55
|
So, it means they would be removed in the table,
|
|
0:13:02
|
So, technically, these values do not have
|
|
0:13:06
|
because there's no active adjacency that's
|
|
0:13:11
|
but it doesn't really make sense why
|
|
0:13:16
|
So normally, if I change them all in one router,
|
|
0:13:19
|
So, under the RIP process, timer's basic.
|
|
0:13:24
|
So, I'm updating every 5 seconds now.
|
|
0:13:31
|
Then, the result of this, if we look at the
|
|
0:13:37
|
It means that if the table is converged,
|
|
0:13:43
|
Show IP Route RIP.
|
|
0:13:47
|
If the table is converged, we should
|
|
0:13:51
|
have a time index that is less than 5 seconds.
|
|
0:13:55
|
So, this one here, that is 20;
|
|
0:13:59
|
It means that these are in the
|
|
0:14:04
|
So, eventually, the network is
|
|
0:14:07
|
but it's definitely not as fast convergence
|
|
0:14:17
|
So again, if you're confused about this,
|
|
0:14:21
|
is to go to the router and turn
|
|
0:14:29
|
So, let's say Uptime.
|
|
0:14:30
|
And then, also for the debug messages.
|
|
0:14:36
|
So, debug is Uptime and log is Uptime. You could do it
|
|
0:14:43
|
But now, on router 2, if we look at
|
|
0:14:50
|
we should see that every 5 seconds,
|
|
0:14:55
|
and every 5 seconds, we are receiving updates in.
|
|
0:14:59
|
Now, if I were to go to router 5,
|
|
0:15:03
|
and shut the connection down,
|
|
0:15:06
|
we should see on router 2...
|
|
0:15:10
|
when we compare the last time
|
|
0:15:15
|
which in this case is...
|
|
0:15:19
|
58 seconds after.
|
|
0:15:20
|
So, at 58, we received an update from router 5,
|
|
0:15:25
|
which means that at 18
|
|
0:15:31
|
this should be where we go into hold down.
|
|
0:15:44
|
Let's see...
|
|
0:15:48
|
So, about there, the prefix is going into hold down.
|
|
0:15:53
|
So, it's 20 seconds after the last update came in.
|
|
0:15:57
|
Then, another 10 seconds after this, then,
|
|
0:16:04
|
the table, which is this very last one.
|
|
0:16:10
|
You'll see that the timers
|
|
0:16:13
|
Because the RIP implementation is using
|
|
0:16:18
|
which is basically a randomization of a timers...
|
|
0:16:21
|
to make sure that the timer is not sending or receiving
|
|
0:16:30
|
So, this is why the timers are large by default,
|
|
0:16:33
|
because if the update timer is 30 seconds,
|
|
0:16:37
|
then, the RIP Jitter value is not really gonna matter.
|
|
0:16:40
|
But if you're trying to do very fast convergence,
|
|
0:16:44
|
and 3 seconds is your hold down,
|
|
0:16:50
|
Now, additionally,
|
|
0:16:52
|
when we look at these updates,
|
|
0:16:56
|
it says, "We're building an update
|
|
0:17:02
|
Let's see, this actually went out
|
|
0:17:05
|
But if we look at the number of
|
|
0:17:08
|
there's a limit to the size of the
|
|
0:17:13
|
So, if you exceed a certain number of routes,
|
|
0:17:15
|
you have to break it into multiple updates.
|
|
0:17:19
|
So, then, you should be running into is that if
|
|
0:17:24
|
it's feasible that you would not even
|
|
0:17:29
|
before the remote neighbor goes into
|
|
0:17:36
|
So, in a real design, this is probably not gonna be
|
|
0:17:41
|
where the size of the RIP
|
|
0:17:44
|
it means you need to run it with a protocol.
|
|
0:17:51
|
And then, let those do the more efficient
|
|
0:18:05
|
There is a question here, "Under the timer's basic,
|
|
0:18:11
|
Let's take a look at this here,
|
|
0:18:15
|
Timer's Basic.
|
|
0:18:20
|
The interval between updates,
|
|
0:18:24
|
And valid was...
|
|
0:18:29
|
Let's say, 15. Hold down in 15.
|
|
0:18:31
|
Flush is 20.
|
|
0:18:35
|
Then, the sleep time in milliseconds.
|
|
0:18:38
|
Okay, let's take a look at the command
|
|
0:18:43
|
So, from the main documentation page,
|
|
0:18:48
|
we would go to Products, IOS...
|
|
0:18:52
|
Regular IOS...
|
|
0:18:55
|
12.4...
|
|
0:18:57
|
12.4T.
|
|
0:19:01
|
Then, Reference Guides,
|
|
0:19:03
|
and Command Reference.
|
|
0:19:07
|
Then, under Routing Protocols,
|
|
0:19:15
|
So, we can see here in RIP, there's only
|
|
0:19:20
|
Pretty much, this means that the
|
|
0:19:23
|
If we were to compare this to OSPF or BGP,
|
|
0:19:26
|
you see that that's broken down
|
|
0:19:30
|
because there's tons of commands
|
|
0:19:34
|
So, in this case, we have the Timer's Basic.
|
|
0:19:37
|
And what you would want to look
|
|
0:19:45
|
is what is the usage guidelines for the command.
|
|
0:19:47
|
So, it's actually, this one right here.
|
|
0:19:50
|
It says, "To adjust the timers, use Timer Basic."
|
|
0:19:54
|
The update is...
|
|
0:19:57
|
how often updates are sent.
|
|
0:20:00
|
Invalid is the time after which
|
|
0:20:03
|
It should be at least 3 times the update.
|
|
0:20:06
|
A route becomes invalid when there's an
|
|
0:20:10
|
The route then enters the hold down state.
|
|
0:20:14
|
However, the route is still used to forward packets.
|
|
0:20:18
|
The route is marked as "Inaccessible"
|
|
0:20:22
|
So, in this case, once we go into the invalid timer,
|
|
0:20:26
|
then, we start to poison the route.
|
|
0:20:29
|
So, we start advertising it to everyone as
|
|
0:20:35
|
So, technically, you could see, there's a
|
|
0:20:41
|
when the route enters hold down,
|
|
0:20:44
|
and it receives an update with a hop count
|
|
0:20:48
|
The route is marked as "Inaccessible"
|
|
0:20:51
|
However, it's still could be used.
|
|
0:20:52
|
So normally, these are the same thing, but you
|
|
0:20:57
|
Okay, then the flush timer, this one
|
|
0:21:06
|
So, let's try just searching for that.
|
|
0:21:09
|
What I would guess that it would be
|
|
0:21:15
|
So, let's say, RIP Timer's Basic Sleep Timer.
|
|
0:21:25
|
Let's try on Cisco's website.
|
|
0:21:37
|
RIP Sleep Timer.
|
|
0:21:45
|
So, it doesn't even really show.
|
|
0:21:47
|
What you could do with this...
|
|
0:21:50
|
is that if you turn time stamping
|
|
0:21:56
|
you could look at what is the exact time that you're
|
|
0:22:03
|
Then, if you were to set
|
|
0:22:07
|
so, if we said it to be the
|
|
0:22:12
|
So, if we look at this value,
|
|
0:22:17
|
divided by a thousand.
|
|
0:22:21
|
So, that's how many seconds it would be.
|
|
0:22:25
|
So, that would be...
|
|
0:22:28
|
1200 hours? Is the maximum. It looks like.
|
|
0:22:32
|
So, if you set this to something reasonable,
|
|
0:22:36
|
So, like 3000 milliseconds.
|
|
0:22:38
|
You should be able to see based on
|
|
0:22:43
|
But what I would guess is that
|
|
0:22:46
|
where by default is a randomized value.
|