Scenario 5: Frame Relay Host Migration

During the ebb and flow of business cycles and reorganizations, many consolidations in plant and office locations can take place. These include office moves and closures, which require existing remote access infrastructures to be relocated. In a small to medium-sized remote access Frame Relay environment, it occasionally might become necessary to rehome your remote users to a new location. The following scenario describes how to manage such a move and the required steps to implement a seamless transition between two Frame Relay hosts in different locations.

The example here works on the premise that an office located in Austin, TX, will be closed in a matter of months and relocated to Phoenix, AZ. Fourty remote access circuits are currently configured on a host in the Austin office. These circuits must be remapped to a host in Phoenix.

Working with Your Vendor

One of the first steps is to speak to your vendor to provision a host circuit in the new location. In this case, a Frame Relay T1 is ordered for Phoenix and it is also necessary to map the endpoints onto this host. The end-user locations are most likely geographically dispersed. Service management is simplified if there is one vendor that provisions and installs the endpoint and host circuits because they most likely cross LEC boundaries.

If you anticipate the time frame necessary for the vendor to deliver the service, you can request that the DLCIs be provisioned on top of existing circuits. This means that although you might currently have an existing DLCI mapped onto the end-user circuit, the vendor has the means of configuring another DLCI and mapping it back to Phoenix. This allows you to carry several point-to-point circuits on one Frame Relay line.

You must provide the vendor with new DLCI numbers for the remote users that differ from the previous ones. Make sure that they are sequential and coincide with the way you want to see the mappings. For example, you might want to choose the DLCI range of 100139. This provides a simplified migration when building the new host.

At this point, the vendor must perform a series of tasks to migrate the host from Austin to Phoenix. Initially, they must install the host circuit in Phoenix. Secondly, they must build and provision the new mappings for the remote users, which creates another virtual circuit (VC) at the remote end that points back to the Phoenix host while keeping the existing maps back to Austin. After this is completed, you are ready to perform the tasks required to migrate.

Preparing the Host

Supposing that the vendor performed the required tasks, you are now ready to begin the process of migration. In this example, a 3640 host is used with 1602s at the remote user's premise. Initially, you must configure and set up the new host circuit in Phoenix. Essentially, it should look like the existing installation in Austin, unless features and functionality have been added or removed. For the purposes of this example, start by configuring the T1 controller (see Example 18-48).

Example 18-48. Configuration Commands that Provide Basic Signaling Services for the Frame Relay Host

 3640-frame-phoenix#configure terminal 3640-frame-phoenix(config)# controller T1 1/0 3640-fram(config-controller)# description Frame Relay T1-Phoenix, AZ,     Vendor M Circuit # 83XXXXXXXX 3640-fram(config-controller)# framing esf 3640-fram(config-controller)# fdl ansi 3640-fram(config-controller)# linecode b8zs 3640-fram(config-controller)# channel-group 0 timeslots 1-24 speed 64 

The vendor provides a circuit that runs coding schemes such as Extended Superframe (ESF) framing and bipolar 8-zero substitution (B8ZS) linecoding.

NOTE

It is a recommended practice to use a description of the circuit in the configuration, in case any issues exist with the line.

Next, the corresponding serial interface must be configured to split the host circuit into its corresponding subinterfaces and DLCIs. Traditional Frame Relay lines look like what is shown in Example 18-49.

Example 18-49. These Configuration Commands Allow the Serial Interface to Interact with the Controller Previously Configured

 3640-frame-phoenix#config terminal 3640-frame-phoenix(config)#interface Serial1/0:0 3640-frame-phoenix(config-if)# description T1 Frame Relay Phoenix,     AZ: Vendor M / Circuit #: 83XXXXXXXX 3640-frame-phoenix(config-if)# no ip address 3640-frame-phoenix(config-if)# encapsulation frame-relay IETF 3640-frame-phoenix(config-if)# ip mroute-cache 3640-frame-phoenix(config-if)# frame-relay lmi-type ansi 

An IP address is not used for the host circuit. Frame Relay encapsulation is ANSI LMI. After it is configured, you can check to see if you have the appropriate signaling by performing a show interfaces command (see Example 18-50).

Example 18-50. Output from the show interfaces Command Should Show the Status of the Serial Interface, the Type of Frame Relay Encapsulation and the Type of LMI

 3640-frame-phoenix#show interfaces Serial1/0:0 Serial1/0:0 is up, line protocol is up   Hardware is DSX1   Description: T1 Frame Relay Phoenix, AZ: Vendor M / Circuit #: 83XXXXXXXX   MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,      reliability 255/255, txload 2/255, rxload 1/255   Encapsulation FRAME-RELAY IETF, loopback not set   Keepalive set (10 sec)   LMI enq sent  103431, LMI stat recvd 103431, LMI upd recvd 0, DTE LMI up   LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0   LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE   Broadcast queue 0/64, broadcasts sent/dropped 2304560/0, interface broadcasts 2011528   <output omitted> 3640-frame-phoenix# 

You must also begin the task of configuring the subinterfaces that are mapped to this new host. Enter the commands in Example 18-51, which specify the appropriate subinterfaces and their corresponding DLCIs. The numbering scheme in this example allows the subinterface to correspond to the DLCI of the PVC.

Example 18-51. These Commands Allow Configuration of the Subinterface. It Is a Good Idea to Create These Subinterfaces from a Text File Template

 interface Serial1/0:0.100 point-to-point  description fr 56k frame to johnsmith  ip unnumbered loopback1  frame-relay interface-dlci 100 ! interface Serial1/0:0.101 point-to-point  description 56k frame to nshumpar  ip unnumbered loopback1  frame-relay interface-dlci 101 ! interface Serial1/0:0.102 point-to-point  description 128k frame to okaabipo  ip unnumbered loopback1  frame-relay interface-dlci 102 ! interface Serial1/0:0.103 point-to-point  description 56k frame to djohnson  ip unnumbered loopback1  frame-relay interface-dlci 103 

Further in this example, Loopback1 provides addressing for the subinterfaces (see Example 18-52).

Example 18-52. Interface Loopback1 Provides a Routing Pointer for the Endpoints and Conserves Address Space

 3640-frame-phoenix#config terminal 3640-frame-phoenix(config)# interface Loopback1 3640-frame-phoenix(config-if)# description Vendor M Frame Relay address placeholder 3640-frame-phoenix(config-if) ip address 10.10.0.1 255.255.255.252 

This loopback interface allows communication with the rest of the network as it forwards traffic to the connected serial and Ethernet interfaces.

Routing Options

Based on the assumption that no readdressing is going to be performed and that the new environment will mirror the old, two approaches can be taken with respect to routing.

Method 1: Moving Routes with Ethernet Interface in Shutdown State

This method requires the Ethernet interface to be administratively shutdown. A console must be set up on the Phoenix router to bypass the Ethernet interface, which should be shut down to avoid any adverse routing consequences that might result from having both routes in different locations.

After all the subinterfaces are created and the Ethernet interface is administratively shut down, it is a good idea to copy and paste the IP routes from one router to another. When the transition is complete, the Ethernet interface can be turned up to allow routes to be forwarded if necessary.

Method 2: Host by Host Migration

If a previous method creates too much downtime, it is also possible to enter the routes individually as they are migrated. They must also be removed from the router in Austin. This method brings the users up as soon as the route statement is placed in the Phoenix router.

The decision on which method to use is subjective because it depends on the window of time necessary to migrate the remote users. If the first method is used, the larger the number of endpoints, the longer the downtime for users as the migration proceeds.

After the subinterfaces are ready, the task of migrating the remote users can begin.

Endpoint Migration

The host is now ready and work can begin on migrating the endpoints to this new circuit. The endpoint serial configuration for a 56-k frame line is similar to Example 18-53.

Example 18-53. These Are the Common Command Entries to Configure Endpoint Routers

 1602-frame#config terminal 1602-frame(config)# interface Serial0 1602-frame(config-if)# no ip address 1602-frame(config-if)# encapsulation frame-relay IETF 1602-frame(config-if)# service-module 56k clock source line 1602-frame(config-if)# service-module 56k network-type dds 1602-frame(config-if)# frame-relay lmi-type ansi ! 

The subinterface on 1602 can be configured with an unnumbered interface to conserve IP addresses (see Example 18-54).

Example 18-54. Subinterface Configuration Commands for Endpoint Routers

 1602-frame#config terminal 1602-frame(config)# interface Serial0.1 point-to-point 1602-frame(config-if)# ip unnumbered Ethernet0 1602-frame(config-if)# frame-relay interface-dlci 16 

To configure a new subinterface, you must use the same commands with a different DLCI. Following the numbering guidelines given to the vendor, the task of configuring new subinterfaces can begin. To configure a new subinterface for the DLCI that is mapped to the host in Phoenix, you can enter the commands in Example 18-55. End with CNTL/Z.

Example 18-55. New Configuration Commands for the Endpoint Router

 1602-frame# configure terminal 1602-frame(config)#interface  serial0.100 1602-frame(config-if)# ip unnumbered  Loopback 1 1602-frame(config-if)# frame-relay interface-dlci 100 1602-frame(config-if)#  end 1602-frame# 

Perform a show interfaces command to make sure that the line is operational and has been turned up by the vendor (see Example 18-56).

After it is verified that the PVC is up, the routing should be changed to the new line. For example, assuming static routes, the routing accounts for a default route to the host network, and one back to the remote network. Example 18-57 shows the configuration for the existing network.

Example 18-56. Verifying Proper Configuration and PVC Establishment

 1602-frame# show interfaces serial0.100 Serial0.100 is up, line protocol is up   Hardware is QUICC Serial (with onboard CSU/DSU)   Interface is unnumbered.  Using address of Ethernet0 (10.84.5.105)   MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,   reliability 255/255, txload 1/255, rxload 1/255   Encapsulation FRAME-RELAY 1602-frame# 

Example 18-57. Endpoint and Host Routing Configuration

 1602-frame#configure terminal 1602-frame(config)# ip route 0.0.0.0 0.0.0.0 Serial 0.1 1602-frame(config)# ip route 10.10.10.0 255.255.255.248 Ethernet0 

To migrate this service over the new PVC, a simple routing command must be entered to the core router configuration to complete the migration of this PVC:

 3640-frame-phoenix(config)#ip route 10.10.10.0 255.255.255.248 Serial 0.100 

By entering this command, you can now route data over the new PVC rather than the old. If the route statements already exist in the Phoenix host, this service is now operational. The default routes for the old host are replaced in favor of routes to the new host. Additionally, routes from the Austin router must be removed prior to reenabling the interfaces. Now, the Austin router is ready to be decommissioned.

If Method 1 is used to migrate, after all the remote users are moved over, the routes can be removed from the Austin router, and the Ethernet interface for Phoenix can be turned up to advertise the new routes in a different location.

As long as the routes are placed in the new host, the endpoint is reachable from the new location.