nctions: constructing routing tables for the paths between VPN sites, by using any routing technology (such as OSPF, RIP, or a border gateway protocol), and forwarding packets to the next hops within the VPN domain. From a VPN user's point of view, a virtual router provides the same functional- ity as a physical router. Separate routing and forwarding capabilities provide each virtual router with the appearance of a dedicated router that guarantees isolation from the traffic of other VPNs while running on shared forwarding and transmis- sion resources. To the customer edge access device, the virtual router appears as a neighbor router in the customer edge-based network. Three main virtual router deployment scenarios can be used for building VPNs: virtual router-to-virtual router connectivity over a Layer 2 connection, vir- tual router-to-virtual router connectivity tunneled over an IP or MPLS network, and aggregation of multiple virtual routers over a backbone virtual router to pro- vide connectivity over a Layer 2 IP or MPLS network. These virtual router deploy- ment scenarios can coexist on a single provider edge or within a single VPN. RFC 2547 VPNs Versus Virtual Router VPNs Table 9.2 compares the RFC 2547 VPN and virtual router VPN architectures. The standards debate is ongoing, with high-profile companies on both sides of the argument. For now, the choice of a network-based VPN implementation is up to the provider. All these IP VPN services are more complicated to configure and require more attention from both carriers and customers than Frame Relay, private- line, or ATM services. Without any application or architectural triggers for the cus- tomer to move to IP VPN service, the shift may be very gradual. Layer 2 VPNs Carriers need to continue to benefit from legacy services such as TDM private lines, Frame Relay, and ATM while they introduce new Ethernet metro-transport and Ethernet access services. They need a common edge infrastructure that supports both new and legacy services and allows all the servic