PE-router Provisioning and Scaling
When provisioning an MPLS/VPN solution, one of the major concerns is how to scale the PE-router configuration and what limits should be drawn so that the configuration can scale. This is certainly not a trivial exercise, and numerous factors will affect this scaling, some of which we will cover during this section. There are no "magic" numbers relevant to each and every design, and the limitations that will be used very much depend on the actual deployment and design requirements.
As with all new technologies, deployment experience is generally sketchy (at best). Therefore, only limited information is available for any design decisions. An amount of theoretical data must be used. This does not mean that a successful deployment of the architecture cannot take place, although a certain amount of tuning may need to occur during the deployment phases of the design so that an optimal production environment is produced.
The first implication of the MPLS/VPN architecture to understand is that each of the PE-routers does not need to carry every route that belongs to the customers of the VPN service. This means that, potentially, the amount of memory required to hold BGP routes may be reduced. However, the information within the BGP routes is increased to include such things as extended attributes, which must be held in memory.
Multiple VRFs may be used within the PE configuration. There is no hard limit on the number of VRFs that can be configured on a PE-router?this is bounded by the number of interfaces. A certain number of data structures is required for each VRF, but this does not cause a significant amount of memory increase. Each VRF can hold as many routes as it needs. The only limit on this, as with standard BGP routing, is the amount of available memory on the PE-router. This is the real limit on PE scaling, and exactly how many routes can be held in a router will depend on such things as the number of BGP neighbors that advertise the routes and the amount of memory required to store the attributes contained within the paths of the routes.
Note
To place an upper limit on the memory usage incurred by each VRF, you can use the maximum routes command in the VRF definition to limit the total number of routes that can reside in a VRF. You also can use neighbor maximum-prefix command to limit the number of routes received from a CE-router running BGP with the PE-router.
When provisioning for PE-to-CE connectivity, it is important to bear in mind that the current IOS implementation provides a maximum of 32 protocol descriptor blocks (PDBs) per PE-router. One PDB is used per protocol instance, including static and connected. Therefore, careful design is required when provisioning the PE-router so that no more than 32 protocol instances are planned for.
If BGP is used between PE- and CE-routers, then only one BGP process is required and only 1 PDB is used. Even if you use BGP in several VRFs, they are considered as different routing contexts that run within the same BGP process. The situation is similar with RIP if multiple routing contexts within the RIP process are configured. However, if OSPF is used for PE-CE connectivity, separate OSPF processes are required (one per VRF), and one PDB is used per VRF where you run an OSPF process.
For example, consider a PE-router in which you have to run BGP with some sites, OSPF with the majority of the sites, RIP with a few sites, and static routing toward the rest of the sites. If all the sites for each routing protocol instance were contained within the same VRF, then only six PDBs would be necessary (one for BGP, one for OSPF, one for RIP, one for static routing, one for connected routing, and one for the service provider backbone IGP). However, if each site belonged to a different VRF, then the number of PDBs would increase.
