Another important requirement is the capability to build extranets without compromising the security of the intranet. For example, an automobile manufacturer might want a corporate intranet for communicating between sites and factories but also require an extranet to communicate to dealers. The auto dealers are selling the cars, so it is crucial for the automobile manufacturer to be able to communicate quickly and effectively with the dealers regarding ordering, shipping, and maintenance and recalls. All this must be done without compromising the intranet's security. With MPLS VPNs, communication is fairly easy. Let us suppose that an intranet contains the following routes: 10.20/16 10.30/16 10.100/16 All the transaction hosts for order entry and tracking that are accessed by dealers are in the 10.100/16 domain. The dealer extranet contains all the dealer routes. Those can be any public or private routes. For the dealers to access the transaction servers for order placement, only the 10.100/16 routes need to be imported into the extranet VRF, in addition to the dealer routes. This provides connectivity between the dealers and the automobile manufacturer without compromising the security of the automobile manufacturer's intranet. If the attackers in the dealer networks send packet to hosts in different subnets, such as 10.20/16 or 10.30/16, the PEs won't know where to send those packets because there are no routes for 10.20/16 in the extranet VRF; thus, packets to all routes outside the extranet are dropped. Refer to Figure 5-3 for details on how routes are imported into VRFs. From the previous example, it can be easily observed that in the MPLS VPNs environment, you can create extranets just by performing a few simple configuration steps on a PE. Figure 5-3. Importing Routes into VRFs |