Frame Relay Configuration on Cisco Devices

Now that you have learned the Frame Relay basics, this section details how to configure Cisco devices for use with a Frame Relay network. As a quick review, it is essential to know what kind of circuit you are using for the Frame Relay connection. Many Cisco devices that have channel service unit/data service unit (CSU/DSU) functionality already have Frame Relay capability built into the IOS. Verify that your IOS supports what you need in Frame Relay.

It is also important to know what your CIR and LMI are for your Frame Relay connection(s). If you are setting up multiple sites, you need to have this information available for each site. You also need to have the DLCIs for each site so that you can set up the proper PVCs between sites. After you have all that information, you are ready to begin.

The Frame Relay design you are working with is rather simple, but it gives you an idea of what types of things to configure and look out for. Figure 9-11 shows the Frame Relay network that you are configuring in this example. This is a public Frame Relay configuration.

Figure 9-11 Example Frame Relay Network for Configuration

Serial 0 CSU/DSU

Figure 9-11 Example Frame Relay Network for Configuration

Serial 0 CSU/DSU

Serial 0

Picture Fram Configurations

San Diego FRAD

Serial Link from CSU/DSU -

Serial 0

San Diego FRAD

Serial Link from CSU/DSU -

Three different locations exist within the Frame Relay network topology in Figure 9-11. All three locations need to be configured to communicate with the Frame Relay switching fabric but do not need to be configured to communicate with all the other devices. Because this is a public configuration, it is up to the service provider's Frame Relay switches to determine the paths between nodes.

Example 9-1 shows the Vancouver FRAD configuration.

Example 9-1 Vancouver FRAD

Vancouver>enable Vancouver#configure terminal Vancouver(config)#interface serial 0

Vancouver(config-if)#ip address 192.168.2.26 255.255.255.0 Vancouver(config-if)#encapsulation frame-relay ietf Vancouver(config-if)#frame-relay interface-dlci 210 Vancouver(config-if)#frame-relay lmi-type q933a

Vancouver(config-if)#no shutdown

The FRAD located in Vancouver is configured with an IP address of 192.168.2.26 with a 24-bit mask. The Frame Relay encapsulation type is set to ietf. You can leave it at the default of cisco if you are certain that you are communicating only with Cisco devices. If you are unsure or you know that you are communicating with other vendor equipment, it is required that you use ietf. The DLCI is set for 210 and the LMI type has been explicitly set up for Annex A operation (q933a). The frame type of ietf specifies the format of the header of each Frame Relay frame and is not related to the signaling between the customer premises equipment (CPE) and the ingress switch. This is the job of the lmi-type command (q933a).

Example 9-2 shows the San Diego FRAD configuration.

Example 9-2 San Diego FRAD SD>enable

SD#configure terminal SD(config)#interface serial 0

SD(config-if)#ip address 192.168.1.25 255.255.255.0 SD(config-if)#encapsulation frame-relay ietf SD(config-if)#frame-relay interface-dlci 200

SD(config-if)#no shutdown

The FRAD located in San Diego has been configured with an IP address of 192.168.1.25 with a 24-bit mask. Again, the Frame Relay encapsulation type has been set to ietf. The DLCI has been configured for 200. No LMI type is set because auto LMI was specified in the topology. Auto LMI is the default configuration. It detects the LMI type if LMI is not explicitly set.

Example 9-3 shows the Denver FRAD configuration.

Example 9-3 Denver FRAD

Denver>enable Denver#configure terminal Denver(config)#interface serial 0

Denver(config-if)#ip address 192.168.3.27 255.255.255.0 Denver(config-if)#encapsulation frame-relay ietf Denver(config-if)#frame-relay interface-dlci 200 Denver(config-if)#frame-relay lmi-type cisco

Denver(config-if)#no shutdown

The FRAD located in Denver has been configured with an IP address of 192.168.3.27 with a 24-bit mask. The encapsulation type has been set as ietf, and the DLCI has been configured for 200. Remember, DLCIs are only locally significant and can be the same value at multiple locations. After the traffic leaves the FRAD and gets to the Frame Relay switch, the DLCI can change on the next hop. Also remember that after the Frame Relay switch, the network can convert into a completely different technology such as ATM. The LMI type has been set to cisco on the Denver FRAD, which means that you are using the original Gang of Four LMI type.

These configuration examples show three endpoints that are not related to one another. This separation is evidenced by the fact that each serial interface is in a different IP subnet. Although DLCIs are locally significant between directly connected interfaces and do not need to be numerically equivalent, those DLCIs that face each other on an end-to-end basis must be in the same subnet.

Furthermore, one of these sites can be made into a hub and logically connect, through IP routing, the remaining two sites (referred to as the spokes of the hub). As such, the hub location can be configured with sub-interfaces of the same physical serial interface. A subinterface is characterized by multiple streams of data. Each stream is destined for a different endpoint, and all of them are multiplexed into a single stream that emanates from the same physical interface.

In the case of a hub-and-spoke arrangement, the sub-interfaces of the same physical interface need to be placed in separate IP subnets, with each subnet matching that of the remote Frame Relay interface to which it is virtually connected. The primary serial interface has its IP address removed, as all of the IP activity occurs on the sub-interfaces. On the remote devices at the end of the hub's spokes, the VCs related to those of the subinterfaces on the hub can be established on the primary serial interfaces of the spoke routers. In other words, a sub-interface can, but is not required to, face another subinterface.

This example is not necessarily how every service provider sets up their network, and there is no guarantee that you will use the same service provider throughout your network topology. Nevertheless, this example should give you a good understanding of some of the basic configuration steps required for Frame Relay.

Continue reading here: ATM and BISDN

Was this article helpful?

0 0

Readers' Questions

  • Reima Laukkanen
    How to set up a csudsu for frame relay?
    1 year ago