GRE Tunnels and VRFs

Wed 23 January 2019
Tunnel

GRE Tunnelling. It's a tool that should be in every network engineer's toolbox, but not one we like to use very often.

But sometimes, it's needed. Sometimes you need to just make something work, across somebody else's network. This week's task is to do just that, in support of an office migration for a client.

So, let's have a look at how GRE works, and how it can work in a multi-VRF environment.

To talk through this, we'll use two routers connected together in GNS3, like this:

GRE Topology

We need to route between the two customer subnets, but those IP's are not reachable across the transit. So we create a tunnel.

On R1:

Router#conf
Configuring from terminal, memory, or network [terminal]? t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#hostname R1
R1(config)#int lo0
R1(config-if)#ip address 192.168.1.1 255.255.255.255
R1(config-if)#int gi0/0
R1(config-if)#ip addres 192.168.0.1 255.255.255.0
R1(config-if)#ip route 192.168.2.2 255.255.255.255 192.168.0.2
R1(config)#int lo99
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#int tunnel0
R1(config-if)#tunnel mode gre ip
R1(config-if)#tunnel source lo0
R1(config-if)#tunnel dest 192.168.2.2
R1(config-if)#ip route 10.1.1.0 255.255.255.0 tunnel0
R1(config)#int tunn0
R1(config-if)#ip address 169.254.254.1 255.255.255.252
R1(config-if)#

And on R2:

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#hostname R2
R2(config)#int lo0
R2(config-if)#ip address 192.168.2.2 255.255.255.255
R2(config-if)#int gi0/0
R2(config-if)#ip address 192.168.0.2 255.255.255.0
R2(config-if)#no shut
R2(config-if)#ip route 192.168.1.1 255.255.255.255 192.168.0.1
R2(config)#int lo99
R2(config-if)#ip address 10.1.1.1 255.255.255.0
R2(config-if)#int tunn0
R2(config-if)#ip address 169.254.254.2 255.255.255.252
R2(config-if)#tunnel mode gre ip
R2(config-if)#tunnel source lo0
R2(config-if)#tunnel dest 192.168.1.1
R2(config-if)#ip route 10.0.0.0 255.255.255.0 tunnel0
R2(config-if)#do ping 10.0.0.1 source lo99
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/5 ms
R2(config-if)#

So, what did we just do?

  • We added a loopback, to be used for the tunnel endpoints.
  • We added IP addressing for the transit link between the two routers.
  • We added a route to each router, so that the loopbacks were reachable across the transit link.
  • We added another loopback to each router (Lo99) to represent a customer subnet.
  • We added a tunnel interface, and created a GRE tunnel between the infrastructure loopbacks
  • We added a route to make the customer subnet reachable over the tunnel.
  • We tested, and it worked.

So now the customer subnets can reach each other, while the underlying infrastructure doesn't have knowledge of those subnets. Obviously this is just over one link in this example, but that one link could be a very complex infrastructure instead.

Customer VRFs

If the customer is in a VRF, we can still do this. In fact, it's a relatively simple change.

On R1:

R1(config)#ip vrf customer
R1(config-vrf)#int lo99
R1(config-if)#ip vrf forwarding customer
% Interface Loopback99 IPv4 disabled and address(es) removed due to disabling VRF customer
R1(config-if)# ip address 10.0.0.1 255.255.255.0
R1(config-if)#int tunn0
R1(config-if)#ip vrf forwarding customer
% Interface Tunnel0 IPv4 disabled and address(es) removed due to disabling VRF customer
R1(config-if)# ip address 169.254.254.1 255.255.255.252
R1(config-if)#no ip route 10.1.1.0 255.255.255.0 Tunnel0
R1(config)# ip route vrf customer 10.1.1.0 255.255.255.0 Tunnel0

On R2:

R2(config)#ip vrf customer
R2(config-vrf)#int tunn0
R2(config-if)#ip vrf forwarding customer
% Interface Tunnel0 IPv4 disabled and address(es) removed due to disabling VRF customer
R2(config-if)# ip address 169.254.254.2 255.255.255.252
R2(config-if)#int lo99
R2(config-if)# ip vrf forwarding customer
% Interface Loopback99 IPv4 disabled and address(es) removed due to disabling VRF customer
R2(config-if)# ip address 10.1.1.1 255.255.255.0
R2(config-if)#no ip route 10.0.0.0 255.255.255.0 Tunnel0
R2(config)#ip route vrf customer 10.0.0.0 255.255.255.0 Tunnel0

Here we moved the customer subnets (Lo99) into VRF's. To make the tunnels work, we then moved the tunnel IP addressing into the VRF, and added routes into the VRF to say the other customer range is reachable across the tunnel. Notice that the tunnel still establishes across the default VRF, while customer traffic tunnels across it and pops out within the customer VRF.

Multi - VRF

Now, what if we don't use a default VRF for our infrastructure? What if we use a VRF called "infra"? No problem.

R1:

R1(config)#ip vrf infra
R1(config-vrf)#exit
R1(config)#int lo0
R1(config-if)#ip vrf forwarding infra
% Interface Loopback0 IPv4 disabled and address(es) removed due to disabling VRF infra
R1(config-if)#ip address 192.168.1.1 255.255.255.255
R1(config-if)#int gi0/0
R1(config-if)#ip vrf forwarding infra
% Interface GigabitEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF infra
R1(config-if)# ip address 192.168.0.1 255.255.255.0
R1(config-if)#int tunn0
R1(config-if)#tunnel vrf infra
R1(config)#no ip route 192.168.2.2 255.255.255.255 192.168.0.2
R1(config)#ip route vrf infra 192.168.2.2 255.255.255.255 192.168.0.2

R2:

R2(config)#ip vrf infra
R2(config-vrf)#exit
R2(config)#int lo0
R2(config-if)#ip vrf forwarding infra
% Interface Loopback0 IPv4 disabled and address(es) removed due to disabling VRF infra
R2(config-if)#
*Jan 22 19:53:13.838: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)# ip address 192.168.2.2 255.255.255.255
R2(config-if)#int gi0/0
R2(config-if)#ip vrf forwarding infra
% Interface GigabitEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF infra
R2(config-if)# ip address 192.168.0.2 255.255.255.0
R2(config-if)#int tunn0
R2(config-if)#tunnel vrf infra
R2(config-if)#no ip route 192.168.1.1 255.255.255.255 192.168.0.1
R2(config)#ip route vrf infra 192.168.1.1 255.255.255.255 192.168.0.1

This time, we moved everything from the default VRF into the infra VRF. That's the loopbacks, physical link and the routes to the loopbacks via the physical link.

Then we configure the tunnel vrf command. This tells the tunnel to establish over this VRF. The tunnel goes through this VRF, and the contents of the tunnel pop out in the ip vrf forwarding VRF.

Summary

GRE Tunnels are sometimes a necessary tool to make things work, and sometimes it's important just to make things work.

Share this post

  • Share to Facebook
  • Share to Twitter
  • Share to Google+
  • Share to LinkedIn
  • Share by Email