1
00:00:01,930 --> 00:00:08,425
[music]

2
00:00:08,426 --> 00:00:14,651
Okay, so next is going to
be redistribution in IPv6.

3
00:00:14,652 --> 00:00:19,149
We'll again be using our-- this
will probably be one of the last

4
00:00:19,149 --> 00:00:20,650
times we use this topology.

5
00:00:20,651 --> 00:00:26,470
I'm going to be moving over to a different
one for doing tunneling, because

6
00:00:26,471 --> 00:00:29,249
we already have IPv6 running
everywhere here, so there's

7
00:00:29,250 --> 00:00:32,440
not really any place to tunnel.

8
00:00:32,441 --> 00:00:37,022
But what we're going to do is we'll
use this topology here for our

9
00:00:37,023 --> 00:00:40,891
redistribution, and I'm not going
to get real fancy with it.

10
00:00:40,892 --> 00:00:45,084
We're just going to look at some of the
little caveats with redistribution.

11
00:00:45,085 --> 00:00:48,015
This is, of course, a whole other topic.

12
00:00:48,016 --> 00:00:54,972
INE has several other videos out there
just on the topic of redistribution,

13
00:00:54,973 --> 00:00:59,278
so we're not going to get into a
whole bunch of details such as loop

14
00:00:59,279 --> 00:01:04,007
prevention, and all that kind of
stuff, because it is fundamentally

15
00:01:04,008 --> 00:01:11,946
the same as IPv4 redistribution. You still
have to account for possible loops,

16
00:01:11,947 --> 00:01:17,144
we can still use route tagging,
you can use distribute lists,

17
00:01:17,145 --> 00:01:24,618
you can use prefix lists, tags, all the
different methods of controlling loops

18
00:01:24,619 --> 00:01:31,407
are the same. The only thing that
we really need to worry about

19
00:01:31,408 --> 00:01:33,874
is a couple of little caveats, and then,

20
00:01:33,875 --> 00:01:37,744
of course, we have to also get
back to the OSPF database and look

21
00:01:37,745 --> 00:01:43,510
at the changes to the externals, although
that's not going to take a long time.

22
00:01:43,511 --> 00:01:47,037
Now, one of the fundamental
things you really, really, really

23
00:01:47,038 --> 00:01:52,590
need to watch for is that the connected
interfaces are not automatically

24
00:01:52,591 --> 00:02:01,017
redistributed as they are in IPv4. Now, if
you're not really good with redistribution,

25
00:02:01,018 --> 00:02:04,148
let me just explain quickly what we mean by that.

26
00:02:04,149 --> 00:02:07,144
Generally speaking, what's going to happen is,

27
00:02:07,145 --> 00:02:13,056
when you redistribute into a routing protocol
it's going to go to that parent protocol.

28
00:02:13,057 --> 00:02:18,994
So I'll throw out an example. Let's say
you're redistributing RIP into OSPF.

29
00:02:18,995 --> 00:02:23,926
So you go into OSPF, you say
redistribute RIP, you hit Enter.

30
00:02:23,927 --> 00:02:27,582
What the router's essentially going
to do-- now obviously the IOS

31
00:02:27,584 --> 00:02:31,835
does not type show commands internally, of
course. But essentially what it's going to do,

32
00:02:31,836 --> 00:02:34,025
is say show ip route RIP.

33
00:02:34,026 --> 00:02:37,076
And it's going to look at the routing
table and get all the RIP routes.

34
00:02:37,077 --> 00:02:41,036
And it's going to take them, and
based on whatever criteria you put

35
00:02:41,037 --> 00:02:44,645
on the redistribution line,
or just going with defaults,

36
00:02:44,646 --> 00:02:50,531
it's going to take those routes and it's going
to put them into OSPF. Fine, no problem.

37
00:02:50,532 --> 00:02:57,075
But, what about the connected
interface that's running RIP?

38
00:02:57,076 --> 00:03:01,652
When it does a show ip route RIP,
that route is not going to show up,

39
00:03:01,653 --> 00:03:07,545
because it's not in his routing table from
RIP. It's in his routing table as connected,

40
00:03:07,546 --> 00:03:15,792
because it's his interface. In IPv4,
it'll look at that and go, well,

41
00:03:15,793 --> 00:03:24,907
you said redistribute RIP, and this interface
is running RIP. And you know what?

42
00:03:24,908 --> 00:03:28,342
You probably wanted that connected route.

43
00:03:28,343 --> 00:03:35,165
So as long as it's connected to an interface
running the redistributed protocol,

44
00:03:35,166 --> 00:03:40,980
it will grab that subnet and bring
it along and put it into OSPF.

45
00:03:40,981 --> 00:03:46,059
Now, there's a caveat with that even with IPv4.

46
00:03:46,061 --> 00:03:53,833
And that is, if under the OSPF process
you had done your own redistribute

47
00:03:53,833 --> 00:03:59,184
connected and said whatever, then
the IOS would look at that and go,

48
00:03:59,185 --> 00:04:03,777
oh, wait a minute, you're
redistributing connected interfaces.

49
00:04:03,779 --> 00:04:07,052
Well then, I'm not going to do this automatic

50
00:04:07,052 --> 00:04:11,017
bringing in of connected from
the redistributed protocol.

51
00:04:11,018 --> 00:04:15,894
So you would have lost that connected
interface in RIP if you had

52
00:04:15,895 --> 00:04:21,894
done the redistribute connected, and run it
through a route map as per best practice.

53
00:04:21,896 --> 00:04:27,367
Now, if you had literally just said,
redistribute connected, under OSPF I mean,

54
00:04:27,368 --> 00:04:31,391
you would have been fine anyway. You would
have gotten all of the connected interfaces.

55
00:04:31,392 --> 00:04:33,577
But if you've done it per best practice,

56
00:04:33,579 --> 00:04:37,782
and you've run it through a route
map, you better make sure you include

57
00:04:37,783 --> 00:04:43,243
that other interface. So how
does all of that relate to IPv6?

58
00:04:43,244 --> 00:04:50,456
IPv6 looks at everything I just
said and goes, wait a minute.

59
00:04:50,457 --> 00:04:54,249
David, back up a little bit to where you said,

60
00:04:54,250 --> 00:04:59,627
the router looks at the routing
protocol redistribution and says,

61
00:04:59,628 --> 00:05:06,901
well, they probably wanted it. Wait,
probably? We have a name for that.

62
00:05:06,902 --> 00:05:08,963
It's called making an assumption.

63
00:05:08,965 --> 00:05:14,911
The router was assuming that you
wanted that connected RIP route

64
00:05:14,911 --> 00:05:20,524
just because you said redistribute RIP and
it's a connected interface running RIP.

65
00:05:20,526 --> 00:05:23,318
So yes, the router made an assumption.

66
00:05:23,318 --> 00:05:28,504
Truth be told - and this is just
my humble little opinion - that's

67
00:05:28,505 --> 00:05:31,783
true and accurate most of the time.

68
00:05:31,785 --> 00:05:36,225
It's a good thing and it's why
it's sort of always been that way.

69
00:05:36,225 --> 00:05:43,281
Problem is, assumptions aren't
usually good in networking.

70
00:05:43,282 --> 00:05:45,708
We want things to be deterministic.

71
00:05:45,709 --> 00:05:48,466
We want things to be exactly the way
they're supposed to be and completely

72
00:05:48,467 --> 00:05:50,806
and totally technically accurate.

73
00:05:50,807 --> 00:05:55,985
Technically, it should not be
grabbing those connected interfaces.

74
00:05:55,986 --> 00:06:00,408
That does not happen automatically in IPv6.

75
00:06:00,408 --> 00:06:07,369
Now, can we tell it to exhibit the
exact same behavior as IPv4 does?

76
00:06:07,370 --> 00:06:13,579
Yes, we can, and that's one of the caveats we're
going to look at in our config here today.

77
00:06:13,580 --> 00:06:22,632
The other piece to this - RIPng
acts a little bit interesting here.

78
00:06:22,633 --> 00:06:29,763
It sort of acts like metric transparent, if
you're familiar with that from the MPLS world.

79
00:06:29,764 --> 00:06:32,437
I'll show you what I mean when we get there though.

80
00:06:32,438 --> 00:06:36,192
So, on that note, let's hop over
and take a look at what we're

81
00:06:36,193 --> 00:06:40,656
going to redistribute today. And like I said,
we're not going to redistribute everything.

82
00:06:40,657 --> 00:06:45,239
We'll just do some spot redistribution,

83
00:06:45,240 --> 00:06:50,797
if you will, just so you can see some of
the caveats that we're talking about.

84
00:06:50,798 --> 00:06:55,096
So what we're going to start with
here is, we're going to start

85
00:06:55,097 --> 00:07:03,162
with doing a redistribution on router
5 and we'll just go from EIGRP

86
00:07:03,163 --> 00:07:08,898
over into the OSPF world and vice versa.

87
00:07:08,899 --> 00:07:20,254
We'll go both ways here with OSPF and EIGRP
on router 5. Let's hop over to router 5.

88
00:07:20,255 --> 00:07:26,251
Let me get over to the command line
here, on router 5, and we will say--

89
00:07:26,252 --> 00:07:33,847
first thing we're going to say
is do show run section router,

90
00:07:33,848 --> 00:07:37,891
because as we were building our routing protocols,

91
00:07:37,891 --> 00:07:43,069
we sort of did a mix and match of
how we were running EIGRP and OSPF.

92
00:07:43,069 --> 00:07:47,460
I'm just going to look so we're
all on the same page here.

93
00:07:47,461 --> 00:07:59,378
We ran named mode EIGRP on router 5 and
then we did legacy ospf ipv6 config.

94
00:07:59,379 --> 00:08:03,590
In other words, we did not do OSPFv3.

95
00:08:03,591 --> 00:08:09,943
So that said, let's start with
redistribution into OSPF.

96
00:08:09,944 --> 00:08:21,522
So we will say, ipv6 router
ospf 1, redistribute eigrp 100.

97
00:08:21,523 --> 00:08:26,114
And I'm going to start with just hitting
Enter, and let's take a look at what happens.

98
00:08:26,115 --> 00:08:31,835
Let's hop over to, say-- router 2
seems like a good candidate because

99
00:08:31,835 --> 00:08:37,446
that's in area 0, and say, do show ipv6 route ospf,

100
00:08:38,550 --> 00:08:44,070
and we should now have an external route -
at least one. Of course, we have a couple.

101
00:08:44,071 --> 00:08:52,010
So we have 36, which is of course
the subnet up here at the top

102
00:08:52,010 --> 00:08:56,260
between router 3 and 6, so that's to be expected.

103
00:08:56,261 --> 00:09:01,671
We don't have anything for 456.
That's to be expected as well,

104
00:09:01,672 --> 00:09:06,308
because remember, the little
dots there mean link local only.

105
00:09:06,309 --> 00:09:11,723
There's nothing to advertise. That's literally
being treated like a transit network.

106
00:09:11,724 --> 00:09:21,971
We also picked up ipv6 route
for router 6's loopback.

107
00:09:21,971 --> 00:09:28,768
Now router 5's loopback, of course, is already
in OSPF. At least it's supposed to be.

108
00:09:28,769 --> 00:09:32,789
Yeah there it is, okay. Looking
right past it there for a second.

109
00:09:32,790 --> 00:09:37,437
So, router 5's loopback's
already in OSPF natively.

110
00:09:37,437 --> 00:09:43,629
So, we pick up 36 in router 6's loopback. But
this is exactly what I was talking about.

111
00:09:45,038 --> 00:09:53,061
We don't have anything connected. Now, in this
case, it's not probably the best example,

112
00:09:53,062 --> 00:09:56,416
because there's nothing to be connected.

113
00:09:56,417 --> 00:10:01,590
So, to change that, let's go to
router 5 - since we've already sort

114
00:10:01,591 --> 00:10:08,565
of looked at his loopback - and
say, interface loopback 55,

115
00:10:08,566 --> 00:10:21,449
and I'm going to say, ipv6
address 2001:db8:55::55/128,

116
00:10:21,451 --> 00:10:27,723
and then we'll say-- that should
already be in EIGRP at this point.

117
00:10:27,723 --> 00:10:29,666
So, let's go to router 6.

118
00:10:29,667 --> 00:10:39,528
Do show ipv6 unicast-- do show ipv6
route for EIGRP [might work better?].

119
00:10:39,529 --> 00:10:46,675
So he's already learning that 55
network. So, the 55 network is in EIGRP.

120
00:10:46,677 --> 00:10:50,497
But again, if we go to router 2,

121
00:10:55,371 --> 00:10:59,742
not an external route. We
don't have the 55 anywhere.

122
00:10:59,743 --> 00:11:05,949
and this is the behavior I was talking about
a minute ago in our little intro there.

123
00:11:05,950 --> 00:11:13,650
You're not getting the connected network
even though that interface is running EIGRP.

124
00:11:13,651 --> 00:11:21,187
So if I go over to router 5 and I
say, do show ipv6 eigrp interfaces,

125
00:11:21,188 --> 00:11:25,464
it's going to cover that 55
loopback I just created.

126
00:11:25,464 --> 00:11:30,243
It's there, it's running EIGRP,
but it's not coming along.

127
00:11:30,244 --> 00:11:36,548
Now, we already sort of talked about this.
The reason is we need to go back into OSPF,

128
00:11:36,549 --> 00:11:40,230
and this is the caveat that I'm
really trying to show you here.

129
00:11:40,231 --> 00:11:48,105
And when you say, Redistribute eigrp
100, you need to say, include connected.

130
00:11:48,106 --> 00:11:55,057
Or you can always, of course, go into OSPF
and do your own redistribute connected.

131
00:11:55,058 --> 00:11:57,115
Of course you could still do that.

132
00:11:57,116 --> 00:12:02,558
But if you want it to exhibit the same
behavior that IPv4 did by default,

133
00:12:02,558 --> 00:12:05,964
then you have to actually say
include connected. And by the way,

134
00:12:05,965 --> 00:12:09,878
you can also-- if you're
familiar with the word subnets,

135
00:12:09,879 --> 00:12:15,163
you cannot type that - unknown
command, never heard of it.

136
00:12:15,164 --> 00:12:23,730
If you look at the options here
there is no choice to do subnets.

137
00:12:23,731 --> 00:12:31,090
That's understood in IPv6, so a
couple little caveats there.

138
00:12:31,092 --> 00:12:37,806
Number one, when you're redistributing
into OSPF you can set the metric type.

139
00:12:37,806 --> 00:12:40,599
You can always manually set the metric,

140
00:12:40,600 --> 00:12:45,005
run it through a route map, set the
tag, these are all things you can do.

141
00:12:45,006 --> 00:12:52,991
The big caveat being include connected, and
not using the subnets keyword anymore.

142
00:12:52,992 --> 00:12:56,242
So those are some of the caveats going into OSPF.

143
00:12:56,242 --> 00:12:59,621
And then let's look at what
this thing actually creates.

144
00:12:59,622 --> 00:13:07,623
So, do show ipv6 ospf database
external self-originated.

145
00:13:07,624 --> 00:13:16,288
So this is the-- these are, I should say, the
type 5 LSAs that router 5 is generating.

146
00:13:16,289 --> 00:13:20,773
So, just to revisit the OSPF
database here for a second,

147
00:13:20,774 --> 00:13:31,041
these are really, really no different
than for OSPF Version 2. It's external,

148
00:13:31,042 --> 00:13:38,445
It's got an advertising router.
The sequence checksum length,

149
00:13:38,446 --> 00:13:42,084
obviously, it's an IPv6 prefix and
that means we have to give it

150
00:13:42,084 --> 00:13:48,891
the mask and/or prefix length. The
metric type, the actual metric.

151
00:13:48,892 --> 00:13:53,174
The thing that's missing, and I
mentioned this in a lesson when we were

152
00:13:53,175 --> 00:13:57,825
going through OSPF, the thing that's
missing is the forwarding address.

153
00:13:57,826 --> 00:14:04,816
There is no need - it wouldn't even
work - to expose the forwarding address

154
00:14:04,817 --> 00:14:10,467
in IPv6, because the forwarding address
is always a link local address.

155
00:14:13,298 --> 00:14:22,519
Now just like IPv4 and OSPF version 2,
if I went to a router in another area

156
00:14:22,520 --> 00:14:33,589
and said do show ip-- not ip. Do
show ipv6 ospf database external,

157
00:14:34,816 --> 00:14:39,075
the type 5 LSAs are, just like version 2,

158
00:14:39,076 --> 00:14:45,312
passed through the entire network completely
unchanged. So here's your external.

159
00:14:45,313 --> 00:14:48,491
Routing bit is set, which is really
funny because it's from the advertising

160
00:14:48,492 --> 00:14:57,510
router, 10.5.5.5. Yet if I were to say
do show ipv6 ospf database router

161
00:14:57,511 --> 00:15:03,326
for 10.5.5.5, he's going to have nothing.

162
00:15:03,327 --> 00:15:08,615
We can't even filter it that way, but
we could say-- we could just hit Enter.

163
00:15:08,617 --> 00:15:13,956
These are the type 1 LSAs,
and this is for 10.1.1.1,

164
00:15:13,956 --> 00:15:24,536
there's router 2, router 3, Router
4, and of course switch 4 somewhere.

165
00:15:24,537 --> 00:15:31,656
There it is, switch 4, and that's it. I
don't have a type 1 LSA for router 5.

166
00:15:31,657 --> 00:15:36,419
I'm sure - if you're already
familiar with OSPF at all - you know

167
00:15:36,419 --> 00:15:42,046
that this is where the type 4 LSA
comes in to support how we're

168
00:15:42,047 --> 00:15:46,558
going to get to this external router.

169
00:15:46,559 --> 00:15:55,316
We have this router here, 10.5.5.5,
that's advertising himself effectively

170
00:15:55,317 --> 00:15:58,099
as an ASBR, but how do I get to him?

171
00:15:58,099 --> 00:16:06,373
That's where we have to say show me
the database for inter-area router.

172
00:16:06,374 --> 00:16:09,625
Now I'll have a type 4 LSA.

173
00:16:09,626 --> 00:16:15,691
This is basically nothing more than
the ABR, router 4, telling me,

174
00:16:15,692 --> 00:16:23,147
hey, when you need to get to
that ASBR, router 5, come to me.

175
00:16:23,148 --> 00:16:29,728
This is the type 4. It's
almost exactly like a type 3.

176
00:16:29,728 --> 00:16:34,140
The real difference between a type
3 and a type 4 is a type 3 is

177
00:16:34,141 --> 00:16:38,991
advertising a destination prefix as
being available through the ABR,

178
00:16:38,992 --> 00:16:46,161
and a type 4 is advertising an ASBR
as being available through an ABR.

179
00:16:46,162 --> 00:16:53,937
You can also, by the way, see this
with a do show ipv6 ospf borders.

180
00:16:53,938 --> 00:16:58,887
This will show you all of the
routers that we know of that

181
00:16:58,888 --> 00:17:05,246
are ABRs or ASBRs. And the cool thing
is, it'll actually show you here,

182
00:17:05,247 --> 00:17:09,491
that's an ABR, that's an ASBR, and
if it's both, by the way, there'll

183
00:17:09,492 --> 00:17:13,283
just be a slash and it'll say ABR/ASBR.

184
00:17:13,284 --> 00:17:20,323
Then you can also see if you
learned this intra or inter-area.

185
00:17:20,324 --> 00:17:26,813
So the lowercase versus uppercase i
in this first column right here.

186
00:17:26,814 --> 00:17:31,989
So these two characters right here
are telling you, essentially,

187
00:17:31,991 --> 00:17:35,139
did you learn about that router from a type 1,

188
00:17:35,140 --> 00:17:38,615
or did you learn about that router from a type 4.

189
00:17:38,615 --> 00:17:40,753
That's essentially what that means right there.

190
00:17:40,754 --> 00:17:45,022
Did you learn about this from within
your own area or via a type 4

191
00:17:45,023 --> 00:17:47,973
LSA from another area, okay?

192
00:17:47,974 --> 00:17:59,170
So again, type 4s and 5s, not fundamentally
different in OSPF from IP version 4.

193
00:17:59,172 --> 00:18:05,516
That pretty much wraps up OSPF.
Let's hop over to router 5 again.

194
00:18:05,517 --> 00:18:20,612
Let's say router eigrp ipv6. Address family
ipv6 unicast for AS 100, topology base.

195
00:18:20,613 --> 00:18:28,743
Redistribute OSPF 1. And then
like always, if I just hit Enter,

196
00:18:28,744 --> 00:18:35,777
I'm not going to advertise anything. If I go
to router 6 and say, do show ip route eigrp,

197
00:18:35,778 --> 00:18:44,014
Nothing, right? And if I say,
do show ipv6 eigrp topology...

198
00:18:49,060 --> 00:18:56,253
Okay? He's learning them-- actually he's not.
I'm sorry. These are the ones he's creating.

199
00:18:56,254 --> 00:19:01,181
So 36 and 6 he's putting in. So,
he's not learning them, nothing.

200
00:19:01,182 --> 00:19:05,264
That's of course because you
have to put in a seed metric.

201
00:19:05,265 --> 00:19:12,840
So a lot of people go, okay, fine. So, metric,
bandwidth delay reliability load mtu,

202
00:19:12,842 --> 00:19:21,481
they're all ones. There we go. And with IPv4,
and more importantly with 32-bit metrics,

203
00:19:21,481 --> 00:19:26,470
this was okay. But now, going to
be a little bit of a problem.

204
00:19:26,471 --> 00:19:30,385
If I go up to router 6 and I look at the topology,

205
00:19:35,698 --> 00:19:37,506
look at the feasible distance.

206
00:19:39,330 --> 00:19:41,389
Little bit of a problem.

207
00:19:45,608 --> 00:19:50,962
Now, with IPv6, it'll actually take that.

208
00:19:50,963 --> 00:19:57,643
Because IPv6 routing table supports larger
metrics than the IPv4 routing table.

209
00:19:57,644 --> 00:20:06,172
So it'll actually take it with IPv6, but
really, 4.2 billion for your metric?

210
00:20:06,173 --> 00:20:10,890
I don't think that's really what you're after.
I really recommend staying away from it.

211
00:20:10,891 --> 00:20:13,812
If this was IPv4, this wouldn't even work.

212
00:20:13,813 --> 00:20:16,790
It would come up and say that the
metric is-- I think what it says

213
00:20:16,791 --> 00:20:22,773
is metric infinity, whatever, okay? This
technically works with IPv6, but man,

214
00:20:22,774 --> 00:20:26,896
seriously, I recommend not doing
it. Make it something reasonable.

215
00:20:26,897 --> 00:20:31,484
Metric - I don't care - 1500.

216
00:20:31,485 --> 00:20:36,389
You still don't want it to be a good
metric, because with redistribution,

217
00:20:36,390 --> 00:20:42,274
it's pretty much best practice to
keep external routes at a worse

218
00:20:42,275 --> 00:20:44,648
metric than internal routes.

219
00:20:44,648 --> 00:20:50,980
There's tons of other ways - I refer
to that as layering - but there's

220
00:20:50,981 --> 00:20:55,387
several different ways to solve
redistribution, loop problems and such.

221
00:20:55,388 --> 00:20:59,599
But making external routes less
favorable than internal routes,

222
00:20:59,601 --> 00:21:03,521
either through admin distance, through
metric, through a combination of them -

223
00:21:03,522 --> 00:21:09,048
there's a bunch of ways, but one of them
is to keep the metric not so favorable.

224
00:21:09,049 --> 00:21:14,234
But at least 1.5 megs is better than 1K.

225
00:21:14,235 --> 00:21:18,069
It's still going to be a lot more
favorable, and instead of these

226
00:21:18,070 --> 00:21:21,609
ridiculous numbers like this, you're
going to get something at least

227
00:21:21,609 --> 00:21:27,565
a little more reasonable. It's still not
great but it's considerably shorter.

228
00:21:29,077 --> 00:21:34,413
Really, it doesn't matter. The point
is you have to provide a seed metric.

229
00:21:34,414 --> 00:21:41,083
I would just, with named mode, really
avoid the 1.1.1.1. You have to for IPv4.

230
00:21:41,084 --> 00:21:45,677
For ipv6, it just gets
extraordinarily ugly if you don't.

231
00:21:45,678 --> 00:21:51,922
Other than that, there's your
routes. There's your routes.

232
00:21:51,923 --> 00:21:56,846
Something else you could possibly do here
is, on router 5-- I've got all these

233
00:21:56,847 --> 00:22:05,870
loopbacks coming in. Loopback for 1, 2,
3, switch 4 - I got a lot of loopbacks.

234
00:22:05,871 --> 00:22:15,915
I could go to router 5 and I could say,
af-interface g0/0.-- no, not on this guy.

235
00:22:15,915 --> 00:22:19,826
Sorry. Fa0/0.456,

236
00:22:25,747 --> 00:22:38,705
summary-address 2001:db8:100:100::/64.

237
00:22:38,706 --> 00:22:41,466
I could create a summary address,

238
00:22:45,067 --> 00:22:47,359
go back to router 6.

239
00:22:50,030 --> 00:22:54,258
And first off, we get rid of all the loopbacks,

240
00:22:54,259 --> 00:23:00,675
and now we're advertising just the
loopback subnet range in as a /64.

241
00:23:00,676 --> 00:23:04,046
The other thing to note is, just like with IPv4,

242
00:23:04,046 --> 00:23:08,928
and you can do this in IPv4 as well, as
soon as you create a summary address

243
00:23:08,929 --> 00:23:13,304
this now becomes an internal
route. That's because, technically

244
00:23:13,305 --> 00:23:18,592
router 5 is originating the
route, not redistributing it.

245
00:23:18,593 --> 00:23:23,524
He's redistributing the routes
into the EIGRP topology table but

246
00:23:23,525 --> 00:23:27,721
then when he goes to send them out that
interface and you have the summary address,

247
00:23:27,722 --> 00:23:33,542
he goes, oh, so suppress
those and generate this /64.

248
00:23:33,543 --> 00:23:40,379
The key is, and generate the
/64. He's originating it.

249
00:23:40,380 --> 00:23:43,776
Why would it be external if he's originating it?

250
00:23:45,663 --> 00:23:50,506
When it goes through that process it
does make it an internal route again,

251
00:23:50,507 --> 00:23:52,839
which can sometimes throw
people a little bit there.

252
00:23:52,839 --> 00:23:55,919
It can also maybe mess with your
admin distance a little bit too.

253
00:23:55,920 --> 00:23:59,702
So you got to be a little bit careful
if you were bringing a summary

254
00:23:59,704 --> 00:24:05,126
in from say-- you were
summarizing in OSPF and EIGRP,

255
00:24:05,127 --> 00:24:08,569
but you wanted to follow the OSPF path,

256
00:24:08,570 --> 00:24:13,043
you might have to do some admin
distance manipulation here.

257
00:24:13,045 --> 00:24:17,616
Because otherwise, it's going to follow
EIGRP with an admin distance of 90

258
00:24:17,616 --> 00:24:22,693
over OSPF with an admin distance of 110.

259
00:24:22,694 --> 00:24:27,965
So just again some interesting little
things you have to watch out for there.

260
00:24:29,773 --> 00:24:33,505
Other than that, that's
redistribution into EIGRP.

261
00:24:33,506 --> 00:24:35,929
Not really too much to do there.

262
00:24:35,930 --> 00:24:40,091
Let's go down-- and let me switch back
to our diagram here real quick for you.

263
00:24:40,091 --> 00:24:41,546
What we're going to do next--

264
00:24:41,547 --> 00:24:44,050
I don't even have to go both ways
because I'm not even interested

265
00:24:44,052 --> 00:24:47,518
in full connectivity, I'm just
trying to show you some caveats and

266
00:24:47,519 --> 00:24:52,341
things to watch out for. So we saw the
type 4s, we saw the type 5s in OSPF.

267
00:24:52,342 --> 00:24:56,393
In EIGRP, we saw what you have
to mess with, with the metric.

268
00:24:56,393 --> 00:24:59,092
I'm not even going to redistribute into BGP.

269
00:24:59,094 --> 00:25:02,253
We're going to do a lot of
that in the MPLS section

270
00:25:02,254 --> 00:25:06,153
when we're talking about transition
mechanisms and tunneling.

271
00:25:06,154 --> 00:25:10,607
So, we're going to get back to that. I'm not
even going to bother doing it right now.

272
00:25:12,190 --> 00:25:14,635
There's not really too much
to be concerned with anyway.

273
00:25:14,636 --> 00:25:17,216
It's sort of like redistributing
in anything else.

274
00:25:17,217 --> 00:25:21,800
What we will do, just so you can
see a little bit of a caveat here,

275
00:25:21,800 --> 00:25:27,077
Is we'll redistribute on router
4, into the RIP process.

276
00:25:27,078 --> 00:25:31,340
Because we've done redistribution
into OSPF - no big deal.

277
00:25:31,341 --> 00:25:35,299
Redistribution into EIGRP, into OSPF,

278
00:25:35,301 --> 00:25:40,414
and now redistribution into RIP on router 4.

279
00:25:40,415 --> 00:25:45,043
So let's switch back over here to the command line,

280
00:25:45,044 --> 00:25:53,012
go to router 4, and we're going to-- I'm
going to have to look at the config,

281
00:25:53,013 --> 00:26:00,283
because I don't remember. Do show ipv6 protocol.
I think we called it RIPv3, yes we did.

282
00:26:00,284 --> 00:26:10,610
So, ipv6 router rip RIPv3, redistribute ospf 1.

283
00:26:10,611 --> 00:26:17,307
And on this one, I'm leaving the metric off
on purpose, because I want you to see this.

284
00:26:17,308 --> 00:26:22,139
If you go to Switch 1 now, who's
right below router 4 there,

285
00:26:22,140 --> 00:26:29,286
do show IPv6 route-- I could filter
it with RIP. You know what? I will.

286
00:26:29,287 --> 00:26:31,429
I was going to say, he doesn't
really have anything else,

287
00:26:31,430 --> 00:26:35,047
but you do have all those local and
connected, so I'll just filter it on RIP.

288
00:26:35,048 --> 00:26:41,702
Here we go. So, I think the first most interesting
thing, is he actually has some routes.

289
00:26:44,672 --> 00:26:47,339
Like, for example, the ::3.

290
00:26:49,150 --> 00:26:54,551
That is an OSPF route. So is ::2.

291
00:26:54,552 --> 00:26:57,443
Now, 52, that's native RIP.

292
00:26:57,443 --> 00:27:02,791
That's over between switch 2 and router
5 if you're looking at the diagram.

293
00:27:02,792 --> 00:27:09,335
41-- sorry, not 41. What was the other one? Here.

294
00:27:09,336 --> 00:27:19,330
8 is switch 2's loopback so that's native,
but there's another one coming from OSPF.

295
00:27:19,331 --> 00:27:23,538
We already have some networks
here coming from OSPF.

296
00:27:23,539 --> 00:27:30,178
But what's interesting is we don't have
everything. We don't have the EIGRP routes.

297
00:27:30,179 --> 00:27:32,937
We don't have router 1's loopback.

298
00:27:32,937 --> 00:27:37,958
There's a lot of things we don't
have, and the answer is simply here.

299
00:27:37,959 --> 00:27:45,594
If you say do debug ipv6 rip, and
we watch for an update to come in

300
00:27:45,595 --> 00:27:49,643
- and of course RIP being the speed demon
it is, it could take a second here.

301
00:27:51,657 --> 00:27:55,540
That's him sending, sending...

302
00:27:55,541 --> 00:28:01,598
He just sent out all of his updates.
We've got to wait for a receive though.

303
00:28:14,491 --> 00:28:25,219
There we go. We'll turn off the debugging,
give it a second to stabilize here. Okay.

304
00:28:25,220 --> 00:28:30,225
And we can already see
what's happening right here,

305
00:28:30,226 --> 00:28:36,528
coming in on VLAN 41 from router
4. Look at all those prefixes.

306
00:28:36,529 --> 00:28:39,478
Yeah, there's 41, there's 3's loopback,

307
00:28:39,479 --> 00:28:44,625
there's 2's loopback, switch 4's loopback.
And notice what they all have in common,

308
00:28:44,626 --> 00:28:54,178
metric 1, metric 1, metric 1, metric 1.
But, look, I'm getting the DMVPN cloud 123,

309
00:28:54,179 --> 00:28:57,846
I'm getting the host DMVPN route from router 1.

310
00:28:57,846 --> 00:29:04,118
Router 1's loopback, router 6's loopback
coming all the way from EIGRP over there,

311
00:29:04,119 --> 00:29:08,626
there's that 55 network coming in from router 5,

312
00:29:08,627 --> 00:29:14,997
VLAN 36 between router 3 and 6 coming
from EIGRP - I'm receiving everything.

313
00:29:14,998 --> 00:29:19,191
But the metric on all of them is 16.

314
00:29:19,192 --> 00:29:24,464
And the reason is, if you were to
go look at the OSPF environment for

315
00:29:24,465 --> 00:29:31,501
the DMVPN, the costs are like 1000, and
all the routes being redistributed

316
00:29:31,501 --> 00:29:39,836
into OSPF from EIGRP all have a metric of
20 by default. Well, I got news for you.

317
00:29:39,838 --> 00:29:46,630
20 doesn't fit into a RIP hop count
of 15, and 1000 certainly doesn't.

318
00:29:46,630 --> 00:29:49,592
So what do you end up with? Well, here it is.

319
00:29:49,593 --> 00:29:56,916
You end up with routes being
learned but an invalid metric.

320
00:29:56,917 --> 00:30:01,369
Now, th00
 I'm getting the host DMVPN
 route from router 1.

0:28:57.680000 --> 0:28:59.780000
 Router 1's loop back.

0:28:59.780000 --> 0:29:01.500000
 Router 6's loop back.

0:29:01.500000 --> 0:29:04.400000
 Coming all the way from
 EIGRP over there.

0:29:04.400000 --> 0:29:08.700000
 Okay. There's that 55 network
 coming in from router 5.

0:29:08.700000 --> 0:29:12.680000
 VLAN 36 between router 3
 and 6 coming from EIGRP.

0:29:12.680000 --> 0:29:15.300000
 I'm receiving everything.

0:29:15.300000 --> 0:29:19.520000
 But the metric on
 all of them is 16.

0:29:19.520000 --> 0:29:24.600000
 And the reason is if you were to go
 look at the OSPF environment for the

0:29:24.600000 --> 0:29:28.500000
 DMVPN, the costs are like 1,000.

0:29:28.500000 --> 0:29:35.240000
 And all the routes being redistributed
 into OSPF from EIGRP all have a

0:29:35.240000 --> 0:29:37.900000
 metric of 20 by default.

0:29:37.900000 --> 0:29:39.840000
 Well, I got news for you.

0:29:39.840000 --> 0:29:44.480000
 20 doesn't fit into a
 RIP hop count of 15.

0:29:44.480000 --> 0:29:46.620000
 And 1,000 certainly doesn't.

0:29:46.620000 --> 0:29:48.300000
 So what do you end up with?

0:29:48.300000 --> 0:29:49.720000
 Well, here it is.

0:29:49.720000 --> 0:29:57.160000
 You end up with routes being
 learned but unenvalid metric.

0:29:57.160000 --> 0:30:01.560000
 Okay. Now, the interesting thing
 is IPV4 won't even do this.

0:30:01.560000 --> 0:30:05.680000
 RIP on IPV4 basically says if I don't
 have a seed metric, then I'm not

0:30:05.680000 --> 0:30:10.040000
 redistributing but this is what I was
 talking about with the last bullet

0:30:10.040000 --> 0:30:17.260000
 point on the slide there that RIPNG exhibits
 a metric transparent behavior.

0:30:17.260000 --> 0:30:23.060000
 It's trying to take the metric from
 OSPF and put it in the RIP.

0:30:23.060000 --> 0:30:27.240000
 Now, for some routes, that worked.


0:30:27.240000 --> 0:30:29.740000
 Some routes, that was okay.

0:30:29.740000 --> 0:30:32.600000
 Other routes? Not so much.

0:30:32.600000 --> 0:30:38.140000
 So really, the moral of the story is can
 you redistribute without a metric?

0:30:38.140000 --> 0:30:40.180000
 I don't know, sort of.

0:30:40.180000 --> 0:30:43.000000
 If you're careful, sure.

0:30:43.000000 --> 0:30:46.980000
 But again, we'll bring them in
 as a relatively bad metric.

0:30:46.980000 --> 0:30:51.320000
 But as long as you put a metric on and
 then when we receive the updates

0:30:51.320000 --> 0:30:55.880000
 and I have the debugging off right now,
 let's see if they showed up already.

0:30:55.880000 --> 0:31:00.360000
 Yeah, we already got them all.

0:31:00.360000 --> 0:31:02.200000
 So it already updated.

0:31:02.200000 --> 0:31:05.040000
 Notice they all have
 a metric of 10 now.

0:31:05.040000 --> 0:31:13.860000
 All the ones coming in from OSPF,
 which is to be perfectly expected.

0:31:13.860000 --> 0:31:17.500000
 So again, these are just some of the
 caveats you have to watch out for

0:31:17.500000 --> 0:31:20.760000
 with redistribution with IPV6.

0:31:20.760000 --> 0:31:25.660000
 So just to summarize, you don't forget
 the include connected part.

0:31:25.660000 --> 0:31:27.420000
 That can really throw you.

0:31:27.420000 --> 0:31:31.160000
 Rip, the way it handles the seed
 metric is a little weird.

0:31:31.160000 --> 0:31:34.940000
 And if you're doing maimed mode in
 the IGRP, I would recommend staying

0:31:34.940000 --> 0:31:38.720000
 away from the metric of 1111.

0:31:38.720000 --> 0:31:43.820000
 And like I said earlier, as far as the BGP
 goes, it's not really any different.

0:31:43.820000 --> 0:31:50.480000
 It's exactly the same as IPV4, but we
 will be doing some as we move into

0:31:50.480000 --> 0:31:56.660000
 tunneling in the next sections.

0:31:56.660000 --> 0:31:57.900000
 Thank you. Thank you.