Intranet and Extranet Integration
Extranet support within the context of the MPLS/VPN architecture simply involves the import of routes from one VRF into a different VRF that services another VPN site. As we have seen in previous chapters, this is controlled through the use of the route target BGP extended community and import statements within the VRF that is associated with the particular VPN site. An example of this type of connectivity is illustrated in Figure 11-1.
From the figure, we can see that two separate organizations are capable of communicating directly across the MPLS/VPN backbone as they import each other's routes into their relevant VRFs.
If we examine the EuroBank London site, for example, we can see that it has its routes advertised with a route target value of 1234:17. All other PE-routers that have EuroBank sites (or FastFoods sites) attached are configured to import any routes that contain a route target with a value of 1234:17 into the EuroBank and FastFoods VRFs. These PE-routers are also configured to import any routes that contain a route target value of 1234:18, which corresponds to the FastFoods VPN, into both of these VRFs.
Figure 11-1. Extranet VPN Connectivity Between Sites
Because all the FastFoods site routes are advertised across the MPLS/VPN backbone with a route target value of 1234:18, these routes are also imported into the EuroBank and FastFoods VRFs. This means that all EuroBank and FastFoods sites have both EuroBank and FastFoods routes within their local routing table and, therefore, have connectivity across organizations.
This type of topology can be enhanced further through manipulation of the route target. In Figure 11-2, the EuroBank VPN customer has added a central site to the topology with which only EuroBank sites should be capable of communicating.
The example in Figure 11-2 shows that the EuroBank central site exports its routes with a route target value of 1234:19. Routes that contain this route target value are imported into the EuroBank VRF on all PE-routers, but not into the FastFoods VRF because this has not been configured to import routes with this particular route target value. This means that only the EuroBank sites are capable of accessing the central site, but they are also still capable of accessing the FastFoods sites. However, the FastFoods sites are not capable of accessing the EuroBank central site, even though they import routes from the EuroBank VPN.
Figure 11-2. Extranet VPN Connectivity with Central Site Access
Note
It should be noted that with this type of connectivity, IP address space between the two different VPN customers should be unique. In our example, if the FastFoods sites were to use the same address space as the EuroBank central site (or any other EuroBank site), and vice versa, connectivity would be broken because sites would receive the same set of routes from two different locations.
Note
In the extranet example shown in Figure 11-2, it is possible for users from a FastFoods site to use Telnet to access the central EuroBank router (or an unprotected host at the EuroBank central site) and then access other EuroBank hosts or routers. Therefore, it is important, as with any other type of connectivity, to make sure that adequate security arrangements, such as access-list filtering, are in place to prevent this type of attack.
