And that next discussion is going to be all about VPNs, virtual private networks.
So for the exam under VPNs, we have to know about GRE and we have to know about site-to-site IPsec VPN tunnels.
And then we have to know about GRE over IPsec. Very, very important.
We already covered one type of VPN and that is VRFs. So VRFs is the type of VPN as well, folks.
What else is another type of VPN?
VLANs. All right. VLANs are a type of VPN as well, if you didn't know that.
We're creating basically virtual tunnels through that layer two environment.
And so VPNs are all over the place.
But we typically, most of us say VPNs, we think of IPsec VPNs.
But there's a lot more than just that.
So let's begin here by talking about GRE tunneling.
We'll do a configuration verification.
You better know how to do this for the certification exam.
All right. So first of all, what is a VPN?
A VPN is any type of tunnel that virtually connects to non-direct connected points directly to each other.
So when you think about this environment here, when I'm trying to connect it to this environment,
we have the ability to connect over the Internet.
The problem is, is that the Internet has many, many, many, many, many, many different routers between us.
Many different networks between us.
So when you think about routers, routers, routers, routers, routers, routers, routers, routers.
So we, we, we, these two devices are not directly connected to each other.
But with the VPN, I can logically, virtually direct them, directly connect them to each other.
So the same thing here with a mobile worker or a small office, home office.
I can virtually, directly connect these devices back to, let's say, headquarters.
But and that doesn't necessarily mean security.
Keep that in mind, though.
Keep that in mind.
VPN doesn't necessarily mean security.
Because when we talk about layer two examples, for example, like VLANs, VLANs, that's a type of VPN.
But there's no like encryption and integrity checking and stuff like that with VLANs.
Frame relay was a type of VPN back in the day.
ATM was.
VPLS, virtual private LAN services, virtual private wire services.
Those are all layer two examples of VPNs, regardless of whether there's safety and security on them or not.
In layer three, we have GREs, no built in security with GRE.
Let's be clear about that.
And then MPLS layer three VPNs, just because it's a VPN, right?
That doesn't mean it's safe and secure.
A MPLS layer three VPN might not be as safe and secure as you need it to be.
And therefore, you are still going to have to implement encryption for your traffic going across that VPN.
IPsec VPNs.
Yeah, those ones, if implemented properly, again, provide encryption.
But you can set up IPsec VPNs without encryption.
You can use authentication header instead of ESP, and then you get a VPN without encryption.
So a VPN is only as safe and secure as you make it to be based on the parameters that you're specifying with it.
So GRE specifically is what our discussion is about right now.
GRE gives us the ability to create a point to point link over an IP network.
So here's our IP network right now, the Internet.
I have HQ, I have branch, and I am not directly connected between HQ and branch because the Internet's in between.
There could be 50 routers, 40 routers, 30 routers, 10 routers, many, many different interconnections between.
This is Internet to Internet.
So my Internet connection, this is the Internet connection over here.
We're going out to the Internet.
Routers, routers, routers, routers, routers.
We're not directly connected.
This interface is in a totally different subnet than this interface over here.
So I could use a GRE tunnel to directly connect virtually these two routers together.
So therefore, that GRE tunnel on each side is in the exact same subnet slash VLAN slash broadcast domain as an example.
And with GRE, we utilize protocol number 47.
So you have TCP's protocol number 6, UDP's protocol number 17, ICMP's protocol 1, IGMP's protocol number 2, ESP's protocol number 50.
All right, GRE's protocol number 47, OSPF's protocol number 89, EIGP's protocol number 88, GRE's protocol number 47.
So with an access control list, if you specify protocol number 47, GRE, does that mean you could block GRE traffic?
Sure you could. Originally designed by Cisco.
So this was a Cisco idea, a Cisco invention.
Very awesome idea.
Very awesome invention, by the way.
And it is an open standard, RFC 2784, meaning you can pretty much use GRE tunnels on any equipment by any manufacturer as long as they support RFC 2784.
What you need to realize, though, is that when we are dealing with GRE, there is no protection, no security, no encryption, nothing by default.
That means anybody can eavesdrop on your traffic.
Anybody can.
So implementing a GRE tunnel by itself over an untrusted network is a very, very bad idea.
And I'll show you later how you can protect GRE traffic over an untrusted network.
It's called GRE over IPsec.
And then we have encryption.
Sorry, so we don't have encryption, sorry, but with GRE over IPsec, we would have encryption.
So just by layering two different technologies together, we'll accomplish our objective.
So we'll get back to that later.
But by default, no encryption.
Remember that.
But what it does give us is what we call multi-protocol support.
So take a look at this.
I can run OSPF between those two routers over the GRE tunnel.
What does that mean?
It means that I can form neighbor adjacencies and I can share OSPF traffic, OSPF routes.
And then we can learn all the networks in branch by HQ and all the networks in HQ by branch.
And we'll have full routing connectivity over the internet through this GRE tunnel.
So the question now is, how does this even work?
How is this even possible?
Well, it's because we're creating tunnels.
So folks, when we talk about creating tunnels, whether they're IPsec tunnels or GRE tunnels or 802.1Q trunking encapsulated tunnels in our layer two environments, are we really creating tunnels?
Like, are we really creating tunnels through those environments?
No.
No, we're not.
What are we actually doing?
Does anybody know what we're actually doing to make all of this work?
What's the buzzword?
What's the keyword?
What is it that we actually do to make all of this tunneling happen?
Because we're not really creating tunnels ever.
We're doing encapsulation.
That's it.
That's all we're doing.
Encapsulating.
So regardless of whether it's 802.1Q, like when you think about it, it's 802.1Q.
Like when you think about our trunking discussion, what did we say?
Let's go ahead and in that case, add a tag.
The tag is a type of encapsulation in that particular scenario.
So going back to this page here we had, where we said, hey, there's our normal PC frame.
It arrives here.
If it needs to go across this trunk link, what do we need to do?
We need to be able to notify the other side which VLAN that traffic belongs to.
So break it open, add in an 802.1Q tag.
That's a type of encapsulation.
So that way the other side knows what to do with that traffic because the VLAN information is going to be included inside of it.
So with GRE, what are we doing in this case?
We're taking the entire packet.
So here's my entire packet.
So this packet, let's say, is going to from here, from here.
So this is my source.
This is going to be my destination.
So the packet arrives at the router and needs to be sent through the GRE tunnel, which doesn't really exist.
Remember, it's just encapsulation, over to this side, the destination.
So our original IP header has, let's say, 10.0.0.10 in it.
So 10.0.0.10, source IP.
Destination IP, 10.0.254, let's say, .5, 10.0.254.5, source and destination.
So that is still going to be right down here.
But what do we got to encapsulate?
We got to add header information to it.
So we take that packet and we add header information to it.
So this GRE header, what's going to be contained in that GRE header?
Well, how do we go from this router all the way over to this router?
Well, we get there over the internet.
So we go from this IP address.
So that is now our new source IP, our new source IP.
And this right here is going to be our destination IP.
So the source IP might be 203.0.113.90.
That's what it is in this case.
And the destination IP is 198.51.100.46.
So by encapsulating this, this is now the header that is used to go from this physical
interface all the way over to this physical interface over the internet.
And then when we get over this side, we tear all of this off.
And now we're left with the original packet again.
And then the original packet gets to be routed to its destination.
So that's what's happening.
There's no tunnel.
It's just encapsulation that's being utilized in this particular case.
Right.
So take the original packet and encapsulate it.
So that's my original packet.
Let's just remove it.
And there you go.
Now you're left with that to go over there.
And then when we get to the other side, you rip off the header and you're left with that.
Now, the problem we run into now is the MTU, the maximum transmission unit.
And that's why I have the diagram the way I have it.
So what is the maximum transmission unit for any Ethernet interface?
So for any Ethernet interface, what's the maximum transmission unit?
It's 1500.
So normally what would happen, and what does that mean?
It's the maximum size of a packet that can be put into an Ethernet frame.
So the maximum packet size is 1500.
And then you add on your Ethernet header, which adds another 18.
So 1518 is the grand total of the frame.
But the packet cannot be greater than 1500 on typical Ethernet interfaces.
So what does that mean?
It means that if we send a packet, the PC, the PC sends a packet that is 1500 bytes in size.
Then if we have the 1500 here, plus the 4 here, plus the 20 here, we're now at 1524.
Is that greater than the maximum transmission unit?
Yes, it is.
Which means what's going to have to happen now, folks?
Fragmentation.
Is fragmentation good, or is fragmentation bad?
Well, in this case, if we don't do fragmentation, then the packet has to get dropped.
But if we do fragmentation, now we have to get the CPU involved.
Because what does the CPU have to do?
It has to take this packet, and it's going to have to break it up.
Now in reality, if we do fragmentation, we're going to have to break it up.
Now in reality, it's not going to take the 1524 packet and break it up.
It's going to take the 1500 packet and break it up.
So it might create one, let's say, that is 1400, and one that is 100.
There's your 1500.
Now you have to add on your GRE header here, and you have to add on your GRE header here.
So now you've got a 1424, and you've got a 124.
It's a lot of work.
So for every single packet, if your router has to do this, it's going to slow your router down.
It's going to cause problems.
And then add encryption on top of that, folks.
That's even worse.
So the maximum transmission unit, whenever you're using GRE, is going to have to be dropped down to this.
Now luckily, when you use tunnel interfaces, GRE tunnel interfaces, it automatically happens for you.
Your router automatically sets it to 1476, the MTU of the interface, of the tunnel interface.
So what does that mean?
It means that our clients, we don't want them to send packets any greater than 1476, or else fragmentation is going to have to occur.
Now, it is possible that you might have set up that the routers are not allowed to do fragmentation.
So if the routers are not allowed to do fragmentation, or let's say the packet has the do not fragment bit set in your environment, then if the packet has a do not fragment bit set in it, then the router is not allowed to fragment it at all.
And therefore, the packet would have to be dropped if fragmentation was not allowed and the packet was greater than 1476.
So if the packet is 1477, it would have to be fragmented, and if do not fragment is enabled, then that means that the packet is going to have to be dropped.
If the do not fragment bit is not set, then the packet is going to be fragmented.
But if you ever need to adjust the MTU of any type of interface, folks, you can go and adjust the MTU of the interface by typing in the IP MTU command under the interface, so interface configuration mode, and you would specify the MTU.
So if you wanted the MTU to be 1400, then you'd set it to 1400 as an example.
So just keep that in mind for the certification exam.
They love to test you on this stuff.
And for you to recognize that, hey, if all of a sudden we're doing any type of encapsulation, the MTU may not be set properly.
So we'd have to manually adjust the MTU of the interface in order to accomplish this.
But with GRE Tunnels, it automatically sets it to 1476 for us.
So we don't technically have to change it for the tunnel interface.
But when we get to something like IPSec later, we would have to do it on the physical interfaces for IPSec.
We'd have to change the MTU on the interface, and we'll talk about that later.
So let's go ahead and do a GRE configuration now.
So in our environment, we're going to configure a GRE between R1 and branch.
So all of the values you see here in this image, we're going to have to change it to this, though,
because I think that conflicts with my environment.
We'll put two here instead in this configuration.
Actually, to make it better, let's do this.
Let's do this today.
So it's clear.
So what we're going to do here is we are going to set up a new IP address.
So we're going to go ahead and set up a new IP address.
And we're going to use the IP address of the facility.
And we're going to set up a new IP address of the facility.
Let's do this today.
So it's clear.
So what we're going to do here is we are going to set up, between R1 and branch, over the internet, a GRE tunnel.
So if we go to previous diagrams that we've used in this course, for example, like this one here,
we're setting up the GRE tunnel from here all the way over to here.
Over the internet connection.
So let's just use this page here while we go through it.
Which means I have no notes that I can access during this discussion.
So let's do the GRE tunnel here.
So in order for us to view this without anything else coming in the way, let's disable that interface right now.
Because what I want to do is I want to set this up so that way there are 10.0.254.0.24 network.
And, for example, our 10.0.0.0.24 network.
In the end, we're going to learn them over the GRE tunnel for both of those devices.
That's what I want to do here.
So I don't want this in the way right now during this configuration.
Because this, according to OSPF, will be superior to the GRE tunnel from a cost standpoint.
So I'll come back and talk about that later.
But for R2 right now, let's go to interface, fastethernet, 0.0.0.0.
And let's just shut it down.
So that way there, in the end, we only have this path we're going to be able to take.
So you can see the GRE tunnel in action.
So if we go back to DSW1 as an example,
we should see that we no longer have any routes to 10.0.254.0 in our routing table.
Before I did.
So if I come back up here, 10.0.254.0 was in my routing table.
All right.
So now that we have that done, let's go ahead and go to R1.
And on R1, I'm going to type in show IP interface brief.
All right.
So right now we have these different physical interfaces.
Fastethernet 0.0.0.0 is going to be the physical interface that we use to go onto the Internet.
And so if we go to branch and take a peek at its interfaces, show IP interface brief,
we're going to see the same thing here.
This is going to be our physical interface that we're going to be using to get to the Internet.
This is important because that IP address we need for our GRE configuration.
So I need the IP address of the interfaces connected to the Internet for this to work.
So going back to R1, I'm going to type in configure terminal.
We'll type in interface tunnel.
And I'm going to create tunnel number 0 here today for my demonstration.
So this is a virtual interface, a tunnel interface.
Now, notice the tunnel is down.
And that makes sense because we haven't done any configuration right now.
What we're going to do is we are now going to give the tunnel its own private IP address.
So that way there, the tunnel private IP address can be directly connected to this tunnel private IP address when it's all said and done.
So we're going to type in IP address.
And what did we say we were going to use on our other diagram?
We said 172.20.1.1.255.255.255.252.
So the other side is going to be 172.20.1.2.30.
Now I want to specify the source of the tunnel.
So we're going to say, oh, sorry, before I do that, one thing, the mode of the tunnel.
Let's do that first.
So tunnel mode, you'll see that Cisco tunnel interfaces can operate in many, many, many, many, many, many different modes.
We are dealing with GRE.
You'll notice that I can do GRE IP.
So that would be where the underlying network is IPv4.
So I'm running GRE on top of an IPv4 network.
And that's what we're doing here, GRE on top of an IPv4 network.
You could do GRE on top of an IPv6 network.
So if you were creating a GRE tunnel over the IPv6 internet, then you would do GRE over IPv6.
Multipoint, this is for DMVPNs over the internet, as an example.
So if you wanted to do, for example, like a hub, HQ, and then, pardon me, you go out to, let's say, the internet, and then you have your spokes here.
So there's spoke one, spoke two, spoke three.
Those would be your branch offices, branch offices.
Well, we could have this as a multipoint mode interface, and then that one interface would have tunnels from here to here, here to here, and here to here.
That's what that is.
So that is for DMVPNs, dynamic multipoint VPNs using GRE, as well as GRE over IPv6.
If you are interested in that at all, folks, if you're interested in that at all, I encourage you to check out the Anarsi course that we have available in our environment.
I get into DMVPNs in that course, so I definitely encourage you to take advantage of that.
Right, so if you go to the Anarsi course, this is actually Anarsi version 1.0, but Anarsi version 1.1 also has it.
But you go to Anarsi version 1.1 would be the better option.
I just haven't loaded into my account yet.
And you'll see that there is a discussion on DMVPNs called DMVPN Configuration and Verification, and then DMVPN IPsec Configuration and Verification.
So if you're ever interested in DMVPNs for your environment, they're awesome, by the way.
I encourage you to check that out, take a peek at that.
So tunnel mode is imperative here, especially for the certification exam.
So you have to understand what is the underlying network.
If the underlying network's IPv4, then it's GRE IP.
If the underlying network's IPv6, then it's GRE IPv6.
That's it.
What I also want to point out to you is that this right here, tunnel mode GRE IP, that's the default.
So you don't have to type this in at all.
It defaults to using that.
All right, now for the certification exam, if you ever had to configure a tunnel, I want you to be careful.
Why?
Because you don't know if there's already that tunnel already previously configured, like partially configured in a simulation.
Because Cisco might ask you to do a simulation, but partially configure it.
If they ever ask you to do that, be very, very careful, because what if they told you, we want you to create a tunnel, and we want you to use Interface Tunnel 0?
So you go ahead and type Interface Tunnel 0.
But what they've done is they've actually preconfigured that, and they put the wrong mode in.
So just because in the real world you don't have to type it in, doesn't mean you shouldn't type it in on the exam.
Why?
Because what if they preconfigured the interface with the wrong tunnel mode just to mess you up?
So always verify that.
Type in Do Show Interface Tunnel 0, and find out.
Oops, Show Run, sorry.
Show Run Interface Tunnel 0, and find out, did they change the mode?
If there's no mode listed, it's GRE over IP.
Another way you can do that is Show Interface Tunnel 0, and if it tells you right here GRE IP, then you know it's GRE IP.
If it's not GRE IP, then type in the command Tunnel Mode GRE IP.
So what have we done so far?
We've created the tunnel.
We've given it an IP address, and we've configured Tunnel Mode GRE IP.
Now I need to define the source of my tunnel.
So what's the source?
My source is that physical interface right there, FastEthernet 0.0.0.
So all I have to do is type in, in my tunnel configuration, Tunnel Source FastEthernet 0.0.0.
And therefore, it'll use the IP address of that interface as the source IP of the tunnel.
Now I'm going to type in Tunnel Destination, and the Tunnel Destination is going to be the IP address of branches interface connected to the Internet.
So let's go over there, and we'll copy and paste that over here onto R1, and there we go.
Now what you're going to see is my tunnel go up.
Now that is totally misleading.
Why is that misleading?
It's misleading because I haven't even configured the other side.
I haven't configured the other side.
How in the world is my tunnel up?
That makes no sense.
It really does make no sense, right?
So why in the world is the tunnel up?
I'll tell you why the tunnel is up.
The tunnel is up because there is a route in my routing table to get to that address.
That's it.
There is a route in my routing table to get to that address.
And what is that route?
It's the default route.
That's right.
The default route.
So as long as you have one route in the routing table to get to that destination, your tunnel goes up up.
That's it.
That's all.
So never rely on up up for your tunnel interface to determine if it's actually working.
Because right now the other side is not even configured.
So it's not really up up in the grand scheme of things.
But the virtual interface is.
But the tunnel is not.
Keep that in mind.
So how do you test if the tunnel is working?
You're going to ping to the other side of this tunnel and trace to the other side of this tunnel.
That's what you're going to do using the private IP address.
If that works, then you know the tunnel is working.
So let's take a look at our config.
Do show run interface tunnel zero.
We have our config done here.
So now we're going to go over to the other side.
We've got to go to branch.
And on branch, I'm going to create interface tunnel.
So interface tunnel.
You don't have to use the same number on the other side.
But I like to use the same number.
We're going to type tunnel mode GREIP.
Although, again, I don't have to do that because that's the default value.
It's a good habit to get into just in case on an exam they turn around and they pre-configure some things
and they mess it all up ahead of time just to make you struggle on the exam.
All right.
What do we want now?
We want our IP address.
So what was the IP address on the other side?
We said it was 172.21.1.
So we're going to do 172.21.2 over here and 255.255.255.252.
And then tunnel source for this router is going to be gigabit ethernet 0 slash 1.
And then our tunnel destination is going to be the IP address of R1's interface connected to the Internet,
which is this one right here.
And there you go.
We're done.
So now I have a tunnel created between here and here.
Well, no, not really, right?
There's no tunnel.
Remember that.
All I've done is set up my router.
So if traffic arrives at the router and that traffic needs to go from here over to here,
it can be encapsulated, pun old, over to the other side.
So let's first of all take a peek at show IP route on branch.
Do we have an entry for that tunnel interface?
We do.
It's right there.
So the tunnel is directly connected to us at 172.21.0.
Go to R1.
Type in show IP route.
And what do we have in this particular case?
We can see that we have 172.21.0.
Again, tunnel 0.
Perfect.
Love it.
So far, so good.
Let's go ahead and ping through that tunnel.
So 172.2.
Right?
So the ping worked.
The question is, did the ping actually work this way, or did it actually just ping all the way around?
Well, we know this is down, so we know that it did not what?
We know that it did not go this way.
But the best way to verify it is trace.
Because if I type in 172.20.1.2, and there is just one hop,
then we know that we actually used the GRE tunnel,
and we did not just go to the Internet, bounce around through a bunch of routers.
Because if we went to the Internet, then we'd see the router IP addresses in there.
Whereas in this case, we don't, meaning we actually encapsulated it and came out the other side.
So there you go.
Our GRE tunnel is actually working in our particular case.
So now let's run OSPF on the GRE tunnel.
Because if we go to branch right now, we don't have any routes over here in this environment showing up in our routing table.
We only have the directly connected routes and the static route.
So if right now we go to configure terminal interface tunnel 0, IP OSPF 1 area 0,
let's go over to R1 and do the same thing, configure terminal interface tunnel 0, IP OSPF 1 area 0.
What are we going to find?
We're going to find we form a neighbor adjacency over the actual tunnel.
If we do show IP OSPF interface brief, you'll see here that we have tunnel 0 participating in the routing process in area 0 right now.
Look at the cost.
The cost is inflated.
OSPF does not prefer a tunnel interface if there's another path to go.
So it artificially inflates the cost really high, so it avoids it unless it's the last option available.
So with that in mind, though, if we go to somebody like R1 right now and we type in do show IP route, what are we going to see now?
We should see OSPF learned routes from the branch office now through the tunnel.
So you see how we've been able to now learn about that network through our tunnel interface.
Not too shabby.
Now let's think about it from the perspective of R2.
If we bring back up our interface on R2 now, let's bring this back up.
What's going to happen?
Well, we're going to form a neighbor adjacency here, and then that network is going to be successfully shared over here,
and then that's going to be successfully shared up to there and so on and so forth.
What does that mean?
It means now under normal conditions, we're going to go which way in order to get to that particular network?
Well, we're going to take the path through our environment.
So, for example, if I went to R1 right now, you're going to see that we prefer 10.0.254.0 via what?
Going this way right now.
Going that way.
Why?
Because that would be a lower cost.
Look, the cost is 22 right now, right?
So if this is our WAN connection, a higher speed WAN connection, more expensive WAN connection,
more stable WAN connection, we could use that as a primary path.
And then if and only if that path fails, then we can go ahead and use the backup path, which would be maybe our GRE tunnel.
So this is an option you have.
So if you want to do like a primary, secondary, you can.
If you just want to use GRE and no longer pay for your WAN connection, you can do that as well.
Many different opportunities here.
But let's go back to R2 and let's bring this down.
Then what we're going to eventually see is that we're going to be updated here.
And when we get updated, we're now going to be going through the GRE tunnel in order to get to that particular network, as you see here.
Look, the cost is a lot higher in that particular scenario.
I'm going to go back to my notes now for GRE and take a peek to make sure that we've covered everything we need to cover in this particular case.
So I do have in the slides the configurations.
Listen to the slides if you ever want to go back and review them.
When you look at this output here, again, if it says up-up, that just means the virtual interface is up-up.
It doesn't mean your tunnel is actually working.
You want to test the tunnel, you're going to have to ping it, you're going to have to trace it.
If you need to verify the address, you can verify it here.
Notice the bandwidth is set to 100 kilobits per second by default.
That's why OSPF has such a high cost for it automatically.
Notice that the encapsulation is tunnel, in this case, GRE over IP tunnel.
And so anything I'm highlighting are things I want you to remember for the certification exam.
What else do we have?
We have our tunnel source.
So the tunnel source, when you put in the IP address or the interface for your configuration, it will automatically populate the IP address there.
And then the destination, you put it in, it will specify the destination.
This here is not really the MTU.
That's not really the MTU.
That's just a virtual MTU.
The real MTU here is down at the bottom.
This is your tunnel transport MTU.
This is the one right here, 1476 that we talked about before.
This was R1.
Let me see here.
What else do I want to talk about?
This is still R1.
So something to keep in mind here, you'll see that keepalives are not set.
What does that mean?
By default, there is no way to track whether your tunnel is working or not.
Why?
Because as long as you have a destination in your routing table to reach the tunnel destination, then your tunnel is going to be what?
Your tunnel is going to be up, up.
But there's no way to constantly track that tunnel destination.
Could you use something like IPSLA, generate a little ping and test that?
You can do stuff like that.
But we do have built-in keepalives that I want you to know about for the certification exams.
So keepalive is not set.
So that's the default.
Default equals not set.
Now, if you turn on keepalives, so when you turn them on, the default is going to be what?
The default is going to be 10 seconds for the interval, meaning we're going to send a keepalive message every 10 seconds to the destination from the source.
And the default is also three retries, meaning if the 10-second interval fails, so I send it out and I don't get a response, then I'll try another one 10 seconds later.
If I don't get a response, then I'll try another one 10 seconds later.
If I don't get a response, that's after three retries.
So if three retries, I don't get a response, then the tunnel comes down.
Right, so GRE tunnels are what we classify as stateless, which means that every single tunnel endpoint you have does not keep any information about the state or availability of the remote tunnel endpoint.
So therefore, your local tunnel interface is always going to be up, up as long as you have that route to the destination IP.
So in this case, the GRE tunnel keepalive mechanism is about sending out these keepalives so that way their one side can be notified if the other side is still available.
If the other side is not available, then this side can go down.
Right, if you want this more aggressive, you can change those values.
Now, I want to talk about the recursive error.
What is a recursive error?
Well, if you ever see this, look what it says here.
Line protocol up down.
Line protocol interface tunnel zero is up.
And then it says tunnel five recur down.
Tunnel zero temporarily disabled due to recursive routing.
Then it says tunnel is down.
Then the tunnel comes up.
Then it says tunnel is disabled due to recursive routing.
Therefore, the tunnel is down.
When does this happen?
This occurs when the tunnel destination is reachable through the actual tunnel itself.
So picture this.
My router here, when my GRE tunnel comes up, if we're running OSPF, for example, on the physical interface as well as the tunnel interface, when the tunnel comes up,
the physical interface network is injected into OSPF.
It will then be shared through the tunnel.
So the router on the other side learns about that through the tunnel.
Likewise, on the other side, the tunnel physical interface will be shared over here.
So when I have this side configured as destination, as 203.0.113.90 as we configured, this address right here, if OSPF is enabled on the physical interface connected to the internet,
the network ID of that interface gets injected into OSPF.
It gets shared across the tunnel.
Now this router branch A says, oh, the destination is reachable through the tunnel and no longer out the actual interface.
So what that means is that we have recursive routing.
I have learned about the destination through the tunnel.
So what that does is it tears down the tunnel because that is wrong.
You can't learn about the physical tunnel destination through the virtual tunnel.
That can happen.
So as a result of that, it waits a bit and it comes up again.
And then what happens?
It learns about the destination through the tunnel again.
So what's the problem here?
The problem is you enabled the routing protocol on the physical tunnel interface.
That can't happen.
So if you enabled EIGRP on the actual physical tunnel interface, you'd have recursive routing.
If you enabled OSPF on the physical, you'd have recursive routing and so on and so forth.
So for example, if you were the type of person to use the network command for OSPF,
network 0.0.0.0, 255, 255, 255, 255, area, whatever, you would always have recursive routing with GRE and it wouldn't work.
Because you will always end up learning the physical interface through the tunnel.
So you can't have your dynamic routing protocol running on that physical tunnel interface.
Only the virtual tunnel interface for this to work.
Keep that in mind for the certification exam.
All right.
So that is GRE.
Make sure you can configure it.
Make sure you can verify it.
Make sure you know the things I pointed out to you.
Make sure you can ping.
You can trace route across it.
Oh, and don't forget, you can also place a tunnel interface in what?
A VRF, as we talked about at the very end of our VRF discussion.
So keep that in mind for the exam as well.