Whether 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.
interface Tunnel1 ip address 192.168.1.1 255.255.255.0 tunnel source Serial0/0 tunnel destination 220.127.116.11 interface Serial0/0 ip address 18.104.22.168 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 22.214.171.124 255.255.255.255 126.96.36.199
interface Tunnel1 ip address 192.168.1.3 255.255.255.0 tunnel source Serial0/0 tunnel destination 188.8.131.52 interface Serial0/0 ip address 184.108.40.206 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 220.127.116.11 255.255.255.255 18.104.22.168
R2 (Transit Router)
interface Serial0/0 ip address 22.214.171.124 255.255.255.0 interface Serial0/1 ip address 126.96.36.199 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.
//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 188.8.131.52 no ip route 184.108.40.206 255.255.255.255 220.127.116.11 //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 18.104.22.168 tunnel vrf FVRF //add the physical interface to the VRF //and reassign the addressing interface Serial0/0 ip vrf forwarding FVRF ip address 22.214.171.124 255.255.255.0
//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 126.96.36.199 no ip route 188.8.131.52 255.255.255.255 184.108.40.206 //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 220.127.116.11 tunnel vrf FVRF //add the physical interface to the VRF //and reassign the addressing interface Serial0/0 ip vrf forwarding FVRF ip address 18.104.22.168 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.
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 22.214.171.124 to network 0.0.0.0 126.96.36.199/24 is subnetted, 1 subnets C 188.8.131.52 is directly connected, Serial0/0 S* 0.0.0.0/0 [1/0] via 184.108.40.206
The output and testing from R3 is similar, but has been eliminated for brevity.
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.