Before any migration to an MPLS solution can occur, whether across a pure router network or a network that consists of ATM switches, certain pre-migration steps must be completed.
As we have already discussed in the previous section, one of the advantages of running MPLS within the core of a service provider network is the capability to remove BGP information from transit routers. This means that all customer routes must be carried within BGP, which is good design practice for several reasons:
BGP is the only protocol that can scale to a large number of routes; this is one of the design goals of the protocol.
As external routing is carried within BGP, the internal routing structure of the network is protected from outside influence such as route flapping.
Quality of service policy can be distributed using BGP (such as QoS policy propagation for BGP [QPPB]) so that differentiated service can be provided to individual customers using the BGP community attribute.
The injection of a large number of routes into the IGP reduces the performance of the protocol and leads to stability and scalability issues.
The migration of customer routes into BGP is covered in more detail in Chapter 13, "Guidelines for the Deployment of MPLS/VPN."
The configuration of the internal BGP sessions should include the use of the next-hop-self command (in conjunction with update-source loopback xx) within the BGP configuration so that the BGP next hop of the customer routes is one of the loopback interface addresses of the advertising edge router. This is necessary so that customer interface addresses do not have to be redistributed in the IGP of the service provider. This also provides a more stable environment for the BGP sessions between edge routers.
After all external routes are carried within BGP, the next premigration step is to enable Cisco Express Forwarding (CEF) on all routers within the network. CEF is a fundamental requirement of the Cisco implementation of the MPLS architecture and must be enabled globally on all routers.
It is not necessary to enable CEF on all interfaces within the backbone?only on those that will perform label imposition, such as inbound interfaces on edge LSRs. However, if there is no particular reason to disable CEF on an interface, then we recommend that it be enabled across the network on all interfaces. To enable CEF globally, use the command ip cef or ip cef distributed (if distributed CEF on the 75xx series is required). To disable CEF on an interface basis, use the no ip route-cache cef or no ip route-cache distributed commands.
If distributed CEF is disabled on an interface, then CEF switching of packets will still occur, although this will occur on the 75xx RSP rather than the interface. If CEF switching must be disabled for the 75xx interface completely, then the command no ip route-cache cef is also required.