A common requirement within most network deployments will be that Internet access is available to some or all sites within a VPN. This Internet access may be provided through a different service provider than the one offering the MPLS/VPN service, or it may be through the same organization. If Internet access to VPN members is provided across the same infrastructure as the MPLS/VPN service offering, then this Internet access to certain member sites of a specific VPN can be achieved in several ways within the MPLS/VPN architecture.
Some deployments will require that connectivity between VPN members and the Internet be achieved through a firewall; other implementations will not. Some will require central site access only, while others will require connectivity from any site to the Internet directly across the backbone. It is important to remember that any of the methods described within this section are valid; the choice of which one to deploy will depend largely on the given topology of the customer sites and the customer connectivity and security requirements.
Again, a sample topology, shown in Figure 12-19 will serve as the reference backbone network to help explain all the Internet connectivity options.
Figure 12-19 shows the SuperCom backbone that is providing an MPLS/VPN service to its VPN customers, and also provides Internet access through its New York POP. Full routing is taken from the Internet and propagated to some of the PE-routers.
The propagation of full routing to the PE-routers is a design choice and depends on whether any of the VPN or non-VPN customers require full Internet routing. A typical example of a customer requiring full routing would be a smaller Internet service provider buying Internet connectivity from the service provider, or a multihomed customer running BGP with more than one service provider. If full routing is not a requirement, then default routing is the recommended design choice because it lowers the memory requirements and CPU load on the PE-routers.