1
00:00:00,000 --> 00:00:11,115
[music]

2
00:00:11,116 --> 00:00:17,897
Let's jump in and start with the
straightforward - IPv6 over IPv6 since

4
00:00:17,897 --> 00:00:23,160
that is, of course, our
main topic for the course.

6
00:00:23,161 --> 00:00:27,866
Let's just go ahead and jump right
over the command line here.

8
00:00:27,867 --> 00:00:32,296
That's basically what we're going
to be doing, so hopefully you have

11
00:00:32,296 --> 00:00:33,736
the diagram handy.

12
00:00:33,737 --> 00:00:35,394
If not, you'll want to get it handy.

13
00:00:35,394 --> 00:00:38,634
I may switch back and forth to it
for reference as we go as well,

15
00:00:38,635 --> 00:00:42,886
but this would be a good place to have
our diagram probably printed out,

17
00:00:42,887 --> 00:00:48,092
or available on another screen,
or something you can switch to.

19
00:00:48,092 --> 00:00:51,983
Again, we're going to be
starting off here between--

21
00:00:51,984 --> 00:00:57,615
we'll start with Router 3 to Switch 3.

22
00:00:57,616 --> 00:01:00,991
As we go through the upcoming lessons
here with different combinations.

24
00:01:00,991 --> 00:01:04,799
I will rebuild it each time.

25
00:01:04,799 --> 00:01:08,105
We'll be starting with
no BGP in each lesson.

27
00:01:08,106 --> 00:01:11,528
That way we can see each one how to
build it and that way gives us the

29
00:01:11,529 --> 00:01:16,646
opportunity to do a couple of more
combinations of things as well.

31
00:01:16,647 --> 00:01:24,327
On Router 3, we're going to say
router bgp 100 and we're going to say

34
00:01:24,328 --> 00:01:29,473
address-family ipv6 unicast.

35
00:01:29,474 --> 00:01:43,347
Then we're going to say neighbor
2001:DB8:100:39::9 remote as_300.

38
00:01:43,348 --> 00:01:47,957
That's just the easiest way
to jump in and get started.

40
00:01:47,958 --> 00:01:53,871
Couple of things to note, BGP--
and you have to realize it inside of a

42
00:01:53,872 --> 00:01:58,352
company the size of Cisco and such,
there's different teams that code

44
00:01:58,353 --> 00:02:24,327
different parts and
since that's the case.

46
00:02:24,327 --> 00:02:27,754
Then things like this happen.

47
00:02:27,754 --> 00:02:32,451
Which is sort of fun.

48
00:02:32,451 --> 00:02:40,624
If we look at the show run for the section
BGP, something to note is, what we did,

52
00:02:40,625 --> 00:02:45,115
is we went into router BGP 100.

53
00:02:45,115 --> 00:02:51,526
And we went right into address-family
IPv6, and put in the neighbor with the

56
00:02:51,527 --> 00:02:53,956
remote-as statement.

57
00:02:53,957 --> 00:03:00,041
Well, the code looked at that and said,
Oh, I see what you're trying to do

59
00:03:00,042 --> 00:03:03,002
what you meant to do, is you
meant to put the neighbor

61
00:03:03,003 --> 00:03:12,690
statement up here under global BGP mode,
and you meant to turn it off for IPv4,

63
00:03:12,690 --> 00:03:18,843
because you didn't turn it
on in address-family IPv4,

65
00:03:18,843 --> 00:03:22,287
and you meant to activate it in IPv6.

66
00:03:22,288 --> 00:03:28,802
What sort of nice about this code is -
and again most versions of IOS will do

68
00:03:28,803 --> 00:03:31,758
this for you - it just moves the stuff
around to where it needs to be,

70
00:03:31,758 --> 00:03:36,630
so my whole thing with IPv6, go
right into address-family IPv6 and

72
00:03:36,631 --> 00:03:38,483
start putting in your commands.

73
00:03:38,483 --> 00:03:41,252
As you do this, what you're
going to end up with,

75
00:03:41,252 --> 00:03:48,946
is the code moving the stuff
to where it should be.

77
00:03:48,946 --> 00:03:50,921
Moving forward, let's go ahead
and get our neighbor up.

79
00:03:50,921 --> 00:03:57,849
By the way, if you take a
look at do show ipv6 tcp--

82
00:03:57,850 --> 00:04:04,352
sorry, you don't actually have to say
that on this do show tcp brief all.

84
00:04:04,352 --> 00:04:09,744
You can see that he's already
listening on TCP port 179,

86
00:04:09,744 --> 00:04:14,414
and he's listening specifically for
traffic coming from that neighbor's

88
00:04:14,415 --> 00:04:24,626
IPv6 address on any port to any
interface on this router port 179.

90
00:04:24,626 --> 00:04:29,912
So he's already listening
for the session over IPv6.

92
00:04:29,913 --> 00:04:35,540
And the reason of course is because
we put in an IPv6 address as our

94
00:04:35,541 --> 00:04:36,837
neighbor statement.

95
00:04:36,838 --> 00:04:41,167
So let's go over to switch 3, and
we'll do the same basic thing.

97
00:04:41,168 --> 00:04:49,774
So router bgp 300 and address-family
IPv6 unicast and neighbor 2001

99
00:04:49,775 --> 00:05:03,590
DB8:100:39::3 remote-as 100 and that
actually should bring the neighbor

101
00:05:03,590 --> 00:05:07,839
relationship up as long
as everything is correct,

103
00:05:07,840 --> 00:05:11,312
because we do have direct connectivity.

104
00:05:11,313 --> 00:05:16,372
This is of course the directly connected
interfaces, I'm peering on physicals.

107
00:05:16,373 --> 00:05:22,378
So then you say, do
show bgp ipv6 summary.

109
00:05:22,379 --> 00:05:24,152
It'll probably yell at me.

110
00:05:24,153 --> 00:05:25,384
Yeah, it did.

111
00:05:25,385 --> 00:05:28,384
You're not suppose to use--
you're supposed to start putting in

113
00:05:28,385 --> 00:05:30,650
unicast or multicast now
on these commands too.

115
00:05:30,651 --> 00:05:32,888
I notice it's yelling at me.

116
00:05:32,889 --> 00:05:36,612
Use the show bgp ipv6 unicast.

117
00:05:36,613 --> 00:05:38,598
Oh okay, I'm so sorry.

118
00:05:38,598 --> 00:05:41,090
So let's see if we can
prevent getting yelled at.

120
00:05:41,091 --> 00:05:45,166
Do show bgp ipv6 unicast summary.

121
00:05:45,167 --> 00:05:47,052
See now it doesn't yell.

122
00:05:47,052 --> 00:05:51,501
But the point is is our neighbor is up,
it's been up for 36 seconds at this point.

125
00:05:51,502 --> 00:05:56,546
No routes sent or receive, because
I'm not injecting anything into BGP.

128
00:05:56,547 --> 00:06:01,472
If I were just to say,
show bgp ipv6 unicast.

130
00:06:01,472 --> 00:06:05,390
There's nothing in our table and
that's not going to do us much good.

132
00:06:05,391 --> 00:06:10,164
So I'm going to go ahead and inject
switch 3's loopback here, and of course,

135
00:06:10,165 --> 00:06:12,626
I could redistribute connected.

136
00:06:12,627 --> 00:06:14,473
There's a bunch of
ways I could do this.

138
00:06:14,474 --> 00:06:16,678
I'm just going to bring it
in with a network statement.

140
00:06:16,678 --> 00:06:31,637
So network 2001 DB8:100:100::9/128.

141
00:06:31,638 --> 00:06:34,284
I don't know how an i snuck in there.

142
00:06:34,285 --> 00:06:37,057
It's not exactly hex.

143
00:06:37,057 --> 00:06:44,482
Do show bgp ipv6 unicast and there
you go, we're injecting our network.

146
00:06:44,483 --> 00:06:50,045
And as long as we've done our job correctly,
this should show up on Router 3 now.

149
00:06:50,046 --> 00:06:55,632
Do show bgp ipv6 unicast.

150
00:06:55,633 --> 00:06:57,037
There we go.

151
00:06:57,037 --> 00:07:05,317
So just from the basics, just getting started
here, sending IPv6 routes over an IPv6

154
00:07:05,318 --> 00:07:10,134
session in BGP is really
just as simple as that.

156
00:07:10,135 --> 00:07:24,639
In fact, I should really be
able to ping it - no problem.

159
00:07:24,640 --> 00:07:27,916
The other thing to note too, is a lot of
people look at this, and they're like,

162
00:07:27,917 --> 00:07:34,412
oh but the next hop is 39.9 - what
about that whole link local thing.

164
00:07:34,412 --> 00:07:41,329
Well, do show ipv6 route bgp.

165
00:07:41,330 --> 00:07:48,280
Notice the next hop in the BGP table
is the actual physical address of the

167
00:07:48,281 --> 00:07:50,115
next device.

168
00:07:50,116 --> 00:08:03,235
However, when BGP says, do
show ipv6 cef for that address

170
00:08:03,236 --> 00:08:09,610
notice that it's attached to FA0/1.

171
00:08:09,611 --> 00:08:14,479
So when he does his recursive look up he
knows that it's supposed to go to the

173
00:08:14,480 --> 00:08:17,100
link local address of the neighbor.

174
00:08:17,101 --> 00:08:20,975
So it's already done the recursive look
up when it puts the BGP route into

176
00:08:20,976 --> 00:08:22,340
the routing table.

177
00:08:22,340 --> 00:08:26,362
It already knows to route that
interface to the link local address.

179
00:08:26,362 --> 00:08:31,173
Now, in a minute we're going to see
where this is not always the case but

181
00:08:31,174 --> 00:08:33,892
let's take a look at
that as we move forward.

183
00:08:33,893 --> 00:08:37,765
First, just to show you if you are
familiar with BGP you got to really be

185
00:08:37,765 --> 00:08:44,407
careful here with some of your older
commands like, do show IP BGP, nothing.

188
00:08:44,408 --> 00:08:48,323
Do show IP BGP summary, nothing.

189
00:08:48,323 --> 00:08:51,993
Do show IP BGP neighbors, nothing.

190
00:08:51,994 --> 00:08:56,759
Because we're not doing the
IPv4 address-family right now.

192
00:08:56,760 --> 00:09:02,522
We've only turned on address-family IPv6
unicast so the equivalent of these,

194
00:09:02,523 --> 00:09:03,692
I've already shown you two of them.

195
00:09:03,693 --> 00:09:10,634
The other one of course would be do
show bgp ipv6 unicast neighbors.

197
00:09:10,635 --> 00:09:12,877
And then you can see that the neighbors
are up, and we don't need to look at this

200
00:09:12,878 --> 00:09:14,550
whole thing.

201
00:09:14,551 --> 00:09:19,001
What we do need to see though
is this part right here.

203
00:09:19,002 --> 00:09:24,142
So address-family, ipv6 unicast
advertised and received.

205
00:09:24,143 --> 00:09:28,699
And of course, in order for us to agree on
an address family we're exchanging between

208
00:09:28,699 --> 00:09:33,036
BGP neighbors, then you
have to have advertised it.

210
00:09:33,036 --> 00:09:37,810
Meaning saying you're willing to accept
that address-family and you have

212
00:09:37,810 --> 00:09:43,035
to be willing to send it
or send it and receive it.

214
00:09:43,036 --> 00:09:45,301
You have to do both.

215
00:09:45,301 --> 00:09:48,151
So that's just real simple basic.

216
00:09:48,152 --> 00:09:50,821
From here on out, it's just BGP.

218
00:09:50,821 --> 00:09:53,966
All the same things apply
that apply on IPv4.

220
00:09:53,966 --> 00:09:57,285
You can do all the same things,
same route manipulation.

222
00:09:57,286 --> 00:10:00,101
We're going to look at some
of that stuff moving forward,

224
00:10:00,102 --> 00:10:05,164
but in the meantime I'm going to bring
up a BGP session with Router 6 as well.

227
00:10:05,165 --> 00:10:08,152
But Router 6 I want to do
a little bit differently.

229
00:10:08,152 --> 00:10:18,844
On Router 6 I'm going to say
neighbor FE80::6 and then we have to

231
00:10:18,845 --> 00:10:30,534
say % VLAN 69 and it would probably help
if I actually put the remote-as on there.

234
00:10:30,534 --> 00:10:34,601
That's your mode AS
100 and that's fine.

236
00:10:34,602 --> 00:10:40,350
I want you to see this, I did this one on
purpose first meaning doing Switch 3 before

239
00:10:40,350 --> 00:10:41,878
Router 6.

240
00:10:41,879 --> 00:10:48,847
This particular set of equipment that
I'm operating this whole thing on for

242
00:10:48,848 --> 00:10:53,573
these lessons this is running on
physical equipment and for some of the

244
00:10:53,573 --> 00:10:56,972
features that I use for some
other courses and such,

246
00:10:56,973 --> 00:11:03,839
we need some advanced code on these and
it is rather advanced code for this

248
00:11:03,840 --> 00:11:07,939
hardware platform, and it
does have a few minor issues

250
00:11:07,940 --> 00:11:11,093
and you're about to see one of them
- that's why I'm bringing it up.

252
00:11:11,093 --> 00:11:29,682
If I say, router bgp 100 address-family
ipv6 unicast neighbor fe80::9%gigabit

255
00:11:29,683 --> 00:11:45,581
Ethernet 0/0.-- actually that's
gigabit 0/1 remote 300 - there we go.

258
00:11:45,582 --> 00:11:49,594
It actually performs a traceback.

259
00:11:49,595 --> 00:11:58,907
It's actually sort of interesting
- IPv6 is address Rs - no,

261
00:11:58,908 --> 00:12:05,923
no it's not code for link local
address with wrong table ID.

263
00:12:05,924 --> 00:12:10,866
Okay. This is clearly and error.

264
00:12:10,867 --> 00:12:16,475
Like I said, other code and that's why
I wanted to show you Switch 3 first.

267
00:12:16,476 --> 00:12:18,598
Other code does not do this.

268
00:12:18,599 --> 00:12:19,686
It's fine.

269
00:12:19,686 --> 00:12:23,900
This is how you peer using
link local addresses.

271
00:12:23,900 --> 00:12:27,941
For some reason this particular
code on this particular platform,

273
00:12:27,942 --> 00:12:33,207
nothing to lose sleep over is this
not production code in anyway.

275
00:12:33,208 --> 00:12:35,613
You would never be using
this in production.

277
00:12:35,614 --> 00:12:39,523
Cisco refers to it as
experimental code.

279
00:12:39,524 --> 00:12:47,533
It's not like internal or anything you
can technically download it through CCO

281
00:12:47,534 --> 00:12:52,002
it just doesn't show up on the normal
download page for this platform.

283
00:12:52,003 --> 00:12:57,098
I don't want to go so far as to say
beta because it's not it's experimental

285
00:12:57,099 --> 00:12:59,819
but point is this, it
doesn't really matter.

287
00:12:59,820 --> 00:13:03,605
It's really a whole lot of explanation
just to say, the neighbor's up.

290
00:13:03,606 --> 00:13:05,080
So, it can yell.

291
00:13:05,081 --> 00:13:05,854
It can scream.

292
00:13:05,855 --> 00:13:07,632
It can do its little traceback.

293
00:13:07,633 --> 00:13:10,973
I like to just say it's throwing
a temper tantrum over here.

295
00:13:10,973 --> 00:13:13,334
The fact of the matter is, it's up.

296
00:13:13,335 --> 00:13:20,350
And if I said do show BGP IPv6
unicast, he's got the route.

298
00:13:20,351 --> 00:13:21,422
So it's working.

299
00:13:21,423 --> 00:13:24,059
Everything's fine, okay.

300
00:13:24,060 --> 00:13:26,336
Notice though, he is listing
the next hop directly as

302
00:13:26,337 --> 00:13:29,461
the link local address there now.

303
00:13:29,461 --> 00:13:34,696
Which, you know, sort of
saves a little bit I guess.

305
00:13:34,697 --> 00:13:39,251
When you get to the routing table, and
it's just already set to the link local.

308
00:13:39,252 --> 00:13:42,633
Now, he does of course still have to
look up the interface and all that,

310
00:13:42,634 --> 00:13:44,709
for the recursive lookup.

311
00:13:44,710 --> 00:13:52,887
But that's basically IPv6 over
IPv6, using link local addresses.

313
00:13:52,888 --> 00:14:00,167
So the way you do it, is you put in, again,
the remote neighbor's address and then

316
00:14:00,168 --> 00:14:07,636
the % then remember case sensitive
and the egress interface

318
00:14:07,637 --> 00:14:13,454
written out in it's entirety, you
can't say GI0/1 we've been through

320
00:14:13,455 --> 00:14:15,238
this in a previous lesson.

321
00:14:15,239 --> 00:14:16,938
But that's how you do it.

322
00:14:16,939 --> 00:14:21,480
Now again this particular code yells
at you it's nothing to worry about.

324
00:14:21,480 --> 00:14:25,482
Normal production level code like
this does not and it's fine,

326
00:14:25,482 --> 00:14:27,524
it just comes right up.

327
00:14:27,525 --> 00:14:32,931
One other quick thing to note there
are some versions of code out there

329
00:14:32,932 --> 00:14:37,261
usually the older stuff that
the way you did was you said,

331
00:14:37,262 --> 00:14:42,421
neighbor FE80::6 remote AS 100.

332
00:14:42,421 --> 00:14:53,226
Then you would say neighbor FE80::6
update source in this case VLAN 69 or

334
00:14:53,227 --> 00:14:59,180
update source gigabit 0/1 and I think
this code actually still supports that.

336
00:14:59,181 --> 00:15:02,052
I haven't actually tried it
on this particular code.

338
00:15:02,053 --> 00:15:12,360
It wouldn't take much to do it here.

339
00:15:12,361 --> 00:15:46,855
It should go down neighbor fe80::6 remote
100, no, this is the switch, up vlan 69.

343
00:15:46,856 --> 00:15:50,763
That's how you did it on
some older versions of code.

345
00:15:50,764 --> 00:15:54,576
I'm not even sure if this version of
code will even do it that way anymore.

347
00:15:54,576 --> 00:16:01,700
That's sort of like a legacy config,
so can't give up quite yet though

349
00:16:01,701 --> 00:16:04,819
because the other side may
not have given up yet.

351
00:16:04,820 --> 00:16:09,910
Peer closed the session, now
he did realize it was down.

353
00:16:09,911 --> 00:16:12,100
So I don't think it's going to come up.

354
00:16:12,101 --> 00:16:26,993
Do show BGP IPv6 unicast summary.

355
00:16:26,994 --> 00:16:34,436
Yeah, current state is active for that
neighbor which basically means he

357
00:16:34,437 --> 00:16:39,584
thinks he's trying but
he's not really doing it.

359
00:16:39,584 --> 00:16:51,267
Do show TCP brief all.

360
00:16:51,267 --> 00:16:56,028
He says he's listening to it.

361
00:16:56,028 --> 00:17:00,972
It's just not going
to work, that's fine.

363
00:17:00,972 --> 00:17:22,899
We'll just say no to that.

364
00:17:22,900 --> 00:17:32,984
This is it, like I said, this
is the new way to do it anyway.

366
00:17:32,985 --> 00:17:35,844
Just to let you know again, if you
did have legacy code - if you

368
00:17:35,869 --> 00:17:39,554
had some older code on some devices -
you may have to do it with the update

370
00:17:39,555 --> 00:17:45,358
source method in order
to get this to work.

372
00:17:45,358 --> 00:17:48,760
While we're waiting for that
to come back up - and again,

374
00:17:48,761 --> 00:17:52,624
we may have to wait for some stuff to
time out since it was already trying.

376
00:17:52,625 --> 00:18:05,200
Let's take a look here real quick -
so it's listening right, it's idle I

378
00:18:05,200 --> 00:18:11,120
got to give him a second
to go active on it.

380
00:18:11,121 --> 00:18:16,510
Here we go, that should come up.

382
00:18:16,511 --> 00:18:19,481
Anyway while we're waiting for that
I'm going to run a little bit of iBGP

384
00:18:19,482 --> 00:18:26,138
over here so let's go over to
Router 3 and I want to say--

386
00:18:26,139 --> 00:18:30,661
now for this guy we really sort of
have no choice but to run over link

388
00:18:30,661 --> 00:18:34,728
local because that's all
I have on VLAN 344.

390
00:18:34,729 --> 00:18:37,006
I'm going to run this down to Router 4.

391
00:18:37,007 --> 00:18:48,527
So I'm going to say neighbor
FE80::4% FastEthernet0/0.

393
00:18:48,527 --> 00:18:55,813
344 remote AS 100 and
traceback thank you.

395
00:18:55,814 --> 00:18:57,836
At least it's predictable, right?

396
00:18:57,837 --> 00:19:14,637
Router 4, router bgp 100 address
family ipv6 unicast 4 as 100 -

398
00:19:14,638 --> 00:19:17,750
I don't know why I typed that, that's
like a EIGRP command that I was

400
00:19:17,751 --> 00:19:44,139
trying to type there - neighbor
fe80::3 % and traceback and up, see?

402
00:19:44,140 --> 00:19:45,179
Oh my goodness I'm going to crash.

403
00:19:45,179 --> 00:19:48,015
Oh wait, no I'm up
- it's just funny.

405
00:19:48,016 --> 00:19:56,701
Do show bgp ipv6 unicast.

406
00:19:56,702 --> 00:20:03,467
I just want to point out that the next hop
is going to be kept to global address.

409
00:20:03,467 --> 00:20:08,456
One of the things that gets a little
entertaining - and we could do this too

411
00:20:08,456 --> 00:20:14,693
- let's see with link local only--
to show the other example,

413
00:20:14,693 --> 00:20:17,147
let's bring up between 5 and 6.

414
00:20:17,147 --> 00:20:27,884
This is just sending the route straight
through - no big deal, nothing to really to--

417
00:20:27,884 --> 00:20:30,541
now we have a little bit
of a problem of course,

419
00:20:30,542 --> 00:20:34,433
because that address is not reachable.

420
00:20:34,434 --> 00:20:39,760
If I were to say, do show bgp ipv6 unicast--
and the reason we know by the way is

423
00:20:39,761 --> 00:20:54,684
that it's not set as best, so if we were
to take a look at that particular network,

426
00:20:54,684 --> 00:20:57,426
the next hop is inaccessible.

427
00:20:57,427 --> 00:21:02,519
This is because we're not running any
routing protocols anywhere, advertising

429
00:21:02,520 --> 00:21:08,929
this in anywhere so the typical fix
to this would be to go to Router 3.

431
00:21:08,930 --> 00:21:12,415
I'm just trying to show you
how this is like regular BGP.

433
00:21:12,415 --> 00:21:21,625
It's really not any different and I'm
just going to say next-hop-self.

435
00:21:21,626 --> 00:21:34,489
Tell him to change the next hop to his own
address, he's going to yell at me again.

438
00:21:34,490 --> 00:21:42,634
Should clear it if not we'll
reset the connection.

440
00:21:42,635 --> 00:22:06,237
A little more concerned that switch 3
and Router 6 haven't come back up.

442
00:22:06,237 --> 00:22:09,608
That would be why.

443
00:22:09,609 --> 00:22:15,705
It never took out the other one
- it's still in there wrong.

445
00:22:15,706 --> 00:22:39,523
That's entertaining.

446
00:22:39,524 --> 00:22:43,386
Let's kill it completely.

447
00:22:43,386 --> 00:22:48,459
That should get completely rid of it.

448
00:22:48,460 --> 00:22:50,110
Okay, better.

449
00:22:50,111 --> 00:23:11,980
Let's try this again -
neighbor fe80::6%vlan69.

451
00:23:11,981 --> 00:23:17,292
Let's see if 3 has updated 4 yet.

452
00:23:17,293 --> 00:23:20,768
There we go, look at that -
just fixing everything at once.

455
00:23:20,769 --> 00:23:23,148
Now we have a good next hop.

456
00:23:23,148 --> 00:23:27,995
I can't really ping that one,
because the way it is right now,

458
00:23:27,996 --> 00:23:33,409
switch 3 has no idea how to get back
to Router 4, so pings, and traces,

461
00:23:33,410 --> 00:23:36,668
and stuff at this point
would not really be useful.

463
00:23:36,669 --> 00:23:41,319
But the fact of the matter is, we
have the route, it's chosen as best,

466
00:23:41,320 --> 00:23:46,320
the next hop has been changed to the next
link local address using the next hop self.

469
00:23:46,321 --> 00:23:50,227
Something else I want to show you
though - sort of the opposite of what

471
00:23:50,228 --> 00:23:58,508
we just did on Router 3 and 4, where
3 was peered on physicals and

473
00:23:58,509 --> 00:24:04,514
therefore when he was trying to send
the update he was leaving the next hop

475
00:24:04,515 --> 00:24:11,577
alone like BGP normally does with iBGP
remember this is a eBGP learned route

477
00:24:11,578 --> 00:24:16,884
being sent to an iBGP neighbor and he
left the next hop alone which is the

479
00:24:16,885 --> 00:24:18,380
default behavior.

480
00:24:18,381 --> 00:24:19,718
That's all great.

481
00:24:19,719 --> 00:24:23,708
Where things get a little interesting
is if I go to Router 6 and say do

483
00:24:23,709 --> 00:24:29,102
show BGP IPv6 unicast.

484
00:24:29,103 --> 00:24:34,992
His next hop is already a link local
address so then what's going to happen

486
00:24:34,993 --> 00:24:49,090
when if I say neighbor
FE08::5%gigabitethernet0/0.

488
00:24:49,091 --> 00:24:55,615
456 remote AS 100 I'm going
to send this to Router 5 now.

490
00:24:55,616 --> 00:25:02,285
By the way as we're typing all these in
just be glad it's not like 10 gigabit

492
00:25:02,286 --> 00:25:07,106
Ethernet and stuff like that -
its name's a little long here.

494
00:25:07,107 --> 00:25:11,008
Router bgp 100.

495
00:25:11,009 --> 00:25:14,328
And just to show you, by the way, I
said I wasn't really going to go

498
00:25:14,329 --> 00:25:19,192
there in the previous lesson when I was sort
of introducing this, but I will anyway.

501
00:25:19,193 --> 00:25:36,818
You can also say, no bgp ipv4-- oops, oh
I think I set-- I didn't even say it,

505
00:25:36,818 --> 00:25:40,683
it's default, sorry.

506
00:25:40,684 --> 00:25:45,816
No bgp default ipv4 unicast,
and what that does is say,

508
00:25:45,817 --> 00:25:52,142
don't even bother negotiating IPv4 address-family
with this guy, with anybody really,

511
00:25:52,143 --> 00:25:53,961
because I'm not running it.

512
00:25:53,961 --> 00:25:59,552
I just want to show you, that if I
then say, address-family ipv6 unicast,

515
00:25:59,553 --> 00:26:11,227
like we did with the other guys and
said neighbor FE80::6 fastethernet0/0.

517
00:26:11,228 --> 00:26:25,763
456 remote AS 100 traceback up
go ahead, come on you can do it.

520
00:26:25,764 --> 00:26:27,463
Here we go.

521
00:26:27,464 --> 00:26:33,013
Do show BGP IPv6 unicast.

522
00:26:33,013 --> 00:26:47,365
Oh hey take your time there.

523
00:26:47,365 --> 00:26:51,275
Meanwhile do show run section BGP.

524
00:26:51,276 --> 00:26:58,871
I just want to show you that it doesn't
put the no activate line under

526
00:26:58,872 --> 00:27:09,410
address-family IPv4 anymore because that's
not the default address-family anymore.

529
00:27:09,411 --> 00:27:12,289
Oops. Notice I'm not getting
anything here let's take a look.

531
00:27:12,290 --> 00:27:21,286
Do debug IP, do debug BGP
IPv6 unicast update.

533
00:27:21,286 --> 00:27:23,351
Let's see what we're getting.

534
00:27:23,352 --> 00:27:30,654
Do clear BGP IPv6 unicast * in.

535
00:27:30,654 --> 00:27:40,641
Do a soft reset in, oh
look what's happening.

537
00:27:40,641 --> 00:27:47,430
So we receive it, receive
an update about that

539
00:27:47,431 --> 00:27:56,984
information denied due to martian
multi protocol next hop reachability.

541
00:27:56,984 --> 00:28:06,193
Yeah he doesn't like the next hop. Why?

542
00:28:06,193 --> 00:28:10,382
Because it doesn't know what
to set the next hop to.

544
00:28:10,382 --> 00:28:19,996
Remember, normal iBGP behavior would be
to send the next hop through unchanged.

547
00:28:19,997 --> 00:28:24,357
The problem is - think this through
for a minute - what next hop does

549
00:28:24,358 --> 00:28:28,362
Router 6 have on the actual route?

550
00:28:28,363 --> 00:28:31,330
Fe80::9.

551
00:28:31,331 --> 00:28:37,691
What good would it do to send a link
local next hop downstream to another

553
00:28:37,692 --> 00:28:42,263
router who doesn't have
anything set on it at all--

555
00:28:42,264 --> 00:28:45,442
he has no idea how to get to fe80::9.

556
00:28:45,443 --> 00:28:49,329
In fact, he would think that that
was locally connected to him,

558
00:28:49,330 --> 00:28:53,414
which, if you look at our
diagram, it's certainly not.

560
00:28:53,414 --> 00:28:56,233
Instead he goes, well I don't
know what to set it to,

562
00:28:56,234 --> 00:28:59,582
so I guess I'll just set it to nothing.

563
00:28:59,582 --> 00:29:08,534
Router 5 gets that and goes nothing, okay.
That's a martian.

565
00:29:08,534 --> 00:29:17,273
Martian is what we use to call I guess
foreign, unknown, unwanted addresses.

568
00:29:17,274 --> 00:29:22,165
I'm sure you guys on your networks
probably have a list of networks on

570
00:29:22,166 --> 00:29:29,639
your outside BGP sessions or whatever if
you're running it that you don't allow in.

573
00:29:29,640 --> 00:29:33,857
Lately the more common term
you hear for that is bogan.

575
00:29:33,858 --> 00:29:38,034
Bogan, martian same thing basically
stuff we don't want or don't know how

577
00:29:38,035 --> 00:29:39,793
to deal with or whatever.

578
00:29:39,793 --> 00:29:45,678
So this is basically his way of saying
I have no idea what this next hop of

580
00:29:45,679 --> 00:29:48,099
:: is supposed to mean.

581
00:29:48,100 --> 00:29:51,517
I can't follow, theoretically
I guess that would be a

583
00:29:51,517 --> 00:29:56,042
default to IPv6 and he's
going I can't do that.

585
00:29:56,043 --> 00:30:00,715
So no. No good, denied.

586
00:30:00,716 --> 00:30:04,760
Doesn't show up in the BGP
table - nothing at all.

588
00:30:04,761 --> 00:30:08,383
I'm just trying to show you that
the fix for this, by the way,

591
00:30:08,383 --> 00:30:10,207
is going to be the same.

592
00:30:10,208 --> 00:30:17,441
That neighbor-- and you just say, next-hop-self
- let him set it to his own address.

596
00:30:17,442 --> 00:30:20,721
Let him resend it.

597
00:30:20,722 --> 00:30:24,269
Router 5 should get it - let's
just give it a second here.

599
00:30:24,294 --> 00:30:27,194
You always know you're in good shape
when you see the debug go by and he

601
00:30:27,194 --> 00:30:31,369
actually installs--
he actually calls to the install route

603
00:30:31,370 --> 00:30:38,507
process when he receives the update.

604
00:30:38,508 --> 00:30:40,668
I'm not patient, this has
about 10 more seconds before

606
00:30:40,668 --> 00:30:46,468
I clear it - especially since the command's
right up there in my history anyway.

609
00:30:46,468 --> 00:30:49,883
We're going to force
it, here we go.

611
00:30:49,884 --> 00:30:54,603
Like I said, always a good process when
it calls the revise route process,

614
00:30:54,604 --> 00:30:59,039
and says installing the route
into the routing table.

616
00:30:59,039 --> 00:31:08,527
Now he likes it because the next
hop he received is FE80::6.

618
00:31:08,528 --> 00:31:18,368
So from a BGP perspective there's not
really that much to running IPv6 over IPv6.

621
00:31:18,368 --> 00:31:22,949
It gets a little trickier if you want
to use link local only address and the

623
00:31:22,950 --> 00:31:27,525
main reason I spent a little bit of
time on this is that may end up being a

625
00:31:27,526 --> 00:31:29,785
rather common thing to do.

626
00:31:29,786 --> 00:31:38,832
We mentioned back in the introduction
lesson that link locals remove the need

628
00:31:38,833 --> 00:31:44,054
to have globally routable
addresses on our LAN links.

630
00:31:44,055 --> 00:31:48,520
That being the case it might very well
be possible you're going to be peering

632
00:31:48,520 --> 00:31:50,294
BGP over that.

633
00:31:50,295 --> 00:31:55,201
So being able to peer BGP on link
local is I think significantly

635
00:31:55,202 --> 00:31:59,992
important and that's again the big
thing and you're going to see a trend

637
00:31:59,993 --> 00:32:02,327
here as we go through the
next couple lessons.

639
00:32:02,328 --> 00:32:07,627
The big trick with BGP and IPv6,
is watching that next hop.

641
00:32:07,627 --> 00:32:10,460
That next hop becomes critical.

642
00:32:10,460 --> 00:32:17,621
When it's IPv6 over IPv6, the issue
comes in to the link local addressing.

645
00:32:17,622 --> 00:32:19,582
That's where the problem comes in.

646
00:32:19,582 --> 00:32:24,985
Now remember, when we were over on Router
4 getting the routes down from Router 3,

649
00:32:24,986 --> 00:32:27,124
on VLAN 344.

650
00:32:27,124 --> 00:32:31,507
Technically, there was nothing
wrong with this route.

652
00:32:31,507 --> 00:32:34,046
That could have been fine.

653
00:32:34,047 --> 00:32:38,828
So I'm just pointing out that if
you're using global addresses,

655
00:32:38,829 --> 00:32:42,140
for your nthe problem comes in.


0:32:19.500000 --> 0:32:23.380000
 Now remember when we were over on router
 four getting the routes down

0:32:23.380000 --> 0:32:29.920000
 from router three on VLAN 344 technically
 there was nothing wrong with

0:32:29.920000 --> 0:32:33.700000
 this route. That could
 have been fine.

0:32:33.700000 --> 0:32:39.240000
 So I'm just pointing out that if you're
 using global addresses for your

0:32:39.240000 --> 0:32:44.080000
 next hops and for your peering that
 you don't really have a problem.

0:32:44.080000 --> 0:32:48.440000
 Remember the problem with this one wasn't
 that the route was being formatted

0:32:48.440000 --> 0:32:52.220000
 wrong, whether the route was
 being denied or thrown away.

0:32:52.220000 --> 0:32:57.160000
 No, no, no. The only problem was we don't
 have a route to get to the next

0:32:57.160000 --> 0:33:02.420000
 hop. Well I could have given it
 a route to get to the next hop.

0:33:02.420000 --> 0:33:05.960000
 Just to show you that this would have
 worked normally and we'll wrap up

0:33:05.960000 --> 0:33:11.620000
 with this here. If I went back to router
 five, if I go back to router

0:33:11.620000 --> 0:33:17.000000
 three and I take off
 the next hop self.

0:33:17.000000 --> 0:33:22.440000
 Go back to router
 four and clear it.

0:33:22.440000 --> 0:33:41.660000
 Okay. It goes back to unusable
 but with a global address.

0:33:41.660000 --> 0:33:49.720000
 Technically I could just go to router
 three and say redistribute connected.

0:33:49.720000 --> 0:33:54.800000
 Normally I would want to do a route
 map and filter it and all that.

0:33:54.800000 --> 0:33:56.320000
 I don't even have to do that.

0:33:56.320000 --> 0:33:58.200000
 I'll just say redistribute
 connected.

0:33:58.200000 --> 0:34:01.940000
 I'm going to end up with a whole
 bunch of stuff that I don't want.

0:34:01.940000 --> 0:34:10.400000
 And I just did that under BGP
 and I did not want to do that.

0:34:10.400000 --> 0:34:14.060000
 Sorry. Can use BGP to
 get to a BGP next hop.

0:34:14.060000 --> 0:34:15.520000
 That's a logic problem.

0:34:15.520000 --> 0:34:21.220000
 I needed to say and on router three
 I forget how I'm running it.

0:34:21.220000 --> 0:34:23.960000
 Do you sure run section BGP?

0:34:23.960000 --> 0:34:35.440000
 It's actually LSPF
 I'm looking for.

0:34:35.440000 --> 0:34:38.660000
 And so on this one we ran IPv6.

0:34:38.660000 --> 0:34:57.320000
 So we have to say IPv6 router.

0:34:57.320000 --> 0:34:59.720000
 Redistribute connected.

0:34:59.720000 --> 0:35:08.440000
 There we go. Router four should
 now get that route through OSPF.

0:35:08.440000 --> 0:35:17.740000
 And it should become reachable.

0:35:17.740000 --> 0:35:31.960000
 There we go. Soon as we get the next
 hop information from OSPF, then BGP

0:35:31.960000 --> 0:35:36.920000
 can use it. So again I just wanted
 to point out it's not like I don't

0:35:36.920000 --> 0:35:39.600000
 want anybody to come out thinking oh
 you always have to do next hop self

0:35:39.600000 --> 0:35:42.080000
 with IPv6 or something like that.

0:35:42.080000 --> 0:35:45.640000
 No, it's just that our external network
 was not being brought into the

0:35:45.640000 --> 0:35:47.120000
 routing process.

0:35:47.120000 --> 0:35:50.680000
 So you have typical next hop reachability
 problems just like you would

0:35:50.680000 --> 0:35:58.040000
 in IPv4. So at the end of the day, again
 running IPv6 over an IPv6 session

0:35:58.040000 --> 0:36:06.340000
 with BGP is really no different than
 running IPv4 over IPv4 with BGP.