1
00:00:03,270 --> 00:00:06,807
[music]

2
00:00:09,176 --> 00:00:17,918
Next is IPB4 over IPB6 session
so pretty much the opposite of

3
00:00:17,918 --> 00:00:21,822
what we did in that last section
there. Let's switch over

4
00:00:21,822 --> 00:00:31,131
to the command line and we're
going to start with

5
00:00:31,131 --> 00:00:38,705
Router BGP100 on Router 3.
In this case, we're not going

6
00:00:38,705 --> 00:00:41,208
to turn off the IPB4
address family because we

7
00:00:41,208 --> 00:00:45,412
actually want to use it. In
fact, we'll actually say and

8
00:00:45,412 --> 00:00:58,392
you can do it right here. We can
say neighbor 2001DB8:100:39::9

9
00:00:58,392 --> 00:01:04,865
remote AS300 and if I say
do show run section BGP

10
00:01:04,865 --> 00:01:08,969
what we should have is that
neighbor is going

11
00:01:08,969 --> 00:01:13,140
to automatically be activated
for the IPB4 address family so

12
00:01:13,140 --> 00:01:16,710
that's already to go as the
default. Let's go to Switch

13
00:01:16,710 --> 00:01:43,003
3, Router BGP300 neighbor
2001DB8:100:39::3 these

14
00:01:43,003 --> 00:02:25,645
should come up and by the way
you could really-- let's see,

15
00:02:25,645 --> 00:02:44,898
have some going on here.
It's active. 2001 DBA:100:39::3.

16
00:02:44,898 --> 00:03:16,563
Let's go back over and look at
Router 3. 3 is not showing

17
00:03:16,563 --> 00:03:25,772
anything at all. So let's see
router bgp 100 neighbor.

18
00:03:25,772 --> 00:03:38,051
It's not taking that at all.
He's not even showing it.

19
00:03:38,051 --> 00:03:48,161
Nothing. Well, address family
IPv4 unicast-- shouldn't have to

20
00:03:48,161 --> 00:03:51,665
do this. It's supposed to be the
default, but it could just be

21
00:03:51,665 --> 00:03:55,368
because-- and again
you have different things

22
00:03:55,368 --> 00:03:57,804
happen on different
codes, so sometimes it's just

23
00:03:57,804 --> 00:04:03,110
not even worth arguing about it
so neighbor activate.

24
00:04:03,110 --> 00:04:07,814
As you can see the switch is
doing it for us, but this

25
00:04:07,814 --> 00:04:10,317
one, the router here doesn't
seem to be actually doing it

26
00:04:10,317 --> 00:04:14,054
by default. There we go.
Now it's up. That's how it

27
00:04:14,054 --> 00:04:17,557
should have been. So it didn't
activate the IPv4 address

28
00:04:17,557 --> 00:04:20,627
family by default just because
it's on IPv6 neighbor.

29
00:04:20,627 --> 00:04:24,164
And I usually just do it under
the address family anyway.

30
00:04:24,164 --> 00:04:28,168
It's the best way to do it. I
was just trying to shortcut

31
00:04:28,168 --> 00:04:29,770
there a little bit and you see
what happens when you

32
00:04:29,770 --> 00:04:35,609
do that, right? So switch didn't
need it but this guy does.

33
00:04:35,609 --> 00:04:38,078
Let's go ahead and bring in a
network statement. So

34
00:04:38,078 --> 00:04:45,218
network, it almost advertises
loopback 10.9.9.9 mask,

35
00:04:45,218 --> 00:04:52,025
it's a /32, do show ip bgp.
There we go. He's injecting his

36
00:04:52,025 --> 00:04:57,764
IPv4 network. And by the way, I
think I mentioned this before,

37
00:04:57,764 --> 00:05:01,701
maybe not, the show ip BGP
you're technically not supposed

38
00:05:01,701 --> 00:05:09,209
to use anymore. Do show bgp
ipv4 unicast because that's so

39
00:05:09,209 --> 00:05:14,414
much easier. But it's more
uniform with where we're headed

40
00:05:14,414 --> 00:05:18,318
with the commands now that we're
supporting address families.

41
00:05:18,318 --> 00:05:26,459
Now, the real fun. Let's go
over to Router 3 and say

42
00:05:26,459 --> 00:05:36,169
do show bgp ipv4 unicast,
and check out the next hop.

43
00:05:36,169 --> 00:05:42,709
For some reason, the router
doesn't think this is reachable,

44
00:05:42,709 --> 00:05:48,815
which I think is a little odd
myself, but for some reason he

45
00:05:48,815 --> 00:05:53,553
says he can't get there.
I'll save the jokes, I guess,

46
00:05:53,553 --> 00:05:56,656
here. If you go back and
look at our diagram,

47
00:05:56,656 --> 00:06:00,660
there's not that address
anywhere. That address

48
00:06:00,660 --> 00:06:06,233
does not exist. Do show ip
route. You're going to look

49
00:06:06,233 --> 00:06:08,768
at the entire routing
table. There is no

50
00:06:08,768 --> 00:06:14,474
32 anywhere in our entire
topology. Our entire topology

51
00:06:14,474 --> 00:06:20,413
is 10s for loopbacks, 50s
for some of the VLANs up at

52
00:06:20,413 --> 00:06:22,716
the top and some of the VLANs
down at the bottom like

53
00:06:22,716 --> 00:06:28,488
where RIP is running and
173 in most places. So

54
00:06:28,488 --> 00:06:33,893
there's a whole bunch of OSPF
routes for IPv4. The 204.186s,

55
00:06:33,893 --> 00:06:36,563
these are for underneath
the DMVPN cloud, so you

56
00:06:36,563 --> 00:06:38,632
don't even have to worry
about those. But they're

57
00:06:38,632 --> 00:06:43,503
not 32s either, okay? The
fact of the matter is this next

58
00:06:43,503 --> 00:06:47,907
hop is completely and
totally useless. Now, I'm

59
00:06:47,907 --> 00:06:53,113
going to explain where
it comes from, and in

60
00:06:53,113 --> 00:06:56,216
Cisco's defense here,
they had to put something,

61
00:06:56,216 --> 00:07:00,253
and here's where the issue comes
in. I'm going to send

62
00:07:00,253 --> 00:07:05,191
you an IPB4 network over and
I'll show you right,

63
00:07:05,191 --> 00:07:13,933
the do show TCP [?] this is
literally only an IPB6 session.

64
00:07:13,933 --> 00:07:19,239
What's he supposed to set the
next hop to? In the

65
00:07:19,239 --> 00:07:23,276
router's defense it's not like
he has a whole lot of choices.

66
00:07:23,276 --> 00:07:28,048
He pretty much has to guess.
He has to make something up.

67
00:07:28,048 --> 00:07:32,319
Now, how they chose to make it
up, I can't say I completely

68
00:07:32,319 --> 00:07:37,223
agree with, but, none the less,
they had to just make

69
00:07:37,223 --> 00:07:47,467
something up. Of course, what
they did, the 32, well,

70
00:07:47,467 --> 00:07:53,773
that's 20 out of the beginning
out of the IPB6 address of the

71
00:07:53,773 --> 00:08:06,820
neighbor. 1 is 01 13 well, what
would be 0D, but of course we

72
00:08:06,820 --> 00:08:18,331
drop the leading 0 so it's just
the D and then 184 is B8.

73
00:08:18,331 --> 00:08:25,071
It took the first 32 bits out of
the network portion of the IPB6

74
00:08:25,071 --> 00:08:33,313
address of the peer and put that
in as the next hop.

75
00:08:33,313 --> 00:08:37,984
Like I said and that's supposed
to be useful how?

76
00:08:37,984 --> 00:08:42,389
I don't know. It's not helpful,
but again, they have

77
00:08:42,389 --> 00:08:48,728
to put something in, so there
it is. Now, they could've

78
00:08:48,728 --> 00:08:50,230
of, a lot of people look
at this and say, well, they

79
00:08:50,230 --> 00:08:53,032
could've taken the end
of it. I'm not saying I

80
00:08:53,032 --> 00:08:56,336
completely disagree, but
the problem with taking

81
00:08:56,336 --> 00:09:00,206
the end of it, is I mean, just
take a look at our example here,

82
00:09:00,206 --> 00:09:07,781
there is a 64 bit network
portion 2001DB8:100:39::9.

83
00:09:07,781 --> 00:09:13,987
That means that the entire last
64 bits are all zeros with a

84
00:09:13,987 --> 00:09:19,993
nine at the end. What would
our next hop have been?

85
00:09:19,993 --> 00:09:25,365
0.0.0.9 well, that's not a valid
IP address. That's not

86
00:09:25,365 --> 00:09:28,234
a valid next hop anyway. In
fact, you wouldn't be able to

87
00:09:28,234 --> 00:09:31,337
advertise it. It's an invalid
next hop. It's not even an

88
00:09:31,337 --> 00:09:38,645
IP address. By taking the
beginning, even though it's

89
00:09:38,645 --> 00:09:42,582
pretty much not very
useful, at least they know

90
00:09:42,582 --> 00:09:45,585
there's going to be bits there.
At least they know there's going

91
00:09:45,585 --> 00:09:50,457
to be some addressing to
take. Even if it becomes

92
00:09:50,457 --> 00:09:58,064
32.1.0.0 because we did
2001::9 which technically

93
00:09:58,064 --> 00:10:02,869
you could do, wouldn't be a real
thing, but they just wanted

94
00:10:02,869 --> 00:10:06,573
to make sure that there were
actually going to be bits there.

95
00:10:06,573 --> 00:10:08,975
That it wasn't going to be all
zeros. Because it could

96
00:10:08,975 --> 00:10:12,879
have easily been 0.0.0.9 here
and that wouldn't have been

97
00:10:12,879 --> 00:10:17,617
any more helpful for one thing
and certainly not helpful

98
00:10:17,617 --> 00:10:28,361
in this case. To fix this, to
actually send IPB4 over IPB6

99
00:10:28,361 --> 00:10:31,965
we're pretty much not going to
have any choice but to

100
00:10:31,965 --> 00:10:35,902
do something we did in
a previous lesson. Go back

101
00:10:35,902 --> 00:10:57,357
to switch 3, route map
RM2R3 for B4 set IP next hop

102
00:10:57,357 --> 00:11:06,199
250.1 .39.9 and this should yell
at us. There we go. Warning:

103
00:11:06,199 --> 00:11:09,269
Next hop address is our
address, and I look

104
00:11:09,269 --> 00:11:13,606
at that and I say oh good,
thank you. Now I know I didn't

105
00:11:13,606 --> 00:11:21,814
make a typo. Here is the
thing. Why is it yelling at you?

106
00:11:21,814 --> 00:11:27,353
You have to remember that route
maps were designed,

107
00:11:27,353 --> 00:11:31,424
not what we are using them for
right now. They were designed

108
00:11:31,424 --> 00:11:34,761
for policy-based routing.
Where you would basically say

109
00:11:34,761 --> 00:11:37,497
match on this type of traffic
and set the next hop to this

110
00:11:37,497 --> 00:11:40,633
guy. Match on this type of
traffic, set the next hop to

111
00:11:40,633 --> 00:11:47,307
that guy over there. You would
never, in policy-based routing,

112
00:11:47,307 --> 00:11:50,877
set the next hop to your own
address. I mean that would

113
00:11:50,877 --> 00:11:54,047
be like the world's smallest
routing loop. They would

114
00:11:54,047 --> 00:11:55,748
never even leave the
router. You might as

115
00:11:55,748 --> 00:11:59,752
well set it to 127.0.0.1 at that
point because it's

116
00:11:59,752 --> 00:12:05,992
not going anywhere so that's why
it's yelling at us. Is that

117
00:12:05,992 --> 00:12:08,962
if we tried to use this route
map for policy based routing,

118
00:12:08,962 --> 00:12:11,497
we could be creating a real
problem for ourselves here.

119
00:12:11,497 --> 00:12:15,635
It's nice, It's trying to tell
us, "Hey, do you know

120
00:12:15,635 --> 00:12:17,870
what you're doing here?" I'm
going to look at that and

121
00:12:17,870 --> 00:12:21,441
go, "Oh, that's so nice of you,
I know what I'm doing, be

122
00:12:21,441 --> 00:12:24,444
quiet." I know that I'm
going to use this to

123
00:12:24,444 --> 00:12:28,615
manipulate a BGP route, I'm
not going to be using this

124
00:12:28,615 --> 00:12:35,054
for policy based routing so it's
okay. So Router BGP300 on

125
00:12:35,054 --> 00:12:39,559
this guy, okay and then,
by the way, this is just

126
00:12:39,559 --> 00:12:42,195
a stupid little trick I'll do.
I'll just show it to you real

127
00:12:42,195 --> 00:12:45,098
quick. You're working on
a lot of devices, complex

128
00:12:45,098 --> 00:12:50,103
topology and stuff, you forget
what VGB is running on this

129
00:12:50,103 --> 00:12:53,573
router. Now obviously,
there's tons of other show

130
00:12:53,573 --> 00:12:56,743
commands to find out,
but a lot of times, I'll

131
00:12:56,743 --> 00:13:03,149
just say Router VGB, oh what
was it again but 1 boom.

132
00:13:03,149 --> 00:13:08,254
You can only run one instance of
BGP on the router. Just say

133
00:13:08,254 --> 00:13:12,392
1 and it'll tell you, no, no,
I'm already running as AS300

134
00:13:12,392 --> 00:13:18,898
and I go, "Oh, that's right,
thanks, got it." Address family

135
00:13:18,898 --> 00:13:40,053
IPB4 unicast for neighbor
2001DV8:100:39::9 no, 3 route

136
00:13:40,053 --> 00:14:09,716
map RM2R3 for V4 out.
Hop over to Router 3, much

137
00:14:09,716 --> 00:14:17,757
better. Now, it's 50.1.39.9 and
I'm following it through BGP

138
00:14:17,757 --> 00:14:26,065
10999 do show IP route for 10999
and it's going to be a

139
00:14:26,065 --> 00:14:35,408
BGP learned route, no problem.
This one, fairly easy to see,

140
00:14:35,408 --> 00:14:39,112
but I want to show you another
aspect of this that can be a

141
00:14:39,112 --> 00:14:44,183
little trickier to see. Again,
I'm sure by this point,

142
00:14:44,183 --> 00:14:49,722
you're getting a trend that when
you're doing IPB6 and BGP.

143
00:14:49,722 --> 00:14:53,159
Really, when you're doing IPB4
and BGP you always have

144
00:14:53,159 --> 00:14:55,928
to be concerned with next
hop issues, right.

145
00:14:55,928 --> 00:14:59,732
It's just that it seems to be a
little bit more of an issue

146
00:14:59,732 --> 00:15:04,637
in IPv6 when you factor in the
whole link-local problem. And

147
00:15:04,637 --> 00:15:08,608
then when you start sending
IPv6 over IPv4 or IPv4 over

148
00:15:08,608 --> 00:15:12,979
IPv6, it just complicates
it even further. The advantage

149
00:15:12,979 --> 00:15:14,881
of course to all of this--
because a lot of people

150
00:15:14,881 --> 00:15:18,584
look at this and go, right, why
am I even doing this again?

151
00:15:18,584 --> 00:15:22,922
The idea is that we only have to
have one BGP process,

152
00:15:22,922 --> 00:15:27,260
one BGP session between these
two routers. Could I

153
00:15:27,260 --> 00:15:32,565
run completely and totally
dual stack? Sure. I'll show

154
00:15:32,565 --> 00:15:38,070
you that in a second. On
switch 3, I'm going to

155
00:15:38,070 --> 00:15:41,174
bring up router 6 again. But
once again, I'm going to do

156
00:15:41,174 --> 00:15:46,345
link local on this side.
So I'm going to say neighbour

157
00:15:46,345 --> 00:16:01,694
FE80::6%VLAN69 remote
100. I don't know why but

158
00:16:01,694 --> 00:16:04,263
when I'm using link-local
addressing and I have to do

159
00:16:04,263 --> 00:16:07,900
that whole percent interface,
you probably notice that I quite

160
00:16:07,900 --> 00:16:11,003
often forget to type
remote ASA after it.

161
00:16:11,003 --> 00:16:12,972
I don't know why. I think my
brain is just sitting there

162
00:16:12,972 --> 00:16:15,308
thinking, You've already
typed all that. Surely, that's

163
00:16:15,308 --> 00:16:19,212
the end of the command. I don't
know. I do it all the time.

164
00:16:19,212 --> 00:16:21,013
Only when I do that part,
though. Usually I remember

165
00:16:21,013 --> 00:16:45,204
but for some reason when
I do that, nope. So we

166
00:16:45,204 --> 00:17:06,158
fire up BGP 100, address-family
ipv4 unicast neighbor.

167
00:17:06,158 --> 00:17:29,448
See he's 9. And I just want to
show you on this one as soon as

168
00:17:29,448 --> 00:17:39,325
the neighbor comes up.
[?] AS. That's because I set him

169
00:17:39,325 --> 00:17:57,643
about 100. There we go. Invalid
next top received,

170
00:17:57,643 --> 00:18:09,789
martian next top. Isn't that
nice. Do show debug.

171
00:18:09,789 --> 00:18:13,859
Counsel message, not a debug.
Depends on the code.

172
00:18:13,859 --> 00:18:17,930
You may have to actually debug
that, debug the update to see

173
00:18:17,930 --> 00:18:29,075
it, but notice what this is
doing. 254.128.0.0, remember

174
00:18:29,075 --> 00:18:34,080
what we said it does an6:07.420000
 have to do that whole percent interface,
 you've probably noticed that

0:16:07.420000 --> 0:16:10.260000
 I quite often forget the
 type remote AS after it.

0:16:10.260000 --> 0:16:11.360000
 I don't know why.

0:16:11.360000 --> 0:16:13.820000
 I think my brain is just sitting there
 thinking, you've already typed

0:16:13.820000 --> 0:16:16.440000
 all that. Surely that's
 the end of the command.

0:16:16.440000 --> 0:16:18.980000
 I don't know. I do
 it all the time.

0:16:18.980000 --> 0:16:22.560000
 Only when I do that part though, usually
 I remember, but for some reason

0:16:22.560000 --> 0:16:43.280000
 when I do that, nope.

0:16:43.280000 --> 0:17:03.040000
 Okay. So we fire up BGP 100 address
 family IPV for unicast neighbor.

0:17:03.040000 --> 0:17:34.260000
 See, he's nine. And I just want
 to show you on this one.

0:17:34.260000 --> 0:17:54.660000
 Soon as the neighbor comes up.

0:17:54.660000 --> 0:17:58.880000
 In valid next top received
 Martian next top.

0:17:58.880000 --> 0:18:01.720000
 Isn't that nice?

0:18:01.720000 --> 0:18:13.520000
 Do show debug. Okay, console message,
 not a debug depends on the code.

0:18:13.520000 --> 0:18:18.560000
 You may have to actually debug that
 debug the updates to see it.

0:18:18.560000 --> 0:18:20.840000
 But notice what this is doing.

0:18:20.840000 --> 0:18:31.060000
 254.128.0.0. Well, remember
 what we said it does.

0:18:31.060000 --> 0:18:33.520000
 And you'll see the problem.

0:18:33.520000 --> 0:18:40.460000
 This is to further complicate the
 problem that we had a minute ago.

0:18:40.460000 --> 0:18:42.240000
 Okay, quick reminder.

0:18:42.240000 --> 0:18:46.320000
 If we go back over to router 3, the
 problem we were having is we were

0:18:46.320000 --> 0:18:48.060000
 getting that ridiculous.

0:18:48.060000 --> 0:18:51.740000
 There was it way back here.

0:18:51.740000 --> 0:18:55.880000
 That ridiculous 32.1.13.184.

0:18:55.880000 --> 0:18:58.780000
 But look, at least
 he was taking it.

0:18:58.780000 --> 0:19:03.260000
 At least he was taking it and
 going, well, that's great.

0:19:03.260000 --> 0:19:04.720000
 I don't know where it is.

0:19:04.720000 --> 0:19:07.100000
 I don't have next
 top reach ability.

0:19:07.100000 --> 0:19:09.060000
 So I can't set it as best.

0:19:09.060000 --> 0:19:14.040000
 But at least it showed up
 on router 6 right now.

0:19:14.040000 --> 0:19:17.680000
 I'm getting this thing and it's just
 flat out telling me it's an invalid

0:19:17.680000 --> 0:19:21.940000
 next top. Okay, again,
 one more time.

0:19:21.940000 --> 0:19:23.180000
 It is a Martian.

0:19:23.180000 --> 0:19:28.140000
 Why? 254. In an IPv4 address.

0:19:28.140000 --> 0:19:30.700000
 Really? That's a neat trick.

0:19:30.700000 --> 0:19:33.340000
 I'd have to look up what
 class that even is.

0:19:33.340000 --> 0:19:39.240000
 E, F, G. I don't know what class
 we're up to when we get to 254.

0:19:39.240000 --> 0:19:41.200000
 Because we don't use them.

0:19:41.200000 --> 0:19:43.080000
 Okay, but it's not usable.

0:19:43.080000 --> 0:19:44.520000
 That's the problem.

0:19:44.520000 --> 0:19:47.740000
 And again, this is because it's
 pulling it from the link local.

0:19:47.740000 --> 0:19:51.840000
 F, E becomes 254.

0:19:51.840000 --> 0:19:59.200000
 And this isn't even a matter of saying
 do show IPvGP and going, oh, oh,

0:19:59.200000 --> 0:20:01.640000
 yeah, that next top's
 not reachable.

0:20:01.640000 --> 0:20:02.680000
 It's not reachable.

0:20:02.680000 --> 0:20:04.300000
 It's not even valid.

0:20:04.300000 --> 0:20:07.320000
 Okay, so you see the problem here.


0:20:07.320000 --> 0:20:08.660000
 I'm not going to go
 through fixing it.

0:20:08.660000 --> 0:20:12.380000
 You would fix it with the route
 map just like we already did.

0:20:12.380000 --> 0:20:16.340000
 I'm just trying to show you that if
 you're using link locals, this can

0:20:16.340000 --> 0:20:22.600000
 even be more of a problem
 or more difficult to find.

0:20:22.600000 --> 0:20:27.380000
 However, you want to say that because
 it's beyond just not reachable.

0:20:27.380000 --> 0:20:32.200000
 It's not even valid when you take those
 first 32 bits and you convert

0:20:32.200000 --> 0:20:35.180000
 them. So that can really
 be a problem.

0:20:35.180000 --> 0:20:38.100000
 Okay? But just to show you real quickly
 here, the other way you can do

0:20:38.100000 --> 0:20:42.420000
 this is I'm just actually, I'm just
 going to say no route or BGP 100 on

0:20:42.420000 --> 0:20:47.800000
 this guy. And up on switch three, I'm
 going to say, let's see where we're

0:20:47.800000 --> 0:20:53.940000
 at. Do show run, begin BGP since the
 switch, this version of code on the

0:20:53.940000 --> 0:20:59.240000
 switch does not have section yet.

0:20:59.240000 --> 0:21:06.220000
 Okay. So I want to say
 no to this neighbor.

0:21:06.220000 --> 0:21:15.740000
 Okay. And instead I'm going to just
 do this neighbor 50 dot 1 dot 69 dot

0:21:15.740000 --> 0:21:22.440000
 six remote as 100.

0:21:22.440000 --> 0:21:25.340000
 And actually he's not even putting
 in a network right now.

0:21:25.340000 --> 0:21:26.920000
 We're just looking
 at neighborhoods.

0:21:26.920000 --> 0:21:36.520000
 Let's put in a network
 network 10999.

0:21:36.520000 --> 0:21:46.720000
 And then address family IPV
 six, unicast neighbor.

0:21:46.720000 --> 0:22:02.840000
 F8, the air colon colon six
 percent VLAN 69 remote 100.

0:22:02.840000 --> 0:22:06.620000
 I said percent I typed dollar.

0:22:06.620000 --> 0:22:19.820000
 They're close. Network 2001 DBA colon
 100 colon 100 colon nine slash 128.

0:22:19.820000 --> 0:22:24.160000
 Do show IPV GP. So he should
 be injecting his loop back.

0:22:24.160000 --> 0:22:49.560000
 Do show BGP IPV six unicast and he should
 be injecting his IPV six loop

0:22:49.560000 --> 0:22:58.480000
 back. Isn't remote as 300.

0:22:58.480000 --> 0:23:12.240000
 Add just family IPV six, unicast neighbor
 F8, zero colon colon nine.

0:23:12.240000 --> 0:23:20.300000
 Big bit ethernet 01 remote as 300.


0:23:20.300000 --> 0:23:25.700000
 Trace back and neighbor comes up.

0:23:25.700000 --> 0:23:28.060000
 IPV four neighbors already up.

0:23:28.060000 --> 0:23:29.080000
 You can see there.

0:23:29.080000 --> 0:23:33.680000
 So if I said do show IPV GP he
 should have the IPV four route.

0:23:33.680000 --> 0:23:40.600000
 Do show BGP IPV six unicast he
 should have the IPV six route.

0:23:40.600000 --> 0:23:46.820000
 Perfect. But do show TCP.

0:23:46.820000 --> 0:23:53.620000
 Brief all. I just want to show you that
 that means we have two sessions

0:23:53.620000 --> 0:24:00.320000
 established. So again back to the why
 did we go through all these last

0:24:00.320000 --> 0:24:01.520000
 couple sections.

0:24:01.520000 --> 0:24:08.640000
 Yes, you can absolutely keep your IPV four
 and your IPV six sections completely

0:24:08.640000 --> 0:24:14.760000
 separate. And I could say do show run
 section BGP and we have just two

0:24:14.760000 --> 0:24:23.940000
 completely separate configs and I'm
 running IPV four over IPV four.

0:24:23.940000 --> 0:24:27.940000
 And for a lot of people they're going
 to look at that and go yeah, yeah

0:24:27.940000 --> 0:24:28.480000
 that makes sense.

0:24:28.480000 --> 0:24:29.660000
 That's how we're going to do it.

0:24:29.660000 --> 0:24:33.120000
 And this is of course the support dual
 stack and we're going to get the

0:24:33.120000 --> 0:24:36.920000
 transition mechanisms coming
 up in a few lessons.

0:24:36.920000 --> 0:24:39.160000
 But that's exactly
 what that's for.

0:24:39.160000 --> 0:24:41.020000
 There's nothing wrong with this.

0:24:41.020000 --> 0:24:43.180000
 You just have extra TCP sessions.

0:24:43.180000 --> 0:24:49.340000
 So doing it the way I just showed you
 you can do one session either IPV

0:24:49.340000 --> 0:24:55.380000
 four or IPV six and exchange either
 type or any type really of address

0:24:55.380000 --> 0:24:57.700000
 family or route across it.

0:24:57.700000 --> 0:25:00.200000
 So that's really the advantage.

0:25:00.200000 --> 0:25:04.000000
 And the one of course that we're going
 to need for a while, particularly

0:25:04.000000 --> 0:25:09.820000
 when we get to MPLS is going to be the
 IPV six routes across the IPV four

0:25:09.820000 --> 0:25:15.340000
 session. So that's going to become
 a little bit of an issue.

0:25:15.340000 --> 0:25:18.480000
 We're going to deal with
 it when we get to MPLS.

0:25:18.480000 --> 0:25:24.140000
 But that's how you get the routes through
 BGP regardless of the underlying