Configuring Frame Relay
This chapter describes the tasks for
configuring Frame Relay on a router or access server. For a complete
description of the commands mentioned in this chapter, refer to the "Frame
Relay Commands" chapter in the Wide-Area Networking Command Reference.
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 module.
To install software on a new router or access
server 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 the Configuration Fundamentals Configuration
Guide.
To configure access between SNA devices over
a Frame Relay network, see the "Configuring SNA Frame Relay Access
Support" chapter in the Bridging and IBM Networking Configuration
Guide.
Frame Relay Hardware Configurations
•
Routers and access servers can connect
directly to a channel service unit/digital service unit (CSU/DSU), which then
connects to a remote Frame Relay switch.
Routers and access servers can connect
directly to a channel service unit/digital service unit (CSU/DSU), which then
connects to a remote Frame Relay switch. 
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.
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 25
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 (WAN).
Frame Relay Configuration Task List
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.
See the "Frame
Relay Configuration Examples" section 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 Wide-Area Networking Command Reference
for information about the commands listed in the tasks.
Enable Frame Relay Encapsulation
To set Frame Relay
encapsulation at the interface level, perform the following tasks beginning in
global configuration mode:
|
interface serial number1
|
|
|
1
This command is documented in the "Interface Commands"
chapter in the Configuration Fundamentals Command Reference.
|
Frame
Relay supports encapsulation of all supported protocols except bridging in
conformance with RFC 1490, allowing interoperability between multiple vendors.
Use the Internet Engineering Task Force (IETF) form of Frame Relay
encapsulation if your router or access server 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-data-link connection identifier (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 "Static
Address Mapping Examples" later in this chapter.
Configure Dynamic or Static Address Mapping
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 or access server;
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 that 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.
Configure Dynamic Mapping
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.
Configure Static Mapping
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:
You can 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 command
description in the Wide-Area Networking Command Reference and the
examples at the end of this chapter for more information about using the broadcast
keyword.
For examples of how to establish static
address mapping, see the "Static
Address Mapping Examples" section later in this chapter.
Configure the LMI
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.
Set the LMI Type
If the router or access server is attached to
a public data network (PDN), 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 devices: ANSI T1.617 Annex D, Cisco, and ITU-T Q.933
Annex A. To do so, perform the following task in interface configuration mode:
For an example of how to set the LMI type,
see the "Pure
Frame Relay DCE Example" section later in this chapter.
Set the LMI Keepalive Interval
A keepalive interval must
be set to enable the LMI. By default, this interval is 10 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:
For an example of how to specify an LMI
keepalive interval, see the "Two
Routers in Static Mode Example" section later in this chapter.
Set the LMI Polling and Timer Intervals
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:
See the "Frame Relay Commands"
chapter in the Wide-Area Networking Command Reference for details
about commands used to set the polling and timing intervals.
Customize Frame Relay for Your Network
Configure Frame Relay Subinterfaces
For an example of how to define a
subinterface, see the section "Subinterface
Examples" later in this chapter.
Understand Frame Relay Subinterfaces
Frame Relay subinterfaces provide a mechanism
for supporting partially meshed Frame Relay networks. 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. Transitivity is true on LANs, but not on Frame Relay
networks unless A is directly connected to C.
Additionally, certain protocols such as
AppleTalk and transparent bridging cannot 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.
Configuring Frame Relay
subinterfaces ensures that a single physical interface is treated as multiple
virtual interfaces. This capability allows us to overcome split horizon rules.
Packets received on one virtual interface can now be forwarded out another
virtual interface, even if they are configured on the same physical interface.
Subinterfaces address
the limitations of Frame Relay networks 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 )
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 network 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
network work fully is to create a fully meshed network (Network B), but doing
so requires a large number of PVCs, which may not be economically feasible.
Using subinterfaces,
you can subdivide the Frame Relay network into three smaller subnetworks
(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 can access
two subinterfaces and can therefore forward packets without violating split
horizon rules. If transparent bridging is being used, each subinterface is
viewed as a separate bridge port.
Figure 26
Using Subinterfaces to Provide Full Connectivity on a Partially Meshed Frame
Relay Network
Define Frame Relay Subinterfaces
|
interface serial
number.subinterface-number {multipoint | point-to-point}1
|
Specify a serial interface. |
1
This command is documented in the "Interface Commands"
chapter in the Configuration Fundamentals Configuration Guide.
|
Subinterfaces can be configured for
multipoint or point-to-point communication. (There is no default.)
Define Subinterface Addressing
For point-to-point
subinterfaces, the destination is presumed to be known and is identified or
implied in the frame-relay interface-dlci command. For multipoint
subinterfaces, the destinations can be dynamically resolved through the use of
Frame Relay Inverse ARP or can be statically mapped through the use of the frame-relay
map command.
Addressing on Point-to-Point Subinterfaces
If you specified a point-to-point
subinterface in Step
3 of the previous procedure, perform the following task in interface
configuration mode:
For an explanation of the many available
options, refer to this command in the Wide-Area Networking Command
Reference. For an example of how to associate a DLCI with a subinterface,
see the section "Subinterface
Examples" later in this chapter.
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 or access server. Instead, you can simply avoid using that subinterface
number and use a different subinterface number instead.
Addressing on Multipoint Subinterfaces
If you specified a multipoint subinterface in
Step
3 under "Define Frame Relay Subinterfaces," perform the tasks in
one or both of the following sections:
Accept Inverse ARP for Dynamic Address Mapping on Multipoint Subinterfaces
Dynamic address mapping
uses Frame Relay Inverse ARP to request the next hop protocol address for a
specific connection, given a DLCI. Responses to Inverse ARP requests are
entered in an address-to-DLCI mapping table on the router or access server; the
table is then used to supply the next hop protocol address or the DLCI for
outgoing traffic.
Since the physical
interface is now configured as multiple subinterfaces, you must provide
information that distinguishes a subinterface from the physical interface and
associates a specific subinterface with a specific DLCI.
To associate a specific multipoint
subinterface with a specific DLCI, perform the following task in interface
configuration mode:
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 address mapping on a subinterface.
For an example of configuring Frame Relay
multipoint subinterfaces with dynamic address mapping, see the "Frame
Relay Multipoint Subinterface with Dynamic Addressing Example"
section.
Configure Static Address Mapping on Multipoint Subinterfaces
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:
The broadcast keyword is required for
routing protocols such as OSI protocols and the Open Shortest Path First (OSPF)
protocol. See the frame-relay map command description in the Wide-Area
Networking Command Reference 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.
Configure Transparent Bridging for Frame Relay
Transparent bridging
for Frame Relay encapsulated serial and HSSI interfaces is supported on our
routers. Transparent bridging for Frame Relay encapsulated serial interfaces is
supported on our access servers.
Point-to-Point Subinterfaces
To configure transparent bridging for
point-to-point subinterfaces, complete the following tasks in interface
configuration mode:
|
bridge-group bridge-group2
|
|
1
This command is documented in the "Interface Commands"
chapter in the Configuration Fundamentals Command Reference.
2
This command is documented in the Bridging and IBM Networking Command
Reference.
|
Point-to-Multipoint Interfaces
To
configure transparent bridging for point-to-multipoint subinterfaces, complete
the following tasks in interface configuration mode:
|
1
This command is documented in the "Interface Commands"
chapter in the Configuration Fundamentals Command Reference.
2
This command is documented in the Bridging and IBM Networking Command
Reference.
|
Configure a Backup Interface for a Subinterface
Both point-to-point and multipoint Frame Relay subinterfaces
can be configured with a backup interface. This approach 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:
|
1
This command is documented in the "Interface Commands"
chapter in the Configuration Fundamentals Command Reference.
|
Configure Frame Relay Switching
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. You perform the switching by configuring your
router or access server as a Frame Relay network. There are two parts to a
Frame Relay network: a Frame Relay DTE (the router or access server) and a
Frame Relay DCE switch. illustrates
this concept.
In ,
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 devices
to be used as depicted in this Frame Relay network.
Enable Frame Relay Switching
You must enable packet switching before you
can configure it on a Frame Relay DTE or 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.
Configure a Frame Relay DTE Device, DCE Switch, or NNI Support
You can configure an interface as a DTE
device or a 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:
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.
Specify the Static Route
You must specify a
static route for PVC switching. To do so, perform the following task in
interface configuration mode:
For an example of how to specify a static
route, see the section "Pure
Frame Relay DCE Example" later in this chapter.
Disable or Reenable Frame Relay Inverse ARP
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 or access server 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 under the following conditions:
•Disable Inverse ARP for a selected protocol
and DLCI pair when you know that the protocol is not supported on the other end
of the connection.
Disable Inverse ARP for a selected protocol
and DLCI pair when you know that the protocol is not supported on the other end
of the connection.
•Reenable Inverse ARP for a protocol and DLCI
pair if conditions or equipment change and the protocol is then supported on
the other end of the connection.
Reenable Inverse ARP for a protocol and DLCI
pair if conditions or equipment change and the protocol is then supported on
the other end of the connection.
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.
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 or disable it, perform
one of the following tasks in interface configuration mode:
Create a Broadcast Queue for an Interface
Very large Frame Relay networks might have
performance problems when many DLCIs terminate in a single router or access
server that 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.
Configure Payload Compression
You can configure
payload compression on point-to-point or multipoint interfaces or
subinterfaces. Payload compression uses the stac method to predict what the
next character in the frame will be. Because the prediction is done
packet-by-packet, the dictionary is not conserved across packet boundaries.
Payload compression on each virtual circuit
consumes approximately 40 kilobytes for dictionary memory.
To configure payload compression on a
specified multipoint interface or subinterface, complete the following task:
To configure payload compression on a
specified point-to-point interface or subinterface, complete the following
task:
Configure TCP/IP Header Compression
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. Reconstructing a smaller header that identifies the
connection and indicates the fields that changed and the amount of change
reduces the number of bytes 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.
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. Configure an Individual IP Map for 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:
Note An interface that is configured to support
TCP/IP header compression cannot also support priority queuing or custom
queuing.
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.
Configure an Interface for TCP/IP Header Compression
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:
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."
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.
Disable TCP/IP Header Compression
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 examples of how to turn off TCP/IP header
compression, see the section "Disabling
Inherited TCP/IP Header Compression Example" and the section
"Disabling Explicit TCP/IP Header Compression Example."
Configure Discard Eligibility
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:
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 User Datagram Protocol (UDP) port, an access list
number, or a packet size. See the frame-relay de-list command in the Wide-Area
Networking Command Reference 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:
Configure DLCI Priority Levels
DLCI priority levels
allow you to separate different types of traffic and can provide a traffic
management tool for congestion problems caused by following situations:
•Traffic from sites with high-speed access
being queued at destination sites with lower speed access.
Traffic from sites with high-speed access
being queued at destination sites with lower speed access.
Make sure that you define each of the
DLCIs to which you intend to apply levels. You can associate priority-level
DLCIs with subinterfaces.
Note DLCI priority levels provide a way to define
multiple parallel DLCIs for different types of traffic. DLCI priority levels do
not assign priority queues within the router or access server; in fact, they
are independent of the device's priority queues. However, if you enable queuing
and use the same DLCIs for queuing, then high-priority DLCIs can be put into
high-priority queues.
DLCI priority levels provide a way to define
multiple parallel DLCIs for different types of traffic. DLCI priority levels do
not assign priority queues within the router or access server; in fact, they
are independent of the device's priority queues. However, if you enable queuing
and use the same DLCIs for queuing, then high-priority DLCIs can be put into
high-priority queues.
Note If you do not explicitly specify a DLCI for
each of the priority levels, the last DLCI specified in the command line is
used as the value of the remaining arguments. However, you must provide at
least the high-priority and the medium-priority DLCIs.
If you do not explicitly specify a DLCI for
each of the priority levels, the last DLCI specified in the command line is
used as the value of the remaining arguments. However, you must provide at
least the high-priority and the medium-priority DLCIs. Monitor the Frame Relay Connections
Frame Relay Configuration Examples
IETF Encapsulation Examples
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.
encapsulation frame-relay IETF
frame-relay map ip 131.108.123.2 48 broadcast
frame-relay map ip 131.108.123.3 49 broadcast
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.
encapsulation frame-relay
frame-relay map ip 131.108.123.2 48 broadcast ietf
frame-relay map ip 131.108.123.3 49 broadcast ietf
Static Address Mapping Examples
The following sections
provide examples of static address mapping for the IP, AppleTalk, DECnet, and
IPX protocols.
Two Routers in Static Mode Example
Configuration for Router 1
interface serial 0
!
ip address 131.108.64.2 255.255.255.0
encapsulation frame-relay
keepalive 10
frame-relay map ip 131.108.64.1 43
Configuration for Router 2
interface serial 0
!
ip address 131.108.64.1 255.255.255.0
encapsulation frame-relay
keepalive 10
frame-relay map ip 131.108.64.2 43
AppleTalk Routing Example
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).
Configuration for Router 1
!
interface Serial0
ip address 172.21.59.24 255.255.255.0
encapsulation frame-relay
appletalk cable-range 10-20 18.47
appletalk zone eng
frame-relay map appletalk 18.225 100 broadcast
Configuration for Router 2
interface Serial2/3
ip address 172.21.177.18 255.255.255.0
encapsulation frame-relay
appletalk cable-range 10-20 18.225
appletalk zone eng
clockrate 2000000
frame-relay map appletalk 18.47 100 broadcast
DECnet Routing Example
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.
decnet routing 32.6
!
interface serial 1
encapsulation frame-relay
frame-relay map decnet 56.4 101 broadcast
IPX Routing Example
The following example illustrates how to send
packets destined for IPX address 200.0000.0c00.7b21 out on DLCI 102:
ipx routing 000.0c00.7b3b
!
interface ethernet 0
ipx network 2abc
!
interface serial 0
ipx network 200
encapsulation frame-relay
frame-relay map ipx 200.0000.0c00.7b21 102 broadcast
Subinterface Examples
The following sections provide basic Frame
Relay subinterface examples and variations appropriate for different routed
protocols and for bridging.
Basic Subinterface Examples
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.
interface serial 0
encapsulation frame-relay
interface serial 0.1 point-to-point
ip address 10.0.1.1 255.255.255.0
frame-relay interface-dlci 42
interface serial 0.2 multipoint
ip address 10.0.2.1 255.255.255.0
frame-relay map 10.0.2.2 18
Frame Relay Multipoint Subinterface with Dynamic Addressing Example
The following example configures two
multipoint subinterfaces for dynamic address resolution. Each subinterface is
provided with an individual protocol address and subnet mask, and the
interface-dlci command associates the subinterface with a specified DLCI.
Addresses of remote destinations for each multipoint subinterface will be
resolved dynamically.
interface Serial0
no ip address
encapsulation frame-relay
frame-relay lmi-type ansi
!
interface Serial0.103 multipoint
ip address 172.21.177.18 255.255.255.0
frame-relay interface-dlci 300
!
interface Serial0.104 multipoint
ip address 172.21.178.18 255.255.255.0
frame-relay interface-dlci 400
IPX Routes over Frame Relay Subinterfaces Example
The following example
configures a serial interface for Frame Relay encapsulation and sets up
multiple IPX virtual networks corresponding to Frame Relay subinterfaces:
ipx routing 0000.0c02.5f4f
!
interface serial 0
encapsulation frame-relay
interface serial 0.1 multipoint
ipx network 1
frame-relay map ipx 1.000.0c07.d530 200 broadcast
interface serial 0.2 multipoint
ipx network 2
frame-relay map ipx 2.000.0c07.d530 300 broadcast
ipx routing
interface serial 2 multipoint
ipx network 1
frame-relay map ipx 1.000.0c02.5f4f 200 broadcast
Unnumbered IP over a Point-to-Point Subinterface Example
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.
Configuration for Router A
frame-relay switching
!
interface token-ring 0
ip address 131.108.177.1 255.255.255.0
!
interface serial 0
no ip address
encapsulation frame-relay IETF
!
interface Serial0.2 point-to-point
ip unnumbered TokenRing0
ip pim sparse-mode
frame-relay interface-dlci 20
Configuration for Router B:
frame-relay switching
!
interface token-ring 0
ip address 131.108.178.1 255.255.255.0
!
interface serial 0
no ip address
encapsulation frame-relay IETF
bandwidth 384
clockrate 4000000
frame-relay intf-type dce
!
interface serial 0.2 point-to-point
ip unnumbered TokenRing1
ip pim sparse-mode
bandwidth 384
frame-relay interface-dlci 20
Transparent Bridging Using Subinterfaces Example
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.
interface serial 0
encapsulation frame-relay
interface serial 0.1 point-to-point
bridge-group 1
frame-relay interface-dlci 42
interface serial 0.2 point-to-point
bridge-group 1
frame-relay interface-dlci 64
interface serial 0.3 point-to-point
bridge-group 1
frame-relay interface-dlci 73
Configuration Providing Backward Compatibility Example
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.
encapsulation frame-relay
frame-relay map ip 131.108.123.2 48 broadcast ietf
! interoperability is provided by IETF encapsulation
frame-relay map ip 131.108.123.3 49 broadcast ietf
frame-relay map ip 131.108.123.7 58 broadcast
! this line allows the router to connect with a
! device running an older version of software
frame-relay map decnet 21.7 49 broadcast
Configure IETF based on map entries and protocol for more
flexibility. Use this method of configuration for backward compatibility and
interoperability.
Booting from a Network Server over Frame Relay Example
When booting from a Trivial File Transfer Protocol (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:
boot system gs3-bfx 131.108.126.2
interface Serial 0
encapsulation frame-relay
frame-relay map IP 131.108.126.2 100 broadcast
The frame-relay map command is used to map an IP address
into a DLCI address. To boot over Frame Relay, you must explicitly give the
address of the network server to boot from, 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 must
be in the configuration:
boot system gs3-bfx.83-2.0 131.108.13.111
!
interface Serial 1
ip address 131.108.126.200 255.255.255.0
encapsulation frame-relay
frame-relay map ip 131.108.126.111 100 broadcast
frame-relay map ip 131.108.126.200 101 broadcast
This entry allows the remote router to return a boot image
(from the network server) to the router booting over Frame Relay. Here, 101 is
a DLCI of the router being booted.
Frame Relay Switching Examples
The following sections provide several
examples of configuring one or more routers as Frame Relay switches:
•PVC Switching Configuration
Example—In this example, one router
has two interfaces configured as DCEs; the router switches frames from the
incoming interface to the outgoing interface on the basis of the DLCI alone.
PVC Switching Configuration
Example—In this example, one router
has two interfaces configured as DCEs; the router switches frames from the
incoming interface to the outgoing interface on the basis of the DLCI alone.
•Pure Frame Relay DCE Example—In this example, a Frame Relay
network is set up with two routers functioning as switches; standard NNI
signaling is used between them.
Pure Frame Relay DCE Example—In this example, a Frame Relay
network is set up with two routers functioning as switches; standard NNI
signaling is used between them.
•Hybrid DTE/DCE PVC Switching
Example—In this example, one router is
configured with both DCE and DTE interfaces (a hybrid DTE/DCE Frame Relay
switch). It can switch frames between two DCE ports and between a DCE port and
a DTE port.
Hybrid DTE/DCE PVC Switching
Example—In this example, one router is
configured with both DCE and DTE interfaces (a hybrid DTE/DCE Frame Relay
switch). It can switch frames between two DCE ports and between a DCE port and
a DTE port.
•Switching over an IP Tunnel
Example—In this example, two routers
are configured to switch Frame Relay PVCs over a point-to-point IP tunnel.
Switching over an IP Tunnel
Example—In this example, two routers
are configured to switch Frame Relay PVCs over a point-to-point IP tunnel. PVC Switching Configuration Example
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 ).
Configuration for Router A
frame-relay switching
!
interface Ethernet0
ip address 131.108.160.58 255.255.255.0
!
interface Serial1
no ip address
encapsulation frame-relay
keepalive 15
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 100 interface Serial2 200
frame-relay route 101 interface Serial2 201
clockrate 2000000
!
interface Serial2
encapsulation frame-relay
keepalive 15
frame-relay intf-type dce
frame-relay route 200 interface Serial1 100
frame-relay route 201 interface Serial1 101
clockrate 64000
Pure Frame Relay DCE Example
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 ).
Configuration for Router A
frame-relay switching
!
interface ethernet 0
no ip address
shutdown
!
interface ethernet 1
no ip address
shutdown
!
interface ethernet 2
no ip address
shutdown
!
interface ethernet 3
no ip address
shutdown
!
interface serial 0
ip address 131.108.178.48 255.255.255.0
shutdown
!
interface serial 1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay lmi-type ansi
frame-relay route 100 interface serial 2 200
!
interface serial 2
no ip address
encapsulation frame-relay
frame-relay intf-type nni
frame-relay lmi-type q933a
frame-relay route 200 interface serial 1 100
clockrate 2048000
!
interface serial 3
no ip address
shutdown
Configuration for Router C
frame-relay switching
!
interface ethernet 0
no ip address
shutdown
!
interface ethernet1
no ip address
shutdown
!
interface ethernet 2
no ip address
shutdown
!
interface ethernet 3
no ip address
shutdown
!
interface serial 0
ip address 131.108.187.84 255.255.255.0
shutdown
!
interface serial 1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 300 interface serial 2 200
!
interface serial 2
no ip address
encapsulation frame-relay
frame-relay intf-type nni
frame-relay lmi-type q933a
frame-relay route 200 interface serial 1 300
!
interface serial 3
no ip address
shutdown
Hybrid DTE/DCE PVC Switching Example
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:
Configuration for Router B
frame-relay switching
!
interface ethernet 0
ip address 131.108.123.231 255.255.255.0
!
interface ethernet 1
ip address 131.108.5.231 255.255.255.0
!
interface serial 0
no ip address
shutdown
!
interface serial 1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 102 interface serial 2 201
frame-relay route 103 interface serial 3 301
!
interface serial 2
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 201 interface serial 1 102
frame-relay route 203 interface serial 3 302
!
interface serial 3
ip address 131.108.111.231
encapsulation frame-relay
frame-relay lmi-type ansi
frame-relay route 301 interface serial 1 103
frame-relay route 302 interface serial 1 203
frame-relay map ip 131.108.111.4 400 broadcast
Switching over an IP Tunnel Example
You can achieve switching
over an IP tunnel by creating a point-to-point tunnel across the internetwork
over which PVC switching can take place (see ).
Configuration for Router A
frame-relay switching
!
interface Ethernet0
ip address 108.131.123.231 255.255.255.0
!
interface Ethernet1
ip address 131.108.5.231 255.255.255.0
!
interface Serial0
no ip address
shutdown
!
interface Serial1
ip address 131.108.222.231 255.255.255.0
encapsulation frame-relay
frame-relay map ip 131.108.222.4 400 broadcast
frame-relay route 100 interface Tunnel1 200
!
interface Tunnel1
tunnel source Ethernet0
tunnel destination 150.150.150.123
Configuration for Router D
frame-relay switching
!
interface Ethernet0
ip address 131.108.231.123 255.255.255.0
!
interface Ethernet1
ip address 131.108.6.123 255.255.255.0
!
interface Serial0
ip address 150.150.150.123 255.255.255.0
encapsulation ppp
!
interface Tunnel1
tunnel source Serial0
tunnel destination 108.131.123.231
!
interface Serial1
ip address 131.108.7.123 255.255.255.0
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 300 interface Tunnel1 200
TCP/IP Header Compression Examples
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.
IP Map with Inherited TCP/IP Header Compression Example
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.
interface serial 1
encapsulation frame-relay
ip address 131.108.177.178 255.255.255.0
frame-relay map ip 131.108.177.177 177 broadcast
frame-relay ip tcp header-compression passive
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:
Router> show frame-relay map
Serial 1 (administratively down): ip 131.108.177.177
dlci 177 (0xB1,0x2C10), static,
broadcast,
CISCO
TCP/IP Header Compression (inherited), passive (inherited)
This example also applies to dynamic mappings
achieved with the use of inverse-arp on point-to-point subinterfaces where no
Frame Relay maps are configured.
Using an IP Map to Override TCP/IP Header Compression Example
The following example
shows the use of a Frame Relay IP map to override the compression set on the
interface:
interface serial 1
encapsulation frame-relay
ip address 131.108.177.178 255.255.255.0
frame-relay map ip 131.108.177.177 177 broadcast nocompress
frame-relay ip tcp header-compression passive
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:
Serial 1 (administratively down): ip 131.108.177.177
dlci 177 (0xB1,0x2C10), static,
broadcast,
CISCO
Disabling TCP/IP Header Compression Examples
Disabling Inherited TCP/IP Header Compression Example
interface serial 1
encapsulation frame-relay
ip address 131.108.177.179 255.255.255.0
frame-relay ip tcp header-compression passive
frame-relay map ip 131.108.177.177 177 broadcast
frame-relay map ip 131.108.177.178 178 broadcast tcp header-compression
serial interface 1
no frame-relay ip tcp header-compression
Use of the show frame-relay map
command will display the resulting compression and encapsulation
characteristics:
Router> show frame-relay map
Serial 1 (administratively down): ip 131.108.177.177 177
dlci 177(0xB1, 0x2C10), static,
broadcast
CISCO
Serial 1 (administratively down): ip 131.108.177.178 178
dlci 178(0xB2,0x2C20), static
broadcast
CISCO
TCP/IP Header Compression (enabled)
As a result, header compression is disabled
for the first map (with DLCI 177), which inherited its header compression
characteristics from the interface. However, header compression is not disabled
for the second map (DLCI 178), which is explicitly configured for header
compression.
Disabling Explicit TCP/IP Header Compression Example
In this second example,
the initial configuration is the same as the previous example, but you enter
the following commands:
serial interface 1
no frame-relay ip tcp header-compression
frame-relay map ip 131.108.177.178 178 nocompress
Use of the show frame-relay map
command will display the resulting compression and encapsulation
characteristics:
Router> show frame-relay map
Serial 1 (administratively down): ip 131.108.177.177 177
dlci 177(0xB1,0x2C10), static,
broadcast
CISCO
Serial 1 (administratively down): ip 131.108.177.178 178
dlci 178(0xB2,0x2C20), static
broadcast
CISCO
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 was
explicitly configured for header compression.
No comments:
Post a Comment