|
0:00:13
|
In our next section here, we're going to look at RIP next generation
|
|
0:00:16
|
or RIPng for dynamic IPv6 routing.
|
|
0:00:21
|
Now just like RIP version 2 this is an open standards based
|
|
0:00:24
|
protocol. It's defined in RFC 2080 where the vast majority of the
|
|
0:00:29
|
majority of it is very similar to RIP version 2
|
|
0:00:33
|
so it is a distance factor protocol, still uses the same
|
|
0:00:36
|
principles of the hop count for the metric, the split-horizon
|
|
0:00:41
|
for preventing loops, it does have periodic updates.
|
|
0:00:45
|
The transport protocol is still using UDP, the difference
|
|
0:00:48
|
is that now it uses UDP port 521 as opposed to 520 where previously
|
|
0:00:54
|
it used multicast 224.0.0.9 in IPv4, now it's using FF02::9
|
|
0:01:02
|
so in IPv6, the multicast prefix
|
|
0:01:06
|
FF02 is the equivalent of IPv4's 244.0.0
|
|
0:01:12
|
so it is a link local multicast where FF02::1 would be
|
|
0:01:17
|
all hosts. Again, that's the equivalent of the all 255s
|
|
0:01:21
|
FF02::2 would be all routers equivalent of 224.0.0.2
|
|
0:01:28
|
we'll see with OSPF we use the FF02::5 and 6
|
|
0:01:33
|
RIP is using the 9, EIGRP is going to use A
|
|
0:01:37
|
which is the equivalent of 224.0.0.10
|
|
0:01:39
|
so a lot of the details behind the protocols will be very similar
|
|
0:01:43
|
between the version 4 and the version 6 implementations
|
|
0:01:48
|
so again, as long as you understand how IP version 4 works
|
|
0:01:51
|
you can learn most of this is just a comparison between
|
|
0:01:54
|
the new features of the protocols.
|
|
0:01:59
|
Now configuration wise, RIPng is very straightforward
|
|
0:02:02
|
the only thing we need to do is go to the link level
|
|
0:02:04
|
and turn the process on
|
|
0:02:07
|
so in IPv6 routing there is no network statement under the
|
|
0:02:10
|
routing processes, we're always enabling everything at the
|
|
0:02:13
|
per interface level where when we define the interface process
|
|
0:02:17
|
it is automatically going to enable the global process.
|
|
0:02:22
|
The only real caveat that is different between RIPng
|
|
0:02:25
|
and RIP version 2 is that split-horizon is on globally
|
|
0:02:29
|
under the process, so if we were to run RIPng
|
|
0:02:34
|
on our frame relay network from Router 5 down to the spokes
|
|
0:02:38
|
if Router 5 wanted to accept an update in from Router 2
|
|
0:02:42
|
and then send this back down to the other spokes
|
|
0:02:45
|
it would have to disable the split-horizon process globally.
|
|
0:02:49
|
So it's globally under the RIP process, it is not
|
|
0:02:52
|
at a per link level like it is in IP version 4
|
|
0:02:59
|
so up to this point, I have some basic IPv6 subnets
|
|
0:03:03
|
that are configured on the VLAN 8 of Switch 2
|
|
0:03:06
|
the transit link between Router 5 and Switch 2
|
|
0:03:10
|
Router 5's LAN segment
|
|
0:03:12
|
the frame relay between 1 and 5
|
|
0:03:14
|
the LAN between 1 and 6
|
|
0:03:16
|
the LAN between 6 and Switch 1
|
|
0:03:18
|
and then finally the VLAN 7 interface of Switch 1
|
|
0:03:24
|
So let's look at enabling RIP version 2 on some of these interfaces.
|
|
0:03:27
|
We'll start with the connections between Router 5 and Switch 2
|
|
0:03:30
|
And again, our configuration is very straightforward for this.
|
|
0:03:35
|
So we simply go to the link level in this case on Switch 2, this
|
|
0:03:38
|
is VLAN 8
|
|
0:03:40
|
we say ipv6 rip
|
|
0:03:42
|
give it a locally significant process ID, so this could be
|
|
0:03:46
|
a name or a number we could just say ipv6 rip 1
|
|
0:03:51
|
enable
|
|
0:03:56
|
we see the other interface level features
|
|
0:03:59
|
we could do summarization, we could advertise a default route
|
|
0:04:02
|
we could change the metric which is the same as the offset list
|
|
0:04:07
|
we say ipv6 rip
|
|
0:04:13
|
1 summary address
|
|
0:04:15
|
so any prefix that we have installed in the RIP database
|
|
0:04:18
|
we can then advertise a shorter match of it.
|
|
0:04:21
|
So if we had two /64s we could advertise this
|
|
0:04:25
|
as a /63
|
|
0:04:27
|
The summarization logic for IPv6 is going to be identical
|
|
0:04:30
|
to IPv4, the only difference is that you have more bits to
|
|
0:04:34
|
deal with so you have to be very careful about drawing the
|
|
0:04:37
|
or writing the address out in binary.
|
|
0:04:42
|
Now again, in the actual exam you will have access to the
|
|
0:04:45
|
Windows Calculator so you don't have to do the hex to
|
|
0:04:47
|
binary and binary to hex conversions manually.
|
|
0:04:51
|
You can write it out if you want to and then you can use the
|
|
0:04:54
|
calculator to double check your work.
|
|
0:05:00
|
So here on Switch 2 we have the VLAN 8 interface, then we have
|
|
0:05:03
|
VLAN 58, we'll simply say ipv6 rip 1 enable
|
|
0:05:09
|
we'll do this on Router 5's Fast Ethernet 0/0
|
|
0:05:13
|
this is the link that goes to Switch 2
|
|
0:05:17
|
we have the frame relay interface that goes to Router 1
|
|
0:05:22
|
Router 1 has the frame relay interface that goes to Router 5
|
|
0:05:26
|
the LAN interface that goes to Router 6
|
|
0:05:30
|
and then inbound on Router 6
|
|
0:05:34
|
Fast Ethernet 0/0.146
|
|
0:05:38
|
so ideally, if the updates are working
|
|
0:05:42
|
and on Router 6 let's also put this under the loopback.
|
|
0:05:45
|
We should be able to go to Switch 2
|
|
0:05:49
|
and be learning the loopback of Router 6
|
|
0:05:53
|
this would tell us if the transport from 6 to 1
|
|
0:05:56
|
from 1 to 5 and from 5 to Switch 2 is working.
|
|
0:05:59
|
Then just like IPv4 routing, just because I have a route to
|
|
0:06:04
|
you doesn't necessarily mean that you have a route back to me.
|
|
0:06:07
|
So we would need to check this bidirectionally.
|
|
0:06:14
|
So let's look now on Switch 2
|
|
0:06:17
|
look at the show ipv6 route rip
|
|
0:06:23
|
we are receiving 2001:155:28::/64
|
|
0:06:28
|
this is the frame relay interface that is between Router 1 and Router 5
|
|
0:06:33
|
but right now we're not receiving the link that is
|
|
0:06:37
|
behind Router 1
|
|
0:06:41
|
so let's see what is Router 1 receiving
|
|
0:06:43
|
if we show ipv6 route rip
|
|
0:06:49
|
we are learning the routes from Switch 2
|
|
0:06:54
|
so this is the VLAN 8 interface of Switch 2
|
|
0:06:59
|
we're also not learning the loopback of Router 6
|
|
0:07:03
|
so we may want to look at the LAN segment between Router 1
|
|
0:07:07
|
and Router 6, if we show run on Fast Ethernet 0/0
|
|
0:07:15
|
we do have the RIP process enabled.
|
|
0:07:20
|
On Router 6 if we look at our LAN interface
|
|
0:07:24
|
we do have RIP enabled. If we show ipv6 interface
|
|
0:07:28
|
Fast Ethernet 0/0.146
|
|
0:07:33
|
it says that the joined group addresses include FF02::9
|
|
0:07:40
|
this tells me that I am running the RIPng process
|
|
0:07:43
|
on the interface because the ::9 address, that is the
|
|
0:07:47
|
RIPng address.
|
|
0:07:49
|
So it may be just that the network is converging here
|
|
0:07:52
|
let's again look at the show ipv6 route rip
|
|
0:07:57
|
so we're not getting the update from 6 to Router 1
|
|
0:08:03
|
On Router 6 let's look at the show ipv6 route local
|
|
0:08:07
|
this is going to show all my connected interfaces.
|
|
0:08:12
|
The difference between this and the show ip route
|
|
0:08:14
|
connected is that the connected is going to show
|
|
0:08:17
|
the prefixes where the local is going to show the actual addresses.
|
|
0:08:22
|
So the local address on the Ethernet is 67::6
|
|
0:08:27
|
whereas the prefix on that link is 67::/64
|
|
0:08:36
|
so we should be sending these updates out.
|
|
0:08:38
|
There's really not that much complex configuration
|
|
0:08:41
|
that goes along with it.
|
|
0:08:42
|
If we look at these two...
|
|
0:08:48
|
two LAN interfaces, we should be sending RIP out.
|
|
0:08:50
|
If we look at the show run include ipv6, we would want to
|
|
0:08:54
|
make sure that IPv6 unicast routing is actually on
|
|
0:09:00
|
then let's check one more time at Router 1
|
|
0:09:02
|
show ipv6 route rip, so we're not receiving the prefix in.
|
|
0:09:05
|
Ok, next step that we would want to look at for troubleshooting
|
|
0:09:08
|
would be the debug for RIP to see if we're actually
|
|
0:09:11
|
advertising that out.
|
|
0:09:14
|
So on Router 6, let's say debug ipv6 rip
|
|
0:09:26
|
We should see the periodic updates coming in from Router 1
|
|
0:09:30
|
and then being sent outbound from Router 6
|
|
0:09:42
|
So Router 6 says that we are sending the multicast
|
|
0:09:45
|
update out to Fast Ethernet 0/0.146
|
|
0:09:56
|
we have received an update in. This was from Router 1
|
|
0:10:02
|
so let's look at the show ipv6 route
|
|
0:10:14
|
so we can see Router 6 is receiving the routes and actually
|
|
0:10:17
|
what I should have looked at on Router 1 I was looking at just the RIP routes
|
|
0:10:20
|
I may have the static route configured from before
|
|
0:10:25
|
which I do.
|
|
0:10:26
|
So the key is that just like in regular IPv4 routing
|
|
0:10:30
|
IPv6 is using the administrative distance to figure out which routes
|
|
0:10:33
|
are going to get installed in the table
|
|
0:10:36
|
then as we saw before for IPv4 RIP and IPv4 EIGRP
|
|
0:10:41
|
if the route is not installed in the routing table
|
|
0:10:45
|
it implies what?
|
|
0:10:52
|
If the route is not in the routing table, it also means that you
|
|
0:10:54
|
cannot advertise it.
|
|
0:10:56
|
So Router 1 has a static route configured for the loopback of Router 6
|
|
0:11:01
|
This is an equal longest match to the RIP route that we are
|
|
0:11:04
|
receiving in.
|
|
0:11:06
|
So when we receive the RIP route, it doesn't go into the
|
|
0:11:08
|
routing table which means then we can't advertise it.
|
|
0:11:11
|
So I simply need to remove those
|
|
0:11:16
|
static IPv6 routes on Router 1
|
|
0:11:33
|
Once these are removed, we can say clear ipv6
|
|
0:11:39
|
clear ipv6 rip 1
|
|
0:11:43
|
that's going to flush the routes out of the table.
|
|
0:11:45
|
Now if we show ipv6 route rip
|
|
0:11:49
|
We see now we're receiving the loopback in from Router 6
|
|
0:11:58
|
Now notice here in the routing table that when we are receiving
|
|
0:12:01
|
the updates, the next hop value is pointing at the
|
|
0:12:05
|
link local address of the remote neighbor.
|
|
0:12:09
|
Again, this is going to be true of all of the dynamic
|
|
0:12:12
|
protocols whether it's RIP, EIGRP, OSPF or BGP
|
|
0:12:16
|
Now BGP is a little bit more straightforward
|
|
0:12:18
|
because we can simply set the next hop value to whatever we want.
|
|
0:12:21
|
It's simply an attribute of the update.
|
|
0:12:25
|
But for IGP, this would then imply that we need Layer 3
|
|
0:12:29
|
to Layer 2 resolution for the remote link local address.
|
|
0:12:35
|
Now from Router 1's perspective, when we are trying to get to
|
|
0:12:38
|
the loopback of Router 6, this is not really an issue because we're
|
|
0:12:41
|
going over Ethernet.
|
|
0:12:43
|
So the ICMP neighbor discovery process is automatically going to take
|
|
0:12:46
|
care of this for us.
|
|
0:12:48
|
So from Router 1 if I were to ping this address here
|
|
0:12:54
|
we can see that we can send traffic to Router 6
|
|
0:12:57
|
but if I were to go behind the frame relay cloud
|
|
0:13:02
|
so let's say on Switch 2
|
|
0:13:05
|
we're now trying to send traffic all the way from Switch 2
|
|
0:13:10
|
this direction to Router 6's loopback.
|
|
0:13:15
|
Switch 2 does have the routes installed if we
|
|
0:13:18
|
show ipv6 route rip
|
|
0:13:20
|
so we do know the 6::6
|
|
0:13:26
|
but the problem is now going to be when the packet is
|
|
0:13:28
|
routed from Switch 2 to Router 5
|
|
0:13:31
|
Router 5 has the route, but when it does a lookup
|
|
0:13:35
|
for the next hop value
|
|
0:13:37
|
it points to the link local address of Router 1
|
|
0:13:41
|
on the multipoint frame relay interface.
|
|
0:13:52
|
So this would then imply from Router 5's perspective
|
|
0:13:55
|
when we look at the show ipv6 route rip
|
|
0:14:00
|
if we do not have a frame relay mapping for the
|
|
0:14:02
|
link local address of Router 1
|
|
0:14:06
|
we would not be properly -- we would not be able to properly
|
|
0:14:09
|
encapsulate any packet going towards this link local address.
|
|
0:14:15
|
So again, this is another reason why we would not want to
|
|
0:14:17
|
use multipoint non-broadcast interfaces
|
|
0:14:21
|
if we had separate point-to-point sub interfaces from the hub down to
|
|
0:14:25
|
the spoke, from the hub down to the spokes then we would never
|
|
0:14:28
|
run into this problem to begin with.
|
|
0:14:33
|
So it means now on Router 5 I need to add a frame relay map
|
|
0:14:37
|
for the link local address of Router 1
|
|
0:14:39
|
and tell it that this is reachable out circuit 501
|
|
0:14:50
|
so now we can see that we have connectivity from
|
|
0:14:53
|
Switch 2 all the way to Router 6's loopback.
|
|
0:14:58
|
Also when we look at the address that was used
|
|
0:15:00
|
on Router 5, it's kind of hard to keep track of exactly what
|
|
0:15:05
|
address this is relating to
|
|
0:15:08
|
so in this particular case, you'll see a lot of the examples
|
|
0:15:11
|
in the volume 1 workbook and the volume 2 workbook
|
|
0:15:14
|
where we change the link local address on the NBMA
|
|
0:15:17
|
interface. You can do this if you want to, you don't
|
|
0:15:21
|
necessarily have to.
|
|
0:15:23
|
It's just more for the clarity of the configuration that if
|
|
0:15:26
|
I were to go to Router 1's point-to-point serial
|
|
0:15:32
|
and say the ipv6 address FE80::1 is a link local address
|
|
0:15:40
|
it now means that when I advertise my RIP updates to
|
|
0:15:44
|
Router 5
|
|
0:15:46
|
and I show ipv6 route rip on Router 5
|
|
0:15:53
|
we see that these are now being received in through the next
|
|
0:15:57
|
hop FE80::1
|
|
0:16:00
|
so I can now just tell visually that that's
|
|
0:16:03
|
Router 1 that's advertising that route to me.
|
|
0:16:06
|
Then of course this would mean I would need to change the
|
|
0:16:09
|
frame relay mapping
|
|
0:16:11
|
to point FE80::1
|
|
0:16:14
|
towards circuit 501
|
|
0:16:27
|
so we're not going to spend a ton of time on the different
|
|
0:16:29
|
features for the IGPs
|
|
0:16:31
|
if under the RIP process globally, if we say ipv6
|
|
0:16:35
|
router rip 1
|
|
0:16:38
|
you see that there's not too many features that the protocol
|
|
0:16:40
|
has to begin with, so we could change the administrative distance
|
|
0:16:44
|
we could do a distribute list for filtering.
|
|
0:16:48
|
We can see that this only supports the prefix list for filtering
|
|
0:16:52
|
because IPv6 makes the distinction between a prefix
|
|
0:16:56
|
list being used for routing and an access list being used
|
|
0:17:00
|
for a traffic filter.
|
|
0:17:02
|
So it's a little more obvious as to which they apply to with IPv6
|
|
0:17:06
|
versus IPv4
|
|
0:17:12
|
We have maximum paths if we wanted to do equal cost load balancing
|
|
0:17:16
|
we could turn poison reverse on or disable it globally
|
|
0:17:20
|
and I believe this is on by default.
|
|
0:17:23
|
We could change the port number if we wanted to
|
|
0:17:25
|
I'm not a 100 percent sure why you would do that, but
|
|
0:17:27
|
you technically can, again, this defaults to 521
|
|
0:17:32
|
Redistribution in IPv6 is going to be same type of logic
|
|
0:17:36
|
as IPv4
|
|
0:17:38
|
One of the caveats we'll see with this when we say
|
|
0:17:42
|
redistribute another protocol let's say redistribute ospf 1
|
|
0:17:49
|
By default, it is not going to include the connected interfaces
|
|
0:17:54
|
that are in the OSPF process.
|
|
0:18:00
|
So as we talked about before with IP version 4 redistribution
|
|
0:18:04
|
there's two steps that happen automatically
|
|
0:18:07
|
the first is that the router looks in the routing table for
|
|
0:18:10
|
any routes installed as OSPF
|
|
0:18:14
|
then it looks for any connected interfaces that are running the
|
|
0:18:16
|
OSPF process.
|
|
0:18:20
|
In the case of IPv6, it's only that first step
|
|
0:18:23
|
it's only looking at what are the dynamic routes learned from OSPF
|
|
0:18:27
|
if we want to include the connected interfaces, we can
|
|
0:18:31
|
but we need to specifically tell the process to do that.
|
|
0:18:39
|
So this would mean that if we had the RIP domain
|
|
0:18:43
|
between these four devices, then we were running OSPF
|
|
0:18:48
|
between Switch 1 and Router 6
|
|
0:18:51
|
so we have redistribution of RIP into OSPF on Router 6
|
|
0:18:57
|
it would mean that by default, the OSPF domain
|
|
0:19:00
|
would not have a route to this LAN segment
|
|
0:19:03
|
and then likewise the RIP domain would not have a route
|
|
0:19:06
|
to this LAN segment.
|
|
0:19:10
|
We can configure it to do that, we just need to simply
|
|
0:19:12
|
add the include connected command onto the end of the redistribution statement.
|
|
0:19:19
|
Now documentation wise, you'll see that there's not as many
|
|
0:19:22
|
features available in IPv6 yet as there are
|
|
0:19:26
|
in IPv4
|
|
0:19:28
|
so if we go to the 12.4 T configuration guide
|
|
0:19:33
|
then down to IPv6
|
|
0:19:35
|
configuration guide
|
|
0:19:39
|
then we see the protocols
|
|
0:19:41
|
the routing protocols would be RIPng
|
|
0:19:45
|
OSPF
|
|
0:19:48
|
IS-to-IS
|
|
0:19:50
|
EIGRP, BGP, static routing and policy routing.
|
|
0:20:00
|
For the RIP configuration, even if you were to look at the command
|
|
0:20:02
|
reference, there's really not that much that you can do with this
|
|
0:20:06
|
so we can do distribute list filtering, we could do route tagging
|
|
0:20:10
|
during redistribution
|
|
0:20:15
|
customizing the RIP process probably this is things like
|
|
0:20:18
|
changing the timers
|
|
0:20:22
|
the number of maximum paths
|
|
0:20:24
|
default information
|
|
0:20:26
|
so most of this is self-explanatory, you just need to simply spend
|
|
0:20:28
|
some time reading through the configuration guide and looking at
|
|
0:20:31
|
the command reference.
|