Unprotected Services Access
| The use of VPN routing and forwarding instances (VRFs) and multiprotocol Border Gateway Protocol (MP-BGP) allows enough flexibility for traffic to be leaked between VPNs. This is achieved by importing and exporting routes between VRFs to provide IP connectivity among different VNs. You can use this type of inter-VN connectivity to provide services that do not need to be protected by the central site firewalls or that would represent an unnecessary burden to the VN perimeter firewalls. Because of the any-to-any nature of an IP cloud, little chance exists of controlling inter-VN traffic after the routes have been exchanged. Note Although these services are not protected by the VN perimeter firewalls, the IP segment to which they belong can potentially be headended by a firewall and thus be "protected." Because it is unsecured, you must deploy this type of connectivity carefully; it can potentially create unwanted back doors between VNs and break the concept of the VN as a "security zone" protected by a robust VN perimeter front end. In general, the deployment should be targeted at the creation of extranet VNs. Extranet VNs can communicate with many VNs; however, they do not provide a transit zone between the VNs that communicate with it. In routing terms, this means that the extranet VN contains routes to the client VNs, and the client VNs contains routes to the extranet VN; however, the routes from one client are not leaked to another client through the extranet VN. Importing and exporting routes between VNs precludes the use of overlapping address spaces between the VNs. If address reuse is necessary, you must deploy a routed VN perimeter with Network Address Translation (NAT) capabilities. The guidelines for such deployment are discussed later in this chapter. When routes are imported between VRFs, the exchange of traffic between VNs follows the shortest path within the IP core. This prevents inter-VN traffic from traversing the VN perimeter firewalls at the central site. If the shared resources are physically close to the requesters, it is desirable to avoid an inefficient "trombone" traffic pattern that travels all the way to the central services site and back. It may be tempting to consider this approach as a means to provide peer-to-peer connectivity across VNs. To provide peer-to-peer connectivity, however, all prefixes in one VRF must be leaked to another VRF and vice versa. After this is done, the separation between the VRFs is lost and the original purpose of having the VRFs is defeated. Therefore, the use of route imports and exports is devoted mainly to the creation of extranet VNs rather than enabling controlled communication between VNs. The extranet capability by means of imports and exports is versatile and has found many applications within enterprises, especially in shared data centers. The following sections cover several useful scenarios that arise when importing and exporting routes between VRFs. This is by no means exhaustive, but the intention here is to provide the necessary fundamentals for creative individuals to adapt the technology to their particular needs. Basic Import/Export MechanismImporting and exporting routes between different VRFs is a function of multiprotocol interior Border Gateway Protocol (MP-iBGP). An MP-iBGP update carries the extended community attribute, which contains both the route distinguisher (RD) and the export route targets (RTs) for the prefixes being announced. The RTs contain the information that allows the importing and exporting of prefixes to happen. When a router receives an MP-iBGP update, the RTs in the import statements for each VRF are compared to the RTs received with the update (which correspond to the export statements on the VRF sending the update). Thus, a prefix is installed in a VRF when the RT in the MP-iBGP update matches an RT in an import statement for the receiving VRF. A single VRF can have many import and export statements, each with a different RT value. Thus, a single prefix might be announced with many different RT values, which can be selectively imported into specific VRFs on specific routers. It is important to keep in mind that when a VRF learns a prefix by means of MP-iBGP, it does not advertise this prefix to its other neighbors. In other words, MP-iBGP is not transitive and does not reflect routing updates. Hence, prefixes are imported and exported between VRFs and not between VNs. When a prefix is imported/exported between two VRFs, it is not automatically advertised to other VRFs in the destination VN. You can use route maps to filter which prefixes received in an MP-iBGP update are to be imported into a VRF. Their use allows a finer level of granularity in selecting which routes are leaked between VRFs. This level of granularity can prove useful when only certain hosts or segments should be reached from outside the VN they belong to. Multiplatform DeploymentIn general, you can use BGP to transport routing information between different physical routers. To allow this communication, it is necessary to establish BGP sessions (which are TCP connections) between the routers. These sessions are defined by the neighbor statements in the BGP configuration. In the scenario shown in Figure 8-1, the updates travel over the BGP connections and are imported into the VRFs that match the RTs in the extended community, as explained earlier. Figure 8-1. RT Imports and Exports Across Platforms In the example, we used an RT of 3:3 for the RED VN. Notice that this RT value is imported and exported by all VRFs. Also, note that BGP has been configured with the necessary neighbor statements and that each neighbor has been activated under the VPN version 4 (vpnv4) address family to handle the extended community attribute. Single-Platform DeploymentIt is possible to import and export routes between different VRFs within a single physical router. In this case, no BGP sessions are established between routers because, obviously, there is a single router. However, it is still necessary to enable an MP-BGP process within the router to enable the exchange of routes between VRFs based on the RTs and the import/export statements. The commands in Example 8-1 illustrate the BGP configuration required to enable local importing/exporting of routes. Notice that there are no neighbor statements, and therefore there are no statements under the vpnv4 address family either. Example 8-1. Local Importing and Exporting of Routes
This functionality allows the creation of extranets when VRFs are used to provide a level of router virtualization, but BGP/MPLS VPNs (RFC 2547) are not necessarily being deployed. Any-to-Any and Hub-and-Spoke VPNsTo create an any-to-any VPN, it is necessary to export and import all the routes for the VPN at every site. This means that the export statements used for a VRF on one router must match the import statements used by all other VRFs in the VPN and vice versa. Figure 8-2 shows three sites and a VPN named RED, which has been created by importing and exporting RT RED in the RED VRFs on every router. Figure 8-2. Any-to-Any VPNs Note A VPN is built by RT exchange; the RD is locally significant and does not determine any relationship between a VRF on one device and a VRF on another device. In the example, different RDs are used for the same VPN on different platforms to illustrate this. By using asymmetric import and export statements between different BGP neighbors, it is possible to create VPNs in which spoke sites can only communicate with a hub location. Figure 8-3 again shows three sites. This time, the configuration is provided to allow communication only between the spokes and the hub site for the BLUE VPN. Note that the spokes cannot talk to each other in this configuration because the routes between spokes have not been explicitly exchanged. Figure 8-3. Hub-and-Spoke VPNs Extranet VPNIt is common to require the sharing of services in one VPN with many other VPNs. The use of asymmetric import and export statements across different VPNs allows many VPNs to communicate with a shared extranet VPN. In this scenario, the VPNs have routes for the extranet and vice versa, but the extranet does not act as a transit area between VPNs. Therefore, although the VPNs are kept separate from each other, they can connect to shared resources. Figure 8-4 illustrates how to configure this scenario. Figure 8-4. Extranet VPN As shown in the example, the routes for the shared services VRF are exported with a RT of 1:1. These are imported into the RED and BLUE VRFs, allowing communication from the VRFs to the shared services. Communication in the other direction is achieved by importing the BLUE and RED routes into the services VRF. The latter is achieved by importing RTs 2:2 and 3:3, which correspond to BLUE and RED routes, respectively. It is important to highlight that the BLUE and RED routes imported into the Services VRF by MP-iBGP are not re-advertised. In other words, the updates imported with RTs 2:2 and 3:3 are not exported with an RT of 1:1 (or any other RT for that matter) by the Services VRF; therefore, this configuration will not provide connectivity between the RED and BLUE VRFs. Localized Inter-VPN CommunicationAs you may have noticed by now, it is necessary to explicitly import all routes that are to be present in a VPN. Furthermore, because of the nontransitivity of iBGP, you must do this at every physical router that will participate in the VPN. Therefore, importing a route into a VRF on a single physical router does not populate this route into all VRFs in a VPN. In other words, when a route is imported onto a VRF on a single physical router, that route is not automatically advertised to other physical routers participating in the VPN. To populate the route in all VRFs participating in the VPN, it is necessary to explicitly import the prefixes into each and every VRF. Figure 8-5 helps illustrate this concept better. In the three-site scenario in Figure 8-5, we have created RED and BLUE VPNs with full any-to-any connectivity within each VPN. Selective imports and exports are used to interconnect the RED and BLUE VPNs only at Site 1. Figure 8-5. Localized Communication Between RED and BLUE VPNs Note The both command used in the configuration is equivalent to separate import and export statements for the RT specified. Thus, both 2:2 is equivalent to typing import 2:2 and export 2:2 under the same VRF. To interconnect the RED and BLUE VPNs only at Site 1, you must add a new RT to the configuration. In Figure 8-6, we use a value of 5:5 to export and import routes between the BLUE and RED VPNs. By adding the import and export statements on both VRFs (RED and BLUE), we can establish communication between the VRFs. Because this is done only on the site-1 physical router, this includes only routes that are local to Site 1; routes that have been learned from other sites via BGP will not be exchanged across VPNs. Figure 8-6. Inter-VPN Local Connectivity In this manner, you can create localized inter-VPN connectivity if required. A more practical scenario is to create localized extranet VPNs (which just means creating an extranet on a single site). In the example shown in Figure 8-7, this setup implies configuring the extranet only on the routers on Site 1. Doing so provides connectivity only between prefixes and extranet resources local to Site 1. Figure 8-7. Extranet VPN Local Connectivity Local extranet routes are exported with RT 5:5, and local routes are exported with RTs 52:52 and 53:53 for BLUE and RED, respectively. The use of alternate RTs for the BLUE and RED VRFs allows us to ensure that the local extranet VRF is populated only with local routes for RED and BLUE. We could have used the existing 2:2 and 3:3 RTs for BLUE and RED, but this would have installed routes from Sites 2 and 3 on the local extranet VRF for Site 1. Leaking Traffic with the Global TableIn many cases, it is necessary to reach resources in the global table from within a VRF and vice versa. One classic example of this requirement is the deployment of network management stations in a VRF. These stations need to access subnets in the global table that provide management access to provider (P) and provider edge (PE) routers. The mechanisms to use in this case differ from those used to create communication between VRFs. Instead of using MP-BGP, you must use static routes to forward traffic between the global table and the necessary VRFs. The topology in Figure 8-8 illustrates how to achieve this. In the example in this figure, we provide communication between subnet 10.0.2.0/30 in the BLUE VRF and subnet 10.1.2.4/30 in the global routing table. Figure 8-8. Traffic Leaking Between a VRF and the Global Table You can create static routes within a VRF that point to a prefix in the global table by using the physical interface as the next hop to the desired destination. When creating the route from the VRF to the global, a physical interface not assigned to a VRF provides a valid next hop to the global table prefix. When creating the route from the global to the VRF, the next hop is an interface that exists inside the destination VRF. The configuration in PE-4, as shown in Example 8-2, achieves the desired result. Example 8-2. Static Routes Between a VRF and the Global Routing Table
The first static route (IP route 10.0.2.0 255.255.255.252 Serial 2/0) is installed in the global table and provides connectivity in the global to VRF direction. Notice that the next hop is interface Serial 2/0, which is included in the BLUE VRF. The second static route (IP route VRF blue 10.1.2.4 255.255.255.252 Serial 1/0) is installed in the VRF and uses Serial 1/0 as its next hop. Interface Serial 1/0 is not in a VRF and therefore provides a valid next hop to destinations in the global table. When using Ethernet interfaces, you must add a next-hop IP address and the next-hop interface to the static route configuration. This allows the router to determine which IP to resolve through the Address Resolution Protocol (ARP) when using a LAN interface. In our example, the static route in the global would become this: ip route 10.0.2.0 255.255.255.252 Ethernet2 10.0.2.2 The static route from the VRF to the global would be this: ip route vrf blue 10.1.2.4 255.255.255.252 Ethernet1 10.1.2.6 The show commands in Example 8-3 illustrate the resulting routing entries. Example 8-3. Static Route Entries Between VRFs and the Global Routing Table
You can use the global keyword as an alternative configuration to the static route providing connectivity from the VRF to the global table. In the preceding example, the static route in the VRF would become this: ip route vrf blue 10.1.2.4 255.255.255.252 10.1.2.6 global However, there isn't an equivalent keyword in the global-to-VRF direction, so the static route for the return traffic would remain the same: ip route 10.0.2.0 255.255.255.252 Serial2/0 |
EAN: 2147483647
Pages: 128