| MixedNetworks

No Category

May 20, 2020

EXAM TOPIC

2.0 Virtualization
- 2.2 Configure and verify data path virtualization technologies
  - 2.2.a GRE and IPsec tunneling

VIDEO OVERVIEW

OVERVIEW

In this section we take a look at GRE (Generic Routing Encapsulation).

GRE, as you’ve already seen, stands for Generic Routing Encapsulation. What this is allows us to do is encapsulate packets inside another packet that then allows them to be forwarded over an IP network.

A good example of this being below.

Here we’ve got two sites connected to the internet via an ISP, Site A and Site B. As both sites are connected to the internet and not directly connected via MPLS or other means – it means that at present, Sites A’s subnet of 192.168.10.0/24 is unable to route to Site B’s 192.168.20.0/24 across the internet to communicate or exchange routing information.

The reason for this is that we cannot route our private addresses across the internet.

One of the ways of working around this could be to use a GRE tunnel.

What this will do is allow us to create a point to point connection between Site A and Site B. The GRE tunnel will allow the two sites to communicate with each other as if they where directly connected, forming a logical tunnel between the two and acting if they’re layer 2 adjacent.

The traffic is now able to be routed across the internet as the traffic will be routed via a new GRE packet that includes the original packet within it, allowing it to be routed.

To give you an understanding of how this looks. Below displays an example of an original IP packet, before we’ve encapsulated it with GRE.

This is then how the packet would then look once it’s been encapsulated within GRE.

BENEFITS

GRE tunnels provide us a number of benefits:

Defined as an RFC standard – RFC2784.
- Although GRE was created by Cisco, the standard can be used by multiple vendors.
- Great thing about being supported by multiple vendors is that we can create GRE tunnels between devices of multiple vendors.

Supports the use of Unicast, Multicast and Broadcast traffic.
- What this allows us to do is run routing protocols across our GRE tunnel to form a neighbour relationship.

GRE Tunnels are simple and easy to deploy.
- You’ll see in the configuration section below that the configuration for our GRE tunnels are super simple and easy to create.

DISADVANTAGES

Traffic is not encrypted by default.
- By default, traffic traversing our GRE tunnel is not encrypted – instead traffic is sent via clear text.
- To resolve this, we need to use IPsec in addition to our GRE tunnel.

GRE tunnels are not scalable.
- GRE tunnels have to be created manually with each tunnel requiring a source, destination and IP address.
- If we have a number of GRE tunnels within our network, these can start to become difficult to manage

CONFIGURATION

So now we understand GRE tunnelling, lets take a look at how we can configure them on our Cisco devices.

We’re going to be using the example we looked at earlier for our GRE lab.

So you can see we have two sites connected to our ISP, both with public IP addresses at each location.

Each of our locations has its own network. At Site A we’re using 192.168.10.0/24 and at Site B we’re using 192.168.20.0/24.

What we’re going to do is create a GRE tunnel between the two sites to connect them and allow them to act as if they’re directly connected.

For the tunnel itself we need an IP for each end on the same subnet. As such, in this scenario we’re going to be using 172.16.0.0/24.

The first thing we need to do is configure our interfaces on the following routers:

ISP
SITE_A
SITE_B

ISP#configure terminal
ISP(config)#interface Serial2/0
ISP(config-if)#ip address 32.113.43.2 255.255.255.248
ISP(config-if)#no shutdown
ISP(config-if)#exit
ISP(config)#interface Serial2/1
ISP(config-if)#ip address 82.122.36.2 255.255.255.248
ISP(config-if)#no shutdown

SITE_A#configure terminal
SITE_A(config)#interface Serial2/0
SITE_A(config-if)#ip address 32.113.43.1 255.255.255.248
SITE_A(config-if)#no shutdown
SITE_A(config-if)#exit
SITE_A(config)interface loopback 0
SITE_A(config-if)#ip address 172.16.0.1 255.255.255.0
SITE_A(config-if)#exit
SITE_A(config)#ip route 0.0.0.0 0.0.0.0 32.113.43.2

SITE_B#configure terminal
SITE_B(config)#interface Serial2/1
SITE_B(config-if)#ip address 82.122.36.1 255.255.255.248
SITE_B(config-if)#no shutdown
SITE_B(config-if)#exit
SITE_B(config)#interface loopback 0
SITE_B(config-if)#ip address 172.16.0.2 255.255.255.0
SITE_B(config-if)#exit
SITE_B(config)#ip route 0.0.0.0 0.0.0.0 82.122.36.2

Now that we’ve got our basic configuration on our devices, the first thing we need to do is confirm we can route between Site A and Site B over the internet.

SITE_A#ping 82.122.36.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 82.122.36.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/1 ms

Now we’ve confirmed routing between our public interfaces from Site A to Site B, lets get into the configuration of our GRE tunnel.

SITE_A#configure terminal
SITE_A(config)#interface tunnel 1
SITE_A(config-if)#tunnel source Serial2/0
SITE_A(config-if)#tunnel destination 82.122.36.1
SITE_A(config-if)#ip address 172.16.0.1 255.255.255.0

SITE_B#configure terminal
SITE_B(config)#interface tunnel 1
SITE_B(config-if)#tunnel source Serial2/2
SITE_B(config-if)#tunnel destination 32.113.43.1
SITE_B(config-if)#ip address 172.16.0.2 255.255.255.0

Now that’s been completed, that’s all of the configuration required for our GRE tunnel.

As such, the next thing we need to do is confirm our GRE tunnel is now up and active.

SITE_B# show interface tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.0.2/24
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 82.122.36.1 (Serial2/1), destination 32.113.43.1
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled

We can see here that the interface we created it in an up state and is a GRE tunnel.

The next thing we need to do is ping the remote end of the GRE tunnel to confirm we have routing via the GRE tunnel.

SITE_B#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms

Here we can see that we can now route across our GRE tunnel.

SITE_B#traceroute 172.16.0.1
Type escape sequence to abort.
Tracing the route to 172.16.0.1
  1 172.16.0.1 40 msec 40 msec 44 msec

If we do a traceroute from Site B across to Site A, you’ll see that we only have 1 hop

From the perspective of our site routers, they act like they’re directly connected – this is where it gets the tunnelling name from.

In reality, the packets are routing via the ISP between the sites – but encapsulated within the GRE packets, as we discussed earlier.

Now we’ve got our tunnel up between Site A and Site B, we still cannot route between the local subnets – which is what we’re trying to achieve.

SITE_A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 32.113.43.2 to network 0.0.0.0

     32.0.0.0/29 is subnetted, 1 subnets
C       32.113.43.0 is directly connected, Serial2/0
C    192.168.10.0/24 is directly connected, Loopback0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, Tunnel1
S*   0.0.0.0/0 [1/0] via 32.113.43.2

SITE_A#ping 192.168.20.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.254, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

You can see here if we try to ping the subnet at Site B from Site A, our packets are undeliverable. The reason for this is that our routers would try to route this via their default static route, which is via our ISP.

Now we’ve got our GRE tunnel up and active, we’ve got two ways of routing between the subnets at both of our sites.

Create static routes for the subnets to route via the GRE tunnel.
Setup a routing protocol between Site A and Site B, via the GRE tunnel.

As GRE tunnels allow the use of multicast and broadcast traffic, one of the benefits of using GRE tunnels is that we can use routing protocols across it. As such, we’ll setup some basic EIGRP configuration between Site A and Site B.

SITE_A#configure terminal
SITE_A(config)#router eigrp 10
SITE_A(config-router)#network 192.168.10.0 0.0.0.255
SITE_A(config-router)#network 172.16.0.0 0.0.0.255

SITE_B#configure terminal
SITE_B(config)router eigrp 10
SITE_B(config-router)#network 192.168.20.0 0.0.0.255
SITE_B(config-router)#network 172.16.0.0 0.0.0.255

We can see now, that our two routers have formed an EIGRP neighbour relationship across the GRE tunnel.

SITE_A#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.0.2              Tu1               13 00:01:22   35  5000  0  3

What should now have also learned the local subnets across the tunnel, via EIGRP.

Let’s take a look at the routing table on Site A.

SITE_A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 32.113.43.2 to network 0.0.0.0

     32.0.0.0/29 is subnetted, 1 subnets
C       32.113.43.0 is directly connected, Serial2/0
C    192.168.10.0/24 is directly connected, Loopback0
     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.0.0/24 is directly connected, Tunnel1
D       172.16.0.0/16 is a summary, 00:06:14, Null0
D    192.168.20.0/24 [90/297372416] via 172.16.0.2, 00:05:51, Tunnel1
S*   0.0.0.0/0 [1/0] via 32.113.43.2

Here we can see now that we’ve learned Site B’s 192.168.20.0/24 subnet across the GRE tunnel via EIGRP.

If I do a ping to this from Site A, we can confirm we can now route to site B’s local subnet across the tunnel.

SITE_A#ping 192.168.20.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/32/40 ms

Success!

RECURSIVE ROUTING

So here you can see our current configuration for our GRE lab.

In our current setup, we’re running EIGRP (process 10) across our GRE tunnel and advertising our local subnet at each branch and the tunnel interface.

One problem that can occur if we’re not careful with the routes we advertise across the tunnel is an issue called Recursive Routing.

To explain this a little easier, lets take a look at our setup at the moment.

Site A knows at the moment, to terminate the end of the GRE tunnel it needs to route to site B’s public IP address, via the ISP.

What happens if we accidentally advertise our public interface at site B across the tunnel?

In the example above, you can see that we’re now advertising our public network at site B via EIGRP.

Site A will then learn this route via EIGRP.

SITE_A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 32.113.43.2 to network 0.0.0.0

     32.0.0.0/29 is subnetted, 1 subnets
C       32.113.43.0 is directly connected, Serial2/0
C    192.168.10.0/24 is directly connected, Loopback0
     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.0.0/24 is directly connected, Tunnel1
D       172.16.0.0/16 is a summary, 00:00:04, Null0
D    82.0.0.0/8 [90/297756416] via 172.16.0.2, 00:00:03, Tunnel1
D    192.168.20.0/24 [90/297372416] via 172.16.0.2, 00:00:03, Tunnel1
S*   0.0.0.0/0 [1/0] via 32.113.43.2

As this route is more specific than our default route (0.0.0.0) via our ISP, Site A will try to route to the public IP address of site B, via the GRE tunnel.

The problem with this is that we cannot route to the public IP address via the GRE tunnel. As such, the tunnel drops.

What happens when the GRE tunnel drops? The route we learned via the GRE tunnel that caused the tunnel to drop is removed from our routing table.

As such, Site A can again route to Site B via its public IP address and form a GRE tunnel between the sites.

What happens when our tunnel is formed? Again, we’ll learn the public IP address of site B via the GRE tunnel and the tunnel drops again.

We’re now stuck in a situation where the GRE tunnel is stuck constantly coming online and then dropping offline.
This is known as Recursive Routing.

The way of avoiding/resolving the issue is to NOT advertise the public interfaces across the GRE tunnel.

#GRE

Comments are closed