|
0:00:13
|
In our next section for IPv6, we're going to look at
|
|
0:00:16
|
EIGRPv6 for routing
|
|
0:00:18
|
which like RIPng similarity to RIP version 2
|
|
0:00:23
|
EIGRPv6 is very similar to regular EIGRP routing.
|
|
0:00:28
|
It still uses its own transport protocol which is IPv6 protocol number 88
|
|
0:00:34
|
It's going to use multicasts going to FF02::A
|
|
0:00:38
|
to find the neighbors and then unicast to synchronize
|
|
0:00:42
|
the topology.
|
|
0:00:47
|
Configuration wise, there's basically only two things that we
|
|
0:00:50
|
need to do in order to get the process running
|
|
0:00:52
|
is at the link level turn the process on
|
|
0:00:55
|
we simply say IPv6 EIGRP give it an AS number
|
|
0:01:00
|
then globally under the process, we need to say no shut down.
|
|
0:01:05
|
So by default, the process is disabled globally
|
|
0:01:09
|
even though we're manually enabling it at the interface level.
|
|
0:01:15
|
Now we'll see that with EIGRPv6 and OSPFv3, they are still using
|
|
0:01:21
|
the 32-bit IPv4 address format for the router identifier
|
|
0:01:28
|
which means that if the router is running IPv6
|
|
0:01:31
|
only and has no IP version 4 addresses configured at all
|
|
0:01:36
|
we would manually need to specify the router ID
|
|
0:01:39
|
under the routing process.
|
|
0:01:48
|
So for our basic implementation, again it's going to be very similar
|
|
0:01:51
|
to the regular EIGRP
|
|
0:01:56
|
so let's configure this on the same interfaces that we did before
|
|
0:02:00
|
for the RIPng between the routers.
|
|
0:02:04
|
We'll see that some of the older versions on the Catalyst IOS
|
|
0:02:07
|
do not yet support EIGRPv6, I believe it's the later 12.4 T
|
|
0:02:13
|
and beyond versions that first added support for this.
|
|
0:02:18
|
So let's go to Router 6 and we'll say on the LAN segment
|
|
0:02:22
|
that goes to Router 1 ipv6 eigrp 1
|
|
0:02:29
|
so it's just that simple ok, just the one command at the interface level.
|
|
0:02:32
|
Then under the routing process globally ipv6 router eigrp 1
|
|
0:02:37
|
we need to say no shut down
|
|
0:02:42
|
so that's the common mistake that people make when implementing this.
|
|
0:02:44
|
If you do not say no shut down globally, then the process
|
|
0:02:47
|
is not actually going to be enabled.
|
|
0:02:58
|
We'll do the same thing on Router 1 and actually this
|
|
0:03:02
|
version doesn't support EIGRP.
|
|
0:03:06
|
So let's say ipv6
|
|
0:03:10
|
it doesn't support EIGRP. This is if we show version include IOS
|
|
0:03:16
|
this is 12.4 mainline, so what I need to do then
|
|
0:03:21
|
is I need to run EIGRP on the links between 4 and 6
|
|
0:03:27
|
and 4 and 5 because these three routers these are running
|
|
0:03:31
|
12.4 T
|
|
0:03:35
|
so on Router 4, right now at the link level
|
|
0:03:41
|
I am automatically assigning my address through IPv6 auto config
|
|
0:03:47
|
which is going to be fine. I'm still allowed to run the
|
|
0:03:50
|
routing protocols, the only difference is that I don't
|
|
0:03:52
|
automatically know what the address that Router 4 has assigned is.
|
|
0:03:56
|
If we look at the show ipv6 route local
|
|
0:04:02
|
this is the actual global unicast address that Router 4
|
|
0:04:05
|
now has assigned on that particular interface.
|
|
0:04:13
|
So next on Router 4, let's make sure that IPv6
|
|
0:04:16
|
unicast routing is on.
|
|
0:04:19
|
At the link level we'll say ipv6 eigrp 1
|
|
0:04:26
|
Globally ipv6 router eigrp 1
|
|
0:04:29
|
and then no shut down
|
|
0:04:34
|
so we see we now have an adjacency with Router 6
|
|
0:04:37
|
Note that the neighbor is using the link local address for the communication.
|
|
0:04:49
|
If we show ipv6 eigrp neighbors we can see that that's the link
|
|
0:04:53
|
local address of Router 6, if we show ipv6 route
|
|
0:04:59
|
we see that we have an internal EIGRP route which is the
|
|
0:05:01
|
loopback of Router 6
|
|
0:05:04
|
so it has the administrative distance of 94 internal
|
|
0:05:07
|
still going to be using the same external distance of 170
|
|
0:05:12
|
If we were to look at the show ipv6 eigrp topology
|
|
0:05:19
|
we could look at the topology and see the details about
|
|
0:05:23
|
any specific prefix
|
|
0:05:25
|
we can see the logic is the same between the regular
|
|
0:05:29
|
EIGRP process and this one
|
|
0:05:31
|
where we're looking at the minimum bandwidth along the path
|
|
0:05:34
|
the accumulative delay
|
|
0:05:38
|
the composite metric for this particular route is
|
|
0:05:41
|
156160
|
|
0:05:43
|
this then is our feasible distance.
|
|
0:05:46
|
If I had other alternate paths to this
|
|
0:05:49
|
I would then be running the feasibility condition against them
|
|
0:05:52
|
to see first who has the lowest end to end metric which
|
|
0:05:57
|
becomes my feasible distance
|
|
0:05:59
|
then any neighbor with a lower advertise distance
|
|
0:06:03
|
then my feasible distance
|
|
0:06:05
|
that would be considered a feasible successor
|
|
0:06:08
|
and can be used for unequal cost load balancing.
|
|
0:06:19
|
So just like RIP here, if you spend some time looking
|
|
0:06:21
|
through the configuration guide, there's not a whole
|
|
0:06:24
|
lot that you can do with the EIGRP process
|
|
0:06:27
|
a lot of the basic functionality between the version 4 and the
|
|
0:06:30
|
version 6 is still the same. We could do summarization
|
|
0:06:36
|
this would be at the
|
|
0:06:39
|
at the interface level ipv6 summary address eigrp
|
|
0:06:43
|
the AS number, then the summary that we're trying to generate.
|
|
0:06:49
|
Authentication for EIGRP
|
|
0:06:52
|
it's going to be very similar, it's going to use the key chain
|
|
0:06:55
|
so we specify the key chain at the link level
|
|
0:06:58
|
turn authentication on
|
|
0:07:01
|
specify what the key chain name is for that particular AS.
|
|
0:07:09
|
Then just like regular EIGRP, it does support automatic
|
|
0:07:12
|
key rotation based on the time of the day
|
|
0:07:16
|
so again, if we were doing that just like regular EIGRP
|
|
0:07:18
|
the key is to make sure that the routers' times are synchronized.
|
|
0:07:22
|
So generally you would want to run NTP to make sure they
|
|
0:07:26
|
agree on the clocks so that they do the migration from one key to the other
|
|
0:07:31
|
one at the same time.
|
|
0:07:42
|
So we can see most of the other features are the same
|
|
0:07:45
|
we could do EIGRP stub routing
|
|
0:07:47
|
this would be to reduce the EIGRP query domain size
|
|
0:07:51
|
so that the upstream neighbor does not ask me for
|
|
0:07:55
|
alternate paths to routes that have been lost.
|
|
0:08:00
|
It says you can change the metric weighting. This would affect
|
|
0:08:02
|
which portions of the composite metric are going to go into the actual
|
|
0:08:06
|
calculation.
|
|
0:08:08
|
If we look at here the adjusting the weights
|
|
0:08:12
|
it should tell us here
|
|
0:08:16
|
what the formula is we need -- we may need to look at the
|
|
0:08:19
|
command reference, so let's look at 12.4 T commands
|
|
0:08:24
|
then down to IPv6 commands
|
|
0:08:39
|
this would then be metric weights under EIGRP
|
|
0:08:51
|
and we can see what the calculation is, so it's identical
|
|
0:08:54
|
between the version 4 counterpart and
|
|
0:08:57
|
EIGRPv6, so again, if you understand how the
|
|
0:09:01
|
version 4 protocols work, the migration to the new ones is
|
|
0:09:04
|
very straightforward as long as we understand how the addressing
|
|
0:09:07
|
structure works.
|