(dramatic music)
- In this video I'd like to introduce
the concept of GRE tunnels,
and before I do that,
let me just back up for a moment and talk about
what is a tunnel in the first place?
Here's a real high level of looking at this concept
of a tunnel.
So imagine for a moment an IP packet,
okay so imagine in binary you have a string of bits
which is your data,
maybe your web browsing or whatever,
and then in front of that string of bits you have another
string of bits which is your TCP segment header,
and then in front of that you've go another string of bits
which is your IP header,
and that's where it ends.
So you've got your IP header,
your TCP header,
and then all of your data.
Now, that long string of bits,
can you take that as it is and put it on a wire
and send it out?
Hopefully you said,
"Well no Keith, you can't take a layer three packet
"and place it directly on a wire,
"you can't just bypass the data link layer.
"We need the data link layer."
Why do we need the data link layer?
Well because that wire,
let's just assume it's an Ethernet wire,
that Ethernet wire is expecting ones and zeros
to take the form of Ethernet.
In other words if I send a string of bits to you,
and it arrives on your Ethernet NIC card,
your Ethernet NIC card is assuming the first few ones
and zeros are the preamble,
and then the next few ones and zeros after that
are a destination MAC,
and then there's a source MAC,
so if I just sent you a string of ones and zeros that
started with the IP header
and there was no Ethernet header in front of that,
you wouldn't be able to interpret that,
you wouldn't know what to do with that.
So I need to take that IP packet and wrap it inside of
something that you will understand,
something this cable supports that I can send to you,
because your NIC card does not natively understand IP,
but it does understand another protocol, Ethernet,
which carries IP.
So typically we say that
that's the process of encapsulation,
where I'm taking some protocol,
in this case a layer two protocol Ethernet,
and I'm using it to encapsulate something else,
which in this case is a layer three protocol which is IP.
Another way of saying that is,
tunneling,
in other words I'm taking some protocol that does not
natively go across this wire,
I can't put it on this wire and I'm saying well,
how can I put it across this wire?
What if I take this data,
this structure here,
whatever it is,
and wrapped it in something else
that is supported on this wire and got it through?
Now in the case of Ethernet it's just point to point,
right on Ethernet you and I share an Ethernet wire
so I encapsulated the Ethernet.
Well let's take it one step further.
Let's say that I have a situation like this,
where I have a couple of routers on the end that have
an IPv6 network but in the middle there is no IPv6.
Could I put an IPv6 packet on this wire right here?
No I couldn't because fast Ethernet zero zero on R one
doesn't even have an IPv6 address.
That interface does not understand IPv6,
and even if somehow I could put an IPv6 packet on there,
when it got to this device right here,
he doesn't understand IPv6.
There's no way I could natively put an IPv6 packet
from R one to R two because the devices in the middle
don't support IPv6.
But, what if I could do this?
What if I could take my IPv6 packet,
so maybe on R one I type ping 2001 two two two two,
two two two two,
colon colon two.
So I'm doing an Ipv6 ping.
In order to get that to go across,
what if I took that IPv6 packet and at the front of it,
I put an IPv4 header?
An IPv4 header with
one dot one dot one dot one
as the source,
and how about two dot two dot two dot two
as the destination?
That could go across that wire.
That could go from router one to router two because
all these devices know how to route IPv4.
That is what's called tunneling,
where I create a tunnel and in this case the two end points
of the tunnel would be router one and router two,
and what this tunnel is doing is it's taking information in
that normally could not go across this connection,
and it's somehow wrapping it in some additional header
that my intermediary,
my transit network does understand and can carry it through,
and then once it pops out the other end of the tunnel,
then we can strip off that outer header revealing the
native packet inside and we can process it.
That's what's called tunneling.
Now there's a variety of ways to do tunneling.
A lot of times in a lot of devices,
you will actually create a tunnel interface
just like we've talked about loopback interfaces
which are logical interfaces,
we've talked about sub-interfaces
which are logical interfaces,
I've talked about dialer interfaces,
well now we're gonna do another logical interface
that does not exist until you create it by typing it in,
which is an interface tunnel.
Now when you create an interface tunnel,
then the question is okay,
well how is it going to encapsulate something,
what's it going to do?
And there's a variety of ways to do that.
And the default way that tunnels encapsulate something
is called Generic Route Encapsulation which is GRE.
So let's talk about GRE.
So that's what GRE stands for,
Generic Route Encapsulation,
it is a standard way of doing tunneling,
one of many ways of doing tunneling,
as defined here in RFC 2784.
You actually could probably read that,
it's very short.
The way GRE works is very very simple.
So GRE,
why is it called Generic Route Encapsulation,
because GRE says look,
I don't care what's in the payload,
what's in the payload is irrelevant to me,
and I'm just gonna slap a new header on that
and then send it out onto the wire.
So GRE basically has a concept of an inner payload
that it's carrying that it's wrapping,
and then GRE itself relies on some outer protocol,
that's what we call the delivery protocol.
Like in my example of what I just drew right there,
my inner protocol would be my IPv6 packet,
and my outer or my delivery protocol would be
IP version four,
and GRE would stick its own special little header
right in the middle.
So this is what it would look like.
So for example,
if I was doing GRE in the example I showed you,
then I would have in my IPv6 packet right here,
with my IPv6 header and all that stuff,
and then GRE adds this stuff.
So GRE adds its own header,
which is consisting of a protocol type,
and the protocol type uses the exact same
type values as Ethernet.
So if you think about it okay,
think about an Ethernet frame.
If I send you an Ethernet frame and
that Ethernet frame has IPv4 packet in it,
and then right behind that I send you another Ethernet frame
that has an IPv6 packet,
at layer two,
how's your NIC card gonna tell the difference?
Well because in that Ethernet frame in the header,
there's an EtherType fact value,
it's called the type code.
And there's one type code that says,
I'm an Ethernet frame carrying IP version four.
There's another type code that says,
I'm an Ethernet frame carrying IP version six.
Well those numbers are the exact same numbers
I used right here in the protocol type field.
And then we have a version which is zero
and then the flags which isn't really used for anything,
and then GRE says,
I don't care what the delivery protocol is
but usually the delivery protocol is IP version four.
So in the IP header,
the protocol number well instead of six for TCP
or 17 for UDP,
you would actually see the protocol number 47.
That means that behind this IP header,
is a GRE header.
So when you configure a tunnel interface,
the defaulting encapsulation type
if you don't specify anything else,
will be this,
it will be GRE.
And configuring a tunnel interface is really simple.
You just type interface tunnel and you give it a number.
For example,
when you create a loopback interface,
does a number really matter?
No.
Most people usually start with interface loopback zero
or interface loopback one but hey,
there's nothing stopping you from
creating interface loopback 99.
Same thing here.
Might as well start with interface tunnel zero,
but you can put any number after that that you want.
And yes,
just like you can have multiple loopback interfaces
in a router,
you could have multiple tunnel interfaces
in a router as well.
Now, the question you have to ask yourself is,
what kind of data is gonna be in the payload of this tunnel?
What is this tunnel gonna be carrying?
In my example I said,
Well, I'm gonna want IPv6 packets tunneled
across an IP version four cloud.
So, Ipv6 is gonna be in the payload
of what's being tunneled.
So if it's IPv6,
then I would need an IPv6 address on my tunnel interface.
If I plan on taking IPv4 packets and tunneling them,
then I would need IPv4 address.
Here's a key thing to think about.
Remember this basic rule,
that an interface,
whether it be a logical interface
like a loopback or a tunnel,
or a physical interface like a fast Ethernet or a serial,
an interface in order to carry some sort of protocol,
like IPv4, IPv6,
has to have an address for that protocol on itself.
In other words if I create an interface tunnel
and I don't enable it for IPv6,
I don't put an IPv6 address on there,
there is no way IPv6 packets will ever use
that tunnel interface because it doesn't know what IPv6 is.
Now the second step in creating my tunnel interface.
So I'm gonna have my tunnel interface,
and we know that some sort of data's
going to be going across here,
in my case it was IPv6,
and we know that the tunnel itself in order to transport it,
is gonna slap on there some sort of destination address
and some sort of source address.
Now my particular case is gonna be a source IPv4 address,
and a destination IPv4 address.
So there's gonna be some router here,
we'll just say router A,
some router here which is router B,
and some routers in the middle
which are just carrying this packet.
So the source IP address is gonna have to be
some IP address on router A because he's sourcing a tunnel.
The destination IP address is gonna have to be
some IP address on router B,
because that's where tunnel destination is,
that's where it's ending.
So the commands we actually use for that are tunnel source,
and you can either reference an IP address
on your router itself,
or you can reference an interface,
say okay on my router all these packets are gonna be leaving
fast Ethernet zero zero,
so why don't I just borrow the IP address of
fast Ethernet zero zero as my tunnel source,
so you can do that,
tunnel source, interface, fast Ethernet zero zero.
And then you're gonna use the tunnel destination command,
which gives the IP address of the destination.
So let's do a real example of this,
so this typology I actually already have set up,
I've already pre-configured everything,
and my objective here is I want router one to be able to
IPv6 ping this address right here.
Problem is,
I don't have any IPv6 in the middle,
so I need to create a tunnel between
router one and router two.
So on router one,
I'm gonna create an interface tunnel
and I'll just give it interface tunnel zero,
and now if I want this tunnel to carry IPv6 traffic,
it has to understand IPv6,
so I have a choice.
I could come up with a completely different IPv6 address
and put it on the tunnel,
but one thing nice about IPv6,
I can just enable IPv6,
I could say IPv6 enable,
and that will create a link-local address on my tunnel
and FE80 address.
And then I'm gonna have a tunnel source,
let me expand this a little bit here,
tunnel source,
and I'm just gonna point to fast Ethernet zero zero.
In other words I'm gonna be telling router one
okay, when you take your IPv6 packets
and you apply a GRE header,
and then in front of the GRE header you add a IP header,
I want the source address to be one one one one,
what we see right here.
And then I'm gonna have a tunnel destination of router two.
Tunnel destination is going to be two two two two.
So just those three commands,
actually those four commands,
creating the tunnel in the first place,
enabling the tunnel for IPV6,
saying my source is fast Ethernet zero zero,
my destination is two two two two,
and then there's one other thing I have to do.
If I want to be able to ping this IPv6 network,
R one has to learn about it.
So across the tunnel,
I'm actually gonna be running EIGRP for V6.
I will actually form an EIGRP relationship
between router one and router two across this tunnel.
So I'll enable EIGRPv6 on here,
and then I'm gonna replicate that same thing
but in reverse on router two.
I'll create a tunnel interface on router two,
I will also say IPv6 enable,
I'll say tunnel source will be his fast Ethernet zero one,
so that he uses two two two two as the source IP address,
tunnel destination will be one one one one,
and then I'll enable IPv6 EIGRP on his tunnel interface.
So let me go ahead and build that and
show you how that works.
Okay, so let's start by taking a look at router one.
Let's look at my configuration so far.
So on router one,
I have my loopback address and I'm gonna want EIGRP for IPv6
to advertise that loopback once my tunnel is built.
I have not created any tunnel yet.
And then here's the physical interface that's gonna be
carrying that tunnel traffic,
fast Ethernet zero zero.
So let's go ahead and build the tunnel on this side.
Interface tunnel,
and you can see here I've got a
wide range of numbers I could choose from,
I'm just gonna start with interface tunnel zero.
Now, let's just stop right there.
No other configuration.
Show interface tunnel zero.
So right now it's down because
I haven't given it the necessary information,
I haven't told what the source is yet,
I haven't told what the destination is yet,
but look at this.
Tunnel protocol is GRE.
Transport method is IP.
So this is saying by default,
it's gonna use IP version four
as the source and destination,
I just haven't told it what addresses to use yet,
and then behind the IP version four header,
it's gonna create that additional GRE header as well.
So let's finish out my configuration of that
interface tunnel zero,
so I'll say tunnel source and
according to my picture right here,
I want the tunnel source to be fast Ethernet zero zero,
I want you to borrow that IP address
as your source IP address.
Tunnel destination,
this destination of your packets is gonna be
two dot two dot two dot two,
and now that I've given it a source and destination,
the tunnel came up.
Now it's not fully up yet because
I haven't configured the other side.
Now if I want IPv6 to go across that I have to enable IPv6,
I could give it an IPv6 address,
but I'm just gonna say IPv6 enable,
because if I want EIGRP running across this tunnel remember,
your IPv6 routing protocols like EIGRP and OSPF,
they form neighbor relationships
with their link-local addresses.
I don't even need a global address to form a
neighbor relationship between two routers
running an EIGRP or OSPF for IPv6.
So I'm just gonna enable that and then,
I'm gonna enable IPv6 EIGRP.
So before I complete the tunnel
on the other side on router two,
let's look at what I've done so far.
Okay so I've got my loopback here,
I've already got that included in my EIGRP process,
now I've created my tunnel interface,
I said I'm allowing you to have IPv6 run across this tunnel,
I'm allowing you to have EIGRP run across the tunnel,
so whoever's at the other end of the tunnel,
if they're also participating in EIGRP
autonomous-system 100,
you can talk to them,
and then I have my tunnel source as being the fast Ethernet
and the tunnel destination being R two
over on the other side.
So, let's go ahead and I'm just gonna copy all that,
and I'm gonna go over to R two on the other side.
I'm gonna paste it in and
just make a couple of minor changes.
Okay so number one.
Tunnel destination's not going to be two two two two,
so now my tunnel destination is gonna be pointing back to
one one one one,
and my tunnel source is not gonna be
fast Ethernet zero zero,
my tunnel source is gonna be fast Ethernet zero slash one.
And there we go look at that.
Not only did the tunnel come up,
by my EIGRP neighbor relationship across that tunnel
immediately came up as well.
Show IPv6 EIGRP neighbor,
and we can see that I have formed a neighbor
across my tunnel interface.
How do I know it actually worked?
Show IPv6 route,
and we can see that I learned of the loopback interface of
router one across that tunnel,
the tunnel interface is the next hop,
and now I can ping it.
from router two I can ping the IPv6,
the loopback interface of router one,
and that's because it's going across the tunnel.
If I do a debug IP packet,
and then do that same ping,
let's turn off the debug packet now.
Okay, so here was my IPv6 ping,
and notice it created,
so this is OSPF because actually I have OSPF
running across IPv4,
that's how router one even knew how to
get to two two two two,
and that's how router two even knew how to
get to one one one one,
if I did not have reachability of my tunnel endpoints,
it would be pointless,
so I had to have some sort of routing protocol running
between all four devices so my tunnel endpoints
could actually reach other,
but here we see.
Here is my IPv6 packet is actually inside of that,
and actually I think we could do even more if I do,
let's do this,
debug IP packet detail and then do the ping again,
ugh.
Debug IP packet detail,
come on, where is that ping?
There we go.
So right here.
Come on stop, stop, stop!
Un all,
okay.
So this is what I'm looking for.
Now we can actually see the protocol field,
notice protocol 47.
That is the protocol that's reserved for GRE.
So this is me,
router two sending an IPv version four packet to router one,
but the protocol is 47.
So when router one gets that,
he'll say,
Oh, 47,
I need to redirect that to my tunnel interface
because that's the one that's actually doing GRE.
And then the tunnel interface will strip off this
IP version four header,
revealing the IPv6 inside,
and that's why my IPv6 ping is successful,
which is way up here.
That shows my successful IPv6 ping.
So that concludes this discussion of
configuring GRE tunnels.
(dramatic music)