GRE Point-To-Point Configuration

So Today I have sometime to write about the GRE Fundamentals and how it works.

Let’s get started!

The Generic Encapsulation Protocol (GRE) it’s the IP protocol number 47 and it’s beauty relies in the fact that it allows to encapsulate a different variety of IP network layer protocols into a GRE Tunnel.

When do we need to run GRE tunnels?

There might be times where you cannot send “X” protocol over a network cause it’s not supported or even allowed.

With GRE you could send the “X” protocol encapsulated into a GRE header in order to let it go through.

Configuration Fundamentals:

Point-To-Point-GRE Tunnel Scenario

Screen Shot 2015-07-15 at 9.54.03 AM

In this lab we have LAN-A and LAN-B separated by an ISP.

We want to communicate between those 2 subnets using a Routing Protocol but the ISP is not willing to run a Dynamic Routing Protocol.

GRE is here to save us! We can build a GRE tunnel between R1 and R3 and then inside that GRE tunnel run a Dynamic Routing Protocol.

Let’s do it

First R1:

interface Tunnel1

ip address 1.1.1.1 255.255.255.252

tunnel source FastEthernet0/0

tunnel destination 3.3.3.1

Next R3:

interface Tunnel1

ip address 1.1.1.2 255.255.255.252

tunnel source 3.3.3.1

tunnel destination 2.2.2.1

 NOTE: For this to work connectivity between 2.2.2.1 and 3.3.3.1 MUST exist (Otherwise the tunnel will never come up).

Verification commands:

R3#sh ip int brief | ex unassigned 

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            3.3.3.1         YES manual up                    up      

Loopback1                  192.168.20.1    YES manual up                    up      

Tunnel1                    1.1.1.2         YES manual up                    up

Now let’s get the routing over the tunnel configured in such a way both Subnets are reachable through the tunnel interface 1.

R1

router ospf 1

log-adjacency-changes

network 1.1.1.0 0.0.0.3 area 0

network 192.168.10.0 0.0.0.255 area 0

R3

router ospf 10

log-adjacency-changes

network 1.1.1.0 0.0.0.3 area 0

network 192.168.20.0 0.0.0.255 area 0

Afterwards we can see the OSPF neighbor relationship is formed and both routers know that to reach each other Subnets need to send the traffic via the tunnel.

R1#sh ip ospf  neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.20.1      0   FULL/  -        00:00:37    1.1.1.2         Tunnel1

R1#sh ip route 192.168.20.0

Routing entry for 192.168.20.0/32, 1 known subnets

O       192.168.20.1 [110/11112] via 1.1.1.2, 03:17:29, Tunnel1

R3#sh ip ospf  neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.10.1      0   FULL/  -        00:00:37    1.1.1.1         Tunnel1

R3#sh ip route 192.168.10.0

Routing entry for 192.168.10.0/32, 1 known subnets

O       192.168.10.1 [110/11112] via 1.1.1.1, 03:18:07, Tunnel1

Finally let’s test the reachability between both sites

R3#ping 192.168.10.1 source 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.20.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/41/48 ms

That’s it! Reachability has been tested through a GRE tunnel that is tunnelling OSPF packets.

Regards,

Jcarvaja