|
0:00:12
|
Now, for the unicast updating,
|
|
0:00:15
|
the reason potentially we would want to do this...
|
|
0:00:17
|
is to make sure that other
|
|
0:00:20
|
would not be able to receive the
|
|
0:00:28
|
So, between router 5 and switch 2
|
|
0:00:33
|
if router 5 says that the unicast neighbor for RIP...
|
|
0:00:38
|
is switch 2's address, which is 155.10.58.8,
|
|
0:00:44
|
and switch 2 say that router 5's address,
|
|
0:00:53
|
we are then assuming that those
|
|
0:00:59
|
which normally switches the packets
|
|
0:01:04
|
so the unicast MAC addresses
|
|
0:01:07
|
it would mean that the RIP updates
|
|
0:01:10
|
would not be replicated to other ports on the LAN.
|
|
0:01:15
|
So, it could be considered a security feature
|
|
0:01:19
|
of the routing protocols to not
|
|
0:01:24
|
but instead only to find the unicast neighbors
|
|
0:01:30
|
Now, then of course, the disadvantage is you need to keep
|
|
0:01:38
|
But implementation wise, we would go to...
|
|
0:01:41
|
the RIP process of router 5 and say,
|
|
0:01:47
|
that neighbor."
|
|
0:01:49
|
But additionally, interface Fast Ethernet
|
|
0:01:55
|
This would stop either the broadcast
|
|
0:02:00
|
but still allow us to send the unicast update.
|
|
0:02:05
|
Then, if we were to look at switch 2,
|
|
0:02:11
|
and likewise, under the RIP process,
|
|
0:02:15
|
VLAN 58 is passive.
|
|
0:02:20
|
But I'll send unicast updates to router 5."
|
|
0:02:28
|
So now, on router 5, if we look at the Show Debug,
|
|
0:02:31
|
we're still debugging IP Packet Detail,
|
|
0:02:36
|
If we clear the log and then show the results of this,
|
|
0:02:52
|
we see that now, when we are
|
|
0:02:57
|
they're going to the unicast destination.
|
|
0:03:02
|
So, if we looked at other logs here
|
|
0:03:10
|
let's say, Show Log Include,
|
|
0:03:14
|
that string, via Fast Ethernet 0/0.
|
|
0:03:18
|
we see that when we're sending,
|
|
0:03:20
|
we're just going to the unicast address. We're
|
|
0:03:26
|
or the RIpv2 broadcast address.
|
