WEBVTT 00:00:00.000 --> 00:00:08.760 And that next discussion is going to be all about VPNs, virtual private networks. 00:00:08.760 --> 00:00:15.160 So for the exam under VPNs, we have to know about GRE and we have to know about site-to-site IPsec VPN tunnels. 00:00:16.320 --> 00:00:20.360 And then we have to know about GRE over IPsec. Very, very important. 00:00:22.719 --> 00:00:28.080 We already covered one type of VPN and that is VRFs. So VRFs is the type of VPN as well, folks. 00:00:29.040 --> 00:00:30.639 What else is another type of VPN? 00:00:36.279 --> 00:00:39.639 VLANs. All right. VLANs are a type of VPN as well, if you didn't know that. 00:00:40.400 --> 00:00:44.320 We're creating basically virtual tunnels through that layer two environment. 00:00:44.919 --> 00:00:47.040 And so VPNs are all over the place. 00:00:47.040 --> 00:00:50.799 But we typically, most of us say VPNs, we think of IPsec VPNs. 00:00:50.799 --> 00:00:52.080 But there's a lot more than just that. 00:00:52.080 --> 00:00:54.919 So let's begin here by talking about GRE tunneling. 00:00:54.919 --> 00:00:56.480 We'll do a configuration verification. 00:00:56.919 --> 00:00:59.000 You better know how to do this for the certification exam. 00:01:00.160 --> 00:01:02.560 All right. So first of all, what is a VPN? 00:01:02.560 --> 00:01:07.440 A VPN is any type of tunnel that virtually connects to non-direct connected points directly to each other. 00:01:07.440 --> 00:01:12.680 So when you think about this environment here, when I'm trying to connect it to this environment, 00:01:12.680 --> 00:01:14.480 we have the ability to connect over the Internet. 00:01:15.080 --> 00:01:19.360 The problem is, is that the Internet has many, many, many, many, many, many different routers between us. 00:01:19.360 --> 00:01:21.160 Many different networks between us. 00:01:21.160 --> 00:01:24.639 So when you think about routers, routers, routers, routers, routers, routers, routers, routers. 00:01:24.639 --> 00:01:30.559 So we, we, we, these two devices are not directly connected to each other. 00:01:31.239 --> 00:01:37.839 But with the VPN, I can logically, virtually direct them, directly connect them to each other. 00:01:38.000 --> 00:01:40.879 So the same thing here with a mobile worker or a small office, home office. 00:01:41.080 --> 00:01:45.879 I can virtually, directly connect these devices back to, let's say, headquarters. 00:01:48.599 --> 00:01:52.480 But and that doesn't necessarily mean security. 00:01:52.480 --> 00:01:53.639 Keep that in mind, though. 00:01:53.680 --> 00:01:54.360 Keep that in mind. 00:01:54.360 --> 00:01:56.080 VPN doesn't necessarily mean security. 00:01:56.440 --> 00:02:02.199 Because when we talk about layer two examples, for example, like VLANs, VLANs, that's a type of VPN. 00:02:02.839 --> 00:02:06.680 But there's no like encryption and integrity checking and stuff like that with VLANs. 00:02:07.320 --> 00:02:09.880 Frame relay was a type of VPN back in the day. 00:02:09.880 --> 00:02:10.800 ATM was. 00:02:11.199 --> 00:02:14.800 VPLS, virtual private LAN services, virtual private wire services. 00:02:14.800 --> 00:02:20.000 Those are all layer two examples of VPNs, regardless of whether there's safety and security on them or not. 00:02:20.399 --> 00:02:24.360 In layer three, we have GREs, no built in security with GRE. 00:02:24.399 --> 00:02:25.320 Let's be clear about that. 00:02:25.839 --> 00:02:29.800 And then MPLS layer three VPNs, just because it's a VPN, right? 00:02:29.839 --> 00:02:31.320 That doesn't mean it's safe and secure. 00:02:31.320 --> 00:02:36.279 A MPLS layer three VPN might not be as safe and secure as you need it to be. 00:02:37.080 --> 00:02:42.520 And therefore, you are still going to have to implement encryption for your traffic going across that VPN. 00:02:43.960 --> 00:02:45.360 IPsec VPNs. 00:02:45.720 --> 00:02:49.360 Yeah, those ones, if implemented properly, again, provide encryption. 00:02:49.600 --> 00:02:52.119 But you can set up IPsec VPNs without encryption. 00:02:52.880 --> 00:02:57.639 You can use authentication header instead of ESP, and then you get a VPN without encryption. 00:02:58.080 --> 00:03:03.520 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. 00:03:04.199 --> 00:03:06.800 So GRE specifically is what our discussion is about right now. 00:03:07.360 --> 00:03:11.160 GRE gives us the ability to create a point to point link over an IP network. 00:03:11.160 --> 00:03:13.639 So here's our IP network right now, the Internet. 00:03:14.520 --> 00:03:22.440 I have HQ, I have branch, and I am not directly connected between HQ and branch because the Internet's in between. 00:03:22.839 --> 00:03:28.119 There could be 50 routers, 40 routers, 30 routers, 10 routers, many, many different interconnections between. 00:03:28.160 --> 00:03:29.279 This is Internet to Internet. 00:03:29.320 --> 00:03:32.399 So my Internet connection, this is the Internet connection over here. 00:03:32.600 --> 00:03:33.839 We're going out to the Internet. 00:03:33.960 --> 00:03:35.800 Routers, routers, routers, routers, routers. 00:03:36.080 --> 00:03:37.080 We're not directly connected. 00:03:37.440 --> 00:03:40.919 This interface is in a totally different subnet than this interface over here. 00:03:41.919 --> 00:03:49.080 So I could use a GRE tunnel to directly connect virtually these two routers together. 00:03:49.080 --> 00:03:55.080 So therefore, that GRE tunnel on each side is in the exact same subnet slash VLAN slash broadcast domain as an example. 00:03:55.639 --> 00:03:58.759 And with GRE, we utilize protocol number 47. 00:03:59.520 --> 00:04:10.039 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. 00:04:10.559 --> 00:04:17.959 All right, GRE's protocol number 47, OSPF's protocol number 89, EIGP's protocol number 88, GRE's protocol number 47. 00:04:18.399 --> 00:04:25.279 So with an access control list, if you specify protocol number 47, GRE, does that mean you could block GRE traffic? 00:04:25.279 --> 00:04:28.359 Sure you could. Originally designed by Cisco. 00:04:28.880 --> 00:04:31.359 So this was a Cisco idea, a Cisco invention. 00:04:31.600 --> 00:04:32.760 Very awesome idea. 00:04:32.880 --> 00:04:34.600 Very awesome invention, by the way. 00:04:35.239 --> 00:04:45.160 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. 00:04:46.600 --> 00:04:53.679 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. 00:04:53.720 --> 00:04:56.320 That means anybody can eavesdrop on your traffic. 00:04:57.200 --> 00:04:57.760 Anybody can. 00:04:58.600 --> 00:05:06.519 So implementing a GRE tunnel by itself over an untrusted network is a very, very bad idea. 00:05:07.920 --> 00:05:11.679 And I'll show you later how you can protect GRE traffic over an untrusted network. 00:05:11.720 --> 00:05:13.160 It's called GRE over IPsec. 00:05:14.839 --> 00:05:16.119 And then we have encryption. 00:05:17.000 --> 00:05:21.399 Sorry, so we don't have encryption, sorry, but with GRE over IPsec, we would have encryption. 00:05:21.440 --> 00:05:24.600 So just by layering two different technologies together, we'll accomplish our objective. 00:05:24.640 --> 00:05:25.760 So we'll get back to that later. 00:05:25.959 --> 00:05:27.279 But by default, no encryption. 00:05:27.279 --> 00:05:27.760 Remember that. 00:05:28.200 --> 00:05:31.359 But what it does give us is what we call multi-protocol support. 00:05:31.799 --> 00:05:32.600 So take a look at this. 00:05:32.839 --> 00:05:40.920 I can run OSPF between those two routers over the GRE tunnel. 00:05:41.799 --> 00:05:42.679 What does that mean? 00:05:42.959 --> 00:05:50.440 It means that I can form neighbor adjacencies and I can share OSPF traffic, OSPF routes. 00:05:50.839 --> 00:05:58.000 And then we can learn all the networks in branch by HQ and all the networks in HQ by branch. 00:05:58.399 --> 00:06:03.959 And we'll have full routing connectivity over the internet through this GRE tunnel. 00:06:07.119 --> 00:06:09.239 So the question now is, how does this even work? 00:06:09.839 --> 00:06:11.160 How is this even possible? 00:06:12.279 --> 00:06:14.239 Well, it's because we're creating tunnels. 00:06:14.239 --> 00:06:37.160 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? 00:06:37.600 --> 00:06:41.799 Like, are we really creating tunnels through those environments? 00:06:41.880 --> 00:06:42.399 No. 00:06:43.559 --> 00:06:44.200 No, we're not. 00:06:44.200 --> 00:06:45.160 What are we actually doing? 00:06:45.160 --> 00:06:47.679 Does anybody know what we're actually doing to make all of this work? 00:06:47.920 --> 00:06:48.799 What's the buzzword? 00:06:48.799 --> 00:06:49.839 What's the keyword? 00:06:50.679 --> 00:06:54.119 What is it that we actually do to make all of this tunneling happen? 00:06:54.839 --> 00:06:56.880 Because we're not really creating tunnels ever. 00:07:00.559 --> 00:07:01.760 We're doing encapsulation. 00:07:01.760 --> 00:07:02.279 That's it. 00:07:02.519 --> 00:07:03.279 That's all we're doing. 00:07:04.320 --> 00:07:05.160 Encapsulating. 00:07:05.640 --> 00:07:10.399 So regardless of whether it's 802.1Q, like when you think about it, it's 802.1Q. 00:07:10.959 --> 00:07:13.760 Like when you think about our trunking discussion, what did we say? 00:07:14.160 --> 00:07:16.480 Let's go ahead and in that case, add a tag. 00:07:16.880 --> 00:07:20.000 The tag is a type of encapsulation in that particular scenario. 00:07:21.200 --> 00:07:28.959 So going back to this page here we had, where we said, hey, there's our normal PC frame. 00:07:28.959 --> 00:07:30.079 It arrives here. 00:07:33.679 --> 00:07:37.160 If it needs to go across this trunk link, what do we need to do? 00:07:37.160 --> 00:07:42.399 We need to be able to notify the other side which VLAN that traffic belongs to. 00:07:42.679 --> 00:07:46.359 So break it open, add in an 802.1Q tag. 00:07:46.359 --> 00:07:47.880 That's a type of encapsulation. 00:07:49.079 --> 00:07:53.839 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. 00:07:56.239 --> 00:07:58.279 So with GRE, what are we doing in this case? 00:07:58.279 --> 00:07:59.600 We're taking the entire packet. 00:08:00.040 --> 00:08:01.720 So here's my entire packet. 00:08:02.720 --> 00:08:06.679 So this packet, let's say, is going to from here, from here. 00:08:06.679 --> 00:08:07.720 So this is my source. 00:08:08.160 --> 00:08:09.359 This is going to be my destination. 00:08:11.559 --> 00:08:19.640 So the packet arrives at the router and needs to be sent through the GRE tunnel, which doesn't really exist. 00:08:19.640 --> 00:08:22.720 Remember, it's just encapsulation, over to this side, the destination. 00:08:23.799 --> 00:08:29.720 So our original IP header has, let's say, 10.0.0.10 in it. 00:08:29.720 --> 00:08:33.960 So 10.0.0.10, source IP. 00:08:34.359 --> 00:08:46.599 Destination IP, 10.0.254, let's say, .5, 10.0.254.5, source and destination. 00:08:56.320 --> 00:09:00.159 So that is still going to be right down here. 00:09:01.840 --> 00:09:03.440 But what do we got to encapsulate? 00:09:03.440 --> 00:09:05.719 We got to add header information to it. 00:09:07.880 --> 00:09:11.919 So we take that packet and we add header information to it. 00:09:12.320 --> 00:09:16.719 So this GRE header, what's going to be contained in that GRE header? 00:09:17.919 --> 00:09:27.159 Well, how do we go from this router all the way over to this router? 00:09:28.760 --> 00:09:30.359 Well, we get there over the internet. 00:09:30.679 --> 00:09:33.280 So we go from this IP address. 00:09:33.799 --> 00:09:43.320 So that is now our new source IP, our new source IP. 00:09:45.039 --> 00:09:50.359 And this right here is going to be our destination IP. 00:09:51.359 --> 00:10:03.880 So the source IP might be 203.0.113.90. 00:10:03.880 --> 00:10:05.159 That's what it is in this case. 00:10:05.799 --> 00:10:09.280 And the destination IP is 198.51.100.46. 00:10:10.440 --> 00:10:19.159 So by encapsulating this, this is now the header that is used to go from this physical 00:10:19.159 --> 00:10:24.679 interface all the way over to this physical interface over the internet. 00:10:26.239 --> 00:10:29.880 And then when we get over this side, we tear all of this off. 00:10:30.520 --> 00:10:33.080 And now we're left with the original packet again. 00:10:33.719 --> 00:10:37.119 And then the original packet gets to be routed to its destination. 00:10:41.400 --> 00:10:42.640 So that's what's happening. 00:10:42.679 --> 00:10:43.760 There's no tunnel. 00:10:44.159 --> 00:10:47.840 It's just encapsulation that's being utilized in this particular case. 00:10:49.440 --> 00:10:49.640 Right. 00:10:49.640 --> 00:10:52.919 So take the original packet and encapsulate it. 00:10:52.919 --> 00:10:54.320 So that's my original packet. 00:10:54.320 --> 00:10:55.359 Let's just remove it. 00:10:56.039 --> 00:10:56.679 And there you go. 00:10:56.679 --> 00:10:59.239 Now you're left with that to go over there. 00:10:59.559 --> 00:11:03.440 And then when we get to the other side, you rip off the header and you're left with that. 00:11:06.200 --> 00:11:13.239 Now, the problem we run into now is the MTU, the maximum transmission unit. 00:11:20.159 --> 00:11:22.400 And that's why I have the diagram the way I have it. 00:11:23.239 --> 00:11:30.039 So what is the maximum transmission unit for any Ethernet interface? 00:11:30.200 --> 00:11:33.479 So for any Ethernet interface, what's the maximum transmission unit? 00:11:34.479 --> 00:11:35.719 It's 1500. 00:11:38.400 --> 00:11:42.080 So normally what would happen, and what does that mean? 00:11:42.080 --> 00:11:47.039 It's the maximum size of a packet that can be put into an Ethernet frame. 00:11:48.039 --> 00:11:51.239 So the maximum packet size is 1500. 00:11:51.520 --> 00:11:54.440 And then you add on your Ethernet header, which adds another 18. 00:11:54.440 --> 00:11:56.880 So 1518 is the grand total of the frame. 00:11:57.159 --> 00:12:02.840 But the packet cannot be greater than 1500 on typical Ethernet interfaces. 00:12:04.320 --> 00:12:05.400 So what does that mean? 00:12:06.159 --> 00:12:14.919 It means that if we send a packet, the PC, the PC sends a packet that is 1500 bytes in size. 00:12:17.400 --> 00:12:27.479 Then if we have the 1500 here, plus the 4 here, plus the 20 here, we're now at 1524. 00:12:28.119 --> 00:12:30.719 Is that greater than the maximum transmission unit? 00:12:31.000 --> 00:12:31.760 Yes, it is. 00:12:33.880 --> 00:12:36.840 Which means what's going to have to happen now, folks? 00:12:40.559 --> 00:12:41.599 Fragmentation. 00:12:41.599 --> 00:12:42.320 Fragmentation. 00:12:42.320 --> 00:12:44.880 Is fragmentation good, or is fragmentation bad? 00:12:46.880 --> 00:12:51.799 Well, in this case, if we don't do fragmentation, then the packet has to get dropped. 00:12:55.119 --> 00:12:59.960 But if we do fragmentation, now we have to get the CPU involved. 00:13:00.359 --> 00:13:01.599 Because what does the CPU have to do? 00:13:01.599 --> 00:13:05.400 It has to take this packet, and it's going to have to break it up. 00:13:06.559 --> 00:13:10.239 Now in reality, if we do fragmentation, we're going to have to break it up. 00:13:11.239 --> 00:13:15.000 Now in reality, it's not going to take the 1524 packet and break it up. 00:13:15.280 --> 00:13:17.559 It's going to take the 1500 packet and break it up. 00:13:18.080 --> 00:13:22.320 So it might create one, let's say, that is 1400, and one that is 100. 00:13:22.359 --> 00:13:23.479 There's your 1500. 00:13:24.640 --> 00:13:29.159 Now you have to add on your GRE header here, and you have to add on your GRE header here. 00:13:29.159 --> 00:13:33.719 So now you've got a 1424, and you've got a 124. 00:13:37.400 --> 00:13:38.239 It's a lot of work. 00:13:38.719 --> 00:13:43.559 So for every single packet, if your router has to do this, it's going to slow your router down. 00:13:43.919 --> 00:13:44.840 It's going to cause problems. 00:13:45.080 --> 00:13:46.960 And then add encryption on top of that, folks. 00:13:46.960 --> 00:13:47.799 That's even worse. 00:13:48.239 --> 00:13:49.000 That's even worse. 00:13:53.320 --> 00:14:01.280 So the maximum transmission unit, whenever you're using GRE, is going to have to be dropped down to this. 00:14:01.640 --> 00:14:06.919 Now luckily, when you use tunnel interfaces, GRE tunnel interfaces, it automatically happens for you. 00:14:07.799 --> 00:14:13.320 Your router automatically sets it to 1476, the MTU of the interface, of the tunnel interface. 00:14:14.359 --> 00:14:15.039 So what does that mean? 00:14:15.039 --> 00:14:24.000 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. 00:14:26.000 --> 00:14:33.520 Now, it is possible that you might have set up that the routers are not allowed to do fragmentation. 00:14:33.880 --> 00:14:46.479 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. 00:14:47.080 --> 00:14:54.760 And therefore, the packet would have to be dropped if fragmentation was not allowed and the packet was greater than 1476. 00:14:54.760 --> 00:15:03.880 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. 00:15:09.400 --> 00:15:12.880 If the do not fragment bit is not set, then the packet is going to be fragmented. 00:15:13.880 --> 00:15:29.880 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. 00:15:29.880 --> 00:15:33.880 So if you wanted the MTU to be 1400, then you'd set it to 1400 as an example. 00:15:34.880 --> 00:15:37.880 So just keep that in mind for the certification exam. 00:15:38.880 --> 00:15:40.880 They love to test you on this stuff. 00:15:41.880 --> 00:15:48.880 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. 00:15:48.880 --> 00:15:53.880 So we'd have to manually adjust the MTU of the interface in order to accomplish this. 00:15:53.880 --> 00:15:56.880 But with GRE Tunnels, it automatically sets it to 1476 for us. 00:15:56.880 --> 00:15:59.880 So we don't technically have to change it for the tunnel interface. 00:16:00.880 --> 00:16:05.880 But when we get to something like IPSec later, we would have to do it on the physical interfaces for IPSec. 00:16:05.880 --> 00:16:08.880 We'd have to change the MTU on the interface, and we'll talk about that later. 00:16:16.880 --> 00:16:18.880 So let's go ahead and do a GRE configuration now. 00:16:18.880 --> 00:16:22.880 So in our environment, we're going to configure a GRE between R1 and branch. 00:16:22.880 --> 00:16:27.880 So all of the values you see here in this image, we're going to have to change it to this, though, 00:16:27.880 --> 00:16:29.880 because I think that conflicts with my environment. 00:16:29.880 --> 00:16:32.880 We'll put two here instead in this configuration. 00:16:33.880 --> 00:16:35.880 Actually, to make it better, let's do this. 00:16:38.880 --> 00:16:39.880 Let's do this today. 00:16:40.880 --> 00:16:41.880 So it's clear. 00:16:42.880 --> 00:16:46.880 So what we're going to do here is we are going to set up a new IP address. 00:16:46.880 --> 00:16:48.880 So we're going to go ahead and set up a new IP address. 00:16:50.880 --> 00:16:52.880 And we're going to use the IP address of the facility. 00:16:52.880 --> 00:16:54.880 And we're going to set up a new IP address of the facility. 00:16:54.880 --> 00:16:55.880 Let's do this today. 00:16:57.880 --> 00:16:58.880 So it's clear. 00:16:59.880 --> 00:17:07.880 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. 00:17:07.880 --> 00:17:12.880 So if we go to previous diagrams that we've used in this course, for example, like this one here, 00:17:17.880 --> 00:17:23.880 we're setting up the GRE tunnel from here all the way over to here. 00:17:24.880 --> 00:17:27.880 Over the internet connection. 00:17:27.880 --> 00:17:30.880 So let's just use this page here while we go through it. 00:17:33.880 --> 00:17:36.880 Which means I have no notes that I can access during this discussion. 00:17:40.880 --> 00:17:41.880 So let's do the GRE tunnel here. 00:17:45.880 --> 00:17:53.880 So in order for us to view this without anything else coming in the way, let's disable that interface right now. 00:17:54.880 --> 00:18:02.880 Because what I want to do is I want to set this up so that way there are 10.0.254.0.24 network. 00:18:03.880 --> 00:18:06.880 And, for example, our 10.0.0.0.24 network. 00:18:07.880 --> 00:18:12.880 In the end, we're going to learn them over the GRE tunnel for both of those devices. 00:18:12.880 --> 00:18:13.880 That's what I want to do here. 00:18:13.880 --> 00:18:18.880 So I don't want this in the way right now during this configuration. 00:18:18.880 --> 00:18:24.880 Because this, according to OSPF, will be superior to the GRE tunnel from a cost standpoint. 00:18:24.880 --> 00:18:25.880 So I'll come back and talk about that later. 00:18:25.880 --> 00:18:32.880 But for R2 right now, let's go to interface, fastethernet, 0.0.0.0. 00:18:32.880 --> 00:18:34.880 And let's just shut it down. 00:18:34.880 --> 00:18:39.880 So that way there, in the end, we only have this path we're going to be able to take. 00:18:39.880 --> 00:18:41.880 So you can see the GRE tunnel in action. 00:18:41.880 --> 00:18:43.880 So if we go back to DSW1 as an example, 00:18:43.880 --> 00:18:51.880 we should see that we no longer have any routes to 10.0.254.0 in our routing table. 00:18:52.880 --> 00:18:53.880 Before I did. 00:18:53.880 --> 00:18:57.880 So if I come back up here, 10.0.254.0 was in my routing table. 00:18:57.880 --> 00:18:58.880 All right. 00:18:58.880 --> 00:19:03.880 So now that we have that done, let's go ahead and go to R1. 00:19:04.880 --> 00:19:14.880 And on R1, I'm going to type in show IP interface brief. 00:19:15.880 --> 00:19:16.880 All right. 00:19:16.880 --> 00:19:18.880 So right now we have these different physical interfaces. 00:19:18.880 --> 00:19:26.880 Fastethernet 0.0.0.0 is going to be the physical interface that we use to go onto the Internet. 00:19:26.880 --> 00:19:30.880 And so if we go to branch and take a peek at its interfaces, show IP interface brief, 00:19:30.880 --> 00:19:32.880 we're going to see the same thing here. 00:19:32.880 --> 00:19:36.880 This is going to be our physical interface that we're going to be using to get to the Internet. 00:19:36.880 --> 00:19:42.880 This is important because that IP address we need for our GRE configuration. 00:19:42.880 --> 00:19:46.880 So I need the IP address of the interfaces connected to the Internet for this to work. 00:19:48.880 --> 00:19:51.880 So going back to R1, I'm going to type in configure terminal. 00:19:51.880 --> 00:19:53.880 We'll type in interface tunnel. 00:19:53.880 --> 00:19:58.880 And I'm going to create tunnel number 0 here today for my demonstration. 00:19:59.880 --> 00:20:03.880 So this is a virtual interface, a tunnel interface. 00:20:03.880 --> 00:20:05.880 Now, notice the tunnel is down. 00:20:05.880 --> 00:20:08.880 And that makes sense because we haven't done any configuration right now. 00:20:08.880 --> 00:20:14.880 What we're going to do is we are now going to give the tunnel its own private IP address. 00:20:14.880 --> 00:20:23.880 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. 00:20:23.880 --> 00:20:25.880 So we're going to type in IP address. 00:20:25.880 --> 00:20:27.880 And what did we say we were going to use on our other diagram? 00:20:27.880 --> 00:20:40.880 We said 172.20.1.1.255.255.255.252. 00:20:40.880 --> 00:20:47.880 So the other side is going to be 172.20.1.2.30. 00:20:49.880 --> 00:20:53.880 Now I want to specify the source of the tunnel. 00:20:54.880 --> 00:20:58.880 So we're going to say, oh, sorry, before I do that, one thing, the mode of the tunnel. 00:20:58.880 --> 00:20:59.880 Let's do that first. 00:20:59.880 --> 00:21:10.880 So tunnel mode, you'll see that Cisco tunnel interfaces can operate in many, many, many, many, many, many different modes. 00:21:13.880 --> 00:21:15.880 We are dealing with GRE. 00:21:17.880 --> 00:21:20.880 You'll notice that I can do GRE IP. 00:21:20.880 --> 00:21:26.880 So that would be where the underlying network is IPv4. 00:21:26.880 --> 00:21:30.880 So I'm running GRE on top of an IPv4 network. 00:21:30.880 --> 00:21:34.880 And that's what we're doing here, GRE on top of an IPv4 network. 00:21:34.880 --> 00:21:36.880 You could do GRE on top of an IPv6 network. 00:21:36.880 --> 00:21:43.880 So if you were creating a GRE tunnel over the IPv6 internet, then you would do GRE over IPv6. 00:21:44.880 --> 00:21:50.880 Multipoint, this is for DMVPNs over the internet, as an example. 00:21:50.880 --> 00:22:01.880 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. 00:22:01.880 --> 00:22:04.880 So there's spoke one, spoke two, spoke three. 00:22:06.880 --> 00:22:10.880 Those would be your branch offices, branch offices. 00:22:10.880 --> 00:22:23.880 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. 00:22:23.880 --> 00:22:24.880 That's what that is. 00:22:24.880 --> 00:22:32.880 So that is for DMVPNs, dynamic multipoint VPNs using GRE, as well as GRE over IPv6. 00:22:32.880 --> 00:22:45.880 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. 00:22:45.880 --> 00:22:54.880 I get into DMVPNs in that course, so I definitely encourage you to take advantage of that. 00:22:54.880 --> 00:23:04.880 Right, so if you go to the Anarsi course, this is actually Anarsi version 1.0, but Anarsi version 1.1 also has it. 00:23:04.880 --> 00:23:07.880 But you go to Anarsi version 1.1 would be the better option. 00:23:07.880 --> 00:23:10.880 I just haven't loaded into my account yet. 00:23:10.880 --> 00:23:19.880 And you'll see that there is a discussion on DMVPNs called DMVPN Configuration and Verification, and then DMVPN IPsec Configuration and Verification. 00:23:20.880 --> 00:23:25.880 So if you're ever interested in DMVPNs for your environment, they're awesome, by the way. 00:23:25.880 --> 00:23:28.880 I encourage you to check that out, take a peek at that. 00:23:28.880 --> 00:23:33.880 So tunnel mode is imperative here, especially for the certification exam. 00:23:33.880 --> 00:23:35.880 So you have to understand what is the underlying network. 00:23:35.880 --> 00:23:39.880 If the underlying network's IPv4, then it's GRE IP. 00:23:39.880 --> 00:23:43.880 If the underlying network's IPv6, then it's GRE IPv6. 00:23:43.880 --> 00:23:44.880 That's it. 00:23:45.880 --> 00:23:50.880 What I also want to point out to you is that this right here, tunnel mode GRE IP, that's the default. 00:23:50.880 --> 00:23:52.880 So you don't have to type this in at all. 00:23:52.880 --> 00:23:55.880 It defaults to using that. 00:24:00.880 --> 00:24:05.880 All right, now for the certification exam, if you ever had to configure a tunnel, I want you to be careful. 00:24:05.880 --> 00:24:06.880 Why? 00:24:06.880 --> 00:24:14.880 Because you don't know if there's already that tunnel already previously configured, like partially configured in a simulation. 00:24:14.880 --> 00:24:18.880 Because Cisco might ask you to do a simulation, but partially configure it. 00:24:18.880 --> 00:24:26.880 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? 00:24:26.880 --> 00:24:28.880 So you go ahead and type Interface Tunnel 0. 00:24:28.880 --> 00:24:35.880 But what they've done is they've actually preconfigured that, and they put the wrong mode in. 00:24:35.880 --> 00:24:42.880 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. 00:24:42.880 --> 00:24:43.880 Why? 00:24:43.880 --> 00:24:48.880 Because what if they preconfigured the interface with the wrong tunnel mode just to mess you up? 00:24:48.880 --> 00:24:50.880 So always verify that. 00:24:50.880 --> 00:24:54.880 Type in Do Show Interface Tunnel 0, and find out. 00:24:54.880 --> 00:24:56.880 Oops, Show Run, sorry. 00:24:56.880 --> 00:25:02.880 Show Run Interface Tunnel 0, and find out, did they change the mode? 00:25:02.880 --> 00:25:05.880 If there's no mode listed, it's GRE over IP. 00:25:05.880 --> 00:25:12.880 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. 00:25:12.880 --> 00:25:21.880 If it's not GRE IP, then type in the command Tunnel Mode GRE IP. 00:25:21.880 --> 00:25:22.880 So what have we done so far? 00:25:22.880 --> 00:25:26.880 We've created the tunnel. 00:25:26.880 --> 00:25:31.880 We've given it an IP address, and we've configured Tunnel Mode GRE IP. 00:25:31.880 --> 00:25:36.880 Now I need to define the source of my tunnel. 00:25:36.880 --> 00:25:37.880 So what's the source? 00:25:37.880 --> 00:25:42.880 My source is that physical interface right there, FastEthernet 0.0.0. 00:25:42.880 --> 00:25:51.880 So all I have to do is type in, in my tunnel configuration, Tunnel Source FastEthernet 0.0.0. 00:25:51.880 --> 00:25:58.880 And therefore, it'll use the IP address of that interface as the source IP of the tunnel. 00:25:59.880 --> 00:26:08.880 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. 00:26:08.880 --> 00:26:16.880 So let's go over there, and we'll copy and paste that over here onto R1, and there we go. 00:26:16.880 --> 00:26:18.880 Now what you're going to see is my tunnel go up. 00:26:18.880 --> 00:26:20.880 Now that is totally misleading. 00:26:20.880 --> 00:26:23.880 Why is that misleading? 00:26:23.880 --> 00:26:26.880 It's misleading because I haven't even configured the other side. 00:26:26.880 --> 00:26:27.880 I haven't configured the other side. 00:26:27.880 --> 00:26:28.880 How in the world is my tunnel up? 00:26:28.880 --> 00:26:29.880 That makes no sense. 00:26:29.880 --> 00:26:33.880 It really does make no sense, right? 00:26:33.880 --> 00:26:35.880 So why in the world is the tunnel up? 00:26:35.880 --> 00:26:36.880 I'll tell you why the tunnel is up. 00:26:36.880 --> 00:26:46.880 The tunnel is up because there is a route in my routing table to get to that address. 00:26:46.880 --> 00:26:48.880 That's it. 00:26:48.880 --> 00:26:59.880 There is a route in my routing table to get to that address. 00:26:59.880 --> 00:27:01.880 And what is that route? 00:27:01.880 --> 00:27:04.880 It's the default route. 00:27:04.880 --> 00:27:05.880 That's right. 00:27:05.880 --> 00:27:07.880 The default route. 00:27:07.880 --> 00:27:14.880 So as long as you have one route in the routing table to get to that destination, your tunnel goes up up. 00:27:14.880 --> 00:27:15.880 That's it. 00:27:15.880 --> 00:27:16.880 That's all. 00:27:16.880 --> 00:27:25.880 So never rely on up up for your tunnel interface to determine if it's actually working. 00:27:25.880 --> 00:27:32.880 Because right now the other side is not even configured. 00:27:32.880 --> 00:27:35.880 So it's not really up up in the grand scheme of things. 00:27:35.880 --> 00:27:37.880 But the virtual interface is. 00:27:37.880 --> 00:27:38.880 But the tunnel is not. 00:27:38.880 --> 00:27:40.880 Keep that in mind. 00:27:40.880 --> 00:27:42.880 So how do you test if the tunnel is working? 00:27:42.880 --> 00:27:48.880 You're going to ping to the other side of this tunnel and trace to the other side of this tunnel. 00:27:48.880 --> 00:27:51.880 That's what you're going to do using the private IP address. 00:27:51.880 --> 00:27:56.880 If that works, then you know the tunnel is working. 00:27:56.880 --> 00:27:57.880 So let's take a look at our config. 00:27:57.880 --> 00:28:00.880 Do show run interface tunnel zero. 00:28:00.880 --> 00:28:02.880 We have our config done here. 00:28:02.880 --> 00:28:04.880 So now we're going to go over to the other side. 00:28:04.880 --> 00:28:05.880 We've got to go to branch. 00:28:05.880 --> 00:28:09.880 And on branch, I'm going to create interface tunnel. 00:28:09.880 --> 00:28:11.880 So interface tunnel. 00:28:11.880 --> 00:28:13.880 You don't have to use the same number on the other side. 00:28:13.880 --> 00:28:15.880 But I like to use the same number. 00:28:15.880 --> 00:28:17.880 We're going to type tunnel mode GREIP. 00:28:17.880 --> 00:28:20.880 Although, again, I don't have to do that because that's the default value. 00:28:20.880 --> 00:28:25.880 It's a good habit to get into just in case on an exam they turn around and they pre-configure some things 00:28:25.880 --> 00:28:30.880 and they mess it all up ahead of time just to make you struggle on the exam. 00:28:30.880 --> 00:28:31.880 All right. 00:28:31.880 --> 00:28:32.880 What do we want now? 00:28:32.880 --> 00:28:33.880 We want our IP address. 00:28:33.880 --> 00:28:35.880 So what was the IP address on the other side? 00:28:35.880 --> 00:28:38.880 We said it was 172.21.1. 00:28:38.880 --> 00:28:46.880 So we're going to do 172.21.2 over here and 255.255.255.252. 00:28:46.880 --> 00:28:54.880 And then tunnel source for this router is going to be gigabit ethernet 0 slash 1. 00:28:54.880 --> 00:29:01.880 And then our tunnel destination is going to be the IP address of R1's interface connected to the Internet, 00:29:01.880 --> 00:29:05.880 which is this one right here. 00:29:05.880 --> 00:29:06.880 And there you go. 00:29:06.880 --> 00:29:07.880 We're done. 00:29:07.880 --> 00:29:10.880 So now I have a tunnel created between here and here. 00:29:10.880 --> 00:29:11.880 Well, no, not really, right? 00:29:11.880 --> 00:29:12.880 There's no tunnel. 00:29:12.880 --> 00:29:13.880 Remember that. 00:29:13.880 --> 00:29:14.880 All I've done is set up my router. 00:29:14.880 --> 00:29:20.880 So if traffic arrives at the router and that traffic needs to go from here over to here, 00:29:20.880 --> 00:29:25.880 it can be encapsulated, pun old, over to the other side. 00:29:25.880 --> 00:29:31.880 So let's first of all take a peek at show IP route on branch. 00:29:31.880 --> 00:29:33.880 Do we have an entry for that tunnel interface? 00:29:33.880 --> 00:29:34.880 We do. 00:29:34.880 --> 00:29:35.880 It's right there. 00:29:35.880 --> 00:29:40.880 So the tunnel is directly connected to us at 172.21.0. 00:29:40.880 --> 00:29:41.880 Go to R1. 00:29:41.880 --> 00:29:44.880 Type in show IP route. 00:29:44.880 --> 00:29:46.880 And what do we have in this particular case? 00:29:46.880 --> 00:29:50.880 We can see that we have 172.21.0. 00:29:50.880 --> 00:29:51.880 Again, tunnel 0. 00:29:51.880 --> 00:29:52.880 Perfect. 00:29:52.880 --> 00:29:53.880 Love it. 00:29:53.880 --> 00:29:54.880 So far, so good. 00:29:54.880 --> 00:29:56.880 Let's go ahead and ping through that tunnel. 00:29:56.880 --> 00:29:59.880 So 172.2. 00:29:59.880 --> 00:30:00.880 Right? 00:30:00.880 --> 00:30:01.880 So the ping worked. 00:30:01.880 --> 00:30:06.880 The question is, did the ping actually work this way, or did it actually just ping all the way around? 00:30:06.880 --> 00:30:09.880 Well, we know this is down, so we know that it did not what? 00:30:09.880 --> 00:30:12.880 We know that it did not go this way. 00:30:12.880 --> 00:30:15.880 But the best way to verify it is trace. 00:30:15.880 --> 00:30:21.880 Because if I type in 172.20.1.2, and there is just one hop, 00:30:21.880 --> 00:30:25.880 then we know that we actually used the GRE tunnel, 00:30:25.880 --> 00:30:29.880 and we did not just go to the Internet, bounce around through a bunch of routers. 00:30:29.880 --> 00:30:34.880 Because if we went to the Internet, then we'd see the router IP addresses in there. 00:30:34.880 --> 00:30:39.880 Whereas in this case, we don't, meaning we actually encapsulated it and came out the other side. 00:30:39.880 --> 00:30:40.880 So there you go. 00:30:40.880 --> 00:30:45.880 Our GRE tunnel is actually working in our particular case. 00:30:45.880 --> 00:30:49.880 So now let's run OSPF on the GRE tunnel. 00:30:49.880 --> 00:30:56.880 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. 00:30:56.880 --> 00:31:00.880 We only have the directly connected routes and the static route. 00:31:00.880 --> 00:31:07.880 So if right now we go to configure terminal interface tunnel 0, IP OSPF 1 area 0, 00:31:07.880 --> 00:31:16.880 let's go over to R1 and do the same thing, configure terminal interface tunnel 0, IP OSPF 1 area 0. 00:31:16.880 --> 00:31:18.880 What are we going to find? 00:31:18.880 --> 00:31:22.880 We're going to find we form a neighbor adjacency over the actual tunnel. 00:31:22.880 --> 00:31:36.880 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. 00:31:36.880 --> 00:31:37.880 Look at the cost. 00:31:37.880 --> 00:31:40.880 The cost is inflated. 00:31:40.880 --> 00:31:45.880 OSPF does not prefer a tunnel interface if there's another path to go. 00:31:45.880 --> 00:31:50.880 So it artificially inflates the cost really high, so it avoids it unless it's the last option available. 00:31:50.880 --> 00:31:58.880 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? 00:31:58.880 --> 00:32:06.880 We should see OSPF learned routes from the branch office now through the tunnel. 00:32:06.880 --> 00:32:24.880 So you see how we've been able to now learn about that network through our tunnel interface. 00:32:24.880 --> 00:32:40.880 Not too shabby. 00:32:40.880 --> 00:32:43.880 Now let's think about it from the perspective of R2. 00:32:43.880 --> 00:32:48.880 If we bring back up our interface on R2 now, let's bring this back up. 00:32:48.880 --> 00:32:50.880 What's going to happen? 00:32:50.880 --> 00:32:55.880 Well, we're going to form a neighbor adjacency here, and then that network is going to be successfully shared over here, 00:32:55.880 --> 00:32:59.880 and then that's going to be successfully shared up to there and so on and so forth. 00:32:59.880 --> 00:33:00.880 What does that mean? 00:33:00.880 --> 00:33:09.880 It means now under normal conditions, we're going to go which way in order to get to that particular network? 00:33:09.880 --> 00:33:13.880 Well, we're going to take the path through our environment. 00:33:14.880 --> 00:33:27.880 So, for example, if I went to R1 right now, you're going to see that we prefer 10.0.254.0 via what? 00:33:27.880 --> 00:33:30.880 Going this way right now. 00:33:30.880 --> 00:33:32.880 Going that way. 00:33:32.880 --> 00:33:33.880 Why? 00:33:33.880 --> 00:33:34.880 Because that would be a lower cost. 00:33:34.880 --> 00:33:36.880 Look, the cost is 22 right now, right? 00:33:36.880 --> 00:33:41.880 So if this is our WAN connection, a higher speed WAN connection, more expensive WAN connection, 00:33:41.880 --> 00:33:45.880 more stable WAN connection, we could use that as a primary path. 00:33:45.880 --> 00:33:52.880 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. 00:33:52.880 --> 00:33:54.880 So this is an option you have. 00:33:54.880 --> 00:33:57.880 So if you want to do like a primary, secondary, you can. 00:33:57.880 --> 00:34:02.880 If you just want to use GRE and no longer pay for your WAN connection, you can do that as well. 00:34:02.880 --> 00:34:04.880 Many different opportunities here. 00:34:04.880 --> 00:34:08.879 But let's go back to R2 and let's bring this down. 00:34:09.879 --> 00:34:13.879 Then what we're going to eventually see is that we're going to be updated here. 00:34:13.879 --> 00:34:18.879 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. 00:34:18.879 --> 00:34:24.879 Look, the cost is a lot higher in that particular scenario. 00:34:24.879 --> 00:34:32.879 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. 00:34:32.879 --> 00:34:35.879 So I do have in the slides the configurations. 00:34:35.879 --> 00:34:55.879 Listen to the slides if you ever want to go back and review them. 00:34:55.879 --> 00:35:03.879 When you look at this output here, again, if it says up-up, that just means the virtual interface is up-up. 00:35:03.879 --> 00:35:05.879 It doesn't mean your tunnel is actually working. 00:35:05.879 --> 00:35:08.879 You want to test the tunnel, you're going to have to ping it, you're going to have to trace it. 00:35:08.879 --> 00:35:11.879 If you need to verify the address, you can verify it here. 00:35:11.879 --> 00:35:14.879 Notice the bandwidth is set to 100 kilobits per second by default. 00:35:14.879 --> 00:35:19.879 That's why OSPF has such a high cost for it automatically. 00:35:19.879 --> 00:35:26.879 Notice that the encapsulation is tunnel, in this case, GRE over IP tunnel. 00:35:26.879 --> 00:35:30.879 And so anything I'm highlighting are things I want you to remember for the certification exam. 00:35:30.879 --> 00:35:31.879 What else do we have? 00:35:31.879 --> 00:35:33.879 We have our tunnel source. 00:35:33.879 --> 00:35:40.879 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. 00:35:40.879 --> 00:35:47.879 And then the destination, you put it in, it will specify the destination. 00:35:47.879 --> 00:35:50.879 This here is not really the MTU. 00:35:50.879 --> 00:35:53.879 That's not really the MTU. 00:35:53.879 --> 00:35:55.879 That's just a virtual MTU. 00:35:55.879 --> 00:35:58.879 The real MTU here is down at the bottom. 00:35:58.879 --> 00:36:00.879 This is your tunnel transport MTU. 00:36:00.879 --> 00:36:05.879 This is the one right here, 1476 that we talked about before. 00:36:17.879 --> 00:36:24.879 This was R1. 00:36:24.879 --> 00:36:25.879 Let me see here. 00:36:25.879 --> 00:36:27.879 What else do I want to talk about? 00:36:27.879 --> 00:36:35.879 This is still R1. 00:36:35.879 --> 00:36:39.879 So something to keep in mind here, you'll see that keepalives are not set. 00:36:39.879 --> 00:36:41.879 What does that mean? 00:36:41.879 --> 00:36:47.879 By default, there is no way to track whether your tunnel is working or not. 00:36:47.879 --> 00:36:48.879 Why? 00:36:48.879 --> 00:36:56.879 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? 00:36:56.879 --> 00:36:58.879 Your tunnel is going to be up, up. 00:36:58.879 --> 00:37:02.879 But there's no way to constantly track that tunnel destination. 00:37:02.879 --> 00:37:06.879 Could you use something like IPSLA, generate a little ping and test that? 00:37:06.879 --> 00:37:08.879 You can do stuff like that. 00:37:08.879 --> 00:37:14.879 But we do have built-in keepalives that I want you to know about for the certification exams. 00:37:14.879 --> 00:37:17.879 So keepalive is not set. 00:37:17.879 --> 00:37:18.879 So that's the default. 00:37:18.879 --> 00:37:23.879 Default equals not set. 00:37:23.879 --> 00:37:30.879 Now, if you turn on keepalives, so when you turn them on, the default is going to be what? 00:37:30.879 --> 00:37:43.879 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. 00:37:43.879 --> 00:37:57.879 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. 00:37:57.879 --> 00:37:59.879 If I don't get a response, then I'll try another one 10 seconds later. 00:37:59.879 --> 00:38:02.879 If I don't get a response, that's after three retries. 00:38:02.879 --> 00:38:08.879 So if three retries, I don't get a response, then the tunnel comes down. 00:38:08.879 --> 00:38:21.879 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. 00:38:22.879 --> 00:38:28.879 So therefore, your local tunnel interface is always going to be up, up as long as you have that route to the destination IP. 00:38:28.879 --> 00:38:39.879 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. 00:38:39.879 --> 00:38:43.879 If the other side is not available, then this side can go down. 00:38:43.879 --> 00:38:49.879 Right, if you want this more aggressive, you can change those values. 00:38:49.879 --> 00:38:52.879 Now, I want to talk about the recursive error. 00:38:52.879 --> 00:38:54.879 What is a recursive error? 00:38:54.879 --> 00:38:58.879 Well, if you ever see this, look what it says here. 00:38:58.879 --> 00:39:00.879 Line protocol up down. 00:39:00.879 --> 00:39:02.879 Line protocol interface tunnel zero is up. 00:39:02.879 --> 00:39:06.879 And then it says tunnel five recur down. 00:39:06.879 --> 00:39:10.879 Tunnel zero temporarily disabled due to recursive routing. 00:39:10.879 --> 00:39:13.879 Then it says tunnel is down. 00:39:13.879 --> 00:39:15.879 Then the tunnel comes up. 00:39:15.879 --> 00:39:20.879 Then it says tunnel is disabled due to recursive routing. 00:39:20.879 --> 00:39:22.879 Therefore, the tunnel is down. 00:39:27.879 --> 00:39:31.879 When does this happen? 00:39:31.879 --> 00:39:59.879 This occurs when the tunnel destination is reachable through the actual tunnel itself. 00:40:00.879 --> 00:40:02.879 So picture this. 00:40:02.879 --> 00:40:28.879 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, 00:40:29.879 --> 00:40:37.879 the physical interface network is injected into OSPF. 00:40:40.879 --> 00:40:45.879 It will then be shared through the tunnel. 00:40:45.879 --> 00:40:49.879 So the router on the other side learns about that through the tunnel. 00:40:49.879 --> 00:40:57.879 Likewise, on the other side, the tunnel physical interface will be shared over here. 00:40:58.879 --> 00:41:20.879 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, 00:41:21.879 --> 00:41:25.879 the network ID of that interface gets injected into OSPF. 00:41:25.879 --> 00:41:27.879 It gets shared across the tunnel. 00:41:27.879 --> 00:41:41.879 Now this router branch A says, oh, the destination is reachable through the tunnel and no longer out the actual interface. 00:41:44.879 --> 00:41:49.879 So what that means is that we have recursive routing. 00:41:50.879 --> 00:41:53.879 I have learned about the destination through the tunnel. 00:41:53.879 --> 00:41:57.879 So what that does is it tears down the tunnel because that is wrong. 00:41:57.879 --> 00:42:02.879 You can't learn about the physical tunnel destination through the virtual tunnel. 00:42:03.879 --> 00:42:05.879 That can happen. 00:42:11.879 --> 00:42:16.879 So as a result of that, it waits a bit and it comes up again. 00:42:16.879 --> 00:42:18.879 And then what happens? 00:42:18.879 --> 00:42:21.879 It learns about the destination through the tunnel again. 00:42:21.879 --> 00:42:23.879 So what's the problem here? 00:42:23.879 --> 00:42:30.879 The problem is you enabled the routing protocol on the physical tunnel interface. 00:42:31.879 --> 00:42:33.879 That can't happen. 00:42:33.879 --> 00:42:34.879 That can't happen. 00:42:34.879 --> 00:42:41.879 So if you enabled EIGRP on the actual physical tunnel interface, you'd have recursive routing. 00:42:41.879 --> 00:42:45.879 If you enabled OSPF on the physical, you'd have recursive routing and so on and so forth. 00:42:46.879 --> 00:42:52.879 So for example, if you were the type of person to use the network command for OSPF, 00:42:52.879 --> 00:43:02.879 network 0.0.0.0, 255, 255, 255, 255, area, whatever, you would always have recursive routing with GRE and it wouldn't work. 00:43:02.879 --> 00:43:07.879 Because you will always end up learning the physical interface through the tunnel. 00:43:07.879 --> 00:43:13.879 So you can't have your dynamic routing protocol running on that physical tunnel interface. 00:43:13.879 --> 00:43:16.879 Only the virtual tunnel interface for this to work. 00:43:16.879 --> 00:43:18.879 Keep that in mind for the certification exam. 00:43:22.879 --> 00:43:23.879 All right. 00:43:23.879 --> 00:43:24.879 So that is GRE. 00:43:24.879 --> 00:43:25.879 Make sure you can configure it. 00:43:25.879 --> 00:43:27.879 Make sure you can verify it. 00:43:27.879 --> 00:43:29.879 Make sure you know the things I pointed out to you. 00:43:29.879 --> 00:43:31.879 Make sure you can ping. 00:43:31.879 --> 00:43:32.879 You can trace route across it. 00:43:32.879 --> 00:43:39.879 Oh, and don't forget, you can also place a tunnel interface in what? 00:43:39.879 --> 00:43:44.879 A VRF, as we talked about at the very end of our VRF discussion. 00:43:44.879 --> 00:43:47.879 So keep that in mind for the exam as well.