|
|
This chapter describes the tasks for configuring Frame Relay on the router. For a complete description of the commands mentioned in this chapter, refer to the "Frame Relay Commands" chapter in the Router Products Command Reference publication. For historical background and a technical overview of Frame Relay, see the Internetworking Technology Overview publication.
Although Frame Relay access was originally restricted to leased lines, dial-up access is now supported. For more information, see the "Configure DDR over Frame Relay" section in the "Configuring DDR" chapter of this publication.
To install software on a new router by downloading software from a central server over an interface that supports Frame Relay, see the "Loading System Images, Microcode Images, and Configuration Files" chapter in this publication.
To configure access between SNA devices over a Frame Relay network, see the "Configuring SNA Frame Relay Access Support" chapter of this publication.
Cisco's Frame Relay implementation currently supports routing on IP, DECnet, AppleTalk, Xerox Network Service, Novell IPX, ISO CLNS, Banyan VINES, and transparent bridging.
The Frame Relay software provides the following capabilities:
Note The ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone (CCITT).
Frame Relay switching is used when all traffic arriving on one DLCI can be sent out on another DLCI to the same next-hop address. In such cases, the router does not have to examine the frames individually to discover the destination address, and as a result, the processing load on the router decreases.
One of the following hardware configurations is possible for Frame Relay connections:
Note A Frame Relay network is not required to support only routers that are connected directly or only routers connected via CSU/DSUs. Within a network, some routers can connect to a Frame Relay switch through a direct connection and others through connections via CSU/DSUs. However, a single router interface configured for Frame Relay can be only one or the other.
The CSU/DSU converts V.35 or RS-449 signals to the properly coded T1 transmission signal for successful reception by the Frame Relay network. Figure 9-1 illustrates the connections between the different components.
The Frame Relay interface actually consists of one physical connection between the network server and the switch that provides the service. This single physical connection provides direct connectivity to each device on a network, such as a StrataCom FastPacket wide-area network.
There are required, basic steps you must follow to enable Frame Relay for your network. In addition, you can customize Frame Relay for your particular network needs and monitor Frame Relay connections. The following sections outline these tasks. The tasks in the first three sections are required.
The following sections describe these tasks. See the examples at the end of this chapter for ideas of how to configure Frame Relay on your network. See the "Frame Relay Commands" chapter in the Router Products Command Reference publication for information about the commands listed in the tasks.
To set Frame Relay encapsulation at the interface level, perform the following tasks beginning in global configuration mode:
| Task | Command |
|---|---|
Specify the serial interface, and enter interface configuration mode. |
|
| 1This command is documented in the "Interface Commands" chapter of the Router Products Command Reference publication. |
Frame Relay supports encapsulation of all supported protocols except bridging in conformance with RFC 1490, allowing interoperability between multiple vendors. Use the IETF form of Frame Relay encapsulation if your router is connected to another vendor's equipment across a Frame Relay network. IETF encapsulation is supported at either the interface level or on a per-DLCI (map entry) basis.
For an example of how to enable Frame Relay and set the encapsulation method, see the sections "IETF Encapsulation Examples" and "Two Routers in Static Mode Example" later in this chapter. Also see the "Configuring Interfaces" chapter if you want to configure subinterfaces on serial interfaces running Frame Relay encapsulation.
Dynamic address mapping uses Frame Relay Inverse ARP to request the next-hop protocol address for a specific connection, given its known DLCI. Responses to Inverse ARP requests are entered in an address-to-DLCI mapping table on the router; the table is then used to supply the next-hop protocol address or the DLCI for outgoing traffic.
Inverse ARP is enabled by default for all protocols it supports, but can be disabled for specific protocol-DLCI pairs. As a result, you can use dynamic mapping for some protocols and static mapping for other protocols on the same DLCI. You can explicitly disable Inverse ARP for a protocol-DLCI pair if you know the protocol is not supported on the other end of the connection. See the "Disable or Reenable Frame Relay Inverse ARP" section later in this chapter for more information.
Because Inverse ARP is enabled by default for all protocols that it supports, no additional command is required to configure dynamic mapping on an interface.
A static map links a specified next-hop protocol address to a specified DLCI. Static mapping removes the need for Inverse ARP requests; when you supply a static map, Inverse ARP is automatically disabled for the specified protocol on the specified DLCI.
You must use static mapping if the router at the other end either does not support Inverse ARP at all or does not support Inverse ARP for a specific protocol that you want to use over Frame Relay.
To establish static mapping according to your network needs, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Define the mapping between a next-hop protocol address and the DLCI used to connect to the address. |
frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco] |
The supported protocols and the corresponding keywords to enable them are as follows:
You can be greatly simplify the configuration for the Open Shortest Path First (OSPF) protocol by adding the optional broadcast keyword when doing this task. See the frame-relay map description in the Router Products Command Reference publication and the examples at the end of this chapter for more information about using the broadcast keyword.
For an example of how to establish static address mapping, see the sections "Two Routers in Static Mode Example," "DECnet Routing Example," and "IPX Routing Example" later in this chapter.
Our Frame Relay software supports the industry-accepted standards for addressing the Local Management Interface (LMI), including the Cisco specification. To configure the LMI, complete the tasks in the following sections. The tasks in the first two sections are required.
If the router is attached to a public data network, the LMI type must match the type used on the public network. Otherwise, you can select an LMI type to suit the needs of your private Frame Relay network.
You can set one of three types of LMIs on our router: ANSI T1.617 Annex D, Cisco, and ITU-T Q.933 Annex A. To do so, perform the following task in interface configuration mode:
The default LMI type is cisco.
For an example of how to set the LMI type, see the "Pure Frame Relay DCE Example" section later in this chapter.
A keepalive interval must be set to enable the LMI. By default, this interval is ten seconds and, per the LMI protocol, must be less than the corresponding interval on the switch. To set the keepalive interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
This command has the same effect as the keepalive interface configuration command.
For an example of how to specify an LMI keepalive interval, see the "Two Routers in Static Mode Example" section later in this chapter.
You can set various optional counters, intervals, and thresholds to fine-tune the operation of your LMI DTE and DCE devices. Set these attributes by performing one or more of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Set the polling verification timer on a DCE or NNI interface. |
|
Set a full status polling interval on a DTE or NNI interface. |
|
See the "Frame Relay Commands" chapter in the Router Products Command Reference publication for details about commands used to set the polling and timing intervals.
Perform the tasks in the following sections to customize Frame Relay:
Frame Relay networks provide multiple point-to-point links, or permanent virtual circuits (PVCs), through the same physical serial interface. Subinterfaces allow blocks of one or more Frame Relay PVCs to be treated as separate subnetworks. A subinterface with a single Frame Relay PVC is modeled as a point-to-point link. A subinterface with multiple Frame Relay PVCs is modeled as a LAN. Protocols such as IP, IPX, and bridging view each subinterface as a separate interface with its own address and protocol assignments.
Subinterfaces provide a mechanism for supporting partially meshed Frame Relay networks. In the past, a single network number (such as an IP subnet or an IPX network number) was assigned to an entire Frame Relay network. Most protocols assume transitivity on a logical network; that is, if station A can talk to station B, and station B can talk to station C, then station A should be able to talk to station C directly. This is true on LANs, but is not true on Frame Relay networks unless they are fully meshed. Additionally, certain protocols such as AppleTalk and transparent bridging could not be supported on partially meshed networks because they require "split horizon," in which a packet received on an interface cannot be transmitted out the same interface even if the packet is received and transmitted on different virtual circuits.
Subinterfaces address these limitations by providing a way to subdivide a partially meshed Frame Relay network into a number of smaller, fully meshed (or point-to-point) subnetworks. Each subnetwork is assigned its own network number and appears to the protocols as if it is reachable through a separate interface. (Note that point-to-point subinterfaces can be unnumbered for use with IP, reducing the addressing burden that might otherwise result.)
For example, suppose you have a five-node Frame Relay network (see Figure 9-2) that is partially meshed (Network A). If the entire network is viewed as a single subnetwork (with a single network number assigned), most protocols assume that node A can transmit a packet directly to node E, when in fact it must be relayed through nodes C and D. This can be made to work with certain protocols (for example, IP) but will not work at all with other protocols (for example, AppleTalk) because nodes C and D will not relay the packet out the same interface on which it was received. One way to make this work fully is to create a fully meshed network (Network B), but that requires a large number of PVCs, which may not be economically feasible.
Using subinterfaces, the Frame Relay network can be subdivided into three smaller networks (Network C) with separate network numbers. Nodes A, B, and C are connected to a fully meshed network, and nodes C and D, as well as nodes D and E are connected via point-to-point networks. In this configuration, nodes C and D would see two subinterfaces, allowing them to forward packets without violating split horizon rules. If transparent bridging is being used, each subinterface is viewed as a separate bridge port.
To configure subinterfaces on a Frame Relay network, perform the following tasks:
| Task | Command |
|---|---|
| Step 1. Specify a serial interface. | |
| Step 2. Configure Frame Relay encapsulation on the serial interface. | |
| Step 3. Specify a subinterface. | interface serial number.subinterface-number [multipoint | point-to-point]1 |
| 1This command is documented in the "Interface Commands" chapter of the Router Products Command Reference publication. |
Subinterfaces can be configured for multipoint or point-to-point communication. Multipoint is the default.
Once you have defined the subinterface, perform the tasks in the following sections in interface configuration mode. You must perform one of the tasks in the first three sections; the task in the fourth section is optional:
If you define a subinterface for multipoint communication, you do not need to associate a DLCI with the subinterface (and you cannot use the frame-relay interface-dlci command). If you define a subinterface for point-to-point communication, you do not need to establish mapping (and you cannot use the frame-relay map command). The frame-relay inverse-arp command is designed for use with an interface configured for multipoint communication and should not be used for a subinterface configured for point-to-point communication.
Note If you define a subinterface for point-to-point communication, you cannot reassign the same subinterface number to be used for multipoint communication without first rebooting the router. However, you can use a different subinterface number.
For an example of how to define a subinterface, see the section "Basic Subinterface Examples" later in this chapter.
You must associate a Frame Relay DLCI with a subinterface to use subinterfaces in the Frame Relay network for point-to-point communication. If you associate a DLCI with a point-to-point subinterface, you cannot use the frame-relay map command.
To associate a DLCI with a subinterface, perform the following task in interface configuration mode:
For an example of how to associate a DLCI with a subinterface, see the section "Basic Subinterface Examples" later in this chapter.
You can configure static or dynamic address mapping on subinterfaces, just as you can on major interfaces.
Dynamic address mapping uses Frame Relay Inverse ARP to request the next-hop protocol address for a specific connection, given its known DLCI. Responses to Inverse ARP requests are entered in an address-to-DLCI mapping table on the router; the table is then used to supply the next-hop protocol address or the DLCI for outgoing traffic.
Inverse ARP is enabled by default for all protocols it supports, but can be disabled for specific protocol-DLCI pairs. As a result, you can use dynamic mapping for some protocols and static mapping for other protocols on the same DLCI. You can explicitly disable Inverse ARP for a protocol-DLCI pair if you know the protocol is not supported on the other end of the connection. See the "Disable or Reenable Frame Relay Inverse ARP" section later in this chapter for more information.
Because Inverse ARP is enabled by default for all protocols that it supports, no additional command is required to configure dynamic mapping on an interface.
A static map links a specified next-hop protocol address to a specified DLCI. Static mapping removes the need for Inverse ARP requests; when you supply a static map, Inverse ARP is automatically disabled for the specified protocol on the specified DLCI.
You must use static mapping if the router at the other end either does not support Inverse ARP at all or does not support Inverse ARP for a specific protocol that you want to use over Frame Relay.
To establish static mapping according to your network needs, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Define the mapping between a next-hop protocol address and the DLCI used to connect to the address. |
frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco] |
The supported protocols and the corresponding keywords to enable them are as follows:
You can be greatly simplify the configuration for the Open Shortest Path First (OSPF) protocol by adding the optional broadcast keyword when doing this task. See the frame-relay map description in the Router Products Command Reference publication and the examples at the end of this chapter for more information about using the broadcast keyword.
For an example of how to establish static address mapping, see the sections "Two Routers in Static Mode Example," "DECnet Routing Example," and "IPX Routing Example" later in this chapter.
Both point-to-point and multipoint Frame Relay subinterfaces can be configured with a backup interface. This allows individual PVCs to be backed up in case of failure rather than depending on the entire Frame Relay connection to fail before the backup takes over. You can configure a subinterface for backup on failure only, not for backup based on loading of the line.
If the serial interface has a backup interface, it will have precedence over the subinterface's backup interface in the case of complete loss of connectivity with the Frame Relay network. As a result, a subinterface backup is activated only if the serial interface is up, or if the serial interface is down and does not have a backup interface defined. If a subinterface has failed while its backup is in use, and then the serial interface goes down, the subinterface backup stays connected.
To configure a backup interface for a Frame Relay subinterface, perform the following tasks, beginning in global configuration mode:
| Task | Command |
|---|---|
| Step 1. Specify the interface. | |
| Step 2. Configure Frame Relay encapsulation. | |
| Step 3. Configure the subinterface. | interface serial number.subinterface-number point-to-point1 |
| Step 4. Specify a DLCI for the subinterface. | |
| Step 5. Specify a backup interface for the subinterface. | backup interface serial number1 |
| Step 6. Specify backup enable and disable delay. | backup delay enable-delay disable-delay1 |
| 1This command is documented in the "Interface Commands" chapter of the Router Products Command Reference publication. |
Frame Relay switching is a means of switching packets based upon the DLCI, which can be looked upon as the Frame Relay equivalent of a MAC address. The switching is performed by configuring your router as a Frame Relay network. There are two parts to a Frame Relay network: a Frame Relay DTE (the router) and a Frame Relay DCE switch. Figure 9-3 illustrates this concept.
In Figure 9-3, Routers A, B, and C are Frame Relay DTEs connected to each other via a Frame Relay network. Our implementation of Frame Relay switching allows our routers to be used as depicted in this Frame Relay network.
Perform the tasks in the following sections, as necessary, to configure Frame Relay switching:
These tasks are described in the following sections.
You must enable packet switching before you can configure it on a Frame Relay DTE, DCE, or with Network to Network Interface (NNI) support. Do so by performing the following task in global configuration mode before configuring the switch type:
For an example of how to enable Frame Relay switching, see the switching examples later in this chapter.
You can configure an interface as a DTE device, DCE switch, or as a switch connected to a switch to support NNI connections. (DCE is the default.) To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
For an example of how to configure a DTE device or DCE switch, see the section "Hybrid DTE/DCE PVC Switching Example" later in this chapter.
For an example of how to configure NNI support, see the section "Pure Frame Relay DCE Example" later in this chapter.
You must specify a static route for PVC switching. To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
For an example of how to specify a static route, see the section "Pure Frame Relay DCE Example" later in this chapter.
Frame Relay Inverse ARP is a method of building dynamic address mappings in Frame Relay networks running AppleTalk, Banyan VINES, DECnet, IP, Novell IPX, and XNS. Inverse ARP allows the router to discover the protocol address of a device associated with the virtual circuit.
Inverse ARP creates dynamic address mappings, as contrasted with the frame-relay map command, which defines static mappings between a specific protocol address and a specific DLCI (see the section "Configure Dynamic or Static Address Mapping" earlier in this chapter for more information).
Inverse ARP is enabled by default but can be disabled explicitly for a given protocol and DLCI pair. Disable or reenable Inverse ARP in the following conditions:
Note If you change from a point-to-point subinterface to a multipoint subinterface, then change the subinterface number. Frame Relay Inverse ARP will be on by default, and no further action is required.
You do not need to enable or disable Inverse ARP if you have a point-to-point interface, because there is only a single destination and discovery is not required.
To select Inverse ARP, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Enable Frame Relay Inverse ARP for a specific protocol and DLCI pair, only if it was previously disabled. |
|
Disable Frame Relay Inverse ARP for a specific protocol and DLCI pair. |
Very large Frame Relay networks might have performance problems when very many DLCIs terminate in a single router and the router must replicate routing updates and service advertising updates on each DLCI. The updates can consume access-link bandwidth and cause significant latency variations in user traffic; the updates can also consume interface buffers and lead to higher packet rate loss for both user data and routing updates.
To avoid such problems, you can create a special broadcast queue for an interface. The broadcast queue is managed independently of the normal interface queue, has its own buffers, and has a configurable size and service rate.
A broadcast queue is given a maximum transmission rate (throughput) limit measured in both bytes per second and packets per second. The queue is serviced to ensure that no more than this maximum is provided. The broadcast queue has priority when transmitting at a rate below the configured maximum, and hence has a guaranteed minimum bandwidth allocation. The two transmission rate limits are intended to avoid flooding the interface with broadcasts. The actual transmission rate limit in any second is the first of the two rate limits that is reached.
To create a broadcast queue, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
TCP/IP header compression, as described by RFC 1144, is designed to improve the efficiency of bandwidth utilization over low-speed serial links. A typical TCP/IP packet includes a 40-byte datagram header. Once a connection is established, the header information is redundant and need not be repeated in every packet that is sent. By reconstructing a smaller header that identifies the connection and indicates the fields that changed and the amount of change, fewer bytes can be transmitted. The average compressed header is 10 bytes long.
For this algorithm to function, packets must arrive in order. If packets arrive out of order, the reconstruction will appear to create regular TCP/IP packets but the packets will not match the original. Because priority queuing changes the order in which packets are transmitted, enabling priority queueing on the interface is not recommended.
You can configure TCP/IP header compression in either of two ways, as described in the following sections:
The "Disable TCP/IP Header Compression" section describes how to disable this feature.
Note If you configure an interface with Cisco encapsulation and TCP/IP header compression, Frame Relay IP maps inherit the compression characteristics of the interface. However, if you configure the interface with IETF encapsulation, the interface cannot be configured for compression. Frame Relay maps will have to be configured individually to support TCP/IP header compression.
TCP/IP header compression requires Cisco encapsulation. If you need to have IETF encapsulation on an interface as a whole, you can still configure a specific IP map to use Cisco encapsulation and TCP header compression.
In addition, even if you configure the interface to perform TCP/IP header compression, you can still configure a specific IP map not to compress TCP/IP headers.
You can specify whether TCP/IP header compression is active or passive. Active compression subjects every outgoing packet to TCP/IP header compression. Passive compression subjects an outgoing TCP/IP packet to header compression only if the packet had a compressed TCP/IP header when it was received.
To configure an IP map to use Cisco encapsulation and TCP/IP header compression, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure an IP map to use Cisco encapsulation and TCP/IP header compression. |
frame-relay map ip-address dlci [broadcast] cisco tcp header-compression {active | passive} |
The default encapsulation is cisco.
Note An interface that is configured to support TCP/IP header compression cannot also support priority queuing or custom queuing.
For an example of how to configure TCP header compression on an IP map, see the "TCP/IP Header Compression Examples" section later in this chapter.
You can configure the interface with active or passive TCP/IP header compression. Active compression, the default, subjects all outgoing TCP/IP packets to header compression. Passive compression subjects an outgoing packet to header compression only if the packet had a compressed TCP/IP header when it was received on that interface.
To apply TCP/IP header compression to an interface, you must perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Note If an interface configured with Cisco encapsulation is later configured with IETF encapsulation, all TCP/IP header compression characteristics are lost. To apply TCP/IP header compression over an interface configured with IETF encapsulation, you must configure individual IP maps, as described in the section "Configure an Individual IP Map for TCP/IP Header Compression."
For an example of how to configure TCP header compression on an interface, see the "TCP/IP Header Compression Examples" section later in this chapter.
You can disable TCP/IP header compression by using either of two commands that have different effects, depending on whether Frame Relay IP maps have been explicitly configured for TCP/IP header compression or have inherited their compression characteristics from the interface.
Frame Relay IP maps that have explicitly configured TCP/IP header compression must also have TCP/IP header compression explicitly disabled.
To disable TCP/IP header compression, perform one of the following tasks in interface configuration mode:
For an example of how to turn off TCP header compression, see the section "Disabling Inherited TCP/IP Header Compression Example."
You can specify which Frame Relay packets have low priority or low time sensitivity and will be the first to be dropped when a Frame Relay switch is congested. The mechanism that allows a Frame Relay switch to identify such packets is the discard eligibility (DE) bit.
This feature requires that the Frame Relay network be able to interpret the DE bit. Some networks take no action when the DE bit is set. Other networks use the DE bit to determine which packets to discard. The most desirable interpretation is to use the DE bit to determine which packets should be dropped first and also which packets have lower time sensitivity.
You can define DE lists that identify the characteristics of packets to be eligible for discarding, and you can also specify DE groups to identify the DLCI that is affected.
To define a DE list specifying the packets that can be dropped when the Frame Relay switch is congested, perform the following task in global configuration mode:
| Task | Command |
|---|---|
frame-relay de-list list-number {protocol protocol | interface type number} characteristic |
You can specify DE lists based on the protocol or the interface, and on characteristics such as fragmentation of the packet, a specific TCP or UDP port, an access list number, or packet size. See the frame-relay de-list command for arguments and other information.
To define a DE group specifying the DE list and DLCI affected, perform the following task in interface configuration mode:
To monitor Frame Relay connections, perform any of the following tasks in EXEC mode:
| Task | Command |
|---|---|
Clear dynamically created Frame Relay maps, which are created by the use of inverse ARP. |
|
| 1This command is documented in the "Interface Commands" chapter of the Router Products Command Reference publication. |
This section provides examples of Frame Relay configurations. It includes the following sections:
The first example that follows sets IETF encapsulation at the interface level. The second example sets IETF encapsulation on a per-DLCI basis. In the first example, the keyword ietf sets the default encapsulation method for all maps to IETF.
In the following example, IETF encapsulation is configured on a per-DLCI basis. This configuration has the same result as the configuration in the first example.
The following sections provide examples of static address mapping for the IP, AppleTalk, DECnet, and IPX protocols.
The following examples illustrate how to configure two routers for static mode.
The following example illustrates how to configure two routers to communicate with each other using AppleTalk over a Frame Relay network. Each router has a Frame Relay static address map for the other router. The use of the appletalk cable-range command indicates that this is extended AppleTalk (Phase II).
The following example sends all DECnet packets destined for address 56.4 out on DLCI 101. In addition, any DECnet broadcasts for interface serial 1 will be sent on that DLCI.
The following example illustrates how to send packets destined for IPX address 200.0000.0c00.7b21 out on DLCI 102:
The following sections provide basic Frame Relay subinterface examples and variations appropriate for different routed protocols and for bridging.
In the following example, subinterface 1 models a point-to-point subnet and subinterface 2 models a broadcast subnet. For emphasis, the multipoint keyword is used for serial subinterface 2, even though a subinterface is multipoint by default.
To use Frame Relay DLCIs 42, 64, and 73 as separate point-to-point links and run transparent bridging over them, the configuration might look like the following example:
From the bridging spanning tree algorithm's point of view, each PVC is a separate bridge port, and a frame arriving on a PVC can be relayed back out a separate PVC.
The following example configures a serial interface for Frame Relay encapsulation and sets up multiple IPX virtual networks corresponding to Frame Relay subinterfaces:
For subinterface serial 0.1, the router at the other end might be configured as follows:
The following example sets up unnumbered IP over subinterfaces at both ends of a point-to-point connection. In this example, Router A functions as the DTE, and Router B functions as the DCE. Routers A and B are both attached to Token Ring networks.
In the following example, Frame Relay DLCIs 42, 64, and 73 are to be used as separate point-to-point links with transparent bridging running over them. The bridging spanning tree algorithm views each PVC as a separate bridge port, and a frame arriving on the PVC can be relayed back out a separate PVC. Be sure that routing is not enabled when configuring transparent bridging using subinterfaces.
The following configuration provides backward compatibility and interoperability with earlier versions that are not compliant with RFC 1490. The ietf keyword is used to generate RFC 1490 traffic. This configuration is possible because of the flexibility provided by separately defining each map entry.
Configure IETF based on map entries and protocol for more flexibility. Use this method of configuration for backward compatibility and interoperability.
When booting from a TFTP server over Frame Relay, you cannot boot from a network server via a broadcast. You must boot from a specific TFTP host. Also, a frame-relay map command must exist for the host that you will boot from.
For example, if file gs3-bfx is to be booted from a host with IP address 131.108.126.2, the following commands would need to be in the configuration:
The frame-relay map command is used to map an IP address into a DLCI address. In order to boot over Frame Relay, the address of the machine to netboot from must be given explicitly, and a frame-relay map entry must exist for that site. For example, if file gs3-bfx.83-2.0 is to be booted from a host with IP address 131.108.126.111, the following commands would need to be in the configuration:
In this case, 100 is the DLCI that can get to host 131.108.126.111.
The remote router must have the following frame-relay map entry:
This entry allows the remote router to return a boot image (from the netboot host) to the router netbooting over Frame Relay. Here, 101 is a DLCI of the router being netbooted.
The following sections provide several examples of configuring one or more routers as Frame Relay switches:
You can configure your router as a dedicated, DCE-only Frame Relay switch. Switching is based on DLCIs. The incoming DLCI is examined, and the outgoing interface and DLCI are determined. Switching takes place when the incoming DLCI in the packet is replaced by the outgoing DLCI, and the packet is sent out the outgoing interface.
In the following example, the router switches two PVCs between interface serial 1 and 2. Frames with DLCI 100 received on serial 1 will be transmitted with DLCI 200 on serial 2 (see Figure 9-4).
Using the PVC switching feature, it is possible to build an entire Frame Relay network using our routers. In the following example, Router A and Router C act as Frame Relay switches implementing a two-node network. The standard Network to Network Interface (NNI) signaling protocol is used between Router A and Router C (see Figure 9-5).
Routers can also be configured as hybrid DTE/DCE Frame Relay switches (see Figure 9-6).
In the following example, Router B acts as a hybrid DTE/DCE Frame Relay switch. It can switch frames between the two DCE ports and between a DCE port and a DTE port. Traffic from the Frame Relay network can also be terminated locally. In the example, three PVCs are defined, as follows:
DLCI 400 is also defined for locally terminated traffic.
Switching over an IP tunnel is done by creating a point-to-point tunnel across the internetwork over which PVC switching can take place (see Figure 9-7).
The following configurations illustrate how to create the IP network depicted in Figure 9-7.
The following examples show various combinations of TCP/IP header compression and encapsulation characteristics on the interface and the effect on the inheritance of those characteristics on a Frame Relay IP map.
The following example shows an interface configured for TCP/IP header compression and an IP map that inherits the compression characteristics. Note that the Frame Relay IP map is not explicitly configured for header compression.
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics; the IP map has inherited passive TCP/IP header compression:
The following example shows the use of a Frame Relay IP map to override the compression set on the interface:
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics; the IP map has not inherited TCP header compression:
The following examples show the use of two different commands to disable TCP/IP header compression.
In this first example, the initial configuration is the following:
You enter the following commands:
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics:
As a result, header compression is disabled for the first map (with DLCI 177), which inherited its header compression characteristics from the interface, but not disabled for the second map (DLCI 178), which is explicitly configured for header compression.
In this second example, the initial configuration is the same as the previous example, but you enter the following commands:
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics:
The result of the commands is to disable header compression for the first map (with DLCI 177), which inherited its header compression characteristics from the interface, and also explicitly to disable header compression for the second map (with DLCI 178), which had been explicitly configured for header compression.
Posted: Wed Jul 2 23:30:40 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
