Add a VPN to an Enterprise Network with Multi-VRF Functionality

[LEFT][CODE]http://www.nil.com/ipcorner/EnterpriseMultiVRF/[/CODE] Let’s assume that you’re the Chief Information Officer (CIO) of a large corporation with numerous small sites spread throughout the world. Financial pressures have forced management to outsource non-core services, including physical site security. The security vendor you’re using would like to implement video surveillance on the remote sites, and it’s your task to provide a transport path between the sites and the gateway located in your data center. The connectivity requirements of the external vendor are displayed in Figure 1.
[B][COLOR=Red]Figure 1[/COLOR] Connectivity requirements[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/ProblemDefinition.png[/IMG]


In most cases, modern video cameras support IP transport, and the initial implementation plan seems easy enough: connect the remote cameras to your network, give the outside vendor controlled access and you’re done. Not so fast; there might be all sorts of privacy and security implications. For example, do you want your employees to access the cameras? Do you want them to be able to access the video equipment on other remote sites? Are you sure the video equipment cannot be used as a backdoor into your network? Once you work through all the potential issues, the best option will likely be to build a dedicated Virtual Private Network (VPN) for the video surveillance equipment (see Figure 2).
[B][COLOR=Red]Figure 2[/COLOR] VPN is used to transport video data across the enterprise network[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/ProblemDefinitionVPN.png[/IMG]


If you’ve decided to build your network with Cisco routers, you already have all the building blocks you need to implement this project. You could build a fully functional MPLS VPN network (but this would require extensive MPLS VPN and BGP knowledge), or you could add a simple VPN to your existing network with the Multi-VRF functionality available in all Cisco routers.


[COLOR=Red][B]Important[/B][/COLOR]
The Multi-VRF design does not scale if you have to add numerous VPNs to your network. In this case, it’s easier to convert your core network into a full-blown MPLS VPN network. If you need assistance with the MPLS VPN technology, you can get [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_c"]consulting[/URL], [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_d"]design[/URL] and [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_i"]deployment[/URL] help from NIL’s professional services team.
[B]
Case Study Description[/B]

Throughout this article, we’ll use a simple non-redundant network with a single remote site. The remote site and the core router are connected with a point-to-point link; the gateway to the external vendor (the [I]CGW [/I]router in Figure 3) is connected to the data center LAN. The physical connectivity of the sample network and its IP addressing are shown in Figure 3.Should you mention what “CGW” stands for in Figure 3?

[B][COLOR=Red]Figure 3[/COLOR] Case study topology and addressing[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/CaseStudyAddressing.png[/IMG]

[B]Multi-VRF Design[/B]

The Multi-VRF functionality allows you to implement multiple independent routing tables on a single physical router without full-blown MPLS VPN functionality. Each VRF (or the global IP routing table) has its own set of associated interfaces and routing processes. In our scenario, the [I]video [/I]VRF on a remote site needs a LAN interface (where the camera will be connected) and an uplink (see Figure 4).
[B][COLOR=Red]Figure 4[/COLOR] Global and VRF interfaces on the Site router[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/GlobalVRFInterfaces.png[/IMG]


The LAN interface on the remote site could be a dedicated router interface (more expensive, but ideal from a security perspective) or a VLAN connected to the router through an existing switch. The uplink interface has to reuse the existing infrastructure of the enterprise network. Unless you’re running a private Layer-2 WAN (for example, Frame Relay or ATM network), you’ll be forced to use IP-over-IP tunneling; the IP packets routed in the [I]video [/I]VRF will be encapsulated in an IP header that will allow them to traverse the enterprise network. You can use simple Generic Routing Encapsulation (GRE) tunnels (as shown in Figure 5) or multipoint tunnels using the Dynamic Multipoint Virtual Private Network (DMVPN) technology.
[B][COLOR=Red]Figure 5[/COLOR] Physical and logical interfaces on the remote site[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/LogicalVRFInterfaces.png[/IMG]


On the central site, it’s best to terminate the GRE tunnels on a dedicated set of devices (a non-redundant solution is displayed in Figure 6). This design provides better security (core devices are not exposed to raw IP packets traversing the VPN) and clear isolation between the IP transport in the enterprise network and the transport of VPN packets belonging to an external organization.
[B][COLOR=Red]Figure 6[/COLOR] GRE tunnel termination on the central site[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/TunnelTermination.png[/IMG]


After you’ve created the VPN transport interfaces, you have to propagate the IP routing information across the VPN. To simplify our scenario, we’ll use static routes across GRE tunnels. If you decided to implement DMVPN tunnels, you should use a dynamic routing protocol in the VPN.


[COLOR=Red][B]Important[/B][/COLOR]
The case study uses a non-redundant design to simplify the description of the architecture. Readers familiar with high-availability IPSec or GRE designs will easily extend the architecture to redundant scenarios. NIL’s professional services team can help you to [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_c"]select the ideal routing technology[/URL], [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_d"]design the network[/URL] and [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_i"]implement[/URL] the selected solution.

[B]Remote Site Implementation[/B]

The initial router configuration of the [I]Site [/I]router (Listing 1) should be familiar to any enterprise networking engineer: we need to configure the router’s LAN and WAN interfaces, create a loopback interface and start an IP routing process that will be used in the enterprise network.
[B][COLOR=Red]Listing 1[/COLOR] Initial configuration of the Site router[/B]


[CODE]hostname Site
!
interface Loopback0
ip address 10.0.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.5.3.1 255.255.255.0
!
interface Serial1/0
description WAN uplink
ip address 10.0.7.5 255.255.255.252
encapsulation ppp
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
end
[/CODE]The Multi-VRF configuration might be a bit unfamiliar if you have never configured MPLS VPN. Before working on anything else, we have to create the Virtual Routing and Forwarding table (VRF) with the [B]ip[/B][B] vrf [/B]command. Each VRF needs a unique [I]route distinguisher [/I](RD) and (optionally) a set of [I]route targets [/I](RT). In most cases, RT and RD are specified in the [I]AS[/I][I]:nn[/I]format, where [I]AS[/I] is the autonomous system number allocated to your organization and [I]nn[/I]is an internal 32-bit number identifying the VPN.


[COLOR=Red][B]Note[/B][/COLOR]
Route targets should not be required for proper operation of Multi-VRF functionality, but I still recommend that you configure them in order to avoid potential Cisco IOS bugs.
If you don’t have a public AS number, you can use a private AS number (they range from 64512 to 65535). 65000 will be used as the AS number in the sample configurations. Now that we have the RD/RT values, we can configure VRF on the [I]Site [/I]router (Listing 2).
[B][COLOR=Red]Listing 2[/COLOR] VRF configuration on the Site router[/B]


[CODE]ip vrf Video
rd 65000:1
route-target both 65000:1
[/CODE]When the VRF is configured, you can attach individual interfaces to it with the [B]ip[/B][B] vrf forwarding [/B]interface configuration command. We have to create a VLAN subinterface for the VLAN (to which the camera will be connected) and a tunnel interface for the WAN uplink (Listing 3).
[B][COLOR=Red]Listing 3[/COLOR] VPN interfaces on the Site router[/B]


[CODE]interface Tunnel0
ip vrf forwarding Video
ip unnumbered FastEthernet0/0.20
tunnel source Loopback0
tunnel destination 10.0.1.3
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding Video
ip address 192.168.3.1 255.255.255.0
[/CODE]Finally, we have to configure a dynamic routing protocol or static routing in the VRF to give the router the information it needs to forward the IP packets received through the VRF interfaces. A simple default route pointing to the tunnel interface is enough for our needs (Listing 4).
[B][COLOR=Red]Listing 4[/COLOR] Static routing in the Video VRF[/B]


[CODE]ip route vrf Video 0.0.0.0 0.0.0.0 Tunnel0[/CODE][B]
[COLOR=Red]Important[/COLOR][/B]
Although the devices connected to a VRF cannot access devices connected to other VRFs or global interfaces, they can nonetheless access the router’s services, including its [I]Telnet[/I], [I]SSH[/I]or [I]HTTP [/I]server. Whenever you connect an untrusted device to an interface of your router, you should protect the router. NIL’s professional services team can help you to [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_c"]select the optimal security mechanism[/URL] as well as to [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_d"]design[/URL] and [URL="http://www.nil.com/C1257455003A036D/html/nil_assist_i"]implement[/URL] the selected solution.

[B]Monitoring Multi-VRF Implementation[/B]

When you have to troubleshoot a Multi-VRF implementation, you can use the usual monitoring commands; most of the commands you’ll find useful are either VRF-independent or include a [B]vrf [/B]keyword. For example, the [B]show [/B][B]ip[/B][B] route [/B]command can be used to inspect the global IP routing table (Listing 5) as well as the VRF routing table (Listing 6).
[B][COLOR=Red]Listing 5[/COLOR] Global IP routing table on the Site router[/B]


[CODE]Site#show ip route | begin Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
C 10.0.7.4/30 is directly connected, Serial1/0
O 10.0.1.2/32 [110/65] via 10.0.7.6, 00:00:14, Serial1/0
O 10.2.2.0/24 [110/65] via 10.0.7.6, 00:00:14, Serial1/0
C 10.0.1.1/32 is directly connected, Loopback0
C 10.0.7.6/32 is directly connected, Serial1/0
C 10.5.3.0/24 is directly connected, FastEthernet0/0
[/CODE][B]

[COLOR=Red]Listing 6[/COLOR] VRF routing table on the Site router[/B]


[CODE]Site#show ip route vrf Video | begin Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C 192.168.3.0/24 is directly connected, FastEthernet0/0.20
S* 0.0.0.0/0 is directly connected, Tunnel0
[/CODE]You can also use two monitoring commands specific to the VRF implementation:
[B]show[/B][B]ip[/B][B] vrf [/B][B][I]name[/I][/B]displays the VRF parameters and the associated interfaces (Listing 7).
[B]show[/B][B]ip[/B][B] vrf interfaces [/B][B][I]name[/I][/B]is very similar to the show ip interface brief command, but displays only the interfaces associated with the specified VRF (Listing 8).
[B][COLOR=Red]Listing 7[/COLOR] Brief description of the Video VRF on the Site router[/B]


[CODE]Site#show ip vrf Video
Name Default RD Interfaces
Video 65000:1 Tu0
Fa0/0.20
Listing 8
Interface status for the Video VRF on the Site router
Site#show ip vrf interfaces Video
Interface IP-Address VRF Protocol
Tu0 192.168.3.1 Video up
Fa0/0.20 192.168.3.1 Video up
[/CODE]Finally, the [B]show running vrf [/B][B][I]name [/I][/B]command (first available in IOS releases 12.2SRC and 12.4(22)T) displays the VRF-related router configuration. This command displays the VRF definition, interface configuration, routing protocol configuration and static routes associated with the specified VRF. The VRF-related configuration on the [I]Site [/I]router is shown in Listing 9.
[B][COLOR=Red]Listing 9[/COLOR] VRF-related configuration on the Site router[/B]


[CODE]Site#show running vrf Video
Building configuration...
Current configuration : 504 bytes
ip vrf Video
rd 65000:1
route-target export 65000:1
route-target import 65000:1
!
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding Video
ip address 192.168.3.1 255.255.255.0
!
interface Tunnel0
ip vrf forwarding Video
ip unnumbered FastEthernet0/0.20
tunnel source Loopback0
tunnel destination 10.0.1.3
!
ip route vrf Video 0.0.0.0 0.0.0.0 Tunnel0
end
[/CODE] [B]

Implementing the Central Gateway[/B]

The central gateway implementation is as straightforward as the remote site implementation: you have to configure the global interfaces, the global routing process, the VRF interfaces and the VRF routing. Static routes will be used for the VRF routing. The VRF default route points to the interface connecting the enterprise network with the external vendor. A static host route pointing to the correct tunnel interface is used for each remote site video camera. The relevant parts of the central gateway configuration are included in Listing 10.


[COLOR=Red][B]Note[/B][/COLOR]
Using static host routes instead of subnet routes further limits the number of devices the external vendor can access in your network. For example, the external vendor cannot access remote site routers due to routing constraints.
[B][COLOR=Red]Listing 10[/COLOR] Configuration of the central gateway[/B]


[CODE]hostname CGW
!
ip vrf Video
rd 65000:0
route-target export 65000:0
route-target import 65000:0
!
interface Loopback0
ip address 10.0.1.3 255.255.255.255
!
interface Tunnel0
description Remote Site
ip vrf forwarding Video
ip unnumbered FastEthernet0/1
tunnel source Loopback0
tunnel destination 10.0.1.1
!
interface FastEthernet0/0
description Data Center LAN interface
ip address 10.2.2.2 255.255.255.0
!
interface FastEthernet0/1
description Link to physical security vendor
ip vrf forwarding Video
ip address 192.168.0.1 255.255.255.0
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
ip route vrf Video 0.0.0.0 0.0.0.0 192.168.0.2
ip route vrf Video 192.168.3.2 255.255.255.255 Tunnel0
!
end
[/CODE] [B]

Implementing Local Inter-VRF Connectivity[/B]

Sometimes users local to a particular site will need access to the video equipment located at that site. In our scenario, users connected to the LAN interface of the [I]Site [/I]router would like to access the web camera connected to the VLAN interface belonging to the [I]Video [/I]VRF. The desired traffic flow is displayed in Figure 7.
[B][COLOR=Red]Figure 7[/COLOR] Desired inter-VRF traffic flow[/B]


[IMG]http://www.nil.com/ipcorner/EnterpriseMultiVRF/$FILE/InterVRFConnectivity.png[/IMG]


Traditionally you could implement this request in the MPLS VPN framework with an [I]overlapping VPN [/I]solution or route leaking between VRFs. In this section, you’ll see how you can use Network Address Translation (NAT) to achieve the same results.


[COLOR=Red][B]Note[/B][/COLOR]
It’s highly recommended that you read the [URL="http://www.nil.com/ipcorner"]IP Corner[/URL] article “[URL="http://www.nil.com/ipcorner/FlexExtraImplement/"]Flexible Extranet Implementation[/URL]” before continuing with this section.
To allow communication between the LAN users and the camera, the router needs to forward packets sent to IP address [I]192.168.3.2[/I] from the global IP routing table to the [I]FastEthernet0/1.20[/I] subinterface. The easiest way to implement this requirement is with a static host route installed in the global IP routing table pointing to the VRF interface. You can see the relevant router configuration in Listing 11 and the resulting entry in the IP routing table in Listing 12.
[B][COLOR=Red]Listing 11 [/COLOR] Static host route from the global IP routing table to the Video VRF[/B]


[CODE]Site#show run | include ip route
ip route 192.168.3.2 255.255.255.255 FastEthernet0/0.20 192.168.3.2
[/CODE][B]

[COLOR=Red]Listing 12[/COLOR] The host route toward the camera in the global IP routing table[/B]


[CODE]Site#show ip route 192.168.3.2
Routing entry for 192.168.3.2/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 192.168.3.2, via FastEthernet0/0.20
Route metric is 0, traffic share count is 1
[/CODE]The [URL="http://www.nil.com/ipcorner"]IP Corner[/URL] article “[URL="http://www.nil.com/ipcorner/FlexExtraImplement/"]Flexible Extranet Implementation[/URL]” has used classic NAT configuration commands to implement NAT between source hosts in VRFs and a server in the global IP routing table. We need to implement reverse functionality (the server is in the VRF). The classic NAT does not work from the global IP routing table to a VRF; you have to use the [I]NAT Virtual Interface[/I] (NVI) configuration commands.
The NVI configuration commands are similar to the classic NAT configuration commands, but do not impose a strict [I]inside/outside [/I]view; every interface on which NAT has to be performed is marked with the [B]ip[/B][B]nat[/B][B] enable [/B]command. Furthermore, the [B]ip[/B][B]nat[/B][B] inside source [/B]command is replaced with the [B]ip[/B][B]nat[/B][B] source [/B]command. As you can see from the NAT-related configuration of the Site router (Listing 13), NAT configuration using NVI configuration commands is no more complex than the traditional NAT.
[B][COLOR=Red]Listing 13[/COLOR] NAT configuration on the Site router[/B]


[CODE]interface FastEthernet0/0
ip address 10.5.3.1 255.255.255.0
ip nat enable
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding Video
ip address 192.168.3.1 255.255.255.0
ip nat enable
!
ip nat log translations syslog
ip nat source list Camera interface FastEthernet0/0.20 overload
!
ip access-list extended Camera
permit ip any host 192.168.3.2
[/CODE] [B]

Summary[/B]

Multi-VRF functionality, available on almost all modern routers produced by Cisco Systems, gives you the ability to configure multiple Virtual Routing and Forwarding tables on a single router without deploying full-blown MPLS VPN functionality.


You can use Multi-VRF functionality to implement tightly controlled VPNs across a traditional enterprise IP network without changing the network core or introducing MPLS VPN functionality in the network. The VRFs configured on the edge routers have to be connected with distinct logical or physical interfaces; if you want to leverage an existing IP infrastructure, your only option is to implement GRE or DMVPN tunnels.


[COLOR=Red][B]Note[/B][/COLOR]
If you’re running a private Frame Relay or ATM network, you can implement the VPN links across the network core with a separate set of virtual circuits. In pure switched-LAN environments, you can use separate VLANs for the VPN links.

The Multi-VRF solution does not scale well if you want to deploy numerous VPNs across a common infrastructure. If your network is evolving in that direction, consider deploying the MPLS VPN technology in your network
[/LEFT]