- Wide-Area Networking Overview
- Configuring Frame Relay
- Adaptive Frame Relay Traffic Shaping for Interface Congestion
- Frame Relay 64-Bit Counters
- Frame Relay MIB Enhancements
- Frame Relay Point-Multipoint Wireless
- Frame Relay Queueing and Fragmentation at the Interface
- Frame Relay PVC Bundles with QoS Support for IP and MPLS
- Frame Relay Voice-Adaptive Traffic Shaping and Fragmentation
- Frame Relay IP RTP Priority
- PPP over Frame Relay
- MQC-Based Frame Relay Traffic Shaping
- Frame Relay PVC Interface Priority Queueing
- Multilink Frame Relay FRF.16.1
- Distributed Multilink Frame Relay FRF.16
- Configuring Frame Relay-ATM Interworking
- Frame Relay-ATM Interworking Supported Standards
Contents
- Wide-Area Networking Overview
- Finding Feature Information
- Frame Relay
- Frame Relay-ATM Internetworking
- Switched Multimegabit Data Service
- Link Access Procedure - Balanced and X.25
- Layer 2 Virtual Private Network
- Layer 2 Tunneling Protocol Version 3
- L2VPN Pseudowire Redundancy
- Layer 2 Virtual Private Network Interworking
- Layer 2 Local Switching
- Wide Area Application Services
Wide-Area Networking Overview
Cisco IOS software provides a range of wide-area networking capabilities to fit almost every network environment need. Cisco offers cell relay via the Switched Multimegabit Data Service (SMDS), circuit switching via ISDN, packet switching via Frame Relay, and the benefits of both circuit and packet switching via Asynchronous Transfer Mode (ATM). LAN emulation (LANE) provides connectivity between ATM and other LAN types. The Cisco IOS Wide-Area Networking Configuration Guide presents a set of general guidelines for configuring the following software components:
This module gives a high-level description of each technology. For specific configuration information, see the appropriate module.
- Finding Feature Information
- Frame Relay
- Switched Multimegabit Data Service
- Link Access Procedure - Balanced and X.25
- Layer 2 Virtual Private Network
- Wide Area Application Services
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Frame Relay
The Cisco Frame Relay implementation currently supports routing on IP, DECnet, AppleTalk, XNS, Novell IPX, CLNS, Banyan VINES, and transparent bridging.
Although Frame Relay access was originally restricted to leased lines, dialup access is now supported. For more information about dialer profiles or legacy dial-on-demand routing (DDR), see the module Dial-on-Demand Routing Configuration.
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 module Loading and Maintaining System Images.
To configure access between Systems Network Architecture (SNA) devices over a Frame Relay network, see the module Configuring SNA Frame Relay Access Support.
The Frame Relay software provides the following capabilities:
Support for the three generally implemented specifications of Frame Relay Local Management Interfaces (LMIs): Conformity to ITU-T I-series (ISDN) recommendation as I122, "Framework for Additional Packet Mode Bearer Services": Conformity to Internet Engineering Task Force (IETF) encapsulation in accordance with RFC 2427, except bridging.
Support for a keepalive mechanism, a multicast group, and a status message, as follows: - The keepalive mechanism provides an exchange of information between the network server and the switch to verify that data is flowing.
- The multicast mechanism provides the network server with a local data-link connection identifier (DLCI) and a multicast DLCI. This feature is specific to our implementation of the Frame Relay joint specification.
- The status mechanism provides an ongoing status report on the DLCIs known by the switch.
Support for both PVCs and SVCs in the same sites and routers. Support for Frame Relay Traffic Shaping beginning with Cisco IOS Release 11.2. Traffic shaping provides the following: - Rate enforcement for individual circuits--The peak rate for outbound traffic can be set to the committed information rate (CIR) or some other user-configurable rate.
- Dynamic traffic throttling on a per-virtual-circuit basis--When backward explicit congestion notification (BECN) packets indicate congestion on the network, the outbound traffic rate is automatically stepped down; when congestion eases, the outbound traffic rate is stepped up again.
- Enhanced queueing support on a per-virtual circuit basis--Custom queueing, priority queueing, and weighted fair queueing can be configured for individual virtual circuits.
Transmission of congestion information from Frame Relay to DECnet Phase IV and CLNS. This mechanism promotes forward explicit congestion notification (FECN) bits from the Frame Relay layer to upper-layer protocols after checking for the FECN bit on the incoming DLCI. Use this Frame Relay congestion information to adjust the sending rates of end hosts. FECN-bit promotion is enabled by default on any interface using Frame Relay encapsulation. No configuration is required.
Support for Frame Relay Inverse ARP as described in RFC 1293 for the AppleTalk, Banyan VINES, DECnet, IP, and IPX protocols, and for native hello packets for DECnet, CLNP, and Banyan VINES. It allows a router running Frame Relay to discover the protocol address of a device associated with the virtual circuit.
- Support for Frame Relay switching, whereby packets are switched based on the DLCI--a Frame Relay equivalent of a Media Access Control (MAC)-level address. Routers are configured as a hybrid DTE switch or pure Frame Relay DCE access node in the Frame Relay network.
Frame Relay switching is used when all traffic arriving on one DLCI can be sent out on another DLCI to the same next-hop address. In such cases, the Cisco IOS software need not examine the frames individually to discover the destination address, and, as a result, the processing load on the router decreases.
The Cisco implementation of Frame Relay switching provides the following functionality:
Switching over an IP tunnel
Switching over Network-to-Network Interfaces (NNI) to other Frame Relay switches
Local serial-to-serial switching
Switching over ISDN B channels
Traffic shaping on switched PVCs
Congestion management on switched PVCs
Traffic policing on User-Network Interface (UNI) DCE
FRF.12 fragmentation on switched PVCs
Support for subinterfaces associated with a physical interface. The software groups one or more PVCs under separate subinterfaces, which in turn are located under a single physical interface. See the Configuring Frame Relay module.
Support for fast-path transparent bridging, as described in RFC 1490, for Frame Relay encapsulated serial and High-Speed Serial Interfaces (HSSIs) on all platforms.
Support of the Frame Relay DTE MIB specified in RFC 1315. However, the error table is not implemented. To use the Frame Relay MIB, refer to your MIB publications.
Support for Frame Relay fragmentation. Cisco has developed the following three types of Frame Relay fragmentation: - End-to-End FRF.12 Fragmentation
FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. This standard was developed to allow long data frames to be fragmented into smaller pieces (fragments) and interleaved with real-time frames. End-to-end FRF.12 fragmentation is recommended for use on PVCs that share links with other PVCs that are transporting voice and on PVCs transporting Voice over IP (VoIP). - Frame Relay Fragmentation Using FRF.11 Annex C
When VoFR (FRF.11) and fragmentation are both configured on a PVC, the Frame Relay fragments are sent in the FRF.11 Annex C format. This fragmentation is used when FRF.11 voice traffic is sent on the PVC, and it uses the FRF.11 Annex C format for data.
See the module Configuring Voice over Frame Relay in the Cisco IOS Voice, Video, and Fax Configuration Guide for configuration tasks and examples for Frame Relay fragmentation using FRF.11 Annex C. - Cisco Proprietary Fragmentation
Cisco proprietary fragmentation is used on data packets on a PVC that is also used for voice traffic.
See the module Configuring Voice over Frame Relay in the Cisco IOS Voice, Video, and Fax Configuration Guide for configuration tasks and examples for Cisco proprietary fragmentation.
- End-to-End FRF.12 Fragmentation
Frame Relay-ATM Internetworking
Cisco IOS software supports the Frame Relay Forum implementation agreements for Frame Relay-ATM Interworking. Frame Relay-ATM Interworking enables Frame Relay and ATM networks to exchange data, despite differing network protocols. There are two types of Frame Relay-ATM Interworking:
FRF.5 Frame Relay-ATM Network Interworking
FRF.5 provides network interworking functionality that allows Frame Relay end users to communicate over an intermediate ATM network that supports FRF.5. Multiprotocol encapsulation and other higher-layer procedures are transported transparently, just as they would be over leased lines.
FRF.5 describes network interworking requirements between Frame Relay Bearer Services and Broadband ISDN (BISDN) permanent virtual circuit (PVC) services.
The FRF.5 standard is defined by the Frame Relay Forum Document Number FRF.5: Frame Relay/ATM PVC Network Interworking Implementation Agreement. For information about which sections of this implementation agreement are supported by Cisco IOS software, see Frame Relay-ATM Interworking Supported Standards.
FRF.8 Frame Relay-ATM Service Interworking
FRF.8 provides service interworking functionality that allows a Frame Relay end user to communicate with an ATM end user. Traffic is translated by a protocol converter that provides communication among dissimilar Frame Relay and ATM equipment.
FRF.8 describes a one-to-one mapping between a Frame Relay PVC and an ATM PVC.
The FRF.8 standard is defined by the Frame Relay Forum Document Number FRF.8: Frame Relay/ATM PVC Network Service Interworking Implementation Agreement. For information about which sections of this implementation agreement are supported by Cisco IOS software, see Frame Relay-ATM Interworking Supported Standards.
Switched Multimegabit Data Service
The Cisco implementation of the SMDS protocol is based on cell relay technology as defined in the Bellcore Technical advisories, which are based on the IEEE 802.6 standard. We provide an interface to an SMDS network using DS1 or DS3 high-speed transmission facilities. Connection to the network is made through a device called an SDSU--an SMDS digital service unit (DSU). The SDSU attaches to a router or access server through a serial port. On the other side, the SDSU terminates the line.
The implementation of SMDS supports the IP, DECnet, AppleTalk, XNS, Novell IPX, Banyan VINES, and OSI internetworking protocols, and transparent bridging.
The implementation of SMDS also supports SMDS encapsulation over an ATM interface. For more information and for configuration tasks, see Configuring ATM.
Routing of AppleTalk, DECnet, IP, IPX, and ISO CLNS is fully dynamic; that is, the routing tables are determined and updated dynamically. Routing of the other supported protocols requires that you establish a static routing table of SMDS neighbors in a user group. Once this table is set up, all interconnected routers and access servers provide dynamic routing.
 Note | When configuring IP routing over SMDS, you may need to make adjustments to accommodate split horizon effects. Refer to the Configuring EIGRP module for information about how Cisco software handles possible split horizon conflicts. By default, split horizon is disabled for SMDS networks. |
The SMDS implementation includes multiple logical IP subnetworks support as defined by RFC 1209. This RFC describes routing IP over an SMDS cloud in which each connection is considered a host on one specific private network, and points to cases where traffic must transit from network to network.
The implementation of SMDS also provides the Data Exchange Interface (DXI) Version 3.2 with heartbeat . The heartbeat mechanism periodically generates a heartbeat poll frame.
When a multicast address is not available to a destination, pseudobroadcasting can be enabled to broadcast packets to those destinations using a unicast address.
Link Access Procedure - Balanced and X.25
X.25 is one of a group of specifications published by the ITU-T. These specifications are international standards that are formally called Recommendations . The ITU-T Recommendation X.25 defines how connections between DTE and DCE are maintained for remote terminal access and computer communications. The X.25 specification defines protocols for two layers of the Open Systems Interconnection (OSI) reference model. The data link layer protocol defined is LAPB. The network layer is sometimes called the packet level protocol (PLP), but is commonly (although less correctly) referred to as the X.25 protocol.
The ITU-T updates its Recommendations periodically. The specifications dated 1980 and 1984 are the most common versions currently in use. Additionally, the International Standards Organization (ISO) has published ISO 7776:1986 as an equivalent to the LAPB standard, and ISO 8208:1989 as an equivalent to the ITU-T 1984 Recommendation X.25 packet layer. The Cisco X.25 software follows the ITU-T 1984 Recommendation X.25 , except for its Defense Data Network (DDN) and Blacker Front End (BFE) operation, which follow the ITU-T 1980 Recommendation X.25 .
Note | The ITU-T carries out the functions of the former CCITT. The 1988 X.25 standard was the last published as a CCITT Recommendation . The first ITU-T Recommendation is the 1993 revision. |
In addition to providing remote terminal access, The Cisco X.25 software provides transport for LAN protocols--IP, DECnet, XNS, ISO CLNS, AppleTalk, Novell IPX, Banyan VINES, and Apollo Domain--and bridging.
Cisco IOS X.25 software provides the following capabilities:
LAPB datagram transport--LAPB is a protocol that operates at Level 2 (the data link layer) of the OSI reference model. It offers a reliable connection service for exchanging data (in units called frames ) with one other host. The LAPB connection is configured to carry a single protocol or multiple protocols. Protocol datagrams (IP, DECnet, AppleTalk, and so forth) are carried over a reliable LAPB connection, or datagrams of several of these protocols are encapsulated in a proprietary protocol and carried over a LAPB connection. Cisco also implements transparent bridging over multiprotocol LAPB encapsulations on serial interfaces.
X.25 datagram transport-- X.25 can establish connections with multiple hosts; these connections are called virtual circuits. Protocol datagrams (IP, DECnet, AppleTalk, and so forth) are encapsulated inside packets on an X.25 virtual circuit. Mappings between the X.25 address of a host and its datagram protocol addresses enable these datagrams to be routed through an X.25 network, thereby permitting an X.25 PDN to transport LAN protocols.
X.25 switch--X.25 calls can be routed based on their X.25 addresses either between serial interfaces on the same router (local switching) or across an IP network to another route r, using X.25 over TCP (XOT). XOT encapsulates the X.25 packet level inside a TCP connection, allowing X.25 equipment to be connected via a TCP/IP-based network. The Cisco X.25 switching features provide a convenient way to connect X.25 equipment, but do not provide the specialized features and capabilities of an X.25 PDN.
ISDN D channel--X.25 traffic over the D channel, using up to 9.6 kbps bandwidth, can be used to support many applications. For example, it may be required as a primary interface where low volume sporadic interactive traffic is the normal mode of operation. For information on how to configure X.25 on ISDN, refer to the modules Configuring X.25 on ISDN and Configuring X.25 on ISDN Using AO/DI.
PAD--User sessions can be carried across an X.25 network using the packet assembler/disassembler (PAD) protocols defined by the ITU-T Recommendations X.3 and X.29.
QLLC--The Cisco IOS software can use the Qualified Logical Link Control (QLLC) protocol to carry SNA traffic through an X.25 network.
Connection-Mode Network Service (CMNS)--CMNS is a mechanism that uses OSI-based network service access point (NSAP) addresses to extend local X.25 switching to nonserial media (for example, Ethernet, FDDI, and Token Ring). This implementation provides the X.25 PLP over Logical Link Control, type 2 (LLC2) to allow connections over nonserial interfaces. The Cisco CMNS implementation supports services defined in ISO Standards 8208 (packet level) and 8802-2 (frame level).
DDN and BFE X.25--The DDN-specified Standard Service is supported. The DDN X.25 Standard Service is the required protocol for use with DDN Packet-Switched Nodes (PSNs). The Defense Communications Agency (DCA) has certified the Cisco DDN X.25 Standard Service implementation for attachment to the DDN. The Cisco DDN implementation also includes Blacker Front End operation.
X.25 MIB--Subsets of the specifications in SNMP MIB Extension for X.25 LAPB (RFC 1381) and SNMP MIB Extension for the X.25 Packet Layer (RFC 1382) are supported. The LAPB XID Table, X.25 Cleared Circuit Table, and X.25 Call Parameter Table are not implemented. All values are read-only. To use the X.25 MIB, refer to the RFCs.
Closed User Groups (CUGs)--A CUG is a collection of DTE devices for which the network controls access between two members and between a member and a nonmember. An X.25 network can support up to 10,000 CUGs. CUGs allow various network subscribers (DTE devices) to be segregated into private subnetworks that have limited incoming or outgoing access.
The Cisco X.25 implementation does not support fast switching.
Layer 2 Virtual Private Network
L2VPN services are point-to-point. They provide Layer 2 point-to-point connectivity over either an MPLS or a pure IP (L2TPv3) core.
- Layer 2 Tunneling Protocol Version 3
- L2VPN Pseudowire Redundancy
- Layer 2 Virtual Private Network Interworking
- Layer 2 Local Switching
Layer 2 Tunneling Protocol Version 3
The Layer 2 Tunneling Protocol Version 3 feature expands Cisco’s support of Layer 2 VPNs. Layer 2 Tunneling Protocol Version 3 (L2TPv3) is an IETF l2tpext working group draft that provides several enhancements to L2TP to tunnel any Layer 2 payload over L2TP. Specifically, L2TPv3 defines the L2TP protocol for tunneling Layer 2 payloads over an IP core network by using Layer 2 VPNs.
L2VPN Pseudowire Redundancy
L2VPNs can provide pseudowire resiliency through their routing protocols. When connectivity between end-to-end PE routers fails, an alternative path to the directed LDP session and the user data can take over. However, there are some parts of the network where this rerouting mechanism does not protect against interruptions in service. The L2VPN Pseudowire Redundancy feature provides the ability to ensure that the CE2 router in can always maintain network connectivity, even if one or all the failures in the figure occur. The L2VPN Pseudowire Redundancy feature enables you to set up backup pseudowires. You can configure the network with redundant pseudowires (PWs) and redundant network elements.
Layer 2 Virtual Private Network Interworking
Layer 2 transport over MPLS and IP already exists for like-to-like attachment circuits, such as Ethernet-to-Ethernet or PPP-to-PPP. L2VPN Interworking builds on this functionality by allowing disparate attachment circuits to be connected. An interworking function facilitates the translation between the different Layer 2 encapsulations. The L2VPN Interworking feature supports Ethernet, 802.1Q (VLAN), Frame Relay, ATM AAL5, and PPP attachment circuits over MPLS and L2TPv3.
Layer 2 Local Switching
Local switching allows you to switch Layer 2 data between two interfaces of the same type (for example, ATM to ATM, or Frame Relay to Frame Relay) or between interfaces of different types (for example, Frame Relay to ATM) on the same router. The interfaces can be on the same line card or on two different cards. During these kinds of switching, the Layer 2 address is used, not any Layer 3 address. Same-port local switching allows you to switch Layer 2 data between two circuits on the same interface.
Wide Area Application Services
Cisco's WAAS Express software interoperates with WAN optimization headend applications from Cisco and improves WAN access and use by optimizing applications that require high bandwidth or are bound to a LAN, such as backup.
WAAS Express helps enterprises meet the following objectives:
Complements the Cisco WAN optimization system by adding the capability to the branch routers.
Provide branch office employees with LAN-like access to information and applications across a geographically distributed network.
Minimize unnecessary WAN bandwidth consumption through the use of advanced compression algorithms.
Virtualize print and other local services to branch office users.
Improve application performance over the WAN by addressing the following common issues: - Low data rates (constrained bandwidth)
- Slow delivery of frames (high network latency)
- Higher rates of packet loss (low reliability)
The Network Analysis Module (NAM) Performance Agent (PA) for WAAS Express analyzes and measures network traffic. The PA enables baselining, monitoring, and troubleshooting of application performance. The analysis and measurement of network traffic is done by the Measurement, Aggregation, and Correlation Engine (MACE). MACE performs the required measurements on a subset of traffic and exports the necessary metrics to a target.