Content
Add a VPN to an Enterprise Network with Multi-VRF Functionality
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.
Figure 1
Connectivity requirements
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).
Figure 2
VPN is used to transport video data across the enterprise network
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.
Important
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 consulting, design and deployment help from NIL’s professional services team.
Case Study Description
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 CGW 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?
Figure 3
Case study topology and addressing
Multi-VRF Design
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 video VRF on a remote site needs a LAN interface (where the camera will be connected) and an uplink (see Figure 4).
Figure 4
Global and VRF interfaces on the Site router
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 video 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.
Figure 5
Physical and logical interfaces on the remote site
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.
Figure 6
GRE tunnel termination on the central site
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.
Important
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 select the ideal routing technology, design the network and implement the selected solution.
Remote Site Implementation
The initial router configuration of the Site 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.
Listing 1
Initial configuration of the Site router
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
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 ip vrf command. Each VRF needs a unique route distinguisher (RD) and (optionally) a set of route targets (RT). In most cases, RT and RD are specified in the AS:nn format, where AS is the autonomous system number allocated to your organization and nn is an internal 32-bit number identifying the VPN.
Note
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 Site router (Listing 2).
Listing 2
VRF configuration on the Site router
ip vrf Video
rd 65000:1
route-target both 65000:1
When the VRF is configured, you can attach individual interfaces to it with the ip vrf forwarding 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).
Listing 3
VPN interfaces on the Site router
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
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).
Listing 4
Static routing in the Video VRF
ip route vrf Video 0.0.0.0 0.0.0.0 Tunnel0
Important
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 Telnet, SSH or HTTP 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 select the optimal security mechanism as well as to design and implement the selected solution.
Monitoring Multi-VRF Implementation
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 vrf keyword. For example, the show ip route command can be used to inspect the global IP routing table (Listing 5) as well as the VRF routing table (Listing 6).
Listing 5
Global IP routing table on the Site router
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
Listing 6
VRF routing table on the Site router
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
You can also use two monitoring commands specific to the VRF implementation:
show ip vrf name displays the VRF parameters and the associated interfaces (Listing 7).
show ip vrf interfaces name is very similar to the show ip interface brief command, but displays only the interfaces associated with the specified VRF (Listing 8).
Listing 7
Brief description of the Video VRF on the Site router
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
Finally, the show running vrf name 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 Site router is shown in Listing 9.
Listing 9
VRF-related configuration on the Site router
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
Implementing the Central Gateway
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.
Note
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.
Listing 10
Configuration of the central gateway
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
Implementing Local Inter-VRF Connectivity
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 Site router would like to access the web camera connected to the VLAN interface belonging to the Video VRF. The desired traffic flow is displayed in Figure 7.
Figure 7
Desired inter-VRF traffic flow
Traditionally you could implement this request in the MPLS VPN framework with an overlapping VPN 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.
Note
It’s highly recommended that you read the IP Corner article “Flexible Extranet Implementation” 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 192.168.3.2 from the global IP routing table to the FastEthernet0/1.20 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.
Listing 11
Static host route from the global IP routing table to the Video VRF
Site#show run | include ip route
ip route 192.168.3.2 255.255.255.255 FastEthernet0/0.20 192.168.3.2
Listing 12
The host route toward the camera in the global IP routing table
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
The IP Corner article “Flexible Extranet Implementation” 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 NAT Virtual Interface (NVI) configuration commands.
The NVI configuration commands are similar to the classic NAT configuration commands, but do not impose a strict inside/outside view; every interface on which NAT has to be performed is marked with the ip nat enable command. Furthermore, the ip nat inside source command is replaced with the ip nat source 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.
Listing 13
NAT configuration on the Site router
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
Summary
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.
Note
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.
Related learning products:
Implementing Cisco MPLS Course
Implementing Cisco MPLS Remote Labs
Implementing Cisco MPLS Traffic Engineering and Other Features Course
Advanced MPLS Traffic Engineering Course
MPLS Traffic Engineering Remote Labs
Implementing Cisco MPLS E-course
More to explore:
IP Corner article “Flexible Extranet Implementation”