![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This section provides the following basic information about Frame Relay networks:
The wide area bridge/router supports both bridging and routing of multiple protocols over Frame Relay. ATM, X.25, and SMDS allow only one path to be assigned to a port, which means only one of these wide area protocols can run over a path or serial line. The running of only one wide area protocol over a path or serial line is mostly true of Frame Relay; however, it is possible to configure dual permanent virtual circuits (PVCs) bound to a single logical port on a boundary router. Figure 337 shows the adding of a backup PVC on path 3 for logical port 2.
To add a backup PVC on path 3 for logical port 2, follow these steps:
1 . Configure port 2 of the NETBuilder II bridge/router number 1 for Frame Relay over a backup PVC 3 at DLCI 21, by entering:
ADD !2 -FR BackupPVC 3@21
2 . Configure port 2 of the NETBuilder II bridge/router number 2 for Frame Relay over a backup PVC 2 at DLCI 21, by entering:
ADD !2 -FR BackupPVC 2@21
Figure 337 Configuring Dual PVCs Over a Single Logical Port
PVCs are permanent circuits between the remote user and the local bridge/router. SVCs are dynamic circuits set up between the remote user and the local bridge/router, which are disconnected after data activity has stopped. You can also configure an SVC as a static connection that works like a PVC by setting the -FR SvcIdleTimer setting to zero or none. See the FR Service Parameters chapter in Reference for Enterprise OS Software for details.
ADD -AppleTalk ADDRess 50.210 @ 205
1 . When configuring the individual protocol that will transmit through Frame Relay, enter the vcid number that identifies the SVC used for the connection.
2 . Identify the local customer premises equipment (CPE) link address (telephone number) assigned by your Frame Relay network service provider for your NETBuilder bridge/router, which identifies the local bridge/router port to the network, using:
SETDefault !<port> -FR LinkAddress = [<E.164 address> (1-15 digits) | <X.121 address> (1-15 digits)
3 . Enter the destination address (the telephone number) of the remote user associated with the bridge/router virtual circuit ID using:
ADD !<port> -FR SvcDestAddress = <vcid> [<E.164 address> (1-15 digits) | <X.121 address> (1-15 digits)
4 . Identify the local SVC telephone number associated with a specified virtual circuit ID (<vcid>) to the remote user (optional) using:
SETDefault !<port> -FR SvcLocalAddress = <vcid> [<E.164 address> (1-15 digits) | <X.121 address> (1-15 digits)]
Figure 338 shows NETBuilder bridge/router port 2 (in Santa Clara), over Frame Relay, connecting a remote user:
Figure 338 SVC and PVC Connections over Frame Relay
A fully meshed Frame Relay topology (Figure 339) is a topology where each node on a network is directly connected to all other nodes on the network. Each node is connected to the other nodes through a PVC, and each PVC has a DLCI associated with it. This DLCI may appear as a different number to each end of the PVC.
Figure 339 Fully Meshed Frame Relay Topology
The topology in Figure 339 is composed of NETBuilder II bridge/routers. Through the established PVCs, bridge/router A is connected to bridge/routers B, C, and D; bridge/router B is connected to bridge/routers A, C, and D; and so on.
A nonmeshed Frame Relay topology (Figure 340) is a topology where each node on a network is not necessarily connected to all other nodes on the network.
Figure 340 Nonmeshed Frame Relay Topology
The topology in Figure 340 is composed of NETBuilder II bridge/routers. Through the established PVCs, bridge/router A is connected to bridge/routers B, C, and D. bridge/routers B, C, and D are connected to bridge/router A only, but not to one another.
Transparent bridging does not correctly operate in some nonmeshed topologies. For example, in Figure 341, the transparent bridge properly forwards traffic received on !v1 to !v2. However, traffic received from one of its remote connections on !v3 is not properly forwarded to the other two remote connections on !v3; therefore, do not configure transparent bridging in this type of nonmeshed topology. The flooding algorithm floods packets on a per-port basis, not on a neighbor-per-port basis.
Figure 341 Transparent Bridging in Nonmeshed Frame Relay Topologies
A partially meshed Frame Relay topology is a topology where some nodes on a network are directly connected to nodes on the network (as in a fully meshed topology) and other nodes are not (as in a nonmeshed topology). Figure 342 is an example of a partially meshed Frame Relay topology.
Figure 342 Partially Meshed Frame Relay Topology
The topology in Figure 342 is composed of four NETBuilder II bridge/routers. Through the established PVCs, bridge/routers A, B, and C are connected to one another, but bridge/router D is connected to bridge/router A only.
Two possible solutions exist to work around the lack of connectivity between bridge/routers B, C, and D in nonmeshed and partially meshed topologies. If you are routing IP-RIP, IPX, or AppleTalk, these protocols offer the next-hop split horizon feature. In IP-RIP, set -RIPIP CONTrol to NonMesh to enable next-hop split horizon. In IPX, next-hop split horizon is enabled by manually configuring neighbors. In AppleTalk, next-hop split horizon is enabled by adding static mappings to the address mapping table.
For example, if you are routing IP-RIP and you set -RIPIP CONTrol to NonMesh, a list of neighbors containing bridge/routers B, C, and D will be generated by the system (for more information, see Reference for Enterprise OS Software), or you can configure them as neighbors using the -RIPIP AdvToNeighbor parameter.
If routing IPX, you can configure bridge/routers B, C, and D as neighbors using the -NRIP PolicyControl and -NRIP AdvToNeighbor parameters. If routing AppleTalk, you can add the address of bridge/routers B, C, and D to an address mapping table. Bridge/router A, the root bridge/router, learns available routes from each neighbor and then updates each neighbor with available routes other than the routes of that particular neighbor. Even though bridge/routers B, C, and D are not directly connected to one another, they can still learn of routes other than their own through bridge/router A.
Another solution for the lack of connectivity is to create virtual ports. Virtual ports are supported by bridging and all routing protocols over a Frame Relay network. You must use virtual ports in a Boundary Routing over Frame Relay topology and when bridging or routing DECnet, VINES, or XNS over Frame Relay in a partially meshed or nonmeshed topology. Using virtual ports in all other bridging and routing scenarios over a Frame Relay network is optional. For information on the number of virtual ports supported per platform, see Table 11 in the Configuring Advanced Ports and Paths chapter.
Virtual ports allow the creation of multiple logical ports on one path. Each PVC attaches a separate logical network. Figure 343 is a Boundary Routing over Frame Relay topology where virtual ports are configured. In this topology, even though the SuperStack II boundary routers are not directly connected to one another, information about each of their networks can still be propagated through the NETBuilder II bridge/router.
Figure 343 Using Virtual Ports in a Boundary Routing Over Frame Relay Topology
For more information on virtual ports, see the Configuring Advanced Ports and Paths chapter. For more information on Boundary Routing over a Frame Relay topology, see the Configuring Boundary Routing System Architecture chapter.
Before attaching your bridge/router to a Frame Relay network, obtain one or more virtual circuit identifiers, called DLCIs, from the Frame Relay service provider. A DLCI identifies a circuit between two devices from the end users' perspective. Each end of the circuit can have a different DLCI number for the link.
The DLCI number can range from 0 to 1023, but the service provider only assigns subscriber numbers ranging from 16 to 991. For ANSI and NTT LMI, 0 to 15 and 992 to 1023 are reserved. For LMI, 0 to 15 and 999 to 1023 are reserved.
In Figure 344, bridge/routers A, B, C, and D are assigned the DLCI numbers 36, 38, 40, and 41, respectively. The following items are examples of what occurs when packets are sent from one bridge/router to another:
3Com bridge/routers can operate in both local and global addressing schemes used by the Frame Relay network. In the standard (local) addressing convention, the DLCI number has only local significance; a duplicate number can be used by other bridge/routers. In the global addressing convention, identifiers used throughout the Frame Relay network are unique, and all traffic to a node has the same destination DLCI number.
Figure 344 Frame Relay Addressing Example
The LMI Protocol runs between the bridge/router data terminal equipment (DTE) and the Frame Relay network switching equipment data communications equipment (DCE). The LMI Protocol provides information about all devices that are accessible on the Frame Relay network by listing all DLCIs connecting the local system with the remote ones. The LMI Protocol improves reliability between the DTE and DCE by exchanging keepalive packets that are sent every 5 to 30 seconds, depending on the configuration. If the LMI Protocol is disabled, the bridge/router assumes that all the DLCIs are active whether they are up and running or not. The LMI Protocol is enabled by default on your bridge/router.
Some switches do not run the LMI Protocol. In this situation, set the -FR CONTrol parameter to NoLMI. For complete information on this parameter, see the FR Service Parameters chapter in Reference for Enterprise OS Software.
This section describes how disaster recovery works, including the use of virtual ports, dial-up, and leased lines.
Disaster recovery is a mechanism that allows you to maintain connectivity between your central and remote sites in the event of a primary line failure or the Frame Relay network failure. This section describes how to use virtual ports and explains possible points of failure in a Frame Relay network.
If you are configuring disaster recovery over Frame Relay on the peripheral node of a Boundary Routing environment, do not configure network resiliency or the central MAC address.
To configure disaster recovery, you must create virtual ports. A PVC attached to the virtual port is designated as the primary PVC. After you create a virtual port, you can add a backup PVC to that virtual port to support disaster recovery. For additional information about configuring virtual ports over Frame Relay, see the Configuring Advanced Ports and Paths chapter.
You must configure virtual ports on both ends of the connection, and you must designate the same PVC on both ends of the connection as a primary PVC. When configuring a backup PVC, you must designate the same PVC on both ends of the connection as the backup PVC. Figure 336 is an example. The PVCs 5@30 at site A and 2@30 at site B are both designated as primary PVCs. 6@45 at site A and 3@45 at site B are both designated as backup PVCs. If you designate a PVC as primary on one end and backup on the other end, all packets are dropped.
You can configure the backup PVC on a separate link to provide redundancy. If the backup PVC is on a separate link, this link can be a leased line or a dial-up line. You can use a dial-up line only on one end of the connection. In most cases, a permanent connection is established between the router at the central site and the switch. At the remote site, the router establishes a connection with the switch using a dial-up link.
When using a dial-up link on a Frame Relay network, only the router can dial out by establishing a connection with the Frame Relay switch. The Frame Relay switch cannot dial out and can accept only incoming connections. When the switch accepts these incoming connections, it activates the PVC associated with that link. Since the switch cannot dial out to establish an end-to-end connection with the router, you must establish a permanent connection between the router and the Frame Relay switch on one side of your configuration. Establishing this connection enables the other side to dial out if the primary PVC fails.
The following points of failure are possible on a Frame Relay network:
A fully redundant network is one on which there is no single point of failure. In a partially redundant network, at least one point of possible failure exists. Data is not transmitted across a backup PVC when the primary PVC is active, which ensures correct sequencing of packets.
The triggering of the backup PVC is kept transparent to the network layer protocols by using DLCI substitution. In the case of a primary PVC failure, Frame Relay sends and receives data using the backup DLCI by substituting the primary DLCI for the backup DLCI in the packet before passing data to the network layer protocols. As long as a PVC exists that can carry the traffic on a virtual port, there is no change in port status, and the network layer protocols are unaware that the backup DLCI is being used.
In a Frame Relay disaster recovery environment, sessions may need to be restarted if a failure occurs on the primary PVC. By default LMI and Annex-D LMI provide full status information for the DLCIs every 60 seconds. If a failure occurs at one end of the primary PVC, it may take up to 60 seconds to inform the other end of the PVC. If a dial-up line is used for the backup PVC, additional time may be necessary to establish the connection. These delays can cause session timeout.
If you are configuring disaster recovery over Frame Relay on the peripheral node of a Boundary Routing environment, do not configure network resiliency. You must decide which type of redundancy best suits your needs.
The following examples show the locations of redundant links and possible points of failure in partially redundant networks.
In Figure 345, central site A is connected to remote site B. A redundant link (shown as the dotted line) is configured at site B, but not at site A. In this configuration, a failure of the link at site A or a failure of the Frame Relay network can bring down the connection between site A and site B.
Figure 345 Partially Redundant Network with Redundant Link at Site B
Table 95 shows the covered and uncovered links for Figure 345 if a primary line or switch fails.
|
Links Covered for Failure |
Links Not Covered for Failure |
|---|---|
|
Link failure at site B |
Link failure at site A |
|
|
Frame Relay network failure |
Figure 346 shows a partially redundant configuration in which the redundant link is located at site A. At site B, a link failure or a Frame Relay network failure can bring down the connection between the two sites.
Figure 346 Partially Redundant Network with Redundant Link at Site A
Table 96 shows the covered and uncovered links for Figure 346 if a primary line or switch fails.
|
Links Covered for Failure |
Links Not Covered for Failure |
|---|---|
|
Link failure at site A |
Link failure at site B |
|
|
Frame Relay network failure |
In Figure 347, the network configuration has redundant links at both site A and site B. The point of failure in this configuration is the Frame Relay network.
Figure 347 Partially Redundant Network with Redundant Links at Site A and Site B
Table 97 shows the covered and uncovered links in this network configuration if a primary line or switch fails.
|
Links Covered for Failure |
Links Not Covered for Failure |
|---|---|
|
Link failure at either end |
Frame Relay network failure |
The following example shows the location of a redundant link between two sites.
Figure 348 shows a Frame Relay configuration that is fully redundant between site A and site B. There is no single point of failure between sites A and B, because redundancy is provided for all possible points of failure between these nodes. Sites A and B have redundant links, and both sites A and B are connected to two different Frame Relay networks. DLCI 40 is the primary PVC going between site A and site B. DLCI 45 is the backup PVC between site A and site B. Each of these PVCs belongs to a different Frame Relay network accessible through different NETBuilder bridge/router interfaces. The primary and backup PVCs are on different interfaces. The network layer protocols believe they are talking to DLCI 40, even when the backup DLCI 45 has taken over. In this configuration, there is no redundancy between site A and site C.
Figure 348 Fully Redundant Network Between Site A and Site B
Frame Relay network data traffic running over an individual virtual circuit of a NETBuilder bridge/router port will exceed network capacity at times. You can configure Frame Relay congestion control for individual virtual circuits to monitor and control the throughput of outgoing data when network capacity is exceeded.
You can configure two types of congestion control:
This section describes how congestion control for other LMI protocol users works. This section also describes how to avoid SNA performance problems when a port is configured for congestion control and LLC2 and SNA.
Congestion control, for bridge/router ports configured to use an LMI protocol other than NTTLMI, optimizes the traffic throughput of a virtual circuit when the traffic exceeds the network capacity by having the bridge/router reduce its traffic load. After the congestion disappears, the bridge/router increases its traffic load again.
When a Frame Relay network is congested, it sets the frames with the Backward Explicit Congestion Notification (BECN) bit set to 1 to notify the NETBuilder bridge/router of the congestion. When the first BECN=1 frame arrives at the bridge/router port to activate congestion control, the current throughput rate on the virtual circuit is reduced to a maximum rate equal to the value of cir.
To turn on congestion control and to set up how many consecutive BECN=1 frames must be sent before the current throughput rate on the virtual circuit is reduced to a maximum rate below the value of cir for the <vcid>, use:
ADD !<port> -FR CongestControl <vcid> [Yes | No] <step> (1-999)
<Vcid> identifies the Frame Relay virtual circuit to be set up for congestion control. The <vcid> for a PVC connection is the DLCI assigned by the Frame Relay service provider from a range of DLCI numbers. The <vcid> for an SVC connection is a DLCI that you assign from the range of DLCI numbers available that have not been assigned for a PVC connection.
<Step> specifies how many consecutive BECN=1 frames must be received before congestion control lowers the throughput rate to a value below cir. Zero is not allowed as a value for <step>, because it indicates that the no BECN=1 frames are required to activate congestion control. Also, <step> should not be set to too large a number because that large of an amount of BECN=1 frames may never reach the bridge/router port in time to activate congestion control while the traffic overload is occurring.
How the congestion control is executed is determined by the values entered for the -FR CIRbothdir parameter, which uses the following syntax:
ADD !<port> -FR CIRbothdir <vcid> <cir> <mincir> <Bc> <Be>
For PVCs, enter for <mincir> the same value you enter for <cir>.
When configuring congestion control, follow these rules:
When the first BECN=1 frame arrives at the bridge/router port to activate congestion control, the current throughput rate on the virtual circuit is reduced to a maximum rate equal to the value of cir. When the configured number of consecutive BECN=1 frames arrive at the bridge/router port, the maximum throughput rate lowers 1/4 to 0.750 times the value of cir as shown in Table 98.
Further throughput rate reduction occurs only when the next number of consecutive BECN=1 frames arrive at the bridge/router port. After the reduction, a throughput increase of 1/8 the existing maximum throughput occurs when the port receives a number of consecutive BECN=0 frames equal to 1/2 of the number of consecutive BECN=1 frames configured for <step>.
For example, if you have configured <step> for 5 consecutive BECN=1 frames for a particular port, it requires 3 BECN=0 frames to increase the throughput by 1/8 of the existing maximum throughput because 2.5, which is half of 5, is rounded up to 3 frames.
The following example shows how congestion control reduces maximum throughput rates for a port as it receives BECN=1 frames, and increases maximum throughput rates as it receives BECN=0 frames.
In this example, cir is equal to 100 kbps, and step is 5. See Table 98 when going through this process:
1 . The port receives one BECN=1 frame and the maximum transmit rate is 100 kbps or cir.
2 . The port receives 5 consecutive BECN=1 frames, which limits the maximum transmit rate to 75 kbps.
3 . The port receives 5 more consecutive BECN=1 frames, which limits the maximum transmit rate to 50 kbps.
4 . The port receives 3 consecutive BECN=0 frames, which increases the maximum transmit rate to 50 times 1.125 = 56.25 kbps.
5 . The port receives 3 more consecutive BECN=0 frames, which increases the maximum transmit rate to 56.25 times 1.125 = 63.28 kbps.
6 . The port receives 5 more consecutive BECN=1 frames, which increases the limits to the maximum transmit rate equal to 50 kbps.
Setting Frame Relay Congestion Control for a port that is configured for LLC2 and SNA over Frame Relay can lower the performance of SNA. The performance can decrease in an SNA network running many LLC2 sessions because LLC2 could take a long time in locating all existing LLC2 sessions to resume the transmission of SNA traffic over the Frame Relay network when it becomes uncongested. Poor response time is an indicator that the SNA performance could be affected by Frame Relay Congestion Control being active in the LLC2 protocol layer.
The -LLC2 FRCongestCont parameter is used to disable Frame Relay from sending messages when the network is congested and uncongested to the LLC2 layer. Disabling Frame Relay Congestion Control for LLC2 enables SNA to regain its former performance.
See "FRCongestCont" in the LLC2 Service Parameters chapter in Reference for Enterprise OS Software for details about this parameter.
Auto startup does not determine the type of data network you subscribe to. After auto startup, you can set this value using the PDNtype parameter in the FR Service. This is a tuning feature.
For example, the following command configures port 2 to FR Service with the Sprint public data network:
SETDefault !2 -FR PDNtype = SPRint
This information applies to all NETBuilder bridge/router platforms.