|
0:00:13
|
So next, we're going to talk about the different IPv6
|
|
0:00:16
|
routing protocols.
|
|
0:00:19
|
We'll see that IPv6 does support routing basically
|
|
0:00:22
|
through all the different variations in the current
|
|
0:00:25
|
IOS versions so we could do static routing, RIPng
|
|
0:00:29
|
is the equivalent of RIPv2, EIGRPv6 is the equivalent of
|
|
0:00:33
|
regular EIGRP
|
|
0:00:34
|
OSPFv3 is the equivalent of OSPFv2
|
|
0:00:38
|
IS-to-IS and multiprotocol BGP
|
|
0:00:41
|
use the same protocol for both the IPv4 and the IPv6
|
|
0:00:47
|
address family.
|
|
0:00:50
|
So in the case of IS-to-IS, it's simply a type length value
|
|
0:00:53
|
extension in order to do IPv6 routing.
|
|
0:00:58
|
For multiprotocol BGP, it's simply a new AFI
|
|
0:01:02
|
and SAFI, the Address Family Identifier and the Sub Address Family Identifier
|
|
0:01:09
|
where in the case of IPv4 unicast routing, we use
|
|
0:01:12
|
AFI 1 and SAFI 1
|
|
0:01:15
|
IPv6 unicast routing is AFI 2
|
|
0:01:19
|
and sub address family identifier 1
|
|
0:01:21
|
so 11 for IPv4 unicast 21 for IPv6 unicast
|
|
0:01:30
|
then we also have policy routing basically the same logic as we have for
|
|
0:01:33
|
IPv4 where we can match a criteria based on an access list
|
|
0:01:39
|
in a route map
|
|
0:01:41
|
and then set either the outgoing interface or the connected next hop
|
|
0:01:45
|
that we want to route traffic to as the packets
|
|
0:01:48
|
come in on that particular link.
|
|
0:01:53
|
So we're not going to get into a lot of detail with the
|
|
0:01:55
|
static routing and the policy routing, it's the same logic as
|
|
0:01:58
|
we already talked about in regular IPv4 routing.
|
|
0:02:01
|
For the dynamic protocols I am going to show examples
|
|
0:02:04
|
of all of these today though.
|
|
0:02:08
|
Now one of the important points to note about the dynamic
|
|
0:02:11
|
protocols with IPv6 is that the routing information
|
|
0:02:15
|
as it is learned inbound
|
|
0:02:19
|
recurses to the remote link local address
|
|
0:02:22
|
of the neighbor
|
|
0:02:24
|
as opposed to their global unicast address.
|
|
0:02:28
|
Now again, the link local address is only locally significant
|
|
0:02:31
|
between any of the neighbors on that particular segment.
|
|
0:02:36
|
So in the case of an Ethernet LAN whoever is in that VLAN
|
|
0:02:40
|
is going to have significance for those particular link local addresses.
|
|
0:02:44
|
For a point-to-point link like PPP or HDLC
|
|
0:02:47
|
it's just going to be significant between the two neighbors on the segment.
|
|
0:02:55
|
For any point-to-point or broadcast configuration
|
|
0:02:59
|
so again, either Ethernet or PPP, HDLC
|
|
0:03:03
|
we really don't care about the link local addressing
|
|
0:03:06
|
because either ICMP neighbor discovery is going to
|
|
0:03:08
|
take care of the resolution for us or with point-to-point we don't
|
|
0:03:12
|
need the resolution. The exception is going to be when we run this
|
|
0:03:16
|
over multipoint non-broadcast not only will we need a resolution
|
|
0:03:21
|
for the remote global unicast address, but also for the remote
|
|
0:03:26
|
link local address.
|
|
0:03:34
|
Now the reason that the IOS does this is that with
|
|
0:03:37
|
IPv6, you can have designs where you don't use
|
|
0:03:41
|
global unicast addresses on the transit links
|
|
0:03:44
|
and you only assign the global addresses down to your actual
|
|
0:03:48
|
end hosts.
|
|
0:03:51
|
Now the main reason to do this is for security of the network
|
|
0:03:54
|
because from the service provider's point of view
|
|
0:03:57
|
there should be no reason that people are sending traffic
|
|
0:04:00
|
actually to the frame relay link itself
|
|
0:04:03
|
or sending traffic to the point-to-point link between
|
|
0:04:06
|
Router 1 and Router 3
|
|
0:04:09
|
so when IPv6 traffic goes into the network, usually
|
|
0:04:12
|
it should be coming from a host on the LAN
|
|
0:04:15
|
going to a host on the LAN
|
|
0:04:18
|
so this means that we would have a global unicast address on
|
|
0:04:21
|
Switch 3's VLAN 9 interface, a global unicast address
|
|
0:04:25
|
on Router 5's Fast Ethernet 0/1 interface
|
|
0:04:30
|
but then the transit links between them we really only
|
|
0:04:33
|
care about the locally significant communication between the two
|
|
0:04:37
|
routers that are on that particular segment.
|
|
0:04:40
|
So if Switch 3 and Switch 1 are running RIPng
|
|
0:04:45
|
the only people that really care about that are Switch 1 and
|
|
0:04:48
|
Switch 3 on that particular segment.
|
|
0:04:53
|
So when you're configuring this on the routers, you technically
|
|
0:04:56
|
do not have to use global unicast addresses at all
|
|
0:04:59
|
you could route the entire network on just link local addresses
|
|
0:05:04
|
but then the potential problem you have with that is it makes
|
|
0:05:07
|
management a little bit more difficult to the router
|
|
0:05:10
|
like you wouldn't be able to telnet to the router
|
|
0:05:13
|
because none of the link local addresses can be routed
|
|
0:05:16
|
between the interfaces.
|
|
0:05:19
|
So in a lot of designs, what people do is have a loopback
|
|
0:05:24
|
that's on the router that either is a global unicast address that's
|
|
0:05:28
|
globally routable or something that's just a unique local address
|
|
0:05:33
|
this would be used for in-band management
|
|
0:05:36
|
like SSHing to the router or doing SNMP polling
|
|
0:05:43
|
but then any of the routing communication over the LAN
|
|
0:05:46
|
or over the point-to-point segments, that would just use the link
|
|
0:05:49
|
local addresses.
|
|
0:05:53
|
So first let's take a look at static routing with IPv6
|
|
0:05:57
|
where mainly there are three variations of this
|
|
0:05:59
|
just like there were in IPv4
|
|
0:06:02
|
where we can use a static route that points to a next
|
|
0:06:06
|
hop value or that points to an interface.
|
|
0:06:11
|
Now the difference between them depends on whether
|
|
0:06:13
|
the interface is multipoint or point-to-point.
|
|
0:06:16
|
If we're routing to a point-to-point interface, then we don't really
|
|
0:06:20
|
care because there's no Layer 3 to Layer 2 resolution
|
|
0:06:23
|
that's required.
|
|
0:06:26
|
Any time we are routing to a multipoint interface
|
|
0:06:30
|
if the static route points directly to the link
|
|
0:06:33
|
it means that we would need to resolve the Layer 2
|
|
0:06:35
|
address of the final destination, not the intermediary next hop
|
|
0:06:42
|
so in the case of IPv6, it almost never makes sense to
|
|
0:06:45
|
point a static route towards a multipoint interface.
|
|
0:06:48
|
We'll see one of the issues that is inherent to this
|
|
0:06:52
|
is the lack of proxy neighbor discovery or proxy inverse
|
|
0:06:57
|
neighbor discovery that is replacing the proxy ARP feature of
|
|
0:07:01
|
IPv4
|
|
0:07:06
|
Now technically there is an RFC that specifies how
|
|
0:07:09
|
proxy neighbor discovery is supposed to work
|
|
0:07:11
|
but as far as I know, Cisco IOS does not implement that.
|
|
0:07:15
|
It's kind of a security issue most of the time in the real world
|
|
0:07:18
|
you should disable regular proxy ARP for IPv4
|
|
0:07:22
|
the same would be true for IPv6
|
|
0:07:29
|
Now any time we are routing to a next hop value
|
|
0:07:33
|
regardless of whether this is on a multipoint non-broadcast
|
|
0:07:37
|
interface or a multipoint broadcast interface, it
|
|
0:07:40
|
means that we're going to do the Layer 2 resolution for the next hop value
|
|
0:07:43
|
itself, not for the final destination
|
|
0:07:47
|
which is typically what we would want to do if we were pointing a
|
|
0:07:50
|
static route at a multipoint interface
|
|
0:07:52
|
we would want to route to the next hop, not directly
|
|
0:07:55
|
to the interface itself.
|
|
0:08:07
|
So let's take a look at this in our particular topology
|
|
0:08:10
|
I'm going to add some additional addresses here
|
|
0:08:12
|
where we will enable IPv6 on Router 6
|
|
0:08:17
|
on the LAN segment between Switch 1 and Router 6
|
|
0:08:22
|
we already have it configured on the link between Router 1
|
|
0:08:25
|
and Router 5, then we'll also put it on Router 5's
|
|
0:08:30
|
Ethernet segment.
|
|
0:08:32
|
Now for some of the switch platforms, you'll see that
|
|
0:08:36
|
by default the memory is not allocated
|
|
0:08:40
|
to store any buffer space for the IPv6 routing table.
|
|
0:08:45
|
So in the case of the 3560 if I go to global config and
|
|
0:08:48
|
say IPv6 unicast routing
|
|
0:08:51
|
it looks like the platform doesn't support this command
|
|
0:08:54
|
when in reality what I need to do first is change the
|
|
0:08:57
|
buffer allocation of the switch database manager
|
|
0:09:01
|
or the SDM template.
|
|
0:09:08
|
To do this I'm going to say sdm prefer
|
|
0:09:11
|
and I want to run both IPv4 and IPv6 unicast routing.
|
|
0:09:15
|
So sdm prefer dual ipv6
|
|
0:09:18
|
dual ipv4 ipv6 routing
|
|
0:09:20
|
the problem with this now though is that I need to
|
|
0:09:23
|
save and reload.
|
|
0:09:25
|
So within the scope of the lab exam if you know that
|
|
0:09:27
|
you need to run IPv6 on that particular device
|
|
0:09:30
|
you may want to just change the template, reload and then
|
|
0:09:33
|
move on to something else and come back later.
|
|
0:09:39
|
So I'm going to do this on Switch 1 and Switch 2
|
|
0:09:45
|
so on Switch 2 I'll change the SDM template and then
|
|
0:09:49
|
save and reload.
|
|
0:09:59
|
In the meantime while we're waiting for this to come back, let's go to
|
|
0:10:01
|
Router 6
|
|
0:10:04
|
we'll turn IPv6 unicast routing on.
|
|
0:10:11
|
Router 6 is going to be in the same subnet that Router 1 is
|
|
0:10:19
|
this is on Fast Ethernet 0/0.146
|
|
0:10:24
|
so its address is going to end in a 6
|
|
0:10:27
|
On the link to Switch 1
|
|
0:10:31
|
this will be 2001:155:28:67::6
|
|
0:10:45
|
then I'll also add a loopback interface on Router 6, so
|
|
0:10:48
|
interface loopback 0
|
|
0:10:51
|
ipv6 address I'll make this a 128 that would be a host
|
|
0:10:54
|
route, let's say 155:28:6::6/128
|
|
0:11:03
|
so 128 here this is equivalent of the /32 host route
|
|
0:11:07
|
in IP version 4
|
|
0:11:18
|
so next let's take a look at Router 1
|
|
0:11:21
|
and look at the different variations of configuring the static routes
|
|
0:11:24
|
whether we're pointing towards the interface pointing towards the
|
|
0:11:28
|
next hop and then when we're pointing at the interface with the
|
|
0:11:31
|
differences between the point-to-point and the
|
|
0:11:33
|
multipoint config.
|
|
0:11:38
|
And before I do this, on Router 5 I need to add
|
|
0:11:41
|
that additional segment, so let's say on Fast Ethernet 0/1
|
|
0:11:52
|
this will have the ipv6 address
|
|
0:11:55
|
2001:155:28:5::5/64
|
|
0:12:07
|
so on Router 1 we'll look at a couple different variations of the static routes.
|
|
0:12:12
|
The first one is simply going to be routing towards the next
|
|
0:12:15
|
hop value.
|
|
0:12:17
|
So if Router 1 were to say to get to the destination
|
|
0:12:21
|
that is Router 6's loopback
|
|
0:12:24
|
so that exact host route
|
|
0:12:29
|
I'm going to route towards the next hop of Router 6
|
|
0:12:35
|
What this essentially means is that when Router 1
|
|
0:12:38
|
sends traffic to the final destination,
|
|
0:12:41
|
it's going to look for the Layer 2 address
|
|
0:12:44
|
of the next hop.
|
|
0:12:54
|
Now since the next hop is directly connected on the LAN
|
|
0:12:57
|
it means that if Router 1 looks at the show ipv6 neighbors
|
|
0:13:01
|
which is the equivalent of the show arp
|
|
0:13:04
|
Router 1 should already know what is the Mac address
|
|
0:13:06
|
that is associated with Router 6
|
|
0:13:09
|
So based on the fact that we know the Mac address of the
|
|
0:13:12
|
next hop, we're going to infer that that is the Layer 2 address
|
|
0:13:16
|
we should use to reach the loopback of Router 6
|
|
0:13:26
|
Now if we were to change this route and point it
|
|
0:13:29
|
directly out the interface
|
|
0:13:32
|
the problem that we're going to run into is that the router
|
|
0:13:35
|
does not run proxy neighbor discovery.
|
|
0:13:38
|
So if I were now to ping
|
|
0:13:44
|
ping 2001:155:28:6::6
|
|
0:13:48
|
I have the debug ipv6 packet on
|
|
0:13:52
|
we should see that Router 1 is going to try to send the
|
|
0:13:56
|
resolution request
|
|
0:13:58
|
for this particular neighbor
|
|
0:14:02
|
but it doesn't know what the Mac address is.
|
|
0:14:06
|
It says encapsulation failed, resolving the next hop
|
|
0:14:10
|
on the interface, so the key is that this message here means
|
|
0:14:13
|
that we're trying to do a Layer 3 to Layer 2 resolution
|
|
0:14:16
|
not for the intermediary next hop value, but for the final
|
|
0:14:21
|
destination.
|
|
0:14:28
|
Now for IP version 4, this is usually not a problem
|
|
0:14:32
|
because if the router receives an arp request for something it
|
|
0:14:35
|
already has a route for in the routing table
|
|
0:14:39
|
it will reply with its own Mac address in proxy
|
|
0:14:43
|
and that's what proxy arp does for IPv4
|
|
0:14:46
|
so if I were to go to Router 6
|
|
0:14:49
|
and say that I had the IPv4 address 6.6.6.6/32
|
|
0:14:58
|
then on Router 1 I said to get to the address 6.6.6.6/32
|
|
0:15:06
|
I'm going to go directly out Fast Ethernet 0/0
|
|
0:15:11
|
basically what this means is that Router 1 is going to send an
|
|
0:15:14
|
arp request and Router 6 is going to reply with its own
|
|
0:15:18
|
Mac address in proxy.
|
|
0:15:26
|
However, with IP version 6, this is not supported in the IOS
|
|
0:15:29
|
so Router 1 does not know what is the Mac address that should
|
|
0:15:33
|
be associated with this final destination.
|
|
0:15:42
|
So essentially there's two solutions to this problem
|
|
0:15:45
|
the first and easiest one would just be not to point the route
|
|
0:15:48
|
out the interface.
|
|
0:15:50
|
If the route pointed to the next hop, then it's going to
|
|
0:15:52
|
solve the problem to begin with.
|
|
0:15:55
|
But if we did not want to change the static route here
|
|
0:15:58
|
if on Router 1 we said show run include route
|
|
0:16:05
|
what kind of workaround could do we do in order for Router 1
|
|
0:16:08
|
to get connectivity
|
|
0:16:10
|
to this address?
|
|
0:16:22
|
We could basically do the equivalent of a static arp entry
|
|
0:16:27
|
so if we told Router 1 what is the Mac address
|
|
0:16:30
|
of that particular IPv6 destination
|
|
0:16:34
|
if we say the IPv6 neighbor
|
|
0:16:37
|
with this IPv6 address
|
|
0:16:39
|
is out Fast Ethernet 0/0
|
|
0:16:43
|
and it has this Mac address
|
|
0:16:48
|
this is essentially a static ICMP neighbor discovery mapping
|
|
0:16:53
|
so now Router 1 should be able to reach that destination
|
|
0:16:59
|
so the key point here is that it's not really a routing problem per se
|
|
0:17:03
|
it's a problem with the Layer 3 to Layer 2 resolution
|
|
0:17:07
|
that ultimately controls the encapsulation.
|
|
0:17:10
|
So if the Router doesn't know what Mac address to use or what DLCI
|
|
0:17:14
|
to use on the frame relay, it's not going to be able to build the
|
|
0:17:16
|
Layer 2 frame.
|
|
0:17:25
|
Now the same would be true over the frame relay network.
|
|
0:17:28
|
On Router 1 if I were to say to get to
|
|
0:17:30
|
2001:155:28:5:5
|
|
0:17:37
|
I would want to use the next hop value of Router 5
|
|
0:17:45
|
so we'll say /64
|
|
0:17:50
|
Now if I send packets to this particular destination
|
|
0:17:54
|
since I already have a resolution for the next hop
|
|
0:17:58
|
I'm able to reach that.
|
|
0:18:01
|
Now additionally, Router 1 has a point-to-point sub interface here
|
|
0:18:08
|
that is configured for the frame relay
|
|
0:18:10
|
this means that I could change the route so that it points directly
|
|
0:18:15
|
at the point-to-point interface and it's not going to negatively
|
|
0:18:20
|
affect the connectivity because Router 1 already knows what is the
|
|
0:18:25
|
DLCI number that is supposed to be used for that link.
|
|
0:18:38
|
Now on the way back from Router 5's perspective, it's going to
|
|
0:18:41
|
be different because Router 5 is using the multipoint frame relay
|
|
0:18:46
|
interface, if we show run interface serial 0/0/0
|
|
0:18:53
|
since this is a multipoint NBMA interface, Router 5 had to do
|
|
0:18:56
|
the static Layer 3 to Layer 2 resolution.
|
|
0:19:00
|
If I were now to say to get to the destination 2001:155:28:146/64
|
|
0:19:14
|
so this is the segment between routers 1, 4 and 6
|
|
0:19:19
|
I want to use the next hop of Router 1
|
|
0:19:24
|
then this should be fine because we already know that that
|
|
0:19:29
|
next hop value is reachable via circuit number 501
|
|
0:19:40
|
Now the problem would come in here if I were to change the route
|
|
0:19:44
|
and say that instead of routing towards the next hop value
|
|
0:19:50
|
we're going to route directly to the interface.
|
|
0:19:52
|
We're routing directly at serial 0/0/0
|
|
0:19:56
|
If we look at the debug frame relay packets
|
|
0:20:04
|
then we ping
|
|
0:20:10
|
the address of Router 1
|
|
0:20:21
|
we see that Router 5 says encapsulation is failing
|
|
0:20:24
|
because it doesn't have a mapping for that particular destination.
|
|
0:20:34
|
So again, just like on Router 1 we basically have two solutions here.
|
|
0:20:38
|
We could either fix the route which would be really the easiest
|
|
0:20:42
|
way to do this is just to change the route so that it points
|
|
0:20:45
|
at the next hop value and not the interface
|
|
0:20:50
|
or we could do what as a workaround?
|
|
0:20:59
|
So what is the problem that Router 5 is having in the first place?
|
|
0:21:05
|
It knows the route to the destination, but it doesn't know what?
|
|
0:21:15
|
It knows what interface to use, but it doesn't know what
|
|
0:21:18
|
DLCI to use, so if we were to go to the frame relay interface
|
|
0:21:22
|
and say to get to the final destination, if we said
|
|
0:21:26
|
frame relay map ipv6
|
|
0:21:28
|
then put the address that we're actually trying to send the traffic to
|
|
0:21:35
|
and tell it that this is reachable out circuit 501
|
|
0:21:41
|
we're basically manually binding what particular Layer 2 address
|
|
0:21:46
|
is supposed to go inside of that packet.
|
|
0:21:50
|
The problem then would be if we were to try to send traffic to
|
|
0:21:52
|
any other destination on that LAN, Router 5 is not going to
|
|
0:21:57
|
know how to resolve that.
|
|
0:22:05
|
So it's kind of like a stupid router trick, you could get it to do this
|
|
0:22:09
|
but there's really no design reason that you would want to.
|
|
0:22:12
|
So instead, the static route for a multipoint interface
|
|
0:22:16
|
it should always point at the next hop value.
|
|
0:22:19
|
If the interface is point-to-point like a point-to-point GRE tunnel
|
|
0:22:23
|
or an IPv6 IP tunnel, an automatic 6 to 4 tunnel
|
|
0:22:27
|
that's fine with pointing the route at the interface
|
|
0:22:31
|
but any time it's multipoint so an Ethernet or a multipoint
|
|
0:22:34
|
frame relay interface, the route should always point at the next
|
|
0:22:37
|
hop value.
|
|
0:22:47
|
Now there's a question here, "What about the link local address?"
|
|
0:22:51
|
Technically they could also point at the remote link local address.
|
|
0:22:56
|
When we do that, we would need to tell the router what
|
|
0:22:58
|
interface to recurse to
|
|
0:23:00
|
because by default, it doesn't know where the link local address
|
|
0:23:04
|
is reachable because we could have the same address let's say
|
|
0:23:08
|
FE80::1 we could have that same address assigned to multiple
|
|
0:23:13
|
links on the same local router.
|
|
0:23:21
|
So let's see on Router -- Switch 1
|
|
0:23:24
|
if it came back and we're running
|
|
0:23:27
|
let's look at the show sdm prefer
|
|
0:23:42
|
so it says now we're running the desktop IPv4 and IPv6
|
|
0:23:45
|
routing template which basically means that we have buffer space that's
|
|
0:23:49
|
allocated both for IPv6 routes and IPv4 routes.
|
|
0:23:55
|
So next let's enable IPv6 between Router 6 and Switch 1
|
|
0:23:59
|
but I'm not going to do this with a global address.
|
|
0:24:03
|
I'm simply going to go to the interface VLAN 67
|
|
0:24:07
|
and say ipv6 enable
|
|
0:24:12
|
what this command does is to turn the protocol on the interface
|
|
0:24:16
|
but not to assign a global unicast address.
|
|
0:24:20
|
This is telling the router just to generate the link local address.
|
|
0:24:27
|
Now if we were to look at the show ipv6 neighbors
|
|
0:24:33
|
from Switch 1 we would basically need to know what is the link
|
|
0:24:36
|
local address of Router 6
|
|
0:24:40
|
Now I could just go to Router 6 and say show ipv6 neighbors and
|
|
0:24:45
|
look at what the Mac address is. I might also be able to
|
|
0:24:48
|
get this if we send packets to FF02::1 which is the all hosts
|
|
0:24:56
|
multicast
|
|
0:24:58
|
this is the equivalent of the all 255 address in IPv4
|
|
0:25:08
|
so basically what this is telling me here if we look at the show ipv6 neighbors
|
|
0:25:13
|
this should now be the link local address of Router 6
|
|
0:25:20
|
On Router 6 if we look at the show ipv6 route local
|
|
0:25:26
|
this tells me what are the local addresses that I have
|
|
0:25:29
|
assigned on my interfaces, we see the loopback 0 is
|
|
0:25:33
|
2001:155:28::6/128
|
|
0:25:41
|
Now on Switch 1 let's turn routing on, so ipv6 unicast routing
|
|
0:25:48
|
then I'll say to get to this particular destination
|
|
0:25:53
|
I'm going to simply use the link local destination.
|
|
0:25:59
|
The problem is now the router also needs to know what is the outgoing interface
|
|
0:26:04
|
because that link local address it could be on
|
|
0:26:06
|
multiple possible links.
|
|
0:26:09
|
So this needs to be on VLAN 67
|
|
0:26:13
|
Now if I were to send traffic to this destination
|
|
0:26:20
|
we can see I can reach that address even though I don't
|
|
0:26:22
|
have a global unicast address assigned to my local interface.
|
|
0:26:35
|
If I were to telnet to that address on Router 6
|
|
0:26:38
|
let's say on Router 6 line console or line vty 0 4
|
|
0:26:44
|
no login
|
|
0:26:48
|
Switch 1 should be able to
|
|
0:26:56
|
telnet to that, I may need to source this from
|
|
0:27:02
|
a global unicast source.
|
|
0:27:06
|
So the key here is that in the normal design if you're
|
|
0:27:09
|
using only link local, it means you're using that segment
|
|
0:27:12
|
just as transit, so if there's an end host here and an end host
|
|
0:27:18
|
here, we could use global unicast addresses on those
|
|
0:27:22
|
end segments, but then use just link local addresses on the
|
|
0:27:26
|
transit links because no one is actually going to
|
|
0:27:30
|
send traffic to the VLAN 67 itself
|
|
0:27:33
|
or the VLAN 79
|
|
0:27:35
|
again, assuming that those are just transit interfaces
|
|
0:27:38
|
that they're not where any of the actual end hosts reside.
|
|
0:27:44
|
So again, the IPv6 static routing is the same exact
|
|
0:27:47
|
logic as IP version 4
|
|
0:27:49
|
you can either route to the next hop or you can route to the
|
|
0:27:51
|
interface, but the problem is if you route at a multipoint
|
|
0:27:54
|
interface, you're going to have Layer 3 to Layer 2 resolution problems.
|
|
0:27:58
|
So it's a general rule just only point the static route
|
|
0:28:01
|
to an interface if it's point-to-point to begin with
|
|
0:28:04
|
like a GRE tunnel or a PPP interface.
|