A migration to Cell-mode MPLS from a PV C-based topology is more involved than the migration of a router-only frame-based MPLS topology. This type of migration requires several stages to allow the existing infrastructure to be switched over to the new MPLS topology with minimal disruption to IP traffic.
In the previous section, we saw that the TransitNet backbone was converted to an MPLS solution across ATM PVCs as a temporary measure. This type of solution involves all the scaling issues that we have already discussed, so a migration to a full Cell-mode
implementation is desirable.
As part of the migration, all existing ATM PVCs must be maintained so that minimal disruption to traffic is achieved. In the case of the TransitNet backbone, in which the ATM topology is provided through use of Cisco BPX switches, this can be achieved by
partitioning the ATM link from the ATM edge LSR to the BPX ATM-LSR so that both MPLS- and standards-based ATM PVCs can coexist across the same physical media. Figure 6-7 shows this topology.
Figure 6-7 Coexistence of MPLS and ATM PVCs
As Figure 6-7 shows, each BPX (or LS1010) switch can be converted to an MPLS-aware switch while maintaining the existing PVC-based topology. Using this method of migration,
the following steps can be used to provide a staged transfer of traffic onto the new MPLS solution:
• Enable the ATM switch for participation in the MPLS topology. This will include all necessary software upgrades, configuration of the switches (including the partitioning of the switch trunks), and the addition and configuration of a Label Switch Controller (LSC) in the case of BPX implementations.
• When the ATM switch is ready for participation in the MPLS topology, each interface that will carry both MPLS and ATM PVC traffic must be configured. On the BPX, this includes the partitioning of the physical interface to carry MPLS traffic in one partition and AuroRoute traffic in the other partition. On the LS1010, this includes the
configuration of the PVCs (which will already exist) and the enabling of MPLS on the physical interface.
• The next step is the configuration of the ATM edge LSR. Because it is necessary to continue to use the existing PVCs during the migration, a further subinterface must be configured that will be used to carry MPLS traffic. The IGP cost of this interface must be higher than the interface that will carry the PVC traffic so that the PVC-based interface is always preferred over the MPLS interface. Multiple hops will exist across the MPLS path, so the cost of the MPLS interface should, in most cases, be greater by default, and no further configuration will be necessary.
• When everything is configured and MPLS functionality is tested across the ATM network, the last stage of the migration is to increase the IGP cost of the PVC
interface so that the MPLS-enabled interface is preferred. This will cause labels to be requested from the downstream ATM-LSR, and label switching of traffic will be
achieved.
Note
For a discussion and configuration examples of running both MPLS and PVCs acro ss the same ATM interface, refer to Chapter 4.
Summary
In this chapter, you've seen several potential migration strategies from classical IP backbones toward MPLS-enabled backbones. These strategies should serve only as a starting point for your own migration strategy, of course, because every network has its own specific requirements. Regardless of which strategy is adopted, a number of common steps must be followed in every network migration toward an MPLS-enabled backbone.
Start with these preparatory steps:
Step 1. Determine the required software and firmware versions for all network devices in your network, based on their hardware configuration.
Step 2. Determine memory requirements and any other potential upgrade requirements for all network devices in your network.
Step 3. Determine the impact that MPLS might have on your network management system, specifically in areas of accounting and billing. You might use NetFlow or IP accounting on the core routers, which will cease to function as soon as these routers start forwarding labeled packets.
Step 4. Test the target software version on your typical hardware platforms in a controlled lab environment to ensure that the software will be stable in your target network.
Step 5. Based on the upgrade requirements, you might decide to perform partial or full migration. (This decision is even more important if you have ATM switches in your network.) Migrate your router-based network to MPLS by following these steps:
Step 1. Upgrade your network devices to the target software version. Verify that your network is stable.
Step 2. If you're running BGP in your network and you plan to remove BGP from your core routers after the migration to an MPLS infrastructure, design your new BGP structure and implement it in parallel with your old structure.
Step 3. Migrate the router part of your network. For networks using an ATM core
infrastructure, retain the traditional ATM PVC setup and run MPLS over the ATM Forum PVCs as an interim step.
Step 4. Verify that your network is stable and performs label switching as planned. Verify that the core routers forward only labeled packets.
Step 5. Remove BGP from the core routers if needed. Verify that the network still performs as planned.
The following additional steps must be performed if you're migrating ATM switches toward MPLS as well:
Step 1. Migrate the ATM part of your network by upgrading ATM switches and establishing a parallel Cell-mode MPLS infrastructure. Verify that the Cell-mode MPLS infrastructure performs as expected.
Step 2. Using IGP cost, move your traffic from ATM Forum PVCs toward a Cell-mode MPLS infrastructure. Verify that the Cell-mode MPLS works as planned.
Step 3. Remove ATM Forum PVCs from your ATM network.