The advantages provided by GRE tunnelling (or any kind of network tunnelling) is that it allows us to interconnect two remote sites over a third network as if those remote sites are directly connected to each other. So let’s say you have two branch offices, one in one city and one in another. You have a subnet of 192.168.1.0/24 at the first office and 192.168.2.0/24 at the second office. Those two offices will never be able to communicate directly with each other over the Internet, because the Internet uses its own IP address ranges and it does not allow the use of private IP addresses to be routed using static and dynamic routing.
However, you can create a GRE tunnel between the edge routers at each branch office. The packets addressed in the 192.168.1.0/24 and 192.168.2.0/24 address ranges will then be tunnelled or encapsulated into IP packets that can be routed over the Internet. Once they arrive at the other edge router, they will be decapsulated and sent onto the local network. In this way, hosts at each branch office will think that the two edge routers are directly connected to each other, allowing you to enable communication between the two offices as if they were really directly connected to each other.
So in summary, a tunnel will allow you to route your private packets over a public or third party network such as the Internet, in such a way so that your networks function as if they are directly connected to each other.
I have a question about the static route
Is there a difference between:
1-ip route 192.168.23.3 255.255.255.255 192.168.12.2
2-ip route 0.0.0.0 0.0.0.0 192.168.12.2
I think if we use the first one we can only connect to 192.168.23.3, so we use the ISP to connect the HQ and Branch only
But if we use the default static route we can also connect to the Internet.
Yes you are correct. Both static routes will indeed allow you to reach the 192.168.23.3 subnet, while the default route will also allow you to reach the Internet as well. In the particular example, connectivity to the Internet was not a requirement, so it wasn’t configured that way, but it will indeed work.
Is it possible to do this all in IPv6? I notice there is a lot of IPv6 Over IPv4 tunnels, but I am wondering if this is possible to do in IPv6 only (for testing purposes).
Yes it is possible to create GRE tunnels using IPv6 for both the internal and external protocol. You can find out more information about this at the following Cisco documentation:
Now in the examples found in there, some implement IPv6 over an IPv4 GRE tunnel. However, IPv6 can be used for both inside and outside of the GRE tunnel.
hello lagapides
can i use eigrp instead a static route
like rene have used EIGRP for introduce a network which is running on HQ and same apply in BRANCH office but why he has not introduced a 192.168.12.0 or 192.168.23.0 in EIGRP
This is a very good question, and indeed an important one. Rene could have included those networks in EIGRP, however, the problem that would occur is that EIGRP would learn of a “better” route between the Branch to HQ routers via the GRE tunnel. But that means that routes to 192.168.12.0 or 192.168.23.0 would be removed from the routing table in favour of the route via the GRE tunnel. But those routes are needed in order to correctly route the GRE tunnel, so the tunnel would fail. This results in the routes being reinstated only to have the tunnel come back up again and the routing changes again, and it fails… and so on. This is called the GRE tunnel recursive routing error, and you can find out more about it (and how to solve it) in this lesson:
GRE and IPSec are used in the real world as VPN solutions especially if you want to run a routing protocol (IPsec alone does not support multicast). Now if you want to use a GRE tunnel as a backup to a main link, you don’t need to have it enabled or automatically turn it on as you need it.
You just need to configure it and make it a backup choice using routing or IP SLA. Normally, a GRE tunnel will come up as soon as it is configured and it will stay up as long as there is a valid tunnel source address or interface that is also up, and as long as the destination IP address is routable.
For this reason, GRE uses keepalives to check on the state of the other end of the link. You can find out more about keepalives and GRE and IPSec at the following link.
I hope I have understood your initial question, but if you need more information, please clarify what it is you want to achieve so we can help you further.
Iam running EIGRP in a Ethernet Private Line (Its only 2 routers) , if I understand I have to configure GRE and IPSec, but how the routers are going to make the decision to use GRE when EPL fails?
I apologize, I’m probably missing something here. Do you have alternate links connecting to your router? Can you please share your topology with us to clarify?
Hello.
What is the best right answer for question below:
“which feature can mitigate fragmentation issues whithin network segment that are between GRE endpoints?”
I cann’t choose between PMTUD and TCP MSS. As for me the best is TCP MSS. Anybody clear clarify?
If you use “ip tcp adjust-mss” on interface its going to intercept only TCP segments with SYN flag, thus this fixes only TCP traffic.
However if you use PMUTD it can fix TCP and also UDP, but you need to be sure that ICMP messages are not filtered, at least unreachables and time-exceeded should be allowed for PMUTD.
But may be you want to enable MTU discovery for GRE path itself? This is done using “tunnel path-mtu-discovery”.
Here is my topology, Active routing protocol is EIGRP, I wanted to know how to configure GRE+IPSec to be active using the Public Address when EIGRP fails.
Yes, I understand, thank you. This setup is somewhat complex compared to a routing change or a simple IP SLA. Here you need to detect an event, such as the loss of connectivity, and implement a change in the configuration that will enable the GRE IPSec tunnel. You can’t have both running at the same time and if one fails, the other takes over automatically.
The first thing that comes to mind is to use Cisco IOS Embedded Event Manager (EEM). This will allow you to detect events and then run scripts that will implement particular configuration changes. In this case, you can set up an IP SLA, and if connectivity is lost, this event can trigger changes in the configuration to enable the tunnel. You can find out more about the EEM feature at the following lesson:
I agree with you. But this question I’ve found on example of practice exam. Here it is:
Q.: Which feature can mitigate fragmentation issues within network segments that are between GRE endpoint?
Possible answers:
Hello Boris,
because option 2 specifically mentions DF bit i would go with it.
Its important to copy DF bit from inside IP header to outside IP header.
Hello Boris,
if you want to get rid of fragmentation after GRE encapsulation you have to enable “tunnel path-mtu-discovery”. This command allows you to copy DF bit value from inside IP header to outside IP header, thus allowing you to discover MTU on tunnel path itself.
For your question is 1) PMUTD good answer, but because of option 2) is mentioning DF bit it makes it more specific answer, thus making it even better answer.
