Building Trusted VPNs with Multi-VRF

Transcription

1 Building Trusted VPNs with Introduction Virtual Private Networks (VPNs) have been a key application in networking for a long time. A slew of possible solutions have been proposed over the last several years. Driving this need has been the requirement for secure transport of sensitive information, controlling information access to those who need it, etc. In large enterprises, particularly those distributed across disparate locations, sensitivity to information pertinent to a department drives the requirement for an IT manager to logically demarcate information flows to be within that department. The need for privacy is another driver behind deployment of VPN solutions. VPN Options VPN technologies can be broadly classified into 2 types secure VPNs and trusted VPNs. Secure VPNs require traffic to be encrypted and authenticated and are most important when communication occurs across an infrastructure that is not trusted (e.g. over the public Internet). The most commonly deployed types of secure VPNs are IPSec VPNs and SSL (Secure Sockets Layer) VPNs. Both offer encryption of data streams. While IPSec VPNs operate at the network layer and require special client software, SSL VPNs are more application centric and can generally work with any SSL-enabled browser. On the other hand, trusted VPNs ensure integrity and privacy of the data transfers but do not provide any encryption capabilities. Trusted VPNs are most useful when the goal is to leverage a shared infrastructure to allow virtual networks to be built. Examples of such trusted VPN technologies include IP/MPLS based Layer 2 VPNs (VPLS, VLL), BGP/MPLS VPNs, ATM or Frame Relay circuits, Layer 2 Tunneling Protocol (L2TP), etc. In short, all these technologies allow a shared infrastructure to be used without compromising the privacy needs of different users or user groups. What is? Central to is the ability to maintain multiple Virtual Routing and Forwarding (VRF) tables on the same Provider Edge () Router. uses multiple instances of a routing protocol such as BGP or to exchange route information for a VPN among peer routers. The capable router maps an input customer interface to a unique VPN instance. The router maintains a different VRF table for each VPN instance on that router. Multiple input interfaces may also be associated with the same VRF on the router, if they connect to sites belonging to the same VPN. This input interface can be a physical interface or a virtual Ethernet interface on a port. routers communicate with one another by exchanging route information in the VRF table with the neighboring router. This exchange of information among the routers is done using BGP or. The routers that communicate with one another should be directly connected at Layer 3. Customers connect to routers in the network using Customer Edge () routers as shown in Figure 1. Different routing protocols may be used for exchanging information between the - routers and between the adjacent - routers. Further, different - routing protocols may be used in a VPN to exchange customer routes with the various customer sites in that VPN. The routes learnt from the - protocol are added to the corresponding VRF instance and redistributed via the - protocol to the peer router in the backbone network. Figure 1 depicts a network using to provide connectivity among sites that belong to multiple VPNs. To share the VPN route table information with remote s, each creates separate virtual interfaces and run different instances of the - routing protocol for each VRF. Some vendors also use the terminology of Multi- VRF or VRF-Lite for this technology Foundry Networks, Inc. 1

2 NetIron XMR 8000 NetIron XMR 8000 L2 network and BGP/MPLS VPNs Compared and BGP/MPLS VPNs share some common aspects. For instance, in both cases the edge router maintains a VRF for all directly connected sites that are part of the same VPN. In both cases, the and routers share customer route information using a variety of - routing protocols, such as, RIP, or static routes. Overlapping address spaces among different VPNs are allowed in both cases. However, there are several differences between the two VPN technologies. The fundamental difference between the two technologies is that Figure 1: A network deploying requires the peering routers to be directly connected at Layer 3. A Layer 2 network may however be present between the routers. On the other hand, BGP/MPLS VPNs have no such restriction. In BGP/MPLS VPNs, the MPLS network determines the path to the peer router. In order to disambiguate overlapping IP addresses, route targets are used in BGP/MPLS VPNs. uses the input interface to uniquely identify the associated VPN, which is why the two routers should be directly connected at Layer 3. Figure 2 compares and BGP/MPLS VPNs in more detail. BGP/MPLS VPN - routing protocol or BGP BGP - routing protocol BGP,, RIP or Static routing BGP,, RIP or Static routing - router connectivity routers should be directly connected at Layer 3 routers are interconnected via an IP/MPLS network Determination of VRF instance Based on input interface only Based on route target (network interface ) or input interface () Number of routing protocol instances Unique routing protocol instance for each VRF instance Single routing protocol instance 2006 Foundry Networks, Inc. 2

3 Building trusted VPNs with BGP/MPLS VPN Controlling advertisement of routes No need for route targets to be used. Route targets used to identify the customer VPN in advertised routes. The destination filters the routes advertised from a peer by comparing the route target with the VPNs maintained locally on that. Number of VRF instances Unique VRF instance for each VPN Unique VRF instance for each VPN Overlapping private Yes Yes addresses allowed across VPNs? Scalability Reasonably scalable Highly scalable Figure 2: and Layer 3 BGP/MPLS VPNs compared Benefits and Applications of provides a reliable mechanism for a network administrator to maintain multiple virtual routers on the same device. The goal of providing isolation among different VPN instances is accomplished without the overhead of heavyweight protocols used in secure VPN technologies or the administrative complexity of MPLS VPNs. It is particularly effective when operational staff has expertise in managing IP networks but may not have the same familiarity in managing MPLS networks. Overlapping address spaces can be maintained among the different VPN instances. As the two examples in the following sections demonstrate, the simplicity of allows for several interesting applications. Example of Usage in an Enterprise Data Center Figure 3 shows an example of in an enterprise data center. Each server farm is used for a dedicated application or set of applications. For security reasons, only specific servers in this farm may be allowed to communicate with other servers. Some accesses may be completely prohibited whereas certain others may be allowed through the firewall. Each server is placed on a different subnet. To ensure optimal performance of the data center, trusted servers should be allowed to communicate directly whereas untrusted servers should not be allowed to directly communicate at all. The figure only shows some servers; in practice, the number of servers could run into tens or hundreds. A common way to accomplish this is by using Policy Based Routing (PBR). However, PBR becomes very difficult to administer and manage as the network begins to grow, may require frequent configuration changes, and is prone to operator errors. MPLS VPNs can also be used to accomplish this. However, it may be too heavy-weight for what needs to be accomplished in this scenario. In addition, operational staff in enterprise data centers may not always be conversant with administering MPLS. Secure VPN technologies like IP-Sec are not required here because the infrastructure is already secure. Therefore, the overhead of encryption is not needed. is an ideal solution for such an application. Servers that are allowed to communicate can be placed in the same instance. If server access is to be controlled at a more granular level (e.g. at the application layer), then traffic from specific applications on that server can be sent on a specific tagged interface to the router in Cluster A. As shown in Figure 3, a highly redundant cluster is achieved by ensuring that no single node becomes a point of failure within this network Foundry Networks, Inc. 3

4 Power 25F Link Console 26F 1F 2F 3F 4F NETWOR KS NetIron XMR 8000 NetIron XMR 8000 NetIron XMR 8000 NETWOR KS NetIron XMR 8000 NETWORK S NetIron XMR 8000 NETWOR KS NetIron XMR 8000 Building trusted VPNs with Application Router Server Farm Cluster A Router Cluster B Firewall Public network Figure 3: Example of usage in an enterprise data center application RIP Customer A, Site 3 FastIronEdgeX424 Static Layer 2 Network for direct - connectivity at Layer 3 Customer B, Site 3 Customer A, Site 4 : Customer Edge : Provider Edge Customer B, Site 4 Figure 4: in a service provider application 2006 Foundry Networks, Inc. 4

5 Example of Usage in a Service Provider Network Figure 4 depicts the use of in a typical service provider application. The service provider here owns a Layer 2 network connecting the s and offers managed VPN services to end users. As shown in the Figure above, a host of - routing protocols can be used,, RIP or Static Routing. It is also possible that a site (such as site 2) may have several customers in close geographical proximity as in a business park. This may warrant a dedicated MTU to be placed on-site, which is owned by the service provider. In such a scenario, the different customers may share the same MTU and still use overlapping private address spaces. The MTU is a switch that adds a unique VLAN tag for each connected customer. The router (labeled 2) maps a Layer 3 tagged interface to a unique VRF. Thus, it could be sharing routes using with one and just using Static Routing with another both can occur over different virtual interfaces on the same physical interface. Layer 3 BGP/MPLS VPNs could also be used in a network such as the above. However, if one of the routers does not support MPLS or if the operational staff is not conversant with MPLS operations, provides an alternative mechanism to achieve the same objective. Foundry Products Supporting Foundry Networks has a broad range of products in its product line that support. o NetIron XMR Series, a family of high-end, carrier-class, backbone routers that scales from the network edge to the core. This includes the NetIron XMR 4000, XMR 8000, XMR 16000, and XMR routers. o NetIron MLX Series, a family of advanced switching routers with unique scalability for Layer 2 metro applications. This includes the NetIron MLX-4, MLX-8, MLX-16, and MLX-32 routers. o NetIron IMR 640, a Terabit MPLS router that is ideal for both service provider and large enterprise applications. Foundry s support for allows unparalleled scalability to be achieved by a service provider. For example, the NetIron XMR series of routers allows up to 2000 VRFs and up to 1 million VPN routes to be maintained in its VRF tables. Summary provides a reliable mechanism for trusted virtual private networks to be built over a shared infrastructure. The ability to maintain multiple virtual routing/forwarding tables allows overlapping private IP addresses to be maintained across VPNs and accomplish goals very similar to those of more complex VPN technologies such as BGP/MPLS VPNs. Author: Ananda Rajagopal Document version 1.1 Foundry Networks, Inc. Headquarters 4980 Great America Parkway Santa Clara, CA U.S. and Canada Toll-free: (888) TURBOLAN Direct telephone: Fax: info@foundrynet.com Web: Foundry Networks, AccessIron, BigIron, EdgeIron, FastIron, IronPoint, IronView, IronWare, JetCore, NetIron, ServerIron, Terathon, TurboIron, and the Iron family of marks are trademarks or registered trademarks of Foundry Networks, Inc. in United States and other countries. All other trademarks are the properties of their respective owners. Although Foundry has attempted to provide accurate information in these materials, Foundry assumes no legal responsibility for the accuracy or completeness of the information. More specific information is available on request from Foundry. Please note that Foundry's product information does not constitute or contain any guarantee, warranty or legally binding representation, unless expressly identified as such in a duly signed writing Foundry Networks, Inc. All Rights Reserved Foundry Networks, Inc. 5