Frame Relay is a high-performance WAN protocol that operates at the physical and Data Link layers of the OSI reference model. Frame Relay has become one of the most extensively used WAN protocols, primarily because it is inexpensive compared to dedicated lines. X.25 was a very popular packet switching technology because it provided a very reliable connection over unreliable cabling infrastructures. It did so by including additional error control and flow control. When you build a WAN there is always a minimum of three basic components, or groups of components, connecting any two sites. Each site needs its own equipment (DTE) to access the telephone company's CO serving the area (DCE). The third component sits in the middle, joining the two access points. In the figure, this is the portion supplied by the Frame Relay backbone.
Frame Relay has lower overhead than X.25, for example, Frame Relay does not provide error correction. The Frame Relay node simply drops packets without notification when it detects errors. Any necessary error correction, such as retransmission of data, is left to the endpoints. Frame Relay handles volume and speed efficiently by combining the necessary functions of the data link and Network layers into one simple protocol. As a data link protocol, Frame Relay provides access to a network, delimits and delivers frames in proper order, and recognizes transmission errors through a standard Cyclic Redundancy Check. As a network protocol, Frame Relay provides multiple logical connections over a single physical circuit and allows the network to route data over those connections to its intended destinations.
Virtual Circuits
The connection through a Frame Relay network between two DTEs is called a virtual circuit (VC). The circuits are virtual because there is no direct electrical connection from end to end. With VCs, Frame Relay shares the bandwidth among multiple users and any single site can communicate with any other single site without using multiple dedicated physical lines. There are two ways to establish VCs:
- SVCs, switched virtual circuits, are established dynamically by sending signaling messages to the network (CALL SETUP, DATA TRANSFER, IDLE, CALL TERMINATION).
- PVCs, permanent virtual circuits, are preconfigured by the carrier, and after they are set up, only operate in DATA TRANSFER and IDLE modes
VCs provide a bidirectional communication path from one device to another. VCs are identified by DLCIs. DLCI values typically are assigned by the Frame Relay service provider (for example, the telephone company). Frame Relay DLCIs have local significance, which means that the values themselves are not unique in the Frame Relay WAN. A DLCI identifies a VC to the equipment at an endpoint. A DLCI has no significance beyond the single link. Two devices connected by a VC may use a different DLCI value to refer to the same connection.
Multiple VCs
Frame Relay is statistically multiplexed, meaning that it transmits only one frame at a time, but that many logical connections can co-exist on a single physical line. Multiple VCs on a single physical line are distinguished because each VC has its own DLCI. Remember that the DLCI has only local significance and may be different at each end of a VC. The figure shows an example of two VCs on a single access line, each with its own DLCI, attaching to a router (R1).
Note that with Frame Relay, customers pay for the bandwidth they use. In effect, they pay for a Frame Relay port. When they increase the number of ports they pay for more bandwidth.
Frame Relay Encapulation
Frame Relay takes data packets from a Network layer protocol encapsulates them as the data portion of a Frame Relay frame, and then passes the frame to the Physical layer for delivery on the wire.
First, Frame Relay accepts a packet from a Network layer protocol such as IP. It then wraps it with an address field that contains the DLCI and a checksum. Flag fields are added to indicate the beginning and end of the frame. The flag fields mark the start and end of the frame and are always the same. The flags are represented either as the hexadecimal number 7E or as the binary number 01111110. After the packet is encapsulated, Frame Relay passes the frame to the Physical layer for transport.
Frame Relay Frame
The CPE router encapsulates each Layer 3 packet inside a Frame Relay header and trailer before sending it across the VC.
Frame Relay Topologies
When more than two sites are to be connected, you must consider the topology of the connections between them. A topology is the map or visual layout of the Frame Relay network. Every network or network segment can be viewed as being one of three topology types: star, full mesh, or partial mesh.
Star Topology (Hub and Spoke)
The simplest WAN topology is a star as shown in the figure. In this topology, Span Engineering has a central site in Chicago that acts as a hub and hosts the primary services. Connections to each of the five remote sites act as spokes. In a star topology, the location of the hub is usually chosen by the lowest leased-line cost. When implementing a star topology with Frame Relay, each remote site has an access link to the Frame Relay cloud with a single VC.
Full Mesh Topology
This figure represents a full mesh topology using dedicated lines. A full mesh topology suits a situation in which the services to be accessed are geographically dispersed and highly reliable access to them is required. A full mesh topology connects every site to every other site. Using leased-line interconnections, additional serial interfaces and lines add costs
Frame Relay Address Mapping
Before a Cisco router is able to transmit data over Frame Relay, it needs to know which local DLCI maps to the Layer 3 address of the remote destination. This address-to-DLCI mapping can be accomplished either by static or dynamic mapping.
Inverse ARP
The Inverse Address Resolution Protocol, also called Inverse ARP, obtains Layer 3 addresses of other stations from Layer 2 addresses, such as the DLCI in Frame Relay networks. It is primarily used in Frame Relay and ATM networks, where Layer 2 addresses of VCs are sometimes obtained from Layer 2 signaling, and the corresponding Layer 3 addresses must be available before these VCs can be used. Whereas ARP resolves Layer 3 addresses to Layer 2 addresses, Inverse ARP does the opposite. On Cisco routers, Inverse ARP is enabled by default for all protocols enabled on the physical interface
Dynamic Mapping
Dynamic address mapping relies on Inverse ARP to resolve a next hop network protocol address to a local DLCI value. The Frame Relay router sends out Inverse ARP requests on its PVC to discover the protocol address of the remote device connected to the Frame Relay network. The router uses the responses to populate an address-to-DLCI mapping table on the Frame Relay router or access server. The router builds and maintains this mapping table, which contains all resolved Inverse ARP requests, including both dynamic and static mapping entries.
The figure shows the output of the show frame-relay map command. You can see that the interface is up and that the destination IP address is 10.1.1.2. The DLCI identifies the logical connection being used to reach this interface. This value is displayed in three ways: its decimal value (102), its hexadecimal value (0x66), and its value as it would appear on the wire (0x1860). This is a static entry, not a dynamic entry.
The user can choose to override dynamic Inverse ARP mapping by supplying a manual static mapping for the next hop protocol address to a local DLCI. A static map works similarly to dynamic Inverse ARP by associating a specified next hop protocol address to a local Frame Relay DLCI. You cannot use Inverse ARP and a map statement for the same DLCI and protocol.
An example of using static address mapping is a situation in which the router at the other side of the Frame Relay network does not support dynamic Inverse ARP for a specific network protocol. To provide accessibility, a static mapping is required to complete the remote Network layer address to local DLCI resolution.
Another example is on a hub-and-spoke Frame Relay network. Use static address mapping on the spoke routers to provide spoke-to-spoke reachability. Because the spoke routers do not have direct connectivity with each other, dynamic Inverse ARP would not work between them.
To map between a next hop protocol address and DLCI destination address, use this command: frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco].
Use the keyword ietf when connecting to a non-Cisco router.You can greatly simplify the configuration for the Open Shortest Path First (OSPF) protocol by adding the optional broadcast keyword when doing this task.
Local Management Interface (LMI)
The LMI is a keepalive mechanism that provides status information about Frame Relay connections between the router (DTE) and the Frame Relay switch (DCE). Every 10 seconds or so, the end device polls the network, either requesting a dumb sequenced response or channel status information. If the network does not respond with the requested information, the user device may consider the connection to be down. When the network responds with a FULL STATUS response, it includes status information about DLCIs that are allocated to that line.
LMI Extensions
- VC status messages - Provide information about PVC integrity by communicating and synchronizing between devices
- Multicasting - Allows a sender to transmit a single frame that is delivered to multiple recipients
- Global addressing - makes the Frame Relay network resemble a LAN in terms of addressing, and ARPs perform exactly as they do over a LAN.
- Simple flow control
LMI messages are exchanged between the DTE and DCE using these reserved DLCIs. There are several LMI types, each of which is incompatible with the others. The LMI type configured on the router must match the type used by the service provider. Three types of LMIs are supported by Cisco routers:
- Cisco - Original LMI extension
- Ansi - Corresponding to the ANSI standard T1.617 Annex D
- q933a - Corresponding to the ITU standard Q933 Annex A
If it is necessary to set the LMI type, use the frame-relay lmi-type [cisco | ansi | q933a] interface configuration command. Configuring the LMI type. When manually setting up the LMI type, you must configure the keepalive interval on the Frame Relay interface to prevent status exchanges between the router and the switch from timing out. The LMI status exchange messages determine the status of the PVC connection. By default, the keepalive time interval is 10 seconds on Cisco serial interfaces. You can change the keepalive interval with the keepalive interface configuration command.
LMI status messages combined with Inverse ARP messages allow a router to associate Network layer and Data Link layer addresses.
Configuring Basic Frame Relay
Verifying configuration with the show interfaces serial command.
Configuring a Static Frame Relay Map
Cisco routers support all Network layer protocols over Frame Relay and the address-to-DLCI mapping can be accomplished either by dynamic or static address mapping.
Dynamic mapping is performed by the Inverse ARP feature. Because Inverse ARP is enabled by default, no additional command is required to configure dynamic mapping on an interface.
Static mapping is manually configured on a router. To map between a next hop protocol address and a DLCI destination address, use the frame-relay map protocol protocol-address dlci [broadcast] command.
Using the Broadcast Keyword
Frame Relay, ATM, and X.25 are nonbroadcast multiaccess (NBMA) networks. NBMA networks allow only data transfer from one computer to another over a VC or across a switching device. NBMA networks do not support multicast or broadcast traffic, so a single packet cannot reach all destinations. This requires you to broadcast to replicate the packets manually to all destinations.
Some routing protocols may require additional configuration options. Because NBMA does not support broadcast traffic, using the broadcast keyword is a simplified way to forward routing updates. The broadcast keyword allows broadcasts and multicasts over the PVC and, in effect, turns the broadcast into a unicast so that the other node gets the routing updates
Split Horizon
By default, a Frame Relay network provides NBMA connectivity between remote sites. NBMA clouds usually use a hub-and-spoke topology. Unfortunately, a basic routing operation based on the split horizon principle can cause reachability issues on a Frame Relay NBMA network.
Recall that split horizon is a technique used to prevent a routing loop in networks using distance vector routing protocols. Split horizon updates reduce routing loops by preventing a routing update received on one interface to be forwarded out the same interface.
Routers that support multiple connections over a single physical interface have many PVCs terminating on a single interface. R1 must replicate broadcast packets, such as routing update broadcasts, on each PVC to the remote routers.
R1 has multiple PVCs on a single physical interface, so the split horizon rule prevents R1 from forwarding that routing update through the same physical interface to other remote spoke routers (R3).
Disabling split horizon may seem to be a simple solution because it allows routing updates to be forwarded out the same physical interface from which they came. However, only IP allows you to disable split horizon; IPX and AppleTalk do not. Also, disabling split horizon increases the chance of routing loops in any network.
The next obvious solution to solve the split horizon problem is to use a fully meshed topology. The preferred solution is to use subinterfaces
Frame Relay Subinterfaces
Frame Relay can partition a physical interface into multiple virtual interfaces called subinterfaces. A subinterface is simply a logical interface that is directly associated with a physical interface. Therefore, a Frame Relay subinterface can be configured for each of the PVCs coming into a physical serial interface.
To enable the forwarding of broadcast routing updates in a Frame Relay network, you can configure the router with logically assigned subinterfaces
Frame Relay subinterfaces can be configured in either point-to-point or multipoint mode:
In split horizon routing environments, routing updates received on one subinterface can be sent out another subinterface. In a subinterface configuration, each VC can be configured as a point-to-point connection. This allows each subinterface to act similarly to a leased line. Using a Frame Relay point-to-point subinterface, each pair of the point-to-point routers is on its own subnet.
The encapsulation frame-relay command is assigned to the physical interface. All other configuration items, such as the Network layer address and DLCIs, are assigned to the subinterface.
Paying for Frame Relay
From a customer's point of view then, Frame Relay is an interface and one or more PVCs. Customers simply buy Frame Relay services from a service provider. However there are some key terms and concepts to learn:
Bursting
A great advantage of Frame Relay is that any network capacity that is being unused is made available or shared with all customers, usually at no extra charge. This allows customers to "burst" over their CIR as a bonu. Because the physical circuits of the Frame Relay network are shared between subscribers, there will often be time where there is excess bandwidth available. Frame Relay can allow customers to dynamically access this extra bandwidth and "burst" over their CIR for free.
For example, DLCI 102 has a CIR of 32 kb/s with an additional CBIR of 16 kb/s for a total of up to 48 kb/s. Frames submitted at this level are marked as Discard Eligible (DE) in the frame header, indicating that they may be dropped if there is congestion or there is not enough capacity in the network. Frames within the negotiated CIR are not eligible for discard (DE = 0). Frames above the CIR have the DE bit set to 1, marking it as eligible to be discarded, should the network be congested.
The BE is the term used to describe the bandwidth available above the CBIR up to the access rate of the link. Unlike the CBIR, it is not negotiated. Frames may be transmitted at this level but will most likely be dropped.
Frame Relay Flow Control
Frame Relay reduces network overhead by implementing simple congestion-notification mechanisms rather than explicit, per-VC flow control. These congestion-notification mechanisms are the Forward Explicit Congestion Notification (FECN) and the Backward Explicit Congestion Notification (BECN).
FECN and BECN are each controlled by a single bit contained in the frame header. They let the router know that there is congestion and that the router should stop transmission until the condition is reversed. BECN is a direct notification. FECN is an indirect one. In periods of congestion, the provider's Frame Relay switch applies the following logic rules to each incoming frame based on whether the CIR is exceeded:
Queuing
Frames arriving at a switch are queued or buffered prior to forwarding. As in any queuing system, it is possible that there will be an excessive buildup of frames at a switch. This causes delays. Delays lead to unnecessary retransmissions that occur when higher level protocols receive no acknowledgment within a set time. To avoid this problem, Frame Relay incorporates a flow control feature. To reduce the flow of frames to the queue, the switch notifies DTEs of the problem using the Explicit Congestion Notification bits in the frame address field.
DTEs receiving frames with the ECN bits set are expected to try to reduce the flow of frames until the congestion clears. If the congestion occurs on an internal trunk, DTEs may receive notification even though they are not the cause of the congestion.
Configuring Frame Relay Subinterfaces
Recall that using Frame Relay subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces to overcome split horizon rules. Packets received on one virtual interface can be forwarded to 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 were reachable through a separate interface. Point-to-point subinterfaces can be unnumbered for use with IP, reducing the addressing burden that might otherwise result.
Step 1. Remove any Network layer address assigned to the physical interface. If the physical interface has an address, frames are not received by the local subinterfaces.
Step 2. Configure Frame Relay encapsulation on the physical interface using the encapsulation frame-relay command.
Step 3. For each of the defined PVCs, create a logical subinterface. Specify the port number, followed by a period (.) and the subinterface number. To make troubleshooting easier, it is suggested that the subinterface number matches the DLCI number.
Step 4. Configure an IP address for the interface and set the bandwidth.
Use the debug frame-relay lmi command to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly.
LMI status messages combined with Inverse ARP messages allow a router to associate Network layer and Data Link layer addresses.
Configuring Basic Frame Relay
Verifying configuration with the show interfaces serial command.
Configuring a Static Frame Relay Map
Cisco routers support all Network layer protocols over Frame Relay and the address-to-DLCI mapping can be accomplished either by dynamic or static address mapping.
Dynamic mapping is performed by the Inverse ARP feature. Because Inverse ARP is enabled by default, no additional command is required to configure dynamic mapping on an interface.
Static mapping is manually configured on a router. To map between a next hop protocol address and a DLCI destination address, use the frame-relay map protocol protocol-address dlci [broadcast] command.
Using the Broadcast Keyword
Frame Relay, ATM, and X.25 are nonbroadcast multiaccess (NBMA) networks. NBMA networks allow only data transfer from one computer to another over a VC or across a switching device. NBMA networks do not support multicast or broadcast traffic, so a single packet cannot reach all destinations. This requires you to broadcast to replicate the packets manually to all destinations.
Some routing protocols may require additional configuration options. Because NBMA does not support broadcast traffic, using the broadcast keyword is a simplified way to forward routing updates. The broadcast keyword allows broadcasts and multicasts over the PVC and, in effect, turns the broadcast into a unicast so that the other node gets the routing updates
Split Horizon
By default, a Frame Relay network provides NBMA connectivity between remote sites. NBMA clouds usually use a hub-and-spoke topology. Unfortunately, a basic routing operation based on the split horizon principle can cause reachability issues on a Frame Relay NBMA network.
Recall that split horizon is a technique used to prevent a routing loop in networks using distance vector routing protocols. Split horizon updates reduce routing loops by preventing a routing update received on one interface to be forwarded out the same interface.
Routers that support multiple connections over a single physical interface have many PVCs terminating on a single interface. R1 must replicate broadcast packets, such as routing update broadcasts, on each PVC to the remote routers.
R1 has multiple PVCs on a single physical interface, so the split horizon rule prevents R1 from forwarding that routing update through the same physical interface to other remote spoke routers (R3).
Disabling split horizon may seem to be a simple solution because it allows routing updates to be forwarded out the same physical interface from which they came. However, only IP allows you to disable split horizon; IPX and AppleTalk do not. Also, disabling split horizon increases the chance of routing loops in any network.
The next obvious solution to solve the split horizon problem is to use a fully meshed topology. The preferred solution is to use subinterfaces
Frame Relay Subinterfaces
Frame Relay can partition a physical interface into multiple virtual interfaces called subinterfaces. A subinterface is simply a logical interface that is directly associated with a physical interface. Therefore, a Frame Relay subinterface can be configured for each of the PVCs coming into a physical serial interface.
To enable the forwarding of broadcast routing updates in a Frame Relay network, you can configure the router with logically assigned subinterfaces
Frame Relay subinterfaces can be configured in either point-to-point or multipoint mode:
- Point-to-point - A single point-to-point subinterface establishes one PVC connection to another physical interface or subinterface on a remote router. In this case, each pair of the point-to-point routers is on its own subnet, and each point-to-point subinterface has a single DLCI. In a point-to-point environment, each subinterface is acting like a point-to-point interface
- Multipoint - A single multipoint subinterface establishes multiple PVC connections to multiple physical interfaces or subinterfaces on remote routers. All the participating interfaces are in the same subnet.
In split horizon routing environments, routing updates received on one subinterface can be sent out another subinterface. In a subinterface configuration, each VC can be configured as a point-to-point connection. This allows each subinterface to act similarly to a leased line. Using a Frame Relay point-to-point subinterface, each pair of the point-to-point routers is on its own subnet.
The encapsulation frame-relay command is assigned to the physical interface. All other configuration items, such as the Network layer address and DLCIs, are assigned to the subinterface.
Paying for Frame Relay
From a customer's point of view then, Frame Relay is an interface and one or more PVCs. Customers simply buy Frame Relay services from a service provider. However there are some key terms and concepts to learn:
- Access rate or port speed - From a customer's point of view, the service provider provides a serial connection or access link to the Frame Relay network over a leased line. The speed of the line is the access speed or port speed. Access rate is the rate at which your access circuits join the Frame Relay network.
- Committed Information Rate (CIR) - Customers negotiate CIRs with service providers for each PVC. The CIR is the amount of data that the network receives from the access circuit. The service provider guarantees that the customer can send data at the CIR. All frames received at or below the CIR are accepted.
Bursting
A great advantage of Frame Relay is that any network capacity that is being unused is made available or shared with all customers, usually at no extra charge. This allows customers to "burst" over their CIR as a bonu. Because the physical circuits of the Frame Relay network are shared between subscribers, there will often be time where there is excess bandwidth available. Frame Relay can allow customers to dynamically access this extra bandwidth and "burst" over their CIR for free.
For example, DLCI 102 has a CIR of 32 kb/s with an additional CBIR of 16 kb/s for a total of up to 48 kb/s. Frames submitted at this level are marked as Discard Eligible (DE) in the frame header, indicating that they may be dropped if there is congestion or there is not enough capacity in the network. Frames within the negotiated CIR are not eligible for discard (DE = 0). Frames above the CIR have the DE bit set to 1, marking it as eligible to be discarded, should the network be congested.
The BE is the term used to describe the bandwidth available above the CBIR up to the access rate of the link. Unlike the CBIR, it is not negotiated. Frames may be transmitted at this level but will most likely be dropped.
Frame Relay Flow Control
Frame Relay reduces network overhead by implementing simple congestion-notification mechanisms rather than explicit, per-VC flow control. These congestion-notification mechanisms are the Forward Explicit Congestion Notification (FECN) and the Backward Explicit Congestion Notification (BECN).
FECN and BECN are each controlled by a single bit contained in the frame header. They let the router know that there is congestion and that the router should stop transmission until the condition is reversed. BECN is a direct notification. FECN is an indirect one. In periods of congestion, the provider's Frame Relay switch applies the following logic rules to each incoming frame based on whether the CIR is exceeded:
- If the incoming frame does not exceed the CIR, the frame is passed.
- If an incoming frame exceeds the CIR, it is marked DE.
- If an incoming frame exceeds the CIR plus the BE, it is discarded.
Queuing
Frames arriving at a switch are queued or buffered prior to forwarding. As in any queuing system, it is possible that there will be an excessive buildup of frames at a switch. This causes delays. Delays lead to unnecessary retransmissions that occur when higher level protocols receive no acknowledgment within a set time. To avoid this problem, Frame Relay incorporates a flow control feature. To reduce the flow of frames to the queue, the switch notifies DTEs of the problem using the Explicit Congestion Notification bits in the frame address field.
- The FECN bit, indicated by the "F" in the figure, is set on every frame that the upstream switch receives on the congested link.
- The BECN bit, indicated by the "B" in the figure, is set on every frame that the switch places onto the congested link to the downstream switch.
DTEs receiving frames with the ECN bits set are expected to try to reduce the flow of frames until the congestion clears. If the congestion occurs on an internal trunk, DTEs may receive notification even though they are not the cause of the congestion.
Configuring Frame Relay Subinterfaces
Recall that using Frame Relay subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces to overcome split horizon rules. Packets received on one virtual interface can be forwarded to 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 were reachable through a separate interface. Point-to-point subinterfaces can be unnumbered for use with IP, reducing the addressing burden that might otherwise result.
To configure subinterfaces on a physical interface, the following steps are required:
Step 1. Remove any Network layer address assigned to the physical interface. If the physical interface has an address, frames are not received by the local subinterfaces.
Step 2. Configure Frame Relay encapsulation on the physical interface using the encapsulation frame-relay command.
Step 3. For each of the defined PVCs, create a logical subinterface. Specify the port number, followed by a period (.) and the subinterface number. To make troubleshooting easier, it is suggested that the subinterface number matches the DLCI number.
Step 4. Configure an IP address for the interface and set the bandwidth.
Step 5. Configure the local DLCI on the subinterface using the frame-relay interface-dlci command.
After configuring a Frame Relay PVC and when troubleshooting an issue, verify that Frame Relay is operating correctly on that interface using the show interfaces command. Recall that with Frame Relay, the router is normally considered a DTE device. However, a Cisco router can be configured as a Frame Relay switch. In such cases, the router becomes a DCE device when it is configured as a Frame Relay switch. The show interfaces command displays how the encapsulation is set up, along with useful Layer 1 and Layer 2 status information, including:
- LMI type
- LMI DLCI
- Frame Relay DTE/DCE type
Nessun commento:
Posta un commento