[music]
So let's jump in with just standard GRE tunnels over IPv6.
For this, we're going to be using a different topology.
This is also saved out there under IPv6 VPN topology.
The basic idea here is, we're going
to use this for VPN MPLS,
really for all of our tunneling or VPN technologies here.
We're going to start with GRE, and we're not going to use all
of these devices for all of the sections.
There's really no need.
But this is the topology that's built
that will support everything
we need it to support moving forward.
The important thing to understand here
is that the switches are just acting like any devices.
We have the IPv4 address listed here,
but it corresponds with what
the IPv6 address is going to be on that subnet as well,
and you'll see those as we go.
VLANs 71, 91, 84, 65, 105, these are all IPv6 enabled already.
Now, our PE routers, which again,
it may or may not be provided,
could of course also just be your edge routers.
That's irrelevant.
We're just looking at the technologies here.
But those are also already configured with IPv6 addresses.
But as we move into technologies such as MPLS and such,
we will be redoing.
So we're going to start with just GRE,
and we'll just build one tunnel
between R1 and R4.
So essentially, we're just going to get our IPv6 from switch 1 to
switch 2 across the top there, and tunnel between R1 and R4.
The most important thing to note
about this diagram is that the core
in the middle there, everything inside the cloud
if you will, is IPv4 only.
It's going to remain that way the whole time.
There's no IPv6 in the cloud.
As we move into this, let's hop over here to our command line.
Let's take a look.
On router 1, for example, if I were to say do show ipv6 route,
all he has is literally a route to Null0.
That's it. He has no IPv6 routes.
If I said do show ipv6 interface brief,
he going to have addresses, like I said,
on his 71 and 91 interfaces going out
to the switches, but not anything
on the core. His core interface
is Fa0/0.12 and that is currently unassigned.
Also, if I said do show ip route,
I want you to note that the only IPv4 routes he has is to either
connected interfaces or the other device's loopbacks.
The loopback numeration is on the diagram there.
It's a little bit different than what we did before.
It's just the device numbers all the way out.
Just to jump in, the first thing we're going to do is we need to
fire up-- need to is a bad word, I suppose.
We could alway do static routes,
but we're going to fire up
a routing protocol over all of this.
We're going to say-- in this case, we'll say, Rack1R1.
We're going to say, interface tunnel 0,
and we will say, tunnel-- well, I
just said about the protocol and
I'm jumping into the tunnel.
Let's do our protocols first,
although we could turn it on here as well
since we're already here.
We'll just do EIGRP, just to pick one to start with.
So ipv6 eigrp 100 - easy enough - interface.
And like I said, this is just going
to be the one up at the top.
So this is going to be interface FA0/0.71,
also running EIGRP 100.
And then ipv6 router eigrp 100.
That starts the global process.
Do show ipv6 eigrp interface, and it's 71.
Perfect.
We can do the exact same thing over on router 4 as well.
So if you'll take a look at the diagram here,
remember we're going from router 1 to router 4,
and then of course it will involve VLAN 71 and VLAN 84.
That's all we're going to work on for right now.
So I just want to make sure everyone
understands where we're at.
On router 4, interface tunnel 0, ipv6 eigrp 100,
interface fa0/0.84.
Also in EIGRP 100 and then router
ipV6 router eigrp 100, and then our switches.
So switch 1, interface loopback 0,
ipv6 eigrp 100.
Loopback 1, by the way, is the one
that has the, we'll call it the
client prefix.
Let me just show you here real quick.
Do show ipv6 interface brief.
If you look at his loopback 1, this is a /64.
This is like the client subnet
that this switch is presenting,
and then this is his normal management loopback,
if you will. I'm going to bring them both in EIGRP.
It doesn't really matter.
I really just want the loopback 1, but we'll bring them all in.
Then of course, router ipv6 eigrp 100.
That's backwards.
Then switch 2.
Here's the good thing we can do.
We can just say-- well, I had typos in there.
It's not even going to help us really.
Switch 2 doesn't really matter.
Interface loopback 0,
ipv6 eigrp 100,
interface loopback 1.
eigrp 100. Interface vlan, and this is 84,
eigrp 100, ipv6 router eigrp 100.
Neighbors should come up.
So 2 and 4 are up,
although I did not see switch 1 and R1 never came up.
Never did the VLAN interface.
Interface vlan 71.
There you go. Neighbors should come up.
So if we've done our job correctly,
we should be able to go to router 1 now
and say do show ipv6 route eigrp,
and he should have router 1's information, which he does.
We should be able to go over to router 4,
do show ipv6 route eigrp, and he
should have switch 2's information,
which he does.
So that's good.
Now we go back to our tunnel.
Interface tunnel 0, and we say ipv6 address.
I don't know 2001 DB8:100:200::, and he's the 4 end of that, /64.
So we put an IPv6 address on the tunnel.
We can do that on both sides.
Then tunnel source is going to be loopback 0.
Tunnel destination is 4.4.4.4.
That's router 4's address.
It's going to say that it's up.
We know that's nonsense.
It's a false up.
If you want, you can say like keep 2,
and send keepalives every 2 seconds,
then within six seconds, it should
tell me the tunnel's down because
there are no keepalives on the other side.
These are GRE keepalives.
There we go.
Tunnel goes down.
That's when it realizes, Oh wait,
the other end's not really up.
The only thing this up meant, just like any other GRE,
is that you have a route to get to the tunnel destination.
It's all it really means.
So router 4, tunnel source loopback0,
tunnel destination 1.1.1.1.
That's like IPV geometry or something.
I don't know what that is.
And then of course, keep 2, and the tunnel should come up.
Router 1's side should come up once the keeps kick in.
I'm not going to leave the keeps on there
because as we move forward to other interfaces,
interface types, it's not going to
work because keepalives are only
supported on GRE tunnels.
In fact, it may not work without
an IPv4 address anyway since both
sides just went down.
We're not going to keep them on there anyway.
Just do no keeps. We're about to change this all to GRE anyway.
There you can tell I'm ready.
It's working because EIGRP just came up over the interface.
Now if I said, do show ipv6 route eigrp,
now we have the routes on both sides.
If we were to go back to say,
switch 1, do show ipv6 route eigrp,
and we were to say do trace, and let's trace to--
let's trace to what would effectively
be the client's subnet over there.
::8. There you can see that
it hits the tunnel on router 1.
Comes out the tunnel on the other end on router 4,
and gets delivered to switch 2.
So very, very simple.
Of course, the glory of
this whole thing is you go to say
router 2, which is a device in the core,
and you say, do show ipv6 interface brief,
and he has nothing.
Unassigned, unassigned, unassigned.
Everything's unassigned.
Do show ipv6 route.
He's not even running IPv6 routing.
So again, this is just standard GRE tunnel.
Now, if we take a look at this
and we go over to-- let's go
back to switch 1.
And let's say, do ping.
Protocol is IPv6.
Target, we'll just ping his loopback just to make it easy.
Repeat count 1.
Datagram size, I don't care.
Time out, 1.
This is all FastEthernet.
It shouldn't take long.
Extended commands, yes.
Source interface, I don't care.
UDP protocol is no.
Verbos is no. I don't care about
changing the precedence or the DSCP value.
I don't necessarily need to see hop by hop.
We did that with the trace.
Destination, no.
Sweep range of sizes, yes.
Minimum sweep size, I'm going to do 1401 bytes.
I'm going to say the max size, I don't care because I'm going to
stop as soon as it starts failing anyway.
The sweep interval is 1.
That's how much it's going jump by.
What this means, by the way, if you've never done this,
this means it's going to start with
a ping of 1401 and then it will
do 1402, 1403, 1404, and so on.
If I said sweep interval 2, it would do 1401,
1403, 1405. It would jump by 2.
That's how much it's going to jump each time.
I'm going to start the ping and as
soon as it hits-- Let's stop that.
There we go. The problem is this isn't really going to do what I
want it to do, unfortunately.
This has to do with that whole packet too big thing.
We could count those packets right there
to figure out what the actual
MTU is, but, do show interface tunnel 0.
Unfortunately, because we
don't have the fragmentation built
in to IPv6 like we talked about back in the introduction part,
unfortunately, sweeping the range
of sizes isn't quite as nice as
it is on IPv4 because you don't have a don't fragment bit.
The devices in the middle can't fragment anyway.
Basically what it means is that at
1478 should be what we managed
to get through here from a payload size,
but that's not entirely correct either.
Again, it's not going to be a really
good indicator here as to what
our actual MTU is.
Why did that not show me that?
All on the switch.
You can see
that the way IPv6 handles the MTU,
is completely different anyway because
it uses the path MTU discovery.
But basically, at the end of the day,
what we're saying here is that right now,
our tunnel and protocol transport
is GRE over IP, which means we're
getting an extra header of GRE right now.
The only thing we're running
over this tunnel is IPv6.
So there's actually no need whatsoever to have a GRE header.
But that's the default.
That's it. It's very simple.
The advantage to this, of course,
is that we could actually run IPv4
over this if we wanted to and so on.
We're going to change that in a minute.
But I just wanted you to know right now
that the tunnel transport
MTU is 1476. So we'll come back and
take a look at this tunnel again
in our next section.
What we'll do in the next section is
we will get rid of the GRE header
and start moving into other tunnel types.
[music]