Using a GRE Tunnel VRF to Separate the Physical Interface

BlueCableKnotWhether we like it our not, production networks often have particular use cases that require the implementation of tunnels. This may be an effort to extend a dynamic routing protocol across a service provider segment or an effort to overcome specific addressing challenges. Without special consideration, the tunnel and physical interface have routing entries that are inserted into the global routing table.

Since all routes are part of a common routing table, administrators must make sure that the route to the remote tunnel endpoint never becomes recursive through the tunnel interface itself. Imagine GRE traffic reaching the remote router using a default route through the physical interface. Next the tunnel interface comes up and an IGP determines the best path to the remote device is through the tunnel itself. This will cause the tunnel to fail and the associated routes to continually flap.

In addition to this challenge, there is likely no reason for the traffic on the physical interface to commingle with the traffic associated with the other interfaces. An elegant solution is to use VRF’s to create the logical separation. This article looks at converting a simple GRE tunnel configuration to a configuration that utilizes a front-side vrf (FVRF).

The image below shows a base configuration that includes all interfaces in the global routing instance.

GREtunnelR1

interface Tunnel1
 ip address 192.168.1.1 255.255.255.0
 tunnel source Serial0/0
 tunnel destination 1.1.2.3

interface Serial0/0 
 ip address 1.1.1.1 255.255.255.0

interface loopback0
 ip address 10.10.10.1 255.255.255.0

router eigrp 1
 network 10.10.10.1 0.0.0.0
 network 192.168.1.1 0.0.0.0
 no auto-summary

ip route 1.1.2.3 255.255.255.255 1.1.1.2

R3

interface Tunnel1
 ip address 192.168.1.3 255.255.255.0
 tunnel source Serial0/0
 tunnel destination 1.1.1.1

interface Serial0/0 
 ip address 1.1.2.3 255.255.255.0

interface loopback0
 ip address 10.30.30.3 255.255.255.0

router eigrp 1
 network 10.30.30.3 0.0.0.0
 network 192.168.1.3 0.0.0.0
 no auto-summary

ip route 1.1.1.1 255.255.255.255 1.1.2.2

R2 (Transit Router)

interface Serial0/0 
 ip address 1.1.1.2 255.255.255.0

interface Serial0/1 
 ip address 1.1.2.2 255.255.255.0

The goal is to convert this to a configuration that separates the physical interfaces into a separate front-side VRF. At the point of completion, the physical interfaces won’t even be present in the global routing tables of R1 and R3.

GREtunnelvrfR1

//create a VRF
ip vrf FVRF

//add a static route for the tunnel in the VRF
//remove the old route to the tunnel endpoint
ip route vrf FVRF 0.0.0.0 0.0.0.0 1.1.1.2
no ip route 1.1.2.3 255.255.255.255 1.1.1.2

//assign the tunnel to a tunnel VRF
interface Tunnel1
 ip address 192.168.1.1 255.255.255.0
 tunnel source Serial0/0
 tunnel destination 1.1.2.3
 tunnel vrf FVRF

//add the physical interface to the VRF
//and reassign the addressing
interface Serial0/0 
 ip vrf forwarding FVRF
 ip address 1.1.1.1 255.255.255.0

R3

//create a VRF
ip vrf FVRF

//add a static route for the tunnel in the VRF
//remove the old route to the tunnel endpoint
ip route vrf FVRF 0.0.0.0 0.0.0.0 1.1.2.2
no ip route 1.1.1.1 255.255.255.255 1.1.2.2

//assign the tunnel to a tunnel VRF
interface Tunnel1
 ip address 192.168.1.3 255.255.255.0
 tunnel source Serial0/0
 tunnel destination 1.1.1.1
 tunnel vrf FVRF

//add the physical interface to the VRF
//and reassign the addressing
interface Serial0/0 
 ip vrf forwarding FVRF
 ip address 1.1.2.3 255.255.255.0

After the configuration changes, the Loopback interface on R1 can still reach the Loopback interface on R3. Additionally, the routes between the physical interfaces have been moved to the vrf named FVRF.

Verification

R1#ping 10.30.30.3 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.30.30.3, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R1#show ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
D       10.30.30.0 [90/297372416] via 192.168.1.3, 00:04:02, Tunnel1
C       10.10.10.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel1
R1#show ip route vrf FVRF

Routing Table: FVRF

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Serial0/0
S*   0.0.0.0/0 [1/0] via 1.1.1.2

The output and testing from R3 is similar, but has been eliminated for brevity.

Conclusion

The configuration of a GRE tunnel VRF offers several advantages of isolation. In a future article, we will look at what is required to further secure this by adding an IPSec connection profile to the tunnel interfaces. While this sounds simple, there are a few VRF specific caveats that must be addressed when combining tunnel with an IPSec configuration.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design and tagged . Bookmark the permalink.

11 Responses to Using a GRE Tunnel VRF to Separate the Physical Interface

  1. Filip says:

    hey Paul, I was trying similar setup once before. Just out of curiosity what version wee testing with?
    TY

  2. john says:

    hey Paul, ip route vrf FVRF 0.0.0.0 0.0.0.0 1.1.2.2 command is to reach network 192.168.1.3/24 right?..with the help of this command tunnel between R1 and R3 is getting built right? and if i am not wrong then to introduce R3’s loopback to R1 you have used eigrp..just clearing up things. TY for awesome post

    • Paul Stewart says:

      In order to build a tunnel between R1 and R3, R1 needs to be able to reach 1.1.2.3 (on R3). Likewise R3 needs to reach 1.1.1.1 (on R1). These are the tunnel source and destinations. Therefore, we do the following–

      //R1
      ip route vrf FVRF 0.0.0.0 0.0.0.0 1.1.1.2

      //R3
      ip route vrf FVRF 0.0.0.0 0.0.0.0 1.1.2.2

      This allows the tunnel to be built in a separate vrf (note the tunnel vrf command under “interface tunnel x”.

      Then, as you stated, the loopbacks are made known in the global routing table via EIGRP.

      • jim bolo says:

        Hey Paul, nice post but what i don’t understand is that any VRF table and the Global table should be completely isolated, so if i placed a tunnel in certain VRF table, how come i can use loopback addresses from the global table inside the VRF table?

        iinterface Tunnel1
        ip address 192.168.1.1 255.255.255.0
        tunnel source Serial0/0
        tunnel destination 1.1.2.3
        tunnel vrf FVRF

      • There are two components to a GRE tunnel. One would be the outer IP Packet that carries transit traffic. The other component is the transit traffic itself. In this example, only the outer packet is part of the FVRF configuration. This is indicated by the “tunnel vrf FVRF”. If transit traffic were also to be part of a VRF (the same or another), it would use “ip vrf forwarding ” command.

  3. Pingback: Explanation: TunnelX temporarily disabled due to recursive routing - PacketU

  4. Chris Andrew says:

    Paul – this has helped a great deal. I could not understand how routes seemingly from a VRF interface found themselves in the global routing table. I’ve been searching for an article to explain this. Along with your lab and final comment above, I now understand this. Thank you very much.

  5. Elvin Arias says:

    Hi Paul,

    Great article.

    Elvin

  6. Kyle Rogers says:

    Paul, do you have any suggestions on how one would use keepalives across a tunnel using fVRF’s? As soon as I enable keepalives my tunnel goes up/down.

  7. Pingback: Segmenting Layer 3 Networks with VRFs - PacketU

Comments are closed.